INTERNET-DRAFT J. Gao Intended Status: Informational Individual Expires: April 17, 2020 October 15, 2019 Motivations and Design Choices of the Flexible Session Protocol draft-gao-fsp-motivations-02 Abstract This document introduces the motivation to design the Flexible Session Protocol which supports mobility and multihoming at the transport layer. FSP is to avoid the routing scalability problem in the IPv6 internetwork. The document serves to explain choices of design goals of FSP as well. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License 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 (http://trustee.ietf.org/license-info) in effect on the date of Gao Expires April 17, 2020 [Page 1] INTERNET DRAFT Motivations of FSP October 15, 2019 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Mobility and Multihoming Support in the IPv6 Internet . . . 4 2. Survey of Infrastructure-Dependent Mobility Support . . . . . . 4 2.1. Separation of Identifier and Locator . . . . . . . . . . . 5 2.1.1. Host Identity Protocol . . . . . . . . . . . . . . . . 5 2.1.2. Identifier-Locator Network Protocol . . . . . . . . . . 6 2.2.3. The Locator/ID Separation Protocol . . . . . . . . . . 7 2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . . 10 2.2.3. Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . 10 2.2.4. Network Mobility (NEMO) Basic Support Protocol . . . . 11 2.3. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4. DMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Survey of Infrastructure-Independent Mobility Support . . . . . 14 3.1. IKEv2 Mobility and Multihoming Protocol . . . . . . . . . . 14 3.2. Mobile SCTP . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. REST Architecture Style . . . . . . . . . . . . . . . . . . 18 4. A Solution at the Origin of the Problem . . . . . . . . . . . . 20 4.1. Separation of Identity and Locator at Transport Layer . . . 20 4.2. Adding Programmer-Friendly Session Semantics . . . . . . . 20 4.2.1. Intuitiveness . . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Really Parallel Streams . . . . . . . . . . . . . . . . 21 4.2.3. Mixed Traffic Class . . . . . . . . . . . . . . . . . . 21 4.2.4. Session Adjournment and Resumption . . . . . . . . . . 21 4.3. Adding Programmer-friendly Security Service . . . . . . . . 21 4.3.1. Ubiquitous Encryption and Authentication of Data . . . 21 4.3.2. Key Establishment versus Application of Keys . . . . . 22 5. Choices of Design Goals . . . . . . . . . . . . . . . . . . . . 22 5.1. Featured Scenarios . . . . . . . . . . . . . . . . . . . . 22 5.1.1. Goal: Support for Mobile Computing . . . . . . . . . . 22 5.1.2. Goal: Adaptable to Specific-Purpose Networks . . . . . 23 5.1.3. Goal: Adaptable to Constrained-Node Networks . . . . . 23 5.1.4. Non-Goal: General Multicast Transport . . . . . . . . . 24 5.2. Optimizing towards IPv6 . . . . . . . . . . . . . . . . . . 24 Gao Expires April 17, 2020 [Page 2] INTERNET DRAFT Motivations of FSP October 15, 2019 5.2.1. Goal: Promoting Transition towards IPv6 . . . . . . . . 24 5.2.2. Goal: NAT friendliness in IPv4 network . . . . . . . . 24 5.2.3. Non-Goal: NAT friendliness in IPv6 network . . . . . . 24 5.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 24 5.3.1. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 24 5.3.2. Goal: Host-Aggregated Congestion Control . . . . . . . 24 5.3.3. Goal: Congestion Control Per Traffic Class . . . . . . 25 5.3.4. Debatable: TCP Friendliness . . . . . . . . . . . . . . 25 5.4. Infrastructure Independency . . . . . . . . . . . . . . . . 25 5.4.1. Goal: More Efficient Use of the IPv6 Address Space . . 25 5.4.2. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 25 5.4.3. Non-Goal: Inventing New Rendezvous Mechanism . . . . . 25 5.5. Feasibility of Hardware Acceleration . . . . . . . . . . . 26 5.5.1. Goal: Hardware-Accelerated Cryptography . . . . . . . . 26 5.5.2. Goal: Hardware-assisted Header Processing . . . . . . . 26 5.6. QoS and Multipath Issues . . . . . . . . . . . . . . . . . 26 5.6.1. Goal: Minimal Delay Service for Milk Like Payload . . . 26 5.6.2. To be studied: Resource Reservation . . . . . . . . . . 26 5.6.3. To be studied: PMTU Discovery . . . . . . . . . . . . . 27 5.7. On-the-wire Compression . . . . . . . . . . . . . . . . . . 27 5.7.1. Goal: Compatibility with Pre-compression . . . . . . . 27 5.7.2. Goal: Decompression Speed . . . . . . . . . . . . . . . 27 5.7.3. Goal: System Robustness . . . . . . . . . . . . . . . . 27 5.7.4. Non-Goal: Versatility of On-the-Wire Compression . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Gao Expires April 17, 2020 [Page 3] INTERNET DRAFT Motivations of FSP October 15, 2019 1. Introduction The motivation of designing the Flexible Session Protocol, which sits at the transport layer along with TCP [RFC0793], is to provide mobility and multihoming support, thus to make routing scalability problem [RFC4984] in the IPv6 [RFC8200] internetwork thoroughly avoidable. FSP means to be programmer-friendly by adding session semantics in the transport layer and providing security services that is flexible to adapt to new cryptography key establishment algorithm implemented at the application layer. FSP is originally intent to be an alternative of TLS [RFC8446], bundled with TCP, in application scenarios that favor high- performance and strong-security in IPv6 networks with mobility support. FSP can be easily tuned to work well for constrained-node networks [RFC7228]. The document serves to explain some design choices of FSP as well. 1.1. Terminology 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 [RFC2119]. 1.2. Mobility and Multihoming Support in the IPv6 Internet Various solutions exist in the IPv6 Internet that support mobility and/or multihoming. In this documents we survey infrastructure- dependent solutions such as HIP [RFC4423], ILNP [RFC6740], LISP [RFC6830], NEMO [RFC3963], MinimalT [MinimaLT], MIPv6 [RFC6275], PMIPv6 [RFC5213], HMIPv6 [RFC5380] and DMM [RFC7333], and infrastructure-independent solutions such as MOBIKE [RFC4555], Mobile SCTP, MPTCP [RFC7430] and REpresentation State Transfer architecture style [RESTful]. This document draws heavily from earlier RFCs and other references when discusses these known solutions. 2. Survey of Infrastructure-Dependent Mobility Support Various solutions exist in the IPv6 Internet that support mobility and/or multihoming. Infrastructure-dependent proposals that support mobility often require some change of current Internet architecture. Gao Expires April 17, 2020 [Page 4] INTERNET DRAFT Motivations of FSP October 15, 2019 In this documents we surveys infrastructure-dependent solutions such as HIP, ILNP, LISP, NEMO, MinimalT, MIPv6, PMIPv6 and HMIPv6. 2.1. Separation of Identifier and Locator 2.1.1. Host Identity Protocol HIP architecture proposes Host Identity namespace that fills an important gap between the IP and DNS namespaces. The Host Identity namespace consists of Host Identifiers (HIs). A Host Identifier is cryptographic in its nature; it is the public key of an asymmetric key-pair. Each host will have at least one Host Identity, but it will typically have more than one. Each Host Identity uniquely identifies a single host; i.e., no two hosts have the same Host Identity. The Host Identity, and the corresponding Host Identifier, can be either public (e.g., published in the DNS) or unpublished. Client systems will tend to have both public and unpublished Identities. Service ------ Socket Service ------ Socket | | | | | | | | End-point | End-point --- Host Identity \ | | \ | | \ | | \ | | Location --- IP address Location --- IP address Figure 1 New Stack Architecture Presented by HIP HIP decouples the transport from the internetworking layer, and binds the transport associations to the Host Identities. Consequently, HIP can provide for a degree of internetworking mobility and multihoming at a low infrastructure cost. HIP mobility [RFC8046] includes IP address changes (via any method) to either party. HIP links IP addresses together, when multiple IP addresses correspond to the same Host Identity, and if one address becomes unusable, or a more preferred address becomes available, existing transport associations can easily be moved to another address. When a node moves while communication is already ongoing, address changes are rather straightforward. The peer of the mobile node can just accept a HIP or an integrity protected IPsec packet from any address and ignore the source address. Gao Expires April 17, 2020 [Page 5] INTERNET DRAFT Motivations of FSP October 15, 2019 In order to start the HIP exchange, the initiator node has to know how to reach the mobile node. Although infrequently moving HIP nodes could use Dynamic DNS [RFC2136] to update their reachability information in the DNS, an alternative to using DNS in this fashion is to use a piece of new static infrastructure to facilitate rendezvous between HIP nodes. The mobile node keeps the rendezvous infrastructure continuously updated with its current IP address(es). The mobile nodes must trust the rendezvous mechanism to properly maintain their HIT and IP address mappings. The rendezvous mechanism [RFC8004] is also needed if both of the nodes happen to change their address at the same time, either because they are mobile and happen to move at the same time, because one of them is off-line for a while, or because of some other reason. 2.1.2. Identifier-Locator Network Protocol The key idea proposed for ILNP is to directly and specifically change the overloaded semantics of the IP Address. The Internet community has indicated explicitly, several times, that this use of overloaded semantics is a significant problem with the use of the Internet protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984]. ILNP explicitly replaces the use of IP Addresses with two distinct name spaces, each having distinct and different semantics: a) Identifier: a non-topological name for uniquely identifying a node. b) Locator: a topologically bound name for an IP subnetwork. The use of these two new namespaces in comparison to IP is given in Table 1. The table shows where existing names are used for state information in end-systems or protocols. Layer | IP | ILNP ---------------+----------------------+--------------- Application | FQDN or IP Address | FQDN Transport | IP Address | Identifier Network | IP Address | Locator Physical i/f | IP Address | MAC address ---------------+----------------------+--------------- FQDN = Fully Qualified Domain Name i/f = interface MAC = Media Access Control Gao Expires April 17, 2020 [Page 6] INTERNET DRAFT Motivations of FSP October 15, 2019 Table 1: Use of Names for State Information in Various Communication Layers for IP and ILNP ILNP supports mobility directly. Essentially, for ILNP, mobility is implemented by enabling: a) Locator values to be changed dynamically by a node, including for active network-layer sessions. b) use of Locator Updates [RFC6743] to allow active network-layer sessions to be maintained. c) for those hosts that expect incoming network-layer or transport- layer session requests (e.g., servers), updates to the relevant DNS entries for those hosts [RFC6742]. 2.2.3. The Locator/ID Separation Protocol The Locator/Identifier Separation Protocol provides a set of functions for routers to exchange information used to map from Endpoint Identifiers (EIDs) that are not globally routable to routable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across a network infrastructure that uses RLOCs for routing and forwarding. The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically identical to IP addresses; it is the semantics of how they are used that differs. LISP implementations must provide ITRs and ETRs. An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its Gao Expires April 17, 2020 [Page 7] INTERNET DRAFT Motivations of FSP October 15, 2019 globally routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. It requires a index system that stores the mappings between EIDs and RLOCs. The index system may be and usually is large-scale distributed, such as Locator/ID Separation Protocol Alternative Logical Topology [RFC6836], and constitutes the new infrastructure that supports LISP. 2.2. Tunneling 2.2.1. Mobile IPv6 Mobility Support in IPv6, known as Mobile IPv6 or MIPv6, is a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. It allows a mobile node to move from one link to another without changing the mobile node's "home address". Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications. In IPv4 mobility [RFC5944], when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent that resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent that resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the Gao Expires April 17, 2020 [Page 8] INTERNET DRAFT Motivations of FSP October 15, 2019 correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. Mobile IPv6 allows nodes to move within the Internet topology while maintaining reachability and ongoing connections between mobile and correspondent nodes as well. To do this, a mobile node sends binding updates (BUs) to its home agent (HA) every time it moves. The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both from the experiences gained from the development of Mobile IP support in IPv4 (Mobile IPv4), and from the opportunities provided by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, but is integrated into IPv6 and offers many other improvements. The major differences between Mobile IPv4 and Mobile IPv6 is summarized as: o There is no need to deploy special routers as "foreign agents", as in Mobile IPv4. Mobile IPv6 operates in any location without any special support required from the local router. o Support for route optimization is a fundamental part of the protocol, rather than a nonstandard set of extensions. o Mobile IPv6 route optimization can operate securely even without pre-arranged security associations. It is expected that route optimization can be deployed on a global scale between all mobile nodes and correspondent nodes. o Support is also integrated into Mobile IPv6 for allowing route optimization to coexist efficiently with routers that perform "ingress filtering". o The IPv6 Neighbor Unreachability Detection ensures symmetric reachability between the mobile node and its default router in the current location. o Most packets sent to a mobile node while away from home in Mobile IPv6 are sent using an IPv6 routing header rather than IP encapsulation, reducing the amount of resulting overhead compared to Mobile IPv4. o Mobile IPv6 is decoupled from any particular link layer, as it uses IPv6 Neighbor Discovery [RFC4861] instead of the Address Resolution Protocol (ARP). This also improves the robustness of the protocol. o The use of IPv6 encapsulation (and the routing header) removes the need in Mobile IPv6 to manage "tunnel soft state". Gao Expires April 17, 2020 [Page 9] INTERNET DRAFT Motivations of FSP October 15, 2019 o The dynamic home agent address discovery mechanism in Mobile IPv6 returns a single reply to the mobile node. The directed broadcast approach used in IPv4 returns separate replies from each home agent. 2.2.2. Proxy Mobile IPv6 It is possible to support mobility for IPv6 nodes without host involvement by extending Mobile IPv6 signaling messages between a network node and a home agent. This approach to supporting mobility does not require the mobile node to be involved in the exchange of signaling messages between itself and the home agent. A proxy mobility agent in the network performs the signaling with the home agent and does the mobility management on behalf of the mobile node attached to the network. Because of the use and extension of Mobile IPv6 signaling and home agent functionality, this protocol is referred to as Proxy Mobile IPv6 (PMIPv6). The Mobile Access Gateway (MAG) is such a proxy function on an access router. MAG manages the mobility-related signaling for a mobile node that is attached to its access link. It is responsible for tracking the mobile node's movements to and from the access link and for signaling the mobile node's local mobility anchor. IP mobility for nodes that have mobile IP client functionality in the IPv6 stack as well as those nodes that do not, would be supported by enabling Proxy Mobile IPv6 protocol functionality in the network. The advantages of developing a network-based mobility protocol based on Mobile IPv6 are: o Reuse of home agent functionality and the messages/format used in mobility signaling. Mobile IPv6 is a mature protocol with several implementations that have undergone interoperability testing. o A common home agent would serve as the mobility agent for all types of IPv6 nodes. 2.2.3. Hierarchical Mobile IPv6 Hierarchical Mobile IPv6 (HMIPv6) mobility management specification [RFC5380] introduces the concept of a hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP). MAP can be located at any level in a hierarchical network of routers, including the Access Router (AR). The MAP will limit the amount of Mobile IPv6 signaling outside the local domain. The introduction of the MAP provides a solution that has these Gao Expires April 17, 2020 [Page 10] INTERNET DRAFT Motivations of FSP October 15, 2019 benefits: o The mobile node sends binding updates to the local MAP rather than the home agent (HA) (which is typically further away) and correspondent nodes (CNs). It mitigates delays caused by MIPv6 signaling. o Only one binding update message needs to be transmitted by the mobile node (MN) before traffic from the HA and all CNs is re- routed to its new location. This is independent of the number of CNs with which the MN is communicating. It mitigates the tunneling burden on the home agent and alleviates the scalability problem. A MAP is essentially a local home agent. The aim of introducing the hierarchical mobility management model in Mobile IPv6 is to enhance the performance of Mobile IPv6 while minimising the impact on Mobile IPv6 or other IPv6 protocols. It is pertinent to note that the use of the MAP does not rely on, or assume the presence of, a permanent home agent. In other words, a mobile node need not have a permanent home address or home agent in order to be HMIPv6-aware or use the features of HMIPv6. A MAP may be used by a mobile node in a nomadic manner to achieve mobility management within a local domain. 2.2.4. Network Mobility (NEMO) Basic Support Protocol Network Mobility (NEMO) Basic Support Protocol is protocol extensions to Mobile IPv6 (MIPv6) to enable support for network mobility. The extensions are backward compatible with Mobile IPv6. In particular, a NEMO-compliant Home Agent can operate as a Mobile IPv6 Home Agent. The NEMO Basic Support ensures session continuity for all the nodes in the Mobile Network, even as the Mobile Router changes its point of attachment to the Internet. It also provides connectivity and reachability for all nodes in the Mobile Network as it moves. The solution supports both mobile nodes and hosts that do not support mobility in the Mobile Network. The solution proposes a bi-directional tunnel between the Mobile Router and its Home Agent. This tunnel is set up when the Mobile Router sends a successful Binding Update to its Home Agent, informing the Home Agent of its current point of attachment. All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. The solution described here does not place any restriction on the number of levels for nested mobility. But note that nested mobility Gao Expires April 17, 2020 [Page 11] INTERNET DRAFT Motivations of FSP October 15, 2019 might introduce significant overhead on the data packets as each level of nesting introduces another IPv6 header encapsulation. Multihoming for Mobile Routers was not discussed in NEMO Basic Support. 2.3. MinimalT Minimal Latency Tunneling [MinimaLT] is a network protocol that provides ubiquitous encryption for maximal confidentiality, including protecting packet headers. MinimaLT provides server and user authentication, extensive Denial-of-Service protections, and IP mobility while approaching perfect forward secrecy. A MinimaLT tunnel is a point-to-point entity that encapsulates the set of connections between two hosts. MinimaLT creates a tunnel on demand in response to the first packet received from a host or a local application's outgoing connection request. Tunnels provide server authentication, encryption, congestion control, and reliability. A MinimaLT tunnel contains a set of connections, that is, a single tunnel between two hosts encapsulates an arbitrary number of connections. Each connection is user-authenticated and provides two- way communication between a client application and service. MinimaLT identifies tunnels by their TID, the TID is pseudorandomly generated by the initiator. A tunnel's IP and UDP port can change without affecting communication. After changing its IP address or UDP port, a host simply assumes the next TID as with a rekey. The other host will recognize the new TID and will transition the tunnel to the new key, IP address, and UDP port. Central to the protocol is the MinimaLT directory service. The directory service resolves queries for (server) hostname information. It provides the server's directory certificate, signed by the server's long-term key. This returned certificate contains the server's IP address, UDP port, long-term key, zero padding (the minimum payload size of the initial packet), and a server ephemeral key. As MinimalT requires new directory service provided by the network infrastructure it is classified as infrastructure-dependent. 2.4. DMM Requirements for DMM reveals that the background behind the interest in studying DMM is primarily as follows. Gao Expires April 17, 2020 [Page 12] INTERNET DRAFT Motivations of FSP October 15, 2019 (1) More than ever, mobile users are consuming Internet content, including that of local Content Delivery Networks (CDNs). Such traffic imposes new requirements on mobile core networks for data traffic delivery. Both traffic offloading and CDN mechanisms could benefit from the development of mobile architectures with fewer hierarchical levels introduced into the data path by the mobility management system. This trend of "flattening" the mobile networks works best for direct communications among peers in the same geographical area. Distributed mobility management in the flattening mobile networks would anchor the traffic closer to the point of attachment of the user. (2) Today's mobile networks present service providers with new challenges. Mobility patterns indicate that mobile nodes often remain attached to the same point of attachment for considerable periods of time [LOCATING-USER]. Specific IP mobility management support is not required for applications that launch and complete their sessions while the mobile node is connected to the same point of attachment. However, IP mobility support is currently designed for always-on operation, maintaining all parameters of the context for each mobile subscriber for as long as they are connected to the network. This can result in a waste of resources and unnecessary costs for the service provider. Infrequent node mobility coupled with application intelligence suggest that mobility support could be provided selectively, thus reducing the amount of context maintained in the network. In centralized mobility management such as MIPv6, PMIPv6 or HMIPv6, the location information in terms of a mapping between the session identifier and the forwarding address is kept at a single mobility anchor, and packets destined to the session identifier are forwarded via this anchor. In other words, such mobility management systems are centralized in both the control plane and the data plane (mobile node IP traffic). The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 are the following: 1. Anchoring Function (AF): allocation to a mobile node of an IP address, i.e., Home Address (HoA), or prefix, i.e., Home Network Prefix (HNP), topologically anchored by the advertising node. That is, the anchor node is able to advertise a connected route into the routing infrastructure for the allocated IP prefixes. This function is a control-plane function. Gao Expires April 17, 2020 [Page 13] INTERNET DRAFT Motivations of FSP October 15, 2019 2. Internetwork Location Management (LM) function: managing and keeping track of the internetwork location of an MN. It is a control-plane function. The location information may be a binding of the advertised IP address/prefix, e.g., HoA or HNP, to the IP routing address of the MN, or it may be a binding of a node that can forward packets destined to the MN. In a client-server protocol model, location query and update messages may be exchanged between a Location Management client (LMc) and a Location Management server (LMs). 3. Forwarding Management (FM) function: packet interception and forwarding to/from the IP address/prefix assigned to the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination. FM may optionally be split into the control plane (FM-CP) and data plane (FM-DP). In Mobile IPv6, the home agent (HA) typically provides the AF; the LMs is at the HA, whereas the LMc is at the MN; the FM function is distributed between the ends of the tunnel at the HA and the MN. In Proxy Mobile IPv6, the local mobility anchor (LMA) provides the AF; the LMs is at the LMA, whereas the LMc is at the MAG; the FM function is distributed between the ends of the tunnel at the LMA and the MAG. In HMIPv6, the Mobility Anchor Point (MAP) serves as a location information aggregator between the LMs at the HA and the LMc at the MN. The MAP also provides the FM function to enable tunneling between HA and itself, as well as tunneling between the MN and itself. Requirements for Distributed Mobility Management [RFC7333] states that distributed mobility management (DMM) is an alternative to the centralized deployment of the location information. While DMM does add scalability to mobile management tremendously it requires substantial infrastructure enhancement to be effective. 3. Survey of Infrastructure-Independent Mobility Support 3.1. IKEv2 Mobility and Multihoming Protocol Gao Expires April 17, 2020 [Page 14] INTERNET DRAFT Motivations of FSP October 15, 2019 IKEv2 [RFC7296] is used for performing mutual authentication, as well as establishing and maintaining IPsec Security Associations (SAs). In the base IKEv2 protocol, the IKE SAs and tunnel mode IPsec SAs are created implicitly between the IP addresses that are used when the IKE_SA is established. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPsec packets. There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason. The MOBIKE protocol provides a mechanism for updating the IP addresses of existing IKE and IPsec SAs is needed. MOBIKE allows both parties to have several addresses, and there are up to N*M pairs of IP addresses that could potentially be used. The party that initiated the IKE_SA is responsible for deciding which address pair is used for the IPsec SAs and for collecting the information it needs to make this decision (such as determining which address pairs work or do not work). The other party simply tells the initiator what addresses it has, but does not update the IPsec SAs until it receives a message from the initiator to do so. This approach applies to the addresses in the IPsec SAs; in the IKE_SA case, the exchange initiator can decide which addresses are used. In MOBIKE, the initiator decides what addresses are used in the IPsec SAs. That is, the responder does not normally update any IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request from the initiator. The responder can, however, update the IKE_SA in some circumstances. Assumes that the initiator has already decided what the new addresses should be. When this decision has been made, the initiator: o Updates the IKE_SA with the new addresses, and sets the "pending_update" flag in the IKE_SA. o Updates the IPsec SAs associated with this IKE_SA with the new addresses (unless the initiator's policy requires a return routability check before updating the IPsec SAs, and the check has not been done for this responder address yet). o If the IPsec SAs were updated in the previous step: If NAT Traversal is not enabled, and the responder supports NAT Traversal, and the initiator either suspects or knows that a NAT is likely to be present, enables NAT Traversal. Gao Expires April 17, 2020 [Page 15] INTERNET DRAFT Motivations of FSP October 15, 2019 o If there are outstanding IKEv2 requests (requests for which the initiator has not yet received a reply), continues retransmitting them using the addresses in the IKE_SA (the new addresses). o When the window size allows, sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification (which does not contain any data), and clears the "pending_update" flag. o If a new address change occurs while waiting for the response, starts again from the first step (and ignores responses to this UPDATE_SA_ADDRESSES request). When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder: o Determines whether it has already received a newer UPDATE_SA_ADDRESSES request than this one. If it has, a normal response message is sent, but no other action is taken. o Checks that the (source IP address, destination IP address) pair in the IP header is acceptable according to local policy. If it is not, replies with a message containing the UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). o Updates the IP addresses in the IKE_SA with the values from the IP header. o Replies with an INFORMATIONAL response. o If necessary, initiates a return routability check for the new initiator address and waits until the check is completed. o Updates the IPsec SAs associated with this IKE_SA with the new addresses. o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. When the initiator receives the reply: o If an address change has occurred after the request was firs sent, no MOBIKE processing is done for the reply message because a new UPDATE_SA_ADDRESSES is going to be sent (or has already been sent, if window size greater than one is in use). o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, keep on using the previously used addresses, or disconnect. Gao Expires April 17, 2020 [Page 16] INTERNET DRAFT Motivations of FSP October 15, 2019 o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done earlier before sending the request; this is the case when no return routability check was required). o If NAT Traversal is supported and NAT detection payloads were included, the initiator enables or disables NAT Traversal. 3.2. Mobile SCTP A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. However, many modern computers allow for the dynamic addition and deletion of network cards (sometimes termed a hot-pluggable interface). Complicate this with the ability of a provider, in IPv6, to dynamically renumber a network, and there still is a gap between full-fault tolerance and the currently defined SCTP protocol. No matter if a card is added or an interface is renumbered, in order to take advantage of this new configuration, the transport association must be restarted. For many fault-tolerant applications this restart is considered an outage and is undesirable. Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration [RFC4960] [RFC5061] is an extension to SCTP to attempt to correct this problem for the more demanding fault-tolerant application. This extension will allow an SCTP stack to: o Dynamically add an IP address to an association. o Dynamically delete an IP address from an association. o Request to set the primary address the peer will use when sending to an endpoint. The dynamic addition and subtraction of IP addresses allows an SCTP association to continue to function through host and network reconfigurations. These changes, brought on by provider or user action, may mean that the peer would be better served by using the newly added address; however, this information may only be known by] the endpoint that had the reconfiguration occur. In such a case this extension allows the local endpoint to advise the peer as to what it thinks is the better primary address that the peer should be using. One last thing this extension adds is a small, 32-bit integer called an adaptation indication that can be exchanged at startup. This is Gao Expires April 17, 2020 [Page 17] INTERNET DRAFT Motivations of FSP October 15, 2019 useful for applications where there are one or more specific layers below the application, yet still above SCTP. In such a case, the exchange of this indication can allow the proper layer to be enabled below the application. 3.3. Multipath TCP Seamless TCP mobility using lightweight MPTCP proxy [HAMPEL] utilizes Multipath TCP (MPTCP) [RFC6824] to implement a TCP mobility solution. However, Analysis of Residual Threats and Possible Fixes for Multipath TCP found some security issues such as ADD_ADDR attack. Hence inherent security of MPTCP is rather doubtful. 3.4. REST Architecture Style REST stands for "Representational State Transfer" [RESTful]. The name is intended to evoke an image of how a well-designed Web application behaves: a network of Web pages forms a virtual state machine, allowing a user to progress through the application by selecting a link or submitting a short data-entry form, with each action resulting in a transition to the next state of the application by transferring a representation of that state to the user. The REST architectural style consists of a set of architectural constraints chosen for the properties they induce on candidate architectures. For purpose of discussing mobility support we note that the first constraints added to the hybrid style are those of the client-server architectural style (CS). Separation of concerns is the principle behind the client-server constraints. CS style is closely followed by the client-stateless-server (CSS) style, such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. Communication must be stateless in nature. It is observable that REST architecture style, or RESTful pattern provides some degree of mobility support at the application layer. There are abundant Web applications that rely on HTTP which are built upon RESTful pattern. The Hypertext Transfer Protocol (HTTP) [RFC1945] [RFC7230] [RFC7540] is a request/response protocol. A client sends a request containing request headers that specify the request method, URI, HTTP version, information about the client, some additional information about the request, and optional application data. The server responds with a status or error code followed by a message containing information about the server and information about the data. This may include a message body. Gao Expires April 17, 2020 [Page 18] INTERNET DRAFT Motivations of FSP October 15, 2019 The browser that accesses the Web application built upon RESTful pattern may change its transport layer address freely, not to mention IP address, provided that each request from the browser contains all of the information necessary to understand the request and the browser can resolve the latest address of the server, as the communication is stateless in nature if it obeys RESTful pattern. Thus we conclude that REST architecture style inherently provides mobility support. Gao Expires April 17, 2020 [Page 19] INTERNET DRAFT Motivations of FSP October 15, 2019 4. A Solution at the Origin of the Problem 4.1. Separation of Identity and Locator at Transport Layer Why we design a new transport protocol to solve the routing scalability problem while provide mobility and multihoming support? Because it is the dominating transport layer protocols, TCP and UDP that take use of the IP address to identifying the end node, introduce the controversial role of IP address both as the identifier and as the routing locator. FSP is meant to be transport layer protocol that keeps the IP address as the routing locator but keeps it from being the key constituent of the FSP identifier or any upper layer protocol built upon FSP. It is a solution to avoid, if not to extirpate, the routing scalability problem. 4.2. Adding Programmer-Friendly Session Semantics It is hard to achieve the goal of making a new transport protocol accepted by the programmers. The service provided by the transport protocol should have some 'killer' features. FSP assumes that session semantics is such a feature. Here we define a session is a bundle of connections or streams that share the same authentication and authorization context. 4.2.1. Intuitiveness This concept is inspired by HTTP persistent connection. The persistent connections of HTTP 1.1 [RFC7230] and HTTP 2.0 [RFC7540] allow multiple request/response transactions (streams) during the lifetime of a single HTTP connection. This reduces overhead during connection establishment and mitigates transport-layer slow-start that would have otherwise been incurred for each transaction. HTTP 2.0 connections can multiplex many request/response pairs in parallel on a single transport connection. Both are important to reduce latency for HTTP's primary use case. These multiple request/response pairs, or streams in parallel, constitute a session. Usually they share the same authentication and authorization context. From a programmer's point of view they constitute a session. It is much more intuitive (and more efficient) than to save the user authentication and authorization state in some representation form at the client side and transfer the state in representation form along with each request to the server side for authorization purpose. Gao Expires April 17, 2020 [Page 20] INTERNET DRAFT Motivations of FSP October 15, 2019 4.2.2. Really Parallel Streams There is head-of-line congestion in HTTP persistent connection. Such head-of-line congestion is anti-intuitive and should be avoided. Connection Multiplication mechanism is meant to solve such head-of- line congestion problem. Connection multiplication makes a branch connection reuse the security context of the master connection and makes the new connection established in zero round trip. As per [RFC8108] an endpoint may send multiple RTP streams in a single RTP session. FSP is meant to cover such requirement as well. 4.2.3. Mixed Traffic Class A real world application may consist mixed traffic classes of streams, for example one control stream which does not tolerate packet loss, and a bundle of streams that carry payloads favoring low-latency while tolerating packet loss. All these streams belong to the same session in the sense of same user authentication and authorization context. 4.2.4. Session Adjournment and Resumption It is not uncommon for an application to exploit TCP as the transport protocol, and as TCP transmits the application data as an unbroken stream of octets it is at the application layer to delimiter the messages that are sent continually. It would be convenient if the application data could still be sent in stream mode and the transport service provides the 'commit' programming interface, through which the application can explicitly set the transmission check point where further sending of data is prohibited until all of the data sent have been acknowledged at the transport layer. It is considered a weak, asymmetric, yet essential requirement for session adjournment and resumption. FSP provides Transmit Transaction mechanism to fulfill such requirement. 4.3. Adding Programmer-friendly Security Service 4.3.1. Ubiquitous Encryption and Authentication of Data As revealed in "Datagram Transport Layer Security" (DTLS) [RFC6347] even client/server applications that takes use of UDP needs to communicate in a way that manages to prevent eavesdropping, tampering, or message forgery. Transport layer protocol should provide inherent support for ubiquitous encryption and/or Gao Expires April 17, 2020 [Page 21] INTERNET DRAFT Motivations of FSP October 15, 2019 authentication of data. 4.3.2. Key Establishment versus Application of Keys IPsec architecture [RFC4301] clearly separates the sub-protocol for key establishment through Internet Key Exchange (IKE) [RFC7296], and the sub-protocol for applying the established key through the Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303]. However, as the mechanism of security association (SA) is stateful it is not convenient to solve the problems at the IP layer which should better be stateless for sake of scalability. Besides, as the IP layer services are often implemented in the kernel of the operating systems the extensibility is limited, but various classes of applications often require variable key establishment process that could be directly managed by the end-node application. It would be convenient if the key established at the application layer could be applied at the transport layer to encrypt the payload with authentication. 5. Choices of Design Goals 5.1. Featured Scenarios 5.1.1. Goal: Support for Mobile Computing As stated in 'Report from the IAB Workshop on Routing and Addressing', September 2007 [RFC4984], 'The workshop participants recognized that the increase in the number of mobile devices can be significant, and that if a scalable routing system supporting generic identity-locator separation were developed and introduced, billions of mobile gadgets could be supported without bringing undue impact on global routing scalability and stability'. FSP can be implemented in the user-space of the operating systems. It is technically feasible to deploy FSP-dependent applications as the Software-as-a-Service [SaaS] on the public cloud computing platform and distribute the FSP-enabled client applications that act as the agents of the SaaS platform through some online application store to serve more than ever mobile users. It has high probability of earning economical benefit to deploy such solution because FSP consume considerably less computing resource than TLS over TCP or DTLS over UDP. Unlike the help desks of the enterprise networks the public cloud Gao Expires April 17, 2020 [Page 22] INTERNET DRAFT Motivations of FSP October 15, 2019 service providers and the wireless communication service providers can be much more tolerant with the new transport protocol. 5.1.2. Goal: Adaptable to Specific-Purpose Networks Here specific-purpose networks mean those networks that dedicatedly serve for some special purpose, such as Storage Area Network (SAN) at which Internet Small Computer Systems Interface (iSCSI) [RFC7143] is targeted. Such specific-purpose networks often favor high performance over privacy. It may find it is overkill to utilize FSP. However in such scenario the weak integrity protection mode that utilize CRC64 [CRC64] may be exploited, where CRC64 calculation may be implemented in commoditized hardware. High-performance software implementation exists as well. And it should be feasible to realize FSP directly over layer 2 jumbogram packet switch network in some specific-purpose network such as at the data center of the cloud service provider. It should be feasibility to exploit hardware acceleration for FSP in the specific-purpose networks. 5.1.3. Goal: Adaptable to Constrained-Node Networks As defined in [RFC7228], a constrained-node network is a network whose characteristics are influenced by being composed of a significant portion of constrained nodes. A constrained-node network always is a constrained network because of the network constraints stemming from the node constraints. In the constrained network some of the characteristics pretty much taken for granted with link layers in common use in the Internet at the time of writing are not attainable, such as in the LLN (as described in Terms Used in Routing for Low-Power and Lossy Networks [RFC7102]). It is observed that key establishment almost always consumes much more CPU power and/or RAM resource than data encryption/decryption that applying the key, per octet transmitted in the network. FSP is designed to support persistent session, where it is possible to establish the connection securely between the constrained node and its more powerful peer during the provisioning phase, and keep the connection secure with the automatic re-keying mechanism, while the upper layer application is able to do transactional works by exploiting transmit transaction mechanism provided by FSP. The session key to be established may even be negotiated with some additional hardware acceleration attached to the constrained node at Gao Expires April 17, 2020 [Page 23] INTERNET DRAFT Motivations of FSP October 15, 2019 the provision phase. 5.1.4. Non-Goal: General Multicast Transport Although there is some trace of supporting 'duplicate-cast' which means sending to two, at most three receivers in design of FSP, Duplication-cast Extensibility is yet to be studied. General multicast support is simply non-goal. 5.2. Optimizing towards IPv6 5.2.1. Goal: Promoting Transition towards IPv6 FSP is intent on promoting IPv6 for sake of transparent end-to-end connectivity. 5.2.2. Goal: NAT friendliness in IPv4 network Network Address Translation and Port Translation (NAPT) [RFC2663] works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. It is mandatory for FSP to keep NAT-friendliness in the IPv4 internetwork because NAT middleboxes are ubiquitous. 5.2.3. Non-Goal: NAT friendliness in IPv6 network It is both feasible and preferable to avoid NAT in the IPv6 internetwork for sake of transparent end-to-end connectivity. 5.3. Congestion Control 5.3.1. Goal: ECN Awareness The Benefits of Using Explicit Congestion Notification (ECN) [RFC8087] outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. FSP should take advantages of ECN [RFC3168]. 5.3.2. Goal: Host-Aggregated Congestion Control We argue that congestion control should be end-to-end at the network layer instead of transport layer. All traffic between two network nodes shall be subjected aggregately to the congestion control. Gao Expires April 17, 2020 [Page 24] INTERNET DRAFT Motivations of FSP October 15, 2019 5.3.3. Goal: Congestion Control Per Traffic Class As it is a designed feature for FSP to carry mixed traffic class in one session, but there is no single congestion control mechanism will work for all traffic classes, it would be convenient that different traffic class is treated with different congestion control mechanism. 5.3.4. Debatable: TCP Friendliness It is observable that traffics such as multi-thread downloading or video-streaming over RTP [RFC3550] that manage to avoid TCP congestion control are overwhelmingly increasing. It might be too conservative to keep up with such application trends to obey with TCP-friendliness. 5.4. Infrastructure Independency FSP does not introduce any new namespace, nor does it depend on new network infrastructure. However it does make some assumption about the network layer infrastructure. 5.4.1. Goal: More Efficient Use of the IPv6 Address Space The length of an IPv6 address is 128 bits. Practices of IPv6 NAPT show that address space of 48 bits is sufficient. There could be optimization space for more efficient use of the IPv6 address space. o Every IPv6 network node is effectively a router And it could be argued that this opinion is implicitly supported by "Unique IPv6 Prefix per Host" [RFC8273]. o The upper layer application is the ultimate IPv6 end-point Again, it could be argued that this opinion is implicitly supported by "Unique IPv6 Prefix per Host". 5.4.2. Goal: ECN Awareness FSP should take advantages of ECN, which is a network infrastructure mechanism. 5.4.3. Non-Goal: Inventing New Rendezvous Mechanism FSP should take advantages of Dynamic DNS [RFC2136] to provide rendezvous mechanism in case that the two participants change their IP addresses simultaneously. It does not intent to re-invent the wheel. Gao Expires April 17, 2020 [Page 25] INTERNET DRAFT Motivations of FSP October 15, 2019 5.5. Feasibility of Hardware Acceleration 5.5.1. Goal: Hardware-Accelerated Cryptography Hardware implementation efficiency and popularity shall be the most important factors of selecting the data integrity and confidentiality protection algorithm. First version of FSP exploits AES-GCM [AES][GCM], liking in The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) [RFC4106]. Here it is explicitly proposed that the upper layer application should take care of key establishment, and install the key established onto the FSP layer, alike to the Use of Channel Bindings to Secure Channels [RFC5056]. Reason behind the proposal is alike to channel binding as well: 'the main goal of channel binding is to be able to delegate cryptographic session protection to network layers below the application in hopes of being able to better leverage hardware implementations of cryptographic protocols'. 5.5.2. Goal: Hardware-assisted Header Processing FSP chooses to design fixed-size header for normal packet that imitates Reduced Instruction Set Computer (RISC) instructions that are easier to process in hardware. 5.6. QoS and Multipath Issues 5.6.1. Goal: Minimal Delay Service for Milk Like Payload An ordinary data flow is wine-like in the sense that the older data are more valuable. If it has to, data packet sent latest are dropped first. In the contrary, milk-like payload is that the newer data are more precious and outdated data packet can be discarded. FSP is designed to support mixed traffic class that providing service both for wine-like payload and milk-like payload. 5.6.2. To be studied: Resource Reservation End-to-End resource reservation protocol packets MAY be piggybacked on the preliminary FSP packets that are exchanged in the connection establishment process to provide guaranteed quality of service. However as resource reservation [RFC2205] requires that the network layer nodes along the path that the protocol packets have passed to keep some state, the scalability is questionable. Gao Expires April 17, 2020 [Page 26] INTERNET DRAFT Motivations of FSP October 15, 2019 However, since resource reservation may assure higher quality of service, future version of FSP should be capable of reserving resource along the network path in the connection establishment process, at least for some special purpose network. 5.6.3. To be studied: PMTU Discovery For sake of maximizing mobility and multi-path support it is not required to implement Packetization Layer Path MTU Discovery [RFC4821] for FSP. PMTU may be discovered together with resource reservation in the future. 5.7. On-the-wire Compression Because lots of content is compressible and compression saves bandwidth, it is proposed that FSP shall support on-the-wire compression. LZ4 algorithm is chosen for it "features extremely fast decoder" [LZ4]. Few well-known loss-less compression algorithm has higher performance than LZ4 (in according to [LZTURBO]) in terms of decompression speed. The apparent one exception, LzTurbo, has not yet open-sourced. Besides, LZ4 offers a high compression derivative called LZ4_HC that shares the same "extremely fast decoder" with the default compressor. It is possible to pre-compress some content with LZ4_HC and serve it to mass client, while each client decodes and gets the original content with on-the-wire speed. 5.7.1. Goal: Compatibility with Pre-compression From the sender side of view lots of content is pre-determined and pre-compressible. It would be welcomed if the on-the-wire compression algorithm chosen offers a high compression branch that share the same on-the-wire speed decoder with the on-the-wire encoder. 5.7.2. Goal: Decompression Speed The decoder should run as fast as possible. 5.7.3. Goal: System Robustness From the receiver point of view decompression may consume unpredictable amount of memory resource. On-the-wire compression service SHOULD be provided in the user space for sake of system Gao Expires April 17, 2020 [Page 27] INTERNET DRAFT Motivations of FSP October 15, 2019 robustness. And the decoder should consume memory resource less than the amount reasonably provided by a constrained node. 5.7.4. Non-Goal: Versatility of On-the-Wire Compression Speed should take precedence over compression ratio on selecting the on-the-wire compression algorithm for FSP. 6. Security Considerations FSP MUST provide mechanism to fight against connection hi-jack attack. FSP SHALL provide data encryption and decryption mechanism to protect confidentiality of the payload For sake of performance FSP chooses symmetric-key algorithm to achieve the goal. In the first version of FSP slightly modified AEAD_AES_128_GCM or AEAD_AES_256_GCM [RFC5116] is applied. FSP SHALL provide data integrity protection mechanism. In the first version Authenticated Encryption with Associated Data [R02] algorithm AES-GCM is applied to protect integrity of each FSP packet, unless the upper layer application explicitly relaxes the requirement. FSP does not intend to provide full-fledged cryptography support. Easy of use with reasonable flexibility takes precedence. It is explicitly proposed that the upper layer application should take care of key establishment, and install the key established onto the FSP layer. 7. IANA Considerations This document has no actions for IANA. 8. References 8.1. Normative References [MinimaLT] W. Michael Petullo, Xu Zhang, Jon A. Solworth, Daniel J. Bernstein, Tanja Lange. MinimaLT: Minimal-latency networking through better security, October 2013, [R02] Rogaway, P., "Authenticated encryption with Associated- Data", ACM Conference on Computer and Communication Gao Expires April 17, 2020 [Page 28] INTERNET DRAFT Motivations of FSP October 15, 2019 Security (CCS'02), pp. 98-107, ACM Press, 2002, . [RESTful] Fielding R. T. and R. N. Taylor, "Principled Design of the Modern Web Architecture", International Conference on Software Engineering, 2000: 407-416. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 2006, . [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, . Gao Expires April 17, 2020 [Page 29] INTERNET DRAFT Motivations of FSP October 15, 2019 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, . [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, . Gao Expires April 17, 2020 [Page 30] INTERNET DRAFT Motivations of FSP October 15, 2019 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 8.2. Informative References [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape Cartridges - DLT1 Format Standard, Annex B", ECMA-182, December 1992. [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", November 2007. [HAMPEL] Hampel, G., Rana, A., and T. Klein, "Seamless TCP mobility using lightweight MPTCP proxy", MobiWac '13: Proceedings of the 11th ACM international symposium on Mobility management and wireless access, DOI 10.1145/2508222.2508226, November 2013. [LOCATING-USER] Kirby, G., "Locating the User", Communications International, 1995. [LZ4] https://lz4.github.io/lz4/ Gao Expires April 17, 2020 [Page 31] INTERNET DRAFT Motivations of FSP October 15, 2019 [LZTURBO] https://github.com/powturbo/TurboBench [SaaS] Peter, M. and G. Tim, "The NIST Definition of Cloud Computing", SP 800-145, September 2011, [RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, DOI 10.17487/RFC1498, August 1993, . [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996, . [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101, February 1997, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", RFC 2956, DOI 10.17487/RFC2956, October 2000, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote Direct Memory Access (RDMA) over IP Problem Statement", RFC 4297, DOI 10.17487/RFC4297, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI Gao Expires April 17, 2020 [Page 32] INTERNET DRAFT Motivations of FSP October 15, 2019 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, . [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, . [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . Gao Expires April 17, 2020 [Page 33] INTERNET DRAFT Motivations of FSP October 15, 2019 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, . [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, . [RFC5889] Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, . [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011, . [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 10.17487/RFC6250, May 2011, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, DOI 10.17487/RFC6741, November 2012, . [RFC6742] RJ Atkinson, SN Bhatti, and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, DOI 10.17487/RFC6742, November 2012, . Gao Expires April 17, 2020 [Page 34] INTERNET DRAFT Motivations of FSP October 15, 2019 [RFC6743] RJ Atkinson and SN Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6743, DOI 10.17487/RFC6743, November 2012, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, . [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, . [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, Gao Expires April 17, 2020 [Page 35] INTERNET DRAFT Motivations of FSP October 15, 2019 . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . [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, . [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. Raiciu, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/RFC7430, July 2015, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", Gao Expires April 17, 2020 [Page 36] INTERNET DRAFT Motivations of FSP October 15, 2019 RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC7925] Tschofenig, H., Ed., and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, May 2017, . Author's Address Jun-an Gao Beijing Capital Highway Development Group Co.,Ltd. Shoufa Plaza-A, Liuliqiao South, Fengtai Beijing People's Republic of China EMail: jagao@outlook.com Gao Expires April 17, 2020 [Page 37]