[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

INTERNET-DRAFT                                                    J. Gao
Intended Status: Experimental
Expires: January 16, 2019                                  July 15, 2018


                       Flexible Session Protocol
                 draft-gao-flexible-session-protocol-00


Abstract

   FSP is a connection-oriented transport layer protocol that provides
   support for mobility, multi-homing and multi-path by introducing the
   concept of 'upper layer thread ID'.

   It introduces the concept of transmit transaction to facilitate a
   quad-party sub-protocol of shared secret installation.

   It provides transport layer features of zero round-trip connection
   multiplication and on-the-wire compression, in addition to ubiquitous
   message authentication with optional encryption service.


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) 2018 IETF Trust and the persons identified as the



Gao                     Expires January 16, 2019                [Page 1]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   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
   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 . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Conventions and Definitions  . . . . . . . . . . . . . . . . .  5
     2.1. Requirements Language . . . . . . . . . . . . . . . . . . .  5
     2.2. Abbreviations and Idioms  . . . . . . . . . . . . . . . . .  6
   3.  Key Mechanisms . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1. Underlying Layer Services Required  . . . . . . . . . . . .  8
       3.1.1. High Mobility . . . . . . . . . . . . . . . . . . . . .  8
       3.1.2. Packet Delivery . . . . . . . . . . . . . . . . . . . .  8
       3.1.3. Network Address Change Notification . . . . . . . . . .  9
       3.1.4. Network Congestion Control  . . . . . . . . . . . . . .  9
     3.2. Identifying Connection by Local ULTID . . . . . . . . . . .  9
     3.3. Defending Against Connection Redirection with ICC . . . . . 10
     3.4. Transmit Transaction  . . . . . . . . . . . . . . . . . . . 10
     3.5. Quad-party Session Key Installation Sub-protocol  . . . . . 10
     3.6. Zero Round-Trip Connection Multiplication . . . . . . . . . 12
   4.  Packet Structure . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1. FSP over UDP/IPv4 . . . . . . . . . . . . . . . . . . . . . 12
     4.2. FSP over IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13
     4.3. Generic FSP Header  . . . . . . . . . . . . . . . . . . . . 15
     4.4. FSP Header Signature  . . . . . . . . . . . . . . . . . . . 15
       4.4.1 Header Stack Pointer . . . . . . . . . . . . . . . . . . 15
       4.4.2 Major  . . . . . . . . . . . . . . . . . . . . . . . . . 15
       4.4.3 Operation Code . . . . . . . . . . . . . . . . . . . . . 16
     4.5. Preliminary FSP Packets . . . . . . . . . . . . . . . . . . 18
       4.5.1. Connect Initialization  . . . . . . . . . . . . . . . . 18
       4.5.2. Acknowledgment to Connect Initialization  . . . . . . . 19
       4.5.3. Connect Request . . . . . . . . . . . . . . . . . . . . 20
     4.6. Normal Fixed Header . . . . . . . . . . . . . . . . . . . . 21
     4.7. Sink Parameter  . . . . . . . . . . . . . . . . . . . . . . 23
     4.8. Selective Negative Acknowledgment . . . . . . . . . . . . . 24
     4.9. RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   5.  The Finite Set of States . . . . . . . . . . . . . . . . . . . 27



Gao                     Expires January 16, 2019                [Page 2]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     5.0. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 27
     5.1. NON_EXISTENT  . . . . . . . . . . . . . . . . . . . . . . . 27
     5.2. LISTENING . . . . . . . . . . . . . . . . . . . . . . . . . 27
     5.3. CONNECT_BOOTSTRAP . . . . . . . . . . . . . . . . . . . . . 28
     5.4. CHALLENGING . . . . . . . . . . . . . . . . . . . . . . . . 28
     5.5. CONNECT_AFFIRMING . . . . . . . . . . . . . . . . . . . . . 28
     5.6. ACTIVE{A.K.A. ESTABLISHED}  . . . . . . . . . . . . . . . . 29
     5.7. COMMITTING  . . . . . . . . . . . . . . . . . . . . . . . . 29
     5.8. PEER_COMMIT . . . . . . . . . . . . . . . . . . . . . . . . 30
     5.9. COMMITTING2 . . . . . . . . . . . . . . . . . . . . . . . . 30
     5.10 COMMITTED . . . . . . . . . . . . . . . . . . . . . . . . . 31
     5.11 CLOSABLE  . . . . . . . . . . . . . . . . . . . . . . . . . 31
     5.12 PRE_CLOSED  . . . . . . . . . . . . . . . . . . . . . . . . 32
     5.13 CLOSED  . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     5.14 CLONING . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   6.  End-to-End Negotiation . . . . . . . . . . . . . . . . . . . . 33
     6.1. Connect Initialization  . . . . . . . . . . . . . . . . . . 33
     6.2. Response to Connect Initialization  . . . . . . . . . . . . 33
     6.3. Weak Key Agreement Request  . . . . . . . . . . . . . . . . 34
     6.4. Weak Key Agreement Response . . . . . . . . . . . . . . . . 35
     6.5. The Last Confirmation . . . . . . . . . . . . . . . . . . . 35
     6.6. Retransmission  . . . . . . . . . . . . . . . . . . . . . . 36
   7.  Quad-party Session Key Installation  . . . . . . . . . . . . . 36
     7.1. API for Session Key Installation  . . . . . . . . . . . . . 36
     7.2. Time to Call API for Session Key Installation . . . . . . . 37
     7.3. Time to Take New Session Key into Effect  . . . . . . . . . 37
     7.4. Generating the Initial Session Key  . . . . . . . . . . . . 38
     7.5. Internal Rekeying . . . . . . . . . . . . . . . . . . . . . 39
   8.  Send and Receive . . . . . . . . . . . . . . . . . . . . . . . 39
     8.1. Packet Integrity Protection . . . . . . . . . . . . . . . . 39
       8.1.1. Application of CRC64  . . . . . . . . . . . . . . . . . 39
       8.1.2. Packet Authentication Only  . . . . . . . . . . . . . . 40
       8.1.3. Authenticated Encryption with Additional Data . . . . . 40
     8.2. Start a New Transmit Transaction  . . . . . . . . . . . . . 42
     8.3. Send a Pure Data Packet . . . . . . . . . . . . . . . . . . 42
     8.4. Commit a Transmit Transaction . . . . . . . . . . . . . . . 42
       8.4.1. Initiate Transmit Transaction Commitment  . . . . . . . 42
       8.4.2. Respond to Transmit Transaction Commitment  . . . . . . 42
       8.4.3. Finalize Transmit Transaction Commitment  . . . . . . . 42
       8.4.4. Time-out for Committing Transmit Transaction  . . . . . 43
     8.5. Retransmission  . . . . . . . . . . . . . . . . . . . . . . 43
       8.5.1. Calculation of RTT  . . . . . . . . . . . . . . . . . . 43
       8.5.2. Generation and transmission of SNACK  . . . . . . . . . 43
       8.5.3. Negative acknowledgment of Packets Sent . . . . . . . . 44
     8.6. Flow Control  . . . . . . . . . . . . . . . . . . . . . . . 44
     8.7. On-the-Wire Compression . . . . . . . . . . . . . . . . . . 45
   9.  Graceful Shutdown  . . . . . . . . . . . . . . . . . . . . . . 45
     9.1. Initiation of Graceful Shutdown . . . . . . . . . . . . . . 45



Gao                     Expires January 16, 2019                [Page 3]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     9.2. Acknowledgment of Graceful Shutdown . . . . . . . . . . . . 45
     9.3. Finalization of Graceful Shutdown . . . . . . . . . . . . . 46
     9.4. Retransmission of RELEASE Packet  . . . . . . . . . . . . . 46
   10  Mobility and Multi-home Support  . . . . . . . . . . . . . . . 46
     10.1. Heartbeat Signals  . . . . . . . . . . . . . . . . . . . . 46
     10.2. Active Address Change Signaling  . . . . . . . . . . . . . 47
     10.3. Heuristic Remote Address Change Adaptation . . . . . . . . 47
     10.4. Heuristic Address Change Acknowledgement . . . . . . . . . 47
     10.5. Explicit Multi-home Informing  . . . . . . . . . . . . . . 48
   11  Connection Multiplication  . . . . . . . . . . . . . . . . . . 48
     11.1. Request to Multiply Connection . . . . . . . . . . . . . . 48
     11.2. Response to Connection Multiplication Request  . . . . . . 48
     11.3. Duplicate Detection of Connection Multiplication Request . 49
     11.4. Retransmission . . . . . . . . . . . . . . . . . . . . . . 50
     11.5. Key Derivation for Branch Connection . . . . . . . . . . . 50
   12  Timeouts and Abrupt Close  . . . . . . . . . . . . . . . . . . 50
     12.1. Timeouts in End-to-End Negotiation . . . . . . . . . . . . 50
     12.2. Timeouts in Multiply . . . . . . . . . . . . . . . . . . . 51
     12.3. Timeout of Transmit Transaction Commitment . . . . . . . . 51
     12.4. Timeout of Graceful Shutdown . . . . . . . . . . . . . . . 51
     12.5. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . . 51
     12.6. Session Key Timeout  . . . . . . . . . . . . . . . . . . . 51
     12.7. Abrupt Close . . . . . . . . . . . . . . . . . . . . . . . 52
   13  Issues for Further Study . . . . . . . . . . . . . . . . . . . 52
     13.1. Milk-type Payload and Minimal Delay Service  . . . . . . . 52
     13.2. Resolution of ULTID in DNS . . . . . . . . . . . . . . . . 52
     13.3. Optimizing FSP towards IPv6  . . . . . . . . . . . . . . . 53
     13.4. Binding End-to-End Negotiation with Resource Reservation . 54
     13.5. Path Selection and PMTU  . . . . . . . . . . . . . . . . . 54
     13.6. Host-Aggregated Congestion Control . . . . . . . . . . . . 54
     13.7. Asymmetric Transmission  . . . . . . . . . . . . . . . . . 54
     13.8. Connection Resurrection  . . . . . . . . . . . . . . . . . 55
     13.9. Architectural evolutions to transit towards IPv6 . . . . . 55
   14  Security Considerations  . . . . . . . . . . . . . . . . . . . 56
     14.1. Resistance against Deny of Service Attack  . . . . . . . . 56
     14.2. Resistance against Replay Attack . . . . . . . . . . . . . 56
     14.3. Resistance against Passive Attacks . . . . . . . . . . . . 56
     14.4. Resistance against Masquerade Attack . . . . . . . . . . . 56
     14.5. Resistance against Active Man-In-The-Middle Attack . . . . 56
     14.6. Privacy concerns . . . . . . . . . . . . . . . . . . . . . 56
   15  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 56
   16  References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 57
     16.2. Informative References . . . . . . . . . . . . . . . . . . 58
   17  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64





Gao                     Expires January 16, 2019                [Page 4]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


1.  Introduction

   Flexible Session Protocol is a connection-oriented transport layer
   provides mobility, multi-homing and multi-path support by introducing
   the concept of 'upper layer thread ID' (ULTID), which was firstly
   suggested in [Gao2002].

   An integrity check code (ICC) field associated with the ULTID is
   designed in the FSP header to protect authenticity and optionally
   privacy of the FSP packet. An FSP packet is assumed to originate from
   the same source if the ICC value associated with certain destination
   ULTID passes validation, regardless of the source or destination
   address in the underlying layer.

   ICC is either calculated by [CRC64] which protects FSP against
   unintended modification, or a cryptographic hash function, or
   cryptographically calculated with some Authenticated Encryption with
   Additional Data ([R01]) algorithm, each of which requires a shared
   secret key.

   In the former case a weak key meant to obfuscate the CRC64 checksum
   is agreed by the FSP participants. In the latter two cases, the
   shared secret key is assumed to be installed by the upper layer
   application (ULA).

   The ULTID is assigned roughly the same semantics with Security
   Parameter Index (SPI) in MOBIKE [RFC4555]. Either the weak key or the
   shared secret key is indexed by the source or destination ULTID in
   the local context of the sender or the receiver, respectively.

   FSP facilitates secret key installation by introducing the concept of
   transmit transaction. Mechanism of transmit transaction also provides
   the session-connection synchronization service to the upper layer.

   FSP is a transport layer protocol as specified in [RFC1122], provides
   services alike TCP [STD5] to ULA, with session layer features as
   suggested in [OSI/RM], most noticeably session-connection
   synchronization. It can be argued that FSP makes it much more
   flexible for the application layer protocols to adopt new key
   establishment protocol/algorithm while offloading routine
   authentication and optionally encryption of the data to the
   underlying layers where it may be much easier to exploit hardware-
   acceleration.

2.  Conventions and Definitions

2.1. Requirements Language




Gao                     Expires January 16, 2019                [Page 5]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   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].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
    interpreted as carrying significance described in RFC 2119.

