< 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. 23 change blocks.
	50 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/