Internet DRAFT - draft-gao-flexible-protocol

draft-gao-flexible-protocol



<Working Group Name>                                         Jason Gao
Internet Draft                                      Software Architect
Intended status: Informational                         January 3, 2018
Expires: July 2018



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


Abstract

   FSP is a connection-oriented transport layer protocol that provides
   mobility, multihoming and multipath load balancing support by
   introducing the concept of 'upper layer thread ID', which was firstly
   suggested in [Gao2002].

   It provides additional transport layer features such as ubiquitous
   message authentication with optional encryption, zero round-trip
   connection cloning, transmit transaction and quad-party shared secret
   installation facility.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November 10,
   2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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.




Gao                     Expires July 3, 2018                  [Page 1]

Internet-Draft        Flexible Session Protocol           January 2018


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 3, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   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


   Status of this Memo .............................................. 1
   Copyright Notice ................................................. 2
   Table of Contents ................................................ 2
   1. Introduction .................................................. 5
   2. Conventions and Definitions.................................... 6
   3. Key Mechanisms ................................................ 8
      3.1. Underlying Layer Services Required ........................ 8
         3.1.1. High Mobility ........................................ 8
         3.1.2. Packet Delivery ...................................... 9
      3.2. Upper Layer Thread Identifier and Integrity Check Code ..... 9
      3.3. Transmit Transaction Facility  ............................ 10
      3.4. Quad-party Session Key Installation Sub-protocol .......... 10



Gao                     Expires July 3, 2018                  [Page 2]

Internet-Draft        Flexible Session Protocol           January 2018


      3.5. Zero round-trip connection cloning ....................... 11
   4. Packet Structure ............................................. 12
      4.1. FSP over UDP/IPv4 ........................................ 12
      4.2. FSP over IPv6 ........................................... 13
      4.3. FSP Header and Header Signature .......................... 14
      4.4. Operation Code .......................................... 15
      4.5. Preliminary FSP Packet ................................... 17
         4.5.1. Connect Initialization .............................. 17
         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 ........................ 25
      4.9. RESET ................................................... 26
   5. The Finite States ............................................ 27
      5.1. NON_EXISTENT ............................................ 27
      5.2. LISTENING ............................................... 27
      5.3. CONNECT_BOOTSTRAP ........................................ 27
      5.4. CHALLENGING ............................................. 28
      5.5. CONNECT_AFFIRMING ........................................ 28
      5.6. ACTIVE{A.K.A. ESTABLISHED} ............................... 28
      5.7. COMMITTING .............................................. 29
      5.8. PEER_COMMIT ............................................. 29
      5.9. COMMITTING2 ............................................. 29
      5.10. COMMITTED .............................................. 30
      5.11. CLOSABLE ............................................... 30
      5.12. PRE_CLOSED ............................................. 31
      5.13. CLOSED ................................................. 31
      5.14. CLONING ................................................ 31
      5.15. {Cloned} ............................................... 32
   6. End-to-End Negotiation ........................................ 32
      6.1. Init Check Code, Salt and Cookie ......................... 32
      6.2. Connect Initialization ................................... 33
      6.3. Response to Connect Initialization ....................... 33
      6.4. Week Session Key Exchange: Initiator to Responder ......... 33
      6.5. Week Session Key Exchange: Responder to Initiator ......... 34
      6.6. Retransmission .......................................... 35
   7. Packet Protection Agreement ................................... 35
      7.1. CRC64 ................................................... 35
      7.2. Payload Encryption and Decryption ........................ 36
      7.3. Packet Authentication Only ............................... 37
      7.4. Installation of Master Key ............................... 38
      7.5. Internal Rekeying ........................................ 39
   8. Send and Receive ............................................. 39
      8.1. Path selection and Multipath Load Balancing .............. 39
      8.2. Start a new Transmit Transaction ......................... 40
      8.3. Send pure data packet .................................... 40


Gao                     Expires July 3, 2018                  [Page 3]

Internet-Draft        Flexible Session Protocol           January 2018


      8.4. Flow Control ............................................ 40
      8.5. SNACK and selective retransmission ....................... 41
         8.5.1. Calculation of RTT .................................. 41
         8.5.2. Generation and transmission of SNACK ................ 41
         8.5.3. Negative acknowledgment of Packets Sent ............. 42
         8.5.4. Retransmission ...................................... 43
      8.6. Commit a Transmit Transaction ............................ 43
      8.7. Respond to Transmit Transaction Commitment ............... 43
      8.8. Finalize a Transmit Transaction Commitment ............... 43
   9. Graceful Close ............................................... 43
      9.1. Initiation of Connection Close ........................... 44
      9.2. Acknowledgment of Connection Close ....................... 44
      9.3. Finalization of Connection Close ......................... 44
      9.4. Retry of Connection Close ................................ 44
   10. Mobility Support ............................................ 44
      10.1. Heartbeat Signals ....................................... 44
      10.2. IP Address Change Detection ............................. 45
      10.3. IP Address Change Notification .......................... 46
   11. Connection Multiplication .................................... 46
      11.1. Request to Multiply Connection .......................... 46
      11.2. Response to Connection Multiplication Request............ 47
      11.3. Duplicate Detection of Connection Multiplication Request . 48
      11.4. Retransmission.......................................... 48
      11.5. Key Derivation for clone connection ..................... 48
   12. Timeouts and abruptly Shutdown ............................... 49
      12.1. Timeouts in End-to-End Negotiation ...................... 49
      12.2. Timeouts in Multiply .................................... 50
      12.3. Timeout of Transmit Transaction Commitment .............. 50
      12.4. Timeout of Graceful Shutdown ............................ 50
      12.5. Idle Timeout ........................................... 50
      12.6. Session Key Timeout ..................................... 50
      12.7. Abrupt Shutdown ......................................... 51
   13. Interesting Issues .......................................... 51
      13.1. Milk-type Payload and Minimal Delay Service ............. 51
      13.2. Resolution of ULTID in DNS .............................. 52
      13.3. Integrated Proxy Mode of Host Name Resolution............ 53
      13.4. Optimizing FSP towards IPv6 ............................. 54
      13.5. More reasons to transit towards IPv6 .................... 54
   14. Security Considerations ...................................... 55
      14.1. Resistance against Deny of Service Attack ............... 55
      14.2. Resistance against Replay Attack ........................ 55
      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. Conclusions ................................................. 56


Gao                     Expires July 3, 2018                  [Page 4]

Internet-Draft        Flexible Session Protocol           January 2018


   17. References .................................................. 57
      17.1. Normative References  .................................... 57
      17.2. Informative References .................................. 58
   18. Acknowledgments ............................................. 64
   Authors' Addresses .............................................. 65