2.2. Abbreviations and Idioms

   o Connection
     An FSP connection is the binding of two network nodes established
     through some end-to-end negotiation process. It is identified by
     the ULTID in the local context of each network node, respectively.

   o EoT
     A transmit transaction is said to reach End of Transaction (EoT) if
     the EoT flag is set in a legitimate PURE_DATA, PERSIST or MULTIPLY
     packet. We said that the packet terminates the transmit transaction
     if the EoT flag is set.

     An ACK_START packet both starts and marks end of a payload-less
     transmit transaction.

     In this version of FSP an ACK_CONNECT_REQ packet itself marks end
     of the singular transmit transaction.

     An FSP end node may not send further data if it has initiated EoT
     of its transmit direction unless a particular ACK_FLUSH packet is
     received. The particular AKC_FLUSH packet MUST acknowledge not only
      the packet with the EoT flag set but all of the packets sent
     before the packet as well.

     EoT, i.e. termination of transmit transaction is unilateral.

   o FREWS
     It stands for the Flag and advertised REceive Window Size. It is
     the 32-bit combined word next to the ICC field in the normal FSP
     fixed header.

   o ICC
     The Identity Check Code is a 64-bit value that depends on both the
     session key and all of the headers of the FSP packet to include the
     ICC, calculated with the same algorithm in the context of each FSP
     participant.

     Only a packet with correct ICC can be accepted by any FSP
     participant as soon as the connection has been established.



Gao                     Expires January 16, 2019                [Page 6]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     Initially CRC64 is exploited to make a checksum that weekly
     protects the FSP packet against unintentional modification. The
     checksum is obfuscated with the initial session key to get the ICC.
     After the ULA installed the long-term session key either some
     cryptographic hash function or some Authenticated Encryption with
     Additional Data algorithm shall be applied to obtain or check the
     ICC.

   o Session
     An FSP session is the transport-layer association of two network
     nodes. A full FSP session consists of one connection that was
     established from scratch and all of its branches.

     However for this version of FSP specification the idioms session
     and connection are interchangeable if not explicitly specified.

   o Session Key
     The session key is a bit string of at least 128 bits that means to
     resist against masquerade attack. It is either initiated during the
     end-to-end negotiation phase or installed by the ULA after the FSP
     connection is established.

     The session key installed by the ULA is called the long-term
     session key. Here long-term means that the key could be used until
     the packet sequence space is exhausted. The packet sequence space
     is exhausted if the number of packets that use the same key reaches
     or exceeds 2,147,483,647(2^31-1).


   o SN
     Sequence Number is the unsigned 32-bit integer number assigned to
     every FSP packet except the preliminary packets.

     Difference of two sequence number is represented by a 32-bit signed
     integer. If the result of SN B subtracting SN A is greater than
     zero, we say that B is greater than A and the packet of the
     sequence number B is later than the packet of the sequence number
     A, although the unsigned integer representation of B may be far
     less that A. Consequently, as the result of A subtracting B is less
     than zero, we say that A is less than B and the packet of the
     sequence number A is earlier than the packet of the sequence number
     A.

   o Transmit Transaction
     A transmit transaction of FSP is a sequence of FSP packets that
     were sent and marked by the ULA as one continuous stream where all
     packets in the stream must be acknowledged before any further
     packet is allowed to be sent.



Gao                     Expires January 16, 2019                [Page 7]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     A PERSIST or MULTIPLY packet always starts a transmit transaction.

     An ACK_START packet both starts and marks end of a payload-less
     transmit transaction.

     For this version of FSP an ACK_CONNECT_REQ packet itself makes a
     singular particular transmit transaction.

   o ULA
     The Upper Layer Application.

   o ULTID
     The Upper Layer Thread Identifier (ULTID) is a 32-bit word that was
     allocated by particular network end node of an FSP connection and
     is unique in the local context of the network end node.

     Theoretically all of the ULAs of a network end node MAY establish
     up to 2^31-1 FSP connections totally. Each connection MUST have a
     unique thread identifier (ULTID) assigned in the local context of
     the network end node.

     A session or connection of FSP does not require a global ID.

3.  Key Mechanisms

3.1. Underlying Layer Services Required

3.1.1. High Mobility

   Here high mobility refers to scenarios such as high-speed train or
   airplane.

   FSP solves somewhat coarse-grain or low-speed mobility problem. Fine-
   grain or high-speed mobility is left to the underlying physical
   network, which is semantics specified in [RFC1122]. To make mobility
   support work effectively it is assumed that one end-node MUST keep
   its lower layer address reasonably stable while the other end-node
   SHOULD NOT change its lower layer address too frequently.

   It is supposed that the packet to inform the remote end to update the
   lower layer address association could reach its destination in a
   satisfying success rate.

3.1.2. Packet Delivery

   FSP requires that the underlying layer provides packet delivery
   service.




Gao                     Expires January 16, 2019                [Page 8]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   In this version of FSP, when FSP is implemented in the IPv4 network,
   every FSP packet MUST be encapsulated in a UDP datagram.

   When FSP is implemented over IPv6, the FSP SHALL be the immediate
   upper layer of IPv6 [RFC8200].


3.1.3. Network Address Change Notification

   Network address change notification is mandatory only in the IPv6
   network.

   We split the IPv6 address of the IPv6 packet underlying FSP into
   three parts. The leftmost 64-bit long word is the network prefix,
   which SHOULD be the unique IPv6 prefix assigned to the host
   [RFC8273]. The centermost 32-bit word is called the aggregation host
   ID, and the rightmost 32-bit word is the ULTID. While the ULTID MUST
   be kept stable even during the life of an FSP session, the network
   prefix part MAY change when an endpoint is roaming. The aggregation
   host ID may change as well. The network prefix part together with the
   aggregation host ID part act as the traditional routing locator at
   the network layer.

   It is supposed that the network layer immediately notify FSP of the
   network prefix and/or aggregation host ID change.

   An participant of an FSP connection SHALL immediately notify its peer
   whenever its underlying IPv6 address is changed with a KEEP_ALIVE
   packet. The peer shall send packet to the participant that has
   notified the address change with the new address.

3.1.4. Network Congestion Control

   It is supposed that end-to-end congestion control is provided at some
   sub-layer of the network layer. However for initial versions of FSP
   it is not expected that such sub-layer exists. Instead a TCP-friendly
   congestion control algorithm embedded in the FSP implementation is
   required.

3.2. Identifying Connection by Local ULTID

   Each FSP connection prepares a pair of ULTIDs. ULTID is assigned
   roughly the same semantics with the Security Parameter Index (SPI) in
   IKE [RFC4301].  An ULTID uniquely indexes a connection in the local
   context of an FSP end node. An FSP end node relies neither source IP
   address nor destination IP address, except the ULTID part of the near
   end's IPv6 address to identify an FSP connection.




Gao                     Expires January 16, 2019                [Page 9]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   Each ULTID is allocated in the local context of the two FSP
   participant respectively. The source ULTID and the destination ULTID
   of an FSP packet usually differ in their values. However, the secret
   keys indexed in the local contexts of the two end-points must have
   the same value.

3.3. Defending Against Connection Redirection with ICC

   An integrity check code (ICC) field associated with the ULTID is
   designed in the FSP header to protect authenticity and optionally
   privacy of the FSP packet. An FSP packet is assumed to originate from
   the same source if the ICC value associated with certain destination
   ULTID passes validation, regardless of the source or destination
   address in the underlying layer.

   On initiating FSP takes use of [CRC64] to make checksum of the FSP
   packet to protect it against unintentional modification. The checksum
   is taken as the ICC.

   After the ULA has installed a shared secret key, value of ICC is
   calculated by firstly getting the secret key associated indexed by
   the local ULTID, then calculating the tag value with the AES-GCM
   [GCM] authenticated encryption with additional data algorithm [R01],
   or calculating the message authentication code with the BLAKE2
   algorithm [RFC7693].

3.4. Transmit Transaction

   FSP facilitates shared secret key installation by introducing the
   concept of transmit transaction.

   A transmit transaction of FSP is a sequence of FSP packets that were
   sent and marked by ULA as one continuous stream where all packets in
   the stream MUST be acknowledged before any further packet is allowed
   to be sent.

   A flag called 'End of Transaction' (EoT) is designed in the FSP
   header. When it is set, it marks that the transmit transaction in the
   direction from the source of the FSP packet towards the destination
   of the FSP packet is committed.

3.5. Quad-party Session Key Installation Sub-protocol

   It is proposed that it is the ULA to do key establishment and/or end-
   point user-agent authentication while the FSP layer provides
   authenticated, optionally encrypted data transfer service. It is
   arguably much more flexible for the application layer protocols to
   adopt new key establishment algorithm while offloading routine



Gao                     Expires January 16, 2019               [Page 10]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   authentication and optionally encryption of the data to the
   underlying layers where it may be much easier to exploit hardware-
   acceleration.

   A dedicate application program interface (API) is designed for the
   ULA to install the secret key established by the ULA participants.

   Protocol for installation of the shared secret key is quad-party in
   the sense that both the upper layer application and the FSP layer of
   the two participant nodes MUST agree on the moment of certain state
   to install the shared secret key.

   The ULA installs the new secret key to the FSP layer. The FSP layer
   SHALL make it sure that the new secret key is taken into effect
   starting from the very first packet of the transmit transaction that
   is immediately next to the transmit transaction where API for
   installation of the new secret key is called.

   By committing a transmit transaction a ULA participant clearly tells
   the underlying FSP layer that the next packet sent MAY adopt a new
   secret key. On receiving a packet with the EoT flag set the ULA is
   informed that the next packet received MAY adopt a new shared secret
   key.

   The ULA participant that installs the new secret key firstly MUST be
   the one that is committing a transmit transaction after it has
   accepted peer's transmit transaction commitment.

   After the ULA install a new secret key every packet sent later than
   the one with the EoT flag set MUST adopt the new secret key. The peer
   MUST have commit a transmit transaction and it SHALL install the same
   secret key on receiving the FSP packet with the EoT flag set.

   The ULA SHOULD have installed the new shared secret key, or install
   it instantly after accepting the packet with the EoT flag set.

   If the new secret key has ever been installed the packet received
   after the one with the EoT flag set MUST adopt the new secret key.

   In a typical scenario the ULA endpoints first setup the FSP
   connection where resistance against connection redirection is weakly
   enforced by CRC64. After the pair of ULA endpoints establish a shared
   secret key, they install the secret key and commit current transmit
   transactions. Authenticity of the FSP packets sent later is
   cryptographically protected by the new secret key and resistance
   against various attacks is secured.

   Although transmit transaction is actually uni-directional the secret



Gao                     Expires January 16, 2019               [Page 11]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   key is shared bi-directionally in this version of FSP.

3.6. Zero Round-Trip Connection Multiplication

   An FSP connection MAY be multiplied to get a branch or branches of
   the connection. In this version of FSP a branch connection MAY NOT be
   multiplied further, and only the connection where authenticity of the
   packets is cryptographically protected may be multiplied.

   The packet that carries the command to multiply an established FSP
   connection MUST be sent from a new allocated local ULTID towards the
   destination ULTID of the original connection. It is an out-of-band
   packet in the context of the original connection and it MUST be
   cryptographically protected by the secret key of the original
   connection. The packet MAY carry payload.

   The receiver of the packet MUST allocate a new local ULTID, accept
   the optional payload in the new context associated with the new
   ULTID, derive a new secret key from the secret key of the original
   connection, and responds from the new context. The response MAY carry
   payload.

   The very first response packet MUST be protected by the new secret
   key. The sender of the multiply command packet MUST automatically
   inaugurate the same secret key, derived from the secret key of the
   same original connection. And it MUST treat the response packet as
   though a transmit transaction had been committed by the responder,
   i.e. authenticity of the response packet is verified with the new
   secret key.

   Thus the branch connection of a new pair of ULTIDs is established
   with zero round-trip overhead. This mechanism may be exploited to
   provide expedited data transfer or parallel data transfer service.

4.  Packet Structure

4.1. FSP over UDP/IPv4

   In this version of FSP, when FSP is implemented in the IPv4 network,
   every FSP packet MUST be encapsulated in a UDP datagram. The UDP
   datagram encapsulated the FSP packet SHALL have the checksum
   disabled. The Source and the destination ULTIDs are put at the
   leading position of the UDP payload. FSP fixed header, optional
   extension headers and FSP payload follow the ULTIDs:







Gao                     Expires January 16, 2019               [Page 12]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


    0                            15 16                           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source Port           |        Destination Port       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |             0                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Source Upper Layer Thread ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Destination Upper Layer Thread ID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          FSP Fix Header                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                Optional FSP Extension Headers                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                       Optional  FSP payload                   ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1 FSP over UDP

4.2. FSP over IPv6

   When FSP is implemented over IPv6, the ULTID part is embedded in the
   IPv6 address. FSP fixed header follows the IPv6 headers:
























