IETF Mobile IP Working Group Sri Gundavelli INTERNET DRAFT Kent Leung Expires: November 14, 2004 Cisco Systems Mobility Agent Identity Extension for Mobile IPv4 draft-sgundave-mip4-identity-ext-00.txt Status of This Memo This document is an individual submission to the Internet Engineering Task Force (IETF). Comments should be submitted to the mip4@ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document specifies a new extension that can be used by any mobility agent operating Mobile IPv4 protocol in the Mobile IP Registration messages for offering its identity to the other mobility agent receiving the message. This is a generic extension that can be used in the Registration Request or Reply message and can be used by the Home Agent, Foreign Agent and the mobile node. Gundavelli Expires 14 November 2004 [Page 1] ^L Internet Draft Mobility Agent Identity Extension 13 May 2004 1. Introduction This document specifies a new generic extension that can be used by mobility agents operating Mobile IP for IPv4 protocol. This extension provides a mechanism for any mobility agent to add its identity in the form of network address and the transport layer end point to the Mobile IP Registration messages. This enables the receiving entity to identify the mobility agent sending the message with out any ambiguity in all deployment scenarios and some involving NAT translation devices. There is a need for this extension at least in one particular scenario when a mobile node sends a registration message with the care-of address not belonging to the foreign agent through where the message is sent for the home agent. Typically, the home agents identify the foreign agent forwarding the Registration Request either by using the source address present in the IP header of the Registration Request or by using the care-of address present in the Registration Request and uses this address as an index parameter for the security association lookup. Both the schemes are insufficient for correctly identifying the foreign agent forwarding the Registration Request for the following reasons. The presence of NAT in the path between the home agent and the foreign agent will reflect the translated address of the NAT device in the IP header of the Registration Request and will not be the address of the foreign agent forwarding the request, scenario covered by [3]. The other mechanism of identifying the foreign agent using the care-of address present in the Registration Request will also fail in the scenario when a given mobile node has registered with its home agent for simultaneous bindings and desires to terminate either all of its bindings or a specific binding by using the services of its currently anchored foreign agent, as the care-of address that will be present in the Registration Request can be either of its home address or the care-of address of its currently anchored foreign agent. Using the extension defined in this draft, the foreign agent can potentially notify its identity to the home agent in a consistent manner and with out any ambiguity. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Other terminology is used as already defined in [2]. 3. Mobility Agent Identity Extension Format This extension is a non-skippable extension. It MAY be sent in the Mobile IP Registration Request or Reply message. It adheres to the short extension format described in [2]. Gundavelli Expires 14 November 2004 [Page 2] ^L Internet Draft Mobility Agent Identity Extension 13 May 2004 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source UDP Port | Destination UDP Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 14 Sub-Type Unique number given to each of the mobility entities 0 Home Agent Identity 1 Foreign Agent Identity 2 Mobile Node Identity Reserved Sent as zero Source Address Source Address of the entity adding this extension Destination Address Destination Address of the entity to where this Message will be sent Source Port Source UDP Port Destination Port Destination UDP Port 4. Overview of the Mobilty Agent Identity Extension This extension provides a mechanism for any mobility agent to encode its identity in the Mobile IP Registration Messages. Gundavelli Expires 14 November 2004 [Page 3] ^L Internet Draft Mobility Agent Identity Extension 13 May 2004 4.1 Foreign Agent Considerations The Mobility Agent Identity extension MAY be used by any foreign agent when it is forwarding a Mobile IP Registration Request to a home agent. The purpose of this extension is to notify the home agent about its care-of address. The foreign agent MAY add this extension when the care-of address in the Registration Request message it received from a mobile node does not match with any of its care-of addresses it offered to that mobile node. As per Section 3.2 and 3.7.2.2 of RFC 3344 [2], the foreign agent when using this extension MUST place it after the Mobile-Home Authentication Extension in registration messages. If the foreign agent shares a mobility security association with the home agent and therefore appends a Foreign-Home Authentication Extension, the Mobility Agent Identity Extension MUST be placed before the Foreign-Home Authentication Extension. 4.2 Home Agent Considerations The Home Agent on receiving a Mobile IP Registration Request with the Mobility Agent Identity extension and with the Foreign-Home Authentication extension MUST use the care-of address present in the Mobility Agent Identity extension for locating the security association and for validating the Foreign-Home Authentication extension. 4.3 Mobile Node Considerations This extension MAY be used in a Mobile IP Registration Request from the mobile node to the home agent when the mobile node uses a co-located care-of address. It SHOULD NOT be used when it is registering with a foreign agent care-of address. As per Section 3.2 and 3.5.2 of RFC 3344 [2], the mobile node when using this extension MUST place it before the Mobile-Home Authentication Extension in the Registration messages. 5. IANA Considerations This document proposes one new extension that requires a type number that have to be assigned by IANA. The number for the extension defined in this document has been taken from the numbering space defined for Mobile IP messages, registration extensions defined in RFC 3344 [2]. The new extension also introduces a new sub-type numbering spaces to be managed by IANA. Sub-type zero, one and two are to be allocated from this number space for the protocol extension specified in this document. Future allocations from this number space require IETF consensus. Gundavelli Expires 14 November 2004 [Page 4] ^L Internet Draft Mobility Agent Identity Extension 13 May 2004 6. Security Considerations The Mobile IP security protocol semantics are used for protecting the extension defined in this document. This proposal does not introduce any new vulnerability. The Mobility Agent Identity extension when present in the Registration Request or the Registration Reply will enable the entity receiving that message to accurately identify the agent sending the request along with its transport layer end point and thus in a way this proposal enhances the security of the Mobile IP Protocol. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 3344, Internet Engineering Task Force, August 2002. [3] H. Levkowetz, S.Vaarala Request for Comments (Proposed Standard) 3519, Mobile IP Traversal of Network Address Translation (NAT) 7. Contact Information Questions and comments about this draft should be directed to the authors: Sri Gundavelli Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134 USA Email: sgundave@cisco.com Phone: +1 408-527-6109 Kent Leung Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134 USA Email: kleung@cisco.com Phone: +1 408-526-5030 Gundavelli Expires 14 November 2004 [Page 5] ^L