idnits 2.17.1 draft-gao-flexible-session-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1977 has weird spacing: '...key and store...' -- The document date (April 16, 2019) is 1835 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3315' is defined on line 2885, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 2895, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 2910, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 2919, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 2924, but no explicit reference was found in the text == Unused Reference: 'RFC5072' is defined on line 2929, but no explicit reference was found in the text == Unused Reference: 'RFC5116' is defined on line 2933, but no explicit reference was found in the text == Unused Reference: 'RFC5942' is defined on line 2937, but no explicit reference was found in the text == Unused Reference: 'RFC6059' is defined on line 2942, but no explicit reference was found in the text == Unused Reference: 'RFC6177' is defined on line 2947, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 2952, but no explicit reference was found in the text == Unused Reference: 'RFC7050' is defined on line 2956, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 2961, but no explicit reference was found in the text == Unused Reference: 'RFC7323' is defined on line 2966, but no explicit reference was found in the text == Unused Reference: 'RFC7608' is defined on line 2971, but no explicit reference was found in the text == Unused Reference: 'RFC8084' is defined on line 2981, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 2989, but no explicit reference was found in the text == Unused Reference: 'RFC8170' is defined on line 2994, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. 'STD7') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 2 errors (**), 0 flaws (~~), 20 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Gao 3 Intended Status: Experimental 4 Expires: October 18, 2019 April 16, 2019 6 Flexible Session Protocol 7 draft-gao-flexible-session-protocol-02 9 Abstract 11 FSP is a connection-oriented transport layer protocol that provides 12 mobility and multihoming support by introducing the concept of 'upper 13 layer thread ID', which is associated with some shared secret that is 14 applied to protect authenticity of the origin of the FSP packets. 16 It introduces the concept of transmit transaction to facilitate a 17 quad-party sub-protocol for shared secret installation. 19 It provides transport layer features of zero round-trip connection 20 multiplication and on-the-wire compression, in addition to ubiquitous 21 message authentication with optional encryption service. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1. High Mobility . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 6 64 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Abbreviations and Idioms . . . . . . . . . . . . . . . . . . . 7 66 3. Key Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Underlying Layer Services Required . . . . . . . . . . . . 9 68 3.1.1. Packet Delivery . . . . . . . . . . . . . . . . . . . . 9 69 3.1.2. Network Address Change Notification . . . . . . . . . . 9 70 3.1.3. Network Congestion Control . . . . . . . . . . . . . . 10 71 3.2. Identifying Connection by Local ULTID . . . . . . . . . . . 10 72 3.3. Defending Against Connection Redirection with ICC . . . . . 10 73 3.4. Transmit Transaction . . . . . . . . . . . . . . . . . . . 10 74 3.5. Quad-party Session Key Installation Sub-protocol . . . . . 11 75 3.6. Zero Round-Trip Connection Multiplication . . . . . . . . . 12 76 4. Packet Structure . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. FSP over UDP/IPv4 . . . . . . . . . . . . . . . . . . . . . 13 78 4.2. FSP over IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.3. Generic FSP Header . . . . . . . . . . . . . . . . . . . . 15 80 4.4. FSP Header Signature . . . . . . . . . . . . . . . . . . . 15 81 4.4.1 Header Stack Pointer . . . . . . . . . . . . . . . . . . 15 82 4.4.2 Major . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.4.3 Operation Code . . . . . . . . . . . . . . . . . . . . . 16 84 4.5. Preliminary FSP Packets . . . . . . . . . . . . . . . . . . 18 85 4.5.1. Connect Initialization . . . . . . . . . . . . . . . . 18 86 4.5.2. Acknowledgment to Connect Initialization . . . . . . . 19 87 4.5.3. Connect Request . . . . . . . . . . . . . . . . . . . . 20 88 4.6. Normal Fixed Header . . . . . . . . . . . . . . . . . . . . 21 89 4.7. Sink Parameter . . . . . . . . . . . . . . . . . . . . . . 23 90 4.8. Selective Negative Acknowledgment . . . . . . . . . . . . . 25 91 4.9. RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5. The Finite State Machine . . . . . . . . . . . . . . . . . . . 27 93 5.1. NON_EXISTENT . . . . . . . . . . . . . . . . . . . . . . . 27 94 5.2. LISTENING . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 5.3. CONNECT_BOOTSTRAP . . . . . . . . . . . . . . . . . . . . . 27 96 5.4. CONNECT_AFFIRMING . . . . . . . . . . . . . . . . . . . . . 28 97 5.5. CHALLENGING . . . . . . . . . . . . . . . . . . . . . . . . 28 98 5.6. ACTIVE{A.K.A. ESTABLISHED} . . . . . . . . . . . . . . . . 29 99 5.7. COMMITTING . . . . . . . . . . . . . . . . . . . . . . . . 29 100 5.8. COMMITTED . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 5.9. PEER_COMMIT . . . . . . . . . . . . . . . . . . . . . . . . 30 102 5.10 COMMITTING2 . . . . . . . . . . . . . . . . . . . . . . . . 31 103 5.11 CLOSABLE . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 5.12 PRE_CLOSED . . . . . . . . . . . . . . . . . . . . . . . . 32 105 5.13 CLOSED . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 5.14 CLONING . . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 5.15 Passive Multiplication . . . . . . . . . . . . . . . . . . 33 108 6. End-to-End Negotiation . . . . . . . . . . . . . . . . . . . . 34 109 6.1. Connect Initialization . . . . . . . . . . . . . . . . . . 34 110 6.2. Response to Connect Initialization . . . . . . . . . . . . 35 111 6.3. Connection Incarnation Request . . . . . . . . . . . . . . 35 112 6.4. Connection Incarnation Response . . . . . . . . . . . . . . 36 113 6.5. The Last Confirmation . . . . . . . . . . . . . . . . . . . 37 114 6.6. Retransmission . . . . . . . . . . . . . . . . . . . . . . 37 115 7. Quad-party Session Key Installation . . . . . . . . . . . . . 37 116 7.1. API for Session Key Installation . . . . . . . . . . . . . 38 117 7.2. Time to Call API for Session Key Installation . . . . . . . 38 118 7.3. Time to Take New Session Key into Effect . . . . . . . . . 38 119 7.4. Generating the Initial Session Key . . . . . . . . . . . . 39 120 7.5. Internal Rekeying . . . . . . . . . . . . . . . . . . . . . 40 121 8. Send and Receive . . . . . . . . . . . . . . . . . . . . . . . 41 122 8.1. Packet Integrity Protection . . . . . . . . . . . . . . . . 41 123 8.1.1. Application of CRC64 . . . . . . . . . . . . . . . . . 41 124 8.1.2. Packet Authentication Only . . . . . . . . . . . . . . 41 125 8.1.3. Authenticated Encryption with Additional Data . . . . . 42 126 8.1.4 ICC of the Out-of-Band Packet . . . . . . . . . . . . . 43 127 8.2. Start a New Transmit Transaction . . . . . . . . . . . . . 43 128 8.3. Send a Pure Data Packet . . . . . . . . . . . . . . . . . . 44 129 8.4. Commit a Transmit Transaction . . . . . . . . . . . . . . . 44 130 8.4.1. Initiate Transmit Transaction Commitment . . . . . . . 44 131 8.4.2. Respond to Transmit Transaction Commitment . . . . . . 44 132 8.4.3. Finalize Transmit Transaction Commitment . . . . . . . 44 133 8.4.4. Time-out for Committing Transmit Transaction . . . . . 45 134 8.5. Retransmission . . . . . . . . . . . . . . . . . . . . . . 45 135 8.5.1. Calculation of RTT . . . . . . . . . . . . . . . . . . 45 136 8.5.2. Generation and transmission of SNACK . . . . . . . . . 45 137 8.5.3. Negative acknowledgment of Packets Sent . . . . . . . . 46 138 8.5.4. Retransmission Interval . . . . . . . . . . . . . . . . 46 139 8.6. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 46 140 8.7. Congestion Control . . . . . . . . . . . . . . . . . . . . 47 141 8.8. On-the-Wire Compression . . . . . . . . . . . . . . . . . . 48 142 8.9. Milk Like Payload and Minimal Delay Service . . . . . . . . 48 143 9. Graceful Shutdown . . . . . . . . . . . . . . . . . . . . . . 49 144 9.1. Initiation of Graceful Shutdown . . . . . . . . . . . . . . 49 145 9.2. Acknowledgment of Graceful Shutdown . . . . . . . . . . . . 50 146 9.3. Finalization of Graceful Shutdown . . . . . . . . . . . . . 50 147 9.4. Retransmission of RELEASE Packet . . . . . . . . . . . . . 50 148 10 Mobility and Multi-home Support . . . . . . . . . . . . . . . 50 149 10.1. Heartbeat Signals . . . . . . . . . . . . . . . . . . . . 50 150 10.2. Active Address Change Signaling . . . . . . . . . . . . . 51 151 10.3. Heuristic Remote Address Change Adaptation . . . . . . . . 51 152 10.4. Heuristic Address Change Acknowledgement . . . . . . . . . 52 153 10.5. NAT-traversal and Multihoming . . . . . . . . . . . . . . 52 154 10.6. Explicit Multi-home Informing . . . . . . . . . . . . . . 52 155 11 Connection Multiplication . . . . . . . . . . . . . . . . . . 53 156 11.1. Request to Multiply Connection . . . . . . . . . . . . . . 53 157 11.2. Response to Connection Multiplication Request . . . . . . 53 158 11.3. Duplicate Detection of Connection Multiplication Request . 54 159 11.4. Retransmission . . . . . . . . . . . . . . . . . . . . . . 55 160 11.5. Key Derivation for Branch Connection . . . . . . . . . . . 55 161 12 Timeouts and Abrupt Close . . . . . . . . . . . . . . . . . . 55 162 12.1. Timeouts in End-to-End Negotiation . . . . . . . . . . . . 55 163 12.2. Timeouts in Multiply . . . . . . . . . . . . . . . . . . . 56 164 12.3. Timeout of Transmit Transaction Commitment . . . . . . . . 56 165 12.4. Timeout of Graceful Shutdown . . . . . . . . . . . . . . . 56 166 12.5. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . . 56 167 12.6. Session Key Timeout . . . . . . . . . . . . . . . . . . . 56 168 12.7. Abrupt Close . . . . . . . . . . . . . . . . . . . . . . . 57 169 13 Issues for Further Study . . . . . . . . . . . . . . . . . . . 57 170 13.1. Resolution of ULTID in DNS . . . . . . . . . . . . . . . . 57 171 13.2. Proxy Pattern for Syndicated Name Resolution . . . . . . . 57 172 13.3. Asymmetric Transmission . . . . . . . . . . . . . . . . . 58 173 14 Security Considerations . . . . . . . . . . . . . . . . . . . 59 174 14.1. Deny of Service Attack . . . . . . . . . . . . . . . . . . 59 175 14.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 59 176 14.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 59 177 14.4. Masquerade Attack . . . . . . . . . . . . . . . . . . . . 59 178 14.5. Active Man-In-The-Middle Attack . . . . . . . . . . . . . 59 179 14.6. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 59 180 15 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 181 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 182 16.1. Normative References . . . . . . . . . . . . . . . . . . . 60 183 16.2. Informative References . . . . . . . . . . . . . . . . . . 62 184 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 185 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65 187 1. Introduction 189 Flexible Session Protocol is a connection-oriented transport layer 190 provides mobility, multi-homing and multi-path support by introducing 191 the concept of 'upper layer thread ID' (ULTID), which was firstly 192 suggested in [Gao2002]. 194 An integrity check code (ICC) field associated with the ULTID is 195 designed in the FSP header to protect authenticity and optionally 196 privacy of the FSP packet. An FSP packet is assumed to originate from 197 the same source if the ICC value associated with certain destination 198 ULTID passes validation, regardless of the source or destination 199 address in the underlying layer. 201 ICC is either calculated by [CRC64] which protects FSP against 202 unintended modification, or a cryptographic hash function, or 203 cryptographically calculated with some Authenticated Encryption with 204 Additional Data ([R01]) algorithm, each of which requires a shared 205 secret key. 207 In the former case a weak key meant to obfuscate the CRC64 checksum 208 is agreed by the FSP participants. In the latter two cases, the 209 shared secret key is assumed to be installed by the upper layer 210 application (ULA). 212 The ULTID is assigned roughly the same semantics with Security 213 Parameter Index (SPI) in MOBIKE [RFC4555]. Either the weak key or the 214 shared secret key is indexed by the source or destination ULTID in 215 the local context of the sender or the receiver, respectively. 217 FSP facilitates secret key installation by introducing the concept of 218 transmit transaction. Mechanism of transmit transaction also provides 219 the session-connection synchronization service to the upper layer. 221 FSP is a transport layer protocol as specified in [RFC1122], provides 222 services alike TCP [STD5] to ULA, with session layer features as 223 suggested in [OSI/RM], most noticeably session-connection 224 synchronization. It can be argued that FSP makes it much more 225 flexible for the application layer protocols to adopt new key 226 establishment protocol/algorithm while offloading routine 227 authentication and optionally encryption of the data to the 228 underlying layers where it may be much easier to exploit hardware- 229 acceleration. 231 1.1. High Mobility 233 Here high mobility refers to scenarios such as high-speed train or 234 airplane. 236 FSP solves somewhat coarse-grain or low-speed mobility problem. Fine- 237 grain or high-speed mobility is left to the underlying physical 238 network, which is semantics specified in [RFC1122]. To make mobility 239 support work effectively it is assumed that one end-node MUST keep 240 its lower layer address reasonably stable while the other end-node 241 SHOULD NOT change its lower layer address too frequently. 243 1.2. Requirements Language 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in RFC 2119 [RFC2119]. 249 In this document, these words will appear with that interpretation 250 only when in ALL CAPS. Lower case uses of these words are not to be 251 interpreted as carrying significance described in RFC 2119. 253 1.3. Conventions 255 Conventions in describing the finite state machine (FSM) of FSP are: 257 ESTABLISHED The string of alphabetic characters designates the 258 name of the state 260 [API: Reset] Upper Layer Application Programming Interface Call 262 {Notify} Call back/notify the upper layer application 264 {new context} Additional action before or after state transition 266 [Send OPCODE_OF_FSP_PACKET] 267 Send some FSP packet 269 [Retransmit OPCODE_OF_FSP_PACKET] 270 Retransmit some FSP packet 272 {On transient state Timeout} 273 Timed-out event 275 {&& additional condition} 276 Together with some additional condition 278 --> state transition 280 |-- branch 282 2. Abbreviations and Idioms 284 o Connection 285 An FSP connection is the binding of two network nodes established 286 through some end-to-end negotiation process. It is identified by 287 the ULTID in the local context of each network node, respectively. 289 o EoT 290 A transmit transaction is said to reach End of Transaction (EoT) if 291 the EoT flag is set in a legitimate PURE_DATA, PERSIST, NULCOMMIT 292 or MULTIPLY packet. We said that the packet terminates the transmit 293 transaction if the EoT flag is set. 295 An FSP end node SHALL NOT send further data if it has initiated EoT 296 of its transmit direction unless a particular ACK_FLUSH packet is 297 received. The particular AKC_FLUSH packet MUST acknowledge not only 298 the packet with the EoT flag set but all of the packets sent before 299 the packet as well. 301 EoT, i.e. termination of transmit transaction is unilateral. 303 o FREWS 304 It stands for the Flag and advertised REceive Window Size. It is 305 the 32-bit combined word next to the ICC field in the normal FSP 306 fixed header. 308 o ICC 309 The Identity Check Code is a 64-bit value that depends on both the 310 session key and all of the headers of the FSP packet to include the 311 ICC, calculated with the same algorithm in the context of each FSP 312 participant. 314 Only a packet with correct ICC can be accepted by any FSP 315 participant as soon as the connection has been established. 317 Initially CRC64 is exploited to make a checksum that weekly 318 protects the FSP packet against unintentional modification. The 319 checksum is obfuscated with the initial session key to get the ICC. 320 After the ULA installed the long-term session key either some 321 cryptographic hash function or some Authenticated Encryption with 322 Additional Data algorithm shall be applied to obtain or check the 323 ICC. 325 o Session 326 An FSP session is the transport-layer association of two network 327 nodes. A full FSP session consists of one connection that was 328 established from scratch and all of its branches. 330 However for this version of FSP specification the idioms session 331 and connection are interchangeable if not explicitly specified. 333 o Session Key 334 The session key is a bit string of at least 128 bits that means to 335 resist against masquerade attack. It is either initiated during the 336 end-to-end negotiation phase or installed by the ULA after the FSP 337 connection is established. 339 The session key installed by the ULA is called the long-term 340 session key. Here long-term means that the key could be used until 341 the packet sequence space is exhausted. The packet sequence space 342 is exhausted if the number of packets that use the same key reaches 343 or exceeds 2,147,483,647(2^31-1). 345 o SN 346 Sequence Number is the unsigned 32-bit integer number assigned to 347 every FSP packet except the preliminary packets. 349 Difference of two sequence number is represented by a 32-bit signed 350 integer. If the result of SN B subtracting SN A is greater than 351 zero, we say that B is greater than A and the packet of the 352 sequence number B is later than the packet of the sequence number 353 A, although the unsigned integer representation of B may be far 354 less that A. Consequently, as the result of A subtracting B is less 355 than zero, we say that A is less than B and the packet of the 356 sequence number A is earlier than the packet of the sequence number 357 A. 359 o Transmit Transaction 360 A transmit transaction of FSP is a sequence of FSP packets that 361 were sent and marked by the ULA as one continuous stream where all 362 packets in the stream must be acknowledged before any further 363 packet is allowed to be sent. 365 A PERSIST or MULTIPLY packet always starts a transmit transaction. 367 ACK_START, alias of NULCOMMIT, both start and terminate a payload- 368 less transmit transaction when it is exploited to acknowledge the 369 ACK_CONNECT_REQ or MULTIPLY packet. 371 o ULA 372 The Upper Layer Application. 374 o ULTID 375 The Upper Layer Thread Identifier (ULTID) is a 32-bit word that was 376 allocated by particular network end node of an FSP connection and 377 is unique in the local context of the network end node. 379 Theoretically all of the ULAs of a network end node MAY establish 380 up to 2^31-1 FSP connections totally. Each connection MUST have a 381 unique thread identifier (ULTID) assigned in the local context of 382 the network end node. 384 A session or connection of FSP does not require a global ID. 386 3. Key Mechanisms 388 3.1. Underlying Layer Services Required 390 3.1.1. Packet Delivery 392 FSP requires that the underlying layer provides packet delivery 393 service. 395 In this version of FSP, when FSP is implemented in the IPv4 network, 396 every FSP packet MUST be encapsulated in a UDP [STD6] datagram 397 [RFC8085]. 399 When FSP is implemented over IPv6, the FSP SHALL be the immediate 400 upper layer of IPv6 [RFC8200]. 402 3.1.2. Network Address Change Notification 404 Network address change notification is mandatory only in the IPv6 405 network. 407 We split the IPv6 address of the IPv6 packet underlying FSP into 408 three parts. The leftmost 64-bit long word is the network prefix, 409 which SHOULD be the unique IPv6 prefix assigned to the host 410 [RFC8273]. The centermost 32-bit word is called the aggregation host 411 ID, and the rightmost 32-bit word is the ULTID. While the ULTID MUST 412 be kept stable even during the life of an FSP session, the network 413 prefix part MAY change when an endpoint is roaming. The aggregation 414 host ID may change as well. The network prefix part together with the 415 aggregation host ID part act as the traditional routing locator at 416 the network layer. 418 It is supposed that the network layer immediately notify FSP of the 419 network prefix and/or aggregation host ID change. 421 An participant of an FSP connection SHALL immediately notify its peer 422 whenever its underlying IPv6 address is changed with a KEEP_ALIVE 423 packet. The peer shall send packet to the participant that has 424 notified the address change with the new address. 426 It is supposed that the packet to inform the remote end to update the 427 lower layer address association could reach its destination in a 428 satisfying success rate. 430 3.1.3. Network Congestion Control 432 It is supposed that end-to-end congestion control is provided at some 433 sub-layer of the network layer. Implementation of FSP MUST include a 434 congestion manager [RFC3124] if such sub-layer service of the network 435 layer is not provided. 437 3.2. Identifying Connection by Local ULTID 439 Each FSP connection prepares a pair of ULTIDs. ULTID is assigned 440 roughly the same semantics with the Security Parameter Index (SPI) in 441 IKE [RFC4301]. An ULTID uniquely indexes a connection in the local 442 context of an FSP end node. An FSP end node relies neither source IP 443 address nor destination IP address, except the ULTID part of the near 444 end's IPv6 address to identify an FSP connection. 446 Each ULTID is allocated in the local context of the two FSP 447 participant respectively. The source ULTID and the destination ULTID 448 of an FSP packet usually differ in their values. However, the secret 449 keys indexed in the local contexts of the two end-points must have 450 the same value. 452 3.3. Defending Against Connection Redirection with ICC 454 An integrity check code (ICC) field associated with the ULTID is 455 designed in the FSP header to protect authenticity and optionally 456 privacy of the FSP packet. An FSP packet is assumed to originate from 457 the same source if the ICC value associated with certain destination 458 ULTID passes validation, regardless of the source or destination 459 address in the underlying layer. 461 On initiating FSP takes use of [CRC64] to make checksum of the FSP 462 packet to protect it against unintentional modification. The checksum 463 is taken as the ICC. 465 After the ULA has installed a shared secret key, value of ICC is 466 calculated by firstly getting the secret key associated indexed by 467 the local ULTID, then calculating the tag value with the AES-GCM 468 [GCM] authenticated encryption with additional data algorithm [R01], 469 or calculating the message authentication code with the BLAKE2 470 algorithm [RFC7693]. 472 3.4. Transmit Transaction 473 FSP facilitates shared secret key installation by introducing the 474 concept of transmit transaction. 476 A transmit transaction of FSP is a sequence of FSP packets that were 477 sent and marked by ULA as one continuous stream where all packets in 478 the stream MUST be acknowledged before any further packet is allowed 479 to be sent. 481 A flag called 'End of Transaction' (EoT) is designed in the FSP 482 header. When it is set, it marks that the transmit transaction in the 483 direction from the source of the FSP packet towards the destination 484 of the FSP packet is committed. 486 3.5. Quad-party Session Key Installation Sub-protocol 488 It is proposed that it is the ULA to do key establishment and/or end- 489 point user-agent authentication while the FSP layer provides 490 authenticated, optionally encrypted data transfer service. It is 491 arguably much more flexible for the application layer protocols to 492 adopt new key establishment algorithm while offloading routine 493 authentication and optionally encryption of the data to the 494 underlying layers where it may be much easier to exploit hardware- 495 acceleration. 497 A dedicate application program interface (API) is designed for the 498 ULA to install the secret key established by the ULA participants. 500 Protocol for installation of the shared secret key is quad-party in 501 the sense that both the upper layer application and the FSP layer of 502 the two participant nodes MUST agree on the moment of certain state 503 to install the shared secret key. 505 The ULA installs the new secret key to the FSP layer. The FSP layer 506 SHALL make it sure that the new secret key is taken into effect 507 starting from the very first packet of the transmit transaction that 508 is immediately next to the transmit transaction where API for 509 installation of the new secret key is called. 511 By committing a transmit transaction a ULA participant clearly tells 512 the underlying FSP layer that the next packet sent MAY adopt a new 513 secret key. On receiving a packet with the EoT flag set the ULA is 514 informed that the next packet received MAY adopt a new shared secret 515 key. 517 The ULA participant that installs the new secret key firstly MUST be 518 the one that is committing a transmit transaction after it has 519 accepted peer's transmit transaction commitment. 521 After the ULA install a new secret key every packet sent later than 522 the one with the EoT flag set MUST adopt the new secret key. The peer 523 MUST have commit a transmit transaction and it SHALL install the same 524 secret key on receiving the FSP packet with the EoT flag set. 526 The ULA SHOULD have installed the new shared secret key, or install 527 it instantly after accepting the packet with the EoT flag set. 529 If the new secret key has ever been installed the packet received 530 after the one with the EoT flag set MUST adopt the new secret key. 532 In a typical scenario the ULA endpoints first setup the FSP 533 connection where resistance against connection redirection is weakly 534 enforced by CRC64. After the pair of ULA endpoints establish a shared 535 secret key, they install the secret key and commit current transmit 536 transactions. Authenticity of the FSP packets sent later is 537 cryptographically protected by the new secret key and resistance 538 against various attacks is secured. 540 Although transmit transaction is actually uni-directional the secret 541 key is shared bi-directionally in this version of FSP. 543 3.6. Zero Round-Trip Connection Multiplication 545 An FSP connection MAY be multiplied to get a branch or branches of 546 the connection. In this version of FSP a branch connection SHALL NOT 547 be multiplied further, and only the connection where authenticity of 548 the packets is cryptographically protected may be multiplied. 550 The packet that carries the command to multiply an established FSP 551 connection MUST be sent from a new allocated local ULTID towards the 552 destination ULTID of the original connection. It is an out-of-band 553 packet in the context of the original connection and it MUST be 554 cryptographically protected by the secret key of the original 555 connection. The packet MAY carry payload. 557 The receiver of the packet MUST allocate a new local ULTID, accept 558 the optional payload in the new context associated with the new 559 ULTID, derive a new secret key from the secret key of the original 560 connection, and responds from the new context. The response MAY carry 561 payload. 563 The very first response packet MUST be protected by the new secret 564 key. The sender of the multiply command packet MUST automatically 565 inaugurate the same secret key, derived from the secret key of the 566 same original connection. And it MUST treat the response packet as 567 though a transmit transaction had been committed by the responder, 568 i.e. authenticity of the response packet is verified with the new 569 secret key. 571 Thus the branch connection of a new pair of ULTIDs is established 572 with zero round-trip overhead. This mechanism may be exploited to 573 provide expedited data transfer or parallel data transfer service. 575 4. Packet Structure 577 4.1. FSP over UDP/IPv4 579 In this version of FSP, when FSP is implemented in the IPv4 network, 580 every FSP packet MUST be encapsulated in a UDP datagram. The UDP 581 datagram encapsulated the FSP packet SHALL have the checksum 582 disabled. The Source and the destination ULTIDs are put at the 583 leading position of the UDP payload. FSP fixed header, optional 584 extension headers and FSP payload follow the ULTIDs: 586 0 15 16 31 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Source Port | Destination Port | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Length | 0 | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Source Upper Layer Thread ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Destination Upper Layer Thread ID | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | | 597 ~ FSP Fix Header ~ 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 ~ Optional FSP Extension Headers ~ 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 ~ ~ 603 ~ Optional FSP payload ~ 604 ~ ~ 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 1 FSP over UDP 609 4.2. FSP over IPv6 611 When FSP is implemented over IPv6, the ULTID part is embedded in the 612 IPv6 address. FSP fixed header follows the IPv6 headers: 614 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 615 ~ IPv6 Header: ~ 616 0 15 16 31 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |Version| Traffic Class | Flow Label | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Payload Length | Next Header | Hop Limit | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | | 623 + Source Network Prefix + 624 | | 625 + Source Address ----------------------------+ 626 | Source Aggregation Host ID | 627 + ----------------------------+ 628 | Source Upper Layer Thread ID | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | | 631 + Destination Network Prefix + 632 | | 633 + Destination Address ---------------------------------+ 634 | Destination Aggregation Host ID | 635 + ---------------------------------+ 636 | Destination Upper Layer Thread ID | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 ~ ~ 639 ~ Optional IPv6 Headers ~ 640 ~ ~ 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | | 643 ~ FSP Fix Header ~ 644 | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 ~ Optional FSP Extension Headers ~ 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 ~ ~ 649 ~ Optional FSP payload ~ 650 ~ ~ 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Figure 2 FSP over IPv6 655 o Network Prefix 656 The leftmost 64-bit of the IPv6 address which MAY and usually do 657 have different value at the difference interface of an IPv6 end- 658 node. 660 o Aggregation Host ID 661 The left 32-bit part of the rightmost 64-bit long word of the IPv6 662 address. All of the aggregation host ID parts of an IPv6 end-node's 663 IPv6 addresses MUST have the same value for this version of FSP. 665 4.3. Generic FSP Header 667 FSP headers include the fixed header and the extension headers. A 668 general fixed header consists of 20-byte operation-code specific 669 fields and a 32-bit FSP Header Signature. An extension header 670 consists an operation-code specific content and a 32-bit FSP Header 671 Signature. The length of the extension header content may be 672 variable, provided that the tail of the full extension header align 673 on 64-bit boundary. 675 0 31 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 ~ ~ 678 ~ Operation Code Specific Fields ~ 679 ~ ~ 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Header Signature | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Figure 3 FSP Header 686 4.4. FSP Header Signature 688 0 15 16 31 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Header Stack Pointer | Major | Operation Code| 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Figure 4 FSP Header Signature 695 4.4.1 Header Stack Pointer 697 For the fixed header the header stack pointer is a 16-bit unsigned 698 integer that specifies the offset of the first octet of the payload. 700 For an extension header the header stack pointer is a 16-bit unsigned 701 integer that specifies the offset of the first octet of the very 702 extension header. 704 The offset that the header stack pointer specifies starts from the 705 begin of the FSP fixed header. If its value is 24 the header contains 706 it is the last extension header or the fix header without any 707 extension. 709 4.4.2 Major 710 It is an octet states current FSP major version. For this FSP version 711 it MUST be 0. 713 It is not mandatory for different major versions of FSP to be 714 compatible. 716 4.4.3 Operation Code 718 It is an octet that stores the code of the command which indicates 719 the function of the packet. 721 Synonym Code Meaning 723 INIT_CONNECT 1 Initialize Connection 725 ACK_INIT_CONNECT 2 Acknowledge Initialization of Connection 727 CONNECT_REQUEST 3 Formally Request to Connect 729 ACK_CONNECT_REQ 4 Acknowledge the Connection Request 731 RESET 5 Reset a connection 732 Refuse to 733 establish the connection, or abort 734 connection. 735 NULCOMMIT 6 Commit without payload 736 The NULCOMMIT packet MUST be payload- 737 less, and its EoT flag MUST be set. It 738 MAY carry optional headers. It always 739 consumes a slot of the send sequence 740 space. It is to commit current transmit 741 transaction, otherwise the NULCOMMIT 742 packet itself SHALL just be skipped when 743 delivering data to ULA. 745 ACK_START 6 Alias of NULCOMMIT, ACKnowledgement to 746 start a connection 747 It is the acknowledgement to 748 ACK_CONNECT_REQ or MULTIPLY, to confirm 749 that the connection has been established 750 or multiplied. ACK_START, or NULCOMMIT, 751 MAY both start a payload-less transmit 752 transaction and terminate the transmit 753 transaction. 755 KEEP_ALIVE 7 Keep the peer alive 756 It is an out-of-band control packet 757 acting as the heart-beating signal. An 758 out-of-band control packet does not 759 consume send sequence space itself. FSP 760 takes use of the KEEP_ALIVE packet to 761 inform the peer about the change of the 762 source IP addresses. Besides, when the 763 MIND flag is set, the KEEP_ALIVE packet 764 is meant to tell the peer which packets 765 should be retransmitted. If the End of 766 Transaction flag of the KEEP_ ALIVE 767 packet is set it is meant to forcefully 768 commit current transmit transaction of 769 the sender of the KEEP_ALIVE packet. 771 PERSIST 8 Make a connection persistent 772 It is meant to start a new transmit 773 transaction after a connection migrated 774 to CLOSABLE state. It can also 775 acknowledge ACK_CONNECT_REQ or MULTIPLY. 776 It MUST carry payload. It always 777 consumes a slot of the send sequence 778 space. 780 PURE_DATA 9 Pure Data 781 It does not carry any optional header. 783 ACK_FLUSH 10 ACKnowledge to remote end's commitment 784 (FLUSHing) of transmit transaction. It 785 is an out-of-band control packet like 786 KEEP_ALIVE. It is sent instantly on 787 having every packet of the last transmit 788 transaction received, meant to make 789 acknowledgment to the remote end and let 790 the remote end stop sending heart-beat 791 signals. 793 RELEASE 11 Release the connection 794 RELEASE packet does not carry payload 795 but it always consumes a slot of the 796 send sequence space. Only when each peer 797 has committed current transmit 798 transaction may a RELEASE packet sent 799 under the request of the ULA. 801 MULTIPLY 12 Multiply the connection 802 It is sent in the context of the 803 original connection and may carry 804 payload and/or optional headers as an 805 out-of-band packet. 807 PEER_SUBNETS 17 Tell the remote end how to address 808 the sender of the packet in the reverse 809 direction. It is the code of the Sink 810 Parameter extension header. 812 SELECTIVE_NACK 18 Tell the remote end to retransmit 813 the packets that were negatively 814 acknowledged. It is the code of the 815 Selective Negative Acknowledgment 816 extension header. 818 4.5. Preliminary FSP Packets 820 Preliminary FSP packets are the packets exchanged during the end-to- 821 end negotiation phase of FSP connection establishment when it is 822 impossible to calculate ICC normally. 824 4.5.1. Connect Initialization 826 0 31 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | | 829 + Timestamp + 830 | | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 + Init-Check-Code + 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Salt | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Header Signature | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 ~ ~ 841 ~ Host Name of the Responder (optional) ~ 842 ~ ~ 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 Figure 5 Connect Initialization 847 Operation Code of this type of packet is INIT_CONNECT. 849 o Timestamp 850 It is a 64-bit unsigned integer that represents number of 851 microseconds elapsed since 00:00, Jan.1, 1970, Coordinated 852 Universal Time. It may be exploited to synchronize the clocks of 853 the participants and/or estimate delay during data transmission in 854 the network. 856 o Init-Check-Code 857 It is a 64-bit random [RFC4086] bit string that means to uniquely 858 associated with the connection initiated. 860 o Salt 861 It a 32-bit random bit string that may be exploited to make secret 862 key agreement. 864 o Host Name of the Responder 865 The optional payload of the Connect Initialization packet is the 866 host name, which is encoded in UTF-8 [RFC3629] and SHOULD be 867 resolvable in DNS, of the responder. 869 4.5.2. Acknowledgment to Connect Initialization 871 0 31 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 874 + Cookie + 875 | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 + Init-Check-Code + 879 | | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 ~ ~ 882 ~ Sink Parameter ~ 883 ~ ~ 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Time Delta | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Header Signature | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Figure 6 Acknowledgment to Connect Initialization 892 Operation Code of this type of packet is ACK_INIT_CONNECT. 894 o Cookie 895 It is a 64-bit bit string cryptographically generated by the 896 responder in a represent-transfer state manner. More specifically 897 when the same timestamp, time delta, Init-Check-Code, salt, source 898 and destination ULTIDs are sent to the responder, the responder 899 MUST be able to generate the identical cookie value. 901 o Init-Check-Code 902 It MUST be identical to the corresponding field in the Connect 903 Initialization packet acknowledged. 905 o Sink Parameter 906 It is an extension header specified in 4.7. 908 o Time Delta 909 It is a 32-bit signed integer which is the difference between the 910 near-end's time and the timestamp value sent in the Connection 911 Initialization packet. The units and the epoch of the near-end's 912 time value and the timestamp value MUST be the same. However, the 913 precision or resolution of the time delta value is chosen 914 arbitrarily by the responder. 916 4.5.3. Connect Request 918 0 31 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | | 921 + Time Stamp + 922 | | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | | 925 + Init-Check-Code + 926 | | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Salt | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Header Signature | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Initial Sequence Number | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Time Delta | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | 937 + Cookie + 938 | | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 ~ ~ 941 ~ Sink Parameter ~ 942 ~ ~ 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 ~ ~ 945 ~ Host Name of the Initiator (optional) ~ 946 ~ ~ 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 Figure 7 Connect Request 951 Operation Code of this type of packet is CONNECT_REQUEST. 953 The value of each field that has the identical name with the one in 954 the associated Connect Initialization and Acknowledgment to Connect 955 Initialization packet MUST be assigned the same value as in these two 956 packets, except header signature in the packet. 958 o Sink Parameter 959 It is an extension header specified in 4.7. 961 o Host Name of the Initiator 962 The optional payload of the Connect Request packet is the host 963 name, which is encoded in UTF-8 and SHOULD be resolvable in DNS, of 964 the initiator. 966 It could be exploited by the responder to look up the address of 967 the initiator that may receive packets in the reverse direction. 969 4.6. Normal Fixed Header 971 0 15 16 31 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Sequence Number | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Expected Sequence Number | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | | 978 + Integrity Check Code + 979 | | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Flags | Advertised Receive Window Size | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Header Signature | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 8 FSP Fixed Header 988 Operation Code of a normal fixed header may be ACK_CONNECT_REQ, 989 PURE_DATA, PERSIST, KEEP_ALIVE, ACK_FLUSH, RELEASE or MULTIPLY. 991 o Sequence Number 992 Each in-band FSP packet is assigned a 32-bit unsigned integer as 993 the sequence number. The sequence number assigned for in-band FSP 994 packets MUST be in strict order. 996 An out-of-band packet that has the operation code of KEEP_ALIVE, 997 ACK_FLUSH or MULTIPLY MUST be assigned a sequence number that falls 998 in the receive window. 1000 o Expected Sequence Number 1001 It stores the earliest sequence number of the packets that were not 1002 yet received in the receive window of the sender. It is an 1003 accumulative acknowledgment. Any packet with the sequence number 1004 before the received Expected Sequence Number is supposed to have 1005 been received by the remote end. 1007 o Integrity Check Code 1008 The ICC. 1010 o Flags 1011 It is bit-field of width 8. From left to right: 1013 - End of Transaction (EoT): If the EoT flag of a packet is set, it 1014 is the last packet of a transmit transaction. A packet with the 1015 EoT flag set MAY be the start and the single packet of the 1016 transmit transaction as well. 1018 - Minimal-Delay (MIND): If the MIND flag of the Connect Request or 1019 Acknowledgment to Connect Request packet is set, the ULA prefers 1020 minimal delay and is willing to tolerate packet loss. FSP SHALL 1021 drop the packet received earliest when there is no enough receive 1022 buffer so that the latest packet received can be saved and the 1023 delay to deliver data to ULA is minimized. 1025 If the MIND flag has been set the EoT flag of any following 1026 packet is simply ignored. 1028 The MIND flag of an FSP packet may be set only if the packet does 1029 not belong to a compressed transmit transaction. 1031 Payload of each FSP packet is delivered to the ULA as an 1032 independent message if the MIND flag has been set. 1034 - Compressed (CPR) If the CPR flag of the first packet of a 1035 transmit transaction is set, compression is applied on the octet 1036 stream of the payloads of the continuous packets that constitute 1037 the transmit transaction, or to put it simply, the payload octet 1038 stream of the transaction transaction. Such transmit transaction 1039 is called a compressed transmit transaction. 1041 When the CPR flag of a packet is set, CPR flag of each following 1042 packet is ignored until reaching termination of the transmit 1043 transaction. 1045 If the payload octet stream of the transmit transaction is 1046 compressed the Minimal-Delay flag of any packet in the transmit 1047 transaction MUST be cleared. 1049 - ECN-Echo (ECE): The Explicit Congestion Notification Echo flag of 1050 a packet is set if the sender of the packet has received an 1051 underlying IPv6 packet with Congestion Experienced code point set 1052 for its peer as stated in "The Addition of Explicit Congestion 1053 Notification (ECN) to IP" [RFC3168]. 1055 - Send Rate Reduced (SRR): The SRR flag of each packet SHALL be set 1056 as soon as the sender has received a legitimate packet with ECE 1057 flag set and has informed the congestion manager to reduce the 1058 send rate, until a sent packet with SRR flag set is acknowledged. 1060 The remaining 3 bits are reserved. 1062 o Advertised Receive Window Size 1063 It is a 20-bit unsigned integer that stores number of the free 1064 blocks in the receive buffer of the sender of the packet that 1065 contains the receive window size field. It is count from the slot 1066 meant to accept the packet with the expected sequence number. 1068 The sender must ensure that the difference between the latest 1069 sequence number sent out and the largest expected sequence number 1070 received does not exceed the value of the latest advertised receive 1071 window size received. 1073 4.7. Sink Parameter 1075 0 31 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 ~ ~ 1078 ~ Addressable Network Prefixes ~ 1079 ~ ~ 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Listener ID/Host ID | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Header Signature | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Figure 9 Sink Parameter 1088 Operation Code in the Header Signature of this extension header is 1089 PEER_SUBNETS. 1091 o Addressable Network Prefixes 1092 These are up to 4 64-bit words that specify the network prefixes of 1093 the lower layer interfaces that are addressable by the receiver in 1094 the reverse direction. 1096 In this version of the FSP 'Addressable Network Prefixes' field is 1097 of fixed length. The last network prefix which is non-zero is the 1098 last resort one. There MUST be at least one non-zero network 1099 prefix. If there are more than one non-zero network prefixes those 1100 other than the last resort are load-balanced preferred. 1102 In an IPv6 network, the addressable network prefix is the leftmost 1103 64 bits of the IPv6 address. The receiver of the Addressable 1104 Network Prefixes SHALL send packet in the reverse direction, i.e. 1105 to the sender of the field with the destination IPv6 address 1106 generated by combining a preferred network prefix with the 1107 aggregation host id and the ULTID part of the source address in the 1108 IPv6 header of the received packet that eventually carries the 1109 Addressable Network Prefixes. 1111 Such feature MAY be exploited to handle links with unidirectional 1112 connectivity, but it is NOT RECOMMENTED. 1114 In an IPv4 network for compatibility with the IPv6 addressed ULA 1115 the 64-bit word of the addressable network prefix specified is 1116 composed as following Figure: 1118 0 15 16 31 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | 0x2002 (IPv6 6to4 prefix) |IPv4 address (leftmost 16 bits)| 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 |IPv4 address(rightmost 16 bits)| UDP port number (16 bits) | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Figure 10 Addressable Network Prefix of FSP over UDP/IPv4 1127 Sender of the Sink Parameter packet SHOULD be NAT-aware. If it is 1128 able to obtain the from the NAT box (as defined in "Traditional IP 1129 Network Address Translator (Traditional NAT)" [RFC3022]) through Port 1130 Control Protocol (PCP) [RFC6887] SHOULD fill in the IPv4 address and 1131 UDP port number fields with the public IP value that were obtained. 1132 If it does not have such capability, it SHALL fill in the addressable 1133 network prefix with all binary zeroes. 1135 o Listener ID 1136 It is the ULTID of the responder that is in LISTENING state. 1138 o Host ID 1139 It is the aggregation host id of the sender. It SHALL be 0 if it is 1140 in the IPv4 network. 1142 4.8. Selective Negative Acknowledgment 1144 0 31 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Gap Width | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Data Length | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 ~ ~ 1151 ~ Further pairs of (Gap Width, Data Length) ~ 1152 ~ ~ 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | | 1155 + Acknowledgement Delay + 1156 | | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Out-band Serial Number | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Header Signature | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 Figure 11 Selective Negative Acknowledgment 1165 The operation code of this type of extension header is SNACK. The 1166 SNACK header contains the descriptor of the receive window gaps: 1168 The descriptor itself is a list of entries. The length of the list 1169 can be zero which means that there is no gap in the receive window. 1170 If the list is not empty, each entry contains the width of one gap in 1171 the receive window and the length of the continuously received data 1172 following the gap, respectively. The unit of aforementioned length of 1173 gaps or number of packets is buffer block. 1175 o Acknowledgement Delay 1176 A 64-bit unsigned integer specifies the delay in microseconds 1177 between sending the packet containing the SNACK extension header 1178 and accepting the last packet that is accumulatively acknowledged 1179 by the SNACK extension header. 1181 o Out-band Serial Number 1182 The SNACK header contains a 32-bit out-band serial number as well. 1183 Each time a packet that contains the SNACK header is sent the out- 1184 band serial number shall increase by one. It is assumed that in the 1185 life of the session no two packets have the same sequence number 1186 and the same SNACK header serial number simultaneously. 1188 4.9. RESET 1189 The 'RESET' packet is a special command packet meant to interrupt 1190 connection setup process or disconnect abruptly. Operation Code of 1191 the packet is RESET. 1193 Structure of a RESET packet in C code snippet with unnamed union 1194 applied: 1196 struct FSP_RejectConnect 1197 { 1198 /* sequence numbers */ 1199 union 1200 { 1201 timestamp_t timeStamp; 1202 struct 1203 { 1204 uint32_t initial; 1205 uint32_t expected; 1206 } sn; 1207 }; 1208 /* uniqueness proof */ 1209 union 1210 { 1211 uint64_t integrityCode; 1212 uint64_t cookie; 1213 uint64_t initCheckCode; 1214 }; 1215 /* bit field to describe reasons for reset */ 1216 uint32_t reasons; 1217 $FSP_HeaderSignature hs; 1218 }; 1220 When the RESET packet is the response to a Connect Initialization 1221 packet both the timeStamp and the initCheckCode fields of the RESET 1222 packet MUST be set to the same values of Time Stamp and Init-Check- 1223 Code in the Connect Initialization packet, respectively. 1225 When the RESET packet is the response to a Connect Request packet 1226 both the timeStamp and the cookie fields of the RESET packet MUST be 1227 set to the same value of Time Stamp and Cookie in the Connect Request 1228 packet, respectively. 1230 When the RESET packet is the response to a packet with a normal fixed 1231 header, the sn.initial, the sn.expected and the integrityCode of the 1232 RESET packet MUST be set as to specification of normal fixed header 1233 field Sequence Number, Expected Sequence Number and Integrity Check 1234 Code, respectively. 1236 5. The Finite State Machine 1238 5.1. NON_EXISTENT 1239 ---[API: Listen]-->LISTENING 1240 |--[API: Connect]-->CONNECT_BOOTSTRAP-->[Send INIT_CONNECT] 1241 |--[API: Multiply]-->CLONING-->[Send MULTIPLY] 1243 NON_EXISTENT is a pseudo-state before a connection is created by the 1244 ULA calling API Listen, Connect or Multiply (or after a connection is 1245 reset). 1247 5.2. LISTENING 1248 ---[API: Reset]-->NON_EXISTENT 1249 |<-->[Rcv.INIT_CONNECT]{&& accepted}[Send ACK_INIT_CONNECT] 1250 |<-->[Rcv.INIT_CONNECT]{&& rejected}[Send RESET] 1251 |<-->[Rcv.CONNECT_REQUEST]{&& duplication detected} 1252 [Retransmit ACK_CONNECT_REQ] 1253 |--[Rcv.CONNECT_REQUEST]-->{Notify} 1254 |-->[API: Accept] 1255 -->{new context}CHALLENGING-->[Send ACK_CONNECT_REQ] 1256 |-->[API: Reject]-->[Send RESET] {abort new context, if any} 1258 LISTENING is a state entered by the ULA calling API Listen. 1260 5.3. CONNECT_BOOTSTRAP 1261 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1262 |--[Rcv.ACK_INIT_CONNECT]-->CONNECT_AFFIRMING 1263 |-->[Send CONNECT_REQUEST] 1264 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1265 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1267 CONNECT_BOOTSTRAP is a state entered by the ULA calling API Connect, 1268 before receiving the acknowledgement of the remote end to the 1269 connection initialization packet. 1271 5.4. CONNECT_AFFIRMING 1272 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1273 |--[Rcv.ACK_CONNECT_REQ]-->[Notify] 1274 |-->{Callback return to accept} 1275 |-->{EOT} 1276 |-->{No Payload to Send}-->COMMITTING2-->[Send ACK_START] 1277 |-->{Has Payload to Send} 1278 |-->{ULA-flushing}-->COMMITTING2 1279 -->[Send PERSIST with EoT] 1280 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Send PERSIST] 1281 |-->{Not EOT} 1282 |-->{No Payload to Send}-->COMMITTING-->[Send ACK_START] 1283 |-->{Has Payload to Send} 1284 |-->{ULA-flushing}-->COMMITTING 1285 -->[Send PERSIST with EoT] 1286 |-->{Not ULA-flushing}-->ESTABLISHED-->[Send PERSIST] 1287 |-->{Callback return to reject]-->NON_EXISTENT-->[Send RESET] 1288 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1289 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1291 CONNECT_AFFIRMING is a state entered by the ULA affirming to send 1292 connect request after receiving the acknowledgement to the connection 1293 initialization packet. 1295 5.5. CHALLENGING 1296 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1297 |<-->[API: Send{new data}]{just pre-buffer} 1298 |--[Rcv.ACK_START] 1299 |-->{ULA-flushing}-->CLOSABLE-->[Notify] 1300 -->[Send ACK_FLUSH] 1301 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Notify] 1302 -->[Send ACK_FLUSH] 1303 |--[Rcv.PERSIST] 1304 |-->{EOT} 1305 |-->{ULA-flushing}-->CLOSABLE-->[Notify] 1306 -->[Send ACK_FLUSH] 1307 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Notify] 1308 -->[Send ACK_FLUSH] 1309 |-->{Not EoT} 1310 |-->{ULA-flushing}-->COMMITTED-->[Notify] 1311 -->[Send delay SNACK] 1312 |-->{Not ULA-flushing}-->ESTABLISHED-->[Notify] 1313 -->[Send delay SNACK] 1314 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1315 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1317 CHALLENGING is a state entered by the ULA accepting the connection 1318 request after a new connection context has been incarnated. The new 1319 connection is incarnated by the FSP context of the near end in the 1320 LISTENING state as a legitimate CONNECT_REQUEST packet is received. 1322 5.6. ACTIVE{A.K.A. ESTABLISHED} 1323 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1324 |--[API: Send{flush}]-->COMMITTING{Urge to commit} 1325 |<-->[API: Send{more data}][Send PURE_DATA] 1326 |--[Rcv.NULCOMMIT] 1327 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1328 |--[Rcv.PURE_DATA] 1329 |--{Not EOT}-->[Send SNACK]-->[Notify] 1330 |--{EOT} 1331 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1332 |--[Rcv.PERSIST] 1333 |--{Not EOT}-->[Send SNACK early] 1334 |--[EOT] 1335 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1336 |--[Rcv.MULTIPLY]{passive multiplication} 1337 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1338 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1340 ACTIVE or ESTABLISHED is a state that the FSP participant has 1341 finished end-to-end negotiation but has not committed current 1342 transmit transaction nor fully received the latest transmit 1343 transaction of the remote end. 1345 5.7. COMMITTING 1346 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1347 |--[Rcv.ACK_FLUSH]-->COMMITTED-->[Notify] 1348 |--[Rcv.NULCOMMIT] 1349 |-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1350 |--[Rcv.PURE_DATA] 1351 |--{Not EOT}-->[Send SNACK]-->[Notify] 1352 |--{EOT}-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1353 |--[Rcv.MULTIPLY]{passive multiplication} 1354 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1355 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1357 COMMITTING is a state that the FSP participant has committed the 1358 transmit transaction but has not fully received the latest transmit 1359 transaction of the remote end, nor the acknowledgement to the 1360 transmit transaction commitment has been received. 1362 The participant in COMMITTING state SHALL NOT transmit further data 1363 until current transmit transaction commitment is acknowledged. 1365 5.8. COMMITTED 1366 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1367 |--[API: Send{more data}]-->ACTIVE-->[Send PERSIST] 1368 |--[API: Send{flush}]-->COMMITTING-->{Flush the send queue} 1369 |--[Rcv.NULCOMMIT] 1370 |-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1371 |--[Rcv.PURE_DATA] 1372 |-->{Not EOT}-->[Send SNACK]-->[Notify] 1373 |-->{EOT} 1374 |-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1375 |--[Rcv.PERSIST] 1376 |-->{Not EOT}-->[Send SNACK] 1377 |-->{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1378 |--[Rcv.MULTIPLY]{passive multiplication} 1379 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1380 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1382 COMMITTED is a state that the FSP participant has committed current 1383 transmit transaction and has received the acknowledgement to the 1384 transmit transaction commitment, but has not fully received the 1385 latest transmit transaction of the remote end. 1387 5.9. PEER_COMMIT 1388 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1389 |--[API: Send{flush}]-->{Mark EoT or append NULCOMMIT} 1390 |-->COMMITTING2-->{Do Send} 1391 |--[API: Shutdown]-->{Append RELEASE} 1392 |-->COMMITTING2-->{Do Send} 1393 |<-->[API: Send{more data}][Send PURE_DATA] 1394 |<-->[Rcv.PURE_DATA]{just prebuffer} 1395 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1396 |--[Rcv.PERSIST] 1397 |-->{Not EOT}-->ACTIVE-->[Send SNACK] 1398 |<-->{EOT}-->[Send ACK_FLUSH] 1399 |--{&& is new transaction}-->[Notify] 1400 |--[Rcv.MULTIPLY]{passive multiplication} 1401 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1402 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1404 PEER_COMMIT is a state that the FSP participant has not committed 1405 current transmit transaction but has fully received the latest 1406 transmit transaction of the remote end, and the acknowledgement to 1407 the transmit transaction commitment has not been received yet. 1409 5.10 COMMITTING2 1410 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1411 |--[API: Shutdown]-->{Append RELEASE}-->PRE_CLOSED-->{Do Send} 1412 |<-->[Rcv.PURE_DATA]{just prebuffer} 1413 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1414 |--[Rcv.ACK_FLUSH]-->CLOSABLE-->[Notify] 1415 |--[Rcv.PERSIST] 1416 |-->{Not EOT}-->COMMITTING-->[Send SNACK] 1417 |-->{EOT}-->[Send ACK_FLUSH] 1418 |--{&& is a new transaction}-->[Notify] 1419 |--[Rcv.MULTIPLY]{passive multiplication} 1420 |--[Rcv.RELEASE]-->[Send ACK_FLUSH]-->[Notify]-->CLOSED 1421 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1422 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1424 COMMITTING2 is a state that the FSP participant has committed current 1425 transmit transaction and has fully received the latest transmit 1426 transaction of the remote end, but the acknowledgement to the 1427 transmit transaction commitment has not been received yet. 1429 The participant in COMMITTING2 state SHALL NOT transmit further data 1430 until current transmit transaction commitment is acknowledged. 1432 5.11 CLOSABLE 1433 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1434 |--[API: Send{more data}]-->PEER_COMMIT-->[Send PERSIST] 1435 |--[API: Send{flush}]-->COMMITTING2-->{Flush the send queue} 1436 |--[API: Shutdown]-->{Append RELEASE}-->PRE_CLOSED-->{Do Send} 1437 |<-->[Rcv.PURE_DATA]{just prebuffer} 1438 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1439 |--[Rcv.PERSIST] 1440 |-->{Not EOT}-->COMMITTED-->[Send SNACK] 1441 |-->{EOT}-->[Send ACK_FLUSH] 1442 |--{&& is a new transaction}-->[Notify] 1443 |--[Rcv.MULTIPLY]{passive multiplication} 1444 |--[Rcv.RELEASE]-->[Send ACK_FLUSH]-->[Notify]-->CLOSED 1445 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1447 CLOSABLE is a state that the FSP participant has committed current 1448 transmit transaction and has received the acknowledgement to the 1449 transmit transaction commitment, and has fully received the latest 1450 transmit transaction of the remote end. 1452 5.12 PRE_CLOSED 1453 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1454 |--[Rcv.ACK_FLUSH]-->CLOSED-->[Notify] 1455 |--[Rcv.RELEASE]-->[Notify]-->CLOSED 1456 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1457 |--{On transient state Timeout}-->CLOSED-->[Notify] 1459 PRE_CLOSED is a state entered by the ULA calling the API Shutdown in 1460 CLOSABLE state. 1462 5.13 CLOSED 1463 |--{On Recycling Needed}-->NON_EXISTENT 1465 CLOSED is a state migrated from PRE_CLOSED state on receiving a 1466 legitimate RELEASE packet from the remote end. 1468 Unlike TCP [STD7], CLOSED state in FSP is not fictional. Instead a 1469 connection context MAY persist in CLOSED state until the session key 1470 runs out of life, or the host system needs to recycle the resource 1471 allocated to the CLOSED session. A connection in CLOSED state MAY be 1472 resurrected. 1474 5.14 CLONING 1475 ---[API: Reset]-->NON_EXISTENT 1476 |<-->[API: Send{new data}]{just prebuffer} 1477 |<-->[Rcv.PURE_DATA]{just prebuffer} 1478 |--[Rcv.ACK_START] 1479 |--{&& Not ULA-flushing}-->PEER_COMMIT 1480 |-->[Send ACK_FLUSH]-->[Notify] 1481 |--{&& ULA-flushing}-->CLOSABLE 1482 |-->[Send ACK_FLUSH]-->[Notify] 1483 |--[Rcv.PERSIST] 1484 |-->{Not EOT} 1485 |--{&& Not ULA-flushing}-->ACTIVE 1486 |-->[Send SNACK]-->[Notify] 1487 |--{&& ULA-flushing}-->COMMITTED 1488 |-->[Send SNACK]-->[Notify] 1489 |-->{EOT} 1490 |--{&& Not ULA-flushing}-->PEER_COMMIT 1491 |-->[Send ACK_FLUSH]-->[Notify] 1492 |--{&& ULA-flushing}-->CLOSABLE 1493 |-->[Send ACK_FLUSH]-->[Notify] 1494 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1495 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1497 CLONING is a state entered by ULA calling the API Multiply from any 1498 state that may accepting an out-of-band packet. 1500 5.15 Passive Multiplication 1501 {ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, COMMITTING2, CLOSABLE} 1502 |-->/MULTIPLY/-->[API{Callback}]-->{new context}CONNECT_AFFIRMING 1503 |-->[{Return Accept}] 1504 |-->{has payload prebuffered}-->{do respond} 1505 |-->{without payload}-->[Prebuffer ACK_START]-->{do respond} 1506 |-->[{Return Reject}]-->{abort creating new context}[Send RESET] 1508 In the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, COMMITTING2 or 1509 CLOSABLE state an FSP end node MAY accept its peer's connection 1510 multiplication request and transit to the unnamed, temporary passive 1511 multiplication state. 1513 6. End-to-End Negotiation 1514 End-to-end negotiation of FSP session occurs in the connection 1515 establishment phase. Connection establishment process of FSP consists 1516 of two and a half pairs of packet exchanges for connection 1517 initialization, connection incarnation and the last confirmation. 1518 During the process various optional header or payload MAY be carried 1519 in the FSP preliminary packets to negotiate end-to-end session 1520 parameters. 1522 6.1. Connect Initialization 1524 The initiator sends the INIT_CONNECT packet to the responder: 1525 (INIT_CONNECT, Timestamp, Init-Check-Code, Salt [, Responder's Host 1526 Name]) 1528 Connection initialization MAY be syndicated with optional address 1529 resolution at the gateway in the IPv6 network by carrying the 1530 responder's host name in the INIT_CONNECT packet. 1532 If it does carry the responder's host name it MUST take the link- 1533 local interface address [RFC4291] as the source IPv6 address and the 1534 default link-local gateway address, FE80::1, as the destination IPv6 1535 address no matter whether the global unicast IP address of the 1536 default gateway is configured. 1538 If the gateway that relays the INIT_CONNECT packet finds that the 1539 responder is on the same link-local network with the initiator it 1540 SHALL change the source and the destination IP addresses of the 1541 INIT_CONNECT packet to the link-local IP addresses of the initiator 1542 and the responder respectively, and relay the packet onto the same 1543 link-local network. 1545 On receiving the INIT_CONNECT packet that carries the responder's 1546 host name the link-local gateway MUST resolute the responder's global 1547 unicast IPv6 address and map the initiator's global unicast IPv6 1548 address, and replace the destination and source address of the 1549 INIT_CONNECT packet respectively, unless it finds that the initiator 1550 and the responder are on the same link-local network, where the 1551 gateway SHALL process the packet as stated in the previous statement. 1553 The gateway SHALL silently ignore the INIT_CONNECT packet if it is 1554 unable to resolve the IP address of the responder. 1556 If the destination address is the default link-local gateway address 1557 while the INIT_CONNECT does not carry the responder's host name 1558 payload, it is supposed that the gateway is the intent destination of 1559 the connection to initialize. 1561 6.2. Response to Connect Initialization 1563 The responder sends acknowledgment to the initiator: 1565 Case 1: (ACK_INIT_CONNECT, Cookie, Init-Check-Code Reflected, Time- 1566 delta, Responder's Sink Parameter) 1568 Case 2: (RESET, Timestamp Reflected, Init-Check-Code Reflected, 1569 Reason of Failure) 1571 In case 1 the responder is ready to accept the connection. It SHALL 1572 NOT make state transition on receiving INIT_CONNECT packet. It SHALL 1573 generate a cookie which is meant to be reflected by the initiator. 1574 The responder MUST send the ACK_INIT_CONNECT packet with the new 1575 allocated local ULTID instead of the original listening ULTID. The 1576 initiator should be able to find out the original listening ULTID by 1577 searching its own connection context. 1579 In the Responder's Sink Parameter the original listener ULTID MUST be 1580 set to the right value. 1582 In case 2 the responder refuses to accept the connection. It SHALL 1583 send back a RESET packet with the listening ULTID as the source 1584 ULTID. 1586 In either case the destination address of the packet sent back MUST 1587 be set to the source address of the corresponding Connect 1588 Initialization packet whose source and destination address MAY be 1589 updated by some intermediary such as the link-local gateway of the 1590 initiator. 1592 6.3. Connection Incarnation Request 1594 (CONNECT_REQUEST, Timestamp, Init-Check-Code, Salt, Cookie Reflected, 1595 Time-delta Reflected, Initial SN, Initiator's Sink Parameter [, 1596 Initiator's Host Name]) 1598 The initiator accepts the Response to Connect Initialization packet 1599 if and only if both the destination ULTID of the response packet 1600 matches the source ULTID of the connect initialization packet and the 1601 Init-Check-Code reflected in the response packet matches the Init- 1602 Check-Code in the connect initialization packet. 1604 If the response packet is accepted the initiator formally requests to 1605 establish the connection by sending the CONECT_REQUEST packet. 1607 In the CONNECT_REQUEST packet the value of the Timestamp, the Init- 1608 Check-Code and the Salt field MUST be the same as in the INIT_CONNECT 1609 packet while the value of the Cookie Reflected field and the Time- 1610 delta Reflected field MUST be the same as in the ACK_INIT_ CONNECT 1611 packet, respectively. 1613 The initiator MUST send the packet towards the remote ULTID that the 1614 responder has preserved and sent with the ACK_INIT_CONNECT packet. It 1615 MUST fill the original listener ID field in the Initiator's Sink 1616 Parameter with the right value. 1618 The source address of the CONNECT_REQUEST packet MUST be set to the 1619 destination address of the received ACK_INIT_CONNECT packet, while 1620 the network prefix and host-id part of the destination address MUST 1621 be set to the source address of the received ACK_INIT_CONNECT packet 1622 in the IPv6 network. 1624 The initiator SHALL save the cookie value that the responder has 1625 given to make up the weak session key. 1627 The initiator MUST fill the Initial SN field with the sequence number 1628 of the packet that will follow CONNECT_REQUEST. The CONNECT_REQUEST 1629 packet is payload free and does not consume the sequence space. 1631 The optional fields Initiator's Host Name is put as the payload of 1632 the CONNECT_REQUEST packet. If presented it MAY be exploited by the 1633 responder as the last resort to resolute the most recent IP address 1634 of the initiator in some extraordinary scenarios such as the 1635 initiator has hibernated for a considerably long time. 1637 6.4. Connection Incarnation Response 1639 Case 1: (ACK_CONNECT_REQ, Initial SN, Expected SN, ICC, FREWS[, 1640 Payload]) 1642 Case 2: (RESET, Timestamp Reflected, Copy of Cookie Reflected, Reason 1643 of Failure) 1645 The responder responds as in case 1 if the reflected cookie was 1646 validated, resources were successfully allocated and the initial 1647 context of the connection was setup. Otherwise it SHOULD respond as 1648 in case 2. 1650 The Initial SN in case 1 is the initial sequence number of the 1651 responder. The responder should fill in the field with a random 32- 1652 bit unsigned integer. As the ACK_CONNECT_REQ packet may carry payload 1653 the sequence number of the responder starts from the ACK_CONNECT_REQ 1654 packet. 1656 The Expected SN MUST equal to the Initial SN specified in the 1657 corresponding CONNECT_ REQUEST packet. 1659 6.5. The Last Confirmation 1661 Case 1: (ACK_START, Initial SN, Expected SN, ICC, FREWS) 1663 Case 2: (PERSIST, Initial SN, Expected SN, ICC, FREWS, payload) 1665 Case 3: (RESET, Initial SN, Expected SN, ICC, Reason of Failure) 1667 The initiator of the connection MUST eventually confirm to the 1668 responder that the connection is established by sending a payload- 1669 less ACK_START packet (case 1) or a PERSIST packet with payload (case 1670 2). 1672 Of course the initiator MAY quit to establish the connection by 1673 sending a legitimate RESET packet (case 3). 1675 6.6. Retransmission 1677 The initiator SHALL retransmit the INIT_CONNECT packet if the 1678 corresponding ACK_INIT_CONNECT packet is not received in some limit 1679 time (by default 15 seconds). 1681 The initiator SHALL retransmit the CONNECT_CONNECT packet if the 1682 corresponding ACK_CONNECT_REQ packet is not received in some limit 1683 time (by default 15 seconds). 1685 The responder SHALL NOT retransmit ACK_INIT_CONNECT or 1686 ACK_CONNECT_REQ packet. 1688 The initiator SHOULD retransmit the right INIT_CONNECT packet or 1689 CONNECT_CONNECT packet until the legitimate ACK_CONNECT_REQ packet is 1690 eventually received. 1692 It SHALL give up if the time starting from the very first 1693 INIT_CONNECT packet was sent has exceed a longer timed-out value (by 1694 default 60 seconds) before the legitimate ACK_CONNECT_REQ packet is 1695 received. 1697 7. Quad-party Session Key Installation 1699 It assumes that in the scenarios applying FSP it is the ULA to do key 1700 establishment and/or end-point authentication while the FSP layer 1701 provides authenticated, optionally encrypted data transfer service. 1702 Together they establish a secure channel between two application end- 1703 points. 1705 Protocol for installation of the shared secret key is quad-party in 1706 the sense that both the upper layer application and the FSP layer of 1707 both the participant nodes MUST agree on the moment of certain state 1708 to install the shared secret key. 1710 It is arguably much more flexible for the application layer protocols 1711 to adopt new key establishment algorithm while offloading routine 1712 authentication and optionally encryption of the data to the 1713 underlying layers where it may be much easier to exploit hardware- 1714 acceleration. 1716 7.1. API for Session Key Installation 1718 A dedicate application program interface (API) is designed for the 1719 ULA to install the secret key established by the ULA participants. 1720 The API SHOULD take four parameters: 1722 - A 'handle' to state the connection context for installing the 1723 session key 1724 - A octet string of initial key materials (IKM) 1725 - An integer to state the length of IKM. The unit is octet. 1726 - An integer to state the desired length of the effective session key 1727 if AEAD is applied. The unit is bit. For this version of FSP desired 1728 length of the effective session key is either 128 or 256. 1730 7.2. Time to Call API for Session Key Installation 1732 The ULA participant that installs the new secret key firstly MUST be 1733 the one that is committing a transmit transaction after it has 1734 accepted peer's transmit transaction commitment. 1736 In a typical scenario the ULA endpoints first setup the FSP 1737 connection where resistance against connection redirection is weakly 1738 enforced by CRC64. 1740 After the pair of ULA endpoints establish a shared secret key, they 1741 install the secret key and commit current transmit transactions. 1742 Authenticity of the FSP packets sent later is cryptographically 1743 protected by the new secret key and resistance against various 1744 attacks is secured. 1746 7.3. Time to Take New Session Key into Effect 1748 The FSP layer SHALL make it sure that the new secret key is taken 1749 into effect starting from the very first packet of the transmit 1750 transaction that is next to the transmit transaction whose context is 1751 where the new secret key is installed. Although transmit transaction 1752 is actually uni-directional the secret key is shared bi-directionally 1753 in this version of FSP. 1755 By committing a transmit transaction a ULA participant clearly tells 1756 the underlying FSP layer that the next packet sent MAY adopt a new 1757 secret key. On receiving a packet with the EoT flag set the ULA is 1758 informed that the next packet received MAY adopt a new shared secret 1759 key. 1761 After the ULA install a new secret key every packet sent later than 1762 the one with the EoT flag set MUST adopt the new secret key. The peer 1763 MUST have commit a transmit transaction and it SHALL install the same 1764 secret key on receiving the FSP packet with the EoT flag set. 1766 The ULA SHOULD have installed the new shared secret key, or install 1767 it instantly after accepting the packet with the EoT flag set. If the 1768 new secret key has ever been installed the packet received after the 1769 one with the EoT flag set MUST adopt the new secret key. 1771 7.4. Generating the Initial Session Key 1773 When the ULA install the secret key, it is required to provide the 1774 initial key material which might have unbalanced bit randomness, not 1775 the session key itself. HMAC-based Extract-and-Expand Key Derivation 1776 Function (HKDF) [RFC5869] is applied to generate the initial session 1777 key. 1779 Given raw key material ikm, length of the ikm nB in octets, intended 1780 master key length lenb in bits, || is octet string concatenation, 1782 If HMAC only is designated, the nB octets of ikm is hashed into 64 1783 octets which is taken as the master key. 1785 If AEAD is designated, the initial session key, or the first secret 1786 key for packet authentication and payload encryption is obtained as 1787 specified in [RFC5869]: 1789 Key Extract phase, 1791 Let Km = BLAKE2(zeros || ikm) , where 1793 zeros is 32 octets of integer 0 1795 BLAKE2b algorithm without key is applied. 1797 The result Km is the master key. 1799 Key Expand phase, 1800 Let Ks = BLAKE2(Km, info) , where 1802 Km is the master key generated in previous phase, 1804 info is concatenation of the arbitrary ASCII string "Establishes 1805 an FSP session", which is 26-octet long, 3 octets of integer 0, 1806 and 1 octet of integer 1. 1808 BLAKE2b algorithm with key is applied. The key applied MUST be the 1809 master key Km. 1811 The result Ks is the initial session key, or the first secret key 1812 for packet authentication and payload encryption. 1814 For this version FSP Ks is a fixed-length AES key together with a 1815 4-octet salt. The salt is meant to be passed to AES-GCM as the 1816 initialization vector together with the sequence number and 1817 expected sequence number fields in the normal FSP fixed header: 1819 0 31 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Salt | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Sequence Number | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Expected Sequence Number | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 Figure 12 Formation of Initialization Vector 1830 7.5. Internal Rekeying 1832 In this version of FSP it is forced to re-key on sending or receiving 1833 every 536870912? (2^29) packets. 1835 Let Ks' = BLAKE2(Km, H || info') , where: 1837 Km is the master key generated as in section 7.4. 1839 H is the 16-octet internal hash sub-key of AES-GCM of previous 1840 session key, 1842 info' is concatenation of the arbitrary ASCII string "Sustains an 1843 FSP connection", which is 26-octet long 1844 and the 4 octets in network order of the 32-bit unsigned integer 1845 that specifies the batch index of the session key. 1847 BLAKE2b algorithm with key is applied. The key applied MUST be the 1848 master key Km. 1850 The result Ks' is the new session key, together with the new salt 1851 meant to be form the IV. 1853 The batch index of the initial session key is 1, and it is increased 1854 by 1 every time before it is to re-key. 1856 8. Send and Receive 1858 8.1. Packet Integrity Protection 1860 8.1.1. Application of CRC64 1862 Starting from ACK_CONNECT_REQUEST, until the ULAs have installed the 1863 shared secret CRC64 is applied to calculate the value of the ICC 1864 field. The algorithm: 1866 1.Take pair of the ULDs as the initial value of accumulative CRC64 1867 The pair of the ULDs is composed of the near end's ULTID and the 1868 remote end's ULTID, where the former is the leftmost 32 bits and 1869 the latter is the rightmost 32 bits of initial value for the send 1870 direction, and the order is reversed for the receive direction. 1872 2.Accumulate the value of the Init-Check-Code field 1874 3.Accumulate the value of the Cookie field successively 1876 4.Accumulate the combined value of the salt and the timeDelta field 1877 where the former is the leftmost 32 bits and the latter is the 1878 rightmost 32 bits 1880 5.Accumulate the value of the Time Stamp field 1882 6.Save the accumulated CRC64 value 1883 as the pre-computed CRC64 value. 1885 When calculate the value ICC of a particular FSP packet, firstly set 1886 ICC to the pre-computed CRC64 value, then calculate the CRC64 1887 checksum of the whole FSP packet, while ULTIDs are NOT included if 1888 the FSP packet is encapsulated in UDP. The result is set as the final 1889 value of the ICC field. 1891 8.1.2. Packet Authentication Only 1893 The ULA designates the FSP layer to either applying HMAC only or 1894 applying AEAD. 1896 If the HMAC flag of a packet is set the pre-designated cryptographic 1897 hash function SHALL be applied to get the message authentication code 1898 (MAC) of the whole packet. Each FSP version MUST designate one and 1899 only one particular cryptographic hash function. 1901 For this FSP version, BLAKE2 [RFC7693] is designated as the 1902 cryptographic hash function. The input key is the secret key that has 1903 been derived from the master key installed by the ULA. The input data 1904 is the full FSP packet, where the ICC field is pre-filled the pair of 1905 the ULDs. As in making CRC64 checksum, the pair of the ULDs is 1906 composed of the near end's ULTID and the remote end's ULTID, where 1907 the former is the leftmost 32 bits and the latter is the rightmost 32 1908 bits of initial value for the send direction, and the order is 1909 reversed for the receive direction. 1911 The hash result is truncated to 64 bits to get the final ICC. 1913 8.1.3. Authenticated Encryption with Additional Data 1915 FSP provides per-packet authenticated encryption service. Only one 1916 authenticated encryption algorithm is allowed for a determined 1917 version of FSP. For this FSP version, the authenticated encryption 1918 algorithm selected is GCM-AES [GCM][AES], it is applied to protect 1919 integrity of the full FSP packets and privacy of the payload. The 1920 length of the session key is determined by the ULA. The four inputs 1921 to GCM-AES authenticated encryption are: 1923 K: the key derived by the master key installed by ULA. 1925 IV: the initial vector, 96-bit string made by concatenating a 32-bit 1926 salt, the 32-bit sequence number of the packet and the 32-bit 1927 expected sequence number field of the packet. The salt is derived by 1928 the master key installed by ULA. 1930 P: the plaintext are the bytes following the fixed header up to the 1931 end of the original payload 1933 AAD: additional authenticated data, from the source ULTID to the last 1934 byte of the fixed header. The source ULTID is stored in the leftmost 1935 32-bit of the ICC field while the destination ULTID is stored in the 1936 rightmost 32-bit of the ICC field before the ICC value is calculated. 1937 The length of the authentication tag MUST be 64 bits for FSP version 1938 0 and 1. The authentication tag is stored in the ICC finally. The 1939 inputs to GCM-AES decryption are: 1941 K: the key installed by ULA. 1943 IV: the initial vector, 96-bit string made by concating consisted of 1944 the 32-bit salt, the 32-bit sequence number of the packet and the 32- 1945 bit expected sequence number field of the packet. 1947 C: the ciphertext are the bytes following the fixed header up to the 1948 end of the received payload 1950 AAD: additional authenticated data, from the source ULTID to the last 1951 byte of the fixed header. The source ULTID is stored in the leftmost 1952 32-bit of the ICC field while the destination ULTID is stored in the 1953 rightmost 32-bit of the ICC field before the ICC value is calculated 1955 T: The authentication tag, which is fetched from the ICC field 1956 received 1958 Only when the outputs of GCM-AES decryption tell that the 1959 authentication tag passed verification may the receiver deliver the 1960 decrypted payload to the ULA. 1962 8.1.4 ICC of the Out-of-Band Packet 1964 When calculating the ICC of an out-band packet (KEEP_ALIVE, ACK_FLUSH 1965 or MULTIPLY), the ExpectedSN field SHALL be filled with zero before 1966 GCM-AES is applied to obtain the ICC value. After the ICC field is 1967 set the ExpectiedSN field is set to the serial number of the out-of- 1968 band packet, which is taken as the second salt as well. 1970 When validating the received ICC the second salt value SHALL be 1971 extracted from the ExpectedSN field of the received out-of-band 1972 packet at first. Then the ExpectedSN field of the received MULTIPLY 1973 packet SHALL be set to zero. Finally GCM-AES description is applied 1974 and the ICC value is checked. 1976 To get or check the ICC of the out-of-band packet the original salt 1977 value that is set on deriving the session key and stored in the 1978 internal security context MUST be XORed with the second salt value 1979 before applying GCM-AES. Instantly after GCM-AES is applied the 1980 original salt value MUST be recovered. 1982 8.2. Start a New Transmit Transaction 1984 The responder starts AND terminates a transmit transaction by send 1985 the ACK_CONNECT_REQ packet. 1987 The initiator starts a new transmit transaction by sending a PERSIST 1988 packet: 1990 (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload) 1992 Or starts AND terminates a transmit transaction by send the ACK_START 1993 packet: 1995 (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter]) 1997 8.3. Send a Pure Data Packet 1999 (PURE_DATA, SN, ExpectedSN, ICC, FREWS, Payload) 2001 After a new transmit transaction has been started further PURE_DATA 2002 packet MAY be sent until a packet with EoT flag set is sent. 2004 8.4. Commit a Transmit Transaction 2006 8.4.1. Initiate Transmit Transaction Commitment 2008 A participant of an FSP connection MAY notify its peer that a 2009 transmit transaction shall be committed by setting the EoT flag of 2010 the last packet of the transmit transaction, be it PERSIST, 2011 ACK_START, PURE_DATA or MULTIPLY. 2013 8.4.2. Respond to Transmit Transaction Commitment 2015 (ACK_FLUSH, SN, ExpectedSN, ICC, FREWS) 2017 If and only if all of the packets in a transmit transaction has been 2018 received MAY ACK_FLUSH packet be sent. 2020 Whenever a legitimate packet falls in the receive window of the 2021 receiver, and the packet fills in the last gap of the sequence of 2022 current transmit transaction on receiving direction, or the packet 2023 with same sequence number has been accepted already, a responding 2024 ACK_FLUSH SHALL be sent back immediately, and the FSP layer MUST 2025 immediately notify the ULA that a transmit transaction has been 2026 committed. 2028 The sequence number (SN) of the ACK_FLUSH packet MUST equal the 2029 latest sequence number of the legitimate packets that have been sent. 2031 The out-of-band serial number SHALL increase by one whenever a new 2032 ACK_FLUSH packet is sent. 2034 8.4.3. Finalize Transmit Transaction Commitment 2036 After receiving the ACK_FLUSH packet the sender of the EoT flag 2037 migrates to the COMMITTED or CLOSABLE state from the COMMITTING or 2038 COMMITTING2 state, respectively. 2040 8.4.4. Time-out for Committing Transmit Transaction 2042 The ULA SHALL be timed-out if there is no packet was acknowledged in 2043 some hard-coded time-out. For this version of FSP the time-out is set 2044 to 30 seconds. 2046 8.5. Retransmission 2048 8.5.1. Calculation of RTT 2050 Initial round trip time (RTT) for the Connection Initiator: Equals to 2051 the mean of the time elapsed when ACK_ INIT_CONNECT was received 2052 since INIT_CONNECT was sent, and the time elapsed till 2053 ACK_CONNECT_REQ was received since CONNECT_REQUEST was sent. 2055 Initial RTT for the Connection Responder: Equals to the time elapsed 2056 when the ACK_START or the first PERSIST packet was received since 2057 ACK_CONNECT_REQ was sent. 2059 Initial RTT for the Initiator of Connection Multiplication: Equals to 2060 the time elapsed when the first PERSIST packet was received since 2061 MULTIPLY was sent. 2063 Initial RTT for the Responder of Connection Multiplication: Equals to 2064 the most recent RTT of the multiplied connection. 2066 Each time a SNACK or an accumulated acknowledgment is received the 2067 round trip time of the packet with most expected SN is calculated. 2068 The round trip time is the difference between the time when the 2069 KEEP_ALIVE packet that carried the acknowledgement was received and 2070 the time when the original packet was sent, minus the delay given in 2071 the SNACK optional header of the KEEP_ALIVE packet. Suppose the 2072 result is RTT_now, then: 2074 RTT_new = (RTT_old + RTT_now) / 2 2076 8.5.2. Generation and transmission of SNACK 2078 Whenever the receiver receives a packet it SHALL shift the time to 2079 send next heartbeat signal earlier to the time of RTT since current 2080 time, if the time to send next heartbeat signal used to be later. If 2081 the time is already earlier than the time of RTT since current time, 2082 it needs not be shifted. 2084 On the time to send the heartbeat signal the FSP node generates the 2085 SNACK header, then generate and send a new KEEP_ALIVE or ACK_FLUSH 2086 packet to carry the SNACK header. It SHALL send an ACK_FLUSH if it is 2087 in PEER_COMMIT, COMMITTING2 or CLOSABLE state, otherwise it SHALL 2088 send a KEEP_ALIVE packet. 2090 8.5.3. Negative acknowledgment of Packets Sent 2092 Both the ACK_FLUSH and the KEEP_ALIVE packet in FSP carry the SNACK 2093 extension header, although number of gap descriptors in the SNACK 2094 extension header in the ACK_FLUSH packet MUST be 0. We call them 2095 SNACK packets. A SNACK packet P1 is said to be later than P0, if and 2096 only if SN of P1 is later than SN of P0, or SN of P1 equals SN of P0 2097 while the out-of-band sequence number of P1 is later than the out-of- 2098 band sequence number of P0. If the latest SNACK packet is ACK_FLUSH, 2099 all the packets with the sequence number later that the expected 2100 field of the packet are assumed to be negatively acknowledged. 2102 By convention when we specify the range, the left square bracket 2103 meant to be inclusive, while the right parenthesis meant to be 2104 exclusive, the packets with SN in the ranges: 2105 [expectedSN, expectedSN + 1st Gap Width), 2107 [expectedSN + 1st Gap Width + 1st Data Length, 2108 expectedSN + 1st Gap Width + 1st DataLength + 2nd Gap Width), 2110 ... 2112 [expectedSN + 1st Gap Width + 1st Data Length 2113 + ... + (n-1)th Gap Width + (n-1)th Data Length, 2114 expectedSN + 1st Gap Width + 1st DataLength 2115 + ... + n-th Gap Width), 2117 together with the packets with SN later than {expectedSN + 1st Gap 2118 Width + 1st DataLength + ... + n-th Gap Width} are assumed to be 2119 negatively acknowledged, if the latest SNACK packet is KEEP_ALIVE. 2121 8.5.4. Retransmission Interval 2123 Any packet sent 4 times RTT earlier that is unacknowledged SHALL be 2124 retransmitted as soon as possible. 2126 FSP does not exploit Exponential backoff on setting retransmission 2127 interval. However, retransmission is subjected to send rate control 2128 at the underlying congestion management service sub-layer. 2130 8.6. Flow Control 2132 The participants of an FSP connection negotiate the initial receive 2133 window size with the FREWS field in the ACK_CONNECT_REQUEST packet, 2134 and the first PERSIST or ACK_START packet that acknowledges the 2135 ACK_CONNECT_REQUEST packet, respectively. The receive window size 2136 SHALL NOT be less than 4 and SHALL be less than 2^24. 2138 An FSP participant advertises current receive window size in the 2139 FREWS field. 2141 An FSP participant SHALL NOT send a packet whose sequence number is 2142 later than the value of the ExpectedSN field plus the advertised 2143 receive window size, where both value come from the very packet 2144 received with the latest sequence number. 2146 8.7. Congestion Control 2148 FSP supposes that end-to-end congestion control is provided by some 2149 shim layer, such as the congestion manager [RFC3124] between the 2150 "traditional" IP layer and the FSP transport layer. The shim layer is 2151 considered as a sub-layer of the network layer. Implementation of FSP 2152 MUST provide such shim layer if the network layer of the end node 2153 does not provide end-to-end congestion management service. 2155 FSP layer SHALL provide following information to the congestion 2156 manager as soon as the first packet on the fly was acknowledged by 2157 any mean, or a legitimate packet falling in the receive window with 2158 the ECE flag set is received: 2160 - The local interface number that the packet carrying the ECE signal 2161 is accepted. 2163 - The remote network prefix that the congestion information is meant 2164 to associate. Note that the aggregated host ID part is NOT included 2165 in the prefix. 2167 - The traffic class. For FSP it is bisected: MIND flag set or not. 2169 - Number of outstanding octets, including all of those in the payload 2170 AND the FSP headers. 2172 - The effective round trip time calculated in the most recent period. 2173 Note that retransmitted packets MUST be excluded on calculating the 2174 effective RTT. 2176 - Whether an ECN-Echo signal was received. The ECE flag of a 2177 legitimate packet falling in the receive window is the ECN-Echo 2178 signal. 2180 - Whether a sent packet with SRR flag set is acknowledged. 2182 The congestion manager SHOULD reduce the send rate if the FSP sender 2183 informed it that an ECN-Echo signal was received. 2185 The sender SHALL NOT inform the congestion manager to reduce the send 2186 rate again even if further packet with ECE flag set is received, 2187 until at least one sent packet with SRR flag set is acknowledged. 2189 A packet with ECE flag set received after the packet with SRR flag 2190 set is acknowledged SHOULD make the congestion manager reduce the 2191 send rate again. 2193 Retransmitted packet SHALL be subjected to send rate control at the 2194 underlying congestion management service sub-layer as well. 2196 Quota or other means to enforce fairness among various FSP 2197 connections SHOULD be provided directly to the ULA by the congestion 2198 management service. 2200 Requirement of an FSP congestion manager would be detailed in a 2201 separate document. 2203 8.8. On-the-Wire Compression 2205 FSP exploits the lossless compression algorithm as per [LZ4]. 2207 If the CPR flag of the first packet of a transmit transaction is set, 2208 compression is applied on the payload octet stream of the transaction 2209 transaction. 2211 When applying compression FSP divides source stream into multiple 2212 blocks. For this version of FSP length of each block is 128KiB 2213 (131072 octets), except the final block whose length may be less than 2214 or equal to 128KiB. The final block is the one that terminate the 2215 transmit transaction, i.e. which contains the last FSP packet of the 2216 transmit transaction. The last FSP packet of the transmit transaction 2217 has the EoT flag set. The "LZ4_compress_fast_continue" method SHALL 2218 be applied on each block. That is, data from previous compressed 2219 blocks are taken use for better compression ratio. 2221 When transferring the result data of compressing each block, the 2222 result data is prefixed with its length. The length is expressed by a 2223 4-octets little-endian integer. 2225 On-the-wire compression of each transmit transactions is independent. 2226 It is the upper layer application that SHALL make agreement on which 2227 transmit transaction utilizes on-the-wire compression. 2229 8.9. Milk Like Payload and Minimal Delay Service 2231 An ordinary data flow is wine-like in the sense that the older data 2232 are more valuable. If it has to, data packet sent latest are dropped 2233 first. In the contrary, milk-like payload is that the newer data are 2234 more precious and outdated data packet can be discarded. 2236 When ULA is willing to accept incomplete message the peer of the 2237 underling FSP node SHALL set the MIND flag of the first PERSIST 2238 packet that starts the first transmit transaction, and set the MIND 2239 flag of every following PURE_DATA packet, while set the Traffic Class 2240 of the underlying IPv6 packet to some registered value. 2242 In the transmission path, any relaying middle box, be it router or 2243 switch, should reserve a reasonably short queue for the packet flow 2244 of such flow to minimize delay. 2246 When the receive buffer overflows the receiver discards the 2247 undelivered packet received first to free buffer space for the latest 2248 packet received. However it keeps order on delivering the packets to 2249 he ULA. ULA may choose to discard packets received earlier than some 2250 threshold. 2252 The receiver SHOULD NOT make any acknowledgement to the packet 2253 received with the MIND flag set. 2255 Minimal delay service is asymmetric in the sense that one 2256 transmission direction the data flow may be milk-like while in the 2257 reverse direction the data flow may be wine-like. 2259 A minimal delay service data flow is terminated by ULA via some out- 2260 of-band control mechanism. 2262 9. Graceful Shutdown 2264 One participant of an FSP connection MAY initiate graceful shutdown 2265 of the connection if and only if its peer has committed the most 2266 recent transmit transaction. 2268 By initiating graceful shutdown the participant tells its peer that 2269 current transmit transaction is to be committed as well. 2271 9.1. Initiation of Graceful Shutdown 2273 (RELEASE, SN, ExpectedSN, ICC, FREWS) 2275 An FSP end node MAY initiate graceful shutdown if it is in the 2276 PEER_COMMIT, COMMITTING2 or CLOSABLE state. It SHALL NOT initiate 2277 graceful shutdown if its peer has not committed current transmit 2278 transaction. 2280 Graceful shutdown is signaled to the remote end by sending a RELEASE 2281 command packet. The FSP end node SHALL migrate to the PRE_CLOSED 2282 state just before sending the RELEASE packet. 2284 9.2. Acknowledgment of Graceful Shutdown 2286 The RELEASE packet may be accepted in the COMMITTING, COMMITTED, 2287 COMMITTING2, CLOSABLE or PRE_CLOSED state. 2289 If the legitimate RELEASE packet is received in the COMMITTING or 2290 COMMITTED state, the FSP end node SHALL buffer the RELEASE packet, 2291 wait each packet of the last transmit transaction of its peer has 2292 been received, deliver all the buffered payload and then migrate to 2293 the CLOSED state. 2295 If the legitimate RELEASE packet is received in the COMMITTING2 or 2296 CLOSABLE state, the FSP end node SHALL migrate to the CLOSED state 2297 immediately. 2299 In either of the two cases the receiver of the RELEASE packet SHALL 2300 acknowledge the sender of the RELEASE packet with a legitimate out- 2301 of-band ACK_FLUSH packet. 2303 If the RELEASE packet is received in the PRE_CLOSED state, it is to 2304 finalize the graceful shutdown procedure. 2306 9.3. Finalization of Graceful Shutdown 2308 If either the legitimate RELEASE packet or the legitimate ACK_FLUSH 2309 packet is received in the PRE_CLOSED state the grace shutdown request 2310 is supposed to be acknowledged and the shutdown procedure SHALL be 2311 finalized by that the FSP end node migrates to the CLOSED state 2312 immediately. 2314 Graceful shutdown in FSP is asymmetric in the sense that it does not 2315 require both ULA participants to call the Shutdown API. 2317 9.4. Retransmission of RELEASE Packet 2319 The FSP end node in the PRE_CLOSED state SHALL retransmit the RELEASE 2320 packet until it migrates to CLOSED state or it is timed out. Interval 2321 between the retransmission is hard-coded to 4 times of RTT. 2323 The RELEASE packet that was sent in the COMMITTING2 or CLOSABLE state 2324 state shall never be retransmitted. 2326 10 Mobility and Multi-home Support 2328 10.1. Heartbeat Signals 2329 FSP requires that the participants periodically send the heartbeat 2330 signals. 2332 The participant in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2333 COMMITING2 or CLOSABLE state MUST send the KEEP_ ALIVE packet as the 2334 heart-beat signal periodically to retain the connection in case that 2335 underlying IP address has changed. 2337 (KEEP_ALIVE, SN, ExpectedSN, ICC, FREWS, Sink Parameter, SNACK) 2339 Heartbeat signal is an out-of-band control packet. It does not carry 2340 payload. The sequence number of the KEEP_ALIVE packet SHALL be set to 2341 the latest sequence number of all of the packets that have been sent. 2343 Only the FSP node in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2344 COMMITING2 or CLOSABLE state MAY process the heartbeat signal. 2346 In this version of FSP the heat-beat period is arbitrarily set to 600 2347 seconds. 2349 The sequence number (SN) of the KEEP_ALIVE packet MUST equal the 2350 latest sequence number of the legitimate packets that have been sent. 2352 The out-of-band serial number SHALL increase by one whenever a new 2353 KEEP_ALIVE packet is sent. 2355 10.2. Active Address Change Signaling 2357 During communication process the FSP participant whose underlying IP 2358 address is changed SHOULD inform its peer such change by transmit a 2359 KEEP_ALIVE packet with the Sink Parameter extension header and the 2360 SNACK header so that the peer can retransmit the packets that were 2361 negatively acknowledged. 2363 Such informing KEEP_ALIVE packet SHALL be sent in the ACTIVE, 2364 COMMITTING, COMMITTED, PEER_COMMIT, COMMITING2 or CLOSABLE state. 2366 Informing KEEP_ALIVE packet SHOULD be sent more frequently than a 2367 normal heart-beat signaling KEEP_ALIVE packet. 2369 For this version of FSP informing KEEP_ALIVE packet SHALL be 2370 retransmitted every 4 RTT interval until the heuristic 2371 acknowledgement is received. 2373 10.3. Heuristic Remote Address Change Adaptation 2375 A participant of the FSP connection SHALL set the source address of 2376 the packet to transmit or retransmit to new IP address as soon as the 2377 near-end IPv4 address or IPv6 network prefix has changed. The ULTID 2378 field MUST remain the same. 2380 When a new packet with a later sequence number is received and the 2381 source IP address of the packet is found to be different with the 2382 preserved IP address of the remote end, the receiver SHOULD 2383 automatically update the preserved IP address of the remote end to 2384 the source IP address of the new packet, unless there is a Sink 2385 Parameter header in the packet. 2387 If the sequence number of the packet received is not the latest in 2388 the receive window the preserved IP address of the remote end SHALL 2389 NOT be updated even if the source address of the received packet has 2390 changed. 2392 10.4. Heuristic Address Change Acknowledgement 2394 The address change signaling KEEP_ALIVE packet is supposed to be 2395 acknowledged if a packet targeted at the new IP address that the 2396 KEEP_ALIVE packet has informed is received. 2398 10.5. NAT-traversal and Multihoming 2400 When FSP is implemented over UDP in the IPv4 network, each endpoint 2401 of the FSP connection is bound one and only one IPv4 address as soon 2402 as the connection is established. Each endpoint SHALL choose the 2403 source IPv4 address of the last packet received as the destination 2404 IPv4 address of the packet that it is to send later. By this mean FSP 2405 over UDP is NAT-friendly. 2407 When FSP is implemented over IPv6 as soon as the connection is 2408 established the IPv6 address may be changed dynamically, and one more 2409 alternate IP address may be added or removed dynamically for 2410 individual endpoint as well, provided that ULTID part keeps unchanged 2411 while the host IDs part of all IPv6 address of the endpoint are of 2412 the same value at any given moment. 2414 The sender may choose as the source IP address by selecting any 2415 network prefix that it has most-recently sent to its peer in the 2416 allowed address list field of the Sink Parameter header, joining with 2417 the host ID in the Sink Parameter header and the stable ULTID of the 2418 sender, and choose as the destination IP address by selecting any 2419 network prefix in the allowed address list field of the Sink 2420 Parameter header most-recently received from its peer, joining with 2421 the peer's host ID and the peer's ULTID. Thus multiple multi-homed 2422 paths MAY co-exist between the two FSP endpoints. 2424 10.6. Explicit Multi-home Informing 2425 If an FSP end node is configured with multiple IPv4 address other 2426 than the loop-back address, or with multiply global unicast IPv6 2427 address, it MAY advertise multiple underlying addresses to the remote 2428 end by put them in the addressable network prefix list of the Sink 2429 Parameter extension header. The Sink Parameter extension header may 2430 be carried in the CONNECT_REQUEST, ACK_CONNECT_REQ, NULCOMMIT, 2431 MULTIPLY or KEEP_ALIVE packet. 2433 Any participant of the communication SHALL NOT make discrimination of 2434 the source or destination IP address of any packet provided that both 2435 the source ULTID and the destination ULTID keep unchanged and the ICC 2436 field passes verification. 2438 11 Connection Multiplication 2440 Connection multiplication is the process of incarnating a new 2441 connection context by re-using security context of an established 2442 connection. 2444 11.1. Request to Multiply Connection 2446 (MULTIPLY, SN, Salt, ICC, FREWS [, Sink Parameter] [, payload]) 2448 The initiator's initial sequence number of the new connection is the 2449 sequence number of the packet that piggybacks the connection 2450 multiplication header. The ExpectedSN field of the normal packet 2451 store a Salt value instead. 2453 The FREWS field MUST be processed in the new connection context while 2454 the ICC MUST be calculated with the session key of the original 2455 connection. 2457 The new connection inherits the remaining key life. ULA SHOULD 2458 negotiate new session key and/or install new session key as soon as 2459 possible. 2461 The optional payload of the MULTIPLY packet MUST be processed in the 2462 new connection context. 2464 The MULTIPLY packet is an out-of-band command packet in the original 2465 connection context. 2467 11.2. Response to Connection Multiplication Request 2469 Case 1: (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter]) 2471 Case 2: (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload) 2472 Case 3: (RESET, SN, ExpectedSN, ICC, FREWS, Reason of Failure) 2474 In all of these cases the ULTID of the remote-end MUST be the value 2475 of the initiator's ULTID in the connection multiplication header. 2477 It is REQUIRED that only a connection in the ESTABLISHED, COMMITTING, 2478 COMMITTED, PEER_COMMIT, COMMITTING2 or CLOSABLE state may accept a 2479 connection multiplication request. 2481 In case 1 the responder admits the multiplication request AND commit 2482 the transmit transaction, the new connection enters into the 2483 PEER_COMMIT or CLOSABLE state immediately, on request of ULA. 2485 In case 2 the responder admits the multiplication request and the new 2486 connection enters into the ESTABLISHED, PEER_COMMIT, or COMMITTING or 2487 CLOSABLE state immediately, depending whether the ULA of the 2488 multiplication initiator has requested to commit the transmit 2489 transaction immediately and whether the ULA of the multiplication 2490 responder has requested to commit the transmit transaction in the 2491 reverse direction immediately. 2493 In case 3 the responder rejects the multiplication request. To defend 2494 against spoofing attack ICC MUST be valid. The value of the SN field 2495 MUST equal the value of the 'Expected SN' field of the requesting 2496 MULTIPLY packet while the value of ExpectedSN field MUST equal the 2497 value of the 'Sequence No' field. 2499 The new connection MUST derive new session key from the session key 2500 of the original connection where the out-of-band requesting MULTIPLY 2501 packet is received immediately. 2503 11.3. Duplicate Detection of Connection Multiplication Request 2505 Every time the responder of connection multiplication receives a 2506 MULTIPLY packet it MUST check the suggested responder's ULTID and the 2507 initiator's ULTID. 2509 The responder MUST reject the multiplication request if the suggested 2510 responder's ULTID equals the near-end ULTID of some connection and 2511 the remote-end ULTID of that connection does not equal the 2512 initiator's ULTID. 2514 The responder MUST recognize the MULTIPLY packet as a duplicate 2515 connection request if some connection matches the request and SHOULD 2516 response by retransmitting the head packet of the send queue of the 2517 matching connection, be it a PERSIST or an COMMIT packet. A 2518 connection matches the MULTIPLY request if and only if the suggested 2519 responder's ULTID in the MULTIPLY packet equals the near-end ULTID of 2520 the connection and the initiator's ULTID equals the remote-end ULTID 2521 of the connection. 2523 11.4. Retransmission 2525 The initiating side SHALL retransmit the MULTIPLY packet if the 2526 corresponding PERSIST packet is not received in some limit time (by 2527 default 15 seconds). 2529 11.5. Key Derivation for Branch Connection 2531 Let K_out = BLAKE2(Km, [d] || Label || 0x00 || Context || L), where: 2533 - Km 2534 is the master key, 2536 - [d] 2537 is one octet of integer Depth. It is alike the KDF counter mode 2538 as the NIST SP800-108. For this version of FSP it is the fixed 2539 number 1, 2541 - Label 2542 is the fixed ASCII string "Multiply an FSP connection" which is 2543 26-octet long for this version of FSP, 2545 - Context 2546 is concatenation of two 32-bit words idB and idR 2548 idB is the ULTID allocated for the branch connection in the 2549 context of the multiplication initiator. idB is byte-order 2550 neutral. 2552 idR is the receiver side ULTID of the original connection that is 2553 to accept the connection multiplication request. idI or idR is 2554 byte-order neutral. 2556 - L 2557 is a 32-bit network byte-order integer specifying the length in 2558 bits of the derived key K-out 2560 12 Timeouts and Abrupt Close 2562 12.1. Timeouts in End-to-End Negotiation 2564 Initially the initiator is in the CONNECT_BOOTSTRAP state. It 2565 migrates to the CONNECT_ AFFIRMING state after it received the 2566 legitimate ACK_INIT_CONNECT packet. Then it migrates to the 2567 PEER_COMMIT or CLOSABLE state after it received the legitimate 2568 ACK_CONNECT _REQ packet, depending on the hint of ULA. 2570 The responder incarnates a new connection context which is initially 2571 in the CHALLENGING state after accepting a legitimate Connect Request 2572 packet. Then it migrates to the COMMITTING or CLOSABLE state, 2573 depending on the packet received from its peer. 2575 If the initiator or the responder is unable to migrate to a new state 2576 in some limit time (by default 60 seconds, except in LISTENING state) 2577 it aborts the connection by recycling the connection context. 2579 12.2. Timeouts in Multiply 2581 Initially the initiating side of Connection Multiplication is in the 2582 CLONING state. It migrates to the ACTIVE, COMMITTED, PEER_COMMIT or 2583 CLOSABLE state after it received the legitimate PERSIST packet. Which 2584 state to migrated depends on the EoT flag of the initiating MULTIPLY 2585 packet and the responding PERSIST packet. 2587 If the initiating side is unable to migrate to a new state in some 2588 limit time (by default 60 seconds) it aborts multiplication by 2589 recycling the new connection context. 2591 12.3. Timeout of Transmit Transaction Commitment 2593 The FSP node MUST abort the connection if the time of no packet 2594 having arrived has exceed certain limit in the COMMITTING or 2595 COMMITTING2 state. 2597 In this FSP version, timeout of transmit transaction commitment is 2598 set to 5 minutes. 2600 12.4. Timeout of Graceful Shutdown 2602 It simply migrates to the NON_EXISTENT pseudo-state if timeout in the 2603 PRE_CLOSED state. 2605 In this FSP version, timeout of Graceful Shutdown is set to 1 minute. 2607 12.5. Idle Timeout 2609 If one participant has not received any packet nor has it sent any 2610 packet in some limit time, it MUST be abruptly closed. 2612 In this FSP version the time limit, or the idle timeout, is set to 4 2613 hours. 2615 12.6. Session Key Timeout 2616 For this FSP version if a secret key is applied for more than 2^30 2617 times the FSP node MUST abruptly closed instantly. 2619 12.7. Abrupt Close 2621 An FSP node abruptly shutdown a session by sending a RESET packet and 2622 release all of the resource occupied by the the session immediately. 2624 (RESET, SN, ExpectedSN, ICC, Reason of Failure) 2626 13 Issues for Further Study 2628 13.1. Resolution of ULTID in DNS 2630 There are two patterns of IP address resolution in FSP: the DNS- 2631 compatible pattern and the proxy pattern. The former pattern relies 2632 on some name service to resolve the IP address of the responder for 2633 the initiator before they exchange end-to-end negotiation packets. 2635 In the DNS-compatible pattern, the responder side of the FSP 2636 participants registered its address identifier, such as 'domain name' 2637 in some name service such as DNS [RFC1034][RFC1035], according to 2638 some pre-agreement at first. The initiator resolves the current IP 2639 address of the responder by consulting the name service, such as 2640 looking after the A or AAAA record [RFC3596] of the domain name in 2641 DNS. 2643 If UDP over IPv4 is exploited as the under layer data packet delivery 2644 service the port number of the responder is firstly resolved just 2645 alike normal network application such as HTTP. Then it is extended to 2646 32-bit ULTID, and ULTIDs of FSP can be considered as the superset of 2647 TCP port numbers. 2649 If the string representation of IPv4/IPv6 address is applied directly 2650 as the peer's address identifier instead of the domain name there is 2651 no need for some real address resolution. But from the API caller's 2652 point of view it is a DNS-compatible mode address resolution. 2654 13.2. Proxy Pattern for Syndicated Name Resolution 2656 The proxy pattern of IP address resolution in FSP is to embed the 2657 address resolution information in the connection initialization 2658 packets and is designed to work in FSP over IPv6 mode only. 2660 In IPv6 network the rightmost 32 bits of the IPv6 address directly 2661 maps to the ULTID so FSP does not need additional multiplexing 2662 mechanism such as port number. And it needs not consult SRV record or 2663 look for some entry in some 'services' file. 2665 If the INIT_CONNECT packet carries the responder's host name it MUST 2666 take the link-local interface address as the source IPv6 address and 2667 the default link-local gateway address, FE80::1, as the destination 2668 IPv6 address no matter whether the global unicast IP address of the 2669 default gateway is configured. In such scenario the link-local 2670 gateway MUST be able to resolute the responder's host name to its 2671 global unicast IPv6 address, and the gateway MUST be able to map the 2672 initiator's link local address to its global unicast IPv6 address. 2674 If the gateway that relays the INIT_CONNECT packet finds that the 2675 responder is on the same link-local network with the initiator it 2676 SHALL change the source and the destination IP addresses of the 2677 INIT_CONNECT packet to the link-local IP addresses of the initiator 2678 and the responder respectively, and relay the packet onto the same 2679 link-local network. 2681 On receiving the INIT_CONNECT packet that carries the responder's 2682 host name the link-local gateway MUST resolute the responder's global 2683 unicast IPv6 address and map the initiator's global unicast IPv6 2684 address, and replace the destination and source address of the 2685 INIT_CONNECT packet respectively, unless it finds that the initiator 2686 and the responder are on the same link-local network, where the 2687 gateway SHALL process the packet as stated in the previous statement. 2689 13.3. Asymmetric Transmission 2691 If there is one participant whose receive interface is not the same 2692 as the send interface the participant is called an asymmetric- 2693 transmissioned node. 2695 Asymmetric transmission itself is asymmetric in the sense that one 2696 participant may be asymmetric-transmissioned node while its peer is a 2697 normal node that the send interface is the same receive interface. 2699 An end node is asymmetric-transmissioned if it received an 2700 ACK_CONNECT_REQ packet, NULCOMMIT or PERSIST packet whose source IP 2701 address that the network interface accepting the packets reported is 2702 not in the allowed IP address list in the Sink Parameter header of 2703 the packet. 2705 For an asymmetric-transmissioned remote end, the near end cannot rely 2706 on automatic IP address change detection. Instead IP address change 2707 notification mechanism shall be utilized. 2709 However for this version of FSP asymmetric transmission support is 2710 optional. 2712 14 Security Considerations 2714 14.1. Deny of Service Attack 2716 FSP is designed to mitigate effect of DoS attack by exploiting Cookie 2717 . 2719 However, resistance against distributed DoS attack relies on external 2720 mechanism such as Distributed-Denial-of-Service Open Threat Signaling 2721 [DOTS]. 2723 14.2. Replay Attack 2725 In-band sequence number and out-of-band sequence number are exploited 2726 to resist against replay attack. 2728 14.3. Passive Attacks 2730 AEAD MAY be exploited by the ULA to protect it against passive 2731 attacks such as eavesdropping, gaining advantage by analyzing the 2732 data sent. 2734 MAC only service MAY also be utilized. Together with application 2735 layer stream-mode encryption it protects the ULA against passive 2736 attacks as well. 2738 14.4. Masquerade Attack 2740 Both AEAD and MAC only service may be exploited to protect the 2741 endpoints against masquerade attack. 2743 If proxy pattern for syndicated name resolution is exploited for FSP 2744 over IPv6, secure neighbor discovery [RFC3971] SHOULD be applied 2745 instead of common neighbor discovery whenever it is feasible. 2747 14.5. Active Man-In-The-Middle Attack 2749 The ULA SHALL take account to protect itself against MITM attack when 2750 making client authentication and key establishment. 2752 14.6. Privacy Concerns 2754 It is beneficial for privacy protection that the ULTID of each 2755 endpoints of an FSP connection is generated randomly [RFC7721]. 2757 15 IANA Considerations 2759 It should be requested that the port number registered for UDP 2760 packets encapsulating FSP in the IPv4 network. The port number 18003 2761 is exploited in the concept prototype implementation. The number is 2762 the decimal presentation of ASCII codes of the character 'F' ('x46') 2763 and 'S' ('x53') concatenated in network byte order. 2765 It should be requested that the 'Next Header'/protocol number is 2766 assigned for FSP over IPv6. Decimal number 144 is exploited in the 2767 concept prototype implementation. 2769 16 References 2771 16.1. Normative References 2773 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 2774 2776 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 2777 Cartridges - DLT1 Format Standard, Annex B", ECMA-182, 2778 December 1992. 2780 [LZ4] https://lz4.github.io/lz4/ 2782 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 2783 Galois/Counter Mode (GCM) and GMAC", November 2007. 2784 2786 [OSI/RM] ISO and IEC, "Information technology-Open Systems 2787 Interconnection - Basic Reference Model: The Basic Model", 2788 ISO/IEC 7498-1 Second edition, November 1994. 2789 2791 [R01] Rogaway, P., "Authenticated encryption with Associated- 2792 Data", ACM Conference on Computer and Communication 2793 Security (CCS'02), pp. 98-107, ACM Press, 2002. 2795 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2796 Communication Layers", STD 3, RFC 1122, DOI 2797 10.17487/RFC1122, October 1989, . 2800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2801 Requirement Levels", BCP 14, RFC 2119, DOI 2802 10.17487/RFC2119, March 1997, . 2805 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 2806 RFC 3124, DOI 10.17487/RFC3124, June 2001, 2807 . 2809 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2810 of Explicit Congestion Notification (ECN) to IP", 2811 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2812 . 2814 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2815 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2816 2003, . 2818 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2819 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2820 2006, . 2822 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2823 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2824 December 2005, . 2826 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2827 Key Derivation Function (HKDF)", RFC 5869, DOI 2828 10.17487/RFC5869, May 2010, . 2831 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2832 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 2833 10.17487/RFC6887, April 2013, . 2836 [RFC7693] Saarinen, M-J., Ed., and J-P. Aumasson, "The BLAKE2 2837 Cryptographic Hash and Message Authentication Code (MAC)", 2838 RFC 7693, DOI 10.17487/RFC7693, November 2015, 2839 . 2841 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2842 (IPv6) Specification", STD 86, RFC 8200, DOI 2843 10.17487/RFC8200, July 2017, . 2846 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 2847 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 2848 . 2850 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2851 1981. 2853 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2854 August 1980. 2856 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 2857 793, September 1981. 2859 16.2. Informative References 2861 [DOTS] Mortensen, A., Andreasen, F., Reddy, T., Gray, C., Compton 2862 R., and N. Teague, "Distributed-Denial-of-Service Open 2863 Threat Signaling (DOTS) Architecture", March 2018, 2864 2867 [Gao2002] Gao, J., "Fuzzy-layering and its suggestion", IETF Mail 2868 Archive, September 2002, 2869 https://mailarchive.ietf.org/arch/msg/ietf/u-6i-6f- 2870 Etuvh80-SUuRbSCDTwg 2872 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2873 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2874 . 2876 [RFC1035] Mockapetris, P., "Domain names - implementation and 2877 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2878 November 1987, . 2880 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2881 Address Translator (Traditional NAT)", RFC 3022, DOI 2882 10.17487/RFC3022, January 2001, . 2885 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2886 C., and M. Carney, "Dynamic Host Configuration Protocol 2887 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2888 2003, . 2890 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2891 "DNS Extensions to Support IP Version 6", STD 88, 2892 RFC 3596, DOI 10.17487/RFC3596, October 2003, 2893 . 2895 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2896 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2897 DOI 10.17487/RFC3633, December 2003, . 2900 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2901 "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 2902 10.17487/RFC3971, March 2005, . 2905 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2906 "Randomness Requirements for Security", BCP 106, RFC 4086, 2907 DOI 10.17487/RFC4086, June 2005, . 2910 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2911 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2912 RFC 4106, DOI 10.17487/RFC4106, June 2005, 2913 . 2915 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2916 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 2917 . 2919 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2920 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2921 DOI 10.17487/RFC4861, September 2007, . 2924 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2925 Address Autoconfiguration", RFC 4862, DOI 2926 10.17487/RFC4862, September 2007, . 2929 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 2930 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 2931 . 2933 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2934 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2935 . 2937 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 2938 Model: The Relationship between Links and Subnet 2939 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 2940 . 2942 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 2943 Detecting Network Attachment in IPv6", RFC 6059, DOI 2944 10.17487/RFC6059, November 2010, . 2947 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 2948 Assignment to End Sites", BCP 157, RFC 6177, DOI 2949 10.17487/RFC6177, March 2011, . 2952 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2953 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2954 2011, . 2956 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2957 the IPv6 Prefix Used for IPv6 Address Synthesis", 2958 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2959 . 2961 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 2962 and D. Wing, "IPv6 Multihoming without Network Address 2963 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 2964 . 2966 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2967 Scheffenegger, Ed., "TCP Extensions for High Performance", 2968 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2969 . 2971 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 2972 Length Recommendation for Forwarding", BCP 198, RFC 7608, 2973 DOI 10.17487/RFC7608, July 2015, . 2976 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2977 Considerations for IPv6 Address Generation Mechanisms", 2978 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2979 . 2981 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 2982 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 2983 . 2985 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2986 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2987 March 2017, . 2989 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2990 Writing an IANA Considerations Section in RFCs", BCP 26, 2991 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2992 . 2994 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 2995 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 2996 May 2017, . 2998 [tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D. 2999 Boneh, "The case for ubiquitous transport-level 3000 encryption", USENIX Security , 2010. 3002 17 Acknowledgements 3004 Authors' Addresses 3006 Jun'an Gao 3007 Beijing Static Traffic Investment and Operation Co.,Ltd. 3008 Shouke Plaza-A, Liuliqiao South, Fengtai 3009 Beijing 3010 People's Republic of China 3012 EMail: jagao@outlook.com