Gao                     Expires January 16, 2019               [Page 13]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ~                          IPv6 Header:                         ~
    0                            15 16                           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                        Source Network Prefix  +
   |                                                               |
   +                 Source Address    ----------------------------+
   |                                   Source Aggregation Host ID  |
   +                                   ----------------------------+
   |                                 Source Upper Layer Thread ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                   Destination Network Prefix  +
   |                                                               |
   +        Destination Address   ---------------------------------+
   |                              Destination Aggregation Host ID  |
   +                              ---------------------------------+
   |                            Destination Upper Layer Thread ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                    Optional IPv6 Headers                      ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          FSP Fix Header                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                Optional FSP Extension Headers                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                       Optional  FSP payload                   ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 2 FSP over IPv6

   o Network Prefix
     The leftmost 64-bit of the IPv6 address which MAY and usually do
     have different value at the difference interface of an IPv6 end-
     node.

   o Aggregation Host ID
     The left 32-bit part of the rightmost 64-bit long word of the IPv6



Gao                     Expires January 16, 2019               [Page 14]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     address. All of the aggregation host ID parts of an IPv6 end-node's
     IPv6 addresses MUST have the same value for this version of FSP.

4.3. Generic FSP Header

   FSP headers include the fixed header and the extension headers. A
   general fixed header consists of 20-byte operation-code specific
   fields and a 32-bit FSP Header Signature. An extension header
   consists an operation-code specific content and a 32-bit FSP Header
   Signature. The length of the extension header content may be
   variable, provided that the tail of the full extension header align
   on 64-bit boundary.

     0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~              Operation Code Specific Fields                   ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 3 FSP Header

4.4. FSP Header Signature

    0                            15 16                           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Header Stack Pointer     |     Major     | Operation Code|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4 FSP Header Signature

4.4.1 Header Stack Pointer

   For the fixed header the header stack pointer is a 16-bit unsigned
   integer that specifies the offset of the first octet of the payload.

   For an extension header the header stack pointer is a 16-bit unsigned
   integer that specifies the offset of the first octet of the very
   extension header.

   The offset that the header stack pointer specifies starts from the
   begin of the FSP fixed header. If its value is 24 the header contains
   it is the last extension header or the fix header without any
   extension.

4.4.2 Major



Gao                     Expires January 16, 2019               [Page 15]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   It is an octet states current FSP major version. For this FSP version
   it MUST be 0.

   It is NOT mandatory for different major versions of FSP to be
   compatible.

4.4.3 Operation Code

   It is an octet that stores the code of the command which indicates
   the function of the packet.

   Synonym              Code    Meaning

   INIT_CONNECT          1      Initialize Connection

   ACK_INIT_CONNECT      2      Acknowledge Initialization of Connection

   CONNECT_REQUEST       3      Formally Request to Connect

   ACK_CONNECT_REQ       4      Acknowledge the Connection Request

   RESET                 5      Reset a connection
                                                             Refuse to
                                establish the connection, or abort
                                connection.
   ACK_START             6      ACKnowledgement to start a connection
                                It is the acknowledgement to
                                ACK_CONNECT_REQ or MULTIPLY, to confirm
                                that the connection has been established
                                or multiplied. It MUST be payload-less,
                                and its EoT flag is always assumed to be
                                set. It MAY carry optional headers. It
                                always consumes a slot of the send
                                sequence space. It is supposed to both
                                start and commit a payload-less transmit
                                transaction which SHALL be skipped.

   KEEP_ALIVE            7      Keep the peer alive
                                It is an out-of-band control packet
                                acting as the heart-beating signal. An
                                out-of-band control packet does not
                                consume send sequence space itself. FSP
                                takes use of the KEEP_ALIVE packet to
                                inform the peer about the change of the
                                source IP addresses. Besides, when the
                                MIND flag is set, the KEEP_ALIVE packet
                                is meant to tell the peer which packets
                                should be retransmitted. If the End of



Gao                     Expires January 16, 2019               [Page 16]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


                                Transaction flag of the KEEP_ ALIVE
                                packet is set it is meant to forcefully
                                commit current transmit transaction of
                                the sender of the KEEP_ALIVE packet.

   PERSIST               8      Make a connection persistent
                                It is meant to start a new transmit
                                transaction after a connection migrated
                                to CLOSABLE state. It can also
                                acknowledge ACK_CONNECT_REQ or MULTIPLY.
                                It MUST either carry payload, or get the
                                EoT flag set with or without payload. It
                                always consumes a slot of the send
                                sequence space.

   PURE_DATA             9      Pure Data
                                It does not carry any optional header.

   ACK_FLUSH             10     ACKnowledge to remote end's commitment
                                (FLUSHing) of transmit transaction. It
                                is an out-of-band control packet like
                                KEEP_ALIVE. It is sent instantly on
                                having every packet of the last transmit
                                transaction received, meant to make
                                acknowledgment to the remote end and let
                                the remote end stop sending heart-beat
                                signals. If the End of Transaction flag
                                of the ACK_FLUSH packet is set it is
                                meant to commit current transmit
                                transaction of the sender of the
                                ACK_FLUSH packet as well.

   RELEASE               11     Release the connection
                                RELEASE packet MAY NOT carry payload but
                                it always consumes a slot of the send
                                sequence space. Only when each peer has
                                committed the transmit transaction may a
                                RELEASE packet sent under the request of
                                the ULA.

   MULTIPLY              12     Multiply the connection
                                It is sent in the context of the
                                original connection and may carry
                                payload and/or optional headers as an
                                out-of-band packet.

   PEER_SUBNETS          17     Tell the remote end how to address
                                the sender of the packet in the reverse



Gao                     Expires January 16, 2019               [Page 17]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


                                direction. It is the code of the Sink
                                Parameter extension header.

   SELECTIVE_NACK        18     Tell the remote end to retransmit
                                the packets that were negatively
                                acknowledged. It is the code of the
                                Selective Negative Acknowledgment
                                extension header.

4.5. Preliminary FSP Packets

   Preliminary FSP packets are the packets exchanged during the end-to-
   end negotiation phase of FSP connection establishment when it is
   impossible to calculate ICC normally.

4.5.1. Connect Initialization

    0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
    +                         Timestamp                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Init-Check-Code                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Salt                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~           Host Name of the Responder (optional)               ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5 Connect Initialization

   Operation Code of this type of packet is INIT_CONNECT.

   o Timestamp
     It is a 64-bit unsigned integer that represents number of
     microseconds elapsed since 00:00, Jan.1, 1970, Coordinated
     Universal Time. It may be exploited to synchronize the clocks of
     the participants and/or estimate delay during data transmission in
     the network.

   o Init-Check-Code



Gao                     Expires January 16, 2019               [Page 18]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     It is a 64-bit random bit string that means to uniquely associated
     with the connection initiated.

   o Salt
     It a 32-bit random bit string that may be exploited to make secret
     key agreement.

   o Host Name of the Responder
     The optional payload of the Connect Initialization packet.

4.5.2. Acknowledgment to Connect Initialization

    0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            Cookie                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Init-Check-Code                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Time Delta                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6 Acknowledgment to Connect Initialization

   Operation Code of this type of packet is ACK_INIT_CONNECT.

   o Cookie
     It is a 64-bit bit string cryptographically generated by the
     responder in a represent-transfer state manner. More specifically
     when the same timestamp, time delta, Init-Check-Code, salt, source
     and destination ULTIDs are sent to the responder, the responder
     MUST be able to generate the identical cookie value.

   o Init-Check-Code
     It MUST be identical to the corresponding field in the Connect
     Initialization packet acknowledged.

   o Time Delta
     It is a 32-bit signed integer which is the difference between the
     near-end's time and the timestamp value sent in the Connection
     Initialization packet. The units and the epoch of the near-end's
     time value and the timestamp value MUST be the same. However, the
     precision or resolution of the time delta value is chosen



Gao                     Expires January 16, 2019               [Page 19]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     arbitrarily by the responder.

4.5.3. Connect Request

    0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Time Stamp                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Init-Check-Code                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Salt                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Initial Sequence Number                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Time Delta                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            Cookie                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                         Sink Parameter                        ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~           Host Name of the Initiator (optional)               ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 7 Connect Request

   Operation Code of this type of packet is CONNECT_REQUEST.

   The value of each field that has the identical name with the one in
   the associated Connect Initialization and Acknowledgment to Connect
   Initialization packet MUST be assigned the same value as in these two
   packets, except header signature in the packet.

   o Sink Parameter
     It is an extension header specified in 4.7.

   o Host Name of the Initiator



Gao                     Expires January 16, 2019               [Page 20]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     It is optional and is stored in the payload part of the Connect
     Request packet. It could be exploited by the responder to look up
     the address of the initiator that may receive packets in the
     reverse direction.

4.6. Normal Fixed Header

    0                            15 16                           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Expected Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     Integrity Check Code                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Flags    |         Advertised Receive Window Size        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 8 FSP Fixed Header

   Operation Code of a normal fixed header may be ACK_CONNECT_REQUEST,
   PURE_DATA, PERSIST, KEEP_ALIVE, ACK_FLUSH, RELEASE or MULTIPLY.

   o Sequence Number
     Each in-band FSP packet is assigned a 32-bit unsigned integer as
     the sequence number. The sequence number assigned for in-band FSP
     packets MUST be in strict order.

     An out-of-band packet that has the operation code of KEEP_ALIVE,
     ACK_FLUSH or MULTIPLY MUST be assigned a sequence number that falls
     in the receive window.

   o Expected Sequence Number
     It stores the earliest sequence number of the packets that were not
     yet received in the receive window of the sender. It is an
     accumulative acknowledgment. Any packet with the sequence number
     before the received Expected Sequence Number is supposed to have
     been received by the remote end.

   o Integrity Check Code
     The ICC.

   o Flags
     It is bit-field of width 8. From left to right:



Gao                     Expires January 16, 2019               [Page 21]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     - End of Transaction(EoT):
       If the EoT flag of a packet is set, it is the last packet of a
       transmit transaction. A packet with the EoT flag set MAY be the
       start and the single packet of the transmit transaction as well.

     - Minimal-Delay (MIND):
       If the MIND flag of the Connect Request or Acknowledgment to
       Connect Request packet is set, the ULA prefers minimal delay and
       is willing to tolerate packet loss. FSP SHALL drop the packet
       received earliest when there is no enough receive buffer so that
       the latest packet received can be saved and the delay to deliver
       data to ULA is minimized.

       If the MIND flag has been set the EoT flag of any following
       packet is simply ignored.

       Payload of each FSP packet is delivered to the ULA as an
       independent message if the MIND flag has been set.

     - HMAC:
       If the HMAC flag of a packet is set the cryptographic hash
       algorithm SHALL be applied to get the message authentication code
       of the whole packet. Each FSP version MUST designate one
       particular cryptographic hash algorithm.

     - Explicit Congestion Notification(ECN):
       Currently yet to be studied.

     The remaining 4 bits are reserved.

   o Advertised Receive Window Size
     It is a 20-bit unsigned integer that stores number of the free
     blocks in the receive buffer of the sender of the packet that
     contains the receive window size field. It is count from the slot
     meant to accept the packet with the expected sequence number.

     The sender must ensure that the difference between the latest
     sequence number sent out and the largest expected sequence number
     received does not exceed the value of the latest advertised receive
     window size received.











Gao                     Expires January 16, 2019               [Page 22]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


4.7. Sink Parameter

    0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~               Addressable Network Prefixes                    ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Listener ID/Host ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 9 Sink Parameter

   Operation Code in the Header Signature of this extension header is
   PEER_SUBNETS.

   o Addressable Network Prefixes
     These are up to 4 64-bit words that specify the network prefixes of
     the lower layer interfaces that are addressable by the receiver in
     the reverse direction.

     In this version of the FSP 'Addressable Network Prefixes' field is
     of fixed length. The last network prefix which is non-zero is the
     last resort one. There MUST be at least one non-zero network
     prefix. If there are more than one non-zero network prefixes those
     other than the last resort are load-balanced preferred.

     In an IPv6 network, the addressable network prefix is the leftmost
     64 bits of the IPv6 address. The receiver of the Addressable
     Network Prefixes SHALL send packet in the reverse direction, i.e.
     to the sender of the field with the destination IPv6 address
     generated by combining a preferred network prefix with the
     aggregation host id and the ULTID part of the source address in the
     IPv6 header of the received packet that eventually carries the
     Addressable Network Prefixes.

     Such feature MAY be exploited to handle links with unidirectional
     connectivity, but it is NOT RECOMMENTED.

     In an IPv4 network for compatibility with the IPv6 addressed ULA
     the 64-bit word of the addressable network prefix specified is
     composed as following Figure:







