Internet DRAFT - draft-gao-fsp-motivations
draft-gao-fsp-motivations
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,
<http://cr.yp.to/tcpip/minimalt-20131031.pdf>
[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,
<http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>.
[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,
<https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>.
[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, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <https://www.rfc-editor.org/info/rfc4423>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>.
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,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, DOI 10.17487/RFC5380, October 2008,
<https://www.rfc-editor.org/info/rfc5380>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740, DOI
10.17487/RFC6740, November 2012, <https://www.rfc-
editor.org/info/rfc6740>.
[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,
<https://www.rfc-editor.org/info/rfc6824>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, DOI
10.17487/RFC6830, January 2013, <https://www.rfc-
editor.org/info/rfc6830>.
[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, <https://www.rfc-editor.org/info/rfc7296>.
[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,
<https://www.rfc-editor.org/info/rfc7333>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <https://www.rfc-editor.org/info/rfc8004>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046, DOI
10.17487/RFC8046, February 2017, <https://www.rfc-
editor.org/info/rfc8046>.
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, <https://www.rfc-
editor.org/info/rfc8087>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI
10.17487/RFC8200, July 2017, <https://www.rfc-
editor.org/info/rfc8200>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References
[AES] NIST, "Advanced Encryption Standard (AES)", November 2001.
<https://doi.org/10.6028/NIST.FIPS.197>
[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.
<http://dx.doi.org/10.6028/NIST.SP.800-38D>
[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,
<https://doi.org/10.6028/NIST.SP.800-145>
[RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, DOI 10.17487/RFC1498, August
1993, <https://www.rfc-editor.org/info/rfc1498>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, DOI
10.17487/RFC1945, May 1996, <https://www.rfc-
editor.org/info/rfc1945>.
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101,
February 1997, <https://www.rfc-editor.org/info/rfc2101>.
[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, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop",
RFC 2956, DOI 10.17487/RFC2956, October 2000,
<https://www.rfc-editor.org/info/rfc2956>.
[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,
<https://www.rfc-editor.org/info/rfc3168>.
[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,
<https://www.rfc-editor.org/info/rfc4106>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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,
<https://www.rfc-editor.org/info/rfc4297>.
[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, <https://www.rfc-
editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, DOI
10.17487/RFC4422, June 2006, <https://www.rfc-
editor.org/info/rfc4422>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[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, <https://www.rfc-
editor.org/info/rfc4861>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[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,
<https://www.rfc-editor.org/info/rfc4984>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>.
[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, <https://www.rfc-
editor.org/info/rfc5061>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
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,
<https://www.rfc-editor.org/info/rfc5218>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
DOI 10.17487/RFC5723, January 2010, <https://www.rfc-
editor.org/info/rfc5723>.
[RFC5889] Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing
Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[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,
<https://www.rfc-editor.org/info/rfc5942>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, DOI
10.17487/RFC6177, March 2011, <https://www.rfc-
editor.org/info/rfc6177>.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI
10.17487/RFC6250, May 2011, <https://www.rfc-
editor.org/info/rfc6250>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network
Protocol (ILNP) Engineering Considerations", RFC 6741, DOI
10.17487/RFC6741, November 2012, <https://www.rfc-
editor.org/info/rfc6741>.
[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,
<https://www.rfc-editor.org/info/rfc6742>.
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,
<https://www.rfc-editor.org/info/rfc6743>.
[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,
<https://www.rfc-editor.org/info/rfc6824>.
[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, <https://www.rfc-
editor.org/info/rfc6832>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, DOI
10.17487/RFC6833, January 2013, <https://www.rfc-
editor.org/info/rfc6833>.
[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, <https://www.rfc-editor.org/info/rfc6836>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[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, <https://www.rfc-editor.org/info/rfc7143>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI
10.17487/RFC7228, May 2014, <https://www.rfc-
editor.org/info/rfc7228>.
[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,
<https://www.rfc-editor.org/info/rfc7230>.
[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
<https://www.rfc-editor.org/info/rfc7231>.
[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, <https://www.rfc-editor.org/info/rfc7296>.
[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,
<https://www.rfc-editor.org/info/rfc7401>.
[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, <https://www.rfc-
editor.org/info/rfc7402>.
[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, <https://www.rfc-
editor.org/info/rfc7429>.
[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, <https://www.rfc-
editor.org/info/rfc7430>.
[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, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI
10.17487/RFC7540, May 2015, <https://www.rfc-
editor.org/info/rfc7540>.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015, <https://www.rfc-
editor.org/info/rfc7608>.
[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,
<https://www.rfc-editor.org/info/rfc7721>.
[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, <https://www.rfc-
editor.org/info/rfc7925>.
[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,
<https://www.rfc-editor.org/info/rfc8108>.
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/info/rfc8170>.
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]
