Network Working Group H. Levkowetz Internet-Draft ipUnplugged Expires: October 27, 2004 April 28, 2004 Mobile IP v4 Home Network Access Identifiers Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt . The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html . This Internet-Draft will expire on October 27, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a Mobile IP v4 extension sub-type to be used to carry a NAI to uniquely identify the Home Network of a Mobile Node. 1. Introduction Originally, Mobile IP v4 (MIPv4) was defined for usage where both Home Agents and Mobile Nodes used publicly routable addresses. This is also currently what is covered by the base specification [RFC3344]. Operation where the Home Address of the Mobile Node is within a private address space as defined in [RFC1918] is not part of Levkowetz Expires October 27, 2004 [Page 1] Internet-Draft MIPv4 Home NAI April 2004 the specification. Subsequently, deployment within private address spaces has taken place, but this brings problems which did not exist when operating with publicly routable addresses only. One of these is unique identification of home network in the cases where different networks happen to use equally numbered RFC 1918 subnets. RFC xxxx [MIP4-AAA-NAI] defines an extension to carry Network Access Identifiers (NAIs) for AAA and other purposes. This document defines a new NAI sub-type number within the numbering space defined by RFC xxxx: a NAI with the purpose of uniquely identifying the home network of a mobile node. 1.1 Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalised. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The Mobile IP related terminology described in [RFC3344] is used in this document. In addition, the following terms are used: NAI Network Access Identifier, an identification string as specified by [RFC2486]. In this document, the NAI is restricted to a subset of those defined by RFC 2486, in that it is REQUIRED to have a realm part which ends with the fully qualified domain name of the Home Agent which advertises it. 2. Home NAI When Mobile IP v4 is deployed within private address spaces, some problems not covered by the base specification [RFC3344] appear. One problem is that there may exist many instances of the address space a mobile node identifies as its home network (the home network could for instance be the [RFC1918] private address space 192.168.1.0/24), and the mobile node can for this reason not any longer uniquely determine its home network by listening to the addresses given in router advertisements [RFC1256] on the current link, and compare those to its own home address. Levkowetz Expires October 27, 2004 [Page 2] Internet-Draft MIPv4 Home NAI April 2004 When a mobile node finds itself in a private address space network with advertised addresses which match its home network, it is in fact possible for it to ascertain whether it is in fact at home or not by attempting a de-registration with the private address of the HA advertising on the current net. As the base specification require that both the Registration Request and Registration reply contains an MN-HA authentication extension which must be verified on receipt by both parties, the MN will not succeed in de-registering with any Home Agent but its own, and can use successful de-registration as a reliable indication of being at home. However, to do this costs time, so a different way of uniquely differentiating between the home network and visited networks would be worthwhile. This document defines a Home NAI which may be advertised by a Home Agent to indicate the home network which it services. The same Home NAI may also be sent by the Home Agent to the Mobile Node in an extension as part of a Registration Reply if it is necessary to inform the Mobile Node of the Home NAI, as would be the case when doing dynamic address assignment. In order to ensure that NAIs used for this purpose are globally unique, it is REQUIRED that such NAIs have a realm part which ends with the fully qualified domain name (FQDN) of the Home Agent which advertises the NAI. It is also required that any user part of the NAI and / or a prefix of the realm part is chosen so as to make sure that the NAIs of each individual home network using the same FQDN are also unique. If more than one Home Agent provides service on a Home Network, they MUST advertise the same Home NAI. They MAY additionally advertise other NAIs such as the Home Agent NAI defined by [MIP4-AAA-NAI], which will be unique for each Home Agent. 2.1 Home NAI extension sub-type This section defines the Home NAI sub-type of the NAI Carrying Extension of [MIP4-AAA-NAI] which may be used in Mobile IP Agent Advertisements, and also in Mobile IP Registration Reply messages. The extension may be used to advertise the identity of the network link a mobility agent services, and in Registration Replies to inform a Mobile Node of the NAI advertised on its home network. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Levkowetz Expires October 27, 2004 [Page 3] Internet-Draft MIPv4 Home NAI April 2004 Type As defined by [MIP4-AAA-NAI] Length 8-bit unsigned integer. Length of the extension, in octets, excluding the extension Type and the extension Length fields. This field MUST be set to 1 plus the total length of the NAI field. Sub-Type MIP4-HOME-NAI (To be assigned by IANA from the sub-type numbering space defined by [MIP4-AAA-NAI]) NAI Contains the NAI [RFC2486] in a string format. 3. Security considerations If the Home NAI were to be used to conclusively determine that a mobile node is at home, instead of requiring a successful (authenticated) de-registration with its Home Agent, the usage of this extension might lower the security of Mobile IPv4. However, the base protocol requires that authentication of registration messages always be done between Home Agent and Mobile Node, and this document in no way changes that. On the other hand, if the Mobile Node always requires the presence of the correct Home NAI in the Mobile IP advertisements from a HA before it will even attempt a de-registration, an otherwise routinely occurring information leakage (by sending a de-registration request to a HA mistakenly believed to be the proper Home Agent for a Mobile Node) is prevented. 4. IANA Considerations This document requires that IANA allocate one new sub-type number from the numbering space defined by [MIP4-AAA-NAI] for the Mobile IP v4 NAI-carrying extension. This new sub-type is the Home NAI sub-type, described in Section 2.1. 5. References 5.1 Normative References [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP Levkowetz Expires October 27, 2004 [Page 4] Internet-Draft MIPv4 Home NAI April 2004 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [MIP4-AAA-NAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for AAA Network Access Identifiers", draft-ietf-mip4-aaa-nai-02 (work in progress), December 2003. 5.2 Informative References [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. Author's Address Henrik Levkowetz ipUnplugged AB Arenavagen 23 Stockholm S-121 28 SWEDEN Phone: +46 708 32 16 08 EMail: henrik@levkowetz.com Levkowetz Expires October 27, 2004 [Page 5] Internet-Draft MIPv4 Home NAI April 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Levkowetz Expires October 27, 2004 [Page 6]