Gao                     Expires January 16, 2019               [Page 23]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


    0                            15 16                           31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  0x2002 (IPv6 6to4 prefix)    |IPv4 address (leftmost 16 bits)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |IPv4 address(rightmost 16 bits)|   UDP port number (16 bits)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 10 Addressable Network Prefix of FSP over UDP/IPv4

   Sender of the Sink Parameter packet SHOULD be NAT-aware. If it is
   able to obtain the from the NAT box [TODO: definition, phrase
   RFC1631] via protocol UPnP[RFC6970]SHOULD fill in the IPv4 address
   and UDP port number fields with the public IP value that were
   obtained. If it does not have such capability, it SHALL fill in the
   addressable network prefix with all binary zeroes.

   o Listener ID
     It is the ULTID of the responder that is in LISTENING state.

   o Host ID
     It is the aggregation host id of the sender. It SHALL be 0 if it is
     in the IPv4 network.

4.8. Selective Negative Acknowledgment

    0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Gap Width                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Data Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~          Further pairs of  (Gap Width, Data Length)           ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                   Acknowledgement Delay                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Out-band Serial Number                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 11 Selective Negative Acknowledgment

   The operation code of this type of extension header is SNACK. The
   SNACK header contains the descriptor of the receive window gaps:



Gao                     Expires January 16, 2019               [Page 24]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   The descriptor itself is a list of entries. The length of the list
   can be zero which means that there is no gap in the receive window.
   If the list is not empty, each entry contains the width of one gap in
   the receive window and the length of the continuously received data
   following the gap, respectively. The unit of aforementioned length of
   gaps or number of packets is buffer block.

   o Acknowledgement Delay
     A 64-bit unsigned integer specifies the delay in microseconds
     between sending the packet containing the SNACK extension header
     and accepting the last packet that is accumulatively acknowledged
     by the SNACK extension header.

   o Out-band Serial Number
     The SNACK header contains a 32-bit out-band serial number as well.
     Each time a packet that contains the SNACK header is sent the out-
     band serial number shall increase by one. It is assumed that in the
     life of the session no two packets have the same sequence number
     and the same SNACK header serial number simultaneously.

4.9. RESET

   The 'RESET' packet is a special command packet meant to interrupt
   connection setup process or disconnect abruptly. Operation Code of
   the packet is RESET.

   Structure of a RESET packet in C code snippet with unnamed union
   applied:

   struct FSP_RejectConnect
   {
        /* sequence numbers */
        union
        {
                timestamp_t timeStamp;
                struct
                {
                        uint32_t initial;
                        uint32_t expected;
                } sn;
        };
        /* uniqueness proof */
        union
        {
                uint64_t integrityCode;
                uint64_t cookie;
                uint64_t initCheckCode;
        };



Gao                     Expires January 16, 2019               [Page 25]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


        /* bit field to describe reasons for reset */
        uint32_t reasons;
        $FSP_HeaderSignature hs;
   };

   When the RESET packet is the response to a Connect Initialization
   packet both the timeStamp and the initCheckCode fields of the RESET
   packet MUST be set to the same values of Time Stamp and Init-Check-
   Code in the Connect Initialization packet, respectively.

   When the RESET packet is the response to a Connect Request packet
   both the timeStamp and the cookie fields of the RESET packet MUST be
   set to the same value of Time Stamp and Cookie in the Connect Request
   packet, respectively.

   When the RESET packet is the response to a packet with a normal fixed
   header, the sn.initial, the sn.expected and the integrityCode of the
   RESET packet MUST be set as to specification of normal fixed header
   field Sequence Number, Expected Sequence Number and Integrity Check
   Code, respectively.































Gao                     Expires January 16, 2019               [Page 26]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


5.  The Finite Set of States

5.0. Conventions

     ESTABLISHED    The string of alphabetic characters designates the
                    name of the state

     [API: Reset]   Upper Layer Application Programming Interface Call

     {Notify}       Call back/notify the upper layer application

     {new context}  Additional action before or after state transition

     [Send OPCODE_OF_FSP_PACKET]
                    Send some FSP packet

     [Retransmit OPCODE_OF_FSP_PACKET]
                    Retransmit some FSP packet

     {On transient state Timeout}
                    Timed-out event

     {&& additional condition}
                    Together with some additional condition

     -->            state transition

     |--            branch

5.1. NON_EXISTENT
     ---[API: Listen]-->LISTENING
     |--[API: Connect]-->CONNECT_BOOTSTRAP-->[Send INIT_CONNECT]
     |--[API: Multiply]-->CLONING-->[Send MULTIPLY]

     NON_EXISTENT is a pseudo-state before a connection is created by
     the ULA calling API Listen, Connect or Multiply (or after a
     connection is reset).

5.2. LISTENING
     ---[API: Reset]-->NON_EXISTENT
     |<-->[Rcv.INIT_CONNECT]{&& accepted}[Send ACK_INIT_CONNECT]
     |<-->[Rcv.INIT_CONNECT]{&& rejected}[Send RESET]
     |<-->[Rcv.CONNECT_REQUEST]{&& duplication detected}
           [Retransmit ACK_CONNECT_REQ]
     |--[Rcv.CONNECT_REQUEST]-->{Notify}
           |-->[API: Accept]
                 -->{new context}CHALLENGING-->[Send ACK_CONNECT_REQ]
           |-->[API: Reject]-->[Send RESET] {abort new context, if any}



Gao                     Expires January 16, 2019               [Page 27]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     LISTENING is a state entered by the ULA calling API Listen.

5.3. CONNECT_BOOTSTRAP
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |--[Rcv.ACK_INIT_CONNECT]-->CONNECT_AFFIRMING
           |-->[Send CONNECT_REQUEST]
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On transient state Timeout}-->NON_EXISTENT-->[Notify]
     |--{On retransmission Timeout}<-->[Retransmit INIT_CONNECT]

     CONNECT_BOOTSTRAP is a state entered by the ULA calling API
     Connect, before receiving the acknowledgement of the remote end to
     the connection initialization packet.

5.4. CHALLENGING
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |<-->[API: Send{new data}]{just prebuffer}
     |--[Rcv.ACK_START]-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.PERSIST]
       |--{Not EOT}-->COMMITTED-->[Send SNACK]-->[Notify]
       |--{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On transient state Timeout}-->NON_EXISTENT-->[Notify]

     CHALLENGING is a state entered by the ULA accepting the connection
     request after a new connection context has been incarnated. The new
     connection is incarnated by the FSP context of the near end in the
     LISTENING state as a legitimate CONNECT_REQUEST packet is received.

5.5. CONNECT_AFFIRMING
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |<-->[API: Send{new data}]{just prebuffer}
     |--[Rcv.ACK_CONNECT_REQ]-->PEER_COMMIT-->[Notifiy]
         |-->[API: Accept]
             |-->{Not EOT}-->[Send PERSIST]
             |-->{EOT}-->COMMITTING2-->[Send PERSIST with EoT]
         |-->[API: Reject]-->NON_EXISTENT-->[Send RESET]
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On transient state Timeout}-->NON_EXISTENT-->[Notify]
     |--{On retransmission Timeout}<-->[Retransmit CONNECT_REQUEST]

     CONNECT_AFFIRMING is a state entered by the ULA affirming to send
     connect request after receiving the acknowledgement to the
     connection initialization packet.







Gao                     Expires January 16, 2019               [Page 28]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


5.6. ACTIVE{A.K.A. ESTABLISHED}
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |--[API: Send{transact}]-->COMMITTING{Urge to Commit}
     |<-->[API: Send{more data}][Send PURE_DATA]
     |--[Rcv.PURE_DATA]
         |--{Not EOT}-->[Send SNACK]-->[Notify]
         |--{EOT}
            |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.PERSIST]
         |--{Not EOT}-->[Send SNACK early]
         |--[EOT]
            |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.EOT]
         |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.MULTIPLY]{passive multiplication}
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On Idle Timeout}-->NON_EXISTENT-->[Notify]

     ACTIVE or ESTABLISHED is a state that the FSP participant has
     finished end-to-end negotiation but has not committed current
     transmit transaction nor fully received the latest transmit
     transaction of the remote end.

5.7. COMMITTING
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |--[Rcv.ACK_FLUSH]-->COMMITTED-->[Notify]
     |--[Rcv.PURE_DATA]
         |--{Not EOT}-->[Send SNACK]-->[Notify]
         |--{EOT}-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.MULTIPLY]{passive multiplication}
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On Idle Timeout}-->NON_EXISTENT-->[Notify]

     COMMITTING is a state that the FSP participant has committed the
     transmit transaction but has not fully received the latest transmit
     transaction of the remote end, nor the acknowledgement to the
     transmit transaction commitment has been received.

     The participant in COMMITTING state MAY NOT transmit further data
     until current transmit transaction commitment is acknowledged.











Gao                     Expires January 16, 2019               [Page 29]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


5.8. PEER_COMMIT
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |--[API: Send{flush}]-->COMMITTING2-->[Urge COMMIT]
     |<-->[API: Send{more data}][Send PURE_DATA]
     |<-->[Rcv.PURE_DATA]{just prebuffer}
     |<-->[Rcv.ACK_START]--[Send ACK_FLUSH]
     |--[Rcv.PERSIST]
         |-->{Not EOT}-->ACTIVE-->[Send SNACK]
         |<-->{EOT}--[Send ACK_FLUSH]
             |--{&& is new transaction}-->[Notify]
     |--[Rcv.EOT]-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.MULTIPLY]{passive multiplication}
     |--[Rcv.RELEASE]-->CLOSED-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On Idle Timeout}-->NON_EXISTENT-->[Notify]

     PEER_COMMIT is a state that the FSP participant has not committed
     current transmit transaction but has fully received the latest
     transmit transaction of the remote end, and the acknowledgement to
     the transmit transaction commitment has not been received yet.

5.9. COMMITTING2
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |<-->[Rcv.PURE_DATA]{just prebuffer}
     |--[Rcv.ACK_FLUSH]-->CLOSABLE-->[Notify]
     |--[Rcv.PERSIST]
         |-->{Not EOT}-->COMMITTING-->[Send SNACK]
         |-->{EOT}-->{keep state}-->[Send ACK_FLUSH]
             |--{&& is a new transaction}-->[Notify]
     |--[Rcv.EOT]-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.MULTIPLY]{passive multiplication}
     |--[Rcv.RELEASE]-->CLOSED-->[Send RELEASE]-->[Notify]
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On Idle Timeout}-->NON_EXISTENT-->[Notify]

     COMMITTING2 is a state that the FSP participant has committed
     current transmit transaction and has fully received the latest
     transmit transaction of the remote end, but the acknowledgement to
     the transmit transaction commitment has not been received yet.

     The participant in COMMITTING2 state MAY NOT transmit further data
     until current transmit transaction commitment is acknowledged.









Gao                     Expires January 16, 2019               [Page 30]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


5.10 COMMITTED
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |--[API: Send{more data}]-->ACTIVE-->[Send PERSIST]
     |--[API: Send{flush}]-->COMMITTING{Urge COMMIT}
     |--[Rcv.PURE_DATA]
         |-->{Not EOT}-->[Send SNACK]-->[Notify]
         |-->{EOT}
            |-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.PERSIST]
         |-->{Not EOT}-->[Send SNACK]
         |-->{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.MULTIPLY]{passive multiplication}
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On Idle Timeout}-->NON_EXISTENT-->[Notify]

     COMMITTED is a state that the FSP participant has committed current
     transmit transaction and has received the acknowledgement to the
     transmit transaction commitment, but has not fully received the
     latest transmit transaction of the remote end.

5.11 CLOSABLE
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |--[API: Send{more data}]-->PEER_COMMIT-->[Send PERSIST]
     |--[API: Send{flush}]-->COMMITTING2-->[Urge COMMIT]
     |--[API: Shutdown]-->[Send RELEASE]-->PRE_CLOSED-->[Notify]
     |<-->[Rcv.PURE_DATA]{just prebuffer}
     |<-->[Rcv.ACK_START]--[Send ACK_FLUSH]
     |--[Rcv.PERSIST]
         |-->{Not EOT}-->COMMITTED-->[Send SNACK]
         |-->{EOT}-->{[Send ACK_FLUSH]
             |--{&& is a new transaction}-->[Notify]
     |--[Rcv.MULTIPLY]{passive multiplication}
     |--[Rcv.RELEASE]-->CLOSED-->[Notify]
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On Idle Timeout}-->CLOSED
     |--{On session key Timeout}-->NON_EXISTENT

     CLOSABLE is a state that the FSP participant has committed current
     transmit transaction and has received the acknowledgement to the
     transmit transaction commitment, and has fully received the latest
     transmit transaction of the remote end.










Gao                     Expires January 16, 2019               [Page 31]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


5.12 PRE_CLOSED
     ---[API: Reset]-->NON_EXISTENT-->[Send RESET]
     |--[Rcv.RELEASE]-->CLOSED-->[Send RELEASE]-->[Notify]
     |--{On retransmission Timeout}<-->[Retransmit RELEASE]
     |--{On transient state Timeout}-->NON_EXISTENT-->[Notify]

     PRE_CLOSED is a state entered by the ULA calling the API Shutdown
     in CLOSABLE state.