1. Introduction

   Flexible Session Protocol is a connection-oriented transport layer
   provides mobility, multihoming and multipath 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 cryptographically calculated with some
   Authenticated Encryption with Additional Data ([R01]) algorithm (for
   current version of FSP the algorithm chosen is [AES]-[GCM]) or a
   cryptographic hash function (for current version of FSP it is BLAKE2
   [RFC7693]) that 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 case, 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 to facilitate transmit transaction
   also provides the session-connection synchronization service to the
   upper layer.




Gao                     Expires July 3, 2018                  [Page 5]

Internet-Draft        Flexible Session Protocol           January 2018


   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

   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.

   Integers, no matter 16-bit, 32-bit or 64-bit, signed or unsigned MUST
   be conveyed in network byte order.

   Well-known acronyms that may be applied in forming words are:

    ID            Identifier
    RTT           Round-Trip Time
    SN            Sequence Number

   o EoT

   A transmit transaction is said to reach End of Transaction (EoT) if
   the 'End of Transaction' 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 out-of-band KEEP_ALIVE or ACK_FLUSH packet whose sequence number
   equals that of the last received packet and whose EoT flag is set
   forcefully terminates the transmit transaction even if the EoT flag
   of the last received packet is unset.




Gao                     Expires July 3, 2018                  [Page 6]

Internet-Draft        Flexible Session Protocol           January 2018


   An ACK_CONNECT_REQ packet itself marks end of the singular transmit
   transaction.

   EOT/Termination of transmit transaction is unilateral. An FSP end
   node may not send further data if it has initiated EOT of its
   transmit direction unless the ACK_FLUSH packet in response of the EOT
   initiative is received.

   o ICC

   The Identity Check Code is a 64-bit value that depends on both the
   aforementioned session key and the FSP packet headers, optionally the
   payload as well, 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
   unless even the initial session key had not been established.

   o Session and Connection

   A full FSP session consists of one connection that was originally
   established from scratch and all of its clones. However for this
   version of FSP session and connection are effectively interchangeable.

   A connection is identified by the ULTID in the local context of the
   ULA endpoint.

   o Session Key

   The session key is a bit string of at least 128 bits that means to
   resist against masquerade attack, either initially established during
   the negotiation phase or installed by the ULA after the FSP
   connection is set up.

   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. The initial session key is
   neither generated nor applied cryptographically.

   After the FSP session is set up the ULA SHOULD establish a shared
   secret key to encrypt payload and/or authenticate the FSP packet. The
   installed key would be called the long-term session key. Here long-



Gao                     Expires July 3, 2018                  [Page 7]

Internet-Draft        Flexible Session Protocol           January 2018


   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 Transmit Transaction

   An FSP packet is the data segment of the underlying IPv6 packet, or
   the payload of one UDP datagram without segmentation in the
   underlying IPv4 layer, while 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 PERSIST or MULTIPLY packet always starts a transmit transaction.

   An ACK_CONNECT_REQ packet itself makes a singular particular transmit
   transaction.

   o ULTID

   The Upper Layer Thread Identifier. It is a 32-bit word that was
   allocated by particular end point of an FSP connection and is unique
   in the local context of the end point.

3. Key Mechanisms

3.1. Underlying Layer Services Required

3.1.1. High Mobility

   High mobility is meant to refer 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. Here 'physical network' has 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 so that the packet to inform the remote end to update the
   lower layer address association could reach its destination in a
   satisfying success rate.


Gao                     Expires July 3, 2018                  [Page 8]

Internet-Draft        Flexible Session Protocol           January 2018


3.1.2. Packet Delivery

   FSP requires that the underlying layer provides packet delivery
   service.

   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 IPv6 address is split 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 the aggregation host id, and the
   rightmost 32-bit word is the ULTID.

   The network prefix part acts as the routing locator. The network
   prefix part of the IPv6 address MAY change when an endpoint is
   roaming, but the ULTID SHALL be kept stable. The endpoint SHOULD
   immediately notify its peer when its IPv6 address is changed. The
   peer SHOULD send packet to the endpoint with the new address.

3.2. Upper Layer Thread Identifier and Integrity Check Code

   To defend against possible connection redirection or dirty data
   injection (message insertion, deletion, modification and replaying),
   each FSP connection prepares a pair of ULTIDs. An ULTID is assigned
   roughly the same semantics with the Security Parameter Index (SPI) in
   MOBIKE [RFC4555].

   An integrity check code (ICC) field is designed in FSP header to
   protect authenticity and optionally privacy of the FSP packet.

   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 secret key, value of ICC is calculated
   by firstly getting the secret key associated with 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].

   An ULTID is effective in the local context of an FSP connection only.
   The source ULTID and the destination ULTID of an FSP packet usually



Gao                     Expires July 3, 2018                  [Page 9]

Internet-Draft        Flexible Session Protocol           January 2018


   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. Transmit Transaction Facility

   FSP facilitates 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.4. Quad-party Session Key Installation Sub-protocol

   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.

   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 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 bidirectionally in this
   version of FSP.

   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.

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



Gao                     Expires July 3, 2018                 [Page 10]

Internet-Draft        Flexible Session Protocol           January 2018


   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.

   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.

3.5. Zero round-trip connection cloning

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




Gao                     Expires July 3, 2018                 [Page 11]

Internet-Draft        Flexible Session Protocol           January 2018


   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 cloned connection. It is an out-of-band
   packet in the context of the cloned connection and it MUST be
   cryptographically protected by the secret key of the cloned
   connection. The packet MAY carry payload as it usually does.

   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 cloned connection,
   and responds from the new context. The response MAY carry payload as
   it usually does. 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 cloned connection. And it MUST treat the response
   packet as though a transmit transaction have been committed by the
   responder, i.e. authenticity of the response packet is verified with
   the new secret key.

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

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 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 July 3, 2018                 [Page 12]

Internet-Draft        Flexible Session Protocol           January 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 header(s).

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ~                          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  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |


Gao                     Expires July 3, 2018                 [Page 13]

Internet-Draft        Flexible Session Protocol           January 2018


   +                                   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

4.3. FSP Header and Header Signature

   FSP headers include fixed headers and 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.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~              Operation Code Specific Fields                   ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Figure 3 FSP Header




Gao                     Expires July 3, 2018                 [Page 14]

Internet-Draft        Flexible Session Protocol           January 2018



   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Header Stack Pointer     |     Major     | Operation Code|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 4 FSP Header Signature



   o Header Stack Pointer

   A 16-bit unsigned integer that specifies the offset of the octet that
   immediately follows the next topmost header, while the first topmost
   header is the one that has the largest offset.

   o Major

   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.

   o Operation Code

   An octet that stores the code of the command which indicates the
   function of the packet.

4.4. Operation Code

   Operation code is the code of the command which indicates the
   function of an FSP 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.





