Network Working Group A. Qin Internet-Draft A. Huang Expires: August 29, 2007 W. Wu B. Sarikaya Huawei Technologies February 25, 2007 PMIPv6 Route Optimization Protocol draft-qin-mipshop-pmipro-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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Qin, et al. Expires August 29, 2007 [Page 1] Internet-Draft PMIPv6 Route Optimization February 2007 Abstract This document defines route optimization protocol for PMIPv6. Proxy home test, concurrent proxy care-of test and handover procedures are explained. Proxy mobile agent uses cryptographically generated home addresses so that no more home test is needed after the initial home test. Handover home keygen token is used during handover in order to eliminate home test for the next proxy mobile agent. A different route optimization protocol is defined for inter-proxy mobile agent operation if the correspondent node is not Mobile IPv6 enabled. Qin, et al. Expires August 29, 2007 [Page 2] Internet-Draft PMIPv6 Route Optimization February 2007 1. Introduction In Proxy Mobile IPv6 (PMIPv6) scheme, the mobility is transparent to mobile nodes (MN) by the Proxy Mobility Agent (PMA) simulating a home link and acting as a proxy on mobile IP operation, also is transparent to correspondent nodes (CN) by forcing all datagrams for a mobile node to be routed through its home agent (HA). Thus, datagrams to the mobile node are often routed along paths that are significantly longer than optimal. However, packets could be routed directly between correspondent nodes and the proxy mobile agent instead of through home agent, such path is optimal. Moreover, immunity to impersonation, denial of service, and redirection-based flooding is necessary for a route optimization protocol in PMIPv6. This document presents a mechanism, based on PMIPv6 [4] and Enhanced Route Optimization for Mobile IPv6 [5], to securely establish optimal route path between PMA and correspondent nodes or between two PMAs. The following types of correspondent nodes are considered: correspondent nodes which have both Mobile IPv6 stack defined in RFC3775 and recognize PMIPv6 messages, correspondent nodes without Mobile IPv6 function which are provided mobility support by Proxy Mobile IPv6, as well as a fixed correspondent node without mobility. This document discusses both the first (Type 1 CNs) and the second (Type 2 CNs). Type 1 CN's MUST support Enhanced Route Optimization for Mobile IPv6 [5] and extensions defined in this document. PMIPv6 RO is transparent for Type 2 CNs. Some terminology is defined in Section 2. Section 3 presents PMIPv6 Route Optimization Protocol for Type 1 CNs and Section 4 presents inter-PMA route optimization protocol for Type 2 CNs. Section 5 defines home agent, Section 6 defines proxy mobile agent and Section 7 defines correspondent node behaviour. In Section 8, formats and options of messages are defined. 2. Terminology 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 [1]. Proxy Mobile Agent (PMA) The proxy mobile agent is a functional element on the access router, which is defined in [4]. In PMIPv6, proxy mobile agent acts an Mobile Ip client agent of MN. In this document, the route optimization function is also provided by PMA. Qin, et al. Expires August 29, 2007 [Page 3] Internet-Draft PMIPv6 Route Optimization February 2007 Proxy Binding Cache A cache of mobility bindings of mobile nodes, maintained by a proxy mobile agent for use in sending or forwarding datagrams to PMAs serving for these mobile nodes. Cryptographically generated home addresses A cryptographically generated home address enables correspondent nodes to securely authenticate the owner of home address (HoA), by means of a strong, cryptographic binding between the interface identifier of the address and the address owner's public key. From the perspective of correspondent node, the home address of the mobile node is owned by proxy mobile agent during route optimization procedure. In this document, proxy mobile IPv6 home addresses are cryptographically generated home addresses using its mobile node's public key. Home prefix could be per-MN prefix or shared prefix. Permanent home keygen token A secret permanent home keygen token, which is generated by a correspondent node for a mobile node, is exchanged between proxy mobile agent and a correspondent node. Permanent home keygen token is kept by proxy mobile agent. The permanent home keygen token is used to authenticate the proxy mobile agent more efficiently in subsequent correspondent registrations. The permanent home keygen token is renewed as soon as the mobile node moves to the next proxy mobile agent. Since the lifetime of proxy binding update is due, permanent home keygen token should be re- generated too. Handover home keygen token A secret handover home keygen token is used during handover, which is generated by a correspondent node for a mobile node. Handover home keygen token, kept by proxy mobile agent, is obtained along with permanent home keygen token at initial time. However, it will be not out-of-date even though the registration lifetime is due. During handover, handover home keygen token is transferred from the previous proxy mobile agent to the next proxy mobile agent. The next proxy mobile agent uses this token to authenticate the proxy binding update. Type 1 Correspondent Node A node that is Mobile IPv6 enabled to be a correspondent node as per [2]. Type 1 CNs can receive route optimized traffic from proxy mobile agents serving their mobile nodes. Type 2 Correpondent Node A mobile node that is served by proxy mobile agent. Route optimization is transparent to Type 2 CNs. Proxy mobile agent provides both mobility and route optimization services to Type 2 CNs. Qin, et al. Expires August 29, 2007 [Page 4] Internet-Draft PMIPv6 Route Optimization February 2007 3. PMIPv6 Route Optimization Protocol This section consists of a set of approaches to meet requirements of route optimization for PMIPv6. 3.1. Route Optimization for PMIPv6 Overview This document describes a route optimization protocol for PMIPv6. This protocol is based on PMIPv6 and Enhanced Route Optimization for Mobile IPv6. Once a mobile node enters its Proxy Mobile IPv6 domain, proxy mobile agent which runs on the access router does the mobility related signaling on behalf of the mobile node. In MIPv6, a mobile node may determine when and which correspondent node needs route optimization. In contrast, access router MAY inform proxy mobile agent to initiate route optimization procedure according to some policies in PMIPv6. The configuration of such policies is out of scope. As soon as proxy mobile agent makes decision on which correspondent node needs route optimization, proxy mobile agent initiates proxy home test procedure depicted in Section 3.2. Correspondent nodes verify the reachability of home address via this procedure. Correspondent nodes also need to verify the reachability of care-of address. Proxy care-of test init message is piggybacked on a proxy binding update message which is sent by proxy mobile agent on behalf of the mobile node to register with a correspondent node. After the first round trip of proxy binding update exchange is over between a correspondent node with proxy mobile agent, the correspondent node sets up a binding cache entry and MAY start routing packets directly to care-of address of the mobile node even though the care-of address is not verified. However, the proxy mobile agent obtains care-of keygen token via this round trip of proxy binding update exchange. The proxy mobile agent MAY initiate another proxy binding update exchange. Thus, the correspondent node MAY authenticate this proxy binding update with both temporary home keygen token and care-of keygen token, and then it makes sure of the validity of proxy binding cache entry created by early proxy binding update exchange. In order to protect against redirection-based flooding attacks, Credit-Based Authorization (CBA) can be exploited as described in [5]. During handover, the next proxy mobile agent simulates home link for the mobile node. For the sake of security, proxy home test should be executed over again for correspondent node to verify the rachability and validity of home address of MN. In order to reduce handover latency brought up with the proxy home test, handover home keygen Qin, et al. Expires August 29, 2007 [Page 5] Internet-Draft PMIPv6 Route Optimization February 2007 token is introduced in Section 3.4. In PMIPv6 route optimization protocol, the proxy home test and proxy care-of test exchanges are initiated by PMA instead of MN. However, both the source address of proxy home test init message and the destination address of proxy home test message are home address of mobile node. So, the proxy mobile agent MUST identify, intercept and process the home test messages. For the sake of security, cryptographically generated home addresses and permanent home keygen token, defined in [5], are used in PMIPv6 route optimization (PMIPv6RO) protocol. Cryptographically generated home addresses, CGA parameters and signature are calculated with the mobile node's public key and private key by each PMA the mobile node visits. The input parameters to the CGA calculations [3] like the subnet prefix, public key and private key are available to each PMA. One possible mechanism is context transfer from the previous PMA. In order to decrease handover latency, handover home keygen token is introduced in PMIPv6RO as a credential for the next proxy mobile agent to be more efficient by means of eliminating home test procedure. As shown in Figure 1, the optimal route path is depicted by slashes which connect correspondent node with proxy mobile agent. +------+ +----+ | HA |-------------------| CN | +------+ +----+ | HAA | | +--------------------+ // \\ / / // \\/ / +---------//-----/--------------------/--+ | // / \\ PMIP Network / | +-------//-----/----\\--------------/----+ // / \\ / // / \\ / //+----+ \\+-------/ CoA1 | | | CoA2 +----+ +----+ |PMA1|<- policies |PMA2|<- policies +----+ for RO +----+ for RO | | -.-.-> [MN] HoA Figure 1: PMIPv6 Route Optimization Operation Qin, et al. Expires August 29, 2007 [Page 6] Internet-Draft PMIPv6 Route Optimization February 2007 3.2. Proxy Home Test Procedure Proxy Home Test procedure validates the home address. It includes two messages as follows: Proxy Home Test Init (Proxy HoTI) Proxy Home Test (Proxy HoT). Since the destination address of Proxy HoT message is the home address of MN, the PMA MUST intercept and process Proxy Home Test message instead of forwarding it to MN. When handoff occurs, correspondent nodes must re-verify the reachability of home address. The next proxy mobile agent MAY also initiate the proxy home test. Proxy mobile agent must keep correspondent nodes list in its Binding Update List. When MN roams into the next PMA, these Binding Update List entries SHOULD be transferred to the next PMA using context transfer protocol or other protocols. When MN roams into the next PMA, the entries in the Binding Update List on MN identity like NAI, private and public keys, etc. SHOULD be transferred to the next PMA. The context transfer protocol is out of scope. As shown in Figure 2, the proxy mobile agent imitates the Mobile IP client of the mobile node. The Proxy Home Test Init (PHoTI) message is sent from PMA to the correspondent node, and it should be transmitted via the shared tunnel between the Home Agent and PMA. Proxy Mobile Agent Home agent Correspondent node According to some policies Decide to optimize route path | | | | | |==Proxy Home Test Init (PHoTI)=>|---------------------->| | | | | | | |<====Proxy Home Test (PHoT)=====|<----------------------| | | | Figure 2: Proxy Home Test Procedure 3.3. Concurrent Proxy Care-of Test Correspondent nodes also need to prove the reachability of care-of address. In this document, since the care-of test is initiated by proxy mobile agent instead of by mobile node, we call it as proxy care-of test procedure in order to differentiate the procedure from the definition in MIPv6 [2]. Qin, et al. Expires August 29, 2007 [Page 7] Internet-Draft PMIPv6 Route Optimization February 2007 Proxy care-of test is piggybacked on a proxy binding update which is sent by proxy mobile agent on behalf of the mobile node to register with a correspondent node. The care-of test is done concurrently with proxy binding update exchange, so we call it concurrent proxy care-of test. As shown in Figure 3, as a correspondent node receives a proxy binding update message, which contains care-of test init option, the CGA Parameters and Signature options, it returns a care-of keygen token in care-of test option piggybacked onto proxy binding acknowledgement (PBA) message. The mechanism is as described in [5]. After the first round trip of proxy binding update exchange is over between a correspondent node with proxy mobile agent, the correspondent node sets up a binding cache entry and may route packets directly to care-of address of the mobile node even though the care-of address is not verified. However, the proxy mobile agent obtains care-of keygen token via this round trip of proxy binding update exchange. The proxy mobile agent may initiate another proxy binding update exchange. Thus, the correspondent node may authenticate this proxy binding update with both temporary home keygen token and care-of keygen token, and then it makes sure that the proxy binding cache entry created by early proxy binding update exchange is legitimate. In order to protect against redirection- based flooding attacks, Credit-Based Authorization is also exploited, which is already introduced in [5]. If proxy mobile agent has only temporary home keygen token instead of permanent home keygen token, the proxy mobile agent calculates the Binding Authorization Data option field of early proxy binding update message with temporary home keygen token and care-of keygen token which is set to ZERO. Proxy mobile agent calculates CGA parameters and signature option according to MN's home address and private and public keys to be sent in a proxy binding update message to acquire permanent home keygen token and handover home keygen token. If proxy mobile agent has permanent home keygen token, proxy mobile agent calculates the Binding Authorization Data option field of early proxy binding update with permanent home keygen token and care-of keygen token which is set to ZERO. No CGA parameters and signature are required. If proxy mobile agent has only handover home keygen token, the proxy mobile agent calculates the Binding Authorization Data option field of early proxy binding update message with handover home keygen token and care-of keygen token which is set to ZERO. In order to renew permanent home keygen token and handover home keygen token, proxy mobile agent must include MN's CGA parameters and signature in this early proxy binding update. Qin, et al. Expires August 29, 2007 [Page 8] Internet-Draft PMIPv6 Route Optimization February 2007 Concurrent proxy care-of test procedure should proceed as soon as mobile node moves into the next PMA. To save handoff latency, concurrent proxy care-of test is piggybacked onto early proxy binding update exchange. As handoff occurs, the next proxy mobile agent calculates the Binding Authorization Data option for early proxy binding update based on handover home keygen token if the next proxy mobile agent has already obtained the handover home keygen token. The next proxy mobile agent and correspondent nodes can resume communication, while care-of address reachability verification proceeds concurrently. The amount of data, which the correspondent node is permitted to send to care-of address until reachability verification completes, is governed by Credit-Based Authorization. This mechanism conforms to [5]. Proxy Correspondent Mobile Agent Node | | | -------Early Proxy Binding Update------------>| | (care-of test init option) | | | | <------Proxy Binding Acknowledgement----------| | (care-of test option) | | | Figure 3: Concurrent Proxy Care-of Test 3.4. Handover Route optimization during handover is shown as Figure 4. If the previous proxy mobile agent forecasts the forthcoming handover of mobile node via layer 2 indication, such as link going down event in the Media-Independent Handover, the previous proxy mobile agent MAY transfer handover context to the next proxy mobile agent in advance. The handover home keygen token and other key parameters could help the next proxy mobile agent to pass the verification of home address required by correspondent nodes. The next proxy mobile agent MAY fetch the handover home keygen token through home agent via proxy binding update exchanges with the home agent of mobile node. After the mobile node left the previous proxy mobile agent, the previous proxy mobile agent deregisters the proxy binding cache entry with correspondent nodes. The correspondent node revokes permanent home keygen token. After the next proxy mobile agent obtains handover home keygen token, it sends out proxy binding update piggybacked by care-of test init option to correspondent nodes. As depicted in Figure 4, after the next proxy mobile agent obtains Qin, et al. Expires August 29, 2007 [Page 9] Internet-Draft PMIPv6 Route Optimization February 2007 the care-of keygen token via early proxy binding update and acknowledges messages, the binding cache entry is generated but unverified in the correspondent node. As soon as the complete proxy binding update message is received by the correspondent node, the binding cache entry could be verified. This proxy binding update contains CGA parameters and signature option with proxy mobile agent's public key and private key to request care-of keygen token. The correspondent node receives the proxy binding update and authenticates it with handover home keygen token and with CGA property. If the proxy binding update passes the verification, the correspondent node returns a care-of keygen token which is encrypted with the next proxy mobile agent's public key. The care-of keygen token is encrypted and sent over proxy binding acknowledgement message as a field. As soon as the next proxy mobile agent receives this proxy binding acknowledgement, it sends a complete proxy binding update message to the correspondent nodes. Binding Authorization Data option of the complete proxy binding update message is calculated using both care-of keygen token and handover home keygen token. Previous Next Correspondent Proxy mobile Agent Proxy mobile agent node | Handover context | | |----------------------->| | |(HoA,CN address,handover| | |home keygen token) | | handover \\ \\ | | Proxy binding update(lifetime = 0) | |------------------------------------------------------>| | Proxy binding Acknowledge (if sent) | |<------------------------------------------------------| | | Early Proxy Binding Update | | |----------------------------->| | | Proxy Binding Acknowledge | | |<-----------------------------| | | Complete Proxy Binding Update| | |----------------------------->| | |Proxy Binding Acknowledge | | |<-----------------------------| | |(new Permanent, | | |Handover home keygen token) | | | | Figure 4: Route Optimization during Handover Procedure Qin, et al. Expires August 29, 2007 [Page 10] Internet-Draft PMIPv6 Route Optimization February 2007 3.5. Complete Proxy Binding Update A complete proxy binding update is a proxy binding update defined in [4]. After proxy binding update which piggybacks care-of test exchanges is finished, a complete proxy binding update must be brought forward. The Binding Authorization Data option field of it is calculated by care-of keygen token for correspondent nodes to verify the reachability of care-of address and authenticate the legitimacy of the PMA which is sending this message on behalf of MN. The complete proxy binding update is exchanged as depicted in Figure 5. After proxy care-of test is processed, the complete proxy binding update exchange follows Figure 5. PBU message must be sent with CGA parameters and signature option for the proxy mobile agent to request permanent home keygen token and handover home keygen token from the correspondent node. A CGA provides a strong binding between its interface identifier and the CGA owner's public key. This enables other nodes to securely authenticate the CGA owner. Depending on the strong security brought up with Cryptographically generated home addresses, lifetime of binding is extended to a longer period more than 7 minutes [2]. Except for the initial test, the following home tests every 7 minutes are no longer needed. The correspondent node MUST authenticate the complete proxy binding update message based on the CGA property of the mobile node's home address. If the proxy mobile agent has only temporary home keygen token, and then the proxy mobile agent uses it to calculate the Binding Authorization Data option for the complete proxy Binding Update message. If the proxy mobile agent has permanent home keygen token, the proxy mobile agent uses it to calculate the Binding Authorization Data option. The home nonce index is set to ZERO. If the permanent home keygen token is required, both permanent home keygen token and handover home keygen token are generated and encrypted with the proxy mobile agent's public key. Both of the two tokens are transferred from correspondent node to the next proxy mobile node via the proxy binding acknowledgement response to the complete proxy binding update message. This new handover home keygen token will be exploited when the next handover occurs. The PBA MAY be protected by CGA property of correspondent nodes. If another proxy mobile agent is sending PBA on behalf of the correspondent node, that proxy mobile agent SHOULD use its own CGA property to protect PBA instead of the correspondent node's CGA property. Qin, et al. Expires August 29, 2007 [Page 11] Internet-Draft PMIPv6 Route Optimization February 2007 Proxy Correspondent Node Mobile Agent | Complete Proxy Binding Update | |--------------------------------------------->| | (CGA parameters, signature, home nonce index)| | | | | | Proxy Binding Acknowledgement | |<---------------------------------------------| |(Permanent home keygen token, | | Handover home keygen token) | | | | | Figure 5: Complete Proxy Binding Update 4. Route Optimization for Correspondent Nodes without Mobile IP This section describes route optimization procedure for correspondent nodes which are not Mobile IP enabled. Trigerring and scenario analysis are made. Two kinds of solutions are proposed: one without return routability and the other with return routability. 4.1. Triggering and Scenario Analysis Route optimization in Mobile IPv6 is an end-to-end operation. Once mobile node and correspondent node complete the route optimization procedure, all of communications between them will be optimized. In Proxy Mobile IP, however, proxy mobile agent is not the communication end but an intermediary router. Generally proxy mobile agent may not be able to judge whether the packets need to be optimized or not. So, it MAY be necessary to define a mechanism that allows mobile node to inform the proxy mobile agent of its route optimization requirement about its communication with the specific correspondent node, or just let PMA to optimize all of the communications between mobile node and other nodes. A flag could be defined to identify two route optimization trigger modes: implicit mode that means that it's up to proxy mobile agent to decide and perform route optimization for mobile node, or explicit mode that means mobile node MUST send a message to trigger proxy mobile agent to perform route optimization for mobile node. The flag of route optimization trigger mode can also be configured in a policy store, such as in AAA infrastructure. After successful access authentication and authorization, proxy mobile agent gets this flag as part of the user profile from AAA infrastructure. On this point route optimization can be considered as a kind of service that Qin, et al. Expires August 29, 2007 [Page 12] Internet-Draft PMIPv6 Route Optimization February 2007 network provides to mobile users. Assuming that both mobile node and correspondent node are using Proxy Mobile IPv6, there are four possible scenarios/cases due to the different location of correspondent node: mobile node and correspondent node attach to the same proxy mobile agent and they belong to the same home agent (case 1), mobile node and correspondent node attach to the same proxy mobile agent but they belong to different home agents (case 2), mobile node and correspondent node attach to different proxy mobile agents, but they have the same home agent (case 3), mobile node and correspondent node attach to different proxy mobile agents, and they have different home agents (case 4). Cases 1 and 2 do not require any signaling between PMAs and packets can be locally routed. As mobile node and correspondent node both attach to the same PMA and this PMA performs registration process on behalf of them and maintains Binding Update List for them. When PMA receives the packets from mobile node or correspondent node, proxy mobile agent SHOULD look up the Binding Update List to check whether or not the destination IP address in the IP packet appears in the Binding Update List as home address. If yes, it means proxy mobile agent has registered with home agent on behalf of destination node and proxy mobile agent SHOULD directly forward the packet on the connected interface instead of sending the packet to the home agent through the bi-directional tunnel. In cases 3 and 4, mobile node and correspondent node attach to different PMAs, the ideal data path is to directly go through these two PMAs to which mobile node and correspondent node attach. A bi- directional tunnel needs to be established between these two proxy mobile agents for route optimization. Proxy mobile agent needs to know IP address of the corresponding PMA to which correspondent node attaches so that it can initiate the route optimization signaling process. HA of CN knows it because IP address of corresponding PMA has been registered with the home agent as the care-of address of CN. Proxy mobile agent can send a request to the home agent of CN and ask for the Binding Cache Entry for the correspondent node if it knows the IP address of that home agent. Another method of obtaining PMAs' addresses is by exchanging them in home test messages during return routability signaling. Modified PHoTI and PHoT messages can be used for this purpose. In Section 4.2 we present a route optimization technique based on obtaining IP address of the corresponding PMA from the home agent and in Section 4.3 based on return routability procedure. Qin, et al. Expires August 29, 2007 [Page 13] Internet-Draft PMIPv6 Route Optimization February 2007 4.2. Route Optimization without Return Routability A possible route optimization process is illustrated in Figure 6, where PMA1 performs route optimization process for communication between MN1 and CN4 whose corresponding PMA is PMA3 and HA is HA2. After getting home agent address of CN4, PMA1 first sends the request with home address of CN4 to HA2 to inquire the IP address of PMA3. HA2 looks up the Binding Cache and responds with the care-of address of CN4. PMA1 sends Proxy Binding Update to PMA3 to register the home address of MN1 and IP address of PMA1 as care-of address with PMA3. PMA3 stores this information in the Binding Cache entry for the MN1 and responds with another Proxy Binding Update sent to PMA1 which interprets it as an acknowledgement as well. PMA1 sends Proxy Binding Acknowledgement to PMA3 to confirm the registration request. After this three-way handshake procedure, Binding Cache Entries for MN1 and CN4 have been created in PMA3 and PMA1 respectively. The packets between MN1 and CN4 can go through the bi-directional tunnel between PMA1 and PMA3 to reach each other. PMA1 HA2 PMA3 | | | | Binding Cache Request/Ack | | |<---------------------------->| | | | | | | | Proxy Binding Update | |----------------------------------------->| | Proxy Binding Update | |<-----------------------------------------| | Proxy Binding Acknowledgement | |----------------------------------------->| | | Figure 6: 3-way Handshake 4.2.1. Tunnel Re-establishment During the Handover Suppose a bi-directional tunnel has been established for route optimization in case 4, handover happens when MN1 moves from PMA1 to PMA2 and PMA2 registers with HA1 on behalf of MN1 after performing access authentication Figure 7. After the handover, PMA3 MUST be informed of the mobility of MN1, or the packets from CN4 to MN1 will still be sent to PMA1 because the Binding Cache Entry for MN1 hasn't been updated in PMA3. In fact, the one end of tunnel has changed from PMA1 to PMA2 due to handover, and the tunnel MUST be re- Qin, et al. Expires August 29, 2007 [Page 14] Internet-Draft PMIPv6 Route Optimization February 2007 established for route optimization. +-----+ +-----+ | HA1 |~~~~~~~~~~~~~~~~~| HA2 | /+-----+\\ +-----+\\ // \\ \\ // \\ \\ // \\ \\ // \\ \\ // \\ \\ +----+ +----+ +----+ |PMA2|~~~~~~~~~~~~~~~~~~|PMA1|~~~~~~~~~~~~~~~|PMA3| +--+-+ +-+--+ +-+--+ | | | | | | -----+---- ----+------- ---+--+-- | +-----+ +--+--+ <-----| MN1 | | CN4 | +-----+ +-----+ Figure 7: Handover Scenario The context transfer of Binding Update List entry for mobile node can trigger the new proxy mobile agent to re-establish the tunnel for route optimization so that route optimized communication can continue after handover. An example for route optimization signaling flow during handover is depicted in Figure 8. Here, the handover is controlled by network in a reactive mode, where new proxy mobile agent (PMA2) sends Context Transfer Request message to old proxy mobile agent (PMA1) and PMA1 responds with Context Transfer Data message which carries user profiles and Binding Update List entries for MN1. PMA2 SHOULD send Proxy Binding Update message to corresponding proxy mobile agent (PMA3 here) according to each Binding Update List entry. The following flow is the same as all that described in Section 4.2 Qin, et al. Expires August 29, 2007 [Page 15] Internet-Draft PMIPv6 Route Optimization February 2007 PMA1 PMA2 PMA3 | | | | Context Transfer Request | | |<---------------------------| | | | | | Context Transfer Data | | |--------------------------->| | | | | | Proxy Binding Update | |-------------------------------->| | Proxy Binding Update | |<--------------------------------| | Proxy Binding Acknowledgement | |-------------------------------->| | | Figure 8: RO in Handover 4.3. Route Optimization with Return Routability If a proxy mobile agent provides mobility service for correspondent nodes, PMIPv6 Route Optimization protocol could be used for such correspondent nodes, as long as the proxy mobile agent intercepts and processes route optimization extensions via looking over the MH types and distinguishing Proxy Mobile IP signaling from data. The process is shown in Figure 9. The proxy home test init message is transmitted over the shared tunnel between proxy mobile agent of mobile node and home agent of mobile node. This proxy home test init message is forwarded to home address of the correspondent node by HA. At the home agent of the correspondent node, this message is tunnelled into the shared tunnel between the home agent of correspondent node and the proxy mobile agent of the correspondent node. The proxy mobile agent of CN intercepts proxy home test init message and extracts MN's home address and care-of address from PHoTI. PMA of CN sends a proxy home test message back to PMA of MN and adds care-of address of CN into PHoT message. PMA of CN creates a Binding Cache entry for this MN. PHoT is transmitted over the shared tunnel between PMA of CN and HA of CN. HA of CN forwards this message to the home address of MN which tunnels it to PMA of MN. PMA of MN receives PHoT message, it extracts the care-of address of CN and adds this information to the Binding Cache entry for CN. PMA of CN next starts care-of test signaling by sending an early binding update message directly to the care-of address of CN, i.e. to PMA of CN. Qin, et al. Expires August 29, 2007 [Page 16] Internet-Draft PMIPv6 Route Optimization February 2007 Due to the address exchange using PHoTI and PHoT messages, care-of test signaling in Figure 9 MUST NOT be started in parallel to home test signaling. Proxy Home Agent(MN) Home Agent(CN) Proxy Mobile Agent(MN) Mobile Agent(CN) | Proxy HoTI | | | |===============>|-------------->|===============>| | Proxy HoT | | | |<===============|<--------------|<===============| | Early Proxy Binding Update | | |------------------------------------------------>| | Proxy Binding Acknowledgement| | |<------------------------------------------------| | Complete Proxy Binding Update| | |------------------------------------------------>| | Proxy Binding Acknowledgement| | |<------------------------------------------------| | | | Figure 9: Route Optimization for Correspondent nodes without mobile ip 5. Home Agent Considerations The home agent MUST drop all HoTI messages received from a home address that has corresponding Binding Cache entry with the proxy registration flag set. The home agent MUST forward all Proxy HoTI messages received from a home address that has corresponding Binding Cache entry with the proxy registration flag set. 6. Proxy Mobile Agent Considerations PMA, after successful Home and Care-of Test exchanges, creates a Binding Cache entry for the correspondent node or PMA of the correspondent node. For each mobile node, the Binding Cache contains one entry for each correspondent node. After handover, PMA deletes the Binding Cache entry and deregisters MN with all its correspondent nodes. PMA MUST maintain a Binding Update List for each MN. The fields are as defined in [2] and with extensions defined in [4]. For each MN for which route optimization service is offered, the list in addition MUST contain the private and public keys of MN. Apart from home registrations as in [4], Binding Update List contains correspondent registrations for route optimization. Qin, et al. Expires August 29, 2007 [Page 17] Internet-Draft PMIPv6 Route Optimization February 2007 After handover, correspondent registration entries in the Binding Update List SHOULD be transferred to the next PMA. Such a transfer provides continuity of correspondent registrations for route optimization. The next PMA refreshes such registrations only after lifetime expiry. PMA MUST maintain a Binding Cache if it has Type 2 CNs. Binding cache entries are created when PMA receives a home test init message. This Binding Cache is called Proxy Binding Cache. From the correspondent nodes PMA receives data packets with Type 2 routing header. Type 2 routing header MUST conform to the structure given in Section 6.1.5 of [2]. PMA MUST process the packet as follows: PMA replaces the source address with the home address given in Type 2 routing header. PMA removes Type 2 routing header. PMA sends the packet to MN. PMA MUST not include IPv4 home address option [6] in proxy binding updates sent for route optimization. PMIPv6 route optimization for dual-stack nodes is TBD. 7. Correspondent Node Considerations This section state the differences in the behaviour of a correspondent node that conforms to Section 9 of [2]. Upon receiving a Proxy Home Test Init message, Early Proxy Binding Update and Complete Proxy Binding Update message, the correspondent node verifies the following: The packet MUST NOT include a Home Address destination option. The correspondent node MUST silently ignore such packets. After a successful Home and Care-of Test exchanges, the correspondent node creates a Binding Cache entry for the proxy mobile agent proxying the mobile node. The entry MUST be deleted after the expiration of its lifetime or after receiving a proxy binding update message which deregisters the mobile node. Correspondent node MUST receive route optimized data packets from PMA encapsulated in IP-in-IP encapsulation. Source address of the outer header MUST be equal PMA's egress interface address and MUST match the Binding Cache entry. CN MUST remove the outer header before passing the packet to the upper layers. CN MUST use Type 2 routing header in outgoing packets to PMA. The destination address is PMA's egress interface address which serves as Care-of address for the mobile node and the type 2 routing header Qin, et al. Expires August 29, 2007 [Page 18] Internet-Draft PMIPv6 Route Optimization February 2007 contains MN's home address. 8. Message Formats This section defines extensions to the Proxy Mobile IPv6 [4] protocol messages and the enhanced route optimization in MIPv6 protocol messages [5]. 8.1. Proxy Home Test +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy Home Test A new MH type should be assigned by IANA. Home Keygen Token This field contains the 64 bit temporary home keygen token used to authenticate the proxy binding update. Care-of Address This field contains the care-of address assigned to the CN by PMA. For descriptions of other fields present in this message, refer to section 6.1.5 in [2]. Qin, et al. Expires August 29, 2007 [Page 19] Internet-Draft PMIPv6 Route Optimization February 2007 8.2. Proxy Home Test Init Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy Home Test Init A new MH type should be assigned by IANA. Care-of Address This field contains the care-of address assigned to the mobile node by PMA. For descriptions of other fields present in this message, refer to section 6.1.5 in [2]. 8.3. Handover Home Keygen Token option Handover home keygen token is a mobility option. It is sent by CN in proxy binding acknowledgement message. Qin, et al. Expires August 29, 2007 [Page 20] Internet-Draft PMIPv6 Route Optimization February 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : Handover Home Keygen Token : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Handover Home Keygen Token option Option Type 8-bit identifier of the type of this mobility option. Its value is TBD. Option Length 8-bit unsigned integer representing the length of the Handover Home Keygen Token field in octets. Handover Home Keygen Token This field contains the Handover home keygen token generated by the correspondent node. The content of this field MUST be encrypted with the proxy mobile agent's public key. The length of the handover home keygen token is 8 octets before encryption. After it is encrypted, this field may be longer than 8 octets. 9. Security Considerations Security mechanism is very important in the route optimization process, especially for the proposal of establishing the tunnel between two proxy mobile agents. In the case of route optimization without return routability, if proxy mobile agent does not authenticate Proxy Binding Update and Proxy Binding Acknowledge messages, a malicious node may send such signaling messages to proxy mobile agents to get the data packets destined for other nodes directed to itself. In addition, when proxy mobile agent sends data packets through the bi-directional tunnel between two proxy mobile agents, corresponding PMA SHOULD examine the data packets to make sure there is a Binding Cache entry for the data source terminal. Route optimization signaling between PMA of MN and CN specified in this document is based on [5] and use return routability with better security properties than the return routability of the base protocol Qin, et al. Expires August 29, 2007 [Page 21] Internet-Draft PMIPv6 Route Optimization February 2007 [2]. Return routability signaling between two PMAs specified in this document is also based on [5] and has better security properties. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [4] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-01 (work in progress), January 2007. [5] Arkko, J., "Enhanced Route Optimization for Mobile IPv6", draft-ietf-mipshop-cga-cba-03 (work in progress), February 2007. 10.2. Informative references [6] Soliman, H., "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03 (work in progress), October 2006. Authors' Addresses Alice Qin Huawei Technologies No.91 BaiXia Rd. Nanjing, Jiangsu 210001 China Email: Alice.Q@huawei.com Qin, et al. Expires August 29, 2007 [Page 22] Internet-Draft PMIPv6 Route Optimization February 2007 Andy Huang Huawei Technologies No.91 BaiXia Rd. Nanjing, Jiangsu 210001 China Phone: +86-25-84565457 Email: hpanda@huawei.com Wenson Wu Huawei Technologies No.91 BaiXia Rd. Nanjing, Jiangsu 210001 China Phone: +86-25-84565459 Email: sunseawq@huawei.com Behcet Sarikaya Huawei Technologies 1700 Alma Dr. Suite 100 Plano, TX 75075 Email: sarikaya@ieee.org Qin, et al. Expires August 29, 2007 [Page 23] Internet-Draft PMIPv6 Route Optimization February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Qin, et al. Expires August 29, 2007 [Page 24]