5.13 CLOSED
     |--{On session key Timeout}-->NON_EXISTENT

     CLOSED is a state migrated from PRE_CLOSED state on receiving a
     legitimate RELEASE packet from the remote end.

     Unlike TCP [STD7], CLOSED state in FSP is not fictional. Instead a
     connection context MAY persist in CLOSED state until the session
     key runs out of life. A connection in CLOSED state MAY be
     resurrected.


5.14 CLONING
     ---[API: Reset]-->NON_EXISTENT
     |<-->[API: Send{new data}]{just prebuffer}
     |<-->[Rcv.PURE_DATA]{just prebuffer}
     |--[Rcv.ACK_START]
         |--{&& Not ULA-flushing}-->PEER_COMMIT
             |-->[Send ACK_FLUSH]-->[Notify]
         |--{&& ULA-flushing}-->CLOSABLE
             |-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.PERSIST]
         |-->{Not EOT}
             |--{&& Not ULA-flushing}-->ACTIVE
                |-->[Send SNACK]-->[Notify]
             |--{&& ULA-flushing}-->COMMITTED
                |-->[Send SNACK]-->[Notify]
         |-->{EOT}
             |--{&& Not ULA-flushing}-->PEER_COMMIT
                |-->[Send ACK_FLUSH]-->[Notify]
             |--{&& ULA-flushing}-->CLOSABLE
                |-->[Send ACK_FLUSH]-->[Notify]
     |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
     |--{On retransmission Timeout}<-->[Retransmit MULTIPLY]
     |--{On transient state Timeout}-->NON_EXISTENT-->[Notify]

     CLONING is a state entered by ULA calling the API Multiply from any
     state that may accepting an out-of-band packet.




Gao                     Expires January 16, 2019               [Page 32]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


6.  End-to-End Negotiation
   End-to-end negotiation of FSP session occurs in the connection
   establishment phase. Connection establishment process of FSP consists
   of two and a half pairs of packet exchanges for connection
   initialization, weak key agreement and the last confirmation. During
   the process various optional header or payload MAY be carried in the
   FSP preliminary packets to negotiate end-to-end session parameters.

6.1. Connect Initialization

   The initiator sends the INIT_CONNECT packet to the responder:
   (INIT_CONNECT, Timestamp, Init-Check-Code, Salt [, Responder's Host
   Name])

   Connection initialization MAY be syndicated with optional address
   resolution at the gateway in the IPv6 network by carrying the
   responder's host name in the Connect Initialization packet.

   If it does carry the responder's host name it MUST take the link-
   local interface address as the source IPv6 address and the default
   link-local gateway address, FE80::1 as the destination IPv6 address
   no matter whether the global unicast IP address of the default
   gateway is configured. In such scenario the link-local gateway MUST
   be able to resolute the responder's host name to its global unicast
   IPv6 address, and the gateway MUST be able to map the initiator's
   link local address to its global unicast IPv6 address.

   If the gateway that relays the INIT_CONNECT packet finds that the
   responder is on the same link-local network with the initiator it
   SHALL change the source and the destination IP addresses of the
   INIT_CONNECT packet to the link-local IP addresses of the initiator
   and the responder, respectively, and relay the packet onto the same
   link-local network.

   On receiving the FSP Connect Initialization packet that carries the
   responder's host name the link-local gateway MUST resolute the
   responder's global unicast IPv6 address and map the initiator's
   global unicast IPv6 address, and replace the destination and source
   address of the FSP Connect Initialization packet, respectively.

   The gateway SHALL silently ignore the FSP Connect Initialization
   packet that does not carry the responder's host name payload if the
   destination address is the default link-local gateway address, or if
   the gateway is unable to resolve the IP address of the responder.

6.2. Response to Connect Initialization

   The responder sends acknowledgment to the initiator:



Gao                     Expires January 16, 2019               [Page 33]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   Case 1: (ACK_INIT_CONNECT, Cookie, Echo of Init-Check-Code, Time-
   delta)

   Case 2: (RESET, Echo of Timestamp, Echo of Init-Check-Code, Reason of
   Failure)

   In case 1 the responder is ready to accept the connection. It MUST
   not make state transition on receiving INIT_CONNECT packet. It just
   generates a cookie which is meant to be echoed back by the initiator.
   The responder MUST send the ACK_INIT_CONNECT packet with the new
   allocated local ULTID instead of the original listening ULTID. The
   initiator should be able to find out the original listening ULTID by
   searching its own connection context.

   In case 2 the responder refuses to accept the connection. It SHALL
   send back a RESET packet with the listening ULTID as the source
   ULTID.

   In either case the destination address of the packet sent back MUST
   be set to the source address of the corresponding Connect
   Initialization packet whose source and destination address MAY be
   updated by some intermediary such as the link-local gateway of the
   initiator.

6.3. Weak Key Agreement Request

   (CONNECT_REQUEST, Timestamp, Init-Check-Code, Salt, Echo of Cookie,
   Echo of Time-delta, Initial SN, Initiator's Sink Parameter [,
   Initiator's Host Name])

   The initiator accepts the Response to Connect Initialization packet
   if and only if both the destination ULTID of the response packet
   matches the source ULTID of the connect initialization packet and the
   echo of the Init-Check-Code in the response packet matches the Init-
   Check-Code in the connect initialization packet.

   If the response packet is accepted the initiator formally requests to
   establish the connection by sending the CONECT_REQUEST packet.

   In the CONNECT_REQUEST packet the value of the Timestamp, the Init-
   Check-Code and the Salt field MUST be the same as in the INIT_CONNECT
   packet while the value of the Echo of Cookie field and the Echo of
   Time-delta field MUST be the same as in the ACK_INIT_ CONNECT packet,
   respectively.

   The initiator MUST send the packet towards the remote ULTID that the
   responder has preserved and sent with the ACK_INIT_CONNECT packet. It
   MUST fill the original listener ID field in the Initiator's Sink



Gao                     Expires January 16, 2019               [Page 34]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   Parameter with the right value.

   The source address of the CONNECT_REQUEST packet MUST be set to the
   destination address of the received ACK_INIT_CONNECT packet, while
   the network prefix and host-id part of the destination address MUST
   be set to the source address of the received ACK_INIT_CONNECT packet
   in the IPv6 network.

   The initiator SHALL save the cookie value that the responder has
   given to make up the weak session key.

   The initiator MUST fill the Initial SN field with the sequence number
   of the packet that will follow CONNECT_REQUEST. The CONNECT_REQUEST
   packet is payload free and does not consume the sequence space.

6.4. Weak Key Agreement Response

   Case 1: (ACK_CONNECT_REQ, Initial SN, Expected SN, Timestamp, FREWS,
   Responder's Sink Parameter[, Payload])

   Case 2: (RESET, Echo of Timestamp, Echo of Echo of Cookie, Reason of
   Failure) The responder responds as in case 1 if the echo of cookie
   was valid, resources were successfully allocated and the initial
   context of the connection was setup. Otherwise it SHOULD respond as
   in case 2.

   The Initial SN in case 1 is the initial sequence number of the
   responder. The responder should fill in the field with a random 32-
   bit unsigned integer. As the ACK_CONNECT_REQ packet may carry payload
   the sequence number of the responder starts from the ACK_CONNECT_REQ
   packet.

   The Expected SN MUST equal to the Initial SN specified in the
   corresponding CONNECT_ REQUEST packet. In the Responder's Sink
   Parameter the original listener ULTID MUST be set to the right value.

6.5. The Last Confirmation

   Case 1: (ACK_Start, Initial SN, Expected SN, ICC, FREWS[, Initiator's
   Sink Parameter])

   Case 2: (PERSIST, Initial SN, Expected SN, ICC, FREWS, payload)

   Case 3: (RESET, Initial SN, Expected SN, ICC, Reason of Failure)

   The initiator of the connection MUST eventually confirm to the
   responder that the connection is established by sending a payload-
   less ACK_START packet (case 1) or a PERSIST packet with payload (case



Gao                     Expires January 16, 2019               [Page 35]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   2).

   Of course the initiator MAY quit to establish the connection by
   sending a legitimate RESET packet (case 3).

6.6. Retransmission

   The initiator SHALL retransmit the INIT_CONNECT packet if the
   corresponding ACK_INIT_CONNECT packet is not received in some limit
   time (by default 15 seconds).

   The initiator SHALL retransmit the CONNECT_CONNECT packet if the
   corresponding ACK_CONNECT_REQ packet is not received in some limit
   time (by default 15 seconds).

   The responder SHALL NOT retransmit ACK_INIT_CONNECT or
   ACK_CONNECT_REQ packet.

   The initiator SHOULD retransmit the right INIT_CONNECT packet or
   CONNECT_CONNECT packet until the legitimate ACK_CONNECT_REQ packet is
   eventually received.

   It SHALL give up if the time starting from the very first
   INIT_CONNECT packet was sent has exceed a longer timed-out value (by
   default 60 seconds) before the legitimate ACK_CONNECT_REQ packet is
   received.

7.  Quad-party Session Key Installation

   It assumes that in the scenarios applying FSP it is the ULA to do key
   establishment and/or end-point authentication while the FSP layer
   provides authenticated, optionally encrypted data transfer service.
   Together they establish a secure channel between two application end-
   points.

   Protocol for installation of the shared secret key is quad-party in
   the sense that both the upper layer application and the FSP layer of
   both the participant nodes MUST agree on the moment of certain state
   to install the shared secret key.

   It is arguably much more flexible for the application layer protocols
   to adopt new key establishment algorithm while offloading routine
   authentication and optionally encryption of the data to the
   underlying layers where it may be much easier to exploit hardware-
   acceleration.

7.1. API for Session Key Installation




Gao                     Expires January 16, 2019               [Page 36]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   A dedicate application program interface (API) is designed for the
   ULA to install the secret key established by the ULA participants.
   The API SHOULD take four parameters:

   - A 'handle' to state the connection context for installing the
   session key
   - A octet string of initial key materials (IKM)
   - An integer to state the length of IKM. The unit is octet.
   - An integer to state the desired length of the effective session key
   if AEAD is applied. The unit is bit. For this version of FSP desired
   length of the effective session key is either 128 or 256.

7.2. Time to Call API for Session Key Installation

   The ULA participant that installs the new secret key firstly MUST be
   the one that is committing a transmit transaction after it has
   accepted peer's transmit transaction commitment.

   In a typical scenario the ULA endpoints first setup the FSP
   connection where resistance against connection redirection is weakly
   enforced by CRC64.

   After the pair of ULA endpoints establish a shared secret key, they
   install the secret key and commit current transmit transactions.
   Authenticity of the FSP packets sent later is cryptographically
   protected by the new secret key and resistance against various
   attacks is secured.

7.3. Time to Take New Session Key into Effect

   The FSP layer SHALL make it sure that the new secret key is taken
   into effect starting from the very first packet of the transmit
   transaction that is next to the transmit transaction whose context is
   where the new secret key is installed. Although transmit transaction
   is actually uni-directional the secret key is shared bi-directionally
   in this version of FSP.

   By committing a transmit transaction a ULA participant clearly tells
   the underlying FSP layer that the next packet sent MAY adopt a new
   secret key. On receiving a packet with the EoT flag set the ULA is
   informed that the next packet received MAY adopt a new shared secret
   key.

   After the ULA install a new secret key every packet sent later than
   the one with the EoT flag set MUST adopt the new secret key. The peer
   MUST have commit a transmit transaction and it SHALL install the same
   secret key on receiving the FSP packet with the EoT flag set.




Gao                     Expires January 16, 2019               [Page 37]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   The ULA SHOULD have installed the new shared secret key, or install
   it instantly after accepting the packet with the EoT flag set. If the
   new secret key has ever been installed the packet received after the
   one with the EoT flag set MUST adopt the new secret key.


7.4. Generating the Initial Session Key

   Given raw key material ikm, length of the ikm nB in octets, intended
   master key length lenb in bits, || is octet string concatenation,

   If HMAC only is designated, the nB octets of ikm is hashed into 64
   octets which is taken as the master key.

   If AEAD is designated, the initial session key, or the first secret
   key for packet authentication and payload encryption is obtained as
   specified in [RFC5869]:

   Key Extract phase,

     Let Km = BLAKE2(zeros || ikm) , where

       zeros is 32 octets of integer 0

     BLAKE2b algorithm without key is applied.

     The result Km is the master key.

   Key Expand phase,

     Let Ks = BLAKE2(Km, info) , where

       Km is the master key generated in previous phase,

       info is concatenation of the arbitrary ASCII string "Establishes
       an FSP session", which is 26-octet long, 3 octets of integer 0,
       and 1 octet of integer 1.

     BLAKE2b algorithm with key is applied. The key applied MUST be the
     master key Km.

     The result Ks is the initial session key, or the first secret key
     for packet authentication and payload encryption.

     For this version FSP Ks is a fixed-length AES key together with a
     4-octet salt. The salt is meant to be passed to AES-GCM as the
     initialization vector together with the sequence number and
     expected sequence number fields in the normal FSP fixed header:



Gao                     Expires January 16, 2019               [Page 38]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


    0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Salt                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Expected Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 12 Constitution of Initialization Vector


7.5. Internal Rekeying

   In this version of FSP it is forced to re-key on sending or receiving
   every 536870912? (2^29) packets.

   Let Ks' = BLAKE2(Km, H || info') , where:

     Km is the master key generated as in section 7.4.

     H is the 16-octet internal hash sub-key of AES-GCM of previous
     session key,

     info' is concatenation of the arbitrary ASCII string "Sustains an
     FSP connection", which is 26-octet long
     and the 4 octets in network order of the 32-bit unsigned integer
     that specifies the batch index of the session key.

   BLAKE2b algorithm with key is applied. The key applied MUST be the
   master key Km.

   The result Ks' is the new session key, together with the new salt
   meant to be form the IV.

   The batch index of the initial session key is 1, and it is increased
   by 1 every time before it is to re-key.

8.  Send and Receive

8.1. Packet Integrity Protection

8.1.1. Application of CRC64

   Starting from ACK_CONNECT_REQUEST, until the ULAs have installed the
   shared secret CRC64 is applied to calculate the value of the ICC
   field. The algorithm:




Gao                     Expires January 16, 2019               [Page 39]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   1.Take pair of the ULDs as the initial value of accumulative CRC64
     The pair of the ULDs is composed of the near end's ULTID and the
     remote end's ULTID, where the former is the leftmost 32 bits and
     the latter is the rightmost 32 bits of initial value for the send
     direction, and the order is reversed for the receive direction.

   2.Accumulate the value of the Init-Check-Code field

   3.Accumulate the value of the Cookie field successively

   4.Accumulate the combined value of the salt and the timeDelta field
     where the former is the leftmost 32 bits and the latter is the
     rightmost 32 bits

   5.Accumulate the value of the Time Stamp field

   6.Save the accumulated CRC64 value
     as the pre-computed CRC64 value.

   When calculate the value ICC of a particular FSP packet, firstly set
   ICC to the pre-computed CRC64 value, then calculate the CRC64
   checksum of the whole FSP packet, while ULTIDs are NOT included if
   the FSP packet is encapsulated in UDP. The result is set as the final
   value of the ICC field.

8.1.2. Packet Authentication Only

   The ULA designates the FSP layer to either applying HMAC only or
   applying AEAD.

   If the HMAC flag of a packet is set the pre-designated cryptographic
   hash function SHALL be applied to get the message authentication code
   (MAC) of the whole packet. Each FSP version MUST designate one and
   only one particular cryptographic hash function.

   For this FSP version, BLAKE2 [RFC7693] is designated as the
   cryptographic hash function. The input key is the secret key that has
   been derived from the master key installed by the ULA. The input data
   is the full FSP packet, where the ICC field is pre-filled the pair of
   the ULDs. As in making CRC64 checksum, the pair of the ULDs is
   composed of the near end's ULTID and the remote end's ULTID, where
   the former is the leftmost 32 bits and the latter is the rightmost 32
   bits of initial value for the send direction, and the order is
   reversed for the receive direction.

   The hash result is truncated to 64 bits to get the final ICC.

8.1.3. Authenticated Encryption with Additional Data



Gao                     Expires January 16, 2019               [Page 40]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   FSP provides per-packet authenticated encryption service. Only one
   authenticated encryption algorithm is allowed for a determined
   version of FSP. For this FSP version, the authenticated encryption
   algorithm selected is GCM-AES [GCM][AES], it is applied to protect
   integrity of the full FSP packets and privacy of the payload. The
   length of the session key is determined by the ULA. The four inputs
   to GCM-AES authenticated encryption are:

   K: the key derived by the master key installed by ULA.

   IV: the initial vector, 96-bit string made by concatenating a 32-bit
   salt, the 32-bit sequence number of the packet and the 32-bit
   expected sequence number field of the packet. The salt is derived by
   the master key installed by ULA.

   P: the plaintext are the bytes following the fixed header up to the
   end of the original payload

   AAD: additional authenticated data, from the source ULTID to the last
   byte of the fixed header. The source ULTID is stored in the leftmost
   32-bit of the ICC field while the destination ULTID is stored in the
   rightmost 32-bit of the ICC field before the ICC value is calculated.
   The length of the authentication tag MUST be 64 bits for FSP version
   0 and 1. The authentication tag is stored in the ICC finally. The
   inputs to GCM-AES decryption are:

   K: the key installed by ULA.

   IV: the initial vector, 96-bit string made by concating consisted of
   the salt, the 32-bit sequence number of the packet and the 32-bit
   expected sequence number field of the packet. The internal 32-bit
   salt MUST be the XOR result of the leftmost two 32-bit words of the
   hash sub-key.

   C: the ciphertext are the bytes following the fixed header up to the
   end of the received payload

   AAD: additional authenticated data, from the source ULTID to the last
   byte of the fixed header. The source ULTID is stored in the leftmost
   32-bit of the ICC field while the destination ULTID is stored in the
   rightmost 32-bit of the ICC field before the ICC value is calculated

   T: The authentication tag, which is fetched from the ICC field
   received Only when the outputs of GCM-AES decryption tell that the
   authentication tag passed verification may the receiver deliver the
   decrypted payload to the ULA.





Gao                     Expires January 16, 2019               [Page 41]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


8.2. Start a New Transmit Transaction

   The responder starts AND terminates a transmit transaction by send
   the ACK_CONNECT_REQ packet.

   The initiator starts a new transmit transaction by sending a PERSIST
   packet:

     (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload)

   Or starts AND terminates a transmit transaction by send the ACK_START
   packet:

     (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter])

