Network Working Group J. Zhang Internet-Draft D. Pearce Expires: February 11, 2006 University of York August 10, 2005 Agent-Based Return Routability Test for Mobile IPv4 Route Optimization draft-zhang-mobopts-agent-mip4rr-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 February 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document is to propose a more deployable route optimization scheme for Mobile IPv4, which is transparent to fixed IPv4 end nodes, and does not need any preconfigured security associations. Specifically, we propose to adapt the Mobile IPv6 Return Routability Test for Mobile IPv4 route optimization, on the basis of an agent- based architecture. In order to achieve this, six new message types and formats are defined for Mobile IPv4. Zhang & Pearce Expires February 11, 2006 [Page 1] Internet-Draft Agent-Based RR for MIPv4 August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Return Routability Test for Mobile IPv4 . . . . . . . . . . . 7 5. New Message Format . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1 Normative References . . . . . . . . . . . . . . . . . . . 17 8.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Zhang & Pearce Expires February 11, 2006 [Page 2] Internet-Draft Agent-Based RR for MIPv4 August 2005 1. Introduction IP Mobility Support for IPv4, or Mobile IPv4 (MIPv4) [RFC3344], is a routing protocol standardized by the IETF to offer mobility functions for mobile hosts. It is designed based on the top of the current IPv4 infrastructure, and no modifications are required in existing fixed hosts and routers that do not understand the protocol. As a result, all datagrams destined for a Mobile Node (MN) away from home are still sent to its home network, and are then redirected by the Home Agent (HA) using the tunnelling technique to the current location (care-of address) of the MN. However, datagrams sent by the MN are forwarded directly to its Correspondent Nodes (CNs) in normal cases. This leads to the problem called triangle routing. In some situation, where the ingress filtering policy needs to be tackled in foreign networks, datagrams sent by the MN MAY be reversed tunnelled to the HA by the Foreign Agent (FA) or the MN itself, and then routed normally from the home network to the CNs. In both cases, datagrams are routed in an inefficient way, because they need to travel a longer path than in normal routing system. Moreover, the home network and the HA may incur a big burden for processing datagrams when there are a large number of MNs with heavy data traffics. To increase the routing efficiency of MIPv4, several route optimization schemes have been proposed to help datagrams be routed directly between MNs and their CNs when they are in foreign networks. However, all these schemes face a security challenge, since a Security Association (SA) needs to be set up between the two communication parties before they can run any route optimization scheme. Currently, there are still no standardized solutions to dynamically set up SAs between two random nodes in the IPv4 infrastructure. Manual SA configuration greatly discourages any MIPv4 route optimization scheme to be standardized and deployed. Mobility Support in IPv6, or Mobile IPv6 (MIPv6) [RFC3775], is another mobility support protocol designed by the IETF based on IPv6 networks. One of the major differences between MIPv6 and MIPv4 is that MIPv6 integrates route optimization support as a fundamental part of the standard, which is due to the expectation of a better support for mobility and security functions in every IPv6 node. Specifically, a method called Return Routability (RR) test is introduced to run the route optimization process between an MN and any CN. Using RR, no preconfigured SA and authentication infrastructure are required between the MN and the CN, and the possibility of suffering from attacks is limited to a very low level. In this document, we propose to adapt the MIPv6 RR test for MIPv4 route optimization. Our design goal is two fold: 1) to achieve route optimization in MIPv4 with the same security level as that in MIPv6; Zhang & Pearce Expires February 11, 2006 [Page 3] Internet-Draft Agent-Based RR for MIPv4 August 2005 2) to maintain the original MIPv4 design goal that mobility support protocol should be transparent to existing fixed nodes and ordinary routers. The structure of this paper is as follows. First an introduction on some related work on route optimization is given in section 3. Then our designed architecture and MIPv4 Return Routability test procedure are described in section 4. Afterwards in section 5 the proposed message formats are presented. Finally, security considerations and IANA considerations are outlined in section 6 and 7 respectively. 2. Requirements 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]. 3. Related Work In this section, a couple of related MIPv4 route optimization schemes and the MIPv6 RR test are reviewed. A. MIPv4 Route Optimization Extension Perkins et al. proposed the route optimization extension [Perki02] for MIPv4, which provides a means for CNs to maintain a binding cache for MNs in order to tunnel datagrams directly to them, bypassing their HA. Basically, an MN's HA and its CNs exchange the Binding Update (BU) message and the Binding Acknowledgement (BAck) message to manage the binding cache in the CNs. Obviously, in order to support this scheme, CNs MUST be modified to understand the protocol. Moreover, since the BU message needs to be authenticated, a preconfigured SA is needed between an MN's HA and a CN. These cause great difficulties for wide deployment. B. Agent-Based MIPv4 Route Optimization More recently, Vadali et al. designed an agent-based MIPv4 route optimization scheme [Vadal01], whose key idea is to introduce Correspondent Agents (CAs) in networks to maintain binding caches and tunnel datagrams on behalf of each individual CN. In this way, the route optimization function is transparent to end nodes, and hence no modifications are required in CNs. In addition, a CA MAY manage the binding caches for a number of end nodes in the same subnet. When multiple CNs in the same subnet are communicating with an MN, only one BU message is required to update the mobility binding, which reduces signalling traffics. However, the security challenge still exists since it is hard to guarantee that an MN's HA shares a SA with Zhang & Pearce Expires February 11, 2006 [Page 4] Internet-Draft Agent-Based RR for MIPv4 August 2005 any CA that it will communicate with. C. Mobile IPv6 Return Routability Test for Route Optimization In MIPv6 route optimization, a mobility option called Binding Authorization Data option [RFC3775] is defined to carry authentication data for protecting Binding Update messages. A binding management key, Kbm, which can be established through the RR test procedure, is employed in this option. The RR test involves four types of messages, which are Home Test Init (HoTI), Care-of Test Init (CoTI), Home Test (HoT), and Care-of Test (CoT). The RR procedure can be briefly described as follows: Each CN holds a secret node key, or Kcn. Each CN also periodically generates nonces. Each nonce is associated with a nonce index. An MN initiates a RR test by sending an HoTI (usually reverse tunnelled using IPsec (IP Security) encapsulating security payload (ESP) to the HA first) and a CoTI to a CN. Specifically, a 64-bit random number called the "home init cookie" is included in the HoTI, and another called the "care-of init cookie" is included in the CoTI by the MN. These cookies are to be returned by the CN in the HoT and the CoT respectively later, in order to verify that the HoT and the CoT match the HoTI and the CoTI respectively. On receipt of the HoTI, the CN returns an HoT, containing the home init cookie, home keygen token, and the index of the nonce used to calculate the home keygen token. The home keygen token is cryptographically generated from calculating a hash function over the concatenation of the Kcn, the source address of the HoTI message (the MN's home address), and a nonce: home keygen token = hash (Kcn | MN's home address | nonce | 0). The HoT is usually sent to the MN's HA in plain text first, and then forwarded to the MN using the IPsec ESP tunnel. On receipt of the CoTI, the CN returns a CoT, containing the care-of init cookie, care-of keygen token, and the index of the nonce used to calculate the care-of keygen token. The home keygen token is cryptographically generated from calculating a hash function over the concatenation of the Kcn, the source address of the CoTI message (the MN's current care-of address), and a nonce: care-of keygen token = hash (Kcn | MN's care-of address | nonce | 1). The CoT is sent directly to the MN in plain text. After receiving both HoT and CoT, the MN is able to create a binding Zhang & Pearce Expires February 11, 2006 [Page 5] Internet-Draft Agent-Based RR for MIPv4 August 2005 management key (Kbm) using a hash function over the home keygen token and the care-of keygen token obtained: Kbm = hash (home keygen token | care-of keygen token). Then the MN can send a BU message to the CN protected by the Kbm contained in the Binding Authorization Data option. Since the BU also contains both the MN's home address and care-of address, and the indices of the nonces used to generate the keygen tokens, given the Kcn, the CN is able to re-generate the keygen tokens, and then calculate the Kbm in order to authenticate the BU. A BAck message may be returned by the CN in response. Figure 1 shows the message flow of the MIPv6 route optimization procedure. MN HA CN | HoTI-Reverse Tunnelled | HoTI(home init cookie) | |-------------------------->|---------------------------->| | | | | CoTI(care-of init cookie) | |-------------------------------------------------------->| | HoT-Tunnelled | HoT(home init cookie,home | |<--------------------------|<----------------------------| | | keygen token,nonce index) | |CoT(care-of init cookie,care-of keygen token,nonce index)| |<--------------------------------------------------------| | BU(Kbm, HoA, CoA, nonce indices) | |-------------------------------------------------------->| | BAck(Kbm, binding status if sent) | |<--------------------------------------------------------| | data packets | |<------------------------------------------------------->| | | Figure 1. MIPv6 Route Optimization Procedure A successful RR test means that the node initiating the test is reachable at its claimed care-of address and its home address. In this way, route optimization can be run without the need for preconfigured SAs. Since the Kbm is available to any nodes who can get both the HoT and the CoT messages, the RR test can not prevent attacks from nodes with such capabilities. However, these nodes can launch similar attacks even without the use of Mobile IPv6. Zhang & Pearce Expires February 11, 2006 [Page 6] Internet-Draft Agent-Based RR for MIPv4 August 2005 4. Return Routability Test for Mobile IPv4 Since currently IPv4 networks are dominant and may still be used for a long time, in order to overcome the obstacles to MIPv4 route optimization deployment as discussed in section 1, and achieve a similar promising situation as in MIPv6, adapting the MIPv6 RR test for use in MIPv4 is proposed in this section. In this scheme, in order to maintain the original MIPv4 design goal that mobility support should be transparent to existing fixed IPv4 nodes, the agent-based architecture introduced in section 3.B is adopted. Figure 2 shows the basic considered architecture and the RR procedure in MIPv4. The RR procedure is very similar to that in MIPv6, unless route optimization is transparent to CNs and performed using Correspondent Agents. Here only the modifications needed to the basic MIPv4 protocol are discussed. MN HA CA CN(s) | HoTI-Reverse Tunnelled | HoTI(home init cookie) | | |-------------------------->|---------------------------->| | | | | | | CoTI(care-of init cookie) | | |-------------------------------------------------------->| | | HoT-Tunnelled | HoT(home init cookie,home | | |<--------------------------|<----------------------------| | | | keygen token,nonce index) | | |CoT(care-of init cookie,care-of keygen token,nonce index)| | |<--------------------------------------------------------| | | RRBU(Kbm, HoA, CoA, nonce indices) | | |-------------------------------------------------------->| | | RRBA(Kbm, binding status if sent) | | |<--------------------------------------------------------| | | data packets | | |<------------------------------------------------------->+<---->| | | | Figure 2. Agent-Based Return Routability Test for Mobile IPv4 Route Optimization A. New Messages Four message types for the RR test need to be defined for MIPv4: the HoTI, CoTI, HoT and CoT. In MIPv6, these messages are carried in the Mobility header. In MIPv4, we propose to send these messages by way of UDP (User Datagram Protocol) packets using the well-known port number 434, with different type values to distinguish them from other mobility messages. These message formats MUST be defined with the Zhang & Pearce Expires February 11, 2006 [Page 7] Internet-Draft Agent-Based RR for MIPv4 August 2005 capability to contain all required data for performing the RR test described in section 3.C. In addition, two other message types for managing binding caches need to be defined. In order to be distinguishable from the Binding Update and Binding Acknowledgement messages defined in [Perki02], they are called RR Binding Update (RRBU) and RR Binding Acknowledgement (RRBA). These messages are also proposed to be sent by way of UDP (port 434), with different type values to distinguish from other mobility messages. Specifically RRBU and RRBA MUST be defined with the capability to contain the authentication data (Binding Authorization Data). Having these six new messages, whether or not MIPv4 RR is supported does not affect other proposed route optimization protocols such as the basic MIPv4 route optimization extension [Perki02] described in section 3.A. This guarantees that other features (if needed) supported by other proposed route optimization scheme are not eliminated by MIPv4 RR route optimization. For example, [Perki02] defines Binding Warning and Binding Request messages in order to managing binding caches more efficiently. B. Correspondent Agent Considerations Correspondent Agents (CAs) are used in this scheme in order to mask the RR and route optimization procedures from CNs. CAs MAY be co- located with a gateway router of any IPv4 network that wishes to support the route optimization function for IPv4 mobility. CAs are supposed to be able to perform RR tests on behalf of each individual CN in their managed subnet. Therefore, a CA MUST hold a secret node key (Kcn), and periodically generate nonces with indices for each CN. It is responsible for refreshing the Kcn for each CN at any suitable time. It MUST be able to process the HoTI and CoTI messages, calculate keygen tokens, and compose the HoT and CoT messages. It MUST be able to process the RRBU message, verify the Kbm established during the RR test, and compose the RRBA message with correct status. Moreover, a CA is responsible for tunnelling datagrams from a CN that has a valid binding cache entry with an MN for route optimization. Note that a binding cache entry can only be created after receiving a successful RRBU from an MN after an RR test: this is different from the basic MIPv4 route optimization extension [Perki02], where a binding cache entry can be created on receiving a successful BU sent by an MN, its HA or even its FA, and a BU can be triggered by various methods determining when a binding cache entry should be set up. Zhang & Pearce Expires February 11, 2006 [Page 8] Internet-Draft Agent-Based RR for MIPv4 August 2005 C. Home Agent Considerations The MIPv4 HA MUST be enhanced to be able to correctly forward the HoTI and HoT messages. As mentioned earlier, the HoTI is reversed tunnelled from the MN to the HA and then redirected to the CN/CA; the HoT is sent from the CN/CA to the HA and then tunnelled to the MN. To protect the HoTI and HoT along the path between the HA and the MN, IPsec ESP tunnel mode or any other suitable protecting method is RECOMMENDED. D. Foreign Agent Considerations There are no particular requirements on the FA in order to support the MIPv4 RR route optimization. E. Mobile Node Considerations The MN MUST be able to initiate RR tests by sending the HoTI and CoTI messages containing the newly generated cookies at a suitable time (normally after a new CoA registration to the HA or whenever the MN needs a new keygen token). It MUST be able to reverse tunnel the HoTI and de-tunnel HoT messages, optionally using a suitable protecting method (such as IPsec ESP tunnel mode) negotiated with its HA. It MUST be able to process the HoT and CoT messages, generate Kbm accordingly, compose the RRBU message, and process the RRBA message. 5. New Message Format A. MIPv4 HoTI Message Format The proposed MIPv4 HoTI message format is shown in Figure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. MIPv4 Home Test Init (HoTI) Message Format IP fields: Zhang & Pearce Expires February 11, 2006 [Page 9] Internet-Draft Agent-Based RR for MIPv4 August 2005 o Source Address: The MN's HoA. o Destination Address: The CN's address. UDP fields: o Source Port: Variable. o Destination Port: 434. HoTI fields: o Type: An 8-bit value that can be distinguished from other mobility messages. To be defined by IANA. o Reserved: A 24-bit field reserved for future use. o Home Init Cookie: A 64-bit field containing the home init cookie. B. MIPv4 CoTI Message Format The proposed MIPv4 CoTI message format is shown in Figure 4. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. MIPv4 Care-of Test Init (CoTI) Message Format IP fields: o Source Address: The MN's CoA. o Destination Address: The CN's address. UDP fields: Zhang & Pearce Expires February 11, 2006 [Page 10] Internet-Draft Agent-Based RR for MIPv4 August 2005 o Source Port: Variable. o Destination Port: 434. CoTI fields: o Type: An 8-bit value that can be distinguished from other mobility messages. To be defined by IANA. o Reserved: A 24-bit field reserved for future use. o Care-of Init Cookie: A 64-bit field containing the care-of init cookie. C. MIPv4 HoT Message Format The proposed MIPv4 HoT message format is shown in Figure 5. 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 | Reserved | Home Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. MIPv4 Home Test (HoT) Message Format IP fields: o Source Address: The CN's address. o Destination Address: The MN's HoA. UDP fields: o Source Port: Variable. Zhang & Pearce Expires February 11, 2006 [Page 11] Internet-Draft Agent-Based RR for MIPv4 August 2005 o Destination Port: 434. HoT fields: o Type: An 8-bit value that can be distinguished from other mobility messages. To be defined by IANA. o Reserved: An 8-bit field reserved for future use. o Home Nonce Index: A 16-bit field containing the index of the nonce used to create the home keygen token. o Home Init Cookie: A 64-bit field containing the home init cookie. o Home Keygen Token: A 64-bit field containing the home keygen token. D. MIPv4 CoT Message Format The proposed MIPv4 CoT message format is shown in Figure 6. 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 | Reserved | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. MIPv4 Care-of Test (CoT) Message Format IP fields: o Source Address: The CN's address. o Destination Address: The MN's CoA. UDP fields: Zhang & Pearce Expires February 11, 2006 [Page 12] Internet-Draft Agent-Based RR for MIPv4 August 2005 o Source Port: Variable. o Destination Port: 434. CoT fields: o Type: An 8-bit value that can be distinguished from other mobility messages. To be defined by IANA. o Reserved: An 8-bit field reserved for future use. o Care-of Nonce Index: A 16-bit field containing the index of the nonce used to create the care-of keygen token. o Care-of Init Cookie: A 64-bit field containing the care-of init cookie. o Care-of Keygen Token: A 64-bit field containing the care-of keygen token. E. MIPv4 RRBU Message Format The proposed MIPv4 RRBU message format is shown in Figure 7. 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 |A|M|G|Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. MIPv4 Return Routability Binding Update (RRBU) Zhang & Pearce Expires February 11, 2006 [Page 13] Internet-Draft Agent-Based RR for MIPv4 August 2005 Message Format IP fields: o Source Address: The MN's CoA. o Destination Address: The CN's address. UDP fields: o Source Port: Variable. o Destination Port: 434. RRBU fields: o Type: An 8-bit value that can be distinguished from other mobility messages. To be defined by IANA. o A: The 'A' bit is set when an RRBA is required in response to the RRBU. o M: The 'M' bit is set when datagrams may be tunnelled to the MN using the minimal encapsulation protocol [RFC2004]. o G: The 'G' bit is set when datagrams may be tunnelled to the MN using Generic Routing Encapsulation (GRE) [RFC1702]. o Reserved: 5-bit field reserved for future use. o Lifetime: A 16-bit field containing the number of seconds left before the binding cache entry MUST be considered expired. A value of zero means that the binding (if exists) for the MN MUST be deleted. o Home Nonce Index: A 16-bit field containing the index of the nonce used to create the home keygen token. o Care-of Nonce Index: A 16-bit field containing the index of the nonce used to create the care-of keygen token. o MN Home Address: The MN's HoA. o MN care-of address: The MN's current CoA. When it is set equal to the MN's HoA, it means that the binding (if any exists) for the MN MUST be deleted. Zhang & Pearce Expires February 11, 2006 [Page 14] Internet-Draft Agent-Based RR for MIPv4 August 2005 o Identification: A 64-bit number used by the receiving node to sequence RRBUs and by the sending node to match returned RRBAs. o Authenticator: The 96-bit Binding Authorization Data. The calculation method of the authenticator is the same as that in MIPv6, except that the data input to the hash function are the Kbm, and the RRBU data excluding the authenticator field itself. E. MIPv4 RRBA Message Format The proposed MIPv4 RRBA message format is shown in Figure 8. 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 | Reserved | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8. MIPv4 Return Routability Binding Acknowledgement (RRBA) Message Format IP fields: o Source Address: The CN's address. o Destination Address: The MN's CoA. UDP fields: o Source Port: Variable. Zhang & Pearce Expires February 11, 2006 [Page 15] Internet-Draft Agent-Based RR for MIPv4 August 2005 o Destination Port: 434. RRBU fields: o Type: An 8-bit value that can be distinguished from other mobility messages. To be defined by IANA. o Reserved: A 16-bit field reserved for future use. o Status: An 8-bit field containing the value indicating the status of the responded RRBU. The value of zero indicates the success of an RRBU. Otherwise, 8 other values are to be defined to indicate various failure status: "reason unspecified", "administratively prohibited", "insufficient resources", "sending node failed authentication", "poorly formed RRBU", "expired home nonce index", "expired care-of nonce index", and "expired nonces". o MN Home Address: The MN's HoA. o Identification: A 64-bit number copied from the identification field of the responded RRBU. o Authenticator: The 96-bit Binding Authorization Data. The calculation method of the authenticator is the same as that in MIPv6, except that the data input to the hash function are the Kbm, and the RRBA data excluding the authenticator field itself. 6. Security Considerations The proposed MIPv4 RR test cannot prevent attacks from nodes who can receive both the HoT and CoT messages: this provides the same security level as the MIPv6 RR test. However, nodes with this capability can launch similar attacks even without the use of MIPv4 RR test. Due to the inherent security vulnerabilities of the RR test, a number of enhancing schemes have been proposed in the IRTF recently. Many of these enhancement schemes could possibly be adapted for use in the MIPv4 RR test in a similar way in the future. 7. IANA Considerations IANA should record the values for the newly defined MIPv4 messages described in section 5, in order to distinguished them from other mobility messages. 8. References Zhang & Pearce Expires February 11, 2006 [Page 16] Internet-Draft Agent-Based RR for MIPv4 August 2005 8.1 Normative References [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 8.2 Informative References [Perki02] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", draft-ietf-mobileip-optim-11.txt , April 2002. [Vadal01] Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route Optimization for Mobile IP", IEEE VTC, October 2001. Authors' Addresses Ji Zhang Communications Research Group, University of York. Heslington York YO10 5DD United Kingdom Phone: +44 1904 432310 Email: jz105@ohm.york.ac.uk David Pearce Communications Research Group, University of York. Heslington York YO10 5DD United Kingdom Phone: +44 1904 432390 Email: dajp1@ohm.york.ac.uk Zhang & Pearce Expires February 11, 2006 [Page 17] Internet-Draft Agent-Based RR for MIPv4 August 2005 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 (2005). 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. Zhang & Pearce Expires February 11, 2006 [Page 18]