MEXT Working Group C. Bauer Internet-Draft S. Ayaz Intended status: Informational DLR Expires: March 13, 2010 A. Ebalard EADS September 9, 2009 Solution Space for Aeronautical NEMO RO draft-bauer-mext-aero-solspace-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 March 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Bauer, et al. Expires March 13, 2010 [Page 1] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 Abstract Many potential solutions have been proposed for NEMO Route Optimization, although none has been adopted up to now. This draft aims on evaluating the different approaches for the aeronautical use case. At the end, a recommendation for the next steps is given. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Correspondent Router . . . . . . . . . . . . . . . . . . . 6 3.2. Global HA to HA . . . . . . . . . . . . . . . . . . . . . 9 4. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Considerations for PIES . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Short Overview of all RO Solutions . . . . . . . . . 19 A.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. Applicability to the Aeronautical Environment . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Bauer, et al. Expires March 13, 2010 [Page 2] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 1. Introduction An extensive overview of NEMO Route Optimization (RO) solution candidates has been provided in [RFC4889]. The options are manifold and obviously the solution has to be adopted based on the operational environment. The task of this draft is to investigate the solutions in more detail and highlight the deficiencies of the protocols that should be addressed in the future. A document listing the requirements that have to be fulfilled by a potential aeronautical NEMO RO solution has already been compiled [I-D.ietf-mext-aero-reqs]. In addition, another document [I-D.bauer-mext-aero-topology] provides information on the aeronautical network environment. We will rely on both to perform the investigation. It is expected that the reader is familiar with the NEMO Support Terminology [RFC4885] and the three above mentioned documents. Bauer, et al. Expires March 13, 2010 [Page 3] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 2. Overview The focus of our investigations is on RO for the ATS/AOS service classes (cf. [I-D.ietf-mext-aero-reqs]). As defined in [I-D.ietf-mext-aero-reqs], the problem of nested MRs is not a requirement and merely desired and can therefore be ignored in the first step. Its only use case is that of a MANET of aircraft, where other solutions to the problem can be found, e.g. within the MANET (routing) itself, that are transparent to NEMO. Support for VMNs is also not required for the ATS/AOS domain. Hence the applicable NEMO RO solutions can be categorized as follows, listing those nodes that are involved in mobility related signaling: 1. MNN to CN: RO is performed between the end systems. 2. MR to CN: The Mobile Router performs RO on behalf of the MNN with the CN. 3. MR to CR: The MR performs RO with a Correspondent Router that is located close to the CN and that can forward traffic from and to the CN. 4. MR to HA: The MR binds to a topologically closer Home Agent. The requirements from [I-D.ietf-mext-aero-reqs] play an important role for the analysis. We list them here for ease of reading: 1. Req1 - Separability: "Since RO may be inappropriate for some flows, an RO scheme MUST support configuration by a per-domain dynamic RO policy database [...]". The rationale for this requirement is to trigger RO only for flows that really require it. 2. Req2 - Multihoming: " An RO solution MUST support an MR having multiple interfaces, and MUST allow a given domain to be bound to a specific interface. It MUST be possible to use different MNPs for different domains". Multihoming itself is supposed to allow segregation of traffic flows over different interfaces. 3. Req3 - Latency: "While an RO solution is in the process of setting up or reconfiguring, packets of specified flows MUST be capable of using the MRHA tunnel". 4. Req4 - Availability: "An RO solution MUST be compatible with network redundancy mechanisms and MUST NOT prevent fall-back to the MRHA tunnel if an element in an optimized path fails. An RO mechanism MUST NOT add any new single point of failure for Bauer, et al. Expires March 13, 2010 [Page 4] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 communications in general". Redundancy mechanisms do not have to be considered for the RO mechanism itself; this requirement merely tries to ensure that RO does not interfere with any existing redundancy mechanism. 5. Req5 - Packet Loss: "An RO scheme SHOULD NOT cause either loss or duplication of data packets during RO path establishment, usage, or transition, above that caused in the NEMO basic support case. An RO scheme MUST NOT itself create non-transient losses and duplications within a packet stream". 6. Req6 - Scalability: "An RO scheme MUST be simultaneously usable by the MNNs on hundreds of thousands of craft without overloading the ground network or routing system. This explicitly forbids injection of BGP routes into the global Internet for purposes of RO". 7. Req7 - Efficient Signaling: "An RO scheme MUST be capable of efficient signaling in terms of both size and number of individual signaling messages and the ensemble of signaling messages that may simultaneously be triggered by concurrent flows". 8. Req8 - Security #1 (for ATS): "The RO scheme MUST NOT further expose MNPs on the wireless link than already is the case for NEMO basic support". 9. Req8 - Security #2 (for ATS): "The RO scheme MUST permit the receiver of a BU to validate an MR's ownership of the CoAs claimed by an MR" and "the RO scheme MUST ensure that only explicitly authorized MRs are able to perform a binding update for a specific MNP". 10. Req9 - Adaptability: "Applications using new transport protocols, IPsec, or new IP options MUST be possible within an RO scheme". In particular, the RO scheme should not fail on the use of previously unknown higher layer protocols. In the first stage we have performed a short analysis of all the four possible approaches outlined above. We came to the conclusion that only two of these, namely "MR to CR" and "MR to HA", are of interest to the aeronautical environment. We therefore focus on these in Section 3 below. Nevertheless, for completeness, we have added the short analysis of all four categories in Appendix A. Bauer, et al. Expires March 13, 2010 [Page 5] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 3. Discussion This section discusses the "MR to CR" and "MR to HA" proposals in detail. 3.1. Correspondent Router The CR approach was first introduced in [I-D.orc] and later a proposal specifically targeted at the aeronautical requirements has been specified in [I-D.draft-bernardos-mext-nemo-ro-cr]. Another document [I-D.draft-wakikawa-mext-cr-consideration] discusses possible issues and provides considerations for the CR protocol. Req1 - Separability: at the moment, the only obvious way how separation could work is on a per address/prefix basis and not traffic type or application. The major problem is related to the CR relying on IGP advertisements within its network to attract traffic destined for the MR. In that case, the separability of different flows can only be achieved based on addresses/prefixes, but not on traffic type on the CR side. The CR specifications (either [I-D.orc] or [I-D.draft-bernardos-mext-nemo-ro-cr]) do not discuss the compatibility with [I-D.draft-ietf-monami6-multiplecoa] and [I-D.draft-ietf-mext-flow-binding] in order to dispatch flows between the MN and its CR via different interfaces (CoA) on the MR. However, whether it is really necessary to direct certain flows, destined to the same CN, over the RO path and others over the MR-HA tunnel is not obvious. At least for the ATS domain, it could be considered sufficient to have separability on a per-address basis. Req2 - Multihoming has, to a certain degree, already been addressed above. Nevertheless, when taking a more detailed look at MCoA, its implementation within the CR protocol comes at the expense of the MR having to register each CoA separatly (no bulk registration). The signaling overhead for the registration grows linearly with the number of CRs the MR is binding with. At least for the ATS domain, this might not be considered as problematic given that only one or at most two CR bindings are probably active at a certain point in time (cf. [I-D.bauer-mext-aero-topology]). Req3 - Latency: the delay of establishing RO with the CR is the sum of the discovery and the registration procedures. Appendix A.3 of [I-D.draft-bernardos-mext-nemo-ro-cr]) states that these steps may be done while the MR-HA tunnel is still used for sending user data. The signaling during a handover is equivalent to that of standard MIPv6 RO for [I-D.orc] and an IKEv2 and BU/BA exchange for [I-D.draft-bernardos-mext-nemo-ro-cr]. For as long as this signaling is performed, it could be expected to rely on the (updated) MR-HA tunnel for as long as the binding with the CR has not been renewed. Bauer, et al. Expires March 13, 2010 [Page 6] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 This behaviour depends though on which of the MR-CR and MR-HA bindings has been first successfully updated. A change of the CoA will trigger the same series of events, except for the discovery procedure that is not needed anymore. Req4 - Availability: the MR maintains a communication path with a unique and static HA and also has direct routing paths (RO paths) with its correspondents, via the various CRs located near those final correspondents. In case of failure of the CR, the MR could switch back to the MR-HA tunnel, given that the failure is detected. However, it is difficult to assess whether the probability for a CR failure is larger then for a HA failure. On the other hand, a CR could also increase the availability in case of HA failure if credentials between MR and CR are available and RO can therefore be established in a different way compared to MIPv6 RO. In terms of routing path characteristics, the shorter path used by the MR-CR tunnel might have a lower probability of failure than the "longer" MR-HA path. Req5 - Packet loss: as already mentioned for Req3, while performing signaling for setting up the RO state, the MR-HA tunnel could be used for user data and no packet loss would therefore be induced. For as long as the mobility binding at the CR has not been re-established, packets can flow from the MR via the HA (if already available) directly to the CN, but on the reverse path packets will be sent to the old CoA of the MR and therefore be lost. Req6 - Scalability: if the number of CNs and, most importantly, the number of networks in which they are hosted increases, more CRs will be needed. Appendix A.6 of [I-D.draft-bernardos-mext-nemo-ro-cr] does not discuss the fact that the more CRs a MR has a binding with, the more signaling it needs to send after a handover (change of CoA). It is therefore important to consider the number of nodes within the ATS and AOS domains. Taking into account the ATS communication model (cf. [I-D.bauer-mext-aero-topology]), the number of CRs that the MR should have an active binding with might be limited to two. Req7 - Efficient Signaling: signaling is required for each binding with a CR. If MCoA/flow-binding should be supported, the amount of signaling might increase. An aspect that is not discussed in Appendix A.7 of [I-D.draft-bernardos-mext-nemo-ro-cr] is the signaling that may be required for the detection of the CR, required once at the time RO is initiated. Req8 - Security: a main requirement is that the authenticity of the MNP of the MR has to be verified. [I-D.orc] relies on the well known Return Routability method of Mobile IPv6 and therefore inherits its security weaknesses. [I-D.draft-bernardos-mext-nemo-ro-cr] proposes Bauer, et al. Expires March 13, 2010 [Page 7] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 to use IKEv2/IPsec to secure the BU/BA exchange with the assumption that "certificates are used to prove ownership of prefixes by MRs and CRs". The location, domain and associated authority under which the CR is deployed can make the deployment difficult, depending on the availability of those credentials. Req9 - Adaptability: for as long as generic packet tunneling is used between MR and CR, no problems can be expected wrt security protocols within the inner tunnel. This is similar to NEMO Basic Support. The discussion related to Req1 and Req2 already mentioned that using certain traffic types (e.g. specific transport protocol) for either flow-specific RO or flow-bindings management could be regarded as problematic. The following paragraphs are not directly related to the requirements anymore, but are from a more general perspective. A critical item, that is not directly covered by the requirements, is the discovery of the CR: it is difficult for the MR to know the anycast address for a particual CR, as needed for the discovery request message. Deriving it from the CN address, as originally proposed in [I-D.orc], can not work if both CN and CR do not share the same 64bit prefix. A CR could be regarded as an entity that is close to the CN but already has a trust relationship with the MR. Taking a closer look at the topology of the aeronautical environment, presented in [I-D.bauer-mext-aero-topology], reveals that the following two options for deployment of CRs are possible for ATS: 1. CR in ANSP network: while the topological location is excellent for RO purposes, the CR can not be considered to have a trust relationship anymore. If the CR would have, then a trust- relationship would also be possible with the CN, as both are within the same operational domain. 2. CR in the neighbouring gACSP network: having a trust relationship between MR and the gACSP domain is very likely, but the topological location is not ideal anymore. The CR can, in general, not be on-path anymore. In fact, it is located in a completely different domain, a situation that will cause operational problems, especially if the network of the CN is multi-homed and peering with several gACSPs. These deployment options are dependent on the credentials mentioned in the discussion of Req8 above. Bauer, et al. Expires March 13, 2010 [Page 8] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 3.2. Global HA to HA The Global Home Agent to Home Agent protocol is specified in [I-D.draft-wakikawa-mext-global-haha-spec] and makes use of the HA reliability protocol [I-D.draft-ietf-mip6-hareliability]. Req1 - Separability: in Global HAHA, instead of having RO triggered on a per-flow or per-destination basis, the MR/MN's position dictates the HA instance used by the MN/MR (usually the topologically closest one). From this perspective, HAHA does not directly provide a way to support this requirement. Whether this requirement is applicable to HAHA is a different question though. Nevertheless, while not explicitly discussed in HAHA at the time of writing, compatibility with MCoA [I-D.draft-ietf-monami6-multiplecoa] and flow-binding [I-D.draft-ietf-mext-flow-binding] specifications could address this issue. Req2 - Multihoming: compatibility with the MCoA/flow-binding specifications needs to be discussed, as already shortly mentioned above in Req1. From a more general point of view, Global HAHA does not fundamentally modify the relationship with the HA, therefore making these protocol extension applicable to it. But due to the way the primary HA of a MN/MR is selected (the topologically closest instance of the first active CoA is used), the addition of new CoA raises questions. If two CoAs have different HA attractors, how should the protocol behave: should it manage to keep a single primary HA for all CoAs (considering one is a primary) or be extended to support bindings for different CoAs with different HAs? Because the binding cache has to be shared between the HA instances, adding support for MCoA/flow-binding to Global HAHA may require additional synchronization and complicates the protocol. Req3 - Latency: the overall latency is composed of the BU/BA exchange between the MR and the HA. In case the MR moves to a different location that attracts a different HA, the MR will receive a HA Switch Message that forces him to establish a binding with the new HA. This requires an additional IKEv2/IPsec and BU/BA exchange. In general, the latency is therefore equivalent to the standard NEMO protocol and several additional RTTs if the MR binds to a new HA after handover events (change of CoA). Req4 - Availability: the operation of HAHA is based on the HA reliability protocol [I-D.draft-ietf-mip6-hareliability] that describes how failovers are performed between local instances. Due to this, a local HA failure can be overcome and this part of the requirement be therefore fulfilled due to the additional local HA instances. When looking at the MR-HA path, if the routing to the home network is broken (not the physical link the MR is using but an Bauer, et al. Expires March 13, 2010 [Page 9] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 element along the path), current behavior is unknown (both for Global HAHA and NEMO Basic Support). Depending on the precise nature of the routing failure, it might be possible within the context of Global HAHA that another HA island starts attracting traffic (this however will also be dependendent on the BGP convergence time of the anycast prefix advertised by the "new" HA island). Req5 - Packet loss: Global HAHA shows the same behaviour as standard MIPv6/NEMO Basic Support. For as long as the MN/MR has not finished mobility signaling for updating the tunnel with the new CoA, the HA will send packets to the old CoA that will therefore be lost. After this signaling has been finished, the MR could be informed by its current HA to switch to another, closer HA. While this adds latency for setting up the RO path (shorter route due to closer HA), it is a "soft" movement and will not cause packet loss as long as the binding with the old HA is kept active while the new binding has not yet been succesfully established. Req6 - Scalability: with Global HAHA, a given MR being handled by the closest HA instance leads to a natural distribution of the traffic between all the HAs. The traffic load at the ground network is dependent on the location of the MRs and the HA islands. From a routing table perspective, Global HAHA deployment puts some load on the BGP routing system, as prefixes have to be advertised. The number of BGP advertised prefixes is dependent on the number of anycast prefixes and HA islands, but should at least be constant and not show any frequent advertise/withdrawal behaviour. Another critical aspect is the network traffic caused by synchronizing the binding caches between the various HA instances (cf. [I-D.draft-ietf-mip6-hareliability]) if the number of HAs is very large. Req7 - Efficient Signaling: in Global HAHA the amount of signaling between the MR and its HA is roughly the same as in NEMO Basic Support. This number is increased by the HA switch operation and therefore depending on the number of HAs. Most importantly, the amount of signaling is constant - it does not depend on the number of correspondent nodes the MR is currently communicating with. Considering that MCoA/flow-bindings will work with Global HAHA in the future, the expected amount of signaling will still remain minimal, for as long as it is performed with only a single HA. As already discussed for Req2 - Multihoming, sychronizing flow-bindings among different HAs will induce more overhead. Req8 - Security: as in Global HAHA bindings are only performed with the HAs of the home network (within a single administrative domain), meeting the security requirements is much easier to fulfill. IKEv2/ IPsec protects the BU/BA message exchanges between the MR and the HA Bauer, et al. Expires March 13, 2010 [Page 10] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 instances. Consecutively, due to the use of IKEv2, the problem of MNP authentication is directly addressed. Req9 - Adaptability: As Global HAHA does not modify the operation of the MR-HA tunnel (apart from having it with the closest HA instance), no limitations are introduced when compared to NEMO Basic Support. The following paragraphs are not directly related to the requirements anymore, but are from a more general perspective. Global HA to HA does not have the problems of the CR protocol wrt security and credentials, as its scope is restricted to the MR and the Mobility Service Provider (MSP) operating the HAs. Its disadvantage is that the level of provided RO depends on the global network presence of the MSP. gACSPs (cf. [I-D.bauer-mext-aero-topology]) can achieve this goal, whether this also holds for airlines acting as their own MSP is unclear. This is in fact a critical aspect for HAHA, as a home network without a distributed global presence can not meet the original goal of providing an adequate, short latency RO path. As mentioned in Section 3.3.1 of [I-D.bauer-mext-aero-topology], the MR could actually be attached to the same network as the CN. Failures within the home network or with the routing path between the visited and the home network breaks connectivity to the HAs and would then prevent communications although both nodes (MR and CN) are in close topological proximity. Bauer, et al. Expires March 13, 2010 [Page 11] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 4. Next steps The investigation showed that both protocols have advantages and disadvantages, although open questions remain for both of them. The CR protocol has issues related to its discovery procedure, but can support multihoming, although at the expense of having to register each CoA separately. The deployment options are restricted by the availability of credentials and by the location of the CNs. Global HA to HA has the advantage of restricting the mobility signaling to the MR and home network only. How multihoming can be addressed is not yet clear; in addition, the overhead caused in the ground network might become an issue with a growing number of HAs. We therefore think that additional work and investigations in the following areas are required: For CR: 1. Discovery procedure. 2. A more detailed specification of the mobility signaling between MR and CR, including mutual authentication between MR and CR. For HAHA: 1. Overhead caused by binding cache synchronizations between HAs. 2. Support for multihoming as in [I-D.draft-ietf-monami6-multiplecoa] and [I-D.draft-ietf-mext-flow-binding]. Aftewards, the solution space investgation can be revisited and the proper solution be selected. Bauer, et al. Expires March 13, 2010 [Page 12] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 5. Considerations for PIES All discussion up to now have been focussed on the ATS/AOS traffic classes. Passenger communications, especially for passenger owned devices, has been ignored. We think though that the number of options is severly limited for this scenario: 1. RO signaling involving the CNs is unrealistic as those nodes are usually within the public Internet and will most like not implement any mobility functionality. 2. Deployment of special infrastructure in the Internet, e.g. CRs, just for the purpose of RO seems unlikely. 3. Forcing passengers to install software for mobility functionality might be regarded as problematic. As a consequence, Route Optimization has to be limited to the MR and the MSP network. This implies Global HA to HA is a reasonable solution for the PIES domain. This would also allow to reuse the protocol for the ATS/AOS environment. Bauer, et al. Expires March 13, 2010 [Page 13] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 6. Security Considerations This document only presents information related to the aeronautical NEMO RO solution space. There are no security issues in this document. Bauer, et al. Expires March 13, 2010 [Page 14] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 7. Acknowledgements Christian Bauer and Serkan Ayaz have been partially supported by the European Commission through the NEWSKY project. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the NEWSKY project or the European Commission. Bauer, et al. Expires March 13, 2010 [Page 15] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 8. References 8.1. Normative References [I-D.bauer-mext-aero-topology] Bauer, C. and S. Ayaz, "ATN Topology Considerations for Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00 (work in progress), July 2008. [I-D.ietf-mext-aero-reqs] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", draft-ietf-mext-aero-reqs-04 (work in progress), August 2009. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. 8.2. Informative References [I-D.bernardos-nemo-miron] Bernardos, C., "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", draft-bernardos-nemo-miron-01 (work in progress), July 2007. [I-D.draft-bernardos-mext-nemo-ro-cr] Bernardos, C., Calderon, M., and I. Soto, "Correspondent Router based Route Optimisation for NEMO (CRON)", July 2008, . [I-D.draft-ietf-mext-flow-binding] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", July 2009, . [I-D.draft-ietf-mip6-hareliability] Wakikawa, R., "Home Agent Reliability Protocol", Bauer, et al. Expires March 13, 2010 [Page 16] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 July 2009, . [I-D.draft-ietf-monami6-multiplecoa] Wakikawa, R., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", May 2009, . [I-D.draft-wakikawa-mext-cr-consideration] Wakikawa, R., "The Design Consideration of Correspondent Router", July 2008, . [I-D.draft-wakikawa-mext-global-haha-spec] Wakikawa, R., Zhu, Z., and L. Zhang, "Global HA to HA Protocol Specification", July 2009, . [I-D.ndproxy] Lee, K., Jeong, J., Park, J., and H. Kim, "ND-Proxy based Route and DNS Optimizations for Mobile Nodes in Mobile Network", February 2004, . [I-D.orc] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol (ORC)", October 2004, . [I-D.pd] Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", February 2004, . [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, Bauer, et al. Expires March 13, 2010 [Page 17] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 "Mobility Header Home Agent Switch Message", RFC 5142, January 2008. Bauer, et al. Expires March 13, 2010 [Page 18] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 Appendix A. Short Overview of all RO Solutions This Appendix covers all four approaches (MNN to CN, MR to CN, MR to CR, MR to HA) to the RO problem with a short analysis. A.1. Analysis For each solution class, a specific draft is shortly summarized before the analysis is performed. A.1.1. MNN to CN In general, for this solution class information related to the MRs access network and access routers (ARs) is exposed to the MNNs. Based on this information, the MNNs can perform RO by themselves directly with the CN. The MR is therefore only in a supporting role. A.1.1.1. Proposal(s) The MR is attached to a subnet with an appropriate AR. The draft [I-D.ndproxy] describes how the MR relays the subnet prefix of the AR inside the mobile network to the MNNs, that in turn use Autoconfiguration [RFC4862] to configure their IP addresses. The MR then acts as a ND proxy. Another, similar approach relies on prefix delegation between MR and AR [I-D.pd] where the AR receives a complete proper prefix that can be used inside the NEMO mobile network. Packets sent over the RO path use the Type 2 Routing Header and Home Destination Option as specified for RO in [RFC3775]. A.1.1.2. Analysis This approach might face problems in the presence of Secure Neighbor Discovery in the access network [RFC3971] when using the MR as ND proxy. MNNs have to implement MIPv6 [RFC3775] for performing RO themselves and the MR has to be upgraded as well. Verifying the requirements against this solution approach, we come to the following conclusions: 1. Req1: Fulfilled. MNNs can decide by themselves to perform RO. 2. Req2: To be discussed. MNNs can configure one address per advertised (access network) prefix. The disadvantage is that the access network has to accept every MNN address as source address for packets, something that may not be supported if the Bauer, et al. Expires March 13, 2010 [Page 19] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 egress interface supports having only a single IP address. 3. Req3: Fulfilled. Can rely on standard MIPv6 RO; MR-HA tunnel therefore used for as long as RO has not been completed. 4. Req4: Fulfilled. RO is performed between the end systems - no additional single-point of failure for communication added. 5. Req5: Fulfilled. As long as the RO path has not been established, packets can be sent over the MR-HA tunnel. 6. Req6: Problematic. Signaling overhead will be per MNN/CoA/home network prefix/CN. BGP not relevant. 7. Req7: Problematic. The signaling for RO is equal to that of standard MIPv6. Several messages and RTTs are needed for every MNN that is performing RO. 8. Req8 #1: To be discussed. While the MNP itself is not part of the RO signaling, the addresses of the individual end systems within the RO signaling is in cleartext. This is also the case for NEMO Basic support though, if no IPsec confidentiality protection is used for user data traffic. 9. Req8 #2: Problematic. If relying on standard MIPv6 RO, MNP/HoA verification can be broken. 10. Req9: To be discussed. As conclusion, while this approach allows for high granularity of RO triggering and setup due to the fact that the MNN is in charge, this approach has problems related to scalability and security if standard MIPv6 RO is used at the MNNs. A.1.2. MR to CN In general, within this solution class the MR performs RO on behalf of the MNN. A.1.2.1. Proposal(s) The MR acts as a transparent MIPv6-MN-proxy by performing standard MIPv6 RO signaling on behalf of the MNN/LFN with the CN. The draft [I-D.bernardos-nemo-miron] describes the detailed operation where the MR performs the Return Routability procedure with its own CoA and the MNN address as HoA. Packets protected by IPsec AH between LFN and CN can not be supported in RO mode, but instead have to be routed via the MR-HA tunnel. Bauer, et al. Expires March 13, 2010 [Page 20] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 Packets sent over the RO path use the Type 2 Routing Header and Home Destination Option as specified for RO in [RFC3775]. A.1.2.2. Analysis The basic problem of this approach is the MR acting transparently between MNN and CN and performing the RO as MN from the CN perspective. This can cause problems for security related protocols, as the MR actions can be regarded as man-in-the-middle attacks. This is particularly the case for IPsec AH. Verifying the requirements against this solution approach, we come to the following conclusions: 1. Req1: To be discussed. MR has to be configured with policies and has to perform packet inspection. Whether RO can be specifically triggered for certain flows, depending on the traffic type, remains to be clarified though (esp. wrt IPsec). 2. Req2: Basically fulfilled. The MR could register several CoAs for the MNN with the help of [I-D.draft-ietf-monami6-multiplecoa], although no bulk registration is available in this case. 3. Req3: Fulfilled. Can rely on standard MIPv6 RO; MR-HA tunnel therefore used for as long as RO has not been completed. 4. Req4: Fulfilled. RO is performed with the correspondent node - no additional single-point of failure for communication added. 5. Req5: Fulfilled. As long as the RO path has not been established, packets can be sent over the MR-HA tunnel. 6. Req6: Problematic. Signaling overhead will be per MNN/CoA/home network prefix/CN. BGP not relevant. 7. Req7: Problematic. The signaling for RO is equal to that of standard MIPv6. Several messages and RTTs are needed for every MNN-CN pair for which RO is performed. 8. Req8 #1: To be discussed. While the MNP itself is not part of the RO signaling, the addresses of the individual end systems within the RO signaling is in cleartext. This is also the case for NEMO Basic support though, if no IPsec confidentiality protection is used for user data traffic. 9. Req8 #2: Problematic. If relying on standard MIPv6 RO, MNP/HoA verification can be broken. Bauer, et al. Expires March 13, 2010 [Page 21] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 10. Req9: Problematic. IPsec AH not supported for reverse path from MNN/LFN to CN. This approach allows to use simple LFNs as MNNs, but introduces problems due to the middlebox operation at the MR. Security concerns with respect to the RO procedure itself are existing if standard MIPv6 RO is used. Scalability is similar to the approaches in Appendix A.1.1. A.1.3. MR to CR For this approach, a new mobility entity called Correspondent Router (CR) is introduced. The MR performs RO with the CR that forwards traffic from/to the CN/MNN. A.1.3.1. Proposal(s) The CR approach was first introduced in [I-D.orc] as a possible solution to the NEMO RO problem. Later, a proposal based on the CR idea which specifically targeted the aeronautical requirements has been specified in [I-D.draft-bernardos-mext-nemo-ro-cr]. A third document [I-D.draft-wakikawa-mext-cr-consideration] has then been issued by the main author of [I-D.orc] for discussing possible issues and for providing considerations for the CR protocol. The MR performs a discovery procedure to detect the CR that should be located either 1) on the routing-path to the CN or 2) within the network of the CN where it can announce proxy-routes via an IGP for the MNP(s) of the MR. Once the mobility binding has been established, the CR can intercept traffic (e.g. based on routes advertised via IGP) and tunnel it to the MR. Similarly, in the reverse direction the MR tunnels traffic destined to the prefix(es) served by the CR directly to this router. This is shown in Figure 1. The discovery procedure is a critical part of the overall protocol and while the original document [I-D.orc] did propose a solution, issues related to this approach are discussed in [I-D.draft-bernardos-mext-nemo-ro-cr]. Hence, this topic has to be regarded as work in progress. The authentication of the MNP in [I-D.orc] is achieved by adding a prefix sub-option containing the MNP(s) of the MR to the Home Test Init (HoTI) message. The HA only forwards the message to the CR if the originator of the message (MR) is also the owner of the prefix contained with the HoTI message. CR Discovery is achieved by an ICMP-based mechanism similar to Dynamic Home Agent Address Discovery (DHAAD), based on the Bauer, et al. Expires March 13, 2010 [Page 22] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 Correspondent Nodes 64bit prefix. The operation of a CR is more complicated if it is located in a multihomed site: asymmetric routing could result if the CR serving the MR on the forward path can not ensure to also intercept and foward packets to the MR on the reverse path. +----+ | MR | <--+ +----+ | v +----------------+ | Access Network | +----------------+ ^ | +----------+ | | +----+ | +---|--+ | CN | | | | +----+ | | | ^ | | v | | | +----+ | | | | CR | <--+ | | +----+ | | ANSP Network | +-----------------+ Figure 1: CR-based NEMO RO. A.1.3.2. Analysis The CR approach has both advantages and disadvantages. 1. Req1: To be discussed. MR has to be configured with policies and has to perform packet inspection. Whether RO can be specifically triggered for certain flows, depending on the traffic type, remains to be clarified though (esp. wrt IPsec). 2. Req2: Basically fulfilled. The MR could register several CoAs for its MNP(s) with the help of [I-D.draft-ietf-monami6-multiplecoa], although no bulk registration is available in this case. 3. Req3: Fulfilled. Similar to standard MIPv6 RO; MR-HA tunnel therefore used for as long as RO has not been completed. 4. Req4: To be discussed. The CR itself could be regarded as a new single point of failure, but if CR failure can be detected the Bauer, et al. Expires March 13, 2010 [Page 23] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 MR-HA tunnel could be used again. 5. Req5: Fulfilled. As long as the RO path has not been established, packets can be sent over the MR-HA tunnel. When the MR performs a transition to a new access network and an RO state has been established with the CR, packets will be lost as the CR will send them to the old CoA of the MR. This is also true for NEMO Basic Support though, where the HA will send packets to the old CoA of the MR for as long as the mobility binding has not been updated. 6. Req6: To be discussed. Signaling overhead is per CoA/MNP/CR. BGP not relevant, IGP advertisements and routing table size at the CR grows with the number of registered MNPs though. 7. Req7: To be discussed. CNs within the same network can be served by a single CR, mobility signaling is therefore only performed for new CoAs. The overall signaling overhead is directly related to the distribution of CNs and CRs. An additional overhead is caused by the discovery procedure. 8. Req8 #1: To be discussed. The MNP itself is part of the RO signaling and could be sent in cleartext. 9. Req8 #2: Problematic. If relying on standard MIPv6 RO, MNP/HoA verification can be broken. 10. Req9: Fulfilled. The tunneling between MR and CR preserves inner packet characteristics. An advantage of CR is that RO is scalable wrt the number of CNs as mobility signaling is performed per network or at least per grouped list of prefixes served by the CR (under the assumption that the CNs are located within those prefixes). Another problem is the authentication between MR and CR: [I-D.orc] relies on the standard MIPv6 Return Routability procedure that has security weaknesses. In addition, the authentication of the CR to the MR is not taken into account in the original draft, but has to be considered as a potential threat. A.1.4. MR to HA For this approach a new home network architecture is introduced where Home Agent functionality is shared among a set of instances that is geographically spread. At a given moment, based on the current topological location, the MR uses the closest HA instance. Bauer, et al. Expires March 13, 2010 [Page 24] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 A.1.4.1. Proposal The Global Home Agent to Home Agent protocol [I-D.draft-wakikawa-mext-global-haha-spec] extends the original MIPv6/NEMO model, where only a single HA is available per MN, to an architecture where HAs are geographically distributed. MNs can bind to the closest HA to achieve a certain level of RO. The Home Network relies on advertising a large common prefix via EGP that inflicts anycast routing. The traffic of a CN will be attracted by the topologically closest HA, just as mobility signaling from the MN will always be attracted by the topologically closest HA as well. In the latter case, the closer HA will inform the MNs current primary HA of the suboptimal routing. The primary HA will send a HA switch message that orders the MN to bind with the closer HA, based on signaling specified in [RFC5142]. This way, by reducing the distance between the MR and its HA, a certain degree of RO is achieved. Signaling between HAs is based on [I-D.draft-ietf-mip6-hareliability]. A graphical illustration is shown in Figure 2. +----+ | MR | <-----+ +----+ | v +----------------+ | Access Network | +----------------+ | +------------|------------------+ | | | +----+ +----+ +----+ | | | HA | | HA | | HA | | | +----+ +----+ +----+ | | Mobility | Service Provider | +------------|------------------+ | v +--------------+ | +----+ | | | CN | | | +----+ | | ANSP Network | +--------------+ Figure 2: Global HA to HA. Bauer, et al. Expires March 13, 2010 [Page 25] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 A.1.4.2. Analysis HAHA is significantly different from the other approaches as it does not require any mobility functionality in the CN or within the CN network. Mobility signaling, apart from the MR and its current primary HA, is performed within the various instances of the HAs in the ground network only. 1. Req1: To be discussed. RO is always implicitly provided by switching to a closer HA. Packet inspection at the MR would have to be introduced to identitfy the different flows. This requirement could only be discussed within the context of multihoming extensions, namely [I-D.draft-ietf-monami6-multiplecoa] and [I-D.draft-ietf-mext-flow-binding]. 2. Req2: To be discussed. Given compatability to [I-D.draft-ietf-monami6-multiplecoa] is provided, the MR could register several CoAs for its MNP(s). It is unclear though how the protocol could support simultaneous mobility signaling with two HAs if each one is considered to be close to each respective, active interface at the MR. 3. Req3: Fulfilled. As long as the MR has not registered to the new HA, the old MR-HA tunnel should be preserved. 4. Req4: Fulfilled. HAHA adds availability mechanisms to the home network as it is based on [I-D.draft-ietf-mip6-hareliability]. 5. Req5: Fulfilled. As long as the binding with the new HA has not been completed, packets can be sent over the MR-previous HA tunnel. 6. Req6: To be discussed. Signaling overhead is per CoA/HA. HAHA relies on BGP advertisements to achieve anycast routing. The scale of the advertisements should only be per HA island/anycast prefix and not per MR/MNP. 7. Req7: Fulfilled. Mobility signaling is similar to MIPv6/NEMO and performed per MR and HA. 8. Req8 #1: Fulfilled. No exposure on the wireless link to what already happens for NEMO. 9. Req8 #2: Fulfilled. Security is on the same level as in NEMO. 10. Req9: Fulfilled. The tunneling between MR and HA preserves inner packet characteristics. Bauer, et al. Expires March 13, 2010 [Page 26] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 While the level of RO provided by HAHA is not as good as for the previous approaches, it can help eliminate continental round-trip times in the aviation scenario. A large advantage are the strong security properties as mobility signaling is restricted to the MR and the HA (mobility service provider). A.2. Applicability to the Aeronautical Environment A.2.1. Overview Table 1 provides a summary of the fulfillment of the individual requirements by each solution. Certain requirements turned out to be difficult to assess within the context of the solution - in that case the "D" categorization has been used to indicate that a more detailed investigation is needed on that subject. As can be seen the first two approaches "MNN to CN" and "MR to CN" have problems related to scalability and efficient signaling, as RO signaling is always performed on a per CN basis. The latter, in addition, has problems related to the security (address authentication) and adaptility requirements. The "MNN to CN" approach is mostly interesting from the nesting problem perspective only. The rationale for Requirement 8 - Security (Section 3.8.1 in [I-D.ietf-mext-aero-reqs]) mentions that it is "reasonable to assume trust relationships between each MR and a number of mobility anchor points topologically near to its CNs". The rationale says that this trust relationship equates on having credentials for the authentication of the MNP between the mobility entities (MR, HA, CR). This statement actually rules out all "X to CN" approaches (under the assumption that standard MIPv6 Return Routability signaling should not be accepted due to its security limitations). More promising solutions are the CR and the HAHA protocols and we have therefore focussed on these two approaches in more detail in Section 3. Bauer, et al. Expires March 13, 2010 [Page 27] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 +-------------+-----------+----------+----------+----------+ | Requirement | MNN to CN | MR to CN | MR to CR | MR to HA | +-------------+-----------+----------+----------+----------+ | 1 | F | D | D | D | | | | | | | | 2 | D | F | F | D | | | | | | | | 3 | F | F | F | F | | | | | | | | 4 | F | F | D | F | | | | | | | | 5 | F | F | F | F | | | | | | | | 6 | P | P | D | D | | | | | | | | 7 | P | P | D | F | | | | | | | | 8-1 | D | D | D | F | | | | | | | | 8-2 | P | P | P | F | | | | | | | | 9 | D | P | F | F | +-------------+-----------+----------+----------+----------+ Abbreviations: F... Fulfilled, P... Problematic, D... To be discussed Table 1: Overview of solution characteristics Bauer, et al. Expires March 13, 2010 [Page 28] Internet-Draft Aeronautical NEMO RO Sol. Space September 2009 Authors' Addresses Christian Bauer German Aerospace Center (DLR) Email: Christian.Bauer@dlr.de Serkan Ayaz German Aerospace Center (DLR) Email: Serkan.Ayaz@dlr.de Arnauld Ebalard EADS Innovation Works Email: arnaud.ebalard@eads.net Bauer, et al. Expires March 13, 2010 [Page 29]