--- 1/draft-ietf-dmm-distributed-mobility-anchoring-13.txt 2019-11-01 05:13:39.593347334 -0700 +++ 2/draft-ietf-dmm-distributed-mobility-anchoring-14.txt 2019-11-01 05:13:39.633348347 -0700 @@ -1,24 +1,24 @@ DMM H. Chan, Ed. Internet-Draft X. Wei Intended status: Informational Huawei Technologies -Expires: September 27, 2019 J. Lee +Expires: May 4, 2020 J. Lee Sangmyung University S. Jeon Sungkyunkwan University CJ. Bernardos, Ed. UC3M - March 26, 2019 + November 1, 2019 Distributed Mobility Anchoring - draft-ietf-dmm-distributed-mobility-anchoring-13 + draft-ietf-dmm-distributed-mobility-anchoring-14 Abstract This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support according to the needs of mobility support. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 27, 2019. + This Internet-Draft will expire on May 4, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,45 +68,44 @@ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 5 3.1. Configurations for Different Networks . . . . . . . . . . 5 3.1.1. Network-based DMM . . . . . . . . . . . . . . . . . . 5 3.1.2. Client-based DMM . . . . . . . . . . . . . . . . . . 6 4. IP Mobility Handling in Distributed Anchoring Environments - Mobility Support Only When Needed . . . . . . . . . . . . . . 7 4.1. Nomadic case (no need of IP mobility): Changing to new IP prefix/address . . . . . . . . . . . . . . . . . . . . . 8 4.2. Mobility case, traffic redirection . . . . . . . . . . . 10 - 4.3. Mobility case, anchor relocation . . . . . . . . . . . . 12 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 8.2. Informative References . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.3. Mobility case, anchor relocation . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 8.2. Informative References . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction A key requirement in distributed mobility management [RFC7333] is to enable traffic to avoid traversing a single mobility anchor far from an optimal route. This document defines different configurations, functional operations and parameters for distributed mobility anchoring and explains how to use them to avoid unnecessarily long routes when a mobile node moves. Companion distributed mobility management documents are already addressing the architecture and deployment - [I-D.ietf-dmm-deployment-models], source address selection - [I-D.ietf-dmm-ondemand-mobility], and control-plane data-plane - signaling [I-D.ietf-dmm-fpc-cpdp]. A number of distributed mobility - solutions have also been proposed, for example, in - [I-D.seite-dmm-dma], [I-D.ietf-dmm-pmipv6-dlif], + [I-D.ietf-dmm-deployment-models], source address selection [RFC8653], + and control-plane data-plane signaling [I-D.ietf-dmm-fpc-cpdp]. A + number of distributed mobility solutions have also been proposed, for + example, in [I-D.seite-dmm-dma], [I-D.ietf-dmm-pmipv6-dlif], [I-D.sarikaya-dmm-for-wifi], [I-D.yhkim-dmm-enhanced-anchoring], and [I-D.matsushima-stateless-uplane-vepc]. Distributed mobility anchoring employs multiple anchors in the data plane. In general, control plane functions may be separated from data plane functions and be centralized but may also be co-located with the data plane functions at the distributed anchors. Different configurations of distributed mobility anchoring are described in Section 3.1. @@ -134,20 +133,26 @@ address used by this flow has to be anchored. If the ongoing IP flow can cope with an IP prefix/address change, the flow can be reinitiated with a new IP address anchored in the new network. On the other hand, if the ongoing IP flow cannot cope with such change, mobility support is needed. A network supporting a mix of flows both requiring and not requiring IP mobility support will need to distinguish these flows. 2. Conventions and Terminology + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 (MIPv6) base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) specification [RFC5213], the "Mobility Related Terminologies" [RFC3753], and the DMM current practices and gap analysis [RFC7429]. These include terms such as mobile node (MN), correspondent node (CN), home agent (HA), home address (HoA), care-of-address (CoA), local mobility anchor (LMA), and mobile access gateway (MAG). In addition, this document uses the following terms: @@ -337,23 +343,24 @@ dynamic IP address. It then uses this IP address when a flow is initiated. Packets from this flow addressed to the MN are simply forwarded according to the forwarding table. There may be multiple IP prefixes/addresses that an MN can select when initiating a flow. They may be from the same access network or different access networks. The network may advertise these prefixes with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node may choose the one with the least cost. In addition, these IP prefixes/addresses may be of different types regarding whether - mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A MN - will need to choose which IP prefix/address to use for each flow - according to whether it needs IP mobility support or not. + mobility support is needed [RFC8653]. A MN will need to choose which + IP prefix/address to use for each flow according to whether it needs + IP mobility support or not, using for example the mechanisms + described in [RFC8653]. 4.1. Nomadic case (no need of IP mobility): Changing to new IP prefix/ address When IP mobility support is not needed for a flow, the LM and FM functions are not utilized so that the configurations in Section 3.1 are simplified as shown in Figure 3. Net1 Net2 @@ -401,20 +408,24 @@ An example call flow is outlined in Figure 4. A MN attaches to AR1, which sends a router advertisement (RA) including information about the prefix assigned to MN, from which MN configures an IP address (IP1). This address is used for new communications, for example with a correspondent node (CN). If the MN moves to a new network and attaches to AR2, the process is repeated (MN obtains a new IP address, IP2, from AR2). Since the IP address (IP1) configured at the previously visited network is not valid at the current attachment point, and any existing flows have to be reestablished using IP2. + Note that in this scenarios, if there is no mobility support provided + by L4 or above, an application might be able to stop before changing + point of attachement, and therefore the traffic would stop. + MN AR1 AR2 CN |MN attaches to AR1: | | | |acquires MN-ID and profile | | |--RS---------------->| | | | | | | |<----------RA(IP1)---| | | | | | | Assigned prefix IP1 | | | IP1 address configuration | | | | | | @@ -432,23 +443,23 @@ | | | | |<-new Flow(IP2,IPcn,...)-----------+---------------------------->| | | | | Figure 4: Re-starting a flow with new IP prefix/address 4.2. Mobility case, traffic redirection When IP mobility is needed for a flow, the LM and FM functions in Section 3.1 are utilized. There are two possible cases: (i) the - initial anchor remains the anchor and forwards traffic to a new - locator in the new network, and (ii) the mobility anchor (data plane - function) is changed but binds the MN's transferred IP address/ + mobility anchor remains playing that role and forwards traffic to a + new locator in the new network, and (ii) the mobility anchor (data + plane function) is changed but binds the MN's transferred IP address/ prefix. The latter enables optimized routes but requires some data plane node that enforces rules for traffic indirection. Next, we focus on the first case. The second one is addressed in Section 4.3. Mobility support can be provided by using mobility management methods, such as the several approaches surveyed in the academic papers ([Paper-Distributed.Mobility], [Paper-Distributed.Mobility.PMIP] and [Paper-Distributed.Mobility.Review]). After moving, a certain MN's traffic flow may continue using the IP prefix from the prior network @@ -583,27 +594,48 @@ protocol, but such a solution may present some scalability concerns and its applicability is typically limited to small networks. One example of this type of solution is described in [I-D.ietf-rtgwg-atn-bgp]. When a mobile associates with an anchor the anchor injects the mobile's prefix into the global routing system. If the mobile moves to a new anchor, the old anchor withdraws the /64 and the new anchor injects it instead. 5. Security Considerations - Security protocols and mechanisms are employed to secure the network - and to make continuous security improvements, and a DMM solution is - required to support them [RFC7333]. + As stated in [RFC7333], "a DMM solution MUST supportany security + protocols and mechanisms needed to secure the network and to make + continuous security improvements". It "MUST NOT introduce new + security risks". - In a DMM deployment [I-D.ietf-dmm-deployment-models] various attacks - such as impersonation, denial of service, man-in-the-middle attacks - need to be prevented. + As described in [I-D.ietf-dmm-deployment-models], there are different + potential deployment models of a DMM solution. The present document + has presented 3 different scenarios for distributed anchoring: (i) + nomadic case, (ii) mobility case with traffic redirection, and (iii) + mobility case with anchor relocation. Each of them has different + security requirements, and the actual security mechanisms would + depend on the specifics of each solution/scenario. + + As general rules, for the first distributed anchoring scenario + (nomadic case), no additional security consideration is needed, as + this does not involve any additional mechanism at L3. If session + connectivity is required, the L4 or above solution used to provide it + MUST also provide the required authentication and security. + + The second and third distributed anchoring scenarios (mobility case) + involve mobility signalling among the mobile node and the control and + data plane anchors. The control-plane messages exchanged between + these entitites MUST be protected using end-to-end security + associations with data-integrity and data-origination capabilities. + IPsec ESP in transport mode with mandatory integrity protection + SHOULD be used for protecting the signaling messages. IKEv2 should + be used to set up security associations between the data and control + plane anchors. 6. IANA Considerations This document presents no IANA considerations. 7. Contributors Alexandre Petrescu and Fred Templin had contributed to earlier versions of this document regarding distributed anchoring for hierarchical network and for network mobility, although these @@ -613,30 +645,35 @@ This document has benefited from other work on mobility support in SDN network, on providing mobility support only when needed, and on mobility support in enterprise network. These works have been referenced. While some of these authors have taken the work to jointly write this document, others have contributed at least indirectly by writing these drafts. The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima, Pierrick Seite, Jouni Korhonen, and Sri Gundavelli. Valuable comments have been received from John Kaippallimalil, - ChunShan Xiong, Dapeng Liu and Fred Templin. Dirk von Hugo, Byju - Pularikkal, Pierrick Seite have generously provided careful review - with helpful corrections and suggestions. Marco Liebsch and Lyle - Bertz also performed very detailed and helpful reviews of this - document. + ChunShan Xiong, Dapeng Liu, Fred Templin, Paul Kyzivat, Joseph + Salowey and Yoshifumi Nishida. Dirk von Hugo, Byju Pularikkal, + Pierrick Seite have generously provided careful review with helpful + corrections and suggestions. Marco Liebsch and Lyle Bertz also + performed very detailed and helpful reviews of this document. 8. References 8.1. Normative References + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility @@ -647,49 +684,48 @@ Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 8.2. Informative References [I-D.ietf-dmm-deployment-models] Gundavelli, S. and S. Jeon, "DMM Deployment Models and Architectural Considerations", draft-ietf-dmm-deployment- models-04 (work in progress), May 2018. [I-D.ietf-dmm-fpc-cpdp] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Moses, D., and C. Perkins, "Protocol for Forwarding Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 (work in progress), June 2018. - [I-D.ietf-dmm-ondemand-mobility] - Yegin, A., Moses, D., and S. Jeon, "On Demand Mobility - Management", draft-ietf-dmm-ondemand-mobility-17 (work in - progress), February 2019. - [I-D.ietf-dmm-pmipv6-dlif] Bernardos, C., Oliva, A., Giust, F., Zuniga, J., and A. Mourad, "Proxy Mobile IPv6 extensions for Distributed Mobility Management", draft-ietf-dmm-pmipv6-dlif-04 (work in progress), January 2019. [I-D.ietf-rtgwg-atn-bgp] Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. Moreno, "A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network", draft-ietf- - rtgwg-atn-bgp-01 (work in progress), January 2019. + rtgwg-atn-bgp-02 (work in progress), May 2019. [I-D.matsushima-stateless-uplane-vepc] Matsushima, S. and R. Wakikawa, "Stateless user-plane architecture for virtualized EPC (vEPC)", draft- matsushima-stateless-uplane-vepc-06 (work in progress), March 2016. [I-D.mccann-dmm-prefixcost] McCann, P. and J. Kaippallimalil, "Communicating Prefix Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 @@ -725,21 +761,26 @@ Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, "Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues", February 2011. [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, . + [RFC8653] Yegin, A., Moses, D., and S. Jeon, "On-Demand Mobility + Management", RFC 8653, DOI 10.17487/RFC8653, October 2019, + . + Authors' Addresses + H. Anthony Chan (editor) Huawei Technologies 5340 Legacy Dr. Building 3 Plano, TX 75024 USA Email: h.a.chan@ieee.org Xinpeng Wei Huawei Technologies