8.3. Send a Pure Data Packet

     (PURE_DATA, SN, ExpectedSN, ICC, FREWS, Payload)

   After a new transmit transaction has been started further PURE_DATA
   packet MAY be sent until a packet with EoT flag set is sent.

8.4. Commit a Transmit Transaction

8.4.1. Initiate Transmit Transaction Commitment

   A participant of an FSP connection MAY notify its peer that a
   transmit transaction shall be committed by setting the EoT flag of
   the last packet of the transmit transaction, be it PERSIST,
   ACK_START, PURE_DATA or MULTIPLY.

8.4.2. Respond to Transmit Transaction Commitment

     (ACK_FLUSH, SN, ExpectedSN, ICC, FREWS)

   If and only if all of the packets in a transmit transaction has been
   received MAY ACK_FLUSH packet be sent.

   Whenever a legitimate packet falls in the receive window of the
   receiver, and the packet fills in the last gap of the sequence of
   current transmit transaction on receiving direction, or the packet
   with same sequence number has been accepted already, a responding
   ACK_FLUSH SHALL be sent back immediately, and the FSP layer MUST
   immediately notify the ULA that a transmit transaction has been
   committed.

8.4.3. Finalize Transmit Transaction Commitment




Gao                     Expires January 16, 2019               [Page 42]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   After receiving the ACK_FLUSH packet the sender of the EoT flag
   migrates to the COMMITTED or CLOSABLE state from the COMMITTING or
   COMMITTING2 state, respectively.

8.4.4. Time-out for Committing Transmit Transaction

   The ULA SHALL be timed-out if there is no packet was acknowledged in
   some hard-coded time-out. For this version of FSP the time-out is set
   to 30 seconds.

8.5. Retransmission

   Any packet sent 4RTT earlier that is negatively acknowledged MUST be
   retransmitted as soon as possible.

8.5.1. Calculation of RTT

   Initial RTT for the Connection Initiator: Equals to the mean of the
   time elapsed when ACK_ INIT_CONNECT was received since INIT_CONNECT
   was sent, and the time elapsed till ACK_CONNECT_REQ was received
   since CONNECT_REQUEST was sent.

   Initial RTT for the Connection Responder: Equals to the time elapsed
   when the ACK_START or the first PERSIST packet was received since
   ACK_CONNECT_REQ was sent.

   Initial RTT for the Initiator of Connection Multiplication: Equals to
   the time elapsed when the first PERSIST packet was received since
   MULTIPLY was sent.

   Initial RTT for the Responder of Connection Multiplication: Equals to
   the most recent RTT of the multiplied connection.

   Each time a SNACK or an accumulated acknowledgment is received the
   round trip time of the packet with most expected SN is calculated.
   The round trip time is the difference between the time when the
   KEEP_ALIVE packet that carried the acknowledgement was received and
   the time when the original packet was sent, minus the delay given in
   the SNACK optional header of the KEEP_ALIVE packet. Suppose the
   result is RTT_now, then:

   RTT_new = (RTT_old + RTT_now) / 2

8.5.2. Generation and transmission of SNACK

   Whenever the receiver receives a packet it SHALL shift the time to
   send next heartbeat signal earlier to the time of RTT since current
   time, if the time to send next heartbeat signal used to be later. If



Gao                     Expires January 16, 2019               [Page 43]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   the time is already earlier than the time of RTT since current time,
   it needs not be shifted.

   On the time to send the heartbeat signal the FSP node generates the
   SNACK header, then generate and send a new KEEP_ALIVE or ACK_FLUSH
   packet to carry the SNACK header. It SHALL send an ACK_FLUSH if it is
   in PEER_COMMIT, COMMITTING2 or CLOSABLE state, otherwise it SHALL
   send a KEEP_ALIVE packet.

8.5.3. Negative acknowledgment of Packets Sent

   Both the ACK_FLUSH and the KEEP_ALIVE packet in FSP carry the SNACK
   extension header, although number of gap descriptors in the SNACK
   extension header in the ACK_FLUSH packet MUST be 0. We call them
   SNACK packets. A SNACK packet P1 is said to be later than P0, if and
   only if SN of P1 is later than SN of P0, or SN of P1 equals SN of P0
   while the out-of-band sequence number of P1 is later than the out-of-
   band sequence number of P0. If the latest SNACK packet is ACK_FLUSH,
   all the packets with the sequence number later that the expected
   field of the packet are assumed to be negatively acknowledged.

   By convention when we specify the range, the left square bracket
   meant to be inclusive, while the right parenthesis meant to be
   exclusive, the packets with SN in the ranges:
     [expectedSN, expectedSN + 1st Gap Width),

     [expectedSN + 1st Gap Width + 1st Data Length,
      expectedSN + 1st Gap Width + 1st DataLength + 2nd Gap Width),

     ...

     [expectedSN + 1st Gap Width + 1st Data Length
        + ... + (n-1)th Gap Width + (n-1)th Data Length,
      expectedSN + 1st Gap Width + 1st DataLength
         + ... + n-th Gap Width),

   together with the packets with SN later than {expectedSN + 1st Gap
   Width + 1st DataLength + ... + n-th Gap Width} are assumed to be
   negatively acknowledged, if the latest SNACK packet is KEEP_ALIVE.

8.6. Flow Control

   The participants of an FSP connection negotiate the initial receive
   window size with the FREWS field in the ACK_CONNECT_REQUEST packet
   and the first PERSIST packet, respectively. The receive window size
   SHALL NOT be less than 4 and SHALL be less than 2^24.

   An FSP participant advertises the receive window size in the FREWS



Gao                     Expires January 16, 2019               [Page 44]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   field.

   An FSP participant SHALL NOT send a packet whose sequence number is
   later than its peer's ExpectedSN plus its peer's advertised receive
   window size.

8.7. On-the-Wire Compression
                          (Application of LZ4)
   Stream-mode
   Segment length
   Per-transaction

9.  Graceful Shutdown

   One participant of an FSP connection MAY initiate graceful shutdown
   of the connection if and only if its peer has committed the most
   recent transmit transaction.

   By initiating graceful shutdown the participant tells its peer that
   current transmit transaction is to be committed as well.

9.1. Initiation of Graceful Shutdown

     (RELEASE, SN, ExpectedSN, ICC, FREWS)

   An FSP end node MAY initiate graceful shutdown if the connection is
   in the PEER_COMMIT, COMMITTING2 or CLOSABLE state only.

   Graceful shutdown is signaled to the remote end by sending a RELEASE
   command packet. The FSP connection SHALL migrate to the PRE_CLOSED
   state just before sending the RELEASE packet.

9.2. Acknowledgment of Graceful Shutdown

     (RELEASE, SN, ExpectedSN, ICC, FREWS)

   The RELEASE packet may be accepted in the COMMITTING, COMMITTED,
   COMMITTING2, CLOSABLE or PRE_CLOSED state only.

   If it is accepted in the COMMITTING, COMMITTED, COMMITTING2 state the
   sender's current transmit transaction is supposed to be committed.
   The receiver automatically migrates to the CLOSABLE state. The ULA
   SHALL be notified with such migration and it SHOULD process the
   committed transmit transaction as soon as possible.

   If the receiver of the RELEASE packet is in CLOSABLE state the ULA
   SHALL be notified with the connection shutdown request.




