NEMO Working Group Seongho Cho Internet Draft Jongkeun Na Document: draft-cho-nemo-mr-registration- Chongkwon Kim 00.txt Seoul National University Expires: October 2004 Sungjin Lee Hyunjung Kang Changhoi Koo Samsung Electronics April 2004 Neighbor MR Authentication and Registration Mechanism in Multihomed Mobile Networks draft-cho-nemo-mr-registration-00 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 October 26, 2004. Abstract In multihomed mobile networks, multiple Mobile Routers can be deployed to provide fault recovery or load sharing. Also, each Mobile Router (MR) can have a bi-directional tunnel with its own Home Agent (HA). In this multihomed mobile network scenario, the neighbor root MR can replace or share the operation of another MR. Therefore, MRs should cooperate with each other to provide session continuity or load sharing. We present an authentication and registration mechanism without introducing extra signaling messages. Using the Return Cho, et al. Expires - October 2004 [Page 1] Internet Draft Neighbor MR Authentication and Registration April 2004 Routability procedure of Mobile IPv6 and the Binding Update message with the neighbor MR registration option, the MR can authenticate and register the neighbor MR to its own HA. And the HA can use this registered neighbor MR information to provide fault recovery or load sharing. Conventions used in this document 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. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Related Multihoming Scenarios and Problem Definition...........4 4. Tunnel Alteration Scenarios....................................4 4.1 Link Failure...............................................4 4.2 MR Failure.................................................4 4.3 Dynamic Load Sharing or Bi-casting.........................5 5. Neighbor MR Authentication and Registration....................5 5.1 Neighbor MRs Discovery.....................................5 5.2 Neighbor MR Authentication using Return Routability........5 5.3 Neighbor MR Registration with the Binding Update Message...6 6. Additional Data Structure for Multihoming......................7 6.1 Neighbor MR List for Mobile Router.........................7 6.2 Neighbor MR List for Home Agent............................7 7. Additional Messages to NEMO Basic Support Protocol.............7 7.1 Neighbor MR Registration Option............................7 7.2 Binding Acknowledgement Status.............................9 8. Conclusion.....................................................9 9. Security Considerations........................................9 Acknowledgement...................................................9 A. HA-based Tunnel Recovery Mechanism............................10 References.......................................................10 Author's Addresses...............................................11 1. Introduction In multihomed mobile networks, multiple MRs can be used to provide fault recovery or load sharing [6]. To support these properties, each MR should cooperate with neighbor MRs. For fault recovery, each MR should substitute the other MR in case of MR failure. And for load sharing, the HA should dynamically make a tunnel through any MR in the multihomed mobile network. Cho, et al. Expires - October 2004 [Page 2] Internet Draft Neighbor MR Authentication and Registration April 2004 To provide fault recovery, the nested tunnel recovery mechanism [3] was introduced. In case of the egress link failure of the MR, the MR can be allocated the new Care-of-Address (CoA) from the neighbor root MR and make another tunnel through the nested tunnel. From this solution, however, the previous session can be continued only in case of link failure. In case of MR failure, the neighbor MR can not cooperate with each other without any previous neighbor information. Related threats are already treated at the multihoming threat analysis draft [10]. To solve the tunnel failure problem, the neighbor MR authentication and registration mechanism is needed. This registration mechanism can be applied tunnel recovery, dynamic load sharing, or bi-casting. In this document, we introduce the neighbor MR authentication and registration mechanism using Return Routability Procedure and Binding Update message. Compared to the NEMO basic support protocol [2], we only introduce the Neighbor MR Registration Option in Binding Update message as a mobility option. This solution is quite simple and can be applied to solve various problems, like not only link failure, but MR failure, load sharing, or bi-casting by the HA. Also, we present a possible solution, named as a HA-based Tunnel Recovery Mechanism in multihomed mobile networks at Section A. After detecting the broken tunnel, the HA can initiate the tunnel recovery with an alternative MR. Also, this mechanism can be applied to the dynamic load sharing or bi-casting. For load sharing or bi-casting, the HA can make another tunnel with a neighbor MR. 2. Terminology It is assumed that readers are familiar with NEMO terminology described in [3, 7], and the terms described in [2, 6]. The neighbor MR In this document, we only consider the MR which has a connection to the fixed Internet. This MR is defined as a root MR at the terminology draft [7]. Therefore, the neighbor MR is also the root MR at the same multihomed mobile network with a connection to the fixed Internet. The neighbor HA We define the neighbor HA which is a correspond HA of the neighbor MR. The MR has a secure association with its own HA, but the neighbor MR does not have any relation with another HA. Originally, the neighbor HA is not known to other MRs. The neighbor MR information Cho, et al. Expires - October 2004 [Page 3] Internet Draft Neighbor MR Authentication and Registration April 2004 In this document, we define the neighbor MR information which can be acquired from the neighbor MR or neighbor HA. This MR information is the Home Address, Care-of Address, and Mobile Network Prefix. 3. Related Multihoming Scenarios and Problem Definition In this draft, we are focusing on (N, N, 1) and (N, N, N) cases in multihoming issue draft [3]. From the view of problem oriented approach in the multihoming issue draft, the DoubleBed case can be this class. In this case, some related threats are identified in threat analysis draft [8, 9, 10]. In these multihomed mobile networks, the sub mobile network can join and leave dynamically. The MR should authenticate and register neighbor MRs to provide fault recovery and load sharing. In some situation, MRs can be manually configured by the network administrators especially if MRs are in the same administrative domain. However, it is highly desirable for mobile routers to discover alternate MRs automatically for greater flexibility. Therefore, the dynamic authentication and registration mechanism is crucial. 4. Tunnel Alteration Scenarios In this section, we discuss tunnel alteration scenarios. To provide fault recovery, broken tunnel scenarios should be considered. Broken tunnel scenarios can be classified as link failure and MR failure. And for load sharing or bi-casting, non-associated MRs and HAs pair should be able to make the bi-directional tunnel dynamically. By classifying the broken tunnel cases and reviewing the load sharing, we identify the reason of neighbor MR registration. 4.1 Link Failure Usually, the MR uses the wireless channel as an access channel for the mobility support. This wireless channel has unreliability because of channel error, blackout, or handover. From these factors, sudden link failure can be happen. Even though the wireless channel is not broken, in case of highly degraded channel, an alternative link can be cost effective. In this case, this high-loss channel can be treated as a broken link. 4.2 MR Failure The MR itself can have a problem, like an operating system bug, packet queue overflow, the lack of CPU cycle, data structure overflow, power supply problem, etc. Sudden hardware failures can happen, and Cho, et al. Expires - October 2004 [Page 4] Internet Draft Neighbor MR Authentication and Registration April 2004 this problem affects whole network nodes in the mobile network. These node problems can cause sudden service suspension. And, the MR is easy to expose to malicious attacks. Because of the mobility, the MR can be a target of any kinds of Denial-of-Service attacks. And detecting attacks is much harder than that of fixed nodes. Because the MR usually uses the wireless channel, the wireless link itself is more vulnerable for attacks. Especially, the MR can experience DoS attacks, like packet flooding, data structure attack using malicious requests or reflected Denial-of-Service attacks. In these cases, the MR cannot activate the alternative tunnel recovery. Therefore, sessions using the previous tunnel cannot be recovered after failure. 4.3 Dynamic Load Sharing or Bi-casting To support dynamic load sharing, non-associated MRs and HAs should cooperate with each other. For traffic from the mobile network, each MR can share its traffic load with neighbor MRs. In that case, each MR should have the neighbor MR information. For the traffic from the outside network, the need for load sharing through HAs can exist. If this traffic sharing is done from the HA side, HAs should share neighbor MRs’ information in the same mobile network. Using this information, neighbor HA can make a bi-directional tunnel with the alternative MR. 5. Neighbor MR Authentication and Registration In this section, we present our Neighbor MR Authentication and Registration Mechanism. Our mechanism consists of Neighbor MRs Discovery, neighbor MR Authentication using Return Routability Procedure, and neighbor MRs Registration using Binding Update message. 5.1 Neighbor MRs Discovery By listening Router Advertisement (RA) messages on the *ingress* interface, the MR can get information of neighbor MRs. This Router Advertisement can be initiated from the explicit Router Solicitation (RS) message. The root MR which is at the visiting network should response to this RS message from the ingress interface. And the responding RA message should contain its own Home Address and Mobile Network Prefix as an option. From this neighbor discovery process, the MR can acquire neighbor MR's information, like Home Address (HoA), Care-of-Address (CoA), and Mobile Network Prefix (MNP). 5.2 Neighbor MR Authentication using Return Routability Cho, et al. Expires - October 2004 [Page 5] Internet Draft Neighbor MR Authentication and Registration April 2004 After acquiring the neighbor MR information, the MR can authenticate the received neighbor MR information. Because the MR operates both as the Mobile Node (MN) of Mobile IPv6 (MIPv6) [1] and the MR of NEMO basic support protocol, the MR can operate as a MN to the neighbor MR. As a MN of MIPv6, the MR initiates the Return Routability procedure with the neighbor MR. Using the Home Test and Care-of Test, the MR can authenticate its own HoA and CoA to the neighbor MR. Therefore, after the mutual Return Routability procedure, each MR can authenticate the neighbor MRs which are discovered from the RA message. 5.3 Neighbor MR Registration with the Binding Update Message After the above Return Routability procedure finished successfully, the MR can register the neighbor MRs with Binding Update message. With an option noted as the Neighbor MR Registration Option, the MR registers acquired neighbor MRs’ HoA, CoA, MNP to its own HA. This registration is periodically repeated as the BU sent. From this periodic registration, the HA can keep the last neighbor MRs list. An example is explained in Figure 1. From the neighbor discovery process, MR2 can get the neighbor MR information from the RA message. Here, the RS process can be optional. After neighbor discovery, MR2 initiates Home Test Init message and Care-of Test Init message for the Return Routability test. Of course, MR1 also initiates the Return Routability procedure. From this mutual Return Routability test, each MR can authenticate the neighbor MR information. If the Return Routability test is failed, MR1 may discard the neighbor information. If the Return Routability test is succeeded, MR1 update this neighbor MR information to the Neighbor MR List and sends the Binding Update message with the Neighbor MR Registration option. After receiving BU from MR1, HA1 updates the neighbor MR information to the Neighbor MR List. And HA1 sends the Binding Acknowledgement. MR1 MR2 HA1 HA2 |[<- RS -] | | | | - RA -> | | | | | --- Home Test Init ---> | | <--- Home Test Init --- | | <------- | (Care-of Test Init) | | -------> | (Care-of Test) | | | --- Home Test ---> | | |<--- Home Test - | | -BU w/ neighbor MR reg opt-> | | | <- Binding Acknowledgement - | | Figure 1 Neighbor MRs Registration Cho, et al. Expires - October 2004 [Page 6] Internet Draft Neighbor MR Authentication and Registration April 2004 6. Additional Data Structure for Multihoming 6.1 Neighbor MR List for Mobile Router The Mobile Router keeps the Neighbor MR List. In this Neighbor MR List, the HA address, the HoA, CoA, and MNP pairs of neighbor MRs are kept. The HA address can be obtained from the Home Test of the Return Routability procedure. And other information is obtained and verified from the above authentication and registration process. This neighbor MR list of the MR can be used when the data packet is received from the neighbor HA. After receiving the IP-in-IP encapsulated packet, the MR can verify by checking whether the outer packet's source address is the HA address of the neighbor Mobile Router and the inner packet’ destination address belongs to the MNP. This neighbor MR List should be updated from the periodic Router Advertisement message. 6.2 Neighbor MR List for Home Agent The Home Agent keeps the Neighbor MR List of the multihomed MR. In this Neighbor MR List, the HoA, CoA, and MNP pairs of the neighbor MR should be kept. This neighbor MR list can be used when the data tunnel are recovered or the traffics are shared with the neighbor MR. In case of a tunnel recovery, the MR can select the alternative MR from this Neighbor MR List. Using the CoA of neighbor MR, the HA can make a bi-directional tunnel with the alternative MR. In case of load sharing, the HA can verify the bi-directional tunnel which comes from the neighbor MR or HA, for the outbound and inbound traffic respectively. After receiving the load-shared IP-in-IP encapsulated packet, the Home Agent can verify by checking whether the outer packet's source address is the HA address or the neighbor MR and the inner packets's destination address belongs to the MNP. This neighbor MR List should be updated from the periodic Binding Update message. 7. Additional Messages to NEMO Basic Support Protocol 7.1 Neighbor MR Registration Option This Neighbor MR Registration Option is included in the Binding Update message as a mobility option to register the neighbor MR. There could be multiple Neighbor MR Registration Options if there exist multiple MRs at the mobile network. The Neighbor MR Registration Option has an alignment requirement. Figure 2 shows the Neighbor MR Registration Option format. Cho, et al. Expires - October 2004 [Page 7] Internet Draft Neighbor MR Authentication and Registration April 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 8 bit unsigned integer indicating the length in octets of the option excluding the type and length fields. Set to 50. Reserved This field is unused for now. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Prefix Length 8 bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Cho, et al. Expires - October 2004 [Page 8] Internet Draft Neighbor MR Authentication and Registration April 2004 Home Address A 16 byte field contains the Home Address of the Neighbor MR. Home Address A 16 byte field contains the Care-of Address of the Neighbor MR. Mobile Network Prefix A 16 byte field contains the Mobile Network Prefix of the Neighbor MR. 7.2 Binding Acknowledgement Status This document also introduces the following new Binding Acknowledgement status value. 144 Neighbor MR Registration failed This message is used to notify the failed neighbor MR registration. If the HA cannot provide the functionality of managing Neighbor MR List or wants to deny the registration request, the Binding Acknowledgement can be returned with this status value. 8. Conclusion In this draft, we propose a Neighbor MR Authentication and Registration mechanism for multihomed mobile networks without new signaling message. Using Return Routability procedure of MIPv6 and Binding Update with a new option of NEMO basic support protocol, the MR can authenticate and register neighbor MRs to its own HA. This solution is quite simple and can be applied to solve various problems, like not only link failure, but MR failure, load sharing, or bi- casting by the HA. 9. Security Considerations Related security problems are treated at the draft, "Threats for Multi-homed Mobile Networks" [10]. Similar threats are also mentioned at other drafts [8, 9]. Acknowledgement Cho, et al. Expires - October 2004 [Page 9] Internet Draft Neighbor MR Authentication and Registration April 2004 A. HA-based Tunnel Recovery Mechanism We also consider the HA-based Tunnel Recovery Mechanism using above registered neighbor MR information. This mechanism consists of the broken tunnel detection, the tunnel recovery request/response process, and tunnel recovery by the neighbor MR. There already exists some tunnel availability test from the HA. The multihoming issue draft [3] considers "tunnel liveness". Basically, the periodic Binding Update and Binding Acknowledgement exchange can check the tunnel liveness. By sending binding updates regularly with shorter livetime value, the HA can check the tunnel liveness. This however may be overhead because the Binding Update message SHOULD be encrypted. And another kinds of method is "tunnel heartbeats". If there exists no data packets exchange, small probe packets can be exchanged between the HA and the MR for shorter period of binding updates. Using this mechanism, the HA can detect the broken tunnel caused by either link failure or MR failure. This active probing can be used for more reliable tunnel liveness. After detecting the tunnel failure, the HA can select the neighbor MR from the Neighbor MR List to recover the previous tunnel. This tunnel can be nested through the neighbor HA if we apply the NEMO Basic Support protocol. Also, this tunnel can be directly delivered to the neighbor MR using any route optimization mechanism. The HA sends the Tunnel Recovery Request message to the selected neighbor MR. Tunnel Recovery Request include the HA's IP Address, MR's Home Address, and Mobile Network Prefix. And the neighbor MR can verify the request by checking own Neighbor MR List. If the HA requests the tunneling for the valid neighbor MR, then it decides whether it can serve the request or not. And it responds to the HA with the Tunnel Recovery Response message. If the HA is approved to make a recovered tunnel with the neighbor MR, the HA can detour packets to the neighbor MR. And the MR can check the bi-directional tunnel by checking the outer packet's source address and the inner packet's destination address. If tunneled packets are valid, then tunneled packets can be decapsulated and delivered to the destination node. References [1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6. Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in progress). June 2003. [2] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. thubert, "Network Mobility (NEMO) Basic Support Protocol," draft-ietf- nemo-basic-support-02.txt (work in progress), May 2003. Cho, et al. Expires - October 2004 [Page 10] Internet Draft Neighbor MR Authentication and Registration April 2004 [3] C. Ng, J. Charbon, and E. Paik, "Multihoming Issues in Network Mobility Support," draft-ng-nemo-multihoming-issues-03.txt (work in progress), Feb 2004. [4] J. Charbon, C-W. Ng, K. Mitsuya, and T. Ernst, "Evaluating Multi- homing Support in NEMO Basic Solution," draft-charbon-nemo- multihoming-evaluation-00.txt (work in progress), Jul 2003. [5] E. K. Paik, H. S. Cho, and T. Ernst, "Multihomed Mobile Networks Problem Statements," draft-paik-nemo-multihoming-problem-00.txt (work in progress), Oct 2003. [6] T. Ernst, N. Montavont, R. Wakikawa, E. Paik, C. Ng, K. Kuladinithi, and T. Noel, "Goals and Benefits of Multihoming," draft-multihoming-generic-goals-and-benefits-00.txt (work in progress), Feb 2004. [7] T. Ernst, H. Lach, "Network Mobility Support Terminology," draft- ietf-nemo-terminology-00.txt (work in progress), May 2003. [8] S. Jung, F. Zhao, F. Wu, H. Kim and S. Sohn, "Threat Analysis for NEMO," Internet Draft, IETF draft-jung-nemo-threat-analysis-01.txt, (work in progress), Oct 2003 [9] A. Petrescu, A. Olivereau, C. Janreteau, H.-Y. Lach, "Threats for Basic Network Mobility Support (NEMO threats)," draft-petrescu- nemo-threats-01.txt, (work in progress), Jan 2004. [10] S. Cho, J. Na, C. Kim, S. Lee, H. Kang, C. Koo, "Threat for Multi-homed Mobile Networks," draft-cho-nemo-threat-multihoming- 00, (work in progress), Feb 2004. Author's Addresses Seongho Cho Seoul National University School of CSE, Seoul National University, San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. Phone: +82-2-884-3936 Email: shcho@popeye.snu.ac.kr Jongkeun Na Seoul National University School of CSE, Seoul National University, San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. Phone: +82-2-884-3936 Email: jkna@popeye.snu.ac.kr Cho, et al. Expires - October 2004 [Page 11] Internet Draft Neighbor MR Authentication and Registration April 2004 Chongkwon Kim Seoul National University School of CSE, Seoul National University, San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. Phone: +82-2-884-3936 Email: ckim@popeye.snu.ac.kr Sungjin Lee Global Standards & Research Team Telecommunication R&D Center, Samsung Electronics, KOREA Email : steve.lee@samsung.com Hyunjeong Kang Global Standards & Research Team Telecommunication R&D Center, Samsung Electronics, KOREA Email : hyunjeong.kang@samsung.com Changhoi Koo Global Standards & Research Team Telecommunication R&D Center, Samsung Electronics, KOREA Email : chkoo@samsung.com Cho, et al. Expires - October 2004 [Page 12]