Gao                     Expires July 3, 2018                 [Page 15]

Internet-Draft        Flexible Session Protocol           January 2018


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 cloned. It MUST be payloadless,
                       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.

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 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. Only carry non-empty payload.

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



Gao                     Expires July 3, 2018                 [Page 16]

Internet-Draft        Flexible Session Protocol           January 2018


                       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 cloned 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 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 Packet

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

4.5.1. Connect Initialization

   Operation Code in this type of packet is INIT_CONNECT.











Gao                     Expires July 3, 2018                 [Page 17]

Internet-Draft        Flexible Session Protocol           January 2018


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Timestamp                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Init Check Code                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Salt                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~           Host Name of the Responder (optional)               ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 5 Connect Initialization

   o Timestamp

   The timestamp 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

   A 64-bit random bit string that means to uniquely associated with the
   connection initiated.

   o Salt

   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.




Gao                     Expires July 3, 2018                 [Page 18]

Internet-Draft        Flexible Session Protocol           January 2018


4.5.2. Acknowledgment to Connect Initialization

   Operation Code of this type of packet is ACK_INIT_CONNECT.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            Cookie                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Init Check Code                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Time Delta                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 6 Acknowledgment to Connect Initialization

   o Cookie

   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

   MUST be identical to the corresponding field in the Connect
   Initialization packet acknowledged.

   o Time Delta

   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 arbitrarily
   by the responder, provided that it is not finer than the timestamp.





Gao                     Expires July 3, 2018                 [Page 19]

Internet-Draft        Flexible Session Protocol           January 2018


4.5.3. Connect Request

   Operation Code of this type of packet is CONNECT_REQUEST.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         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



   'Sink Parameter' is an extension header.

   Host Name of the Initiator is optional, it could be exploited by the
   responder to look up the address of the initiator that may receive
   packets in the reverse direction.


Gao                     Expires July 3, 2018                 [Page 20]

Internet-Draft        Flexible Session Protocol           January 2018


   Values of other fields of the packet MUST be identical with the ones
   in the associated Connect Initialization and Acknowledgment to
   Connect Initialization packet.

4.6. Normal Fixed Header

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

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


   o Sequence Number

   The assigned sequence number of the packet. 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 as
   well.

   Each in-band FSP packet is assigned a 32-bit unsigned integer as the
   sequence number. Difference of two sequence number is represented by
   a 32-bit signed integer. If the result of sequence number B
   subtracting sequence number 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.



Gao                     Expires July 3, 2018                 [Page 21]

Internet-Draft        Flexible Session Protocol           January 2018


   o Expected Sequence Number

   The field 'Expected Sequence Number' 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:

   End of Transaction(EoT): if the EoT flag of a packet is set, it is
   the last, maybe as well the single packet of the transmit transaction.

   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 flags has been set the
   EoT flag is simply ignored. Payload of each FSP packet is delivered
   to the ULA as an independent message.

   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

   Stores number of the free blocks in the receive buffer of the sender
   of the packet contains the receive window size field. The advertised
   receive window size is count from the slot meant to accept the packet



Gao                     Expires July 3, 2018                 [Page 22]

Internet-Draft        Flexible Session Protocol           January 2018


   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.

   It is a 20-bit unsigned integer. The unit is buffer block.

4.7. Sink Parameter

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~               Addressable Network Prefixes                    ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Listener ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Host ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Block Size  |         Advertised Receive Window Size        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Signature                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Figure 8 Sink Parameter



   o Addressable Network Prefixes

   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.




Gao                     Expires July 3, 2018                 [Page 23]

Internet-Draft        Flexible Session Protocol           January 2018


   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:

    0                                                            31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  0x2002 (IPv6 6to4 prefix)    |IPv4 address (lestmost 16 bits)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |IPv4 address(rightmost 16 bits)|   UDP port number (16 bits)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 9 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

   The ULTID of the responder that is in LISTENING state.

   o Host ID





Gao                     Expires July 3, 2018                 [Page 24]

Internet-Draft        Flexible Session Protocol           January 2018


   The aggregation host id of the sender of the Sink Parameter extension
   header. It MAY differ with the aggregation host id in the source
   address of the underlying IPv6 address in the IPv6 network. It SHALL
   be 0 if it is in the IPv4 network.

   o Block Size

   A 8-bit unsigned integer that counts number of 512-octet memory
   sectors that a block of the receive buffer holds.

   Size of the buffer block is predetermined by scenarios of applying
   FSP.

   o Advertised Receive Window Size

   In the Sink Parameter this field advertise the initial receive window
   size of the sender of this extension header.

4.8. 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:

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


   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


Gao                     Expires July 3, 2018                 [Page 25]

Internet-Draft        Flexible Session Protocol           January 2018


   following the gap, respectively. The unit of aforementioned length of
   gaps or number of packets is buffer block.

   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 serial
   number shall increase by one. It is assumed that in the life of the
   session no two packets have both the same sequence number and the
   same SNACK header serial number.

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
        {
         union
         {
           timestamp_t timeStamp;
           struct
           {
             uint32_t initial;
             uint32_t expected;
           } sn;
         };
         //
         union
         {
           uint64_t integrityCode;
           uint64_t cookie;
           uint64_t initCheckCode;
         };
         //
         uint32_t reasons; // bit field
         $FSP_HeaderSignature hs;
        };




Gao                     Expires July 3, 2018                 [Page 26]

Internet-Draft        Flexible Session Protocol           January 2018


   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 as in the Connect
   Initialization packet.

   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 as in the Connect Request packet.

   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.

5. The Finite States

5.1. NON_EXISTENT

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

5.2. LISTENING

   ---[API: Reset]-->NON_EXISTENT
   |<-->[Rcv.INIT_CONNECT]{&& resource available}[Send ACK_INIT_CONNECT]
   |<-->[Rcv.INIT_CONNECT]{&& resource unavailable}[Send RESET]
   |<-->[Rcv.CONNECT_REQUEST]{&& duplication detected}
         [Retransmit ACK_CONNECT_REQ]
   |--[Rcv.CONNECT_REQUEST]-->[API{new context, Callback}]
         |-->[{return}Accept]
               -->{new context}CHALLENGING-->[Send ACK_CONNECT_REQ]
         |-->[{return}Reject]-->[Send RESET] {abort new context}

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 retransmit timeout}[Retransmit INIT_CONNECT]


Gao                     Expires July 3, 2018                 [Page 27]

