draft-ietf-mip4-aaa-nai-01.txt   draft-ietf-mip4-aaa-nai-02.txt 
Mobile IP Working Group F. Johansson Mobile IP Working Group F. Johansson
Internet-Draft ipUnplugged Internet-Draft ipUnplugged
Expires: May 31, 2004 T. Johansson Expires: June 11, 2004 T. Johansson
Bytemobile Bytemobile
December 1, 2003 December 12, 2003
Mobile IPv4 Extension for carrying Network Access Identifiers Mobile IPv4 Extension for carrying Network Access Identifiers
<draft-ietf-mip4-aaa-nai-01.txt> <draft-ietf-mip4-aaa-nai-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 31, 2004. This Internet-Draft will expire on June 11, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
When a mobile node moves between two foreign networks it has to be When a mobile node moves between two foreign networks it has to be
re-authenticated. If for instance the home network has multiple re-authenticated. If the home network has both multiple
Authentication Authorization and Accounting (AAA) servers the Authentication Authorization and Accounting (AAA) servers and Home
re-authentication request may not be received by the same Home AAA Agents (HAs) in use, the Home AAA server may not have sufficient
server as previous authentication requests. In order for the new information to process the re-authentication correctly (i.e., to
Home AAA server to be able to forward the request to the correct Home ensure that the same HA continues to be used). This document defines
Agent it has to know the identity of the Home Agent. This document a Mobile IP extension that carries identities for the Home AAA and HA
defines a Mobile IP extension that carries identities in the form of servers in the form of Network Access Identifiers (NAIs). The
Network Access Identifiers (NAIs), which may be used by an HA to pass extension allows a Home Agent to pass its identity (and that of the
its identity to the mobile node which can then pass it on to the new Home AAA server) to the mobile node, which can then pass it on to the
AAA server when changing point of attachment. This extension may also local AAA server when changing its point of attachment. This
be used in other situations requiring communication of a NAI between extension may also be used in other situations requiring
Mobile IP nodes. communication of a NAI between Mobile IP nodes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 3 2. Requirements terminology . . . . . . . . . . . . . . . . . . . 3
3. NAI Carrying Extension . . . . . . . . . . . . . . . . . . . . 4 3. NAI Carrying Extension . . . . . . . . . . . . . . . . . . . . 4
3.1 Processing of the NAI Carrying Extension . . . . . . . . 5 3.1 Processing of the NAI Carrying Extension . . . . . . . . 5
4. HA Identity subtype . . . . . . . . . . . . . . . . . . . . . 5 4. HA Identity subtype . . . . . . . . . . . . . . . . . . . . . 5
5. AAAH Identity subtype . . . . . . . . . . . . . . . . . . . . 6 5. AAAH Identity subtype . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 9
1. Introduction 1. Introduction
When building networks one would like to be able to have redundancy. When building networks one would like to be able to have redundancy.
In order to achieve this, one might place multiple AAA servers in one In order to achieve this, one might place multiple AAA servers in one
domain. When a mobile node registers via a visited network the domain. When a mobile node registers via a visited network the
authentication will be handled by one of the AAA servers in the home authentication will be handled by one of the AAA servers in the home
domain. At a later point, when the mobile node moves to another domain. At a later point, when the mobile node moves to another
visited domain it again has to be authenticated. However, due to the visited domain it again has to be authenticated. However, due to the
redundancy offered by the AAA protocol, it can not be guaranteed that redundancy offered by the AAA protocol, it can not be guaranteed that
the authentication will be handled by the same AAAH server as the the authentication will be handled by the same AAAH server as the
previous one which can result in the new AAAH not knowing which HA previous one, which can result in the new AAAH not knowing which HA
the session was assigned to. This document defines a Mobile IP the session was assigned to. This document defines a Mobile IP
extension which can be used to distribute the information needed to extension which can be used to distribute the information needed to
resolve this. resolve this.
Furthermore, the only information that is normally available about Furthermore, the only information that is normally available about
the home agent in the registration request is the IP address as the home agent in the registration request is the IP address as
defined in RFC 3344 [1]. This is unfortunately not enough, since the defined in RFC 3344 [5]. This may unfortunately not be enough, since
AAA infrastructure needs to know the FQDN identity of the home agent some AAA infrastructures (such as Diameter [6]) use realm based
to be able to correctly handle the assignment of home agent. A routing; such a AAA infrastructure needs to know the FQDN identity of
reverse DNS lookup would only disclose the identity of the Mobile IP the home agent to be able to correctly handle the assignment of home
interface for that HA IP address, which may or may not have a agent. A reverse DNS lookup would only disclose the identity of the
one-to-one correspondence with the home agent FQDN identity. This is Mobile IP interface for that HA IP address, which may or may not have
the reason why the HA also includes its own identity in the a one-to-one correspondence with the home agent FQDN identity. This
registration reply. It can then be included by the mobile node in the is a reason for the HA to also include its own identity in the
coming registration requests when changing point of attachment. registration reply. The MIP v4 extension defined in this document
also has a subtype defined by which this may be done. The HA identity
can then be included by the mobile node in later registration
requests when changing point of attachment.
2. Requirements terminology 2. Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. document are to be interpreted as described in RFC 2119 [1].
The Mobile IP related terminology described in RFC 3344 [1] is used The Mobile IP related terminology described in RFC 3344 [5] is used
in this document. In addition, the following terms are used: in this document. In addition, the following terms are used:
AAAH AAAH
One of possible several AAA Servers in the Home Network One of possible several AAA Servers in the Home Network
FQDN FQDN
Fully Qualified Domain Name. Fully Qualified Domain Name.
Identity Identity
The identity of a node is equal to its FQDN. The identity of a node is equal to its FQDN.
NAI NAI
Network Access Identifier [2]. Network Access Identifier [2].
3. NAI Carrying Extension 3. NAI Carrying Extension
This section defines the NAI Carrying Extension which may be used in This section defines the NAI Carrying Extension which may be used in
Mobile IP Registration Request and Reply messages, and also in Mobile Mobile IP Registration Request and Reply messages, and also in Mobile
IP Agent Advertisements [1]. The extension may be used by any node IP Agent Advertisements [5]. The extension may be used by any node
that wants to send identity information in the form of a NAI [3]. that wants to send identity information in the form of a NAI [4].
This document also defines some subtype numbers which identify the This document also defines some subtype numbers which identify the
specific type of NAI carried, in Section 4 and Section 5. It is specific type of NAI carried, in Section 4 and Section 5. It is
expected that other types of NAI will be defined by other documents expected that other types of NAI will be defined by other documents
in the future. in the future.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | NAI ... | Type | Length | Sub-Type | NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
(Type to be assigned by IANA) (skippable) [1] (Type to be assigned by IANA) (skippable) [5]
Length 8-bit unsigned integer. Length of the extension, in octets, Length 8-bit unsigned integer. Length of the extension, in octets,
excluding the extension Type and the extension Length excluding the extension Type and the extension Length
fields. This field MUST be set to 1 plus the total length fields. This field MUST be set to 1 plus the total length
of the NAI field. of the NAI field.
Sub-Type This field describes the particular type NAI which is Sub-Type This field describes the particular type NAI which is
carried in the NAI field. carried in the NAI field.
NAI Contains the NAI [2] in a string format. NAI Contains the NAI [2] in a string format.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
contains the NAI of the HA in the form hostname@realm. Together the contains the NAI of the HA in the form hostname@realm. Together the
hostname and realm forms the complete FQDN (hostname.realm) of the hostname and realm forms the complete FQDN (hostname.realm) of the
HA. HA.
A Home Agent using this extension MUST provide it in the first A Home Agent using this extension MUST provide it in the first
Registration Reply sent to a Mobile Node which is not currently Registration Reply sent to a Mobile Node which is not currently
registered. The extension only need to be included in subsequent registered. The extension only need to be included in subsequent
Registration Replies if the same extension is included in Registration Replies if the same extension is included in
Registration Requests received from the same Mobile Node. Registration Requests received from the same Mobile Node.
A mobile node using this extension MUST, if it receives in a A mobile node using this extension MUST, if it receives it in a
registration reply message, provide it in every subsequent registration reply message, provide it in every subsequent
registration request when re-authentication is needed. If the mobile registration request when re-authentication is needed. Failure to
node requests a specific home agent and it has the information re-authenticate, for instance because no AAAH can be reached, will
result in termination of the Mobile-IP session. On initiation of a
new session a new HA Identity NAI may be provided to the Mobile node,
and the requirement above will apply to the newly received NAI.
If the mobile node requires a specific home agent and it has the NAI
available it MUST provide this extension in its initial registration available it MUST provide this extension in its initial registration
request. request.
A foreign agent which receives the Home Agent NAI by this extension A foreign agent which receives the Home Agent NAI by this extension
in a registration request SHOULD include the Home Agent NAI when in a registration request SHOULD include the Home Agent NAI when
requesting Mobile Node authentication through the AAA infrastructure requesting Mobile Node authentication through the AAA infrastructure
if the AAA protocol used can carry the information. if the AAA protocol used can carry the information.
5. AAAH Identity subtype 5. AAAH Identity subtype
skipping to change at page 6, line 33 skipping to change at page 6, line 38
Together the hostname and realm forms the complete FQDN Together the hostname and realm forms the complete FQDN
(hostname.realm) of the home AAA server. (hostname.realm) of the home AAA server.
If there exists several AAA servers in the Home Network, a Home Agent If there exists several AAA servers in the Home Network, a Home Agent
providing AAAH selection support according to this document MUST providing AAAH selection support according to this document MUST
provide the AAAH identity in the first Registration Reply sent to the provide the AAAH identity in the first Registration Reply sent to the
Mobile Node. The extension only need to be included in subsequent Mobile Node. The extension only need to be included in subsequent
Registration Replies if the same extension is included in Registration Replies if the same extension is included in
Registration Requests received from the same Mobile Node. Registration Requests received from the same Mobile Node.
A mobile node MUST always save the latest AAAH Identity received in a A mobile node SHOULD save the latest AAAH Identity received in a
registration reply message and MUST provide the AAAH Identity in registration reply message and SHOULD provide the AAAH Identity in
every registration request sent when re-authenticating. every registration request sent when re-authenticating, for
efficiency reasons. Failure to reach the indicated AAAH during
re-authentication will result in a new AAAH Identity NAI being
returned (which should then be saved and provided in subsequent
registration requests). Similarly, failure to re-authenticate, for
instance because no AAAH can be reached, will result in termination
of the Mobile-IP session; on initiation of a new session a new AAAH
Identity NAI may be provided to the Mobile Node for re-use during
later re-registrations.
A foreign agent which receives the AAAH NAI by this extension in a A foreign agent which receives the AAAH NAI by this extension in a
registration request SHOULD include the AAAH NAI provided when registration request SHOULD include the AAAH NAI provided when
requesting Mobile Node authentication through the AAA infrastructure requesting Mobile Node authentication through the AAA infrastructure
if the AAA protocol used can carry the information. if the AAA protocol used can carry the information.
6. Security Considerations 6. Security Considerations
This specification introduces new Mobile IP extensions that are used This specification introduces new Mobile IP extensions that are used
to carry mobility agent and AAA server identities, in the form of to carry mobility agent and AAA server identities, in the form of
Network Access Identifiers. The Mobile IP messages that carry this Network Access Identifiers. The Mobile IP messages that carry this
extension MUST be authenticated as described in [3], unless other extension MUST be authenticated as described in [4], unless other
authentication methods have been agreed upon. Therefore, this authentication methods have been agreed upon. Therefore, this
specification does not lessen the security of Mobile IP messages. specification does not lessen the security of Mobile IP messages.
It should be noted that the identities sent in the extensions It should be noted that the identities sent in the extensions
specified herein MAY be sent in the clear over the network. However, specified herein MAY be sent in the clear over the network. However,
the authors do not envision that this information would create any the authors do not envision that this information would create any
security issues. security issues.
7. IANA Considerations 7. IANA Considerations
This document defines one new mobile IP extension, and one new Mobile This document defines one new mobile IP extension, and one new Mobile
IP extension sub-type numbering space to be managed by IANA. IP extension sub-type numbering space to be managed by IANA.
Section 3 defines a new Mobile IP extension, the Mobile IP NAI Section 3 defines a new Mobile IP extension, the Mobile IP NAI
Carrying Extension. The type number for this extension is [TBD, Carrying Extension. The type number for this extension is [TBD,
assigned by IANA]. This extension introduces a new sub-type assigned by IANA]. This extension introduces a new sub-type
numbering space where the values 1 and 2 has been assigned values in numbering space where the values 1 and 2 has been assigned values in
this document. Approval of new Mobile IP NAI Carrying Extension this document. Approval of new Mobile IP NAI Carrying Extension
sub-type numbers is subject to Expert Review, and a specification is sub-type numbers is subject to Expert Review, and a specification is
required [5]. required [3].
The content and format for this extension is not specific to AAA The content and format for this extension is not specific to AAA
NAIs, so if in the future new NAIs are defined which does not NAIs, so if in the future new NAIs are defined which does not
strictly fall within the category of AAA NAIs, they may nevertheless strictly fall within the category of AAA NAIs, they may nevertheless
be accommodated within the subtype numbering space defined for the be accommodated within the subtype numbering space defined for the
NAI Carrying Extension defined in this document. NAI Carrying Extension defined in this document.
The value assigned to the NAI Carrying Extension should be taken from The NAI Carrying Extension should be assigned a type value from both
the IANA number space for Mobile IPv4 skippable extensions. the IANA number space for Mobile IPv4 skippable extensions, and from
the IANA number space for Mobile IPv4 advertisement extensions.
Ideally, the numbers assigned from these two numbering spaces should
have the same value.
8. Acknowledgements 8. Acknowledgements
Thanks to the original authors of the GNAIE draft, Mohamed M Khalil, Thanks to the original authors of the GNAIE draft, Mohamed M Khalil,
Emad Qaddoura, Haseeb Akhtar, Pat R. Calhoun. The original draft was Emad Qaddoura, Haseeb Akhtar, Pat R. Calhoun. The original draft was
removed from the MIP WG charter when no use was seen for the removed from the MIP WG charter when no use was seen for the
extension. The original ideas has been reused in this draft. extension. The original ideas has been reused in this draft.
Also thanks to Henrik Levkowetz and Kevin Purser for valuable Also thanks to Henrik Levkowetz and Kevin Purser for valuable
feedback and help when writing this draft. feedback and help when writing this draft.
Normative References Normative References
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
2002. Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC [2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999. 2486, January 1999.
[3] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000. Extension for IPv4", RFC 2794, March 2000.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
Levels", BCP 14, RFC 2119, March 1997. 2002.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. "Diameter Base Protocol", RFC 3588, September 2003.
Authors' Addresses Authors' Addresses
Fredrik Johansson Fredrik Johansson
ipUnplugged AB ipUnplugged AB
Arenavagen 23 Arenavagen 23
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 8 725 5916 Phone: +46 8 725 5916
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/