idnits 2.17.1 draft-gao-flexible-session-protocol-08.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1015 has weird spacing: '... octet maj...' -- The document date (April 18, 2022) is 729 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 ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. 'STD7') (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gao 3 Internet-Draft Individual 4 Intended status: Experimental April 18, 2022 5 Expires: October 20, 2022 7 Flexible Session Protocol 8 draft-gao-flexible-session-protocol-08 10 Abstract 12 FSP is a connection-oriented transport layer protocol that provides 13 mobility and multihoming support by introducing the concept of 'upper 14 layer thread ID', which is associated with some shared secret that is 15 applied with some secure hash or authenticated encryption algorithm 16 to protect authenticity of the origin of the FSP packets. It is able 17 to provide following services to the upper layer application: 19 o Stream-oriented send-receive with native message boundary 20 o Flexibility to exploit authenticated encryption 21 o On-the-wire compression 22 o Light-weight session management 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 20, 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 The dominating transport layer protocols, TCP and UDP that take use 59 of the IP address to identifying the end node, introduce the 60 controversial role of IP address both as the identifier and as the 61 routing locater. 63 Flexible Session Protocol, introduces the concept of 'upper layer 64 thread ID' (ULTID), which was firstly suggested in [Gao2002]. The 65 ULTID is unique in the local context of the FSP node. Its 66 significance may be compared with the Security Parameter Index (SPI) 67 in MOBIKE [RFC4555]. 69 An integrity check code (ICC) field is designed in the FSP packet 70 header to protect authenticity and optionally privacy of the FSP 71 packet. The ICC field is designed to be associated with some shared 72 secret indexed by the source or destination ULTID in the local 73 context of the source or destination node, respectively. An FSP 74 packet is assumed to originate from the same source if the ICC value 75 associated the ULTID passes validation, regardless of the full source 76 or destination address. In such a way FSP provides provides 77 mobility, multi-homing and multi-path support. 79 ICC is either calculated by [CRC64] which protects FSP against 80 unintended modification, or a cryptographic hash function, or 81 cryptographically calculated with some Authenticated Encryption with 82 Additional Data [R01] algorithm, each of which requires a shared 83 secret key. 85 In the former case a weak key meant to obfuscate the CRC64 checksum 86 is agreed by the FSP participants. In the latter two cases, the 87 shared secret key is assumed to be installed by the upper layer 88 application (ULA). 90 Either the weak key or the shared secret key is indexed by the source 91 or destination ULTID in the local context of the sender or the 92 receiver, respectively. 94 FSP facilitates secret key installation by introducing the concept of 95 transmit transaction. Mechanism of transmit transaction also 96 provides the session-connection synchronization service to the upper 97 layer. 99 FSP is a transport layer protocol as specified in [RFC1122], provides 100 services alike TCP [STD5] to ULA, with session layer features as 101 suggested in [OSI_RM], most noticeably session-connection 102 synchronization by introducing the concept of transmit transaction. 104 1.1. Features 106 1.1.1. Transport Layer Mobility Support 108 FSP is meant to be transport layer protocol that keeps the IP address 109 as the routing locater but keeps it from being the key constituent of 110 the end point identifier of FSP or any upper layer protocol built 111 upon FSP. 113 1.1.2. Flexibility to exploit Authenticated Encryption 115 By optionally applying authenticated encryption with additional data 116 on each FSP packet, FSP provides both authentication of message 117 origin and privacy protection service to the upper layer application. 119 The shared key required by the authenticated encryption algorithm is 120 supposed to be established and installed onto the FSP layer by the 121 upper layer application (ULA), and by introducing the concept of 122 transmit tranaction FSP provides mechanism for the connected ULAs to 123 synchronize installation of the shared key. Thus FSP makes it 124 flexible to test, try or apply new key establish algorithms. 126 1.1.3. Transmit Transaction 128 FSP introduces the concept of transmit transaction, which makes it 129 able to mark end of message inherently at the transport layer, 130 effectively eliminate the requirement of message delimiters at the 131 application layer. Besides, it still provides byte-stream-oriented 132 transfer service to its upper layer application which is familiar and 133 friendly to application developers. 135 1.1.4. Light-weight session management 137 In addition to transmit transaction mechanism, which is arguably a 138 feature of session-connection synchronization, the FSP upper layer 139 application is able to fork branch connections of an established 140 connection in zero round-trip mode without compromising security. In 141 this way FSP provides light-weight session management service to ULA. 143 1.1.5. On-the-wire Compression 145 FSP provides on-the-wire compression service through the on-the-wire 146 compression and fragmentation function module. 148 1.2. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 In this document, these words will appear with that interpretation 155 only when in ALL CAPS. Lower case uses of these words are not to be 156 interpreted as carrying significance described in RFC 2119. 158 1.3. Conventions 160 Conventions in describing the finite state machine (FSM) of FSP are: 162 ESTABLISHED The string of alphabetic characters designates 163 the name of the state 164 [API: Reset] Upper Layer Application Programming Interface 165 Call 166 {Notify} Call back/notify the upper layer application 167 {new context} Additional action before or after state 168 transition 169 [Send Send some FSP packet 170 OPCODE_OF_FSP_PACKET] 171 [Retransmit Retransmit some FSP packet 172 OPCODE_OF_FSP_PACKET] 173 {On transient state Timed-out event 174 Timeout} 175 {&& additional Together with some additional condition 176 condition} 177 --> state transition 178 |-- branch 180 2. Abbreviations and Idioms 182 o Connection An FSP connection is the binding of two network nodes 183 established through some end-to-end negotiation process. It is 184 identified by the ULTID in the local context of each network node, 185 respectively. 187 o EoT End of Transaction. A transmit transaction is said to reach 188 EoT if the EoT flag is set in a legitimate PURE_DATA, PERSIST, 189 NULCOMMIT or MULTIPLY packet. We said that the packet terminates 190 the transmit transaction if the EoT flag is set. An FSP end node 191 SHALL NOT send further data if it has initiated EoT of its 192 transmit direction unless a particular ACK_FLUSH packet is 193 received. The particular ACK_FLUSH packet MUST acknowledge not 194 only the packet with the EoT flag set but all of the packets sent 195 before the packet as well. EoT, i.e. termination of transmit 196 transaction is unilateral. 198 o FREWS 200 o The Flags and advertised REceive Window Size. It is the 32-bit 201 combined word next to the ICC field in the normal FSP fixed 202 header. 204 o ICC The Identity Check Code. It is a 64-bit value that depends on 205 both the session key and all of the headers of the FSP packet to 206 include the ICC, calculated with the same algorithm in the context 207 of each FSP participant. Only a packet with correct ICC can be 208 accepted by any FSP participant as soon as the connection has been 209 established. Initially CRC64 is exploited to make a checksum that 210 weekly protects the FSP packet against unintentional modification. 211 The checksum is obfuscated with the initial session key to get the 212 ICC. After the ULA installed the long-term session key either 213 some cryptographic hash function or some Authenticated Encryption 214 with Additional Data algorithm shall be applied to obtain or check 215 the ICC. 217 o Session An FSP session is the transport-layer association of two 218 network nodes. A full FSP session consists of one connection that 219 was established from scratch and all of its branches. However for 220 this version of FSP specification the idioms session and 221 connection are interchangeable if not explicitly specified. 223 o Session Key The session key is a bit string of at least 128 bits 224 that means to resist against masquerade attack. It is either 225 initiated during the end-to-end negotiation phase or installed by 226 the ULA after the FSP connection is established. The session key 227 installed by the ULA is called the long-term session key. Here 228 long-term means that the key could be used until the packet 229 sequence space is exhausted. The packet sequence space is 230 exhausted if the number of packets that use the same key reaches 231 or exceeds 2,147,483,647(2^31-1). 233 o SN The Sequence Number. It is the unsigned 32-bit integer number 234 assigned to every FSP packet except the preliminary packets. 235 Difference of two sequence number is represented by a 32-bit 236 signed integer. If the result of SN B subtracting SN A is greater 237 than zero, we say that B is greater than A and the packet of the 238 sequence number B is later than the packet of the sequence number 239 A, although the unsigned integer representation of B may be far 240 less that A. Consequently, as the result of A subtracting B is 241 less than zero, we say that A is less than B and the packet of the 242 sequence number A is earlier than the packet of the sequence 243 number A. 245 o Transmit Transaction A transmit transaction in FSP is a sequence 246 of FSP packets that were sent and marked by the ULA as one 247 continuous stream where all packets in the stream must be 248 acknowledged before any further packet is allowed to be sent. A 249 ACK_CONNECT_REQ, PERSIST or MULTIPLY packet always starts a new 250 transmit transaction. Any packet with EoT flag set, including the 251 NULCOMMIT packet which is payload-less, terminates the transmit 252 transaction. The NULCOMMIT both starts and terminates a payload- 253 less transmit transaction when it is exploited to acknowledge the 254 ACK_CONNECT_REQ or MULTIPLY packet. 256 o ULA The Upper Layer Application. 258 o ULTID The Upper Layer Thread Identifier (ULTID). It is a 32-bit 259 word that was allocated by particular network end node of an FSP 260 connection and is unique in the local context of the network end 261 node. Theoretically all of the ULAs of a network end node MAY 262 establish up to 2^31-1 FSP connections totally. Each connection 263 MUST have a unique thread identifier (ULTID) assigned in the local 264 context of the network end node. A session or connection in FSP 265 does not require a global ID. 267 3. Key Mechanisms 269 3.1. Underlying Layer Services Required 271 FSP requires that the underlying layer provides packet delivery 272 service. In addition FSP supposes that the underlying layer has 273 following features: 275 3.1.1. Handling of High Mobility 277 Here high mobility refers to scenarios such as high-speed train or 278 airplane. 280 FSP solves somewhat coarse-grain or low-speed mobility problem. 281 Fine-grain or high-speed mobility is left to the underlying physical 282 network. To make mobility support work effectively it is assumed 283 that one end-node MUST keep its lower layer address reasonably stable 284 while the other end-node SHOULD NOT change its lower layer address 285 too frequently. 287 Here the meaning of physical network conforms to what was depicted in 288 [RFC1122]. 290 3.1.2. Network Address Change Notification 292 Network address change notification is mandatory only in the IPv6 293 network. 295 We split the IPv6 address of the IPv6 packet underlying FSP into 296 three parts. The leftmost 64-bit long word is the network prefix, 297 which SHOULD be the unique IPv6 prefix assigned to the host 298 [RFC8273]. The centermost 32-bit word is called the aggregation host 299 ID, and the rightmost 32-bit word is the ULTID. While the ULTID MUST 300 be kept stable even during the life of an FSP session, the network 301 prefix part MAY change when an endpoint is roaming. The aggregation 302 host ID may change as well. The network prefix part together with 303 the aggregation host ID part act as the traditional routing locator 304 at the network layer. 306 The aggragation host ID SHOULD NOT be 0, nor hexadecimal value 307 FDFFFFFFF, nor hexadecimal value FFFFFFFFF so that the final IPv6 308 address assigned can not be an IPv6 subnet anycast address[RFC2526]. 310 It is supposed that the network layer immediately notifies the FSP 311 layer if the network prefix or aggregation host ID changes. 313 An participant of an FSP connection SHALL immediately notify its peer 314 whenever its underlying IPv6 address is changed with a KEEP_ALIVE 315 packet. The peer shall send packet to the participant that has 316 notified the address change with the new address. 318 It is supposed that the packet to inform the remote end to update the 319 lower layer address association could reach its destination in a 320 satisfying success rate. 322 3.1.3. Network Congestion Control 324 Network layer congestion control is mandatory only in future IPv6 325 network. 327 It is supposed that end-to-end congestion control is provided at some 328 sub-layer of the network layer. Implementation of FSP MUST include a 329 congestion manager [RFC3124] if such sub-layer service of the network 330 layer is not provided. 332 3.2. Identifying Connection by Local ULTID 334 Each FSP connection prepares a pair of ULTIDs. An ULTID uniquely 335 indexes a connection in the local context of an FSP end node. An FSP 336 end node relies neither source IP address nor destination IP address, 337 except the ULTID part of the near end's IPv6 address to identify an 338 FSP connection. 340 Each ULTID is allocated in the local context of the two FSP 341 participant respectively. The source ULTID and the destination ULTID 342 of an FSP packet usually differ in their values. However, the secret 343 keys indexed in the local contexts of the two end-points must have 344 the same value. 346 3.3. Defending Against Connection Hijacking with ICC 348 An integrity check code (ICC) field associated with the ULTID is 349 designed in the FSP header to protect authenticity and optionally 350 privacy of the FSP packet. An FSP packet is assumed to originate 351 from the same source if the ICC value associated with certain 352 destination ULTID passes validation, regardless of the source or 353 destination address in the underlying layer. 355 On initiating FSP takes use of [CRC64] to make checksum of the FSP 356 packet to protect it against unintentional modification. The 357 checksum is taken as the ICC. 359 After the ULA has installed a shared secret key, value of ICC is 360 calculated by firstly getting the secret key associated indexed by 361 the local ULTID, then calculating the tag value with the AES-GCM 362 [GCM] authenticated encryption with additional data algorithm , or 363 calculating the message authentication code with the BLAKE2 algorithm 364 [RFC7693]. 366 3.4. Synchronizing Key Installation with Transmit Transaction 368 It is proposed that it is the ULA to do key establishment and/or end- 369 point user-agent authentication while the FSP layer provides 370 authenticated, optionally encrypted data transfer service. 372 A dedicate application program interface (API) is designed for the 373 ULA to install the secret key established by the ULA participants. 375 FSP facilitates shared secret key installation by introducing the 376 concept of transmit transaction. 378 A transmit transaction of FSP is a sequence of FSP packets that were 379 sent and requested by ULA as one continuous stream where all packets 380 in the stream MUST be acknowledged before any further packet is 381 allowed to be sent. 383 A flag called 'End of Transaction' (EoT) is designed in the FSP 384 header. When it is set, it marks that the transmit transaction in 385 the direction from the source of the FSP packet towards the 386 destination of the FSP packet is 'committed'. 388 As the FSP node knows when a transmit transaction at FSP layer is 389 terminated there is no ambiguity which packet is to be applied with 390 the new session key when the key is installed by ULA through the 391 dedicated API. 393 3.5. 0-RTT Connection Multiplication with OOB Packet 395 An FSP connection MAY be multiplied to get a branch or branches of 396 the connection. Multiplication of a connection is protected by 397 deriving new session key from the original security context of the 398 connection. 400 The packet that carries the command to multiply an established FSP 401 connection MUST be sent from a new allocated local ULTID towards the 402 destination ULTID of the original connection. It is an out-of-band 403 (OOB) packet in the context of the original connection and it MUST be 404 cryptographically protected by the secret key of the original 405 connection. The packet MAY carry payload. 407 The receiver of the packet MUST allocate a new local ULTID, accept 408 the optional payload in the new context associated with the new 409 ULTID, derive a new secret key from the secret key of the original 410 connection, and responds from the new context. The response MAY 411 carry payload. 413 The very first response packet MUST be protected by the new secret 414 key. The sender of the multiply command packet MUST automatically 415 inaugurate the same secret key, derived from the secret key of the 416 same original connection. And it MUST treat the response packet as 417 though a transmit transaction had been committed by the responder, 418 i.e. authenticity of the response packet is verified with the new 419 secret key. 421 Thus the branch connection of a new pair of ULTIDs is established 422 with zero round-trip overhead. This mechanism may be exploited to 423 provide expedited data transfer or parallel data transfer service. 425 4. Packet Structure 427 4.1. FSP over UDP/IPv4 429 In this version of FSP, when FSP is implemented in the IPv4 network, 430 every FSP packet MUST be encapsulated in a UDP [STD6] datagram. The 431 UDP datagram encapsulated the FSP packet SHALL have the checksum 432 disabled (i.e. set its value to 0) [RFC8085]. The Source and the 433 destination ULTIDs are put at the leading position of the UDP 434 payload. FSP fixed header, optional extension headers and FSP 435 payload follow the ULTIDs: 437 0 15 16 31 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Source Port | Destination Port | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Length | 0 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Source Upper Layer Thread ID | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Destination Upper Layer Thread ID | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 ~ FSP Fix Header ~ 449 | | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 ~ Optional FSP Extension Headers ~ 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 ~ ~ 454 ~ Optional FSP payload ~ 455 ~ ~ 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 4.2. FSP over IPv6 460 When FSP is implemented over IPv6 [RFC8200], the ULTID part is 461 embedded in the IPv6 address. FSP fixed header follows the IPv6 462 headers: 464 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 465 ~ IPv6 Header: ~ 466 0 15 16 31 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 |Version| Traffic Class | Flow Label | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Payload Length | Next Header | Hop Limit | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | 473 + Source Network Prefix + 474 | | 475 + Source Address ----------------------------+ 476 | Source Aggregation Host ID | 477 + ----------------------------+ 478 | Source Upper Layer Thread ID | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 + Destination Network Prefix + 482 | | 483 + Destination Address ---------------------------------+ 484 | Destination Aggregation Host ID | 485 + ---------------------------------+ 486 | Destination Upper Layer Thread ID | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 ~ ~ 489 ~ Optional IPv6 Headers ~ 490 ~ ~ 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 ~ FSP Fix Header ~ 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 ~ Optional FSP Extension Headers ~ 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ~ ~ 499 ~ Optional FSP payload ~ 500 ~ ~ 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 o Network Prefix The leftmost 64-bit of the IPv6 address which MAY 504 and usually do have different value at the difference interface of 505 an IPv6 end- node. 507 o Aggregation Host ID The left 32-bit part of the rightmost 64-bit 508 long word of the IPv6 address. All of the aggregation host ID 509 parts of an IPv6 end- node's IPv6 addresses MUST have the same 510 value for this version of FSP. 512 Network prefix and aggregation host ID make the IPv6 prefix part of 513 the IPv6 address under the context of FSP. It is assumed that there 514 is a unique IPv6 prefix per host [RFC8273]. 516 RFCs related to IPv6 address configuration such as ND for IPv6 517 [RFC4861], SLAAC [RFC4862], 'IPv6 Subnet Model' [RFC5942], 'IPv6 518 Address Assignment to End Sites' [RFC6177], 'Discovery of the IPv6 519 Prefix Used for IPv6 Address Synthesis' [RFC7050], DHCP [RFC8415] and 520 'IPv6 Node Requirements' [RFC8504] would be reviewed in separate 521 documents. 523 4.3. Generic FSP Header 525 FSP headers include the fixed header and the extension headers. A 526 general fixed header consists of a 32-bit FSP Header Signature and 527 20-byte operation-code specific fields. An extension header consists 528 of a 32-bit Code-Mark-Length Prefix and the operation-code specific 529 content. The length of the extension header content may be variable, 530 provided that the tail of the full extension header align on 64-bit 531 boundary. 533 Integers in the FSP fix header are transmitted in network byte order. 534 Otherwise, integers in the FSP headers are of little-endian. 536 0 31 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Header Signature | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 ~ ~ 541 ~ Operation Code Specific Fields ~ 542 ~ ~ 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 4.4. FSP Header Signature and Code-Mark-Length Prefix 547 0 7 8 15 16 31 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Operation Code| Major | Offset | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 0 7 8 15 16 31 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Operation Code| Mark | Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 4.4.1. Operation Code 559 The operation code is an octet that stores the code of the command 560 which indicates the function of the FSP packet, or specifies the type 561 of some extension header. 563 +------------------+------+---------------------------------------+ 564 | Synonym | Code | Meaning | 565 +------------------+------+---------------------------------------+ 566 | INIT_CONNECT | 1 | Initialize Connection | 567 | ACK_INIT_CONNECT | 2 | Acknowledge Initialization of | 568 | | | Connection | 569 | CONNECT_REQUEST | 3 | Formally Request to Connect | 570 | ACK_CONNECT_REQ | 4 | Acknowledge the Connection Request | 571 | RESET | 5 | Reset a connection. Abort the | 572 | | | connection, or refuse to establish | 573 | | | the connection at the very beginning. | 574 | NULCOMMIT | 6 | Commit without payload. The NULCOMMIT | 575 | | | packet MUST be payload- less, and its | 576 | | | EoT flag MUST be set. It MAY carry | 577 | | | optional extension headers. It always | 578 | | | consumes a slot of the send sequence | 579 | | | space. It is to commit current | 580 | | | transmit transaction, otherwise the | 581 | | | NULCOMMIT packet itself SHALL just be | 582 | | | skipped when delivering data to ULA. | 583 | KEEP_ALIVE | 7 | Keep the peer alive. It is an out-of- | 584 | | | band control packet acting as the | 585 | | | heart-beating signal. An out-of-band | 586 | | | control packet does not consume send | 587 | | | sequence space itself. FSP takes use | 588 | | | of the KEEP_ALIVE packet to inform | 589 | | | the peer about the change of the | 590 | | | source IP addresses. Besides, when | 591 | | | the MIND flag is set, the KEEP_ALIVE | 592 | | | packet is meant to tell the peer | 593 | | | which packets should be | 594 | | | retransmitted. | 595 | PERSIST | 8 | Make a connection persistent. It is | 596 | | | meant to start a new transmit | 597 | | | transaction after a connection | 598 | | | migrated to CLOSABLE state. It can | 599 | | | also acknowledge ACK_CONNECT_REQ or | 600 | | | MULTIPLY. It MUST carry payload. It | 601 | | | always consumes a slot of the send | 602 | | | sequence space. | 603 | PURE_DATA | 9 | Pure Data. It does not carry any | 604 | | | optional header. | 605 | ACK_FLUSH | 10 | ACKnowledge to remote end's | 606 | | | commitment (FLUSHing) of transmit | 607 | | | transaction. It is an out-of-band | 608 | | | control packet like KEEP_ALIVE. It | 609 | | | is sent instantly on having every | 610 | | | packet of the last transmit | 611 | | | transaction received, meant to make | 612 | | | acknowledgment to the remote end and | 613 | | | let the remote end stop sending | 614 | | | heart-beat signals. | 615 | RELEASE | 11 | Release the connection. RELEASE | 616 | | | packet does not carry payload, but it | 617 | | | always consumes a slot of the send | 618 | | | sequence space. | 619 | MULTIPLY | 12 | Multiply the connection. It is sent | 620 | | | in the context of the original | 621 | | | connection and may carry payload | 622 | | | and/or optional headers as an out-of- | 623 | | | band packet. | 624 | PEER_SUBNETS | 17 | Tell the remote end how to address | 625 | | | the sender of the packet in the | 626 | | | reverse direction. It is the code of | 627 | | | the Sink Parameter extension header. | 628 | SELECTIVE_NACK | 18 | Tell the remote end to retransmit the | 629 | | | packets that were negatively | 630 | | | acknowledged. It is the code of the | 631 | | | Selective Negative Acknowledgment | 632 | | | extension header. | 633 +------------------+------+---------------------------------------+ 635 4.4.2. Major 637 It is an octet that states current FSP major version. For this FSP 638 version it MUST be 0. 640 It is not mandatory for different major versions of FSP to be 641 compatible. 643 4.4.3. Mark 645 It is an octet that marks current minor version of the extension 646 header, under the major FSP version specified in the fixed header, 647 and/or serves as the flag, depending on the type of the extension 648 header. 650 It is mandatory for implementations to be compatible with different 651 minor versions of FSP extension header under the same major FSP 652 version. 654 It is not mandatory for minor versions of FSP extension header under 655 the different major FSP version to be compatible, even if the minor 656 versions happen to be the same. 658 4.4.4. Offset 660 The offset field is a 16-bit unsigned integer that specifies the 661 offset of the first octet of the payload, starting from the begin of 662 the FSP fixed header. If its value equals the size of the fixed 663 header the packet has no extension. 665 4.4.5. Length 667 The length field is a 16-bit unsigned integer that specifies the 668 length, including the Type-Version-Length Header and the size of the 669 the operation code specific content of the extension header. 671 4.5. Preliminary FSP Packets 673 Preliminary FSP packets are the packets exchanged during the end-to- 674 end negotiation phase of FSP connection establishment when it is 675 impossible to calculate ICC normally. 677 4.5.1. Connect Initialization 679 0 31 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Header Signature | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Salt | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | | 686 + Timestamp + 687 | | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 + Init-Check-Code + 691 | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 ~ ~ 694 ~ Host Name of the Responder (optional) ~ 695 ~ ~ 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Operation Code of this type of packet is INIT_CONNECT. 700 o Salt It a 32-bit random bit string that may be exploited to make 701 secret key agreement. 703 o Timestamp It is a 64-bit unsigned integer that represents number 704 of microseconds elapsed since 00:00, Jan.1, 1970, Coordinated 705 Universal Time. It may be exploited to synchronize the clocks of 706 the participants and/or estimate delay during data transmission in 707 the network. 708 o Init-Check-Code It is a 64-bit random [RFC4086] bit string that 709 means to uniquely associated with the connection initiated. 710 o Host Name of the Responder The optional payload of the Connect 711 Initialization packet is the host name of the responder. It MUST 712 be encoded in UTF-8 [RFC3629] and SHOULD be resolvable in DNS, 714 4.5.2. Acknowledgment to Connect Initialization 716 0 31 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Header Signature | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Time Delta | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | | 723 + Cookie + 724 | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | | 727 + Init-Check-Code + 728 | | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 ~ ~ 731 ~ Sink Parameter ~ 732 ~ ~ 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Operation Code of this type of packet is ACK_INIT_CONNECT. 737 o Time Delta It is a 32-bit signed integer which is the difference 738 between the near-end's time and the timestamp value sent in the 739 Connection Initialization packet. The units and the epoch of the 740 near-end's time value and the timestamp value MUST be the same. 741 However, the precision or resolution of the time delta value is 742 chosen arbitrarily by the responder. 743 o Cookie It is a 64-bit bit string cryptographically generated by 744 the responder in a represent-transfer state manner. More 745 specifically when the same timestamp, time delta, Init-Check-Code, 746 salt, source and destination ULTIDs are sent to the responder, the 747 responder MUST be able to generate the identical cookie value. 748 o Init-Check-Code It MUST be identical to the corresponding field in 749 the Connect Initialization packet acknowledged. 751 o Sink Parameter 752 It is an extension header specified in 4.7. 754 4.5.3. Connect Request 756 0 31 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Header Signature | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Salt | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 + Time Stamp + 764 | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | | 767 + Init-Check-Code + 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Initial Sequence Number | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Time Delta | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | | 775 + Cookie + 776 | | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 ~ ~ 779 ~ Sink Parameter ~ 780 ~ ~ 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 ~ ~ 783 ~ Host Name of the Initiator (optional) ~ 784 ~ ~ 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Operation Code of this type of packet is CONNECT_REQUEST. 789 The value of each field that has the identical name with the one in 790 the associated Connect Initialization and Acknowledgment to Connect 791 Initialization packet MUST be assigned the same value as in these two 792 packets, except header signature in the packet. 794 Note that the initiator SHALL fill in the time delta field as it is 795 and SHALL NOT assume endian-ness of the time delta field. 797 o Sink Parameter It is an extension header specified in 4.7. 799 o Host Name of the Initiator The optional payload of the Connect 800 Request packet is the host name, which is encoded in UTF-8 and 801 SHOULD be resolvable in DNS, of the initiator. It could be 802 exploited by the responder to look up the address of the initiator 803 that may receive packets in the reverse direction. 805 4.6. Normal Fixed Header 807 0 15 16 31 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Header Signature | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Flags | Advertised Receive Window Size | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Sequence Number | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Expected Sequence Number/Out-of-Band Serial Number | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | | 818 + Integrity Check Code + 819 | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Operation Code of a normal fixed header may be ACK_CONNECT_REQ, 823 PURE_DATA, PERSIST, KEEP_ALIVE, ACK_FLUSH, RELEASE or MULTIPLY. 825 o Flags It is bit-field of width 8. From left to right: 827 * End of Transaction (EoT): If the EoT flag of a packet is set, 828 it is the last packet of a transmit transaction. A packet with 829 the EoT flag set MAY be the start and the single packet of the 830 transmit transaction as well. 831 * Minimal-Delay (MIND): If the MIND flag of the Connect Request 832 or Acknowledgment to Connect Request packet is set, the ULA 833 prefers minimal delay and is willing to tolerate packet loss. 834 FSP SHALL drop the packet received earliest when there is no 835 enough receive buffer so that the latest packet received can be 836 saved and the delay to deliver data to ULA is minimized. If 837 the MIND flag has been set the EoT flag of any following packet 838 is simply ignored. The MIND flag of an FSP packet may be set 839 only if the packet does not belong to a compressed transmit 840 transaction. Payload of each FSP packet is delivered to the 841 ULA as an independent message if the MIND flag has been set. 842 * Compressed (CPR) If the CPR flag of the first packet of a 843 transmit transaction is set, compression is applied on the 844 octet stream of the payloads of the continuous packets that 845 constitute the transmit transaction, or to put it simply, the 846 payload octet stream of the transaction transaction. Such 847 transmit transaction is called a compressed transmit 848 transaction. When the CPR flag of a packet is set, CPR flag of 849 each following packet is ignored until reaching termination of 850 the transmit transaction. If the payload octet stream of the 851 transmit transaction is compressed the Minimal-Delay flag of 852 any packet in the transmit transaction MUST be cleared. 853 o ECN-Echo (ECE): The Explicit Congestion Notification Echo flag of 854 a packet is set if the sender of the packet has received an 855 underlying IPv6 packet with Congestion Experienced code point set 856 for its peer as stated in "The Addition of Explicit Congestion 857 Notification (ECN) to IP" [RFC3168]. 858 o Send Rate Reduced (SRR): The SRR flag of each packet SHALL be set 859 as soon as the sender has received a legitimate packet with ECE 860 flag set and has informed the congestion manager to reduce the 861 send rate, until a sent packet with SRR flag set is acknowledged. 862 o The remaining 3 bits are reserved. 864 Advertised Receive Window Size It is a 20-bit unsigned integer that 865 stores number of the free blocks in the receive buffer of the sender 866 of the packet that contains the receive window size field. It is 867 count from the slot meant to accept the packet with the expected 868 sequence number. The sender must ensure that the difference between 869 the latest sequence number sent out and the largest expected sequence 870 number received does not exceed the value of the latest advertised 871 receive window size received. 873 Sequence Number Each in-band FSP packet is assigned a 32-bit unsigned 874 integer as the sequence number. The sequence number assigned for in- 875 band FSP packets MUST be in strict order. An out-of-band packet that 876 has the operation code of KEEP_ALIVE, ACK_FLUSH or MULTIPLY MUST be 877 assigned a sequence number that falls in the receive window. 879 Expected Sequence Number The 'expected sequence number/out-of-band 880 serial number' field stores the earliest sequence number of the 881 packets that were not yet received in the receive window of the 882 sender for in-band packet. It is an accumulative acknowledgment. 883 Any packet with the sequence number before the received Expected 884 Sequence Number is supposed to have been received by the remote end. 886 Out-of-band Serial Number The 'expected sequence number/out-of-band 887 serial number' field stores a 32-bit unsigned integer that numbers 888 the out-of-band FSP packet separately from the sequence space of the 889 in-band packets. Each time an out-of-band packet is sent the out-of- 890 band serial number SHALL increase by one. It is assumed that in the 891 life of the session no two packets have the same sequence number and 892 the same out-of-band serial number simultaneously. 894 Integrity Check Code The ICC. 896 4.7. Sink Parameter 898 0 31 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Code-Mark-Length Prefix | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Listener ID/Host ID | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 ~ ~ 905 ~ Addressable Network Prefixes ~ 906 ~ ~ 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Operation Code in the Header Signature of this extension header is 910 PEER_SUBNETS. 912 o Listener ID It is the ULTID of the responder that is in LISTENING 913 state. 914 o Host ID It is the aggregation host id of the sender. It SHALL be 915 0 if it is in the IPv4 network. 916 o Addressable Network Prefixes These are up to 4 64-bit words that 917 specify the network prefixes of the lower layer interfaces that 918 are addressable by the receiver in the reverse direction. In this 919 version of the FSP 'Addressable Network Prefixes' field is of 920 fixed length. The last network prefix which is non-zero is the 921 last resort one. There MUST be at least one non-zero network 922 prefix. If there are more than one non-zero network prefixes 923 those other than the last resort are load-balanced preferred. In 924 an IPv6 network, the addressable network prefix is the leftmost 64 925 bits of the IPv6 address. The receiver of the Addressable Network 926 Prefixes SHALL send packet in the reverse direction, i.e. to the 927 sender of the field with the destination IPv6 address generated by 928 combining a preferred network prefix with the aggregation host id 929 and the ULTID part of the source address in the IPv6 header of the 930 received packet that eventually carries the Addressable Network 931 Prefixes. Such feature MAY be exploited to handle links with 932 unidirectional connectivity, but it is NOT RECOMMENTED. In an 933 IPv4 network for compatibility with the IPv6 addressed ULA the 934 64-bit word of the addressable network prefix specified is 935 composed as following Figure: 937 0 15 16 31 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | 0x2002 (IPv6 6to4 prefix) |IPv4 address (leftmost 16 bits)| 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 |IPv4 address(rightmost 16 bits)| UDP port number (16 bits) | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 Sender of the Sink Parameter packet SHOULD be NAT-aware in the IPv4 944 network. If it is able to obtain the from the NAT box (as defined 945 in "Traditional IP Network Address Translator (Traditional NAT)" 946 [RFC3022]) through Port Control Protocol (PCP) [RFC6887] SHOULD 947 fill in the IPv4 address and UDP port number fields with the public 948 IP value that were obtained. If it does not have such capability, 949 it SHALL fill in the addressable network prefix with all binary 950 zeroes. 952 4.8. Selective Negative Acknowledgment 954 0 31 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Code-Mark-Length Prefix | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Expected Sequence Number | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Delay Sample Sequence Number | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Acknowledgement Delay | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Gap Width | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Data Length | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 ~ ~ 969 ~ Further pairs of (Gap Width, Data Length) ~ 970 ~ ~ 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 The operation code of this type of extension header is SNACK.block. 975 o Expected Sequence Number It stores the earliest sequence number of 976 the packets that were not yet received in the receive window of 977 the sender. It is an accumulative acknowledgment. Any packet 978 with the sequence number before the received Expected Sequence 979 Number is supposed to have been received by the remote end. The 980 expected sequence number is represented in little endian. 982 o Delay Sample Sequence Number It stores the sequence number of the 983 packet that the acknowledgement delay was calculated on. The 984 delay sample sequence number is represented in little endian. 986 o Acknowledgement Delay A 32-bit unsigned integer specifies the 987 delay in microseconds between sending the packet containing the 988 SNACK extension header and accepting the last packet that is 989 accumulatively acknowledged by the SNACK extension header. The 990 acknowledgement delay is represented in little endian. 992 o Gap Width and Data Length The SNACK header contains the descriptor 993 of the receive window gaps. The descriptor itself is a list of 994 entries. The length of the list can be zero which means that 995 there is no gap in the receive window. If the list is not empty, 996 each entry contains the width of one gap (Gap Width) in the 997 receive window and the length of the continuously received data 998 following the gap (Data Length), respectively. The unit of 999 aforementioned length of gaps or number of packets is buffer block 1000 which size is agreed upon connection establishment. Gap width and 1001 data length MUST be transmitted in little endian. 1003 4.9. RESET 1005 The 'RESET' packet is a special command packet meant to interrupt 1006 connection setup process or disconnect abruptly. Operation Code of 1007 the packet is RESET. 1009 Structure of a RESET packet in C code snippet with unnamed union 1010 applied: 1012 struct FSP$HeaderSignature 1013 { 1014 octet opCode; 1015 octet major; 1016 uint16_t offset; 1017 }; 1019 struct FSP_RejectConnect 1020 { 1021 FSP$HeaderSignature hs; 1022 /* bit field to describe reasons for reset */ 1023 uint32_t reasons; 1024 /* sequence numbers */ 1025 union 1026 { 1027 timestamp_t timeStamp; 1028 struct 1029 { 1030 uint32_t initial; 1031 uint32_t expected; 1032 } sn; 1033 }; 1034 /* uniqueness proof */ 1035 union 1036 { 1037 uint64_t integrityCode; 1038 uint64_t cookie; 1039 uint64_t initCheckCode; 1040 }; 1041 }; 1043 When the RESET packet is the response to a Connect Initialization 1044 packet both the timeStamp and the initCheckCode fields of the RESET 1045 packet MUST be set to the same values of Time Stamp and Init-Check- 1046 Code in the Connect Initialization packet, respectively. 1048 When the RESET packet is the response to a Connect Request packet 1049 both the timeStamp and the cookie fields of the RESET packet MUST be 1050 set to the same value of Time Stamp and Cookie in the Connect Request 1051 packet, respectively. 1053 When the RESET packet is the response to a packet with a normal fixed 1054 header, the sn.initial, the sn.expected and the integrityCode of the 1055 RESET packet MUST be set as to specification of normal fixed header 1056 field Sequence Number, Expected Sequence Number and Integrity Check 1057 Code, respectively. 1059 5. The Finite State Machine 1061 5.1. NON_EXISTENT 1063 ---[API: Listen]-->LISTENING 1064 |--[API: Connect]-->CONNECT_BOOTSTRAP-->[Send INIT_CONNECT] 1065 |--[API: Multiply]-->CLONING-->[Send MULTIPLY] 1067 NON_EXISTENT is a pseudo-state before a connection is created by the 1068 ULA calling API Listen, Connect or Multiply (or after a connection is 1069 reset). 1071 5.2. LISTENING 1073 ---[API: Reset]-->NON_EXISTENT 1074 |<-->[Rcv.INIT_CONNECT]{&& accepted}[Send ACK_INIT_CONNECT] 1075 |<-->[Rcv.CONNECT_REQUEST] 1076 |--{&& duplication detected}--[Retransmit ACK_CONNECT_REQ] 1077 |--{&& no duplication}-->{Notify} 1078 |-->[API: Accept] 1079 -->{new context}CHALLENGING-->[Send ACK_CONNECT_REQ] 1080 |-->[API: Reject]-->[Send RESET]{abort new context, if any} 1082 LISTENING is a state entered by the ULA calling API Listen. 1084 5.3. CONNECT_BOOTSTRAP 1086 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1087 |-->[Rcv.ACK_INIT_CONNECT]-->CONNECT_AFFIRMING 1088 -->[Send CONNECT_REQUEST] 1089 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1091 CONNECT_BOOTSTRAP is a state entered by the ULA calling API Connect, 1092 before receiving the acknowledgement of the remote end to the 1093 connection initialization packet. 1095 5.4. CONNECT_AFFIRMING 1096 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1097 |--[Rcv.ACK_CONNECT_REQ]-->[Notify] 1098 |-->{Callback return to accept} 1099 |-->{EOT} 1100 |-->{No Payload to Send}-->COMMITTING2-->[Send NULCOMMIT] 1101 |-->{Has Payload to Send} 1102 |-->{ULA-flushing}-->COMMITTING2 1103 -->[Send PERSIST with EoT] 1104 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Send PERSIST] 1105 |-->{Not EOT} 1106 |-->{No Payload to Send}-->COMMITTING-->[Send NULCOMMIT] 1107 |-->{Has Payload to Send} 1108 |-->{ULA-flushing}-->COMMITTING 1109 -->[Send PERSIST with EoT] 1110 |-->{Not ULA-flushing}-->ESTABLISHED-->[Send PERSIST] 1111 |-->{Callback return to reject]-->NON_EXISTENT-->[Send RESET] 1112 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1113 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1115 CONNECT_AFFIRMING is a state entered by the ULA affirming to send 1116 connect request after receiving the acknowledgement to the connection 1117 initialization packet. 1119 5.5. CHALLENGING 1121 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1122 |<-->[API: Send{new data}]{just pre-buffer} 1123 |--[Rcv.NULCOMMIT] 1124 |-->{ULA-flushing}-->CLOSABLE-->[Notify] 1125 -->[Send ACK_FLUSH] 1126 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Notify] 1127 -->[Send ACK_FLUSH] 1128 |--[Rcv.PERSIST] 1129 |-->{EOT} 1130 |-->{ULA-flushing}-->CLOSABLE-->[Notify] 1131 -->[Send ACK_FLUSH] 1132 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Notify] 1133 -->[Send ACK_FLUSH] 1134 |-->{Not EoT} 1135 |-->{ULA-flushing}-->COMMITTED-->[Notify] 1136 -->[Send delay SNACK] 1137 |-->{Not ULA-flushing}-->ESTABLISHED-->[Notify] 1138 -->[Send delay SNACK] 1139 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1140 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1142 CHALLENGING is a state entered by the ULA accepting the connection 1143 request after a new connection context has been incarnated. The new 1144 connection is incarnated by the FSP context of the near end in the 1145 LISTENING state as a legitimate CONNECT_REQUEST packet is received. 1147 5.6. ACTIVE 1149 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1150 |--[API: Send{flush}]-->COMMITTING{Urge to commit} 1151 |<-->[API: Send{more data}][Send PURE_DATA] 1152 |--[Rcv.NULCOMMIT] 1153 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1154 |--[Rcv.PURE_DATA] 1155 |--{EOT}-->PEER_COMMIT 1156 -->[Send ACK_FLUSH]-->[Notify] 1157 |--{Not EOT}-->[Send SNACK]-->[Notify] 1158 |--[Rcv.PERSIST] 1159 |--{EOT}-->PEER_COMMIT 1160 -->[Send ACK_FLUSH]-->[Notify] 1161 |--{Not EOT}-->[Send SNACK] 1162 |--[Rcv.MULTIPLY]{passive multiplication} 1163 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1164 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1166 ACTIVE, also known as ESTABLISHED, is a state that the FSP 1167 participant has finished end-to-end negotiation but has not committed 1168 current transmit transaction nor fully received the latest transmit 1169 transaction of the remote end. 1171 5.7. COMMITTING 1173 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1174 |--[Rcv.ACK_FLUSH]-->COMMITTED-->[Notify] 1175 |--[Rcv.NULCOMMIT] 1176 |-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1177 |--[Rcv.PURE_DATA] 1178 |--{EOT}-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1179 |--{Not EOT}-->[Send SNACK]-->[Notify] 1180 |--[Rcv.MULTIPLY]{passive multiplication} 1181 |--[Rcv.RELEASE] 1182 |--{EOT}-->SHUT_REQUESTED-->[Send ACK_FLUSH]-->[Notify] 1183 |--{Not EOT}-->[Send SNACK lazily] 1184 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1185 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1187 COMMITTING is a state that the FSP participant has committed the 1188 transmit transaction but has not fully received the latest transmit 1189 transaction of the remote end, nor the acknowledgement to the 1190 transmit transaction commitment has been received. 1192 The participant in COMMITTING state SHALL NOT transmit further data 1193 until current transmit transaction commitment is acknowledged. 1195 5.8. COMMITTED 1197 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1198 |--[API: Send{more data}]-->ACTIVE-->[Send PERSIST] 1199 |--[API: Send{flush}]-->COMMITTING-->{Flush the send queue} 1200 |--[Rcv.NULCOMMIT]-->CLOSABLE 1201 -->[Send ACK_FLUSH]-->[Notify] 1202 |--[Rcv.PURE_DATA] 1203 |-->{EOT}-->CLOSABLE 1204 -->[Send ACK_FLUSH]-->[Notify] 1205 |-->{Not EOT}-->[Send SNACK]-->[Notify] 1206 |--[Rcv.PERSIST] 1207 |-->{EOT}-->CLOSABLE 1208 -->[Send ACK_FLUSH]-->[Notify] 1209 |-->{Not EOT}-->[Send SNACK] 1210 |--[Rcv.MULTIPLY]{passive multiplication} 1211 |--[Rcv.RELEASE] 1212 |--{EOT}-->SHUT_REQUESTED 1213 -->[Send ACK_FLUSH]-->[Notify] 1214 |--{Not EOT}-->[Send SNACK lazily] 1215 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1216 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1218 COMMITTED is a state that the FSP participant has committed current 1219 transmit transaction and has received the acknowledgement to the 1220 transmit transaction commitment, but has not fully received the 1221 latest transmit transaction of the remote end. 1223 5.9. PEER_COMMIT 1225 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1226 |--[API: Send{flush}]-->{Mark EoT or append NULCOMMIT} 1227 -->COMMITTING2-->{Do Send} 1228 |--[API: Shutdown]-->PRE_CLOSED-->{Append RELEASE} 1229 -->{Do Send} 1230 |<-->[API: Send{more data}][Send PURE_DATA] 1231 |<-->[Rcv.PURE_DATA]{just prebuffer} 1232 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1233 |--[Rcv.PERSIST] 1234 |<-->{EOT}-->[Send ACK_FLUSH] 1235 --{&& is new transaction}-->[Notify] 1236 |-->{Not EOT}-->ACTIVE-->[Send SNACK] 1237 |--[Rcv.MULTIPLY]{passive multiplication} 1238 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1239 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1241 PEER_COMMIT is a state that the FSP participant has not committed 1242 current transmit transaction but has fully received the latest 1243 transmit transaction of the remote end, and the acknowledgement to 1244 the transmit transaction commitment has not been received yet. 1246 5.10. COMMITTING2 1248 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1249 |--[API: Shutdown]-->PRE_CLOSED-->{Append RELEASE}-->{Do Send} 1250 |<-->[Rcv.PURE_DATA]{just prebuffer} 1251 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1252 |--[Rcv.ACK_FLUSH]-->CLOSABLE-->[Notify] 1253 |--[Rcv.PERSIST] 1254 |--{EOT}--{but a new transaction} 1255 -->[Send ACK_FLUSH]-->[Notify] 1256 |--{Not EOT}-->COMMITTING-->[Send SNACK] 1257 |--[Rcv.MULTIPLY]{passive multiplication} 1258 |--[Rcv.RELEASE]-->SHUT_REQUESTED 1259 -->[Send ACK_FLUSH]-->[Notify] 1260 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1261 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1263 COMMITTING2 is a state that the FSP participant has committed current 1264 transmit transaction and has fully received the latest transmit 1265 transaction of the remote end, but the acknowledgement to the 1266 transmit transaction commitment has not been received yet. 1268 The participant in COMMITTING2 state SHALL NOT transmit further data 1269 until current transmit transaction commitment is acknowledged. 1271 5.11. CLOSABLE 1273 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1274 |--[API: Send{more data}]-->PEER_COMMIT-->[Send PERSIST] 1275 |--[API: Send{flush}]-->COMMITTING2-->{Flush the send queue} 1276 |--[API: Shutdown]-->PRE_CLOSED-->{Append RELEASE}-->{Do Send} 1277 |<-->[Rcv.PURE_DATA]{just prebuffer} 1278 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1279 |--[Rcv.PERSIST] 1280 |--{EOT}--{but a new transaction} 1281 -->[Send ACK_FLUSH]-->[Notify] 1282 |-->{Not EOT}-->COMMITTED-->[Send SNACK] 1283 |--[Rcv.MULTIPLY]{passive multiplication} 1284 |--[Rcv.RELEASE]-->SHUT_REQUESTED 1285 -->[Send ACK_FLUSH]-->[Notify] 1286 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1288 CLOSABLE is a state that the FSP participant has committed current 1289 transmit transaction and has received the acknowledgement to the 1290 transmit transaction commitment, and has fully received the latest 1291 transmit transaction of the remote end. 1293 5.12. SHUT_REQUESTED 1295 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1296 |--[API: Shutdown]-->CLOSED-->[Notify] 1297 |<-->[Rcv.RELEASE]-->[Send ACK_FLUSH] 1298 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1300 SHUT_REQUESTED is a state entered when a legitimate RELEASE packet 1301 was received. 1303 A connection context MAY persist in SHUT_REQUESTED state until the 1304 session key runs out of life, or the host system needs to recycle the 1305 resource allocated. A connection in SHUT_REQUESTED state MAY be 1306 resurrected. 1308 5.13. PRE_CLOSED 1310 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1311 |--[Rcv.ACK_FLUSH]-->CLOSED-->[Notify] 1312 |--[Rcv.RELEASE]-->[Notify]-->CLOSED 1313 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1314 |--{On transient state Timeout}-->CLOSED-->[Notify] 1316 PRE_CLOSED is a state entered on the ULA calling the API Shutdown in 1317 COMMITTING2 or CLOSABLE state. 1319 5.14. CLOSED 1321 |--{On Recycling Needed}-->NON_EXISTENT 1323 CLOSED is a state migrated from PRE_CLOSED state on receiving a 1324 legitimate ACK_FLUSH packet from the remote end, or from 1325 SHUT_REQUESTED state on the ULA calling the API Shutdown. 1327 Unlike TCP [STD7], CLOSED state in FSP is not fictional. Instead a 1328 connection context MAY persist in CLOSED state until the session key 1329 runs out of life, or the host system needs to recycle the resource 1330 allocated to the CLOSED session. A connection in CLOSED state MAY be 1331 resurrected. 1333 5.15. CLONING 1335 ---[API: Reset]-->NON_EXISTENT 1336 |<-->[API: Send{new data}]{just prebuffer} 1337 |<-->[Rcv.PURE_DATA]{just prebuffer} 1338 |--[Rcv.NULCOMMIT] 1339 |--{&& Not ULA-flushing}-->PEER_COMMIT 1340 -->[Send ACK_FLUSH]-->[Notify] 1341 |--{&& ULA-flushing}-->CLOSABLE 1342 --->[Send ACK_FLUSH]-->[Notify] 1343 |--[Rcv.PERSIST] 1344 |-->{Not EOT} 1345 |--{&& Not ULA-flushing}-->ACTIVE 1346 -->[Send SNACK]-->[Notify] 1347 |--{&& ULA-flushing}-->COMMITTED 1348 -->[Send SNACK]-->[Notify] 1349 |-->{EOT} 1350 |--{&& Not ULA-flushing}-->PEER_COMMIT 1351 -->[Send ACK_FLUSH]-->[Notify] 1352 |--{&& ULA-flushing}-->CLOSABLE 1353 -->[Send ACK_FLUSH]-->[Notify] 1354 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1355 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1357 CLONING is a state entered by ULA calling the API Multiply from any 1358 state that may accepting an out-of-band packet. 1360 5.16. Passive Multiplication 1362 {ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, COMMITTING2, CLOSABLE} 1363 |-->/MULTIPLY/-->[API{Callback}]-->{new context}CONNECT_AFFIRMING 1364 |-->[{Return Accept}] 1365 |-->{has payload prebuffered} 1366 -->{Send packet(s) starting with PERSIST} 1367 |-->{without payload}-->[Send NULCOMMIT] 1368 |-->[{Return Reject}]-->{abort creating new context} 1369 -->[Send RESET] 1371 In the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, COMMITTING2 or 1372 CLOSABLE state an FSP end node MAY accept its peer's connection 1373 multiplication request and transit to the unnamed, temporary passive 1374 multiplication state. 1376 5.17. Typical State Transitions 1378 This section is informative. 1380 5.17.1. Typical Main Connection 1382 *** Bootstrapping *** 1383 CONNECT_BOOTSTRAP ------ INIT_CONNECT -------> LISTENING 1384 | <---- ACK_CONNECT_INIT ----- 1385 CONNECT_AFFIRMING ------ CONNECT_REQUEST ----> | 1387 *** Connection affirmation, carrying welcome messages *** 1388 | 1389 {Accept} 1390 {and send a single packet welcome message immediately} 1391 | 1392 | <- ACK_CONNECT_REQ c/w EoT - CHALLENGING 1393 PEER_COMMITTED 1394 | 1395 {Callback, to send ticket immediately} 1396 {(a fictional identification token of a single packet)} 1397 | 1398 COMMITTING2 ----- PERSIST c/w EoT -----> | 1399 CLOSABLE 1400 | <-------- ACK_FLUSH -------- | 1401 CLOSABLE 1402 | 1403 {Send Server's Challenge} 1404 | 1405 | <----- PERSIST w/o EoT ----- PEER_COMMITED 1406 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1407 . 1408 . 1410 . | 1411 {Flush} 1412 | 1413 | <---- PURE_DATA c/w EoT ---- COMMITTING2 1414 CLOSABLE 1415 --------- ACK_FLUSH -------> | 1416 CLOSABLE 1417 | 1418 {Send Client's Response} 1419 | 1420 PEER_COMMITTED ----- PERSIST w/o EoT -----> | 1421 COMMITTED 1422 | <--- KEEP_ALIVE(SNACK) ----- | 1423 . 1424 | ---- PURE_DATA w/o EoT ----> COMMITTED 1425 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ---- | 1426 . 1427 . 1429 | . 1430 {Flush} 1431 | 1432 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1433 CLOSABLE 1434 | <-------- ACK_FLUSH -------- 1435 CLOSABLE 1437 ** Typical C/S request-response exchange on application layer ** 1438 | 1439 {Send Request} 1440 | 1441 PEER_COMMITTED ----- PERSIST w/o EoT -----> | 1442 COMMITTED 1443 | <--- KEEP_ALIVE(SNACK) ----- | 1444 . 1445 | ---- PURE_DATA w/o EoT ----> COMMITTED 1446 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ----- | 1447 . 1448 . 1449 | . 1450 {Flush} 1451 | 1452 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1453 CLOSABLE 1454 | <-------- ACK_FLUSH -------- 1455 CLOSALBE 1456 {Send Response} 1457 | 1458 | <----- PERSIST w/o EoT ----- PEER_COMMITED 1459 COMMITTED 1460 ---- KEEP_ALIVE(SNACK) ----> | 1461 . 1462 | <---- PURE_DATA w/o EoT ---- PEER_COMMITED 1463 COMMITTED ---- KEEP_ALIVE(SNACK) ----> | 1464 . 1465 . 1466 . 1467 {Flush} 1468 | 1469 | <---- PURE_DATA c/w EoT ---- COMMITTING2 1470 CLOSABLE 1471 --------- ACK_FLUSH -------> | 1472 CLOSALBE 1473 . 1474 . 1475 . 1476 *** Following request-responses, e.g. HTTP pipelining *** 1477 . 1478 . 1479 . 1481 CLOSABLE CLOSALBE 1482 . 1483 . 1484 *** End of connection, in a typical C/S application *** 1485 | 1486 {Shutdown} 1487 | 1488 | <---------- RELEASE -------- PRE_CLOSED 1489 SHUT_REQUESTED 1490 --------- ACK_FLUSH -------> | 1491 | CLOSED 1492 {Shutdown} 1493 | 1494 CLOSED 1496 5.17.2. Typical Clone Connection for Get Resource 1498 Client Server 1499 *** Suppose the browser fork a new connection to request *** 1500 *** some resource and the URI is short enough to be *** 1501 *** encapsulated in a single packet *** 1502 {MultiplyAndWrite} 1503 | {In Clonable State} 1504 CLONING ---- MULTIPLY c/w EoT ----> * 1505 {Make Clone Connection} 1506 {and return resource data immediately} 1507 | 1508 | <---- PERSIST w/o EoT ------ PEER_COMMITTED 1509 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1511 <---- PUER_DATA w/o EoT ---- PEER_COMMITTED 1512 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1513 . 1514 . 1515 . | 1516 {Flush} 1517 | 1518 | <--- PURE_DATA c/w EoT ----- COMMITTING2 1519 CLOSABLE 1520 --------- ACK_FLUSH -------> | 1521 CLOSABLE 1522 . 1523 . 1524 *** End of Connection *** 1526 5.17.3. Typical Clone Connection for Push Message 1528 Initiator of Multiplication Responder of Multiplication 1529 *** Suppose the server fork a new connection to push message *** 1530 (Used to be server side) (Used to be client side) 1531 | 1532 {MultiplyAndWrite} 1533 | {In Clonable State} 1534 CLONING ---- MULTIPLY w/o EoT ----> * 1535 {Make Clone Connection} 1536 *** suppose no immediately available responding data *** 1537 | 1538 COMMITTING 1539 | <--- NULCOMMIT(c/w EoT) ---- | 1540 PEER_COMMITTED 1541 | --------- ACK_FLUSH -------> COMMITTED 1542 . 1543 | ---- PURE_DATA w/o EoT ----> COMMITTED 1544 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ---- | 1545 . 1546 . 1547 | . 1548 {Flush} 1549 | 1551 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1552 CLOSABLE 1553 | <-------- ACK_FLUSH -------- 1554 CLOSABLE 1555 . 1556 . 1557 *** End of Connection *** 1559 5.17.4. Simultaneous Shutdown 1561 CLOSABLE CLOSABLE 1562 | | 1563 {Shutdown} {Shutdown} 1564 | | 1565 PRE_CLOSED PRE_CLOSED 1566 | \ / | 1567 | \ / | 1568 | \ / | 1569 | \------------- RELEASE --------------/----->+ 1570 +<------------------- RELEASE ------------/ | 1571 | CLOSED 1572 CLOSED 1574 6. End-to-End Negotiation 1576 End-to-end negotiation of FSP session occurs in the connection 1577 establishment phase. Connection establishment process of FSP 1578 consists of two and a half pairs of packet exchanges for connection 1579 initialization, connection incarnation and the last confirmation. 1580 During the process various optional header or payload MAY be carried 1581 in the FSP preliminary packets to negotiate end-to-end session 1582 parameters. 1584 6.1. Connect Initialization 1586 The initiator sends the INIT_CONNECT packet to the responder: 1587 (INIT_CONNECT, Salt, Timestamp, Init-Check-Code [, Responder's Host 1588 Name]) 1590 Connection initialization MAY be syndicated with optional address 1591 resolution at the gateway in the IPv6 network by carrying the 1592 responder's host name in the INIT_CONNECT packet. 1594 If it does carry the responder's host name it MUST take the link- 1595 local interface address [RFC4291] as the source IPv6 address and the 1596 default link-local gateway address, FE80::1, as the destination IPv6 1597 address no matter whether the global unicast IP address of the 1598 default gateway is configured. 1600 If the gateway that relays the INIT_CONNECT packet finds that the 1601 responder is on the same link-local network with the initiator it 1602 SHALL change the source and the destination IP addresses of the 1603 INIT_CONNECT packet to the link-local IP addresses of the initiator 1604 and the responder respectively, and relay the packet onto the same 1605 link-local network. 1607 On receiving the INIT_CONNECT packet that carries the responder's 1608 host name the link-local gateway MUST resolute the responder's global 1609 unicast IPv6 address and map the initiator's global unicast IPv6 1610 address, and replace the destination and source address of the 1611 INIT_CONNECT packet respectively, unless it finds that the initiator 1612 and the responder are on the same link-local network, where the 1613 gateway SHALL process the packet as stated in the previous statement. 1615 The gateway SHALL silently ignore the INIT_CONNECT packet if it is 1616 unable to resolve the IP address of the responder. 1618 If the destination address is the default link-local gateway address 1619 while the INIT_CONNECT does not carry the responder's host name 1620 payload, it is supposed that the gateway is the intent destination of 1621 the connection to initialize. 1623 6.2. Response to Connect Initialization 1625 The responder sends acknowledgment to the initiator: 1627 (ACK_INIT_CONNECT, Time-delta, Cookie, Init-Check-Code Reflected, 1628 Responder's Sink Parameter) 1630 If the responder is ready to accept the connection, it SHALL generate 1631 a cookie which is meant to be reflected by the initiator. The 1632 responder MUST send the ACK_INIT_CONNECT packet with the new 1633 allocated local ULTID instead of the original listening ULTID. The 1634 initiator should be able to find out the original listening ULTID by 1635 searching its own connection context. 1637 In the Responder's Sink Parameter the original listener ULTID MUST be 1638 set to the right value. 1640 The destination address of the packet sent back MUST be set to the 1641 source address of the corresponding Connect Initialization packet 1642 whose source and destination address MAY be updated by some 1643 intermediary such as the link-local gateway of the initiator. 1645 The responder SHALL NOT make state transition on receiving 1646 INIT_CONNECT packet. 1648 If the responder refuses to accept the connection, it SHALL silently 1649 discard the INIT_CONNECT packet. 1651 6.3. Connection Incarnation Request 1653 (CONNECT_REQUEST, Salt, Timestamp, Init-Check-Code, Initial SN, Time- 1654 delta Reflected, Cookie Reflected, Initiator's Sink Parameter [, 1655 Initiator's Host Name]) 1657 The initiator accepts the Response to Connect Initialization packet 1658 if and only if both the destination ULTID of the response packet 1659 matches the source ULTID of the connect initialization packet and the 1660 Init-Check-Code reflected in the response packet matches the Init- 1661 Check-Code in the connect initialization packet. 1663 If the response packet is accepted the initiator formally requests to 1664 establish the connection by sending the CONECT_REQUEST packet. 1666 In the CONNECT_REQUEST packet the value of the Timestamp, the Init- 1667 Check-Code and the Salt field MUST be the same as in the INIT_CONNECT 1668 packet while the value of the Cookie Reflected field and the Time- 1669 delta Reflected field MUST be the same as in the ACK_INIT_ CONNECT 1670 packet, respectively. 1672 The initiator MUST send the packet towards the remote ULTID that the 1673 responder has preserved and sent with the ACK_INIT_CONNECT packet. 1674 It MUST fill the original listener ID field in the Initiator's Sink 1675 Parameter with the right value. 1677 The source address of the CONNECT_REQUEST packet MUST be set to the 1678 destination address of the received ACK_INIT_CONNECT packet, while 1679 the network prefix and host-id part of the destination address MUST 1680 be set to the source address of the received ACK_INIT_CONNECT packet 1681 in the IPv6 network. 1683 The initiator SHALL save the cookie value that the responder has 1684 given to make up the weak session key. 1686 The initiator MUST fill the Initial SN field with the sequence number 1687 of the packet that will follow CONNECT_REQUEST. The CONNECT_REQUEST 1688 packet is payload free and does not consume the sequence space. 1690 The optional fields Initiator's Host Name is put as the payload of 1691 the CONNECT_REQUEST packet. If presented it MAY be exploited by the 1692 responder as the last resort to resolute the most recent IP address 1693 of the initiator in some extraordinary scenarios such as the 1694 initiator has hibernated for a considerably long time. 1696 6.4. Connection Incarnation Response 1698 Case 1: (ACK_CONNECT_REQ, FREWS, Initial SN, Expected SN, ICC[, 1699 Payload]) 1701 Case 2: (RESET, Reason of Failure, Timestamp Reflected, Copy of 1702 Cookie Reflected) 1704 The responder responds as in case 1 if the reflected cookie was 1705 validated, resources were successfully allocated and the initial 1706 context of the connection was setup. Otherwise it SHOULD respond as 1707 in case 2. 1709 However, if the cookie is invalid, the responder SHALL silently 1710 discard the CONNECT_REQUEST packet. 1712 The Initial SN in case 1 is the initial sequence number of the 1713 responder. The responder should fill in the field with a random 32- 1714 bit unsigned integer. As the ACK_CONNECT_REQ packet may carry 1715 payload the sequence number of the responder starts from the 1716 ACK_CONNECT_REQ packet. 1718 The Expected SN MUST equal to the Initial SN specified in the 1719 corresponding CONNECT_ REQUEST packet. 1721 6.5. The Last Confirmation 1723 Case 1: (NULCOMMIT, FREWS, Initial SN, Expected SN, ICC) 1725 Case 2: (PERSIST, FREWS, Initial SN, Expected SN, ICC, payload) 1727 Case 3: (RESET, Reason of Failure, Initial SN, Expected SN, ICC) 1729 The initiator of the connection MUST eventually confirm to the 1730 responder that the connection is established by sending a payload- 1731 less NULCOMMIT packet (case 1) or a PERSIST packet with payload (case 1732 2). 1734 Of course the initiator MAY quit to establish the connection by 1735 sending a legitimate RESET packet (case 3). 1737 6.6. Retransmission 1739 The initiator SHALL retransmit the INIT_CONNECT packet if the 1740 corresponding ACK_INIT_CONNECT packet is not received in some limit 1741 time (by default 15 seconds). 1743 The initiator SHALL retransmit the CONNECT_CONNECT packet if the 1744 corresponding ACK_CONNECT_REQ packet is not received in some limit 1745 time (by default 15 seconds). 1747 The responder SHALL NOT retransmit ACK_INIT_CONNECT or 1748 ACK_CONNECT_REQ packet. 1750 The initiator SHOULD retransmit the right INIT_CONNECT packet or 1751 CONNECT_CONNECT packet until the legitimate ACK_CONNECT_REQ packet is 1752 eventually received. 1754 It SHALL give up if the time starting from the very first 1755 INIT_CONNECT packet was sent has exceed a longer timed-out value (by 1756 default 60 seconds) before the legitimate ACK_CONNECT_REQ packet is 1757 received. 1759 7. Quad-party Session Key Installation 1761 It is assumed that in the scenarios applying FSP it is the ULA to do 1762 key establishment and/or end-point authentication while the FSP layer 1763 provides authenticated, optionally encrypted data transfer service. 1764 The ULA installs the established shared secret key as the new session 1765 key of the FSP layer. Together they establish a secure channel 1766 between two application end-points. 1768 In a typical scenario the ULA endpoints first setup the FSP 1769 connection where resistance against connection redirection is weakly 1770 enforced by CRC64. After the pair of ULA endpoints have established 1771 a shared secret key, they install the secret key. Authenticity of 1772 the FSP packets sent later is cryptographically protected by the new 1773 secret key and resistance against various attacks is secured. 1775 Although transmit transaction is actually uni-directional the secret 1776 key is shared bi-directionally in this version of FSP. 1778 Protocol for installation of the shared secret key is quad-party in 1779 the sense that both the upper layer application and the FSP layer of 1780 both the participant nodes MUST agree on the moment of certain state 1781 to install the shared secret key. 1783 It is arguably much more flexible for the application layer protocols 1784 to adopt new key establishment algorithm while offloading routine 1785 authentication and optionally encryption of the data to the 1786 underlying layers where it may be much easier to exploit hardware- 1787 acceleration. 1789 7.1. API for Session Key Installation 1791 A dedicate application program interface (API) is designed for the 1792 ULA to install the secret key established by the ULA participants. 1793 The API SHOULD take four parameters: 1795 o A 'handle' to state the connection context for installing the 1796 session key 1797 o A octet string of initial key materials (IKM) 1798 o An integer to state the length of IKM. The unit is octet. 1799 o An integer to state the desired length of the effective session 1800 key if AEAD is applied. The unit is bit. For this version of FSP 1801 desired length of the effective session key is either 128 or 256. 1803 The peer MUST have commit a transmit transaction and it SHALL install 1804 the same secret key on receiving the FSP packet with the EoT flag 1805 set. 1807 The ULA SHOULD have installed the new shared secret key, or install 1808 it instantly after accepting the packet with the EoT flag set. If 1809 the new secret key has ever been installed the packet received after 1810 the one with the EoT flag set MUST adopt the new secret key. 1812 7.2. Time to Call API for Session Key Installation 1814 A participant MAY install new session key if and only if the packet 1815 with the latest sequence number it has received has EoT flag marked. 1817 7.3. Time to Take New Session Key into Effect 1819 By committing a transmit transaction a ULA participant clearly tells 1820 the underlying FSP layer that the next packet sent MAY adopt a new 1821 secret key. On receiving a packet with the EoT flag set the ULA is 1822 informed that the next packet received MAY adopt a new shared secret 1823 key. 1825 After the ULA of a network node installed a new session key, every 1826 packet to send with sequence number later than the one with the EoT 1827 flag set just before the API to install session key was called MUST 1828 adopt the new session key in the FSP layer of the network node. 1830 Every packet received with the sequence number later than the one 1831 with EoT flag set when the ULA called the API to install session key 1832 MUST be validated with the new session key. If the new secret key 1833 has ever been installed the packet received after the one with the 1834 EoT flag set MUST adopt the new secret key. 1836 7.4. Generating the Initial Session Key 1838 When the ULA install the secret key, it is required to provide the 1839 initial key material which might have unbalanced bit randomness, not 1840 the session key itself. HMAC-based Extract-and-Expand Key Derivation 1841 Function (HKDF) [RFC5869] is applied to generate the initial session 1842 key. 1844 Given raw key material ikm, length of the ikm nB in octets, intended 1845 master key length lenb in bits, || is octet string concatenation, 1847 If HMAC only is designated, the nB octets of ikm is hashed into 64 1848 octets which is taken as the master key. 1850 If AEAD is designated, the initial session key, or the first secret 1851 key for packet authentication and payload encryption is obtained as 1852 specified in [RFC5869]: 1854 Key Extract phase, Let Km = BLAKE2(zeros || ikm) , where zeros is 32 1855 octets of integer 0 BLAKE2b algorithm without key is applied. The 1856 result Km is the master key. 1858 Key Expand phase, 1859 Let Ks = BLAKE2(Km, info) , where 1861 Km is the master key generated in previous phase, 1863 info is concatenation of the arbitrary ASCII string "Establishes an 1864 FSP session", which is 26-octet long, 3 octets of integer 0, and 1 1865 octet of integer 1. 1867 BLAKE2b algorithm with key is applied. The key applied MUST be the 1868 master key Km. 1870 The result Ks is the initial session key, or the first secret key 1871 for packet authentication and payload encryption. For this version 1872 FSP the generated Ks is a fixed-length AES key together with a 1873 4-octet salt. The salt is meant to be passed to AES-GCM as the 1874 initialization vector together with the sequence number and 1875 expected sequence number fields in the normal FSP fixed header: 1877 0 31 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Salt | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | Sequence Number | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | Expected Sequence Number/Out-of-band Serial Number | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 The salt is called 'the original salt', separated from 'the second 1887 salt' in the out-of-band packet. 1889 7.5. Internal Rekeying 1891 In this version of FSP it is forced to re-key on sending or receiving 1892 every 536870912? (2^29) packets. 1894 Let Ks' = BLAKE2(Km, H || info') , where: 1896 Km is the master key generated as in section 7.4. 1898 H is the 16-octet internal hash sub-key of AES-GCM of previous 1899 session key, 1900 info' is concatenation of the arbitrary ASCII string "Sustains an 1901 FSP connection", which is 26-octet long and the 4 octets in network 1902 order of the 32-bit unsigned integer that specifies the batch index 1903 of the session key. 1905 BLAKE2b algorithm with key is applied. The key applied MUST be the 1906 master key Km. 1908 The result Ks' is the new session key, together with the new salt 1909 meant to be form the IV. 1911 The batch index of the initial session key is 1, and it is increased 1912 by 1 every time before it is to re-key. 1914 7.6. Sample Sequence of Installing Session Key 1916 This section is informative. 1918 Node A Node B 1919 ULA-A FSP-A FSP-B ULA-B 1920 {Send Km-A} 1921 ->[seq_a2b_0] -> 1922 {Send Km-B} 1923 <- [seq_b2a_0]<- 1924 . 1925 . 1926 . 1927 {Commit} 1928 ->[seq_a2b_m c/w EoT] -> 1929 {Install Key} 1930 . 1931 {Wait} . 1932 . 1933 {Commit} 1934 <- [seq_b2a_n c/w EoT]<- 1935 {Install Key} 1936 . 1937 . {Send Further} 1938 <- [seq_b2a_n+1]<- 1939 . 1940 {Send Further} . 1941 ->[seq_a2b_m+1] -> 1943 o Send Km-A, Send Km-B 1945 ULA of node A and node B send there key material for key 1946 establishment, respectively. 1948 * Commit 1949 * ULA of node A or node B informs the FSP layer to set the End of 1950 Transaction flag of the last packet to send and flush the send 1951 buffer. 1952 * Install Key 1953 * ULA of node A or node B informs the FSP layer to install new 1954 session key, giving key materials for deriving the session key. 1955 A node may call Install Key if and only if its peer has just 1956 committed a transmit transaction. 1957 Wait 1958 The ULA MUST wait until it has received some packet with EoT set 1959 from its peer before it may install new session key. There is no 1960 mandatory calling order of Commit and Install Key. However, if a 1961 node Commit before Install Key and it wants to apply new session 1962 key for the transmit transaction next to the one it has just 1963 committed, it SHALL NOT send further data until Install Key has 1964 returned successfully. In the above example, for node A packet 1965 with sequence number [seq_a2b_m+1] will be sent by applying the 1966 new session key, for node B packet with sequence number 1967 [seq_b2a_n+1] will be sent by applying the new session key. 1969 Send Further 1971 ULA of node A or node B sends further data in the new transmit 1972 transaction, respectively. There is no mandatory order on which node 1973 should start new transmit transaction firstly. 1975 8. Send and Receive 1977 8.1. Packet Integrity Protection 1979 8.1.1. Application of CRC64 1981 Starting from ACK_CONNECT_REQUEST, until the ULAs have installed the 1982 shared secret CRC64 is applied to calculate the value of the ICC 1983 field. The algorithm: 1985 1. Take pair of the ULDs as the initial value of accumulative CRC64 1986 2. Accumulate the value of the Init-Check-Code field 1987 3. Accumulate the value of the Cookie field successively 1988 4. Accumulate the combined value of the salt and the timeDelta field 1989 where the former is the leftmost 32 bits and the latter is the 1990 rightmost 32 bits 1991 5. Accumulate the value of the Time Stamp field 1992 6. Save the accumulated CRC64 value as the pre-computed CRC64 value 1994 The pair of the ULDs is composed of the near end's ULTID and the 1995 remote end's ULTID, where the former is the leftmost 32 bits and the 1996 latter is the rightmost 32 bits of initial value for the send 1997 direction, and the order is reversed for the receive direction. 1999 When calculate the value ICC of a particular FSP packet, firstly set 2000 ICC to the pre-computed CRC64 value, then calculate the CRC64 2001 checksum of the whole FSP packet, while ULTIDs are NOT included if 2002 the FSP packet is encapsulated in UDP. The result is set as the 2003 final value of the ICC field. 2005 8.1.2. Packet Authentication Only 2007 The ULA designates the FSP layer to either applying HMAC only or 2008 applying AEAD. 2010 If the HMAC flag of a packet is set the pre-designated cryptographic 2011 hash function SHALL be applied to get the message authentication code 2012 (MAC) of the whole packet. Each FSP version MUST designate one and 2013 only one particular cryptographic hash function. 2015 For this FSP version, BLAKE2 [RFC7693] is designated as the 2016 cryptographic hash function. The input key is the secret key that 2017 has been derived from the master key installed by the ULA. The input 2018 data is the full FSP packet, where the ICC field is pre-filled the 2019 pair of the ULDs. As in making CRC64 checksum, the pair of the ULDs 2020 is composed of the near end's ULTID and the remote end's ULTID, where 2021 the former is the leftmost 32 bits and the latter is the rightmost 32 2022 bits of initial value for the send direction, and the order is 2023 reversed for the receive direction. 2025 The hash result is truncated to 64 bits to get the final ICC. 2027 8.1.3. Authenticated Encryption with Additional Data 2029 FSP provides per-packet authenticated encryption service. Only one 2030 authenticated encryption algorithm is allowed for a determined 2031 version of FSP. For this FSP version, the authenticated encryption 2032 algorithm selected is GCM-AES [GCM][AES], it is applied to protect 2033 integrity of the full FSP packets, and privacy of the payload 2034 together with the extension headers, if any. The four inputs to GCM- 2035 AES authenticated encryption are: 2037 K: the key derived by the master key installed by ULA. The length of 2038 the session key is determined by the ULA. 2040 IV: the initial vector, 96-bit string made by concatenating a 32-bit 2041 salt, the 32-bit sequence number of the packet and the 32-bit 2042 expected sequence number field of the packet. The salt is derived by 2043 the master key installed by ULA. 2045 P: the plaintext are the bytes following the fixed header up to the 2046 end of the original payload. 2048 AAD: additional authenticated data, for this version of FSP it is the 2049 fixed header of the FSP packet. The source ULTID MUST be stored in 2050 the leftmost 32-bit of the ICC field while the destination ULTID MUST 2051 be stored in the rightmost 32-bit of the ICC field before the ICC 2052 value is calculated. 2054 The length of the authentication tag MUST be 64 bits for FSP version 2055 0 and 1. The authentication tag is stored in the ICC finally. 2057 The inputs to GCM-AES decryption are: 2059 K: the key derived by the master key installed by ULA. The length of 2060 the session key is determined by the ULA. 2062 IV: the initial vector, 96-bit string made by concatenating consisted 2063 of the 32-bit salt, the 32-bit sequence number of the packet and the 2064 32-bit expected sequence number field of the packet. 2066 C: the cipher-text are the bytes following the fixed header up to the 2067 end of the received payload. 2069 AAD: additional authenticated data, for this version of FSP it is the 2070 fixed header of the FSP packet. The source ULTID MUST be stored in 2071 the leftmost 32-bit of the ICC field while the destination ULTID MUST 2072 be stored in the rightmost 32-bit of the ICC field before the ICC 2073 value is calculated. 2075 T: The authentication tag, which is fetched from the ICC field 2076 received. 2078 Only when the outputs of GCM-AES decryption tell that the 2079 authentication tag passed verification may the receiver deliver the 2080 decrypted payload to the ULA. 2082 8.1.4. ICC of the Out-of-Band Packet 2084 When calculating the ICC of an out-band packet (KEEP_ALIVE, ACK_FLUSH 2085 or MULTIPLY), the ExpectedSN field SHALL be filled with the out-of- 2086 band serial number. The first 32-bit word of the fixed header is 2087 taken as the second salt. 2089 To get or check the ICC of the out-of-band packet the original salt 2090 value that is set on deriving the session key and stored in the 2091 internal security context MUST be XORed with the second salt value 2092 before applying GCM-AES. The original salt value MUST be recovered 2093 instantly after GCM-AES is applied. 2095 8.2. Start a New Transmit Transaction 2097 The responder starts a transmit transaction by send the 2098 ACK_CONNECT_REQ packet which MAY terminate the transmit transaction 2099 at the same time. 2101 When the initiator further acknowledges ACK_CONNECT_REQ with 2102 NULCOMMIT it both starts AND terminates a transmit transaction 2103 without sending any data: 2105 (NULCOMMIT, FREWS, SN, ExpectedSN, ICC [, Sink Parameter]) 2107 Any party MAY start a new transmit transaction by sending a PERSIST 2108 packet: 2110 (PERSIST, FREWS, SN, ExpectedSN, ICC, Payload) 2112 PERSIST packet sent by the initiator firstly acknowledges the 2113 ACK_CONNECT_REQ packet as well. 2115 8.3. Send a Pure Data Packet 2117 (PURE_DATA, FREWS, SN, ExpectedSN, ICC, Payload) 2119 After a new transmit transaction has been started further PURE_DATA 2120 packet MAY be sent until a packet with EoT flag set is sent. 2122 8.4. Commit a Transmit Transaction 2124 8.4.1. Initiate Transmit Transaction Commitment 2126 A participant of an FSP connection MAY notify its peer that a 2127 transmit transaction shall be committed by setting the EoT flag of 2128 the last packet of the transmit transaction, be it NULCOMMIT, 2129 PERSIST, PURE_DATA or MULTIPLY. 2131 8.4.2. Respond to Transmit Transaction Commitment 2133 (ACK_FLUSH, FREWS, SN, ExpectedSN, ICC, Sink Parameter, SNACK) 2135 If and only if all of the packets in a transmit transaction has been 2136 received MAY ACK_FLUSH packet be sent. 2138 Whenever a legitimate packet falls in the receive window of the 2139 receiver, and the packet fills in the last gap of the sequence of 2140 current transmit transaction on receiving direction, or the packet 2141 with same sequence number has been accepted already, a responding 2142 ACK_FLUSH SHALL be sent back immediately, and the FSP layer MUST 2143 immediately notify the ULA that a transmit transaction has been 2144 committed. 2146 The sequence number (SN) of the ACK_FLUSH packet MUST equal the 2147 latest sequence number of the legitimate packets that have been sent. 2149 The out-of-band serial number SHALL increase by one whenever a new 2150 ACK_FLUSH packet is sent. 2152 The ACK_FLUSH packet contains a Sink Parameter extension header, 2153 alike KEEP_ALIVE. 2155 The ACK_FLUSH packet SHALL contain a SNACK extension header, although 2156 number of gap descriptors in the SNACK header MUST be 0. 2158 8.4.3. Finalize Transmit Transaction Commitment 2160 After receiving the ACK_FLUSH packet the sender of the EoT flag 2161 migrates to the COMMITTED or CLOSABLE state from the COMMITTING or 2162 COMMITTING2 state, respectively. 2164 8.4.4. Time-out for Committing Transmit Transaction 2166 The ULA SHALL be timed-out if there is no packet was acknowledged in 2167 some hard-coded time-out. For this version of FSP the time-out is 2168 set to 30 seconds. 2170 8.5. Retransmission 2172 8.5.1. Calculation of RTT 2174 We borrows specifications for calculating RTT (and RTO) considerably 2175 from Computing TCP's Retransmission Timer [RFC6298] to calculate 2176 Retransmission Time Out (RTO). 2178 The sender maintains two state variables, SRTT (smoothed round-trip 2179 time) and RTTVAR (round-trip time variation). In addition, we assume 2180 a clock granularity of G seconds. 2182 Initial round trip time (RTT) for the Connection Initiator: Equals to 2183 the mean of the time elapsed when ACK_ INIT_CONNECT was received 2184 since INIT_CONNECT was sent, and the time elapsed till 2185 ACK_CONNECT_REQ was received since CONNECT_REQUEST was sent. 2187 Initial RTT for the Connection Responder: Equals to the time elapsed 2188 when the CONNECT_REQUEST packet was received since the 2189 ACK_INIT_CONNECT packet had been received. 2191 Initial RTT for the Initiator of Connection Multiplication: Equals to 2192 the most recent RTT of the multiplied connection. 2194 Initial RTT for the Responder of Connection Multiplication: Equals to 2195 the most recent RTT of the multiplied connection. 2197 o When the Initial RTT measurement R is made, the host MUST set 2199 SRTT <- R 2200 RTTVAR <- R/2 2202 o When a subsequent RTT measurement R' is made, a host MUST set 2204 RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| 2205 SRTT <- (1 - alpha) * SRTT + alpha * R' 2207 The value of SRTT used in the update to RTTVAR is its value before 2208 updating SRTT itself using the second assignment. That is, updating 2209 RTTVAR and SRTT MUST be computed in the above order. 2211 The above SHOULD be computed using alpha=1/8 and beta=1/4. 2213 R' SHOULD be measured whenever a packet with the SNACK extension 2214 header is received. 2216 Suppose the packet with the latest SN that is accumulatively 2217 acknowledged is P-latest, R' equals the time when the SNACK header is 2218 received, minus the time when P-latest was sent, minus the delay that 2219 the acknowledgment was made. 2221 The delay that the acknowledgment was made is stored in the 2222 "Acknowledgement Delay" field of the SNACK header. It equals the 2223 time difference between the time when the acknowledgement was sent 2224 and the time when P-latest was received. 2226 Note that the no packet with SN later than any gap described in the 2227 SNACK header is considered as the packet with the latest SN that is 2228 accumulatively acknowledged. 2230 8.5.2. Generation and transmission of SNACK 2232 Whenever the receiver receives a packet it SHALL shift the time to 2233 send next heartbeat signal earlier to the time of RTT since current 2234 time, if the time to send next heartbeat signal used to be later. If 2235 the time is already earlier than the time of RTT since current time, 2236 it needs not be shifted. 2238 On the time to send the heartbeat signal the FSP node generates the 2239 SNACK header, then generate and send a new KEEP_ALIVE or ACK_FLUSH 2240 packet to carry the SNACK header. It SHALL send an ACK_FLUSH if it 2241 is in PEER_COMMIT, COMMITTING2 or CLOSABLE state, otherwise it SHALL 2242 send a KEEP_ALIVE packet. 2244 8.5.3. Negative acknowledgment of Packets Sent 2246 Both the ACK_FLUSH and the KEEP_ALIVE packet in FSP carry the SNACK 2247 extension header, although number of gap descriptors in the SNACK 2248 extension header in the ACK_FLUSH packet MUST be 0. We call them 2249 SNACK packets. A SNACK packet P1 is said to be later than P0, if and 2250 only if SN of P1 is later than SN of P0, or SN of P1 equals SN of P0 2251 while the out-of-band sequence number of P1 is later than that of P0. 2252 If the latest SNACK packet is ACK_FLUSH, all the packets with the 2253 sequence number later that the expected field of the packet are 2254 assumed to be negatively acknowledged. 2256 By convention when we specify the range, the left square bracket 2257 meant to be inclusive, while the right parenthesis meant to be 2258 exclusive, the packets with SN in the ranges: 2260 [expectedSN, expectedSN + 1st Gap Width), 2262 [expectedSN + 1st Gap Width + 1st Data Length, expectedSN + 1st Gap 2263 Width + 1st DataLength + 2nd Gap Width), ... 2265 [expectedSN + 1st Gap Width + 1st Data Length... + (n-1)th Gap Width 2266 + (n-1)th Data Length, expectedSN + 1st Gap Width + 1st DataLength... 2267 + n-th Gap Width) 2269 together with the packets with SN later than (expectedSN + 1st Gap 2270 Width + 1st DataLength + ... + n-th Gap Width), these packets are 2271 assumed to be negatively acknowledged. 2273 8.5.4. Retransmission Interval 2275 Until RTT measurement has been made for a packet sent between the 2276 sender and receiver, the sender SHOULD set RTO <- 1 second. 2278 After computing new SRTT, a host MUST updated RTO <- SRTT + max (G, 2279 K*RTTVAR) where K = 4. 2281 Clock granularity SHOULD be finer than 100msec, that is, it SHOULD be 2282 that G <= 0.1 second. 2284 Whenever RTO is computed, if it is less than 1 second, then the RTO 2285 SHOULD be rounded up to 1 second. 2287 An implementation MUST manage the retransmission timer(s) in such a 2288 way that A packet is never retransmitted less than one RTO after the 2289 previous transmission of that packet. 2291 Every time an in-band packet is sent (including a retransmission), if 2292 the timer is not running, start it running so that it will expire 2293 after RTO seconds (for the current value of RTO). 2295 When all outstanding data has been acknowledged, turn off the 2296 retransmission timer. 2298 When the retransmission timer expires, retransmit the packets that 2299 have not been acknowledged by the receiver, but limit by the rate 2300 throttling mechanism. 2302 Rate of retransmission MUST be throttled in a way that No more that 2303 M/2 packets may be retransmitted in a clock interval, suppose in each 2304 clock interval M packets were sent averagely. 2306 Packet retransmission SHALL be subjected to congestion control as 2307 well. 2309 However, at least one packet MAY be retransmitted in one clock 2310 interval, provide that the retransmission timer expires for the first 2311 packet that has not been acknowledged yet. 2313 8.6. Flow Control 2315 The participants of an FSP connection negotiate the initial receive 2316 window size with the FREWS field in the ACK_CONNECT_REQ packet, and 2317 the first PERSIST or NULCOMMIT packet that acknowledges the 2318 ACK_CONNECT_REQ packet, respectively. The receive window size SHALL 2319 NOT be less than 4 and SHALL be less than 2^24. 2321 An FSP participant advertises current receive window size in the 2322 FREWS field. 2324 An FSP participant SHALL NOT send a packet whose sequence number is 2325 later than the value of the ExpectedSN field plus the advertised 2326 receive window size, where both value come from the very packet 2327 received with the latest sequence number. 2329 8.7. Congestion Control 2331 FSP supposes that end-to-end congestion control is provided by some 2332 shim layer, such as the congestion manager [RFC3124] between the 2333 "traditional" IP layer and the FSP transport layer. The shim layer 2334 is considered as a sub-layer of the network layer. Implementation of 2335 FSP MUST provide such shim layer if the network layer of the end node 2336 does not provide end-to-end congestion management service. 2338 FSP layer SHALL provide following information to the congestion 2339 manager as soon as the first packet on the fly was acknowledged by 2340 any mean, or a legitimate packet falling in the receive window with 2341 the ECE flag set is received: 2343 o The local interface number that the packet carrying the ECE signal 2344 is accepted. 2345 o The remote network prefix that the congestion information is meant 2346 to associate. Note that the aggregated host ID part is NOT 2347 included in the prefix. 2348 o The traffic class. For FSP it is bisected: MIND flag set or not. 2349 o Number of outstanding octets, including all of those in the 2350 payload AND the FSP headers. 2351 o The effective round trip time calculated in the most recent 2352 period. Note that retransmitted packets MUST be excluded on 2353 calculating the effective RTT. 2354 o Whether an ECN-Echo signal was received. The ECE flag of a 2355 legitimate packet falling in the receive window is the ECN-Echo 2356 signal. 2357 o Whether a sent packet with SRR flag set is acknowledged. 2359 The congestion manager SHOULD reduce the send rate if the FSP sender 2360 informed it that an ECN-Echo signal was received. 2362 The sender SHALL NOT inform the congestion manager to reduce the send 2363 rate again even if further packet with ECE flag set is received, 2364 until at least one sent packet with SRR flag set is acknowledged. 2366 A packet with ECE flag set received after the packet with SRR flag 2367 set is acknowledged SHOULD make the congestion manager reduce the 2368 send rate again. 2370 Retransmitted packet SHALL be subjected to send rate control at the 2371 underlying congestion management service sub-layer as well. 2373 Quota or other means to enforce fairness among various FSP 2374 connections SHOULD be provided directly to the ULA by the congestion 2375 management service. 2377 Requirement of an FSP congestion manager would be detailed in a 2378 separate document. 2380 8.8. On-the-Wire Compression 2382 FSP exploits the lossless compression algorithm as per [LZ4]. 2384 If the CPR flag of the first packet of a transmit transaction is set, 2385 compression is applied on the payload octet stream of the transaction 2386 transaction. 2388 When applying compression FSP divides source stream into multiple 2389 blocks. For this version of FSP length of each block is 128KiB 2390 (131072 octets), except the final block whose length may be less than 2391 or equal to 128KiB. The final block is the one that terminate the 2392 transmit transaction, i.e. which contains the last FSP packet of the 2393 transmit transaction. The last FSP packet of the transmit 2394 transaction has the EoT flag set. The "LZ4_compress_fast_continue" 2395 method SHALL be applied on each block. That is, data from previous 2396 compressed blocks are taken use for better compression ratio. 2398 When transferring the result data of compressing each block, the 2399 result data is prefixed with its length. The length is expressed by 2400 a 4-octets little-endian integer. 2402 On-the-wire compression of each transmit transactions is independent. 2403 It is the upper layer application that SHALL make agreement on which 2404 transmit transaction utilizes on-the-wire compression. 2406 8.9. Milk Like Payload and Minimal Delay Service 2408 An ordinary data flow is wine-like in the sense that the older data 2409 are more valuable. If it has to, data packet sent latest are dropped 2410 first. In the contrary, milk-like payload is that the newer data are 2411 more precious and outdated data packet can be discarded. 2413 When ULA is willing to accept incomplete message the peer of the 2414 underling FSP node SHALL set the MIND flag of the first PERSIST 2415 packet that starts the first transmit transaction, and set the MIND 2416 flag of every following PURE_DATA packet, while set the Traffic Class 2417 of the underlying IPv6 packet to some registered value. 2419 In the transmission path, any relaying middle box, be it router or 2420 switch, should reserve a reasonably short queue for the packet flow 2421 of such flow to minimize delay. 2423 When the receive buffer overflows the receiver discards the 2424 undelivered packet received first to free buffer space for the latest 2425 packet received. However it keeps order on delivering the packets to 2426 he ULA. ULA may choose to discard packets received earlier than some 2427 threshold. 2429 The receiver SHOULD NOT make any acknowledgement to the packet 2430 received with the MIND flag set. 2432 Minimal delay service is asymmetric in the sense that one 2433 transmission direction the data flow may be milk-like while in the 2434 reverse direction the data flow may be wine-like. 2436 A minimal delay service data flow is terminated by ULA via some out- 2437 of-band control mechanism. 2439 9. Graceful Shutdown 2441 One participant of an FSP connection MAY initiate graceful shutdown 2442 of the connection if and only if its peer has committed the most 2443 recent transmit transaction. 2445 By initiating graceful shutdown the participant tells its peer that 2446 current transmit transaction is to be committed as well. 2448 9.1. Initiation of Graceful Shutdown 2450 (RELEASE, FREWS, SN, ExpectedSN, ICC) 2452 An FSP end node MAY initiate graceful shutdown if it is in the 2453 PEER_COMMIT, COMMITTING2 or CLOSABLE state. It SHALL NOT initiate 2454 graceful shutdown if its peer has not committed current transmit 2455 transaction. 2457 Graceful shutdown is signaled to the remote end by sending a RELEASE 2458 command packet. The FSP end node SHALL migrate to the PRE_CLOSED 2459 state just before sending the RELEASE packet. 2461 9.2. Acknowledgment of Graceful Shutdown 2463 The RELEASE packet may be accepted in the COMMITTING, COMMITTED, 2464 COMMITTING2, CLOSABLE or PRE_CLOSED state. 2466 If the legitimate RELEASE packet is received in the COMMITTING or 2467 COMMITTED state, the FSP end node SHALL buffer the RELEASE packet, 2468 wait each packet of the last transmit transaction of its peer has 2469 been received, deliver all the buffered payload and then migrate to 2470 the SHUT_REQUESTED state. 2472 If the legitimate RELEASE packet is received in the COMMITTING2 or 2473 CLOSABLE state, the FSP end node SHALL migrate to the SHUT_REQUESTED 2474 state immediately. 2476 In either of the two cases the receiver of the RELEASE packet SHALL 2477 acknowledge the sender of the RELEASE packet with a legitimate out- 2478 of-band ACK_FLUSH packet. 2480 If the RELEASE packet is received in the PRE_CLOSED state, it is to 2481 finalize the graceful shutdown procedure. 2483 9.3. Finalization of Graceful Shutdown 2485 If either the legitimate RELEASE packet or the legitimate ACK_FLUSH 2486 packet is received in the PRE_CLOSED state the grace shutdown request 2487 is supposed to be acknowledged and the shutdown procedure SHALL be 2488 finalized by that the FSP end node migrates to the CLOSED state 2489 immediately. 2491 In SHUT_REQUESTED state the FSP node SHALL migrate to CLOSED state 2492 immediately on the Shutdown API called by the ULA. 2494 9.4. Retransmission of RELEASE Packet 2496 The FSP end node in the PRE_CLOSED state SHALL retransmit the RELEASE 2497 packet until it migrates to CLOSED state or it is timed out. 2499 As RELEASE is the in-band packet retransmission of the RELEASE packet 2500 is subjected to the normal retransmission rule. 2502 10. Mobility and Multi-home Support 2504 10.1. Heartbeat Signals 2506 FSP requires that the participants periodically send the heartbeat 2507 signals. 2509 The participant in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2510 COMMITING2 or CLOSABLE state MUST send the KEEP_ ALIVE packet as the 2511 heart-beat signal periodically to retain the connection in case that 2512 underlying IP address has changed. 2514 (KEEP_ALIVE, FREWS, SN, ExpectedSN, ICC, Sink Parameter, SNACK) 2516 (ACK_FLUSH, FREWS, SN, ExpectedSN, ICC, Sink Parameter, SNACK) 2518 Heartbeat signal packet is an out-of-band control packet. It does 2519 not carry payload. The packet is either KEEP_ALIVE or ACK_FLUSH, 2520 depending on whether the peer's transmission transactin has been 2521 committed. The sequence number of the packet SHALL be set to the 2522 latest sequence number of all of the packets that have been sent. 2524 Only the FSP node in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2525 COMMITING2 or CLOSABLE state MAY process the heartbeat signal. 2527 In this version of FSP the heartbeat period is arbitrarily set to 600 2528 seconds. 2530 The sequence number (SN) of the heartbeat signal packet MUST equal 2531 the latest sequence number of the legitimate packets that have been 2532 sent. 2534 The out-of-band serial number SHALL increase by one whenever a new 2535 hearbeat signal packet is sent. 2537 10.2. Active Address Change Signaling 2539 During communication process the FSP participant whose underlying IP 2540 address is changed SHOULD inform its peer such change by transmit a 2541 heartbeat signal packet so that the peer can retransmit the packets 2542 that were negatively acknowledged, if any. 2544 Such informing hearbeat signal packet SHALL be sent in the ACTIVE, 2545 COMMITTING, COMMITTED, PEER_COMMIT, COMMITING2 or CLOSABLE state. 2547 Informing heartbeat signal packet SHOULD be sent more frequently than 2548 a normal heartbeat signaling packet. 2550 For this version of FSP informing heartbeat signal packet SHALL be 2551 retransmitted every 4 RTT interval until the heuristic 2552 acknowledgement is received. 2554 10.3. Heuristic Remote Address Change Adaptation 2556 A participant of the FSP connection SHALL set the source address of 2557 the packet to transmit or retransmit to new IP address as soon as the 2558 near-end IPv4 address or IPv6 network prefix has changed. The ULTID 2559 field MUST remain the same. 2561 When a new packet with a later sequence number is received and the 2562 source IP address of the packet is found to be different with the 2563 preserved IP address of the remote end, the receiver SHOULD 2564 automatically update the preserved IP address of the remote end to 2565 the source IP address of the new packet, unless there is a Sink 2566 Parameter header in the packet. 2568 If the sequence number of the packet received is not the latest in 2569 the receive window the preserved IP address of the remote end SHALL 2570 NOT be updated even if the source address of the received packet has 2571 changed. 2573 10.4. Heuristic Address Change Acknowledgement 2575 The address change signaling heartbeat signal packet is supposed to 2576 be acknowledged if a packet targeted at the new IP address that the 2577 heartbeat signal packet has informed is received. 2579 10.5. NAT-traversal and Multihoming 2581 When FSP is implemented over UDP in the IPv4 network, each endpoint 2582 of the FSP connection is bound one and only one IPv4 address as soon 2583 as the connection is established. Each endpoint SHALL choose the 2584 source IPv4 address of the last packet received as the destination 2585 IPv4 address of the packet that it is to send later. By this mean 2586 FSP over UDP is NAT-friendly. 2588 When FSP is implemented over IPv6 as soon as the connection is 2589 established the IPv6 address may be changed dynamically, and one more 2590 alternate IP address may be added or removed dynamically for 2591 individual endpoint as well, provided that ULTID part keeps unchanged 2592 while the host IDs part of all IPv6 address of the endpoint are of 2593 the same value at any given moment. 2595 The sender may choose as the source IP address by selecting any 2596 network prefix that it has most-recently sent to its peer in the 2597 allowed address list field of the Sink Parameter header, joining with 2598 the host ID in the Sink Parameter header and the stable ULTID of the 2599 sender, and choose as the destination IP address by selecting any 2600 network prefix in the allowed address list field of the Sink 2601 Parameter header most-recently received from its peer, joining with 2602 the peer's host ID and the peer's ULTID. Thus multiple multi-homed 2603 paths MAY co-exist between the two FSP endpoints. 2605 10.6. Explicit Multi-home Informing 2607 If an FSP end node is configured with multiple IPv4 address other 2608 than the loop-back address, or with multiply global unicast IPv6 2609 address, it MAY advertise multiple underlying addresses to the remote 2610 end by put them in the addressable network prefix list of the Sink 2611 Parameter extension header. The Sink Parameter extension header may 2612 be carried in the CONNECT_REQUEST, ACK_CONNECT_REQ, NULCOMMIT, 2613 MULTIPLY or KEEP_ALIVE packet. 2615 Any participant of the communication SHALL NOT make discrimination of 2616 the source or destination IP address of any packet provided that both 2617 the source ULTID and the destination ULTID keep unchanged and the ICC 2618 field passes verification. 2620 11. Connection Multiplication 2622 Connection multiplication is the process of incarnating a new 2623 connection context by re-using security context of an established 2624 connection. 2626 11.1. Request to Multiply Connection 2628 (MULTIPLY, FREWS, SN, Salt, ICC [, Sink Parameter] [, payload]) 2630 The initiator's initial sequence number of the new connection is the 2631 sequence number of the packet that piggybacks the connection 2632 multiplication header. The ExpectedSN field of the normal packet 2633 store a Salt value instead. 2635 The FREWS field MUST be processed in the new connection context while 2636 the ICC MUST be calculated with the session key of the original 2637 connection. 2639 The new connection inherits the remaining key life. ULA SHOULD 2640 negotiate new session key and/or install new session key as soon as 2641 possible. 2643 The optional payload of the MULTIPLY packet MUST be processed in the 2644 new connection context. 2646 The MULTIPLY packet is an out-of-band command packet in the original 2647 connection context. 2649 11.2. Response to Connection Multiplication Request 2651 Case 1: (NULCOMMIT, FREWS, SN, ExpectedSN, ICC [, Sink Parameter]) 2653 Case 2: (PERSIST, FREWS, SN, ExpectedSN, ICC, Payload) 2655 Case 3: (RESET, Reason of Failure, SN, ExpectedSN, ICC) 2657 In all of these cases the ULTID of the remote-end MUST be the value 2658 of the initiator's ULTID in the connection multiplication header. 2660 It is REQUIRED that only a connection in the ESTABLISHED, COMMITTING, 2661 COMMITTED, PEER_COMMIT, COMMITTING2 or CLOSABLE state may accept a 2662 connection multiplication request. 2664 In case 1 the responder admits the multiplication request AND commit 2665 the transmit transaction, the new connection enters into the 2666 PEER_COMMIT or CLOSABLE state immediately, on request of ULA. 2668 In case 2 the responder admits the multiplication request and the new 2669 connection enters into the ESTABLISHED, PEER_COMMIT, COMMITTING or 2670 CLOSABLE state immediately, depending whether the ULA of the 2671 multiplication initiator has requested to commit the transmit 2672 transaction immediately and whether the ULA of the multiplication 2673 responder has requested to commit the transmit transaction in the 2674 reverse direction immediately. 2676 In case 3 the responder rejects the multiplication request. To 2677 defend against spoofing attack ICC MUST be valid. The value of the 2678 SN field MUST equal the value of the 'Expected SN' field of the 2679 requesting MULTIPLY packet while the value of ExpectedSN field MUST 2680 equal the value of the 'Sequence No' field. 2682 The new connection MUST derive new session key from the session key 2683 of the original connection where the out-of-band requesting MULTIPLY 2684 packet is received immediately. 2686 11.3. Duplicate Detection of Connection Multiplication Request 2688 Every time the responder of connection multiplication receives a 2689 MULTIPLY packet it MUST check the suggested responder's ULTID and the 2690 initiator's ULTID. 2692 The responder MUST reject the multiplication request if the suggested 2693 responder's ULTID equals the near-end ULTID of some connection and 2694 the remote-end ULTID of that connection does not equal the 2695 initiator's ULTID. 2697 The responder MUST recognize the MULTIPLY packet as a duplicate 2698 connection request if some connection matches the request and SHOULD 2699 response by retransmitting the head packet of the send queue of the 2700 matching connection, be it a PERSIST or a NULCOMMIT packet. A 2701 connection matches the MULTIPLY request if and only if the suggested 2702 responder's ULTID in the MULTIPLY packet equals the near-end ULTID of 2703 the connection and the initiator's ULTID equals the remote-end ULTID 2704 of the connection. 2706 11.4. Retransmission 2708 The initiating side SHALL retransmit the MULTIPLY packet if the 2709 corresponding PERSIST packet is not received in some limit time (by 2710 default 15 seconds). 2712 11.5. Key Derivation for Branch Connection 2714 Let K_out = BLAKE2(Km, [d] || Label || 0x00 || Context || L), where: 2716 * Km is the master key, 2717 * [d] is one octet of integer Depth. It is alike the KDF counter 2718 mode as the NIST SP800-108. For this version of FSP it is the 2719 fixed number 1, 2720 * Label is the fixed ASCII string "Multiply an FSP connection" 2721 which is 26-octet long for this version of FSP, 2722 * Context is concatenation of two 32-bit words idB and idR idB is 2723 the ULTID allocated for the branch connection in the context of 2724 the multiplication initiator. idB is byte-order neutral. idR is 2725 the receiver side ULTID of the original connection that is to 2726 accept the connection multiplication request. idI or idR is byte- 2727 order neutral. 2728 * L is a 32-bit network byte-order integer specifying the length in 2729 bits of the derived key K-out 2731 12. Timeouts and Abrupt Close 2733 12.1. Timeouts in End-to-End Negotiation 2735 Initially the initiator is in the CONNECT_BOOTSTRAP state. It 2736 migrates to the CONNECT_ AFFIRMING state after it received the 2737 legitimate ACK_INIT_CONNECT packet. Then it migrates to the 2738 PEER_COMMIT or CLOSABLE state after it received the legitimate 2739 ACK_CONNECT _REQ packet, depending on the hint of ULA. 2741 The responder incarnates a new connection context which is initially 2742 in the CHALLENGING state after accepting a legitimate Connect Request 2743 packet. Then it migrates to the COMMITTING or CLOSABLE state, 2744 depending on the packet received from its peer. 2746 If the initiator or the responder is unable to migrate to a new state 2747 in some limit time (by default 60 seconds, except in LISTENING state) 2748 it aborts the connection by recycling the connection context. 2750 12.2. Timeouts in Multiply 2752 Initially the initiating side of Connection Multiplication is in the 2753 CLONING state. It migrates to the ACTIVE, COMMITTED, PEER_COMMIT or 2754 CLOSABLE state after it received the legitimate PERSIST packet. 2755 Which state to migrated depends on the EoT flag of the initiating 2756 MULTIPLY packet and the responding PERSIST packet. 2758 If the initiating side is unable to migrate to a new state in some 2759 limit time (by default 60 seconds) it aborts multiplication by 2760 recycling the new connection context. 2762 12.3. Timeout of Transmit Transaction Commitment 2764 The FSP node MUST abort the connection if the time of no packet 2765 having arrived has exceed certain limit in the COMMITTING or 2766 COMMITTING2 state. 2768 In this FSP version, timeout of transmit transaction commitment is 2769 set to 5 minutes. 2771 12.4. Timeout of Graceful Shutdown 2773 It simply migrates to the NON_EXISTENT pseudo-state if timeout in the 2774 PRE_CLOSED state. 2776 In this FSP version, timeout of Graceful Shutdown is set to 1 minute. 2778 12.5. Idle Timeout 2780 If one participant has not received any packet nor has it sent any 2781 packet in some limit time, it MUST be abruptly closed. 2783 In this FSP version the time limit, or the idle timeout, is set to 4 2784 hours. 2786 12.6. Session Key Timeout 2788 For this FSP version if a secret key is applied for more than 2^30 2789 times the FSP node MUST abruptly closed instantly. 2791 12.7. Abrupt Close 2793 An FSP node abruptly shutdown a session by sending a RESET packet and 2794 release all of the resource occupied by the the session immediately. 2796 (RESET, Reason of Failure, SN, ExpectedSN, ICC) 2798 13. Issues for Further Study 2800 13.1. Resolution of ULTID in DNS 2802 There are two patterns of IP address resolution in FSP: the DNS- 2803 compatible pattern and the proxy pattern. The former pattern relies 2804 on some name service to resolve the IP address of the responder for 2805 the initiator before they exchange end-to-end negotiation packets. 2807 In the DNS-compatible pattern, the responder side of the FSP 2808 participants registered its address identifier, such as 'domain name' 2809 in some name service such as DNS [RFC1034][RFC1035], according to 2810 some pre-agreement at first. The initiator resolves the current IP 2811 address of the responder by consulting the name service, such as 2812 looking after the A or AAAA record [RFC3596] of the domain name in 2813 DNS. 2815 If UDP over IPv4 is exploited as the under layer data packet delivery 2816 service the port number of the responder is firstly resolved just 2817 alike normal network application such as HTTP. Then it is extended 2818 to 32-bit ULTID, and ULTIDs of FSP can be considered as the superset 2819 of TCP port numbers. 2821 If the string representation of IPv4/IPv6 address is applied directly 2822 as the peer's address identifier instead of the domain name there is 2823 no need for some real address resolution. But from the API caller's 2824 point of view it is a DNS-compatible mode address resolution. 2826 13.2. Proxy Pattern for Syndicated Name Resolution 2828 The proxy pattern of IP address resolution in FSP is to embed the 2829 address resolution information in the connection initialization 2830 packets and is designed to work in FSP over IPv6 mode only. 2832 In IPv6 network the rightmost 32 bits of the IPv6 address directly 2833 maps to the ULTID so FSP does not need additional multiplexing 2834 mechanism such as port number. And it needs not consult SRV record 2835 or look for some entry in some 'services' file. 2837 If the INIT_CONNECT packet carries the responder's host name it MUST 2838 take the link-local interface address as the source IPv6 address and 2839 the default link-local gateway address, FE80::1, as the destination 2840 IPv6 address no matter whether the global unicast IP address of the 2841 default gateway is configured. In such scenario the link-local 2842 gateway MUST be able to resolute the responder's host name to its 2843 global unicast IPv6 address, and the gateway MUST be able to map the 2844 initiator's link local address to its global unicast IPv6 address. 2846 If the gateway that relays the INIT_CONNECT packet finds that the 2847 responder is on the same link-local network with the initiator it 2848 SHALL change the source and the destination IP addresses of the 2849 INIT_CONNECT packet to the link-local IP addresses of the initiator 2850 and the responder respectively, and relay the packet onto the same 2851 link-local network. 2853 On receiving the INIT_CONNECT packet that carries the responder's 2854 host name the link-local gateway MUST resolute the responder's global 2855 unicast IPv6 address and map the initiator's global unicast IPv6 2856 address, and replace the destination and source address of the 2857 INIT_CONNECT packet respectively, unless it finds that the initiator 2858 and the responder are on the same link-local network, where the 2859 gateway SHALL process the packet as stated in the previous statement. 2861 13.3. Asymmetric Transmission 2863 If there is one participant whose receive interface is not the same 2864 as the send interface the participant is called an asymmetric- 2865 transmission node. 2867 Asymmetric transmission itself is asymmetric in the sense that one 2868 participant may be asymmetric-transmission node while its peer is a 2869 normal node that the send interface is the same receive interface. 2871 An end node is asymmetric-transmission if it received an 2872 ACK_CONNECT_REQ packet, NULCOMMIT or PERSIST packet whose source IP 2873 address that the network interface accepting the packets reported is 2874 not in the allowed IP address list in the Sink Parameter header of 2875 the packet. 2877 For an asymmetric-transmission remote end, the near end cannot rely 2878 on automatic IP address change detection. Instead IP address change 2879 notification mechanism shall be utilized. 2881 However for this version of FSP asymmetric transmission support is 2882 optional. 2884 14. Security Considerations 2886 14.1. Deny of Service Attack 2888 FSP is designed to mitigate effect of DoS attack by exploiting 2889 Cookie. 2891 However, resistance against distributed DoS attack relies on external 2892 mechanism. 2894 14.2. Replay Attack 2896 In-band sequence number and out-of-band sequence number are exploited 2897 to resist against replay attack. 2899 14.3. Passive Attacks 2901 AEAD MAY be exploited by the ULA to protect it against passive 2902 attacks such as eavesdropping, gaining advantage by analyzing the 2903 data sent. 2905 MAC only service MAY also be utilized. Together with application 2906 layer stream-mode encryption it protects the ULA against passive 2907 attacks as well. 2909 14.4. Masquerade Attack 2911 Both AEAD and MAC only service may be exploited to protect the 2912 endpoints against masquerade attack. 2914 If proxy pattern for syndicated name resolution is exploited for FSP 2915 over IPv6, secure neighbor discovery [RFC3971] SHOULD be applied 2916 instead of common neighbor discovery whenever it is feasible. 2918 14.5. Active Man-In-The-Middle Attack 2920 The ULA SHALL take account to protect itself against MITM attack when 2921 making client authentication and key establishment. 2923 14.6. Privacy Concerns 2925 It is beneficial for privacy protection that the ULTID of each 2926 endpoints of an FSP connection is generated randomly [RFC7721]. 2928 15. IANA Considerations 2930 It should be requested that the port number registered for UDP 2931 packets encapsulating FSP in the IPv4 network. The port number 18003 2932 is exploited in the concept prototype implementation. The number is 2933 the decimal presentation of ASCII codes of the character 'F' ('x46') 2934 and 'S' ('x53') concatenated in network byte order. 2936 It should be requested that the 'Next Header'/protocol number is 2937 assigned for FSP over IPv6. Decimal number 144 is exploited in the 2938 concept prototype implementation. 2940 16. References 2942 16.1. Normative References 2944 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 2946 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 2947 Cartridges - DLT1 Format Standard, Annex B", December 2948 1992. 2950 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 2951 Galois/Counter Mode (GCM) and GMAC", November 2007. 2953 [LZ4] "LZ4: Extremely Fast Compression algorithm", 2954 . 2956 [OSI_RM] ISO and IEC, "Information technology-Open Systems 2957 Interconnection - Basic Reference Model: The Basic Model", 2958 November 1994. 2960 [R01] Rogaway, P., "Authenticated encryption with Associated 2961 Data", 2002. 2963 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2964 Communication Layers", STD 3, RFC 1122, 2965 DOI 10.17487/RFC1122, October 1989, 2966 . 2968 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2969 Requirement Levels", BCP 14, RFC 2119, 2970 DOI 10.17487/RFC2119, March 1997, 2971 . 2973 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 2974 Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, 2975 . 2977 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 2978 RFC 3124, DOI 10.17487/RFC3124, June 2001, 2979 . 2981 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2982 of Explicit Congestion Notification (ECN) to IP", 2983 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2984 . 2986 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2987 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2988 2003, . 2990 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2991 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2992 2006, . 2994 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2995 Key Derivation Function (HKDF)", RFC 5869, 2996 DOI 10.17487/RFC5869, May 2010, 2997 . 2999 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 3000 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 3001 DOI 10.17487/RFC6887, April 2013, 3002 . 3004 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 3005 Cryptographic Hash and Message Authentication Code (MAC)", 3006 RFC 7693, DOI 10.17487/RFC7693, November 2015, 3007 . 3009 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 3010 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 3011 March 2017, . 3013 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3014 (IPv6) Specification", STD 86, RFC 8200, 3015 DOI 10.17487/RFC8200, July 2017, 3016 . 3018 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 3019 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 3020 . 3022 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 3023 1981. 3025 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3026 August 1980. 3028 [STD7] Postel, J., "Transmission Control Protocol", STD 7, 3029 RFC 793, September 1981. 3031 16.2. Informative References 3033 [Gao2002] Gao, J., "Fuzzy-layering and its suggestion", IETF Mail 3034 Archive, September 2002, 3035 . 3038 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 3039 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 3040 . 3042 [RFC1035] Mockapetris, P., "Domain names - implementation and 3043 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3044 November 1987, . 3046 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3047 Address Translator (Traditional NAT)", RFC 3022, 3048 DOI 10.17487/RFC3022, January 2001, 3049 . 3051 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 3052 "DNS Extensions to Support IP Version 6", STD 88, 3053 RFC 3596, DOI 10.17487/RFC3596, October 2003, 3054 . 3056 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 3057 "SEcure Neighbor Discovery (SEND)", RFC 3971, 3058 DOI 10.17487/RFC3971, March 2005, 3059 . 3061 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3062 "Randomness Requirements for Security", BCP 106, RFC 4086, 3063 DOI 10.17487/RFC4086, June 2005, 3064 . 3066 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 3067 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 3068 . 3070 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3071 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3072 DOI 10.17487/RFC4861, September 2007, 3073 . 3075 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3076 Address Autoconfiguration", RFC 4862, 3077 DOI 10.17487/RFC4862, September 2007, 3078 . 3080 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 3081 Model: The Relationship between Links and Subnet 3082 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 3083 . 3085 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 3086 Assignment to End Sites", BCP 157, RFC 6177, 3087 DOI 10.17487/RFC6177, March 2011, 3088 . 3090 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3091 "Computing TCP's Retransmission Timer", RFC 6298, 3092 DOI 10.17487/RFC6298, June 2011, 3093 . 3095 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 3096 the IPv6 Prefix Used for IPv6 Address Synthesis", 3097 RFC 7050, DOI 10.17487/RFC7050, November 2013, 3098 . 3100 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 3101 Considerations for IPv6 Address Generation Mechanisms", 3102 RFC 7721, DOI 10.17487/RFC7721, March 2016, 3103 . 3105 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 3106 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 3107 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3108 RFC 8415, DOI 10.17487/RFC8415, November 2018, 3109 . 3111 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 3112 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 3113 January 2019, . 3115 Appendix A. Acknowledgements 3117 Author's Address 3119 Jun-an Gao 3120 Beijing Capital Highway Development Group Co.,Ltd. 3121 Shoufa Plaza-A, Liuliqiao South, Fengtai 3122 Beijing 3123 People's Republic of China 3125 Email: jagao@outlook.com