MIP6 Working Group SeungSun Hong Internet Draft Fan Zhao Expires: January 12, 2005 S. Felix, Wu UC Davis Souhwan Jung Soongsil Univ. HyunGon Kim ETRI July 12, 2004 UC Davis Multihoming Scenarios with Multiple Home Agents in Mobile IPv6 draft-hong-mip6-multihoming-scenarios-00.txt Status of this Memo 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. This Internet-Draft will expire on January, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the multihoming issues in Mobile IP networks. It specifies the basic multihoming scenario, a mobile node is multihomed to multiple home agents within an AS, then describes the multihoming method for this basic scenario. The principle of the multihoming method in this document is that multiple home agents share security associations established between a mobile node and a home agent. By sharing security associations among home agents who serve the same home link, we can reduce the burden of MN to manage the HA list. This document points out technical issues related to sharing security associations among home agents and specifies possible solutions for them. Also, this document describes how to extend the basic multihoming method to more complicated multihoming cases such as multiple home agents in different AS. S. Hong, et al Expires January 2005 [Page 1] Internet-Draft Multihoming scenario in mipv6 12 July 2004 1. Introduction 1.1 Motivations Multihoming, using multiple connectivities to multiple ISPs simultaneously, provides more reliable and robust network connectivity to customer networks by supporting fault-tolerance, load-sharing. However, supporting multihoming in Mobile IP is more complicated matter because there are invariably many multihoming scenarios in Mobile IP. Wakikawa, et al [5] proposed the HAHA protocol which includes multiple home agents activation scenario. In HAHA protocol, the MN must keep track of the home agents who have its binding information to verify the source address of tunneled packets. In addition, MN must establish an independent SA with each HA to receive to tunneled packets from multiple home agents, which increases the burden of MN to manage security association (SA) database. This document describes several multihoming scenarios in Mobile IP. These scenarios considers the same situation as the multiple Home Agents (HA) activation scenario in HAHA protocol, but they have different assumptions from those in the HAHA protocol. The multihoming scenarios in this document only considers the case that MN only has one HA address, so MN feels like it is communicating with a single HA. Another difference from the HAHA protocol, the MN only maintains one SA for multiple HAs by allowing multiple HAs to share SAs established between the primary HA and the MN. This document describes these multihoming scenarios and specifies technical issues in supporting these multihoming scenarios. In addition, the document provides possible solutions for technical problems in supporting multi-homed MN in Mobile IP network. 1.2 Assumptions Designing a comprehensive multihoming architecture for various multihoming scenarios is important, however, it is a difficult task to achieve because of its complexity. In this section, we make a few assumptions to limit the scope of the multihoming scenario and reduce the complexity of new multihoming architecture in the given scenario. Removing these assumptions does not mean that the architecture would fail to support mobility for multihomed MNs. It simply requires replacing each assumptions with a specific scheme which has the same functionalities as the following assumptions. (Assumption 1) MN accesses multiple HAs using a single IP addresses: The simplest way to remove this assumption is providing the HA list to MN. That is, if MN has knowledge about IP addresses of HAs, it can select its preferred HA based on the list. However, this solution is not transparent to MN because it requires an extra function to manage the HA list. This assumption is applicable across the document unless we specify a different assumption. S. Hong, et al Expires January 2005 [Page 2] Internet-Draft Multihoming scenario in mipv6 12 July 2004 (Assumption 2) MN has only one active CoA at a time: Whenever MN visits new network, it receives new COA. Thus, it is possible for MN to have multiple CoAs. There are many scenarios that may lead to multiple CoAs for MN, as described in [1]. This document assumes one active CoA for MN because it is more common case in Mobile IP network. (Assumption 3) There exist trust relations among HAs: Since this document supports multiple HAs, it requires inter-HA communications. Without a certain level of trust relations among HAs, the new multihoming architecture can easily be compromised. This document provide a inter-HA protocol, the extension of the HAHA protocol, to provide the trust relations among HAs. 2. Basic multihoming scenario - multiple HAs within a single AS The purpose of composing a basic scenario is to decide the scope of basic multihoming architecture and to specify how this basic architecture does support multi-homed MNs. The basic scenario considers the case that MN is multihomed to multiple HAs in different home links within a single AS. The fundamental differences of this basic scenario from the HAHA protocol are: (1) multiple HAs are accessable using one HA address, (2) multiple HAs share security associations established between MN and the primary HA. The goal of this multihoming configuration is to provide HA redundancy for MN. AS 001 (192.168.1.0/24) +-----------------------------------+ | +------+ +------+ | | | HA 2 |============| HA 3 | | | +------+ +------+ | | + = = + | | + = = + | | + = +------+ = + | | + =| HA 1 |= + | | + +--++--+ + | +-----------+----++----+------------+ + ++ + +++ Bidirectional + ++ + +++ IPsec tunnel +------+-++-+------+ | +------+ | Visiting network +++ Unidirectional | |Router| | 10.10.10/24 IPsec tunnel | +------+ | | + ++ + | === Secure inter-HA | +------+ | HA : 192.168.1.254 communication channel | | MN |<------- HN : 192.168.1.0/24 | +------+ | HoA: 192.168.1.100 +------------------+ CoA: 10.10.10.100 Figure 1. The architecture for the basic multihoming scenario S. Hong, et al Expires January 2005 [Page 3] Internet-Draft Multihoming scenario in mipv6 12 July 2004 Figure 1 illustrates an example of basic multihoming scenario. In this scenario, we have three HAs which are located at different links within a single AS. Each HA advertises the same network prefix for MN's home link via the IGP routing protocol. The metric/cost used for these advertisement can be statistically configured on HA or dynamically be MN which sending a kind of priority information to each HA [6]. In addition, the AS routers where the home links are located also advertises BGP messages to the Internet. A MN, whose home address (HoA) is 192.168.1.100, visits a network 10.10.10/24, and receives a care-of-address, 10.10.10.100. The MN sends out the Binding Update (BU) message to its home link with setting the destination address, 192.168.1.254 reserved for HAs (We assume that the MN's HoA is already registered). When the BU message is reached to AS 1, it will be routed to one of HAs according to IGP routing policy. the HA who receives the BU message from the MN becomes the primary HA for that MN. In this example, we assume the home link where HA 1 is on is the best route, so HA 1 is the primary HA for the MN. When HA 1 receives the BU message, it updates the binding information on its Binding Information Cache and sends out the Binding Information Update messages to other HAs at different link. The primary HA (HA 1) sends the BU acknowledgment message back to the MN, and invokes the IKE security association (SA) negotiation if necessary. If the current SA between HA and MN is revoked or expired, the primary HA should invoke the IKE SA negotiation. If SA for a specific MN has been updated, the primary HA should send out the SA Information Update message to other HAs. All HAs that receive the SA Information Update message should confirm the reception of the message using the SA Information acknowledgment. When the MN finishes updating binding information and SA information (if necessary), it can communicate with multiple HAs using multiple bidirectional tunnels. Conceptually, the MN feels like that it is exchanging packets with only its primary HA. That is, all outbound packets from MN are routed to the primary HA because it is the best route to the home link, and all inbound packets from multiple HAs are tunneled to the MN with one HA source address. The benefits of the basic multihoming scenario is that we can reduce the burden of MN to maintain the HA list and SA database. Since the MN can access multiple HAs using one HA address and multiple HAs share SAs, the MN does not have to maintain HA list to track HAs who have its binding information and SA information. If the MN should establish SA with each HA, the burden to manage SA database would increase. Furthermore, if the Key Management Mobility Capability (K) bit in the BU message is cleared, HA should re-establish SA between MN and HA. It is obvious that IKE SA renegotiation per BU dramatically increases the burden of MN. There are several technical issues in supporting this basic multihoming scenario, including inconsistent IPsec sequence number and additional inter-HA communications. The following section describes these technical issues and possible solutions for them. S. Hong, et al Expires January 2005 [Page 4] Internet-Draft Multihoming scenario in mipv6 12 July 2004 3. Technical issues in implementing basic scenario The basic principle of the basic multihoming scenario is that multiple HAs share SA established between MN and its primary HA. However, there are several technical issues in implementing this basic multihoming scenario. This subsection describes these technical issues and suggests possible solutions to deal with these issues. 3.1 Inconsistent IPsec sequence number The IPsec sequence number is an unsigned 32-bit counter which monotonically increments by one for each IPsec packet [2,3]. This field is mandatory and always present even if the anti-replay service for a specific SA is disabled. In addition, the sender's and receiver's counters are initialized to 0 when an SA is established, and the transmitted sequence number must never be allowed to cycle. That, if all sequence numbers are used, the sender's and receiver's counters must be reset to 0 by establishing new SA and key. If multiple HAs are allowed to share the same SA, it is difficult to synchronize IPsec sequence number among tunneled packets by them. That is, if multiple HAs initially set their IPsec sequence numbers to 0 and independently increase their sequence number by one, then an HA would repeat the sequence number sent by other HA. This packet with repeated IPsec sequence number by different HA is still considered as the replayed and discard at MN. To cope with inconsistent IPsec sequence number among multiple senders, we provide additional information, the original IP address of HA, for MN to separate the IPsec packet stream from each HA. All HAs are accessible from MN using the reserved HA address, but each HA should have its original IP address to be attached to the home link. Each HA who shares the same SA adds its original IP address information to the destination option header in the outer header of tunneled packet [8]. To do this, we define the ORIGIN_IP destination option. When MN receives the inbound tunneled packets, it checks the ORIGIN_IP option in the destination option header to extract the original ip address of the sender HA. Based on the original HA address, the MN can split the IPsec tunneled streams into an individual stream from each HA. Additionally, to avoid unnecessary examination of the destination option header for the non-multihomed MN, the primary HA must notify whether the MN is multihomed or not. For this purpose, we define the multi-homed (M) bit and use in the BU acknowledgment message. If M bit is set (using one bit from reserved field), it indicates that the MN is multihomed to multiple HAs. S. Hong, et al Expires January 2005 [Page 5] Internet-Draft Multihoming scenario in mipv6 12 July 2004 3.2 Inter-HA protocol Because the basic multihoming scenario assumes multiple HAs who share SA information, inter-HA protocol is required to synchronize binding and SA information among HAs. The Inter-HA protocol can be categorized into three parts, which are synchronizing binding information, synchronizing SA information, and HA failure detection and recovery. Most messages except synchronizing SA information in this section are equivalent to those defined in HAHA protocol [5]. All the message described in this section must be authenticated and encrypted using the IPsec ESP mode. 3.2.1 Synchronizing binding information There are two possible ways in synchronizing binding information. First, HA can request Binding Cache information for a specific MN to its primary HA. In this case, the HA that wants Binding Cache information sends out the Binding Information Request message to the primary HA for the MN. When the primary HA for the MN receives the Binding Information request message, it replies with the Binding information update message. In this case, the sender of the Binding Information update message copies the identifier field from the request message. The second is that the primary HA for a specific MN sends out the Binding Information Update message to other HAs on the HA list whenever there is the change in its Binding Information Cache. So, if MN registers a new CoA to the primary HA, it sends out new binding information of the MN to other HAs in order to synchronize binding information among them. The Binding Information update message has the same format as the Binding update request message, but it sets the identifier field with random number and also use the Binding Cache Entry Information option [5]. When a HA receives the solicited or unsolicited Binding Information update message, it confirms with the Binding Information acknowledgment message 3.2.2 Synchronizing SA information Along with synchronizing binding information, synchronizing SA information is a critical task to share SA information among multiple HAs. The procedure of synchronizing SA information is very similar to that of binding information except it requires an additional SA Information renew request message. HA can request the SA information for a specific MN to the primary HA using the SA information request message. This message also has 16 bit non-zero identifier field to identity the sender of the request message. When the primary HA receives the SA Information request message, it replies with the SA information update message. In this case, the primary HA copies the identifier field from the request message and store SA entry information in the message. S. Hong, et al Expires January 2005 [Page 6] Internet-Draft Multihoming scenario in mipv6 12 July 2004 On the other hand, HA can send out the SA Information update message in the same manner as the Binding Information update message when there is the change in SA Information for a specific MN by reestablishing SA due to SA revocation or expiration. In this case, the primary HA sets random number in the identifier field. When other HAs receive the SA Information update message, it replies with the SA Information acknowledgment message. Since multiple HA shares SAs, it is possible that one HA used all IPsec sequence numbers earlier than other HAs. If that HA is the primary one, it reestablishes new SA for MN and sends out the SA Information update message. However, the HA is not primary HA, then it sends the SA Information renew request message to the primary HA for that SA. When the primary HA receives this message, it renew SA Information with the MN and sends out the SA Information update message to other HAs. 3.3.3 HA failure detection and recovery There are two possible methods to detect HA failure. First, HA can detect the failure of other HAs by sending an application-level keepalive message to other HAs on a regular basis. If an HA does not respond to these messages consecutively, the sender HA of this message marks the HA entry as invalid. The second method is to use the HA HELLO message defined in [5]. HA regularly sends out these HA HELLO messages to inform other HAs of activeness of the sender HA of these messages. So, if an HA does not receive these message several times in a row, it marks the HA entry as invalid. Recovering from HA failure in the basic scenario is relatively simple because HAs share SA information. Even when an HA detects the failure of one of HAs, it still sends out incoming traffic to the MN because it has the SA information for the MN. However, if the failed HA is the primary HA for MN, the outgoing traffic from MN will experience delay until the IGP settles down new paths to other HAs. Once the new routes to an alternate HA are available, the MN is able to keep sending out tunneled packets with the same SA before the failure without re-establishing SA information. In addition, if the failed HA is the primary HA for the MN and the SA for MN should be renegotiated, the HA receiving the outbound traffic from the MN checks if the primary HA for the MN is marked as invalid. If yes, it takes over the primary HA position for the MN by sending out the primary HA switch message as defined in [5]. To make this work, A HA must know all other HAs located in different links beforehand by manually configured on each HA. S. Hong, et al Expires January 2005 [Page 7] Internet-Draft Multihoming scenario in mipv6 12 July 2004 4. Extended scenarios - multiple HAs in different AS In this section we extends the basic scenario to support multiple HAs in different AS. 4.1 Multiple HAs in different AS with one HoA This scenario considers the case that MN's home links are distributed in different AS. The MN still can access the its home network in different AS using one HoA. In practice, this scenario represents the global HA distribution that multiple HAs are distributed globally irrespective of routing domains to support the global access for their mobile customers. The goal of this multi-homing scenario is to provide HA redundancy and kind of a route optimization. +-----+ +-----+ | CN1 | === : secure inter-HA communication | CN2 | +-*-^-+ +-^-*-+ * * * * * * AS 1(192.168.1/24) AS 2(192.168.1/24) * * +---*-*-------------------+ +-------------------*-*---+ | +-V-*----+ +--------+ | | +--------+ +----*-V-+ | | | HA 1-1 |===| HA 1-2 |==============| HA 2-1 |===| HA 2-2 | | | +--+-^---+ +--------+ | | +--------+ +---^-+--+ | +----+-+------------------+ +------------------+-+----+ + + + + + + + + + +++++++++++++++++++++++++ ++++++++++++++++++++++++ + +++++++++++++++++++++++++ + + ++++++++++++++++++++++++ + + + + +------+-+-+-+------+ VN : 10.10.10/24 ***> : non-ipsec | +V-+-+-V-+ | HN : 192.168.1/24 data traffic | | MN |<----- HoA: 192.168.1.100 +++> : ipsec tunneled | +--------+ | CoA: 10.10.10.100 data traffic +-------------------+ HA : 192.168.1.254 Figure 2. Extended multihoming scenario: multiple HAs in different AS. They are accessable using one HA address. Figure 2 illustrates an example of the extended multihoming scenario. As shown in Figure 2, each AS supports multiple home links for MN as defined in the basic scenario in section 2, and these ASs support multiple HAs globally distributed in different routing domain by advertising the same network prefix of MN's home network (192.169.1/24). The rest of Internet will use the closest HA to communicate with the MN according to the BGP routing policy. S. Hong, et al Expires January 2005 [Page 8] Internet-Draft Multihoming scenario in mipv6 12 July 2004 The benefit of this architecture is that the inbound traffic to the MN is always going to be the cheapest HA according to the BGP policy of the CN domain. For the outbound traffic from the MN is also going to be the cheapest HA (the primary HA) to the visiting network, but it does not mean the cheapest path to the CN. To provide a kind of route optimization for the outbound traffic from the MN, we need the inter-HA communications. That is, if other HA can provide the better route path to the CN than that of the primary HA, it can issue the primary HA switch message to the current primary HA. The technical issue in this extended scenario is that multiple ASs should advertise the same network prefix for MN's home link. These announcements can be deleted by the mechanisms to cope with "route hijacking". Carbon, et al [6] and Savola [7] pointed out this issue and showed the possible solutions. In theory, all prefixes advertised by anyone should be available in the route registry (e.g., Internet Route Registry (IRR))to examine multihoming for a specific prefix. 4.2 Multiple HAs in different AS with multiple HoAs Another extended multihoming scenario is that multiple HAs are distributed in different AS, but MN has multiple HoAs, may be one for each AS. This scenario is the typical example of site-multihoming. This scenario is likely that we have the combination of multiple basic scenario. That is, the configuration of each AS are identical to that of the basic scenario. Since HAs within an AS do not interfere with those in other AS, no change in the basic scenario is required. Also, the HA in one AS does not have to communicate with one in other HA, no inter-HA communication between them is necessary. S. Hong, et al Expires January 2005 [Page 9] Internet-Draft Multihoming scenario in mipv6 12 July 2004 5. Security considerations To protect all the messages between multiple HAs, the HA should use the IPsec ESP mode to authenticate and encrypt inter-HA messages. Since multiple HAs share SA information established between the MN and its primary HA, the primary HA should authenticate the other HAs who serves the same MN to prevent a malicious HA from launching attacks. Whenever a new HA is introduced to serve the same network prefix, other HAs should verify if this new HA is authenticated and authorized for the service. Since this multihoming scenario needs trust relations among HAs who serve the same home link, the mechanism to isolate the compromised HA when they detects it is necesary. For further security considerations, please refer to [4]. References [1] N. Montavont, R. Wakikawa, T. Ernst, and T. Noel, "Problem statement for multihomed mobile nodes," IETF Mobile IP Working Group, Internet- Draft, Work expired, October 2003. [2] S. Kent and R. Atkinson, "RFC:2402: IP authentication header," IETF Network working group, November 1998. [3] S. Kent and R. Atkinson, "RFC 2406: IP encapsulation security payload (ESP)," IETF Network working group, November 1998. [4] D, Johnson, C. Perkins, and J. Arkko, "RFC 3775: Mobility support in IPv6," IETF Network working group, June 2004. [5] R. Wakikawa, V. Devarapalli, and P. Thubert, "Inter Home Agent Protocol (HAHA)," IETF MIP6/NEMO Working group, Internet-Draft, Work in progress, February 2004. [6] J. Charbon, C-W, NG, K. Mitsuya, and T. Ernst, "Evaluating multihoming support in NEMO basic solution," IETF NEMO working group, Internet-Draft, Work expired, July 2003. [7] P. Salova, "Examining site multihoming in finnish networks," Master's thesis, Helsinki University of Technology, April 2003. [8] S. Deering, R. Hinden, "RFC 2460: Internet Protocol, Version 6 (IPv6)," IETF Network working group, December 1998. S. Hong, et al Expires January 2005 [Page 10] Internet-Draft Multihoming scenario in mipv6 12 July 2004 Authors' Addresses SeungSun Hong Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-752-3128 EMail: shong@ucdavis.edu Fan Zhao Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-752-3128 EMail: fanzhao@ucdavis.edu Felix Wu Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-754-7070 EMail: wu@cs.ucdavis.edu Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 EMail: souhwanj@ssu.ac.kr HyunGon Kim Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5428 Email: hyungon@etri.re.kr Hong, et al. [Page 11] Internet Draft Supporting Multi-sender SA July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. S. Hong, et al Expires January 2005 [Page 11]