Mobile IP Working Group H.Ohnishi INTERNET DRAFT Y.Takagi Expires: December 2001 NTT Corporation July 2001 Mobile IP Border Gateway (MBG) Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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. 1.Abstract This draft introduces the use of Mobile IP border gateways (MBGs) to optimize the Mobile IP packet routing from a correspondent node (CN) to a mobile node (MN) without adding more functions to the CN nodes. 2.Introduction The current Mobile IP specification[2] forces all packets forwarded to a mobile node (MN) to be routed via that MN's Home Agent (HA), which often leads to triangular routing, which in turn causes data transmission delay and wastes network resources. Internet-draft "Route optimization in Mobile IP"[3] shows a solution that can optimize the route length, but this solution requires the Ohnishi, Takagi [Page 1] Internet Draft MBG (Mobile IP Border Gateway) July 2001 implementation of additional functions to CN, e.g. managing the binding cache and IP encapsulation, on all correspondent nodes, such as thousands of WWW servers in the Internet, so it is not easy to achieve route optimization by this method. If route optimization is to be achieved between CNs and MNs, the above method is necessary. But ISPs that are going to provide Mobile IP service may want to optimize routes only inside the networks in order to provide the service without the need to alter and maintain correspondent host software. This will significantly reduce the administrative costs of deploying route optimization. In that case, it can be achieved by network elements possessed by ISPs. This draft introduces the use of Mobile IP border gateways (MBGs) that are under ISP's control and can provide route optimization without adding more functions to CNs. MBGs are border gateways that have functions of Mobile IP. MBGs can request the mobile node's care-of address from HAs on behalf of correspondent nodes and create the binding cache. As the MBG maintains the binding cache, successive packets destined to a MN are forwarded directly to the mobile node's care-of address. MBGs are located at the border of ISPs that provide Mobile IP service and have information about HA addresses associated with specific prefix ranges of MN's address. MGBs also have the associated shared keys with these HAs for security associations. MBGs do not have all the information of HAs in the Internet but HAs that are located as follows, - HAs located inside the ISP(s) that have such mobile routing agreements. In this case ISPs are acting as home networks for users. MBGs and HAs are possessed by these same ISPs. MBGs have security associations with HAs and know the HA's address and MN's address(es) which belong to these HAs. - HAs located in intranets which are directly connected to the ISPs In this case intranets are acting as home networks for users but HAs are registered to ISPs. MBGs have security associations with HAs and know the HA's address and MN's address(es) which belongs to these HAs. To achieve route optimization for MNs that are not pre-configured to MBGs, e.g. HAs in SOHO, a way described in "Intercepting Location Updates"[4] can be applied. In this case, HAs must support sending Ohnishi, Takagi [Page 2] Internet Draft MBG (Mobile IP Border Gateway) July 2001 binding message with Router Alert Option and MBGs must support intercepting binding message with Router Alert Option. This is an engineering choice whether to support this method or not. This MBG method has the following features. - does not necessitate all nodes to implement these functions Usually IP networks have few border gateway routers, so the number of MBGs that need to have these specific functions can be limited. In addition, most MNs communicate with WWW servers in other networks more frequently, so it is very effective to optimize the downstream packets arriving from the other networks. - uses same messages specified in "Route optimization in Mobile IP"[3] This method uses same messages specified in "Route optimization in Mobile IP"[3] and does not need to define other messages. - can be used with the "Route optimization in Mobile IP" This method can be used with the "Route optimization in Mobile IP". MNs do not need to have more functions for this method. - can optimize the route in the network surrounded by MBGs regardless of CN's functionality - can easily maintain security associations between MBGs and HAs 3.Terminology Binding Request message receiving list A list of MBG addresses, maintained by HA to keep MBGs that sent Binding Request messages to HA. The list contains MBG addresses, mobile node's addresses and associated lifetimes. Binding Request message sending list A list maintained by MBG to keep HA addresses to which the MBG sent Binding Request messages. The list contains HA addresses, mobile node addresses and associated lifetimes. Ohnishi, Takagi [Page 3] Internet Draft MBG (Mobile IP Border Gateway) July 2001 Binding Update message sending list A list maintained by HA to keep MBG addresses to which HA sends Binding Update messages. The list contains MBG addresses, mobile node's addresses, associated lifetimes and flags to confirm the acknowledgements from MBGs. 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 RFC 2119 [1]. 4.Overview MBG is located between an IP network and a Mobile IP network (see Figure 1). When MBG receives the packets from the other IP network, it searches for the destination IP address associated with registered IP addresses of MNs. If the destination IP address does not match any registered MN's IP address, MBG forward the packet as ordinary IP routing. If the destination address matches the registered MN's IP address, MBG searches for the MN's binding cache. If a binding cache is not found, MBG sends a Binding Request message to HA. After receiving the request form MBG, HA judges whether to send a Binding Update message to MBG. If HA decides to teach the care-of-address of MN, it sends the Binding Update message to MBG. Upon receiving the Binding Update message from HA, MBG makes the binding cache for the MN and successive packets for the MN are forwarded to the care-of address by tunneling mechanism. Upon receiving the registration request whose care-of address is different from the ones in the current binding list, HA sends a Binding Update message to MBG that are performing route optimization. After receiving the Binding Update, the MBG update a binding cache without updating the lifetime in the binding cache. The MBG forwards the packets to the new care-of address. +--------+ | | | CN | | | +--------+ / | | ... ... ... | +-----------------+ | | | IP network | Ohnishi, Takagi [Page 4] Internet Draft MBG (Mobile IP Border Gateway) July 2001 | | +-----------------+ / | | ... ... ... | +--------+ | | | MBG | | | +--------+ / | +--------+ +--------+ | | | | | HA2 | | HA1 | | | | | +--------+ +--------+ | | | +--------+ ... | | | FA | | | +--------+ | | | +--------+ ... | | | MN | | | +--------+ Figure 1: Domain with a MBG 5. Scope of solution This method can be applied to an ISP network that can achieve route optimization in itself. MBGs can achieve route optimization for MNs that are previously registered to MBGs. MBGs are located at border between an ISP and other IP networks and possessed by the ISP. The ISP must recognize MBGs and HAs that will provide functions of route optimization for MNs. MBGs and HAs must know of each other. How to establish security association between MBGs and HAs depends on the location of HAs, - HAs located inside the ISPs ISPs are acting as home networks for users. MBGs and HAs are possessed by these same ISPs. ISPs establish security associations between MBGs and HAs. MBGs have information about HA addresses Ohnishi, Takagi [Page 5] Internet Draft MBG (Mobile IP Border Gateway) July 2001 associated with specific prefix range of MN's address. - HAs located in intranets which directly connected to the ISPs Intranets are acting as home networks for users. HAs may be possessed by users or ISPs. If HAs are provided by users, HAs must be registered to ISPs for route optimization. ISPs establish security associations between MBGs and HAs. MBGs have information about HA addresses associated with specific prefix range of MN's address. - HAs located in other networks If there are any agreements between different IP networks, MBGs can have security associations with HAs in other IP networks. To achieve route optimization for MNs that are not pre-configured to MBGs, e.g. HAs in SOHO, a way described in "Intercepting Location Updates"[4] can be applied. In this case, HAs must support sending binding message with Router Alert Option and MBGs must support intercepting binding message with Router Alert Option. This is an engineering choice whether to support this method or not. 6.message format "Route optimization in Mobile IP"[3] defines four message types used for management of binding cache entries. This draft uses same messages for management of binding cache entries for MBG. 16 Binding Warning message 17 Binding Request message 18 Binding Update message 19 Binding Acknowledge message 6.1 Binding Warning message Binding Warning message is used for the same purpose specified in "Route optimization in Mobile IP"[3]. After receiving Binding Warning message, HA send Binding Update message to Target Node. 6.2 Binding Request message Binding Request message is used for MBG to request a MN's current mobility binding associated with the mobile node's HA. 6.3 Binding Update message Ohnishi, Takagi [Page 6] Internet Draft MBG (Mobile IP Border Gateway) July 2001 This message is used for HA to notify MBG of MN' current mobility binding. After HA makes a judgment to notify MBG of a mobility binding, this message is sent to the corresponding MBG in reference to Binding Request message receiving list. HA keeps the MBG addresses in Binding Update message sending list. Upon receiving the registration request whose care-of address is different from the one in the binding list that has already exist, if the Binding Update message sending list for the MN exists and flag is set, HA sends the Binding Update message to the MBG to support the movement of MN. 6.4 Binding Acknowledge message When an MBG receives a Binding Update message from HA, this message is sent to the HA by the MBG for confirmation. 7. MBG Route Optimization Authentication Extension The MBG Route Optimization Authentication extension is used to authenticate Route Optimization management messages sent with an SPI corresponding to the source IP address of the message. This extension is subtype TBD of the Generalized Authentication Extension [5]. The authenticator value is computed, as before, from the stream of bytes including the shared secret, the UDP payload (that is, the Route Optimization management message), all prior extensions in their entirety, and the type, subtype, length, and SPI of this extension, but not including the authenticator field itself nor the UDP header. This extension is required to be used in any Binding Update message sent by the HA. 8. Miscellaneous Home Agent Operations 8.1 HA configuration HA shares keys with MBGs that have information about the HA address associated with specific prefix range of MN's address. 8.2 Receiving Binding Request messages If mobile nodes are in the home network, HA does not send the Binding Update message to MBG. If mobile nodes are not in the home network, HA send the Binding Update message to MBG according to the condition and create Binding Update message sending list. In order to know which MBGs correctly received the Binding Updates, HA SHOULD set the 'A' bit in the Binding Update, requesting an acknowledgement. Upon receiving the Binding Acknowledge from the MBG, HA sets the flag in the Binding Update message sending list. The examples of conditions Ohnishi, Takagi [Page 7] Internet Draft MBG (Mobile IP Border Gateway) July 2001 are as follows. - The number of received packets in a fixed period - Sort of application - User profile 1) Route optimization judged by number of packets in a fixed period HA sends the Binding Update message to MBG when the number of packets exceeded threshold in fixed period. 2) Route optimization judged by application types The HA sends Binding Update message to the MBG only for the application which is supposed to use large traffic, such as FTP. 3) Route optimization judged by user profile types Users which route optimization are applied to, in addition to "P" bit which is established at the time of registration, can be previously set up at network side. It is possible to apply route optimization only for those users above. These judgments can be combined. It is also possible to perform route optimization only for the connection that exceeds a threshold out of the permitted users. 8.3 Receiving the registration in route optimization Upon receiving the registration request whose care-of address is different from the one in the binding list that has already exist, if the Binding Update message sending list for the MN exists and flag is set, the HA sends the Binding Update message to the MBG to support the movement of MN. 8.4 Receiving Binding Warning messages Receiving a Binding Warning message, HA send Binding Update messages to Target Node. 8.5 Receiving Binding Acknowledge messages Receiving a Binding Acknowledge message, HA set the flag in the Binding Update message sending list. Ohnishi, Takagi [Page 8] Internet Draft MBG (Mobile IP Border Gateway) July 2001 8.6 Sending update messages with the Router Alert Option To achieve route optimization for MNs that are not pre-configured to MBGs, a way described in "Intercepting Location Updates"[4] can be applied. In this case, HAs must send update message with the Router Alert Option. This is an engineering choice whether to support this method or not. 9. Miscellaneous MBG Operations 9.1 MBG configuration MBG is configured with IP addresses of HAs to recognize HAs that MBGs send the Binding Request messages. And MBG is also configured with IP addresses of MNs that belong to the HAs to find packets that are destined to MNs. HAs that MBG have information about are as follows, - HAs located inside the ISPs ISPs are acting as home networks for users. MBGs and HAs are possessed by these same ISPs. ISPs establish security associations between MBGs and HAs. MBGs have information about HA addresses associated with specific prefix range of MN's address. - HAs located in intranets which directly connected to the ISPs Intranets are acting as home networks for users. HAs may be possessed by users or ISPs. If HAs are provided by users, the HAs must be registered to ISPs for route optimization. ISPs establish security associations between MBGs and HAs. MBGs have information about HA addresses associated with specific prefix range of MN's address. - HAs located in other networks If there are any agreements between different IP networks, MBGs can have security associations with HAs in other IP networks. To achieve route optimization for MNs that are not pre-configured to MBGs, e.g. HAs in SOHO, a way described in "Intercepting Location Updates"[4] can be applied. In this case, HAs must support sending binding message with Router Alert Option and MBGs must support intercepting binding message with Router Alert Option. This is an engineering choice whether to support this method or not. 9.2 Receiving packets Ohnishi, Takagi [Page 9] Internet Draft MBG (Mobile IP Border Gateway) July 2001 MBG searches for destination IP address associated with the registered IP addresses of MNs. If the destination address does not match any registered MN's IP address, MBG forward the packet as ordinary IP routing. If the destination address matches the registered MN's IP addresses, MBG searches for appropriate binding cache. If binding cache is found, MBG forward to the care-of address for the MN. If binding cache is not found, the procedure of 9.3 will be applied. 9.3 Sending Binding Request messages to HA MBG sends a Binding Request message to the HA and keeps the HA address, MN'address in Binding Request message sending list. Each Binding Request message sending list has an associated lifetime. Before the expiration of this time period, the MBG does not send the Binding Request message for the MN. After the expiration of this time period, MBG sends Binding Request message when MBG receives packets to the MN. 9.4 Binding Update message received from HA Upon receiving Binding Update from HA, the following procedures shall apply. 1) The lifetime is not 0: In the absence of any binding cache entry, the MBG creates a binding cache entry. In the presence of binding cache entry, the MBG updates a binding cache without updating the lifetime in the binding cache. After receiving the Binding Update, the MBG sends the Binding Acknowledgement to the HA. 2) The lifetime is 0: The MBG deletes the Binding cache. 9.5 Managing the binding list MBG maintains the binding list for lifetime. After the lifetime expired, the binding cache is deleted and packets destined to the MN is forwarded through the HA. Upon receiving the next Binding Update, MBG creates the binding cache and forward the packets for the MN directly to the MN's care-of address. 9.6 Intercepting update message with the Router Alert Option Ohnishi, Takagi [Page 10] Internet Draft MBG (Mobile IP Border Gateway) July 2001 To achieve route optimization for MNs that are not pre-configured to MBGs, a way described in "Intercepting Location Updates"[4] is applied. In this case, MBG must intercept update message with the Router Alert Option like Correspondent Agent described in "Intercepting Location Updates"[4]. This is an engineering choice whether to support this function or not. 10. Using MBG together with "Route optimization in Mobile IP"[3] This sections shows route optimization using this draft together with "Route optimization in Mobile IP"[3]. 10.1 Communication between terminals in the Mobile IP network If both terminals have Mobile IP functions, "Route optimization in Mobile IP"[3] method is applied. 10.2 Communication between terminals in the different IP networks If HA sends a Binding Update message immediately after receiving the packet to an MN without receiving Binding Request message from MBG, the HA sends the Binding Update message to a CN. In this case, "Route optimization in Mobile IP"[3] is applied if the CN has Mobile IP functions. If the CN does not have Mobile IP functions, route optimization is achieved by MBG. 11. IPv6 Consideration MBGv6 also achieves route optimization without adding more functions to CNs. The procedure of MBGv6 is as same as that of MBGv4. This draft can be applied to the MBGv6 with some modifications as follows: -Binding Warning option is used in Mobile IPv6[6] as Binding Warning message in MIPv4. -Binding Request option is used in Mobile IPv6 as Binding Request message in MIPv4. -Binding Update option is used in Mobile IPv6 as Binding Update message in MIPv4. -Binding Acknowledge option is used in Mobile IPv6 as Binding Acknowledge message in MIPv4. Although MN may send Binding Update option to MBGv6 because Binding Update option is always sent by MN, we propose that HA should send Ohnishi, Takagi [Page 11] Internet Draft MBG (Mobile IP Border Gateway) July 2001 Binding Update option to MBGv6. Because it is not desirable that MN should identify MBG. The MBGv6 cannot use a Routing header to forward these intercepted packets to the mobile node, since it cannot modify the packet in flight without invalidating any existing IPv6 AH [7] or ESP [8] header present in the packet. 12. Security Consideration The calculation of the authentication data supplied with the Route Optimization messages is specified to be the same as in the base Mobile IP document for ease of implementation. There is a better method available (HMAC), specified in RFC 2104 [9]. If the base Mobile IP specification is updated to use HMAC, then this specification SHOULD also be updated similarly. 13. 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, Editor. IP Mobility Support version 2 (work in progress). draft-ietf-mobileip-rfc2002-bis-03.txt, September 2000. [3] Charles Perkins and David B. Johnson. Route Optimization in Mobile IP. draft-ietf-mobileip-optim-10.txt, November 2000. [4] C-Y Lee, G. Morrow and F. Kadri, Intercepting Location Updates. draft-lmk-mobileip-intercepting-update-01.txt, November 2000 [5] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension, December 2000. [6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-10.txt, February 2000. [7] Stephen Kent and Randall Atkinson. IP Authentication Header. RFC 2402, November 1998. [8] Stephen Kent and Randall Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, November 1998. [9] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, Ohnishi, Takagi [Page 12] Internet Draft MBG (Mobile IP Border Gateway) July 2001 February 1997. Author's Address Hiroyuki Ohnishi NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4132 EMail: ohnishi.hiroyuki@lab.ntt.co.jp Yasushi Takagi NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6059 EMail: takagi.yasushi@lab.ntt.co.jp Ohnishi, Takagi [Page 13]