Gao                     Expires January 16, 2019               [Page 45]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   In all of these cases a reverse RELEASE packet MUST be sent
   immediately after the original RELEASE packet is received.

   If the RELEASE packet is received in the PRE_CLOSED state it is
   supposed that the grace shutdown request is acknowledged. The
   connection SHALL migrate to CLOSED state immediately.

9.3. Finalization of Graceful Shutdown

   If a legitimate RELEASE command packet is received in the COMMITTING,
   COMMITTED, COMMITTING2 or CLOSABLE state the receiver is passively
   shutdown, and the shutdown is finalized in the sense that it does not
   expect any acknowledgement of the reverse RELEASE packet required to
   be sent, although race condition may occur.

   The FSP node in the PRE_CLOSED state migrates to the CLOSED state
   after the corresponding RELEASE packet is received. It is supposed
   that the original grace shutdown request is acknowledged and the
   shutdown is finalized.

   Graceful shutdown in FSP is asymmetric in the sense that it does not
   require both ULA participants to call the Shutdown API.

9.4. Retransmission of RELEASE Packet

   The FSP end node in the PRE_CLOSED state SHALL retransmit the RELEASE
   packet until it migrates to CLOSED state or it is timed out. Interval
   between the retransmission is hard-coded to 4 times of RTT.

   The RELEASE packet that was sent in the COMMITTING, COMMITTED,
   COMMITTING2 or CLOSABLE state state shall never be retransmitted.

10  Mobility and Multi-home Support

10.1. Heartbeat Signals

   FSP requires that the participants periodically send the heartbeat
   signals.

   The participant in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT,
   COMMITING2 or CLOSABLE state MUST send the KEEP_ ALIVE packet as the
   heart-beat signal periodically to retain the connection in case that
   underlying IP address has changed.

     (KEEP_ALIVE, SN, ExpectedSN, ICC, FREWS, Sink Parameter, SNACK)

   Heartbeat signal is an out-of-band control packet. It does not carry
   payload. The sequence number of the KEEP_ALIVE packet SHALL be set to



Gao                     Expires January 16, 2019               [Page 46]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   the latest sequence number of all of the packets that have been sent.

   Only the FSP node in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT,
   COMMITING2 or CLOSABLE state MAY process the heartbeat signal.

   In this version of FSP the heat-beat period is arbitrarily set to 600
   seconds.

10.2. Active Address Change Signaling

   During communication process the FSP participant whose underlying IP
   address is changed SHOULD inform its peer such change by transmit a
   KEEP_ALIVE packet with the Sink Parameter extension header and the
   SNACK header so that the peer can retransmit the packets that were
   negatively acknowledged.

   Such informing KEEP_ALIVE packet SHALL be sent in the ACTIVE,
   COMMITTING, COMMITTED, PEER_COMMIT, COMMITING2 or CLOSABLE state.

   Informing KEEP_ALIVE packet SHOULD be sent more frequently than a
   normal heart-beat signaling KEEP_ALIVE packet.

   For this version of FSP informing KEEP_ALIVE packet SHALL be
   retransmitted every 4 RTT interval until the heuristic
   acknowledgement is received.

10.3. Heuristic Remote Address Change Adaptation

   A participant of the FSP connection SHALL set the source address of
   the packet to transmit or retransmit to new IP address as soon as the
   near-end IPv4 address or IPv6 network prefix has changed. The ULTID
   field MUST remain the same.

   When a new packet with a later sequence number is received and the
   source IP address of the packet is found to be different with the
   preserved IP address of the remote end, the receiver SHOULD
   automatically update the preserved IP address of the remote end to
   the source IP address of the new packet, unless there is a Sink
   Parameter header in the packet.

   If the sequence number of the packet received is not the latest in
   the receive window the preserved IP address of the remote end SHALL
   NOT be updated even if the source address of the received packet has
   changed.

10.4. Heuristic Address Change Acknowledgement

   The address change signaling KEEP_ALIVE packet is supposed to be



Gao                     Expires January 16, 2019               [Page 47]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   acknowledged if a packet targeted at the new IP address that the
   KEEP_ALIVE packet has informed is received.

10.5. Explicit Multi-home Informing

   If an FSP end node is configured with multiple IPv4 address other
   than the loop-back address, or with multiply global unicast IPv6
   address, it MAY advertise multiple underlying addresses to the remote
   end by put them in the addressable network prefix list of the Sink
   Parameter extension header. The Sink Parameter extension header may
   be carried in the CONNECT_REQUEST, ACK_CONNECT_REQ, ACK_START,
   MULTIPLY or KEEP_ALIVE packet.

   Any participant of the communication SHALL NOT make discrimination of
   the source or destination IP address of any packet provided that both
   the source ULTID and the destination ULTID keep unchanged and the ICC
   field passes verification.

11  Connection Multiplication

   Connection multiplication is the process of incarnating a new
   connection context by re-using security context of an established
   connection.

11.1. Request to Multiply Connection

     (MULTIPLY, SN, Salt, ICC, FREWS [, Sink Parameter] [, payload])

   The initiator's initial sequence number of the new connection is the
   sequence number of the packet that piggybacks the connection
   multiplication header. The ExpectedSN field of the normal packet
   store a Salt value instead.

   The FREWS field MUST be processed in the new connection context while
   the ICC MUST be calculated with the session key of the original
   connection.

   The new connection inherits the remaining key life. ULA SHOULD
   negotiate new session key and/or install new session key as soon as
   possible.

   The optional payload of the MULTIPLY packet MUST be processed in the
   new connection context.

   The MULTIPLY packet is an out-of-band command packet in the original
   connection context.

11.2. Response to Connection Multiplication Request



Gao                     Expires January 16, 2019               [Page 48]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


     Case 1: (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter])

     Case 2: (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload)

     Case 3: (RESET, SN, ExpectedSN, ICC, FREWS, Reason of Failure)

   In all of these cases the ULTID of the remote-end MUST be the value
   of the initiator's ULTID in the connection multiplication header.

   In case 1 the responder admits the multiplication request AND commit
   the transmit transaction, the new connection enters into the
   PEER_COMMIT or CLOSABLE state immediately, on request of ULA.

   In case 2 the responder admits the multiplication request and the new
   connection enters into the ESTABLISHED, PEER_COMMIT, or COMMITTING or
   CLOSABLE state immediately, depending whether the ULA of the
   multiplication initiator has requested to commit the transmit
   transaction immediately and whether the ULA of the multiplication
   responder has requested to commit the transmit transaction in the
   reverse direction immediately.

   In case 3 the responder rejects the multiplication request. To defend
   against spoofing attack ICC MUST be valid. The value of the SN field
   MUST equal the value of the 'Expected SN' field of the requesting
   MULTIPLY packet while the value of ExpectedSN field MUST equal the
   value of the 'Sequence No' field.

   The new connection MUST derive new session key from the session key
   of the original connection where the out-of-band requesting MULTIPLY
   packet is received immediately.

11.3. Duplicate Detection of Connection Multiplication Request

   Every time the responder of connection multiplication receives a
   MULTIPLY packet it MUST check the suggested responder's ULTID and the
   initiator's ULTID.

   The responder MUST reject the multiplication request if the suggested
   responder's ULTID equals the near-end ULTID of some connection and
   the remote-end ULTID of that connection does not equal the
   initiator's ULTID.

   The responder MUST recognize the MULTIPLY packet as a duplicate
   connection request if some connection matches the request and SHOULD
   response by retransmitting the head packet of the send queue of the
   matching connection, be it a PERSIST or an COMMIT packet. A
   connection matches the MULTIPLY request if and only if the suggested
   responder's ULTID in the MULTIPLY packet equals the near-end ULTID of



Gao                     Expires January 16, 2019               [Page 49]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   the connection and the initiator's ULTID equals the remote-end ULTID
   of the connection.

11.4. Retransmission

   The initiating side SHALL retransmit the MULTIPLY packet if the
   corresponding PERSIST packet is not received in some limit time (by
   default 15 seconds).

11.5. Key Derivation for Branch Connection

   Let K_out = BLAKE2(Km, [d] || Label || 0x00 || Context || L), where:

     - Km
       is the master key,

     - [d]
       is one octet of integer Depth. It is alike the KDF counter mode
       as the NIST SP800-108. For this version of FSP it is the fixed
       number 1,

     - Label
       is the fixed ASCII string "Multiply an FSP connection" which is
       26-octet long for this version of FSP,

     - Context
       is concatenation of two 32-bit words idB and idR

       idB is the ULTID allocated for the branch connection in the
       context of the multiplication initiator. idB is byte-order
       neutral.

       idR is the receiver side ULTID of the original connection that is
       to accept the connection multiplication request. idI or idR is
       byte-order neutral.

     - L
       is a 32-bit network byte-order integer specifying the length in
       bits of the derived key K-out

12  Timeouts and Abrupt Close

12.1. Timeouts in End-to-End Negotiation

   Initially the initiator is in the CONNECT_BOOTSTRAP state. It
   migrates to the CONNECT_ AFFIRMING state after it received the
   legitimate ACK_INIT_CONNECT packet. Then it migrates to the
   PEER_COMMIT or CLOSABLE state after it received the legitimate



Gao                     Expires January 16, 2019               [Page 50]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   ACK_CONNECT _REQ packet, depending on the hint of ULA.

   The responder incarnates a new connection context which is initially
   in the CHALLENGING state after accepting a legitimate Connect Request
   packet. Then it migrates to the COMMITTING or CLOSABLE state,
   depending on the packet received from its peer.

   If the initiator or the responder is unable to migrate to a new state
   in some limit time (by default 60 seconds, except in LISTENING state)
   it aborts the connection by recycling the connection context.

12.2. Timeouts in Multiply

   Initially the initiating side of Connection Multiplication is in the
   CLONING state. It migrates to the ACTIVE, COMMITTED, PEER_COMMIT or
   CLOSABLE state after it received the legitimate PERSIST packet. Which
   state to migrated depends on the EoT flag of the initiating MULTIPLY
   packet and the responding PERSIST packet.

   If the initiating side is unable to migrate to a new state in some
   limit time (by default 60 seconds) it aborts multiplication by
   recycling the new connection context.

12.3. Timeout of Transmit Transaction Commitment

   The FSP node MUST abort the connection if the time of no packet
   having arrived has exceed certain limit in the COMMITTING or
   COMMITTING2 state.

   In this FSP version, timeout of transmit transaction commitment is
   set to 5 minutes.

12.4. Timeout of Graceful Shutdown

   It simply migrates to the NON_EXISTENT pseudo-state if timeout in the
   PRE_CLOSED state.

   In this FSP version, timeout of Graceful Shutdown is set to 1 minute.

12.5. Idle Timeout

   If one participant has not received any packet is a limit time, it
   MUST be abruptly closed.

   In this FSP version idle timeout is set to 4 hours.

12.6. Session Key Timeout




Gao                     Expires January 16, 2019               [Page 51]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   For this FSP version if a secret key is applied for more than 2^30
   times the FSP node MUST abruptly closed instantly.

12.7. Abrupt Close

   An FSP node abruptly shutdown a session by sending a RESET packet and
   release all of the resource occupied by the the session immediately.

     (RESET, SN, ExpectedSN, ICC, Reason of Failure)

13  Issues for Further Study

13.1. Milk-type Payload and Minimal Delay Service

   An ordinary data flow is wine-type in the sense that the older data
   are of leftmost value. If it has to, data packet sent latest are
   dropped first.

   In the contrary, milk-type payload is that the newer data are more
   precious and outdated data packet can be discarded.

   When ULA is willing to accept incomplete message the peer of the
   underling FSP node should set the MIND flag of every FSP PURE_DATA
   packet, while set the Traffic Class of the underlying IPv6 packet to
   some registered value.

   In the transmission path, any relaying middle box, be it router or
   switch, should reserve a reasonably short queue for the packet flow
   of such flow to minimize delay.

   When the receive buffer overflows the receiver discards the
   undelivered packet received first to free buffer space for the latest
   packet received. However it keeps order on delivering the packets to
   he ULA. ULA may choose to discard packets received earlier than some
   threshold.

   Optional forward-error-correction feature should be exploited to
   enhance reliability of data transfer under MIND mode.

13.2. Resolution of ULTID in DNS

   There are two patterns of IP address resolution in FSP: the DNS-
   compatible pattern and the proxy pattern. The former pattern relies
   on some name service to resolve the IP address of the responder for
   the initiator before they exchange end-to-end packets.

   The latter embeds the address resolution information in the
   connection bootstrap packets and works in the FSP over IPv6 only.



