MEXT Working Group R. Wakikawa Internet-Draft Toyota ITC Intended status: Informational July 8, 2008 Expires: January 9, 2009 The Design Consideration of Correspondent Router draft-wakikawa-mext-cr-consideration-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 January 9, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Wakikawa Expires January 9, 2009 [Page 1] Internet-Draft Design Consideration of CR July 2008 Abstract This document describes the protocol design consideration of the correspondent router for the NEMO Basic Support Protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design Consideration . . . . . . . . . . . . . . . . . . . . . 4 2.1. Triggering Route Optimization . . . . . . . . . . . . . . 4 2.2. Discoverying Correspondent Router . . . . . . . . . . . . 4 2.3. Registering Binding to Correspondent Router . . . . . . . 5 2.4. Routing Packets via Correspondent Router . . . . . . . . . 6 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 10 A.1. Normative References . . . . . . . . . . . . . . . . . . . 10 A.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Wakikawa Expires January 9, 2009 [Page 2] Internet-Draft Design Consideration of CR July 2008 1. Introduction The MEXT Working Group have discussed the possible route optimization solution for the NEMO Basic Support protocol. The requirements documents are available in IETF [ID-AUTOREQ] [ID-AEROREQ]. One of solution candidate is the Correspondent Router that is defined as "A router that is capable of terminating a Route Optimization session on behalf of a Correspondent Node" in [RFC-4885]. Figure 1 shows the overview of the route optimization for the NEMO Basic Support protocol by Correspondent Router. It is the same figure of RFC-4889 [RFC-4889]. If the Correspondent Router locates on the path between end-nodes, the path can be optimized compared to the dog-leg route (via Home Agent). ************************** HAofMR * #*# * #*# +---------------------+ CN #*# | LEGEND | o #*# +---------------------+ o ############### #*# | #: Tunnel | CR ooooooooooooooo MR | *: NEMO Basic route | ############### | | o: Optimized route | MNN +---------------------+ Figure 1: Correspondent Router However, the protocol design of the correspondent router is not such easier and simpler. We had published "Optimized Route Cache Protocol (ORC)" [PAPER-ORC] [ID-ORC] as a protocol of Correspondent Router, but we found there are both technical and operational issues. In this document, we summarize the issues and required considerations of the Correspondent Router. The keywords "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 [RFC-2119]. Wakikawa Expires January 9, 2009 [Page 3] Internet-Draft Design Consideration of CR July 2008 2. Design Consideration There are several issues to design a protocol for Correspondent Router. 2.1. Triggering Route Optimization In the NEMO Basic Support protocol [RFC-3963], a mobile router takes care of all the mobility signaling. The mobile router first needs to detect the flow in or out the mobile network to initiate the route optimization. The detection can be done by receiving packets of mobile network nodes at either ingress or egress interfaces. In Mobile IPv6, the mobile host can decide whether the route optimization is initiated or not. However, It is hard for the mobile router to optimize only specific flows. The mobile router is an intermediate node between end nodes and cannot judge the route optimization per flow without some policy. The information of the policy might be a flow classification (5 tuples), a route optimization capability (BOOLEAN: ON/OFF), etc. The packets snoofing does not help much to distinguish the flow characteristics such as short/long-term, delay-sensitive, etc. It is also hard to distinguish a flow if there are the ESP protected flows. There are several ways to set such policy to the mobile router. If a mobile network node dynamically installs such policy to a mobile router, we need a new policy exchange protocol between a mobile network node and the mobile router. Alternatively, the operator of the mobile router can statically set the policy. The home agent distribution such as the global HAHA [ID-HAHAINTEROP] [ID-HAHA] is much simpler. The mobile router or the mobile node are not involving the route optimization trigger. The trigger is given by the home agent. 2.2. Discoverying Correspondent Router Since a correspondent router is also intermediate node on the path between end-nodes, it is harder to discover the address of the correspondent router. We have to consider two different scenarios for the discovery. 1. Correspondent Router is located on the path of end-nodes 2. Correspondent Router is NOT located on the path of end-nodes If a correspondent router is located on the path, the mobile router might send control packets (ICMP, etc) and discovers the Correspondent Router. This is dynamic discovery based on routing Wakikawa Expires January 9, 2009 [Page 4] Internet-Draft Design Consideration of CR July 2008 mechanism. On the other hand, if a Correspondent Router is NOT located on the path of end nodes, it can be discovered by some lookup system such as DNS. A mobile router lookup DNS server for the correspondent router address of the target flow. The anycast address can be also used to find the best correspondent router [ID-ORC], but the anycast address must be defined at any networks where correspondent nodes locate. How to look up the anycast address is another issue. The global HAHA [ID-HAHAINTEROP] [ID-HAHA] does not require the dynamic discovering any entity, because the home agents are operated by the same operator and are controlled in their network. 2.3. Registering Binding to Correspondent Router The Correspondent Router and the mobile router are not belong to the same administrative domain, there are several security concerns. After detecting the correspondent Router, a mobile router needs to send a secured binding update to the correspondent router. However, since both a mobile router and a Correspondent Router are intermediate nodes of the end-nodes, a mechanism to secure the signaling between two routers is required. The establishment cost of the security association might be negligible. Next concern is whether a mobile router sends a binding update for either an address of the mobile network node or prefix(es) of the mobile router. If the binding is for the mobile network prefix(es), careful operations must be taken. Otherwise, all the flows initiated from the the mobile network prefix(es) are going to be optimized with the correspondent router. This might be unexpected behavior in some scenarios. After the mobile router registers the prefix binding to the correspondent router, it is uncontrollable to optimize only specific flow destined to correspondent nodes behind the correspondent router. Another security concern is the address/prefix ownership verification of the binding. Since the mobile router does not configure with the address, how can the correspondent router believe the the address in the binding update which is not sent from the address owner (mobile network node). The prefix ownership verification is more challenging issue. An address/prefix ownership verification mechanism between a mobile router and a correspondent router is required. Note that the reachability test like Return Routability cannot be used because the mobile router cannot respond to the correspondent router with the address of the mobile network node or the mobile network prefix(es). In the global HAHA, all the home agents are belong to the same administrative group. Therefore, we might expect the secured link Wakikawa Expires January 9, 2009 [Page 5] Internet-Draft Design Consideration of CR July 2008 between home agents or might utilize strong security mechanism for signaling between home agents. The prefix or address verification is easily operated, since the home agent delegates that address and prefix(es) to the mobile router. 2.4. Routing Packets via Correspondent Router Even after the successful binding registration to the Correspondent Router, the path between two nodes should be via both the mobile router and the Correspondent Router (HA-MR-CR-CN). However, some considerations are required to keep the ideal path by the operators of the Mobile Router and the Correspondent Router. The routing managements are another challenging issue of the Correspondent Router. The issues are classified into two parts: MR-CR routing path management and CN-CR routing path management. MR-CR Route Management: In Figure 1, the path between a correspondent node and a mobile network node is drawn as the symmetric path. However, in the current Internet, the path is often asymmetric. Many autonomous systems has multiple peering points and injects the own routes from them. Therefore, even if one direction is optimized, there is no guarantee that the reverse path is also optimized (Figure 2). Therefore, for the deployment of correspondent routers, the operator must be carefully managed their network in terms of routing, the location of correspondent routers, and the number of correspondent routers, etc. Note that this management is relatively difficult because the mobile router changes its attachment point. The path between the mobile router and the correspondent router is changed by the mobile router's movements. + +++++++++++++++++++++++++ HAofMR + ---------> #+# + #+# +---------------------+ CN #+# | LEGEND | o #+# +---------------------+ o ############### #+# | #: Tunnel | CR ooooooooooooooo MR | +: CN -> MNN | ############### | | o: MNN -> CN | <---------- MNN +---------------------+ Figure 2: Asymmetric Path (MR-CN Route Management) Wakikawa Expires January 9, 2009 [Page 6] Internet-Draft Design Consideration of CR July 2008 CN-CR Route Management: Another routing management issue is how the Correspondent Router handle the packets meant for the mobile router from correspondent nodes. In Figure 3, there are two exit routers toward the Internet in the site of correspondent node and place one or more correspondent routers at the exit router as an example configuration. MNN MNN MNN | | | MR#######HAofMR MR# MR # o # # # # o # # # # o # # # CR1 Router CR1 CR2 CR1###### CR2 + o + o + o + o + o + o CN CN CN a) b) c) Figure 3: Multiple Exit Routers (CN-CR Route Management) In Figure 3-a), if the packets from the correspondent node is routed to the Router, the packet is routed through the home agent (i.e. unoptimized path). In order to optimize the path, the operator MUST guarantee that the Correspondent Router (CR1) receives all packets meant for the mobile router from correspondent nodes. To do so, the CR1 dynamically injects the mobile network prefix of the mobile router to the site of the correspondent node. This injecting routes will be available while the CR1 manages the active binding of the mobile router. However, from the administrative and operational point of view, the route injection of the different prefixes from its autonomous system are often restricted. Another approach is shown in Figure 3-b) and -c). Correspondent Routers are placed at all the exit routers of the site. We now investigate the multiple correspondent router managements. This configuration might brings other routing management issues inside the site of the correspondent router. In Figure 3-b), the mobile router sends a binding update to both CR1 and CR2 to establish bi-directional tunnels. It causes additional overheads to the mobile router such as 1) discovering all the correspondent routers, 2) sending multiple binding updates, 3) managing multiple tunnels. Wakikawa Expires January 9, 2009 [Page 7] Internet-Draft Design Consideration of CR July 2008 Alternatively, after receiving a binding update from the mobile router, the receiver of the binding update (let's say CR1 as an example) synchronizes the state with the other correspondent routers (CR2) in Figure 3-c). The CR2 establishes a tunnel to the CR1 for the packets destined to the mobile network prefix. Additional protocols such as inter-correspondent router protocol like the inter- HAHA protocol [ID-HAHA] might be required. In the global HAHA, the differences might be 1) the aggregated route injection per the home prefix (sets of the mobile network prefixes), 2) the stable (controlled?!) route injection (no dynamic injection). Each home agent in the global HAHA injects its entire home prefix from different location and advertise that the aggregated home prefix route persistently. The routing management of the HAHA must be more controllable for operators than the one of Correspondent routers. Wakikawa Expires January 9, 2009 [Page 8] Internet-Draft Design Consideration of CR July 2008 3. IANA considerations This document does not require any IANA action. Wakikawa Expires January 9, 2009 [Page 9] Internet-Draft Design Consideration of CR July 2008 4. Security Considerations Security vulnerability is not introduced in this specification. Appendix A. References A.1. Normative References [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. A.2. Informative References [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [RFC-4888] C. Ng, et. al, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007. [RFC-4889] C. Ng, et. al, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [ID-HAHA] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA protocol", Work in Progress, September 2006. [ID-HAHAINTEROP] R. Wakikawa, K. Shima and N. Shigechika, "The Global HAHA Operation at the Interop Tokyo 2008", draft-wakikawa-mext-haha-interop2008-00.txt (work in progress), July 2008. [ID-AEROREQ] W. Eddy, et. al,"NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02.txt, May 2008. [ID-AUTOREQ] R. Baldessari, et. al, "Automotive Industry Requirements for NEMO Route Optimization", draft-ietf-mext-nemo-ro-automotive-req-00.txt, February 2008. [PAPER-ORC] Wakikawa, R., Koshiba, S., Uehara, K., and J. Murai, Wakikawa Expires January 9, 2009 [Page 10] Internet-Draft Design Consideration of CR July 2008 "ORC: Optimized Route Cache Management Protocol for Network Mobility", 10th International Conference on Telecommunications, vol 2, pp 1194-1200, February 2003. [ID-ORC] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol (ORC)", Work in Progress, November 2004. Author's Address Ryuji Wakikawa Toyota ITC / Keio University 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: ryuji@jp.toyota-itc.com Wakikawa Expires January 9, 2009 [Page 11] Internet-Draft Design Consideration of CR July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Wakikawa Expires January 9, 2009 [Page 12]