Internet-Draft        Flexible Session Protocol           January 2018


   |--[Transient State timeout]-->NON_EXISTENT-->[Notify]

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]{start keep-alive}[Notify]
     |--{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
   |--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
   |--[Transient State timeout]-->NON_EXISTENT-->[Notify]
   In the CHALLENGING state the keep-alive timer is not started yet.

5.5. CONNECT_AFFIRMING

---[API: Reset]-->NON_EXISTENT-->[Send RESET]
|<-->[API: Send{new data}]{just prebuffer}
|--[Rcv.ACK_CONNECT_REQ]-->PEER_COMMIT-->[API{callback}]
    |-->{Return Accept}
        |-->{Not EOT}-->[Send PERSIST]
        |-->{EOT}-->COMMITTING2-->[Send PERSIST with the EoT flag set]
    |-->{Return Reject}-->NON_EXISTENT-->[Send RESET]
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
|<-->{on retransmit timeout}[Retransmit CONNECT_REQUEST]
|--[Transient State timeout]-->NON_EXISTENT-->[Notify]

5.6. ACTIVE{A.K.A. ESTABLISHED}

---[API: Reset]-->NON_EXISTENT-->[Send RESET]
|--[API: Send{transact}]-->COMMITTING-->[Urge Commit]
|<-->[API: Send{more data}][Send PURE_DATA]
|--[Rcv.PURE_DATA]
    |--{Not EOT}-->{keep state}[Send SNACK]-->[Notify]
    |--{EOT}
       |-->{stop keep-alive}PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv.PERSIST]
    |--{Not EOT}-->{keep state}[Send SNACK early]
    |--[EOT]
       |-->{stop keep-alive}PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv.EOT]



Gao                     Expires July 3, 2018                 [Page 28]

Internet-Draft        Flexible Session Protocol           January 2018


    |-->{stop keep-alive}PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv.MULTIPLY]{passive cloning}
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
|--[Idle timeout]-->NON_EXISTENT-->[Notify]

5.7. COMMITTING

---[API: Reset]-->NON_EXISTENT-->[Send RESET]
|--[Rcv.ACK_FLUSH]-->COMMITTED-->[Notify]
|--[Rcv.PURE_DATA]
    |--{Not EOT}-->{keep state}[Send SNACK]-->[Notify]
    |--{EOT}-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv. Out-of-band EOT]-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv.MULTIPLY]{passive cloning}
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
|--[Short-Idled timeout]-->NON_EXISTENT-->[Notify]
Note that we may not transmit further data until former transaction
acknowledged.

5.8. PEER_COMMIT

---[API: Reset]-->NON_EXISTENT-->[Send RESET]
|--[API: Send{flush}]-->COMMITTING2-->[Urge COMMIT]{enable retry}
|<-->[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]
        |--{Not a new transaction}[End.]
        |--{A new transaction}--[Notify]
|--[Rcv.EOT]-->[Send ACK_FLUSH]-->[Notify]{with duplication suppressed}
|--[Rcv.MULTIPLY]{passive cloning}
|--[Rcv.RELEASE]-->CLOSED-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
|--[Idle timeout]-->NON_EXISTENT-->[Notify]

5.9. COMMITTING2

---[API: Reset]-->NON_EXISTENT-->[Send RESET]
|<-->[Rcv.PURE_DATA]{just prebuffer}



Gao                     Expires July 3, 2018                 [Page 29]

Internet-Draft        Flexible Session Protocol           January 2018


|--[Rcv.ACK_FLUSH]-->{stop keep-alive}CLOSABLE-->[Notify]
|--[Rcv.PERSIST]
    |-->{Not EOT}-->COMMITTING-->[Send SNACK]
    |-->{EOT}-->{keep state}-->[Send ACK_FLUSH]
        |-->{Not a new transaction}[End.]
        |-->{A new transaction}-->[Notify]
|--[Rcv.EOT]-->[Send ACK_FLUSH]-->[Notify]{with duplication suppressed}
|--[Rcv.MULTIPLY]{passive cloning}
|--[Rcv.RELEASE]-->CLOSED{stop keep-alive}-->[Send RELEASE]-->[Notify]
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
|--[Short-Idled timeout]-->NON_EXISTENT-->[Notify]

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}-->{keep state}[Send SNACK]-->[Notify]
    |-->{EOT}
       |-->{stop keep-alive}CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv.PERSIST]
    |-->{Not EOT}-->{keep state}[Send SNACK]
    |-->{EOT}-->{stop keep-alive}CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv. Out-of-band EOT]
       |-->{stop keep-alive}CLOSABLE-->[Send ACK_FLUSH]-->[Notify]
|--[Rcv.MULTIPLY]{passive cloning}
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
|--[Idle timeout]-->NON_EXISTENT

5.11. CLOSABLE

---[API: Reset]-->NON_EXISTENT-->[Send RESET]
|--[API: Send{more data}]-->PEER_COMMIT-->[Send PURE_DATA]{enable retry}
|--[API: Send{flush}]-->COMMITTING2-->[Urge COMMIT]{enable retry}
|--[API: Shutdown]-->[Send RELEASE]-->PRE_CLOSED-->[Notify]
|<-->[Rcv.PURE_DATA]{just prebuffer}
|<-->[Rcv.ACK_START]--[Send ACK_FLUSH]
|<-->[Rcv.Out-of-band EOT]--[Send ACK_FLUSH]
|--[Rcv.PERSIST]
    |-->{Not EOT}-->COMMITTED-->[Send SNACK]



Gao                     Expires July 3, 2018                 [Page 30]

Internet-Draft        Flexible Session Protocol           January 2018


    |-->{EOT}-->{keep state}[Send ACK_FLUSH]
        |-->{Not a new transaction}[End.]
        |-->{A new transaction}-->[Notify]
|--[Rcv.MULTIPLY]{passive cloning}
|--[Rcv.RELEASE]-->CLOSED-->[Notify]
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]
|--[Idle timeout]-->NON_EXISTENT-->[Notify]

5.12. PRE_CLOSED

---[API: Reset]-->NON_EXISTENT-->[Send RESET]
|--[Rcv.RELEASE]-->CLOSED{stop Keep-alive}-->[Send RELEASE]-->[Notify]
|--[Retransmission timeout][Retransmit RELEASE]
|--[Transient timeout]-->NON_EXISTENT

5.13. CLOSED