Gao                     Expires January 16, 2019               [Page 52]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   In the DNS-compatible pattern, the responder side of the FSP
   participants registered its address identifier, such as 'domain name'
   in some name service such as DNS, according to some pre-agreement at
   first. The initiator resolves the current IP address of the responder
   by consulting the name service, such as looking after the A or AAAA
   record of the domain name in DNS.

   In IPv6 network the rightmost 32 bits of the IPv6 address directly
   maps to the ULTID so FSP does not need additional multiplexing
   mechanism such as port number. Here it needs not consult SRV record
   or look for some entry in some 'services' file.

   If UDP over IPv4 is exploited as the layer data packet delivery
   service the port number of the responder is firstly resolved just
   alike normal network application such as HTTP and is extended to 32-
   bit ULTID. Here ULTIDs of FSP can be considered as the superset of
   TCP port numbers.

   If the string representation of IPv4/IPv6 address is applied directly
   as the peer's address identifier instead of the domain name there is
   no need for some real address resolution. But from the API caller's
   point of view it is a DNS-compatible mode address resolution.

13.3. Optimizing FSP towards IPv6

   There are some interesting points to integrated FSP with IPv6 in
   besides integrated proxy mode of host name resolution.

   Originally FSP is optimized towards IPv6 and 64-bit computing. In
   fact, the upper layer application is assumed to be addressed with
   IPv6-compatible address even in a pure IPv4 network.

   To utilize IPv6 address space more efficiently FSP makes some slight
   tuning of address architecture when working over the IPv6 network. In
   an IPv6 packet that carries FSP payload each of the source and
   destination 128-bit IPv6 address is split into three parts: the 64-
   bit network prefix, the 32-bit aggregation host id and the 32-bit
   ULTID.

   When FSP is applied in an IPv6 networks, the lower layer addresses
   SHALL be IPv6. The rightmost 32 bits of each IPv6 address is
   designated as the ULTID which MUST keep unchanged across IPv6 address
   migration or translation. The leftmost 96 bits still holds the
   routing locator semantics. It can be argued that the routing
   scalability problem in the IPv6 network is effectively eliminated by
   such tuning of IPv6.

   One FSP connection MAY associate with up to 4 lower layer addresses.



Gao                     Expires January 16, 2019               [Page 53]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   Besides the IP addresses associated with an FSP connection MAY change
   after the FSP connection is established.

13.4. Binding End-to-End Negotiation with Resource Reservation

   End-to-End resource reservation protocol packets MAY be piggybacked
   on preliminary FSP packets in the connection establishment process to
   provide determinant quality of service.

13.5. Path Selection and PMTU

   When FSP is implemented over UDP in the IPv4 network, each endpoint
   of the FSP connection is bound one and only one IPv4 address as soon
   as the connection is established. Each endpoint SHALL choose the
   source IPv4 address of the last packet received as the destination
   IPv4 address of the packet that it is to send later. By this mean FSP
   over UDP is NAT-friendly.

   When FSP is implemented over IPv6 as soon as the connection is
   established the IPv6 address may be changed dynamically, and one more
   alternate IP address may be added or removed dynamically for
   individual endpoint as well, provided that ULTID part keeps unchanged
   while the host IDs part of all IPv6 address of the endpoint are of
   the same value at any given moment.

   The sender may choose as the source IP address by selecting any
   network prefix that it has most-recently sent to its peer in the
   allowed address list field of the Sink Parameter header, joining with
   the host ID in the Sink Parameter header and the stable ULTID of the
   sender, and choose as the destination IP address by selecting any
   network prefix in the allowed address list field of the Sink
   Parameter header most-recently received from its peer, joining with
   the peer's host ID and the peer's ULTID. Thus multiple multi-homed
   paths MAY co-exist between the two FSP endpoints.

                         (PMTU to be discussed)

13.6. Host-Aggregated Congestion Control

                      (To be investigated further)

13.7. Asymmetric Transmission

   If there is one participant whose receiving interface is not the same
   as the transmission interface the participant is called an
   asymmetric-transmission node.

   Asymmetric-transmission itself is asymmetric in the sense that one



Gao                     Expires January 16, 2019               [Page 54]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   participant may be asymmetric-transmission node while its peer is
   normal node of symmetric transmission.

   An end node is of asymmetric-transmission if it received an
   ACK_CONNECT_REQ packet, ACK_START or PERSIST packet whose source IP
   address that the network interface accepting the packets reported is
   not in the allowed IP address list in the Sink Parameter header of
   the packet.

   For an asymmetric-transmission remote end, the near end cannot rely
   on automatic IP address change detection. Instead IP address change
   notification mechanism shall be utilized.

13.8. Connection Resurrection

   A connection in CLOSED state MAY be resurrected provided that the
   session key has not run out of life. The ULA should be able to reuse
   the security context of a closed connection established between the
   two end nodes that are meant to negotiate a new connection.

13.9. Architectural evolutions to transit towards IPv6

   To implement FSP, there is some subtle tuning of IPv6 network
   architecture:

   o Split of IPv6 address
     Each physically network interface that has IPv6 address configured
     SHALL NOT have the network prefix configured longer than 96 bits,
     no matter that the IPv6 address is assigned by Stateless Address
     Autoconfiguration ([RFC4862]), stateful Dynamic Host Configuration
     Protocol for IPv6 ([RFC3315], [RFC3633]) or by some other means.

     Whenever an IPv6 interface is reconfigured, the leftmost 64 bits of
     any IPv6 address MAY change freely, the centermost 32 bits SHOULD
     be stable while the rightmost 32 bits MUST keep unmodified.

   o The ULA is the ultimate IPv6 end-point

   o Every network node is effectively a router
     Especially when FSP over UDP in the IPv4 network is exploited if
     one network end node of the participants is not a router in the
     traditional sense, the node is treated as if it were a router
     connecting the IPv6 addressed ULAs across the IPv4 network.








Gao                     Expires January 16, 2019               [Page 55]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


14  Security Considerations

14.1. Resistance against Deny of Service Attack

   FSP is designed to resist against DoS attack by exploiting concept of
   Cookie.

   However, resistance against distributed DoS attack relies on external
   mechanism such as DOTS[DOTS architecture]

14.2. Resistance against Replay Attack

   In-band sequence number and out-of-band sequence number are exploited
   to resist against replay attack.

14.3. Resistance against Passive Attacks

   AEAD MAY be exploited by the ULA to protect it against passive
   attacks such as eavesdropping, gaining advantage by analyzing the
   data sent.

   MAC only service MAY also be utilized. Together with application
   layer stream-mode encryption it protects the ULA against passive
   attacks as well.

14.4. Resistance against Masquerade Attack

   Both AEAD and MAC only service may be exploited to protect the
   endpoints against masquerade attack.

14.5. Resistance against Active Man-In-The-Middle Attack

   The ULA SHALL take account to protect itself against MITM attack when
   making client authentication and key establishment.

14.6. Privacy concerns

   It is beneficial for privacy protection that the ULTID of each
   endpoints of an FSP connection is generated randomly [RFC7721].

15  IANA Considerations

   It should be requested that the port number registered for UDP
   packets encapsulating FSP in the IPv4 network. The port number 18003
   is exploited in the concept prototype implementation. The number is
   the decimal presentation of ASCII codes of the character 'F' and 'S'
   concatenated in network byte order.




Gao                     Expires January 16, 2019               [Page 56]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   It should be requested that the 'Next Header'/protocol number is
   assigned for FSP over IPv6. Decimal number 144 is exploited in the
   concept prototype implementation.

16  References

16.1. Normative 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>

   [OSI/RM]   ISO and IEC, "Information technology-Open Systems
              Interconnection - Basic Reference Model: The Basic Model",
              ISO/IEC 7498-1 Second edition, November 1994.
              <https://www.iso.org/standard/20269.html>

   [R01]      Rogaway, P., "Authenticated encryption with Associated-
              Data", ACM Conference on Computer and Communication
              Security (CCS'02), pp. 98-107, ACM Press, 2002.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, DOI
              10.17487/RFC1122, October 1989, <https://www.rfc-
              editor.org/info/rfc1122>.

   [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>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [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>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the



Gao                     Expires January 16, 2019               [Page 57]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226, DOI
              10.17487/RFC5226, May 2008, <https://www.rfc-
              editor.org/info/rfc5226>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869, DOI
              10.17487/RFC5869, May 2010, <https://www.rfc-
              editor.org/info/rfc5869>.

   [RFC7693]  Saarinen, M-J., Ed., and J-P. Aumasson, "The BLAKE2
              Cryptographic Hash and Message Authentication Code (MAC)",
              RFC 7693, DOI 10.17487/RFC7693, November 2015,
              <https://www.rfc-editor.org/info/rfc7693>.

   [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>.

   [STD5]     Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [STD6]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [STD7]     Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

16.2. Informative References

   [Gao2002]  Gao, J., "Fuzzy-layering and its suggestion", IETF Mail
              Archive, September 2002,
              https://mailarchive.ietf.org/arch/msg/ietf/u-6i-6f-
              Etuvh80-SUuRbSCDTwg

   [Fab1999]  Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in
              TCP and Its Effect on Busy Servers", Proc. Infocom 1999
              pp. 1573-1583.

   [tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D.



Gao                     Expires January 16, 2019               [Page 58]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


              Boneh, "The case for ubiquitous transport-level
              encryption", USENIX Security , 2010.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1644]  Braden, R., "T/TCP -- TCP Extensions for Transactions
              Functional Specification", RFC 1644, DOI 10.17487/RFC1644,
              July 1994, <https://www.rfc-editor.org/info/rfc1644>.

   [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>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3055]  Krishnaswamy, M. and D. Romascanu, "Management Information
              Base for the PINT Services Architecture", RFC 3055, DOI
              10.17487/RFC3055, February 2001, <https://www.rfc-
              editor.org/info/rfc3055>.

   [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>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <https://www.rfc-editor.org/info/rfc3315>.

   [RFC3344]  Perkins, C., Ed., "IP Mobility Support for IPv4",
              RFC 3344, DOI 10.17487/RFC3344, August 2002,
              <https://www.rfc-editor.org/info/rfc3344>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,
              <https://www.rfc-editor.org/info/rfc3596>.



Gao                     Expires January 16, 2019               [Page 59]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003, <https://www.rfc-
              editor.org/info/rfc3633>.

   [RFC3720]  Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
              and E. Zeidner, "Internet Small Computer Systems Interface
              (iSCSI)", RFC 3720, DOI 10.17487/RFC3720, April 2004,
              <https://www.rfc-editor.org/info/rfc3720>.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
              and G. Fairhurst, Ed., "The Lightweight User Datagram
              Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
              2004, <https://www.rfc-editor.org/info/rfc3828>.

   [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>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
              editor.org/info/rfc4086>.

   [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>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, DOI
              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>.

   [RFC4388]  Woundy, R. and K. Kinnear, "Dynamic Host Configuration
              Protocol (DHCP) Leasequery", RFC 4388, DOI
              10.17487/RFC4388, February 2006, <https://www.rfc-
              editor.org/info/rfc4388>.




Gao                     Expires January 16, 2019               [Page 60]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   [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>.

   [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>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, DOI
              10.17487/RFC4862, September 2007, <https://www.rfc-
              editor.org/info/rfc4862>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [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>.

   [RFC5072]  Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
              over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
              <https://www.rfc-editor.org/info/rfc5072>.

   [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>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226, DOI
              10.17487/RFC5226, May 2008, <https://www.rfc-
              editor.org/info/rfc5226>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, DOI



Gao                     Expires January 16, 2019               [Page 61]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


              10.17487/RFC5246, August 2008, <https://www.rfc-
              editor.org/info/rfc5246>.

   [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>.

   [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>.

   [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>.

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", RFC 6434, DOI 10.17487/RFC6434, December
              2011, <https://www.rfc-editor.org/info/rfc6434>.

   [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>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <https://www.rfc-editor.org/info/rfc7050>.



Gao                     Expires January 16, 2019               [Page 62]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   [RFC7157]  Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
              and D. Wing, "IPv6 Multihoming without Network Address
              Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
              <https://www.rfc-editor.org/info/rfc7157>.

   [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>.

   [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>.

   [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",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <https://www.rfc-editor.org/info/rfc7721>.

   [RFC7849]  Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
              N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
              "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, DOI
              10.17487/RFC7849, May 2016, <https://www.rfc-
              editor.org/info/rfc7849>.

   [RFC8084]  Fairhurst, G., "Network Transport Circuit Breakers",
              BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
              <https://www.rfc-editor.org/info/rfc8084>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <https://www.rfc-editor.org/info/rfc8085>.

   [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>.



Gao                     Expires January 16, 2019               [Page 63]


INTERNET DRAFT         Flexible Session Protocol           July 15, 2018


   [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>.

   [I-D.ila-mobility]
              Mueller, J. and T. Herbert, "Mobility Management Using
              Identifier Locator Addressing",  Internet-Draft draft-
              mueller-ila-mobility-03, February 2017.
              <https://datatracker.ietf.org/doc/draft-mueller-ila-
              mobility/>

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", Internet-Draft draft-ietf-quic-
              transport-03, May 2017. <https://github.com/quicwg/base-
              drafts/wiki/QUIC-Versions>




17  Acknowledgements

Authors' Addresses


   Jason Gao
   Beijing
   P.R.China

   EMail: jagao@outlook.com





















Gao                     Expires January 16, 2019               [Page 64]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/