|--[Timeout of Session Key]-->NON_EXISTENT

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
        |-->{stop keep-alive}[Send ACK_FLUSH]-->[Notify]
    |-->{ULA-flushing}-->CLOSABLE
        |-->{stop keep-alive}[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
           |-->{stop keep-alive}[Send ACK_FLUSH]-->[Notify]
        |-->{ULA-flushing}-->CLOSABLE
           |-->{stop keep-alive}[Send ACK_FLUSH]-->[Notify]
|--[Rcv.RESET]-->NON_EXISTENT-->[Notify]



Gao                     Expires July 3, 2018                 [Page 31]

Internet-Draft        Flexible Session Protocol           January 2018


|<-->{on retransmit timeout}[Retransmit MULTIPLY]
|--[Transient State timeout]-->NON_EXISTENT-->[Notify]

5.15. {Cloned}

{ACTIVE, COMMITTING, PEER_COMMIT, COMMITTING2, COMMITTED, CLOSABLE,
PRE_CLOSED, CLOSED}
|<-->[Rcv.MULTIPLY]{&& collision detected}[Send RESET]
|<-->[Rcv.MULTIPLY]{&& duplication detected}
    [Retransmit]{the head packet of the new connection send queue}
|--[Rcv.MULTIPLY]{&& new connection request}-->[API{Callback}]
     |-->[{Return Accept}]-->{new context}ACTIVE/COMMITTING
          -->[Send PERSIST]{with/without EOT}{start keep-alive}
     |-->[{Return}:Reject]-->[Send RESET] {abort creating new context}


6. End-to-End Negotiation

   End-to-end negotiation is the essential part of FSP connection
   establishment procedure. It consists of two and a half pairs of
   packet exchanges for connection initialization, session key
   establishment and the last confirmation.

6.1. Init Check Code, Salt and Cookie

   The init check code is an arbitrary 64-bit random number generated by
   the initiator of a connection.

   The salt is some 32-bit random number generated by the initiator as
   well.

   The cookie is a value computed by the responder with a private secret
   and an algorithm that is assumed known by the responder only. The
   algorithm chosen MUST make the cookie value depend on the salt and
   the responder's ULTID, and the value MUST be independent of any
   participant's IP address. The computation of the cookie MUST be
   recoverable in the sense that in some limit time period when the
   responder's ULTID, the salt and the private secret remain unchanged
   the cookie generated MUST be unchanged as well. Cookie SHOULD NOT be
   stored by the responder.




Gao                     Expires July 3, 2018                 [Page 32]

Internet-Draft        Flexible Session Protocol           January 2018


6.2. Connect Initialization

   The initiator sends the INIT_CONNECT packet to the responder:

   (INIT_CONNECT, Timestamp, Init Check Code, Salt [, Responder's Host
   Name])

6.3. Response to Connect Initialization

   The responder sends acknowledgment to the initiator:

   Case 1: (ACK_INIT_CONNECT, Cookie, Echo of Initiator's Check Code,
   Time-delta)

   Case 2: (RESET, Echo of Timestamp, Echo of Initiator's 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.

6.4. Week Session Key Exchange: Initiator to Responder

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

   The initiator checks that the echo of the initiator's check code in
   the ACK_INIT_CONNECT packet. If the code is correct, the initiator
   formally requests to establish the connection by sending the
   CONECT_REQUEST packet. In the packet the value of the Timestamp, the
   Initiator's 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



Gao                     Expires July 3, 2018                 [Page 33]

Internet-Draft        Flexible Session Protocol           January 2018


   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
   Parameter with the right value.

   The initiator SHALL save the cookie value that the responder has
   given to make up the 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. The
   following packet can only be PERSIST and it may carry payload.

   The initiator should retransmit the CONNECT_REQUEST packet if it does
   not receive the ACK_CONNECT_REQ packet in the limit time (by default
   5 seconds).

   If in a longer time (by default 60 seconds) starting from the first
   INIT_CONNECT packet was transmitted no legitimate ACK_CONNECT_REQ
   packet was received the initiator should give up setting up the
   connection.

6.5. Week Session Key Exchange: Responder to Initiator

   Case 1: (ACK_CONNECT_REQ, Initial SN, Expected SN, Timestamp, Flags
   and Receive Window Size, 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.




Gao                     Expires July 3, 2018                 [Page 34]

Internet-Draft        Flexible Session Protocol           January 2018


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

7. Packet Protection Agreement

   In a typical scenario the ULA endpoints first setup the FSP
   connection where resistance against connection redirection attack is
   weakly endorsed by CRC64. After the pair of ULA endpoints establish a
   shared secret key, install the secret key and commit current transmit
   transactions, authenticity of the FSP packets sent later are
   cryptographically protected.

7.1. CRC64

   After the FSP participants have finished End-to-End negotiation,
   before the ULAs have installed the shared secret CRC64 is applied to
   calculate the value of the ICC field. The algorithm:

   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.


Gao                     Expires July 3, 2018                 [Page 35]

Internet-Draft        Flexible Session Protocol           January 2018


   2. Accumulate the value of the Init Check Code field, the value of
      the Cookie field successively by CRC64.

   3. 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 by CRC64.

   4. Accumulate the value of the Time Stamp field by CRC64.

   5. Save the accumulated CRC64 value as the precomputed CRC64 value.

   6. When calculate the value ICC of a particular FSP packet, firstly
      set ICC to the precomputed 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.

7.2. Payload Encryption and Decryption

   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, 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 installed by ULA.

   IV: the initial vector, 96-bit string consisted of the internal 32-
   bit 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 32-bit word of the
   internal AES hash sub-key and the leftmost 32-bit word of the
   original key, or a 32-bit word installed by the 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




Gao                     Expires July 3, 2018                 [Page 36]

Internet-Draft        Flexible Session Protocol           January 2018


   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 consisted of the internal 32-
   bit 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.

7.3. Packet Authentication Only

   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.

   The ULA designates the FSP layer to either getting MAC or applying
   AEAD.





Gao                     Expires July 3, 2018                 [Page 37]

Internet-Draft        Flexible Session Protocol           January 2018


   For this FSP version, BLAKE2 is designated as the cryptographic hash
   function. The input key is the secret key that has been 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.

7.4. Installation of Master Key

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

   Key Extract phase, as specified in [RFC5869]

       Let Km = BLAKE2(zeros || ikm)

   Here zeros is 32 octets of integer 0, and BLAKE2b algorithm without
   key is applied. The result Km is the master key.

   Key Expand phase, as specified in [RFC5869]

       Let Ks = BLAKE2(Km, info)

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

   The output 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:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Salt                              |



Gao                     Expires July 3, 2018                 [Page 38]

Internet-Draft        Flexible Session Protocol           January 2018


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Expected Sequence Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 10 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 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, 4 octets of the
   network order integer batch index. The result Ks' is the new session
   key, tegother with the new salt meant to be form the IV.

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

8. Send and Receive

   Hereafter 'FREWS' 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.

8.1. Path selection and Multipath Load Balancing

   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.

   FSP over UDP does not support multipath load balancing, however.

   When FSP is implemented over IPv6 as soon as the connection is
   established the IPv6 address may be changed dynamically, and one more


Gao                     Expires July 3, 2018                 [Page 39]

Internet-Draft        Flexible Session Protocol           January 2018


   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 paramter 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 multihomed
   paths MAY co-exist between the two FSP endpoints. FSP implementation
   MUST support multipath load balancing when multiple multihomed paths
   co-exist.

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 pure data packet

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

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




Gao                     Expires July 3, 2018                 [Page 40]

Internet-Draft        Flexible Session Protocol           January 2018


   An FSP participant advertises the receive window size in the FREWS
   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.5. SNACK and selective retransmission

8.5.1. Calculation of RTT

   Initial RTT for the Connection Initiator: Equals to the mean of the
   time elapsed till 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
   till 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 till 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 mean
   round trip time of the packets acknowledged is calculated. 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
   the time is already earlier than the time of RTT since current time,
   it needs not be shifted.





Gao                     Expires July 3, 2018                 [Page 41]

Internet-Draft        Flexible Session Protocol           January 2018


   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.

   If the latest SNACK packet is KEEP_ALIVE, 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






Gao                     Expires July 3, 2018                 [Page 42]

Internet-Draft        Flexible Session Protocol           January 2018


   When we specify the range, the left square bracket meant to be
   inclusive, while the right parenthesis meant to be exclusive by
   convention.

8.5.4. Retransmission

   Any packet sent 4RTT earlier that is negatively acknowledged MUST be
   retransmitted instantly.

8.6. Commit a Transmit Transaction

   A participant of an FSP connection MAY notify its peer that a batch
   of data transmission is finished by setting the EoT flag of the last
   packet of the transmit transaction be it PERSIST, PURE_DATA or
   MULTIPLY, or by setting the EoT flag of an out-of-band KEEP_ALIVE or
   ACK_FLUSH packet whose sequence number is set to the last sequence
   number of the packets sent.

8.7. Respond to Transmit Transaction Commitment

   (ACK_FLUSH, SN, ExpectedSN, ICC, FREWS)

   The receiver of the packet with EoT flag set SHALL modify the
   operation code of the decrypted packet with the corresponding
   sequence number to a pseudo operation code _COMMIT AND set the EoT
   flag of the _COMMIT packet as well, if the ULA has not fetch the
   packet yet. No matter whether the packet has already been fetched the
   FSP layer MUST immediately notify the ULA that a transmit transaction
   has been committed.

   The receiver SHALL send the ACK_FLUSH packet as soon as all packets
   of the transmit transaction has been received.

8.8. Finalize a Transmit Transaction Commitment

   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.

9. Graceful Close

   Shutdown is asymmetric in the sense that one side may unilaterally
   terminate the session without accept all of its peer's packets.


Gao                     Expires July 3, 2018                 [Page 43]

Internet-Draft        Flexible Session Protocol           January 2018


9.1. Initiation of Connection Close

   (RELEASE, SN, ExpectedSN, ICC, FREWS)

   Connection close initiation packet can be sent in the PEER_COMMIT,
   COMMITTING2 or CLOSABLE state only. FSP migrates to the PRE_CLOSED
   state when Shutdown was called in these states.

9.2. Acknowledgment of Connection Close

   (RELEASE, SN, ExpectedSN, ICC, FREWS)

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

9.3. Finalization of Connection Close

   Connection close initiated in the CLOSABLE state needs not be
   acknowledged before the FSP node migrates to the CLOSED state.

   The FSP node in the PRE_CLOSED state migrates to the CLOSED state
   after the corresponding RELEASE packet is received.

9.4. Retry of Connection Close

   The RELEASE packet that was sent in the CLOSABLE state is never
   retransmitted. Loss of the RELEASE packet would simply let the peer
   in CLOSABLE state timeout.

10. Mobility Support

   During communication process the participant whose IP address changed
   should inform its peer by transmit a packet with the Sink Parameter
   header and the optional SNACK header so that the peer can retransmit
   the negatively acknowledged packets.

   FSP requires that the participants periodically send the heartbeat
   signals.

10.1. Heartbeat Signals

   The participant in the ACTIVE, COMMITTING or COMMITTED state MUST
   send the KEEP_ ALIVE packet as the heart-beat signal periodically to


Gao                     Expires July 3, 2018                 [Page 44]

Internet-Draft        Flexible Session Protocol           January 2018


   retain the connection and make selective negative acknowledgment to
   its peer's data transmission:

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

   Heartbeat signal is an out-of-band control packet. It may not carry
   payload and it always borrows the sequence number of the first packet
   waiting to be send at the first try.

   Only the FSP node in the ACTIVE, COMMITTING, PEER_COMMIT or
   COMMITTING2 state may process the heartbeat signal.

   In the CONNECT_BOOTSTRAP or CONNECT_CONFIRMING state before the
   connection is established it is only required to retransmit
   INITIATE_CONNECT or CONNECT_REQUEST packet. None of them is assumed
   as the heartbeat signal.

   If the head packet in the send queue is an unacknowledged COMMIT
   packet it MUST be retransmitted before sending the KEEP_ALIVE packet.

   In the ACTIVE state if the head packet in the send queue is an
   unacknowledged PERSIST packet it MUST be retransmitted instead of the
   KEEP_ALIVE packet when it is time to transmit the heartbeat signal.

   There is no heartbeat signal in the CLOSABLE or CLOSED state.

10.2. IP Address Change Detection

   A participant of FSP connection should 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 packet with a later sequence number is received and the source
   IP address of the packet is found to be different with the preserved
   remote-end IP address the receiver should automatically update the
   preserved remote-end IP address to the source IP address of the
   packet, unless there is a Sink Parameter header in the packet.

   Any participant of the communication does not make discrimination of
   the source or destination IP address of any packet provided that both




Gao                     Expires July 3, 2018                 [Page 45]

Internet-Draft        Flexible Session Protocol           January 2018


   the source ULTID and the destination ULTID keep unchanged and the ICC
   field passes verification.

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

10.3. IP Address Change Notification

   If there is one participant whose receiving interface is not the same
   as the transmission interface the participant is called asymmetric-
   transmission node. Asymmetric-transmission itself is asymmetric in
   the sense that one participant may be asymmetric-transmission node
   while its peer is normal node of symmetric transmission.

   The sender is an asymmetric-transmission node if the ACK_CONNECT_REQ
   packet or PERSIST packet received has a Sink Parameter header and the
   source IP address of the packet that the network interface of the
   receiver reports is not in the allowed IP address list in the Sink
   Parameter header in the packet during connection negotiation. For a
   remote-end asymmetric-transmission node, the near-end cannot rely on
   automatic IP address change detection. Instead IP address change
   notification mechanism should be utilized:

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

   Both the host ID and the list of the allowed IP addresses MUST be the
   new refreshed.

11. Connection Multiplication

   Connection multiplication is the process of incarnating a new
   connection context. Only connection that provides reliable byte-
   stream delivery service may be multiplied. In the future version the
   clone connection MAY provide different class of service with the
   initiating connection.

11.1. Request to Multiply Connection

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





Gao                     Expires July 3, 2018                 [Page 46]

Internet-Draft        Flexible Session Protocol           January 2018


   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

   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.




Gao                     Expires July 3, 2018                 [Page 47]

Internet-Draft        Flexible Session Protocol           January 2018


   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
   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 clone connection

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

   Where Km is the master key,




Gao                     Expires July 3, 2018                 [Page 48]

Internet-Draft        Flexible Session Protocol           January 2018


   [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 - For this version of FSP it is the fixed ASCII string
   "Multiply an FSP connection" which is 26-octet long.

   Context - Concatenation of 4 32-bit word seqI, oobsn, idI and idR

   Length - An 32-bit network byte-order integer specifying the length
   (in bits) of the derived keying material K-output

   seqI is the sequence number of the MULTIPLY packet that is sent by
   the multiplication initiator, in the sequence space of the original
   connection. oobsn is the out-of-band serial number of the MULTIPLY
   packet. Both seqI and seqR MUST in network byte order.

   idI is the sender side ULTID of the original connection that is to
   initiate the connection multiplication request. 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.

12. Timeouts and abruptly Shutdown

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




Gao                     Expires July 3, 2018                 [Page 49]

Internet-Draft        Flexible Session Protocol           January 2018


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 abruptly shutdown.

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

12.6. Session Key Timeout

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






Gao                     Expires July 3, 2018                 [Page 50]

Internet-Draft        Flexible Session Protocol           January 2018


12.7. Abrupt Shutdown

   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. Interesting Issues

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

   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 the two end point host
      nodes are treated as if they were routers connecting the IPv6
      addressed ULAs across the IPv4 network.

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

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.






Gao                     Expires July 3, 2018                 [Page 51]

Internet-Draft        Flexible Session Protocol           January 2018


   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.

   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.




Gao                     Expires July 3, 2018                 [Page 52]

Internet-Draft        Flexible Session Protocol           January 2018


   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. Integrated Proxy Mode of Host Name Resolution

   In IPv6 network, if the global unicast IP address of the default
   gateway is configured, the initiator of the FSP connection MAY the
   IPv6 address of the default gateway as the destination IP address of
   the INIT_CONNECT packet.

   If the global unicast IP address of the default gateway is not
   configured the default link-local gateway address, FE80::1, is
   applied instead.

   The gateway that connects the IPv6 host should be able to resolve the
   IP address of the responder. If there are multiple IP addresses
   resolvable the gateway may arbitrarily select one.

   If the gateway found that the responder is on the same link-local
   network with the initiator it must 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.

   If the gateway found that the responder is not on the same link-local
   network with the initiator it MUST select one public global unicast
   IP address resolved for the initiator and one public global unicast
   IP address resolved for the responder, and correspondingly update the
   64-bit network prefix part of the source and the destination IP
   address field of the underlying IPv6 header of the packet,
   respectively, and relay the packet to the next gateway/router, or the
   responder itself.

   If the gateway is unable to resolve the IP address of the responder,
   it MUST NOT respond to the INIT_CONNECT packet.

   The initiator decides whether to apply path selection according to
   the packet acknowledged. If the 64-bit prefix source address of the
   acknowledgment packet is already in the allowed address list field of
   the acknowledgment packet path selection is assumed done. Otherwise


Gao                     Expires July 3, 2018                 [Page 53]

Internet-Draft        Flexible Session Protocol           January 2018


   path selection is applied to determine the source and destination
   addresses of the CONNECT_REQUEST packet during end-to-end negotiation.

13.4. 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.
   Besides the IP addresses associated with an FSP connection MAY change
   after the FSP connection is established.

13.5. More reasons to transit towards IPv6

   It may be argued that by implements FSP over IPv6 it provides more
   reasons to transit towards IPv6:

   o Infrastructure-independent mobility support

   To support mobility FSP does not assume any infrastructure
   prerequisite.

   However, it may take advantages of physical network mobility support
   or legacy IP mobility support for IPv4/IPv6 ([RFC3344]/[RFC6275]) to
   enhance reliability of FSP mobility support.



Gao                     Expires July 3, 2018                 [Page 54]

Internet-Draft        Flexible Session Protocol           January 2018


   o Elimination of routing scalability issue: FSP over IPv6 assumes
      that the leftmost 64-bit network prefix is effectively the locator
      that may be thoroughly optimized for routing efficiency. And thus
      it may be argued that the routing scalability problem does not
      exist at all for FSP over such tuned IPv6.

   o Network-level fault tolerance through inherent multihoming and
      multipath support

   o Resist against masquerade attacks

   o Ubiquitous encryption and/or authentication of data

   o Performance gains: clone connection makes it easy to avoid head-
      of-line congestion, while mechanism of transmit transaction may
      save substantial acknowledgment overheads in the application layer.

   o Traffic class optimization: FSP support milk-type payload. IPv6
      packet of a milk-type FSP payload should take a mark at the IPv6
      traffic class field to let the underlying network layer to
      minimize delay.

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.



   repeated header discarded...][as sn, fiber id are randomly choosen!





Gao                     Expires July 3, 2018                 [Page 55]

Internet-Draft        Flexible Session Protocol           January 2018


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 over the line iSCSI implementations MUST provide.

   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.

15. IANA Considerations

   A UDP port number should be registered for FSP over UDP/IPv4.

   A next header selector value (protocol number) should be registered
   for FSP over IPv6.

   If Minimal-Delay service is implemented, a dedicate traffic class
   code value should be registered.

16. Conclusions

   Flexible Session Protocol is a transport layer protocol as suggested
   in [RFC1122], with session layer semantic as specified in [OSI/RM].

   Alike TCP [STD7], FSP primarily provides reliable byte-stream
   transfer service. Unlike TCP, the byte-stream may be segmented into
   almost unlimited number of transmit transaction.



Gao                     Expires July 3, 2018                 [Page 56]

Internet-Draft        Flexible Session Protocol           January 2018


   FSP provides token management service by cooperating with ULA to
   manage the shared secret key.

   The clone connection MAY be utilized to provide expedited data
   transfer service.

   The concept of transmit transaction has some semantics of uni-
   direction adjournment of session. Symmetrical commitment of transmit
   transaction provides session-connection synchronization.

17. References

17.1. Normative References

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

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

   [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
             Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
             STD 63, RFC 3629, November 2003.

   [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
             Architecture", RFC 4291, February 2006.

   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
             2008.

   [RFC5869] Krawczyk, H. and Eronen, P. "HMAC-based Extract-and-Expand
             Key Derivation Function (HKDF)", RFC 5869, May 2010.

   [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson , "The BLAKE2
             Cryptographic Hash and Message Authentication Code (MAC)",
             RFC 7693, November 2015.



Gao                     Expires July 3, 2018                 [Page 57]

Internet-Draft        Flexible Session Protocol           January 2018


   [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, July 2017.

   [RFC8273] Brzozowski, J. and Van de Velde, G., "Unique IPv6 Prefix
             per Host", DOI: 10.17487/RFC8273, December 2017

   [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>
             <http://standards.iso.org/ittf/PubliclyAvailableStandards/s
             014258_ISO_IEC_7498-4_1989(E).zip>

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

17.2. Informative References

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

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




Gao                     Expires July 3, 2018                 [Page 58]

Internet-Draft        Flexible Session Protocol           January 2018


   [tcpcrypt]Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D.
             Boneh, "The case for ubiquitous transport-level encryption",
             USENIX Security , 2010.

   [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
             RFC 1034, November 1987.

   [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
             SPECIFICATION", RFC 1035, November 1987.

   [RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions
             Functional Specification", RFC 1644, July 1994.

   [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
             Defeating Denial of Service Attacks which employ IP Source
             Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
             IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
             Explicit Congestion Notification (ECN) to IP", RFC 3168,
             September 2001.

   [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C.,
             and M. Carney, "Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6)", RFC 3315, , July 2003.

   [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
             August 2002.

   [RFC3596] Thomson, S., Huitema, C., Ksinant V. and M. Souissi, "DNS
             Extensions to Support IP Version 6", RFC 3596, October 2003.

   [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
             Host Configuration Protocol (DHCP) version 6", RFC 3633,
             December 2003.

   [RFC3720] J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka and E.
             Zeidner, "Internet Small Computer Systems Interface
             (iSCSI)", RFC 3720, April 2004.




Gao                     Expires July 3, 2018                 [Page 59]

Internet-Draft        Flexible Session Protocol           January 2018


   [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, July 2004.

   [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
             "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
             January 2005.

   [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
             Resource Identifier (URI): Generic Syntax", STD 66, RFC
             3986, January 2005.

   [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness
             Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4106] J. Viega and D. McGrew, "The Use of Galois/Counter Mode
             (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
             4106, June 2005.

   [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, December 2005.

   [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
             2005.

   [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
             4303, December 2005.

   [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
             Network Address Translations (NATs)", RFC 4380, February
             2006.

   [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
             Authentication and Security Layer (SASL)", RFC 4422, June
             2006.

   [RFC4555] Eronen, P., Ed., "IKEv2 Mobility and Multihoming Protocol
             (MOBIKE)", RFC 4555, June 2006.

   [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
             "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
             September 2007.



Gao                     Expires July 3, 2018                 [Page 60]

Internet-Draft        Flexible Session Protocol           January 2018


   [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
             Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
             RFC 4960, September 2007.

   [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
             Channels", RFC 5056, November 2007.

   [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
             Kozuka, Stream Control Transmission Protocol (SCTP) Dynamic
             Address Reconfiguration, RFC 5061, September 2007.

   [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
             over PPP", RFC 5072, September 2007.

   [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
             Encryption", RFC 5116, January 2008.

   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
             2008.

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

   [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
             Model in Ad Hoc Networks", RFC 5889, September 2010.

   [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model:
             The Relationship between Links and Subnet Prefixes", RFC
             5942, July 2010.

   [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
             Assignment to End Sites", BCP 157, RFC 6177, March 2011.

   [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
             Support in IPv6", RFC 6275, July 2011.

   [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer
             Security Version 1.2", RFC 6347, January 2012.




Gao                     Expires July 3, 2018                 [Page 61]

Internet-Draft        Flexible Session Protocol           January 2018


   [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
             Requirements", RFC 6434, December 2011.

   [RFC6740] Atkinson, RJ and SN Bhatti, "Identifier-Locator Network
             Protocol (ILNP) Architectural Description", RFC 6740,
             November 2012.

   [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
             Extensions for Multipath Operation with Multiple Addresses",
             RFC 6824, January 2013.

   [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
             Locator/ID Separation Protocol (LISP)", RFC 6830, January
             2013.

   [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
             the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050,
             November 2013.

   [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and
             D. Wing, "IPv6 Multihoming without Network Address
             Translation", RFC 7157, March 2014.

   [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
             Constrained-Node Networks", RFC 7228, May 2014.

   [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T.
             Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)",
             STD 79, RFC 7296, October 2014.

   [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
             Transfer Protocol Version 2 (HTTP/2)", RFC 7540, May 2015.

   [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
             Length Recommendation for Forwarding", BCP 198, RFC 7608,
             July 2015.

   [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
             Considerations for IPv6 Address Generation Mechanisms", RFC
             7721, March 2016.





Gao                     Expires July 3, 2018                 [Page 62]

Internet-Draft        Flexible Session Protocol           January 2018


   [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, May 2016.

   [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP
             208, RFC 8084, March 2017.

   [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage
             Guidelines", BCP 145, RFC 8085, March 2017.

   [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit
             Congestion Notification (ECN)", RFC 8087, March 2017.

   [RFC8170] D. Thaler, Ed., "Planning for Protocol Adoption and
             Subsequent Transitions", RFC 8170, May 2017.

   [HRX08]   Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly
             High-Speed TCP Variant", ACM SIGOPS Operating System Review,
             2008.

   [NGMN2015]"5G White Paper", NGMN Alliance, February 2015.
             <https://www.ngmn.org/fileadmin/ngmn/content/downloads/Tech
             nical/2015/NGMN_5G_White_Paper_V1_0.pdf>

   [I-D.ila-mobility]

             Mueller, J. and Herbert, T., "Mobility Management Using
             Identifier Locator Addressing",  Internet-Draft draft-
             mueller-ila-mobility-03, February 2017.
             <https://www.ietf.org/id/draft-mueller-ila-mobility-03.txt>

   [I-D.irtf-t2trg-iot-seccons]

             Garcia-Morchon, O., Kumar, S. and Sethi, M., "State of the
             Art and Challenges for the Internet of Things", Internet-
             Draft draft-irtf-t2trg-iot-seccons-03, May 2017.
             <https://www.ietf.org/id/draft-irtf-t2trg-iot-seccons-
             03.txt>

   [I-D.ietf-quic-transport]





Gao                     Expires July 3, 2018                 [Page 63]

Internet-Draft        Flexible Session Protocol           January 2018


             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>

18. Acknowledgments

   <Add any acknowledgements>



   This document was prepared using 2-Word-v2.0.template.dot.





   Copyright (c) 2018 IETF Trust and the persons identified as authors
   of the code. All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in Section
   4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info).





















Gao                     Expires July 3, 2018                 [Page 64]

Internet-Draft        Flexible Session Protocol           January 2018


Authors' Addresses

   Jason Gao
   Software Architect

   Email: jagao@outlook.com









































Gao                     Expires July 3, 2018                 [Page 65]