idnits 2.17.1 draft-gao-flexible-session-protocol-05.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 -- The document date (October 17, 2020) is 1288 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 (~~), 1 warning (==), 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 October 17, 2020 5 Expires: April 20, 2021 7 Flexible Session Protocol 8 draft-gao-flexible-session-protocol-05 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 Ubiquitous authenticated encryption 21 o 0-RTT multiplication of connections 22 o On-the-wire compression 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 April 20, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 Flexible Session Protocol is a connection-oriented transport layer 59 provides mobility, multi-homing and multi-path support by introducing 60 the concept of 'upper layer thread ID' (ULTID), which was firstly 61 suggested in [Gao2002]. 63 An integrity check code (ICC) field associated with the ULTID is 64 designed in the FSP header to protect authenticity and optionally 65 privacy of the FSP packet. An FSP packet is assumed to originate 66 from the same source if the ICC value associated with certain 67 destination ULTID passes validation, regardless of the source or 68 destination address of the packet in the underlying layer. 70 ICC is either calculated by [CRC64] which protects FSP against 71 unintended modification, or a cryptographic hash function, or 72 cryptographically calculated with some Authenticated Encryption with 73 Additional Data [R01] algorithm, each of which requires a shared 74 secret key. 76 In the former case a weak key meant to obfuscate the CRC64 checksum 77 is agreed by the FSP participants. In the latter two cases, the 78 shared secret key is assumed to be installed by the upper layer 79 application (ULA). 81 The ULTID is assigned roughly the same semantics as the Security 82 Parameter Index (SPI) in MOBIKE [RFC4555]. Either the weak key or 83 the shared secret key is indexed by the source or destination ULTID 84 in the local context of the sender or the receiver, respectively. 86 FSP facilitates secret key installation by introducing the concept of 87 transmit transaction. Mechanism of transmit transaction also 88 provides the session-connection synchronization service to the upper 89 layer. 91 FSP is a transport layer protocol as specified in [RFC1122], provides 92 services alike TCP [STD5] to ULA, with session layer features as 93 suggested in [OSI_RM], most noticeably session-connection 94 synchronization. 96 1.1. Features 98 1.1.1. Transport Layer Mobility Support 100 FSP is meant to be transport layer protocol that keeps the IP address 101 as the routing locater but keeps it from being the key constituent of 102 the FSP identifier or any upper layer protocol built upon FSP. It is 103 a solution to avoid the routing scalability problem. 105 The dominating transport layer protocols, TCP and UDP that take use 106 of the IP address to identifying the end node, introduce the 107 controversial role of IP address both as the identifier and as the 108 routing locater. We believe such a problem should be eventually 109 solved at its root. 111 1.1.2. Ubiquitous Authenticated Encryption 113 By applying authenticated encryption with additional data on each FSP 114 packet, FSP provides both authentication of message origin and 115 privacy protection service to the upper layer application. 117 1.1.3. Transmit Transaction 119 FSP introduces the concept of transmit transaction, which makes it 120 able to mark end of message inherently at the transport layer, 121 effectively eliminate the requirement of message delimiters at the 122 application layer. Besides, it still provides byte-stream-oriented 123 transfer service to its upper layer application which is familiar and 124 friendly to application developers. 126 1.1.4. 0-RTT Multiplication of Connections 128 With FSP the upper layer application is able to fork branch 129 connections of an established connection in zero round-trip mode, 130 without compromising security. 132 1.1.5. On-the-wire Compression 134 FSP provides on-the-wire compression service through the on-the-wire 135 compression and fragmentation function module. 137 1.2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 In this document, these words will appear with that interpretation 144 only when in ALL CAPS. Lower case uses of these words are not to be 145 interpreted as carrying significance described in RFC 2119. 147 1.3. Conventions 149 Conventions in describing the finite state machine (FSM) of FSP are: 151 ESTABLISHED The string of alphabetic characters designates 152 the name of the state 153 [API: Reset] Upper Layer Application Programming Interface 154 Call 155 {Notify} Call back/notify the upper layer application 156 {new context} Additional action before or after state 157 transition 158 [Send Send some FSP packet 159 OPCODE_OF_FSP_PACKET] 160 [Retransmit Retransmit some FSP packet 161 OPCODE_OF_FSP_PACKET] 162 {On transient state Timed-out event 163 Timeout} 164 {&& additional Together with some additional condition 165 condition} 166 --> state transition 167 |-- branch 169 2. Abbreviations and Idioms 171 o Connection 172 An FSP connection is the binding of two network nodes established 173 through some end-to-end negotiation process. It is identified by 174 the ULTID in the local context of each network node, respectively. 176 o EoT 177 End of Transaction. A transmit transaction is said to reach EoT 178 if the EoT flag is set in a legitimate PURE_DATA, PERSIST, 179 NULCOMMIT or MULTIPLY packet. We said that the packet terminates 180 the transmit transaction if the EoT flag is set. 182 An FSP end node SHALL NOT send further data if it has initiated 183 EoT of its transmit direction unless a particular ACK_FLUSH packet 184 is received. The particular ACK_FLUSH packet MUST acknowledge not 185 only the packet with the EoT flag set but all of the packets sent 186 before the packet as well. 188 EoT, i.e. termination of transmit transaction is unilateral. 190 o FREWS 191 The Flags and advertised REceive Window Size. It is the 32-bit 192 combined word next to the ICC field in the normal FSP fixed 193 header. 195 o ICC 196 The Identity Check Code. It is a 64-bit value that depends on 197 both the session key and all of the headers of the FSP packet to 198 include the ICC, calculated with the same algorithm in the context 199 of each FSP participant. 201 Only a packet with correct ICC can be accepted by any FSP 202 participant as soon as the connection has been established. 204 Initially CRC64 is exploited to make a checksum that weekly 205 protects the FSP packet against unintentional modification. The 206 checksum is obfuscated with the initial session key to get the 207 ICC. After the ULA installed the long-term session key either 208 some cryptographic hash function or some Authenticated Encryption 209 with Additional Data algorithm shall be applied to obtain or check 210 the ICC. 212 o Session 213 An FSP session is the transport-layer association of two network 214 nodes. A full FSP session consists of one connection that was 215 established from scratch and all of its branches. 217 However for this version of FSP specification the idioms session 218 and connection are interchangeable if not explicitly specified. 220 o Session Key 221 The session key is a bit string of at least 128 bits that means to 222 resist against masquerade attack. It is either initiated during 223 the end-to-end negotiation phase or installed by the ULA after the 224 FSP connection is established. 226 The session key installed by the ULA is called the long-term 227 session key. Here long-term means that the key could be used 228 until the packet sequence space is exhausted. The packet sequence 229 space is exhausted if the number of packets that use the same key 230 reaches or exceeds 2,147,483,647(2^31-1). 232 o SN 233 The Sequence Number. It is the unsigned 32-bit integer number 234 assigned to every FSP packet except the preliminary packets. 236 Difference of two sequence number is represented by a 32-bit 237 signed integer. If the result of SN B subtracting SN A is greater 238 than zero, we say that B is greater than A and the packet of the 239 sequence number B is later than the packet of the sequence number 240 A, although the unsigned integer representation of B may be far 241 less that A. Consequently, as the result of A subtracting B is 242 less than zero, we say that A is less than B and the packet of the 243 sequence number A is earlier than the packet of the sequence 244 number A. 246 o Transmit Transaction 247 A transmit transaction in FSP is a sequence of FSP packets that 248 were sent and marked by the ULA as one continuous stream where all 249 packets in the stream must be acknowledged before any further 250 packet is allowed to be sent. 252 A ACK_CONNECT_REQ, PERSIST or MULTIPLY packet always starts a new 253 transmit transaction. 255 Any packet with EoT flag set, including the NULCOMMIT packet which 256 is payload-less, terminates the transmit transaction. 258 The NULCOMMIT both starts and terminates a payload-less transmit 259 transaction when it is exploited to acknowledge the 260 ACK_CONNECT_REQ or MULTIPLY packet. 262 o ULA 263 The Upper Layer Application. 265 o ULTID 266 The Upper Layer Thread Identifier (ULTID). It is a 32-bit word 267 that was allocated by particular network end node of an FSP 268 connection and is unique in the local context of the network end 269 node. 271 Theoretically all of the ULAs of a network end node MAY establish 272 up to 2^31-1 FSP connections totally. Each connection MUST have a 273 unique thread identifier (ULTID) assigned in the local context of 274 the network end node. 276 A session or connection in FSP does not require a global ID. 278 3. Key Mechanisms 280 3.1. Underlying Layer Services Required 282 FSP requires that the underlying layer provides packet delivery 283 service. In addition FSP supposes that the underlying layer has 284 following features: 286 3.1.1. Handling of High Mobility 288 Here high mobility refers to scenarios such as high-speed train or 289 airplane. 291 FSP solves somewhat coarse-grain or low-speed mobility problem. 292 Fine-grain or high-speed mobility is left to the underlying physical 293 network. To make mobility support work effectively it is assumed 294 that one end-node MUST keep its lower layer address reasonably stable 295 while the other end-node SHOULD NOT change its lower layer address 296 too frequently. 298 Here the meaning of physical network conforms to what was depicted in 299 [RFC1122]. 301 3.1.2. Network Address Change Notification 303 Network address change notification is mandatory only in the IPv6 304 network. 306 We split the IPv6 address of the IPv6 packet underlying FSP into 307 three parts. The leftmost 64-bit long word is the network prefix, 308 which SHOULD be the unique IPv6 prefix assigned to the host 309 [RFC8273]. The centermost 32-bit word is called the aggregation host 310 ID, and the rightmost 32-bit word is the ULTID. While the ULTID MUST 311 be kept stable even during the life of an FSP session, the network 312 prefix part MAY change when an endpoint is roaming. The aggregation 313 host ID may change as well. The network prefix part together with 314 the aggregation host ID part act as the traditional routing locator 315 at the network layer. 317 It is supposed that the network layer immediately notifies the FSP 318 layer if the network prefix or aggregation host ID changes. 320 An participant of an FSP connection SHALL immediately notify its peer 321 whenever its underlying IPv6 address is changed with a KEEP_ALIVE 322 packet. The peer shall send packet to the participant that has 323 notified the address change with the new address. 325 It is supposed that the packet to inform the remote end to update the 326 lower layer address association could reach its destination in a 327 satisfying success rate. 329 3.1.3. Network Congestion Control 331 Network layer congestion control is mandatory only in future IPv6 332 network. 334 It is supposed that end-to-end congestion control is provided at some 335 sub-layer of the network layer. Implementation of FSP MUST include a 336 congestion manager [RFC3124] if such sub-layer service of the network 337 layer is not provided. 339 3.2. Identifying Connection by Local ULTID 341 Each FSP connection prepares a pair of ULTIDs. An ULTID uniquely 342 indexes a connection in the local context of an FSP end node. An FSP 343 end node relies neither source IP address nor destination IP address, 344 except the ULTID part of the near end's IPv6 address to identify an 345 FSP connection. 347 Each ULTID is allocated in the local context of the two FSP 348 participant respectively. The source ULTID and the destination ULTID 349 of an FSP packet usually differ in their values. However, the secret 350 keys indexed in the local contexts of the two end-points must have 351 the same value. 353 3.3. Defending Against Connection Hijacking with ICC 355 An integrity check code (ICC) field associated with the ULTID is 356 designed in the FSP header to protect authenticity and optionally 357 privacy of the FSP packet. An FSP packet is assumed to originate 358 from the same source if the ICC value associated with certain 359 destination ULTID passes validation, regardless of the source or 360 destination address in the underlying layer. 362 On initiating FSP takes use of [CRC64] to make checksum of the FSP 363 packet to protect it against unintentional modification. The 364 checksum is taken as the ICC. 366 After the ULA has installed a shared secret key, value of ICC is 367 calculated by firstly getting the secret key associated indexed by 368 the local ULTID, then calculating the tag value with the AES-GCM 369 [GCM] authenticated encryption with additional data algorithm , or 370 calculating the message authentication code with the BLAKE2 algorithm 371 [RFC7693]. 373 3.4. Synchronizing Key Installation with Transmit Transaction 375 It is proposed that it is the ULA to do key establishment and/or end- 376 point user-agent authentication while the FSP layer provides 377 authenticated, optionally encrypted data transfer service. 379 A dedicate application program interface (API) is designed for the 380 ULA to install the secret key established by the ULA participants. 382 FSP facilitates shared secret key installation by introducing the 383 concept of transmit transaction. 385 A transmit transaction of FSP is a sequence of FSP packets that were 386 sent and requested by ULA as one continuous stream where all packets 387 in the stream MUST be acknowledged before any further packet is 388 allowed to be sent. 390 A flag called 'End of Transaction' (EoT) is designed in the FSP 391 header. When it is set, it marks that the transmit transaction in 392 the direction from the source of the FSP packet towards the 393 destination of the FSP packet is 'committed'. 395 As the FSP node knows when a transmit transaction at FSP layer is 396 terminated there is no ambiguity which packet is to be applied with 397 the new session key when the key is installed by ULA through the 398 dedicated API. 400 3.5. 0-RTT Connection Multiplication with OOB Packet 402 An FSP connection MAY be multiplied to get a branch or branches of 403 the connection. Multiplication of a connection is protected by 404 deriving new session key from the original security context of the 405 connection. 407 The packet that carries the command to multiply an established FSP 408 connection MUST be sent from a new allocated local ULTID towards the 409 destination ULTID of the original connection. It is an out-of-band 410 (OOB) packet in the context of the original connection and it MUST be 411 cryptographically protected by the secret key of the original 412 connection. The packet MAY carry payload. 414 The receiver of the packet MUST allocate a new local ULTID, accept 415 the optional payload in the new context associated with the new 416 ULTID, derive a new secret key from the secret key of the original 417 connection, and responds from the new context. The response MAY 418 carry payload. 420 The very first response packet MUST be protected by the new secret 421 key. The sender of the multiply command packet MUST automatically 422 inaugurate the same secret key, derived from the secret key of the 423 same original connection. And it MUST treat the response packet as 424 though a transmit transaction had been committed by the responder, 425 i.e. authenticity of the response packet is verified with the new 426 secret key. 428 Thus the branch connection of a new pair of ULTIDs is established 429 with zero round-trip overhead. This mechanism may be exploited to 430 provide expedited data transfer or parallel data transfer service. 432 4. Packet Structure 434 4.1. FSP over UDP/IPv4 436 In this version of FSP, when FSP is implemented in the IPv4 network, 437 every FSP packet MUST be encapsulated in a UDP [STD6] datagram. The 438 UDP datagram encapsulated the FSP packet SHALL have the checksum 439 disabled (i.e. set its value to 0) [RFC8085]. The Source and the 440 destination ULTIDs are put at the leading position of the UDP 441 payload. FSP fixed header, optional extension headers and FSP 442 payload follow the ULTIDs: 444 0 15 16 31 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Source Port | Destination Port | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Length | 0 | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Source Upper Layer Thread ID | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Destination Upper Layer Thread ID | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | 455 ~ FSP Fix Header ~ 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 ~ Optional FSP Extension Headers ~ 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 ~ ~ 461 ~ Optional FSP payload ~ 462 ~ ~ 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 4.2. FSP over IPv6 467 When FSP is implemented over IPv6 [RFC8200], the ULTID part is 468 embedded in the IPv6 address. FSP fixed header follows the IPv6 469 headers: 471 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 472 ~ IPv6 Header: ~ 473 0 15 16 31 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |Version| Traffic Class | Flow Label | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Payload Length | Next Header | Hop Limit | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | | 480 + Source Network Prefix + 481 | | 482 + Source Address ----------------------------+ 483 | Source Aggregation Host ID | 484 + ----------------------------+ 485 | Source Upper Layer Thread ID | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | | 488 + Destination Network Prefix + 489 | | 490 + Destination Address ---------------------------------+ 491 | Destination Aggregation Host ID | 492 + ---------------------------------+ 493 | Destination Upper Layer Thread ID | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 ~ ~ 496 ~ Optional IPv6 Headers ~ 497 ~ ~ 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 ~ FSP Fix Header ~ 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 ~ Optional FSP Extension Headers ~ 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 ~ ~ 506 ~ Optional FSP payload ~ 507 ~ ~ 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 o Network Prefix 511 The leftmost 64-bit of the IPv6 address which MAY and usually do 512 have different value at the difference interface of an IPv6 end- 513 node. 514 o Aggregation Host ID 515 The left 32-bit part of the rightmost 64-bit long word of the IPv6 516 address. All of the aggregation host ID parts of an IPv6 end- 517 node's IPv6 addresses MUST have the same value for this version of 518 FSP. 520 Network prefix and aggregation host ID make the IPv6 prefix part of 521 the IPv6 address under the context of FSP. It is assumed that there 522 is a unique IPv6 prefix per host [RFC8273]. 524 RFCs related to IPv6 address configuration such as ND for IPv6 525 [RFC4861], SLAAC [RFC4862], 'IPv6 Subnet Model' [RFC5942], 'IPv6 526 Address Assignment to End Sites' [RFC6177], 'Discovery of the IPv6 527 Prefix Used for IPv6 Address Synthesis' [RFC7050], DHCP [RFC8415] and 528 'IPv6 Node Requirements' [RFC8504] would be reviewed in separate 529 documents. 531 4.3. Generic FSP Header 533 FSP headers include the fixed header and the extension headers. A 534 general fixed header consists of a 32-bit FSP Header Signature and 535 20-byte operation-code specific fields. An extension header consists 536 of a 32-bit Code-Mark-Length Prefix and the operation-code specific 537 content. The length of the extension header content may be variable, 538 provided that the tail of the full extension header align on 64-bit 539 boundary. 541 Integers in the FSP fix header are transmitted in network byte order. 542 Otherwise, integers in the FSP headers are of little-endian. 544 0 31 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Header Signature | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 ~ ~ 549 ~ Operation Code Specific Fields ~ 550 ~ ~ 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 4.4. FSP Header Signature and Code-Mark-Length Prefix 555 0 7 8 15 16 31 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Operation Code| Major | Offset | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 0 7 8 15 16 31 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Operation Code| Mark | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 4.4.1. Operation Code 567 The operation code is an octet that stores the code of the command 568 which indicates the function of the FSP packet, or specifies the type 569 of some extension header. 571 +------------------+--------+---------------------------------------+ 572 | Synonym | CodeC2 | Meaning | 573 +------------------+--------+---------------------------------------+ 574 | INIT_CONNECT | 1 | Initialize Connection | 575 | | | | 576 | ACK_INIT_CONNECT | 2 | Acknowledge Initialization of | 577 | | | Connection | 578 | | | | 579 | CONNECT_REQUEST | 3 | Formally Request to Connect | 580 | | | | 581 | ACK_CONNECT_REQ | 4 | Acknowledge the Connection Request | 582 | | | | 583 | RESET | 5 | Reset a connection. Abort the | 584 | | | connection, or refuse to | 585 | | | establish the connection at the very | 586 | | | beginning. | 587 | | | | 588 | NULCOMMIT | 6 | Commit without payload. The NULCOMMIT | 589 | | | packet MUST be payload- | 590 | | | less, and its EoT flag MUST be set. | 591 | | | It MAY carry optional | 592 | | | extension headers. It always consumes | 593 | | | a slot of the send sequence | 594 | | | space. It is to commit current | 595 | | | transmit transaction, otherwise the | 596 | | | NULCOMMIT packet itself SHALL just be | 597 | | | skipped when delivering data | 598 | | | to ULA. | 599 | | | | 600 | KEEP_ALIVE | 7 | Keep the peer alive. It is an out-of- | 601 | | | band control packet acting | 602 | | | as the heart-beating signal. An out- | 603 | | | of-band control packet does | 604 | | | not consume send sequence space | 605 | | | itself. FSP takes use of the | 606 | | | KEEP_ALIVE packet to inform the peer | 607 | | | about the change of the | 608 | | | source IP addresses. Besides, when | 609 | | | the MIND flag is set, the | 610 | | | KEEP_ALIVE packet is meant to tell | 611 | | | the peer which packets should | 612 | | | be retransmitted. If the End of | 613 | | | Transaction flag of the KEEP_ | 614 | | | ALIVE packet is set it is meant to | 615 | | | forcefully commit current | 616 | | | transmit transaction of the sender of | 617 | | | the KEEP_ALIVE packet. | 618 | | | | 619 | PERSIST | 8 | Make a connection persistent. It is | 620 | | | meant to start a new | 621 | | | transmit transaction after a | 622 | | | connection migrated to CLOSABLE | 623 | | | state. It can also acknowledge | 624 | | | ACK_CONNECT_REQ or MULTIPLY. It | 625 | | | MUST carry payload. It always | 626 | | | consumes a slot of the send sequence | 627 | | | space. | 628 | | | | 629 | PURE_DATA | 9 | Pure Data. It does not carry any | 630 | | | optional header. | 631 | | | | 632 | ACK_FLUSH | 10 | ACKnowledge to remote end's | 633 | | | commitment (FLUSHing) of transmit | 634 | | | transaction. It is an out-of-band | 635 | | | control packet like KEEP_ALIVE. | 636 | | | It is sent instantly on having every | 637 | | | packet of the last transmit | 638 | | | transaction received, meant to make | 639 | | | acknowledgment to the remote | 640 | | | end and let the remote end stop | 641 | | | sending heart-beat signals. | 642 | | | | 643 | RELEASE | 11 | Release the connection. RELEASE | 644 | | | packet does not carry payload | 645 | | | but it always consumes a slot of the | 646 | | | send sequence space. Only | 647 | | | when each peer has committed current | 648 | | | transmit transaction may a | 649 | | | RELEASE packet sent under the request | 650 | | | of the ULA. | 651 | | | | 652 | MULTIPLY | 12 | Multiply the connection. It is sent | 653 | | | in the context of the | 654 | | | original connection and may carry | 655 | | | payload and/or optional headers | 656 | | | as an out-of-band packet. | 657 | | | | 658 | PEER_SUBNETS | 17 | Tell the remote end how to address | 659 | | | the sender of the packet in | 660 | | | the reverse direction. It is the code | 661 | | | of the Sink Parameter | 662 | | | extension header. | 663 | | | | 664 | SELECTIVE_NACK | 18 | Tell the remote end to retransmit the | 665 | | | packets that were | 666 | | | negatively acknowledged. It is the | 667 | | | code of the Selective Negative | 668 | | | Acknowledgment extension header. | 669 +------------------+--------+---------------------------------------+ 671 4.4.2. Major 673 It is an octet that states current FSP major version. For this FSP 674 version it MUST be 0. 676 It is not mandatory for different major versions of FSP to be 677 compatible. 679 4.4.3. Mark 681 It is an octet that marks current minor version of the extension 682 header, under the major FSP version specified in the fixed header, 683 and/or serves as the flag, depending on the type of the extension 684 header. 686 It is mandatory for implementations to be compatible with different 687 minor versions of FSP extension header under the same major FSP 688 version. 690 It is not mandatory for minor versions of FSP extension header under 691 the different major FSP version to be compatible, even if the minor 692 versions happen to be the same. 694 4.4.4. Offset 696 The offset field is a 16-bit unsigned integer that specifies the 697 offset of the first octet of the payload, starting from the begin of 698 the FSP fixed header. If its value equals the size of the fixed 699 header the packet has no extension. 701 4.4.5. Length 703 The length field is a 16-bit unsigned integer that specifies the 704 length, including the Type-Version-Length Header and the size of the 705 the operation code specific content of the extension header. 707 4.5. Preliminary FSP Packets 709 Preliminary FSP packets are the packets exchanged during the end-to- 710 end negotiation phase of FSP connection establishment when it is 711 impossible to calculate ICC normally. 713 4.5.1. Connect Initialization 715 0 31 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Header Signature | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Salt | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 + Timestamp + 723 | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | | 726 + Init-Check-Code + 727 | | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 ~ ~ 730 ~ Host Name of the Responder (optional) ~ 731 ~ ~ 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Operation Code of this type of packet is INIT_CONNECT. 736 o Salt 737 It a 32-bit random bit string that may be exploited to make secret 738 key agreement. 739 o Timestamp 740 It is a 64-bit unsigned integer that represents number of 741 microseconds elapsed since 00:00, Jan.1, 1970, Coordinated 742 Universal Time. It may be exploited to synchronize the clocks of 743 the participants and/or estimate delay during data transmission in 744 the network. 745 o Init-Check-Code 746 It is a 64-bit random [RFC4086] bit string that means to uniquely 747 associated with the connection initiated. 748 o Host Name of the Responder 749 The optional payload of the Connect Initialization packet is the 750 host name of the responder. It MUST be encoded in UTF-8 [RFC3629] 751 and SHOULD be resolvable in DNS, 753 4.5.2. Acknowledgment to Connect Initialization 755 0 31 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Header Signature | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Time Delta | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 + Cookie + 763 | | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 + Init-Check-Code + 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 ~ ~ 770 ~ Sink Parameter ~ 771 ~ ~ 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Operation Code of this type of packet is ACK_INIT_CONNECT. 776 o Time Delta 777 It is a 32-bit signed integer which is the difference between the 778 near-end's time and the timestamp value sent in the Connection 779 Initialization packet. The units and the epoch of the near-end's 780 time value and the timestamp value MUST be the same. However, the 781 precision or resolution of the time delta value is chosen 782 arbitrarily by the responder. 783 o Cookie 784 It is a 64-bit bit string cryptographically generated by the 785 responder in a represent-transfer state manner. More specifically 786 when the same timestamp, time delta, Init-Check-Code, salt, source 787 and destination ULTIDs are sent to the responder, the responder 788 MUST be able to generate the identical cookie value. 789 o Init-Check-Code 790 It MUST be identical to the corresponding field in the Connect 791 Initialization packet acknowledged. 793 o Sink Parameter 794 It is an extension header specified in 4.7. 796 4.5.3. Connect Request 798 0 31 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Header Signature | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Salt | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | | 805 + Time Stamp + 806 | | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 + Init-Check-Code + 810 | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Initial Sequence Number | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Time Delta | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | | 817 + Cookie + 818 | | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 ~ ~ 821 ~ Sink Parameter ~ 822 ~ ~ 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 ~ ~ 825 ~ Host Name of the Initiator (optional) ~ 826 ~ ~ 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 Operation Code of this type of packet is CONNECT_REQUEST. 831 The value of each field that has the identical name with the one in 832 the associated Connect Initialization and Acknowledgment to Connect 833 Initialization packet MUST be assigned the same value as in these two 834 packets, except header signature in the packet. 836 Note that the initiator SHALL fill in the time delta field as it is 837 and SHALL NOT assume endian-ness of the time delta field. 839 o Sink Parameter It is an extension header specified in 4.7. 840 o Host Name of the Initiator The optional payload of the Connect 841 Request packet is the host name, which is encoded in UTF-8 and 842 SHOULD be resolvable in DNS, of the initiator. 844 It could be exploited by the responder to look up the address of 845 the initiator that may receive packets in the reverse direction. 847 4.6. Normal Fixed Header 849 0 15 16 31 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Header Signature | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Flags | Advertised Receive Window Size | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Sequence Number | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Expected Sequence Number/Out-of-Band Serial Number | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | | 860 + Integrity Check Code + 861 | | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Operation Code of a normal fixed header may be ACK_CONNECT_REQ, 865 PURE_DATA, PERSIST, KEEP_ALIVE, ACK_FLUSH, RELEASE or MULTIPLY. 867 o Flags It is bit-field of width 8. From left to right: 869 * End of Transaction (EoT): If the EoT flag of a packet is set, 870 it is the last packet of a transmit transaction. A packet with 871 the EoT flag set MAY be the start and the single packet of the 872 transmit transaction as well. 873 * Minimal-Delay (MIND): If the MIND flag of the Connect Request 874 or Acknowledgment to Connect Request packet is set, the ULA 875 prefers minimal delay and is willing to tolerate packet loss. 876 FSP SHALL drop the packet received earliest when there is no 877 enough receive buffer so that the latest packet received can be 878 saved and the delay to deliver data to ULA is minimized. 880 If the MIND flag has been set the EoT flag of any following 881 packet is simply ignored. 883 The MIND flag of an FSP packet may be set only if the packet 884 does not belong to a compressed transmit transaction. 886 Payload of each FSP packet is delivered to the ULA as an 887 independent message if the MIND flag has been set. 888 * Compressed (CPR) If the CPR flag of the first packet of a 889 transmit transaction is set, compression is applied on the 890 octet stream of the payloads of the continuous packets that 891 constitute the transmit transaction, or to put it simply, the 892 payload octet stream of the transaction transaction. Such 893 transmit transaction is called a compressed transmit 894 transaction. 896 When the CPR flag of a packet is set, CPR flag of each 897 following packet is ignored until reaching termination of the 898 transmit transaction. 900 If the payload octet stream of the transmit transaction is 901 compressed the Minimal-Delay flag of any packet in the transmit 902 transaction MUST be cleared. 903 * ECN-Echo (ECE): The Explicit Congestion Notification Echo flag 904 of a packet is set if the sender of the packet has received an 905 underlying IPv6 packet with Congestion Experienced code point 906 set for its peer as stated in "The Addition of Explicit 907 Congestion Notification (ECN) to IP" [RFC3168]. 908 * Send Rate Reduced (SRR): The SRR flag of each packet SHALL be 909 set as soon as the sender has received a legitimate packet with 910 ECE flag set and has informed the congestion manager to reduce 911 the send rate, until a sent packet with SRR flag set is 912 acknowledged. 913 * The remaining 3 bits are reserved. 914 o Advertised Receive Window Size 915 It is a 20-bit unsigned integer that stores number of the free 916 blocks in the receive buffer of the sender of the packet that 917 contains the receive window size field. It is count from the slot 918 meant to accept the packet with the expected sequence number. 920 The sender must ensure that the difference between the latest 921 sequence number sent out and the largest expected sequence number 922 received does not exceed the value of the latest advertised 923 receive window size received. 924 o Sequence Number 925 Each in-band FSP packet is assigned a 32-bit unsigned integer as 926 the sequence number. The sequence number assigned for in-band FSP 927 packets MUST be in strict order. 929 An out-of-band packet that has the operation code of KEEP_ALIVE, 930 ACK_FLUSH or MULTIPLY MUST be assigned a sequence number that 931 falls in the receive window. 932 o Expected Sequence Number 933 The 'expected sequence number/out-of-band serial number' field 934 stores the earliest sequence number of the packets that were not 935 yet received in the receive window of the sender for in-band 936 packet. It is an accumulative acknowledgment. Any packet with 937 the sequence number before the received Expected Sequence Number 938 is supposed to have been received by the remote end. 939 o Out-of-band Serial Number 940 The 'expected sequence number/out-of-band serial number' field 941 stores a 32-bit unsigned integer that numbers the out-of-band FSP 942 packet separately from the sequence space of the in-band packets. 944 Each time an out-of-band packet is sent the out-of-band serial 945 number SHALL increase by one. 947 It is assumed that in the life of the session no two packets have 948 the same sequence number and the same out-of-band serial number 949 simultaneously. 950 o Integrity Check Code 951 The ICC. 953 4.7. Sink Parameter 955 0 31 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Code-Mark-Length Prefix | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Listener ID/Host ID | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 ~ ~ 962 ~ Addressable Network Prefixes ~ 963 ~ ~ 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Operation Code in the Header Signature of this extension header is 967 PEER_SUBNETS. 969 o Listener ID 970 It is the ULTID of the responder that is in LISTENING state. 971 o Host ID 972 It is the aggregation host id of the sender. It SHALL be 0 if it 973 is in the IPv4 network. 974 o Addressable Network Prefixes 975 These are up to 4 64-bit words that specify the network prefixes 976 of the lower layer interfaces that are addressable by the receiver 977 in the reverse direction. 979 In this version of the FSP 'Addressable Network Prefixes' field is 980 of fixed length. The last network prefix which is non-zero is the 981 last resort one. There MUST be at least one non-zero network 982 prefix. If there are more than one non-zero network prefixes 983 those other than the last resort are load-balanced preferred. 985 In an IPv6 network, the addressable network prefix is the leftmost 986 64 bits of the IPv6 address. The receiver of the Addressable 987 Network Prefixes SHALL send packet in the reverse direction, i.e. 989 to the sender of the field with the destination IPv6 address 990 generated by combining a preferred network prefix with the 991 aggregation host id and the ULTID part of the source address in 992 the IPv6 header of the received packet that eventually carries the 993 Addressable Network Prefixes. 995 Such feature MAY be exploited to handle links with unidirectional 996 connectivity, but it is NOT RECOMMENTED. 998 In an IPv4 network for compatibility with the IPv6 addressed ULA 999 the 64-bit word of the addressable network prefix specified is 1000 composed as following Figure: 1002 0 15 16 31 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | 0x2002 (IPv6 6to4 prefix) |IPv4 address (leftmost 16 bits)| 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 |IPv4 address(rightmost 16 bits)| UDP port number (16 bits) | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Sender of the Sink Parameter packet SHOULD be NAT-aware in the IPv4 1010 network. If it is able to obtain the from the NAT box (as defined 1011 in "Traditional IP Network Address Translator (Traditional NAT)" 1012 [RFC3022]) through Port Control Protocol (PCP) [RFC6887] SHOULD 1013 fill in the IPv4 address and UDP port number fields with the public 1014 IP value that were obtained. If it does not have such capability, 1015 it SHALL fill in the addressable network prefix with all binary 1016 zeroes. 1018 4.8. Selective Negative Acknowledgment 1019 0 31 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Code-Mark-Length Prefix | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Expected Sequence Number | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Delay Sample Sequence Number | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Acknowledgement Delay | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Gap Width | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Data Length | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 ~ ~ 1034 ~ Further pairs of (Gap Width, Data Length) ~ 1035 ~ ~ 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 The operation code of this type of extension header is SNACK.block. 1040 o Expected Sequence Number 1041 It stores the earliest sequence number of the packets that were 1042 not yet received in the receive window of the sender. It is an 1043 accumulative acknowledgment. Any packet with the sequence number 1044 before the received Expected Sequence Number is supposed to have 1045 been received by the remote end. 1047 The expected sequence number is represented in little endian. 1048 o Delay Sample Sequence Number 1049 It stores the sequence number of the packet that the 1050 acknowledgement delay was calculated on. 1052 The delay sample sequence number is represented in little endian. 1053 o Acknowledgement Delay 1054 A 32-bit unsigned integer specifies the delay in microseconds 1055 between sending the packet containing the SNACK extension header 1056 and accepting the last packet that is accumulatively acknowledged 1057 by the SNACK extension header. 1059 The acknowledgement delay is represented in little endian. 1060 o Gap Width and Data Length 1061 The SNACK header contains the descriptor of the receive window 1062 gaps. The descriptor itself is a list of entries. The length of 1063 the list can be zero which means that there is no gap in the 1064 receive window. If the list is not empty, each entry contains the 1065 width of one gap (Gap Width) in the receive window and the length 1066 of the continuously received data following the gap (Data Length), 1067 respectively. 1069 The unit of aforementioned length of gaps or number of packets is 1070 buffer block which size is agreed upon connection establishment. 1072 Gap width and data length MUST be transmitted in little endian. 1074 4.9. RESET 1076 The 'RESET' packet is a special command packet meant to interrupt 1077 connection setup process or disconnect abruptly. Operation Code of 1078 the packet is RESET. 1080 Structure of a RESET packet in C code snippet with unnamed union 1081 applied: 1083 struct FSP_RejectConnect 1084 { 1085 FSP$HeaderSignature hs; 1086 /* bit field to describe reasons for reset */ 1087 uint32_t reasons; 1088 /* sequence numbers */ 1089 union 1090 { 1091 timestamp_t timeStamp; 1092 struct 1093 { 1094 uint32_t initial; 1095 uint32_t expected; 1096 } sn; 1097 }; 1098 /* uniqueness proof */ 1099 union 1100 { 1101 uint64_t integrityCode; 1102 uint64_t cookie; 1103 uint64_t initCheckCode; 1104 }; 1105 }; 1107 When the RESET packet is the response to a Connect Initialization 1108 packet both the timeStamp and the initCheckCode fields of the RESET 1109 packet MUST be set to the same values of Time Stamp and Init-Check- 1110 Code in the Connect Initialization packet, respectively. 1112 When the RESET packet is the response to a Connect Request packet 1113 both the timeStamp and the cookie fields of the RESET packet MUST be 1114 set to the same value of Time Stamp and Cookie in the Connect Request 1115 packet, respectively. 1117 When the RESET packet is the response to a packet with a normal fixed 1118 header, the sn.initial, the sn.expected and the integrityCode of the 1119 RESET packet MUST be set as to specification of normal fixed header 1120 field Sequence Number, Expected Sequence Number and Integrity Check 1121 Code, respectively. 1123 5. The Finite State Machine 1125 5.1. NON_EXISTENT 1127 ---[API: Listen]-->LISTENING 1128 |--[API: Connect]-->CONNECT_BOOTSTRAP-->[Send INIT_CONNECT] 1129 |--[API: Multiply]-->CLONING-->[Send MULTIPLY] 1131 NON_EXISTENT is a pseudo-state before a connection is created by the 1132 ULA calling API Listen, Connect or Multiply (or after a connection is 1133 reset). 1135 5.2. LISTENING 1137 ---[API: Reset]-->NON_EXISTENT 1138 |<-->[Rcv.INIT_CONNECT]{&& accepted}[Send ACK_INIT_CONNECT] 1139 |<-->[Rcv.INIT_CONNECT]{&& rejected}[Send RESET] 1140 |<-->[Rcv.CONNECT_REQUEST] 1141 |--{&& duplication detected}--[Retransmit ACK_CONNECT_REQ] 1142 |--{&& no duplication}-->{Notify} 1143 |-->[API: Accept] 1144 -->{new context}CHALLENGING-->[Send ACK_CONNECT_REQ] 1145 |-->[API: Reject]-->[Send RESET]{abort new context, if any} 1147 LISTENING is a state entered by the ULA calling API Listen. 1149 5.3. CONNECT_BOOTSTRAP 1151 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1152 |-->[Rcv.ACK_INIT_CONNECT]-->CONNECT_AFFIRMING 1153 -->[Send CONNECT_REQUEST] 1154 |-->[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1155 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1157 CONNECT_BOOTSTRAP is a state entered by the ULA calling API Connect, 1158 before receiving the acknowledgement of the remote end to the 1159 connection initialization packet. 1161 5.4. CONNECT_AFFIRMING 1163 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1164 |--[Rcv.ACK_CONNECT_REQ]-->[Notify] 1165 |-->{Callback return to accept} 1166 |-->{EOT} 1167 |-->{No Payload to Send}-->COMMITTING2-->[Send NULCOMMIT] 1168 |-->{Has Payload to Send} 1169 |-->{ULA-flushing}-->COMMITTING2 1170 -->[Send PERSIST with EoT] 1171 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Send PERSIST] 1172 |-->{Not EOT} 1173 |-->{No Payload to Send}-->COMMITTING-->[Send NULCOMMIT] 1174 |-->{Has Payload to Send} 1175 |-->{ULA-flushing}-->COMMITTING 1176 -->[Send PERSIST with EoT] 1177 |-->{Not ULA-flushing}-->ESTABLISHED-->[Send PERSIST] 1178 |-->{Callback return to reject]-->NON_EXISTENT-->[Send RESET] 1179 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1180 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1182 CONNECT_AFFIRMING is a state entered by the ULA affirming to send 1183 connect request after receiving the acknowledgement to the connection 1184 initialization packet. 1186 5.5. CHALLENGING 1188 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1189 |<-->[API: Send{new data}]{just pre-buffer} 1190 |--[Rcv.NULCOMMIT] 1191 |-->{ULA-flushing}-->CLOSABLE-->[Notify] 1192 -->[Send ACK_FLUSH] 1193 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Notify] 1194 -->[Send ACK_FLUSH] 1195 |--[Rcv.PERSIST] 1196 |-->{EOT} 1197 |-->{ULA-flushing}-->CLOSABLE-->[Notify] 1198 -->[Send ACK_FLUSH] 1199 |-->{Not ULA-flushing}-->PEER_COMMIT-->[Notify] 1200 -->[Send ACK_FLUSH] 1201 |-->{Not EoT} 1202 |-->{ULA-flushing}-->COMMITTED-->[Notify] 1203 -->[Send delay SNACK] 1204 |-->{Not ULA-flushing}-->ESTABLISHED-->[Notify] 1205 -->[Send delay SNACK] 1206 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1207 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1209 CHALLENGING is a state entered by the ULA accepting the connection 1210 request after a new connection context has been incarnated. The new 1211 connection is incarnated by the FSP context of the near end in the 1212 LISTENING state as a legitimate CONNECT_REQUEST packet is received. 1214 5.6. ACTIVE 1216 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1217 |--[API: Send{flush}]-->COMMITTING{Urge to commit} 1218 |<-->[API: Send{more data}][Send PURE_DATA] 1219 |--[Rcv.NULCOMMIT] 1220 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1221 |--[Rcv.PURE_DATA] 1222 |--{EOT}-->PEER_COMMIT 1223 -->[Send ACK_FLUSH]-->[Notify] 1224 |--{Not EOT}-->[Send SNACK]-->[Notify] 1225 |--[Rcv.PERSIST] 1226 |--{EOT}-->PEER_COMMIT 1227 -->[Send ACK_FLUSH]-->[Notify] 1228 |--{Not EOT}-->[Send SNACK] 1229 |--[Rcv.MULTIPLY]{passive multiplication} 1230 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1231 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1233 ACTIVE, also known as ESTABLISHED, is a state that the FSP 1234 participant has finished end-to-end negotiation but has not committed 1235 current transmit transaction nor fully received the latest transmit 1236 transaction of the remote end. 1238 5.7. COMMITTING 1240 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1241 |--[Rcv.ACK_FLUSH]-->COMMITTED-->[Notify] 1242 |--[Rcv.NULCOMMIT] 1243 |-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1244 |--[Rcv.PURE_DATA] 1245 |--{EOT}-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1246 |--{Not EOT}-->[Send SNACK]-->[Notify] 1247 |--[Rcv.MULTIPLY]{passive multiplication} 1248 |--[Rcv.RELEASE] 1249 |--{EOT}-->SHUT_REQUESTED-->[Send ACK_FLUSH]-->[Notify] 1250 |--{Not EOT}-->[Send SNACK lazily] 1251 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1252 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1254 COMMITTING is a state that the FSP participant has committed the 1255 transmit transaction but has not fully received the latest transmit 1256 transaction of the remote end, nor the acknowledgement to the 1257 transmit transaction commitment has been received. 1259 The participant in COMMITTING state SHALL NOT transmit further data 1260 until current transmit transaction commitment is acknowledged. 1262 5.8. COMMITTED 1264 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1265 |--[API: Send{more data}]-->ACTIVE-->[Send PERSIST] 1266 |--[API: Send{flush}]-->COMMITTING-->{Flush the send queue} 1267 |--[Rcv.NULCOMMIT]-->CLOSABLE 1268 -->[Send ACK_FLUSH]-->[Notify] 1269 |--[Rcv.PURE_DATA] 1270 |-->{EOT}-->CLOSABLE 1271 -->[Send ACK_FLUSH]-->[Notify] 1272 |-->{Not EOT}-->[Send SNACK]-->[Notify] 1273 |--[Rcv.PERSIST] 1274 |-->{EOT}-->CLOSABLE 1275 -->[Send ACK_FLUSH]-->[Notify] 1276 |-->{Not EOT}-->[Send SNACK] 1277 |--[Rcv.MULTIPLY]{passive multiplication} 1278 |--[Rcv.RELEASE] 1279 |--{EOT}-->SHUT_REQUESTED 1280 -->[Send ACK_FLUSH]-->[Notify] 1281 |--{Not EOT}-->[Send SNACK lazily] 1282 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1283 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1285 COMMITTED is a state that the FSP participant has committed current 1286 transmit transaction and has received the acknowledgement to the 1287 transmit transaction commitment, but has not fully received the 1288 latest transmit transaction of the remote end. 1290 5.9. PEER_COMMIT 1291 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1292 |--[API: Send{flush}]-->{Mark EoT or append NULCOMMIT} 1293 -->COMMITTING2-->{Do Send} 1294 |--[API: Shutdown]-->PRE_CLOSED-->{Append RELEASE} 1295 -->{Do Send} 1296 |<-->[API: Send{more data}][Send PURE_DATA] 1297 |<-->[Rcv.PURE_DATA]{just prebuffer} 1298 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1299 |--[Rcv.PERSIST] 1300 |<-->{EOT}-->[Send ACK_FLUSH] 1301 --{&& is new transaction}-->[Notify] 1302 |-->{Not EOT}-->ACTIVE-->[Send SNACK] 1303 |--[Rcv.MULTIPLY]{passive multiplication} 1304 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1305 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1307 PEER_COMMIT is a state that the FSP participant has not committed 1308 current transmit transaction but has fully received the latest 1309 transmit transaction of the remote end, and the acknowledgement to 1310 the transmit transaction commitment has not been received yet. 1312 5.10. COMMITTING2 1314 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1315 |--[API: Shutdown]-->PRE_CLOSED-->{Append RELEASE}-->{Do Send} 1316 |<-->[Rcv.PURE_DATA]{just prebuffer} 1317 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1318 |--[Rcv.ACK_FLUSH]-->CLOSABLE-->[Notify] 1319 |--[Rcv.PERSIST] 1320 |--{EOT}--{but a new transaction} 1321 -->[Send ACK_FLUSH]-->[Notify] 1322 |--{Not EOT}-->COMMITTING-->[Send SNACK] 1323 |--[Rcv.MULTIPLY]{passive multiplication} 1324 |--[Rcv.RELEASE]-->SHUT_REQUESTED 1325 -->[Send ACK_FLUSH]-->[Notify] 1326 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1327 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1329 COMMITTING2 is a state that the FSP participant has committed current 1330 transmit transaction and has fully received the latest transmit 1331 transaction of the remote end, but the acknowledgement to the 1332 transmit transaction commitment has not been received yet. 1334 The participant in COMMITTING2 state SHALL NOT transmit further data 1335 until current transmit transaction commitment is acknowledged. 1337 5.11. CLOSABLE 1339 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1340 |--[API: Send{more data}]-->PEER_COMMIT-->[Send PERSIST] 1341 |--[API: Send{flush}]-->COMMITTING2-->{Flush the send queue} 1342 |--[API: Shutdown]-->PRE_CLOSED-->{Append RELEASE}-->{Do Send} 1343 |<-->[Rcv.PURE_DATA]{just prebuffer} 1344 |<-->[Rcv.NULCOMMIT]-->[Send ACK_FLUSH] 1345 |--[Rcv.PERSIST] 1346 |--{EOT}--{but a new transaction} 1347 -->[Send ACK_FLUSH]-->[Notify] 1348 |-->{Not EOT}-->COMMITTED-->[Send SNACK] 1349 |--[Rcv.MULTIPLY]{passive multiplication} 1350 |--[Rcv.RELEASE]-->SHUT_REQUESTED 1351 -->[Send ACK_FLUSH]-->[Notify] 1352 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1354 CLOSABLE is a state that the FSP participant has committed current 1355 transmit transaction and has received the acknowledgement to the 1356 transmit transaction commitment, and has fully received the latest 1357 transmit transaction of the remote end. 1359 5.12. SHUT_REQUESTED 1361 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1362 |--[API: Shutdown]-->CLOSED-->[Notify] 1363 |<-->[Rcv.RELEASE]-->[Send ACK_FLUSH] 1364 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1366 SHUT_REQUESTED is a state entered when a legitimate RELEASE packet 1367 was received. 1369 A connection context MAY persist in SHUT_REQUESTED state until the 1370 session key runs out of life, or the host system needs to recycle the 1371 resource allocated. A connection in SHUT_REQUESTED state MAY be 1372 resurrected. 1374 5.13. PRE_CLOSED 1376 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1377 |--[Rcv.ACK_FLUSH]-->CLOSED-->[Notify] 1378 |--[Rcv.RELEASE]-->[Notify]-->CLOSED 1379 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1380 |--{On transient state Timeout}-->CLOSED-->[Notify] 1382 PRE_CLOSED is a state entered on the ULA calling the API Shutdown in 1383 COMMITTING2 or CLOSABLE state. 1385 5.14. CLOSED 1387 |--{On Recycling Needed}-->NON_EXISTENT 1389 CLOSED is a state migrated from PRE_CLOSED state on receiving a 1390 legitimate ACK_FLUSH packet from the remote end, or from 1391 SHUT_REQUESTED state on the ULA calling the API Shutdown. 1393 Unlike TCP [STD7], CLOSED state in FSP is not fictional. Instead a 1394 connection context MAY persist in CLOSED state until the session key 1395 runs out of life, or the host system needs to recycle the resource 1396 allocated to the CLOSED session. A connection in CLOSED state MAY be 1397 resurrected. 1399 5.15. CLONING 1401 ---[API: Reset]-->NON_EXISTENT 1402 |<-->[API: Send{new data}]{just prebuffer} 1403 |<-->[Rcv.PURE_DATA]{just prebuffer} 1404 |--[Rcv.NULCOMMIT] 1405 |--{&& Not ULA-flushing}-->PEER_COMMIT 1406 -->[Send ACK_FLUSH]-->[Notify] 1407 |--{&& ULA-flushing}-->CLOSABLE 1408 --->[Send ACK_FLUSH]-->[Notify] 1409 |--[Rcv.PERSIST] 1410 |-->{Not EOT} 1411 |--{&& Not ULA-flushing}-->ACTIVE 1412 -->[Send SNACK]-->[Notify] 1413 |--{&& ULA-flushing}-->COMMITTED 1414 -->[Send SNACK]-->[Notify] 1415 |-->{EOT} 1416 |--{&& Not ULA-flushing}-->PEER_COMMIT 1417 -->[Send ACK_FLUSH]-->[Notify] 1418 |--{&& ULA-flushing}-->CLOSABLE 1419 -->[Send ACK_FLUSH]-->[Notify] 1420 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1421 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1423 CLONING is a state entered by ULA calling the API Multiply from any 1424 state that may accepting an out-of-band packet. 1426 5.16. Passive Multiplication 1427 {ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, COMMITTING2, CLOSABLE} 1428 |-->/MULTIPLY/-->[API{Callback}]-->{new context}CONNECT_AFFIRMING 1429 |-->[{Return Accept}] 1430 |-->{has payload prebuffered} 1431 -->{Send packet(s) starting with PERSIST} 1432 |-->{without payload}-->[Send NULCOMMIT] 1433 |-->[{Return Reject}]-->{abort creating new context} 1434 -->[Send RESET] 1436 In the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, COMMITTING2 or 1437 CLOSABLE state an FSP end node MAY accept its peer's connection 1438 multiplication request and transit to the unnamed, temporary passive 1439 multiplication state. 1441 5.17. Typical State Transitions 1443 This section is informative. 1445 5.17.1. Typical Main Connection 1447 *** Bootstrapping *** 1448 CONNECT_BOOTSTRAP ------ INIT_CONNECT -------> LISTENING 1449 | <---- ACK_CONNECT_INIT ----- 1450 CONNECT_AFFIRMING ------ CONNECT_REQUEST ----> | 1452 *** Connection affirmation, carrying welcome messages *** 1453 | 1454 {Accept} 1455 {and send a single packet welcome message immediately} 1456 | 1457 | <- ACK_CONNECT_REQ c/w EoT - CHALLENGING 1458 PEER_COMMITTED 1459 | 1460 {Callback, to send ticket immediately} 1461 {(a fictional identification token of a single packet)} 1462 | 1463 COMMITTING2 ----- PERSIST c/w EoT -----> | 1464 CLOSABLE 1465 | <-------- ACK_FLUSH -------- | 1466 CLOSABLE 1467 | 1468 {Send Server's Challenge} 1469 | 1470 | <----- PERSIST w/o EoT ----- PEER_COMMITED 1471 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1472 . 1473 . 1475 . | 1476 {Flush} 1477 | 1478 | <---- PURE_DATA c/w EoT ---- COMMITTING2 1479 CLOSABLE 1480 --------- ACK_FLUSH -------> | 1481 CLOSABLE 1482 | 1483 {Send Client's Response} 1484 | 1485 PEER_COMMITTED ----- PERSIST w/o EoT -----> | 1486 COMMITTED 1487 | <--- KEEP_ALIVE(SNACK) ----- | 1488 . 1489 | ---- PURE_DATA w/o EoT ----> COMMITTED 1490 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ---- | 1491 . 1492 . 1493 | . 1494 {Flush} 1495 | 1496 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1497 CLOSABLE 1498 | <-------- ACK_FLUSH -------- 1499 CLOSABLE 1501 *** Typical C/S request-response exchange on application layer *** 1502 | 1503 {Send Request} 1504 | 1505 PEER_COMMITTED ----- PERSIST w/o EoT -----> | 1506 COMMITTED 1507 | <--- KEEP_ALIVE(SNACK) ----- | 1508 . 1509 | ---- PURE_DATA w/o EoT ----> COMMITTED 1510 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ----- | 1511 . 1512 . 1513 | . 1514 {Flush} 1515 | 1516 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1517 CLOSABLE 1518 | <-------- ACK_FLUSH -------- 1519 CLOSALBE 1520 {Send Response} 1521 | 1522 | <----- PERSIST w/o EoT ----- PEER_COMMITED 1524 COMMITTED 1525 ---- KEEP_ALIVE(SNACK) ----> | 1526 . 1527 | <---- PURE_DATA w/o EoT ---- PEER_COMMITED 1528 COMMITTED ---- KEEP_ALIVE(SNACK) ----> | 1529 . 1530 . 1531 . 1532 {Flush} 1533 | 1534 | <---- PURE_DATA c/w EoT ---- COMMITTING2 1535 CLOSABLE 1536 --------- ACK_FLUSH -------> | 1537 CLOSALBE 1538 . 1539 . 1540 . 1541 *** Following request-responses, e.g. HTTP pipelining *** 1542 . 1543 . 1544 . 1546 CLOSABLE CLOSALBE 1547 . 1548 . 1549 *** End of connection, in a typical C/S application *** 1550 | 1551 {Shutdown} 1552 | 1553 | <---------- RELEASE -------- PRE_CLOSED 1554 SHUT_REQUESTED 1555 --------- ACK_FLUSH -------> | 1556 | CLOSED 1557 {Shutdown} 1558 | 1559 CLOSED 1561 5.17.2. Typical Clone Connection for Get Resource 1562 Client Server 1564 *** Suppose the browser fork a new connection to request *** 1565 *** some resource and the URI is short enough to be *** 1566 *** encapsulated in a single packet *** 1568 {MultiplyAndWrite} 1569 | {In Clonable State} 1570 CLONING ---- MULTIPLY c/w EoT ----> * 1571 {Make Clone Connection} 1572 {and return resource data immediately} 1573 | 1574 | <---- PERSIST w/o EoT ------ PEER_COMMITTED 1575 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1577 <---- PUER_DATA w/o EoT ---- PEER_COMMITTED 1578 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1579 . 1580 . 1581 . | 1582 {Flush} 1583 | 1584 | <--- PURE_DATA c/w EoT ----- COMMITTING2 1585 CLOSABLE 1586 --------- ACK_FLUSH -------> | 1587 CLOSABLE 1588 . 1589 . 1590 *** End of Connection *** 1592 5.17.3. Typical Clone Connection for Push Message 1593 Initiator of Multiplication Responder of Multiplication 1595 *** Suppose the server fork a new connection to push message *** 1597 (Used to be server side) (Used to be client side) 1598 | 1599 {MultiplyAndWrite} 1600 | {In Clonable State} 1601 CLONING ---- MULTIPLY w/o EoT ----> * 1602 {Make Clone Connection} 1603 *** suppose no immediately available responding data *** 1604 | 1605 COMMITTING 1606 | <--- NULCOMMIT(c/w EoT) ---- | 1607 PEER_COMMITTED 1608 | --------- ACK_FLUSH -------> COMMITTED 1609 . 1610 | ---- PURE_DATA w/o EoT ----> COMMITTED 1611 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ---- | 1612 . 1613 . 1614 | . 1615 {Flush} 1616 | 1618 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1619 CLOSABLE 1620 | <-------- ACK_FLUSH -------- 1621 CLOSABLE 1622 . 1623 . 1624 *** End of Connection *** 1626 5.17.4. Simultaneous Shutdown 1628 CLOSABLE CLOSABLE 1629 | | 1630 {Shutdown} {Shutdown} 1631 | | 1632 PRE_CLOSED PRE_CLOSED 1633 | \ / | 1634 | \ / | 1635 | \ / | 1636 | \------------- RELEASE --------------/----->+ 1637 +<------------------- RELEASE ------------/ | 1638 | CLOSED 1639 CLOSED 1641 6. End-to-End Negotiation 1643 End-to-end negotiation of FSP session occurs in the connection 1644 establishment phase. Connection establishment process of FSP 1645 consists of two and a half pairs of packet exchanges for connection 1646 initialization, connection incarnation and the last confirmation. 1647 During the process various optional header or payload MAY be carried 1648 in the FSP preliminary packets to negotiate end-to-end session 1649 parameters. 1651 6.1. Connect Initialization 1653 The initiator sends the INIT_CONNECT packet to the responder: 1654 (INIT_CONNECT, Salt, Timestamp, Init-Check-Code [, Responder's Host 1655 Name]) 1657 Connection initialization MAY be syndicated with optional address 1658 resolution at the gateway in the IPv6 network by carrying the 1659 responder's host name in the INIT_CONNECT packet. 1661 If it does carry the responder's host name it MUST take the link- 1662 local interface address [RFC4291] as the source IPv6 address and the 1663 default link-local gateway address, FE80::1, as the destination IPv6 1664 address no matter whether the global unicast IP address of the 1665 default gateway is configured. 1667 If the gateway that relays the INIT_CONNECT packet finds that the 1668 responder is on the same link-local network with the initiator it 1669 SHALL change the source and the destination IP addresses of the 1670 INIT_CONNECT packet to the link-local IP addresses of the initiator 1671 and the responder respectively, and relay the packet onto the same 1672 link-local network. 1674 On receiving the INIT_CONNECT packet that carries the responder's 1675 host name the link-local gateway MUST resolute the responder's global 1676 unicast IPv6 address and map the initiator's global unicast IPv6 1677 address, and replace the destination and source address of the 1678 INIT_CONNECT packet respectively, unless it finds that the initiator 1679 and the responder are on the same link-local network, where the 1680 gateway SHALL process the packet as stated in the previous statement. 1682 The gateway SHALL silently ignore the INIT_CONNECT packet if it is 1683 unable to resolve the IP address of the responder. 1685 If the destination address is the default link-local gateway address 1686 while the INIT_CONNECT does not carry the responder's host name 1687 payload, it is supposed that the gateway is the intent destination of 1688 the connection to initialize. 1690 6.2. Response to Connect Initialization 1692 The responder sends acknowledgment to the initiator: 1694 Case 1: (ACK_INIT_CONNECT, Time-delta, Cookie, Init-Check-Code 1695 Reflected, Responder's Sink Parameter) 1697 Case 2: (RESET, Reason of Failure, Timestamp Reflected, Init-Check- 1698 Code Reflected) 1700 In case 1 the responder is ready to accept the connection. It SHALL 1701 NOT make state transition on receiving INIT_CONNECT packet. It SHALL 1702 generate a cookie which is meant to be reflected by the initiator. 1703 The responder MUST send the ACK_INIT_CONNECT packet with the new 1704 allocated local ULTID instead of the original listening ULTID. The 1705 initiator should be able to find out the original listening ULTID by 1706 searching its own connection context. 1708 In the Responder's Sink Parameter the original listener ULTID MUST be 1709 set to the right value. 1711 In case 2 the responder refuses to accept the connection. It SHALL 1712 send back a RESET packet with the listening ULTID as the source 1713 ULTID. 1715 In either case the destination address of the packet sent back MUST 1716 be set to the source address of the corresponding Connect 1717 Initialization packet whose source and destination address MAY be 1718 updated by some intermediary such as the link-local gateway of the 1719 initiator. 1721 6.3. Connection Incarnation Request 1723 (CONNECT_REQUEST, Salt, Timestamp, Init-Check-Code, Initial SN, Time- 1724 delta Reflected, Cookie Reflected, Initiator's Sink Parameter [, 1725 Initiator's Host Name]) 1727 The initiator accepts the Response to Connect Initialization packet 1728 if and only if both the destination ULTID of the response packet 1729 matches the source ULTID of the connect initialization packet and the 1730 Init-Check-Code reflected in the response packet matches the Init- 1731 Check-Code in the connect initialization packet. 1733 If the response packet is accepted the initiator formally requests to 1734 establish the connection by sending the CONECT_REQUEST packet. 1736 In the CONNECT_REQUEST packet the value of the Timestamp, the Init- 1737 Check-Code and the Salt field MUST be the same as in the INIT_CONNECT 1738 packet while the value of the Cookie Reflected field and the Time- 1739 delta Reflected field MUST be the same as in the ACK_INIT_ CONNECT 1740 packet, respectively. 1742 The initiator MUST send the packet towards the remote ULTID that the 1743 responder has preserved and sent with the ACK_INIT_CONNECT packet. 1744 It MUST fill the original listener ID field in the Initiator's Sink 1745 Parameter with the right value. 1747 The source address of the CONNECT_REQUEST packet MUST be set to the 1748 destination address of the received ACK_INIT_CONNECT packet, while 1749 the network prefix and host-id part of the destination address MUST 1750 be set to the source address of the received ACK_INIT_CONNECT packet 1751 in the IPv6 network. 1753 The initiator SHALL save the cookie value that the responder has 1754 given to make up the weak session key. 1756 The initiator MUST fill the Initial SN field with the sequence number 1757 of the packet that will follow CONNECT_REQUEST. The CONNECT_REQUEST 1758 packet is payload free and does not consume the sequence space. 1760 The optional fields Initiator's Host Name is put as the payload of 1761 the CONNECT_REQUEST packet. If presented it MAY be exploited by the 1762 responder as the last resort to resolute the most recent IP address 1763 of the initiator in some extraordinary scenarios such as the 1764 initiator has hibernated for a considerably long time. 1766 6.4. Connection Incarnation Response 1768 Case 1: (ACK_CONNECT_REQ, FREWS, Initial SN, Expected SN, ICC[, 1769 Payload]) 1771 Case 2: (RESET, Reason of Failure, Timestamp Reflected, Copy of 1772 Cookie Reflected) 1774 The responder responds as in case 1 if the reflected cookie was 1775 validated, resources were successfully allocated and the initial 1776 context of the connection was setup. Otherwise it SHOULD respond as 1777 in case 2. 1779 The Initial SN in case 1 is the initial sequence number of the 1780 responder. The responder should fill in the field with a random 32- 1781 bit unsigned integer. As the ACK_CONNECT_REQ packet may carry 1782 payload the sequence number of the responder starts from the 1783 ACK_CONNECT_REQ packet. 1785 The Expected SN MUST equal to the Initial SN specified in the 1786 corresponding CONNECT_ REQUEST packet. 1788 6.5. The Last Confirmation 1790 Case 1: (NULCOMMIT, FREWS, Initial SN, Expected SN, ICC) 1792 Case 2: (PERSIST, FREWS, Initial SN, Expected SN, ICC, payload) 1794 Case 3: (RESET, Reason of Failure, Initial SN, Expected SN, ICC) 1796 The initiator of the connection MUST eventually confirm to the 1797 responder that the connection is established by sending a payload- 1798 less NULCOMMIT packet (case 1) or a PERSIST packet with payload (case 1799 2). 1801 Of course the initiator MAY quit to establish the connection by 1802 sending a legitimate RESET packet (case 3). 1804 6.6. Retransmission 1806 The initiator SHALL retransmit the INIT_CONNECT packet if the 1807 corresponding ACK_INIT_CONNECT packet is not received in some limit 1808 time (by default 15 seconds). 1810 The initiator SHALL retransmit the CONNECT_CONNECT packet if the 1811 corresponding ACK_CONNECT_REQ packet is not received in some limit 1812 time (by default 15 seconds). 1814 The responder SHALL NOT retransmit ACK_INIT_CONNECT or 1815 ACK_CONNECT_REQ packet. 1817 The initiator SHOULD retransmit the right INIT_CONNECT packet or 1818 CONNECT_CONNECT packet until the legitimate ACK_CONNECT_REQ packet is 1819 eventually received. 1821 It SHALL give up if the time starting from the very first 1822 INIT_CONNECT packet was sent has exceed a longer timed-out value (by 1823 default 60 seconds) before the legitimate ACK_CONNECT_REQ packet is 1824 received. 1826 7. Quad-party Session Key Installation 1828 It is assumed that in the scenarios applying FSP it is the ULA to do 1829 key establishment and/or end-point authentication while the FSP layer 1830 provides authenticated, optionally encrypted data transfer service. 1831 The ULA installs the established shared secret key as the new session 1832 key of the FSP layer. Together they establish a secure channel 1833 between two application end-points. 1835 In a typical scenario the ULA endpoints first setup the FSP 1836 connection where resistance against connection redirection is weakly 1837 enforced by CRC64. After the pair of ULA endpoints have established 1838 a shared secret key, they install the secret key. Authenticity of 1839 the FSP packets sent later is cryptographically protected by the new 1840 secret key and resistance against various attacks is secured. 1842 Although transmit transaction is actually uni-directional the secret 1843 key is shared bi-directionally in this version of FSP. 1845 Protocol for installation of the shared secret key is quad-party in 1846 the sense that both the upper layer application and the FSP layer of 1847 both the participant nodes MUST agree on the moment of certain state 1848 to install the shared secret key. 1850 It is arguably much more flexible for the application layer protocols 1851 to adopt new key establishment algorithm while offloading routine 1852 authentication and optionally encryption of the data to the 1853 underlying layers where it may be much easier to exploit hardware- 1854 acceleration. 1856 7.1. API for Session Key Installation 1858 A dedicate application program interface (API) is designed for the 1859 ULA to install the secret key established by the ULA participants. 1860 The API SHOULD take four parameters: 1862 o A 'handle' to state the connection context for installing the 1863 session key 1864 o A octet string of initial key materials (IKM) 1865 o An integer to state the length of IKM. The unit is octet. 1866 o An integer to state the desired length of the effective session 1867 key if AEAD is applied. The unit is bit. For this version of FSP 1868 desired length of the effective session key is either 128 or 256. 1870 The peer MUST have commit a transmit transaction and it SHALL install 1871 the same secret key on receiving the FSP packet with the EoT flag 1872 set. 1874 The ULA SHOULD have installed the new shared secret key, or install 1875 it instantly after accepting the packet with the EoT flag set. If 1876 the new secret key has ever been installed the packet received after 1877 the one with the EoT flag set MUST adopt the new secret key. 1879 7.2. Time to Call API for Session Key Installation 1881 A participant MAY install new session key if and only if the packet 1882 with the latest sequence number it has received has EoT flag marked. 1884 7.3. Time to Take New Session Key into Effect 1886 By committing a transmit transaction a ULA participant clearly tells 1887 the underlying FSP layer that the next packet sent MAY adopt a new 1888 secret key. On receiving a packet with the EoT flag set the ULA is 1889 informed that the next packet received MAY adopt a new shared secret 1890 key. 1892 After the ULA of a network node installed a new session key, every 1893 packet to send with sequence number later than the one with the EoT 1894 flag set just before the API to install session key was called MUST 1895 adopt the new session key in the FSP layer of the network node. 1897 Every packet received with the sequence number later than the one 1898 with EoT flag set when the ULA called the API to install session key 1899 MUST be validated with the new session key. If the new secret key 1900 has ever been installed the packet received after the one with the 1901 EoT flag set MUST adopt the new secret key. 1903 7.4. Generating the Initial Session Key 1905 When the ULA install the secret key, it is required to provide the 1906 initial key material which might have unbalanced bit randomness, not 1907 the session key itself. HMAC-based Extract-and-Expand Key Derivation 1908 Function (HKDF) [RFC5869] is applied to generate the initial session 1909 key. 1911 Given raw key material ikm, length of the ikm nB in octets, intended 1912 master key length lenb in bits, || is octet string concatenation, 1914 If HMAC only is designated, the nB octets of ikm is hashed into 64 1915 octets which is taken as the master key. 1917 If AEAD is designated, the initial session key, or the first secret 1918 key for packet authentication and payload encryption is obtained as 1919 specified in [RFC5869]: 1921 Key Extract phase, 1923 Let Km = BLAKE2(zeros || ikm) , where 1925 zeros is 32 octets of integer 0 1926 BLAKE2b algorithm without key is applied. 1928 The result Km is the master key. 1929 Key Expand phase, 1931 Let Ks = BLAKE2(Km, info) , where 1933 Km is the master key generated in previous phase, 1935 info is concatenation of the arbitrary ASCII string "Establishes an 1936 FSP session", which is 26-octet long, 3 octets of integer 0, and 1 1937 octet of integer 1. 1939 BLAKE2b algorithm with key is applied. The key applied MUST be the 1940 master key Km. 1942 The result Ks is the initial session key, or the first secret key 1943 for packet authentication and payload encryption. 1945 For this version FSP the generated Ks is a fixed-length AES key 1946 together with a 4-octet salt. The salt is meant to be passed to 1947 AES-GCM as the initialization vector together with the sequence 1948 number and expected sequence number fields in the normal FSP fixed 1949 header: 1951 0 31 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Salt | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | Sequence Number | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Expected Sequence Number/Out-of-band Serial Number | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 The salt is called 'the original salt', separated from 'the second 1961 salt' in the out-of-band packet. 1963 7.5. Internal Rekeying 1965 In this version of FSP it is forced to re-key on sending or receiving 1966 every 536870912? (2^29) packets. 1968 Let Ks' = BLAKE2(Km, H || info') , where: 1970 Km is the master key generated as in section 7.4. 1972 H is the 16-octet internal hash sub-key of AES-GCM of previous 1973 session key, 1974 info' is concatenation of the arbitrary ASCII string "Sustains an 1975 FSP connection", which is 26-octet long and the 4 octets in network 1976 order of the 32-bit unsigned integer that specifies the batch index 1977 of the session key. 1979 BLAKE2b algorithm with key is applied. The key applied MUST be the 1980 master key Km. 1982 The result Ks' is the new session key, together with the new salt 1983 meant to be form the IV. 1985 The batch index of the initial session key is 1, and it is increased 1986 by 1 every time before it is to re-key. 1988 7.6. Sample Sequence of Installing Session Key 1990 This section is informative. 1992 Node A Node B 1993 ULA-A FSP-A FSP-B ULA-B 1994 {Send Km-A} 1995 ->[seq_a2b_0] -> 1996 {Send Km-B} 1997 <- [seq_b2a_0]<- 1998 . 1999 . 2000 . 2001 {Commit} 2002 ->[seq_a2b_m c/w EoT] -> 2003 {Install Key} 2004 . 2005 {Wait} . 2006 . 2007 {Commit} 2008 <- [seq_b2a_n c/w EoT]<- 2009 {Install Key} 2010 . 2011 . {Send Further} 2012 <- [seq_b2a_n+1]<- 2013 . 2014 {Send Further} . 2015 ->[seq_a2b_m+1] -> 2017 o Send Km-A, Send Km-B 2019 ULA of node A and node B send there key material for key 2020 establishment, respectively. 2022 * Commit 2024 ULA of node A or node B informs the FSP layer to set the End of 2025 Transaction flag of the last packet to send and flush the send 2026 buffer. 2027 * Install Key 2029 ULA of node A or node B informs the FSP layer to install new 2030 session key, giving key materials for deriving the session key. 2032 A node may call Install Key if and only if its peer has just 2033 committed a transmit transaction. 2034 * Wait 2036 The ULA MUST wait until it has received some packet with EoT 2037 set from its peer before it may install new session key. 2039 There is no mandatory calling order of Commit and Install Key. 2040 However, if a node Commit before Install Key and it wants to 2041 apply new session key for the transmit transaction next to the 2042 one it has just committed, it SHALL NOT send further data until 2043 Install Key has returned successfully. 2045 In the above example, for node A packet with sequence number 2046 [seq_a2b_m+1] will be sent by applying the new session key, for 2047 node B packet with sequence number [seq_b2a_n+1] will be sent 2048 by applying the new session key. 2049 * Send Further 2051 ULA of node A or node B sends further data in the new transmit 2052 transaction, respectively. 2054 There is no mandatory order on which node should start new 2055 transmit transaction firstly. 2057 8. Send and Receive 2059 8.1. Packet Integrity Protection 2061 8.1.1. Application of CRC64 2063 Starting from ACK_CONNECT_REQUEST, until the ULAs have installed the 2064 shared secret CRC64 is applied to calculate the value of the ICC 2065 field. The algorithm: 2067 1. Take pair of the ULDs as the initial value of accumulative CRC64 2068 2. Accumulate the value of the Init-Check-Code field 2069 3. Accumulate the value of the Cookie field successively 2070 4. Accumulate the combined value of the salt and the timeDelta field 2071 where the former is the leftmost 32 bits and the latter is the 2072 rightmost 32 bits 2073 5. Accumulate the value of the Time Stamp field 2074 6. Save the accumulated CRC64 value as the pre-computed CRC64 value 2076 The pair of the ULDs is composed of the near end's ULTID and the 2077 remote end's ULTID, where the former is the leftmost 32 bits and the 2078 latter is the rightmost 32 bits of initial value for the send 2079 direction, and the order is reversed for the receive direction. 2081 When calculate the value ICC of a particular FSP packet, firstly set 2082 ICC to the pre-computed CRC64 value, then calculate the CRC64 2083 checksum of the whole FSP packet, while ULTIDs are NOT included if 2084 the FSP packet is encapsulated in UDP. The result is set as the 2085 final value of the ICC field. 2087 8.1.2. Packet Authentication Only 2089 The ULA designates the FSP layer to either applying HMAC only or 2090 applying AEAD. 2092 If the HMAC flag of a packet is set the pre-designated cryptographic 2093 hash function SHALL be applied to get the message authentication code 2094 (MAC) of the whole packet. Each FSP version MUST designate one and 2095 only one particular cryptographic hash function. 2097 For this FSP version, BLAKE2 [RFC7693] is designated as the 2098 cryptographic hash function. The input key is the secret key that 2099 has been derived from the master key installed by the ULA. The input 2100 data is the full FSP packet, where the ICC field is pre-filled the 2101 pair of the ULDs. As in making CRC64 checksum, the pair of the ULDs 2102 is composed of the near end's ULTID and the remote end's ULTID, where 2103 the former is the leftmost 32 bits and the latter is the rightmost 32 2104 bits of initial value for the send direction, and the order is 2105 reversed for the receive direction. 2107 The hash result is truncated to 64 bits to get the final ICC. 2109 8.1.3. Authenticated Encryption with Additional Data 2111 FSP provides per-packet authenticated encryption service. Only one 2112 authenticated encryption algorithm is allowed for a determined 2113 version of FSP. For this FSP version, the authenticated encryption 2114 algorithm selected is GCM-AES [GCM][AES], it is applied to protect 2115 integrity of the full FSP packets, and privacy of the payload 2116 together with the extension headers, if any. The four inputs to GCM- 2117 AES authenticated encryption are: 2119 K: the key derived by the master key installed by ULA. The length of 2120 the session key is determined by the ULA. 2122 IV: the initial vector, 96-bit string made by concatenating a 32-bit 2123 salt, the 32-bit sequence number of the packet and the 32-bit 2124 expected sequence number field of the packet. The salt is derived by 2125 the master key installed by ULA. 2127 P: the plaintext are the bytes following the fixed header up to the 2128 end of the original payload. 2130 AAD: additional authenticated data, for this version of FSP it is the 2131 fixed header of the FSP packet. The source ULTID MUST be stored in 2132 the leftmost 32-bit of the ICC field while the destination ULTID MUST 2133 be stored in the rightmost 32-bit of the ICC field before the ICC 2134 value is calculated. 2136 The length of the authentication tag MUST be 64 bits for FSP version 2137 0 and 1. The authentication tag is stored in the ICC finally. 2139 The inputs to GCM-AES decryption are: 2141 K: the key derived by the master key installed by ULA. The length of 2142 the session key is determined by the ULA. 2144 IV: the initial vector, 96-bit string made by concatenating consisted 2145 of the 32-bit salt, the 32-bit sequence number of the packet and the 2146 32-bit expected sequence number field of the packet. 2148 C: the cipher-text are the bytes following the fixed header up to the 2149 end of the received payload. 2151 AAD: additional authenticated data, for this version of FSP it is the 2152 fixed header of the FSP packet. The source ULTID MUST be stored in 2153 the leftmost 32-bit of the ICC field while the destination ULTID MUST 2154 be stored in the rightmost 32-bit of the ICC field before the ICC 2155 value is calculated. 2157 T: The authentication tag, which is fetched from the ICC field 2158 received. 2160 Only when the outputs of GCM-AES decryption tell that the 2161 authentication tag passed verification may the receiver deliver the 2162 decrypted payload to the ULA. 2164 8.1.4. ICC of the Out-of-Band Packet 2166 When calculating the ICC of an out-band packet (KEEP_ALIVE, ACK_FLUSH 2167 or MULTIPLY), the ExpectedSN field SHALL be filled with the out-of- 2168 band serial number. The first 32-bit word of the fixed header is 2169 taken as the second salt. 2171 To get or check the ICC of the out-of-band packet the original salt 2172 value that is set on deriving the session key and stored in the 2173 internal security context MUST be XORed with the second salt value 2174 before applying GCM-AES. The original salt value MUST be recovered 2175 instantly after GCM-AES is applied. 2177 8.2. Start a New Transmit Transaction 2179 The responder starts a transmit transaction by send the 2180 ACK_CONNECT_REQ packet which MAY terminate the transmit transaction 2181 at the same time. 2183 When the initiator further acknowledges ACK_CONNECT_REQ with 2184 NULCOMMIT it both starts AND terminates a transmit transaction 2185 without sending any data: 2187 (NULCOMMIT, FREWS, SN, ExpectedSN, ICC [, Sink Parameter]) 2189 Any party MAY start a new transmit transaction by sending a PERSIST 2190 packet: 2192 (PERSIST, FREWS, SN, ExpectedSN, ICC, Payload) 2194 PERSIST packet sent by the initiator firstly acknowledges the 2195 ACK_CONNECT_REQ packet as well. 2197 8.3. Send a Pure Data Packet 2199 (PURE_DATA, FREWS, SN, ExpectedSN, ICC, Payload) 2201 After a new transmit transaction has been started further PURE_DATA 2202 packet MAY be sent until a packet with EoT flag set is sent. 2204 8.4. Commit a Transmit Transaction 2206 8.4.1. Initiate Transmit Transaction Commitment 2208 A participant of an FSP connection MAY notify its peer that a 2209 transmit transaction shall be committed by setting the EoT flag of 2210 the last packet of the transmit transaction, be it NULCOMMIT, 2211 PERSIST, PURE_DATA or MULTIPLY. 2213 8.4.2. Respond to Transmit Transaction Commitment 2215 (ACK_FLUSH, FREWS, SN, ExpectedSN, ICC) 2217 If and only if all of the packets in a transmit transaction has been 2218 received MAY ACK_FLUSH packet be sent. 2220 Whenever a legitimate packet falls in the receive window of the 2221 receiver, and the packet fills in the last gap of the sequence of 2222 current transmit transaction on receiving direction, or the packet 2223 with same sequence number has been accepted already, a responding 2224 ACK_FLUSH SHALL be sent back immediately, and the FSP layer MUST 2225 immediately notify the ULA that a transmit transaction has been 2226 committed. 2228 The sequence number (SN) of the ACK_FLUSH packet MUST equal the 2229 latest sequence number of the legitimate packets that have been sent. 2231 The out-of-band serial number SHALL increase by one whenever a new 2232 ACK_FLUSH packet is sent. 2234 8.4.3. Finalize Transmit Transaction Commitment 2236 After receiving the ACK_FLUSH packet the sender of the EoT flag 2237 migrates to the COMMITTED or CLOSABLE state from the COMMITTING or 2238 COMMITTING2 state, respectively. 2240 8.4.4. Time-out for Committing Transmit Transaction 2242 The ULA SHALL be timed-out if there is no packet was acknowledged in 2243 some hard-coded time-out. For this version of FSP the time-out is 2244 set to 30 seconds. 2246 8.5. Retransmission 2248 8.5.1. Calculation of RTT 2250 We borrows specifications for calculating RTT (and RTO) considerably 2251 from Computing TCP's Retransmission Timer [RFC6298] to calculate 2252 Retransmission Time Out (RTO). 2254 The sender maintains two state variables, SRTT (smoothed round-trip 2255 time) and RTTVAR (round-trip time variation). In addition, we assume 2256 a clock granularity of G seconds. 2258 Initial round trip time (RTT) for the Connection Initiator: Equals to 2259 the mean of the time elapsed when ACK_ INIT_CONNECT was received 2260 since INIT_CONNECT was sent, and the time elapsed till 2261 ACK_CONNECT_REQ was received since CONNECT_REQUEST was sent. 2263 Initial RTT for the Connection Responder: Equals to the time elapsed 2264 when the CONNECT_REQUEST packet was received since the 2265 ACK_INIT_CONNECT packet had been received. 2267 Initial RTT for the Initiator of Connection Multiplication: Equals to 2268 the most recent RTT of the multiplied connection. 2270 Initial RTT for the Responder of Connection Multiplication: Equals to 2271 the most recent RTT of the multiplied connection. 2273 o When the Initial RTT measurement R is made, the host MUST set 2275 SRTT <- R 2276 RTTVAR <- R/2 2278 o When a subsequent RTT measurement R' is made, a host MUST set 2280 RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| 2281 SRTT <- (1 - alpha) * SRTT + alpha * R' 2283 The value of SRTT used in the update to RTTVAR is its value before 2284 updating SRTT itself using the second assignment. That is, 2285 updating RTTVAR and SRTT MUST be computed in the above order. 2287 The above SHOULD be computed using alpha=1/8 and beta=1/4. 2289 R' SHOULD be measured whenever a packet with the SNACK extension 2290 header is received. 2292 Suppose the packet with the latest SN that is accumulatively 2293 acknowledged is P-latest, R' equals the time when the SNACK header 2294 is received, minus the time when P-latest was sent, minus the 2295 delay that the acknowledgment was made. 2297 The delay that the acknowledgment was made is stored in the 2298 "Acknowledgement Delay" field of the SNACK header. It equals the 2299 time difference between the time when the acknowledgement was sent 2300 and the time when P-latest was received. 2302 Note that the no packet with SN later than any gap described in 2303 the SNACK header is considered as the packet with the latest SN 2304 that is accumulatively acknowledged. 2306 8.5.2. Generation and transmission of SNACK 2308 Whenever the receiver receives a packet it SHALL shift the time to 2309 send next heartbeat signal earlier to the time of RTT since current 2310 time, if the time to send next heartbeat signal used to be later. If 2311 the time is already earlier than the time of RTT since current time, 2312 it needs not be shifted. 2314 On the time to send the heartbeat signal the FSP node generates the 2315 SNACK header, then generate and send a new KEEP_ALIVE or ACK_FLUSH 2316 packet to carry the SNACK header. It SHALL send an ACK_FLUSH if it 2317 is in PEER_COMMIT, COMMITTING2 or CLOSABLE state, otherwise it SHALL 2318 send a KEEP_ALIVE packet. 2320 8.5.3. Negative acknowledgment of Packets Sent 2322 Both the ACK_FLUSH and the KEEP_ALIVE packet in FSP carry the SNACK 2323 extension header, although number of gap descriptors in the SNACK 2324 extension header in the ACK_FLUSH packet MUST be 0. We call them 2325 SNACK packets. A SNACK packet P1 is said to be later than P0, if and 2326 only if SN of P1 is later than SN of P0, or SN of P1 equals SN of P0 2327 while the out-of-band sequence number of P1 is later than that of P0. 2328 If the latest SNACK packet is ACK_FLUSH, all the packets with the 2329 sequence number later that the expected field of the packet are 2330 assumed to be negatively acknowledged. 2332 By convention when we specify the range, the left square bracket 2333 meant to be inclusive, while the right parenthesis meant to be 2334 exclusive, the packets with SN in the ranges: 2336 [expectedSN, expectedSN + 1st Gap Width), 2338 [expectedSN + 1st Gap Width + 1st Data Length, 2339 expectedSN + 1st Gap Width + 1st DataLength + 2nd Gap Width), 2340 ... 2341 [expectedSN + 1st Gap Width + 1st Data Length 2342 + ... + (n-1)th Gap Width + (n-1)th Data Length, 2343 expectedSN + 1st Gap Width + 1st DataLength 2344 + ... + n-th Gap Width), 2346 together with the packets with SN later than (expectedSN + 1st Gap 2347 Width + 1st DataLength + ... + n-th Gap Width), these packets are 2348 assumed to be negatively acknowledged. 2350 8.5.4. Retransmission Interval 2352 o Until RTT measurement has been made for a packet sent between the 2354 sender and receiver, the sender SHOULD set 2356 RTO <- 1 second. 2357 o After computing new SRTT, a host MUST update 2359 RTO <- SRTT + max (G, K*RTTVAR) 2361 where K = 4. 2362 o Clock granularity SHOULD be finer than 100msec, that is, it SHOULD 2363 be that G <= 0.1 second. 2364 o Whenever RTO is computed, if it is less than 1 second, then the 2365 RTO SHOULD be rounded up to 1 second. 2366 o An implementation MUST manage the retransmission timer(s) in such 2367 a way that 2369 * A packet is never retransmitted less than one RTO after the 2370 previous transmission of that packet. 2371 * Every time an in-band packet is sent (including a 2372 retransmission), if the timer is not running, start it running 2373 so that it will expire after RTO seconds (for the current value 2374 of RTO). 2375 * When all outstanding data has been acknowledged, turn off the 2376 retransmission timer. 2377 * When the retransmission timer expires, retransmit the packets 2378 that have not been acknowledged by the receiver, but limit by 2379 the rate throttling mechanism. 2380 o Rate of retransmission MUST be throttled in a way that 2382 * No more that M/2 packets may be retransmitted in a clock 2383 interval, suppose in each clock interval M packets were sent 2384 averagely. 2385 * Packet retransmission SHALL be subjected to congestion control 2386 as well. 2387 * However, at least one packet MAY be retransmitted in one clock 2388 interval, provide that the retransmission timer expires for the 2389 first packet that has not been acknowledged yet. 2391 8.6. Flow Control 2393 The participants of an FSP connection negotiate the initial receive 2394 window size with the FREWS field in the ACK_CONNECT_REQ packet, and 2395 the first PERSIST or NULCOMMIT packet that acknowledges the 2396 ACK_CONNECT_REQ packet, respectively. The receive window size SHALL 2397 NOT be less than 4 and SHALL be less than 2^24. 2399 An FSP participant advertises current receive window size in the 2400 FREWS field. 2402 An FSP participant SHALL NOT send a packet whose sequence number is 2403 later than the value of the ExpectedSN field plus the advertised 2404 receive window size, where both value come from the very packet 2405 received with the latest sequence number. 2407 8.7. Congestion Control 2409 FSP supposes that end-to-end congestion control is provided by some 2410 shim layer, such as the congestion manager [RFC3124] between the 2411 "traditional" IP layer and the FSP transport layer. The shim layer 2412 is considered as a sub-layer of the network layer. Implementation of 2413 FSP MUST provide such shim layer if the network layer of the end node 2414 does not provide end-to-end congestion management service. 2416 FSP layer SHALL provide following information to the congestion 2417 manager as soon as the first packet on the fly was acknowledged by 2418 any mean, or a legitimate packet falling in the receive window with 2419 the ECE flag set is received: 2421 o The local interface number that the packet carrying the ECE signal 2422 is accepted. 2423 o The remote network prefix that the congestion information is meant 2424 to associate. Note that the aggregated host ID part is NOT 2425 included in the prefix. 2426 o The traffic class. For FSP it is bisected: MIND flag set or not. 2427 o Number of outstanding octets, including all of those in the 2428 payload AND the FSP headers. 2429 o The effective round trip time calculated in the most recent 2430 period. Note that retransmitted packets MUST be excluded on 2431 calculating the effective RTT. 2432 o Whether an ECN-Echo signal was received. The ECE flag of a 2433 legitimate packet falling in the receive window is the ECN-Echo 2434 signal. 2435 o Whether a sent packet with SRR flag set is acknowledged. 2437 The congestion manager SHOULD reduce the send rate if the FSP sender 2438 informed it that an ECN-Echo signal was received. 2440 The sender SHALL NOT inform the congestion manager to reduce the send 2441 rate again even if further packet with ECE flag set is received, 2442 until at least one sent packet with SRR flag set is acknowledged. 2444 A packet with ECE flag set received after the packet with SRR flag 2445 set is acknowledged SHOULD make the congestion manager reduce the 2446 send rate again. 2448 Retransmitted packet SHALL be subjected to send rate control at the 2449 underlying congestion management service sub-layer as well. 2451 Quota or other means to enforce fairness among various FSP 2452 connections SHOULD be provided directly to the ULA by the congestion 2453 management service. 2455 Requirement of an FSP congestion manager would be detailed in a 2456 separate document. 2458 8.8. On-the-Wire Compression 2460 FSP exploits the lossless compression algorithm as per [LZ4]. 2462 If the CPR flag of the first packet of a transmit transaction is set, 2463 compression is applied on the payload octet stream of the transaction 2464 transaction. 2466 When applying compression FSP divides source stream into multiple 2467 blocks. For this version of FSP length of each block is 128KiB 2468 (131072 octets), except the final block whose length may be less than 2469 or equal to 128KiB. The final block is the one that terminate the 2470 transmit transaction, i.e. which contains the last FSP packet of the 2471 transmit transaction. The last FSP packet of the transmit 2472 transaction has the EoT flag set. The "LZ4_compress_fast_continue" 2473 method SHALL be applied on each block. That is, data from previous 2474 compressed blocks are taken use for better compression ratio. 2476 When transferring the result data of compressing each block, the 2477 result data is prefixed with its length. The length is expressed by 2478 a 4-octets little-endian integer. 2480 On-the-wire compression of each transmit transactions is independent. 2481 It is the upper layer application that SHALL make agreement on which 2482 transmit transaction utilizes on-the-wire compression. 2484 8.9. Milk Like Payload and Minimal Delay Service 2486 An ordinary data flow is wine-like in the sense that the older data 2487 are more valuable. If it has to, data packet sent latest are dropped 2488 first. In the contrary, milk-like payload is that the newer data are 2489 more precious and outdated data packet can be discarded. 2491 When ULA is willing to accept incomplete message the peer of the 2492 underling FSP node SHALL set the MIND flag of the first PERSIST 2493 packet that starts the first transmit transaction, and set the MIND 2494 flag of every following PURE_DATA packet, while set the Traffic Class 2495 of the underlying IPv6 packet to some registered value. 2497 In the transmission path, any relaying middle box, be it router or 2498 switch, should reserve a reasonably short queue for the packet flow 2499 of such flow to minimize delay. 2501 When the receive buffer overflows the receiver discards the 2502 undelivered packet received first to free buffer space for the latest 2503 packet received. However it keeps order on delivering the packets to 2504 he ULA. ULA may choose to discard packets received earlier than some 2505 threshold. 2507 The receiver SHOULD NOT make any acknowledgement to the packet 2508 received with the MIND flag set. 2510 Minimal delay service is asymmetric in the sense that one 2511 transmission direction the data flow may be milk-like while in the 2512 reverse direction the data flow may be wine-like. 2514 A minimal delay service data flow is terminated by ULA via some out- 2515 of-band control mechanism. 2517 9. Graceful Shutdown 2519 One participant of an FSP connection MAY initiate graceful shutdown 2520 of the connection if and only if its peer has committed the most 2521 recent transmit transaction. 2523 By initiating graceful shutdown the participant tells its peer that 2524 current transmit transaction is to be committed as well. 2526 9.1. Initiation of Graceful Shutdown 2528 (RELEASE, FREWS, SN, ExpectedSN, ICC) 2530 An FSP end node MAY initiate graceful shutdown if it is in the 2531 PEER_COMMIT, COMMITTING2 or CLOSABLE state. It SHALL NOT initiate 2532 graceful shutdown if its peer has not committed current transmit 2533 transaction. 2535 Graceful shutdown is signaled to the remote end by sending a RELEASE 2536 command packet. The FSP end node SHALL migrate to the PRE_CLOSED 2537 state just before sending the RELEASE packet. 2539 9.2. Acknowledgment of Graceful Shutdown 2541 The RELEASE packet may be accepted in the COMMITTING, COMMITTED, 2542 COMMITTING2, CLOSABLE or PRE_CLOSED state. 2544 If the legitimate RELEASE packet is received in the COMMITTING or 2545 COMMITTED state, the FSP end node SHALL buffer the RELEASE packet, 2546 wait each packet of the last transmit transaction of its peer has 2547 been received, deliver all the buffered payload and then migrate to 2548 the SHUT_REQUESTED state. 2550 If the legitimate RELEASE packet is received in the COMMITTING2 or 2551 CLOSABLE state, the FSP end node SHALL migrate to the SHUT_REQUESTED 2552 state immediately. 2554 In either of the two cases the receiver of the RELEASE packet SHALL 2555 acknowledge the sender of the RELEASE packet with a legitimate out- 2556 of-band ACK_FLUSH packet. 2558 If the RELEASE packet is received in the PRE_CLOSED state, it is to 2559 finalize the graceful shutdown procedure. 2561 9.3. Finalization of Graceful Shutdown 2563 If either the legitimate RELEASE packet or the legitimate ACK_FLUSH 2564 packet is received in the PRE_CLOSED state the grace shutdown request 2565 is supposed to be acknowledged and the shutdown procedure SHALL be 2566 finalized by that the FSP end node migrates to the CLOSED state 2567 immediately. 2569 In SHUT_REQUESTED state the FSP node SHALL migrate to CLOSED state 2570 immediately on the Shutdown API called by the ULA. 2572 9.4. Retransmission of RELEASE Packet 2574 The FSP end node in the PRE_CLOSED state SHALL retransmit the RELEASE 2575 packet until it migrates to CLOSED state or it is timed out. 2577 As RELEASE is the in-band packet retransmission of the RELEASE packet 2578 is subjected to the normal retransmission rule. 2580 10. Mobility and Multi-home Support 2582 10.1. Heartbeat Signals 2584 FSP requires that the participants periodically send the heartbeat 2585 signals. 2587 The participant in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2588 COMMITING2 or CLOSABLE state MUST send the KEEP_ ALIVE packet as the 2589 heart-beat signal periodically to retain the connection in case that 2590 underlying IP address has changed. 2592 (KEEP_ALIVE, FREWS, SN, ExpectedSN, ICC, Sink Parameter, SNACK) 2594 Heartbeat signal is an out-of-band control packet. It does not carry 2595 payload. The sequence number of the KEEP_ALIVE packet SHALL be set 2596 to the latest sequence number of all of the packets that have been 2597 sent. 2599 Only the FSP node in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2600 COMMITING2 or CLOSABLE state MAY process the heartbeat signal. 2602 In this version of FSP the heat-beat period is arbitrarily set to 600 2603 seconds. 2605 The sequence number (SN) of the KEEP_ALIVE packet MUST equal the 2606 latest sequence number of the legitimate packets that have been sent. 2608 The out-of-band serial number SHALL increase by one whenever a new 2609 KEEP_ALIVE packet is sent. 2611 10.2. Active Address Change Signaling 2613 During communication process the FSP participant whose underlying IP 2614 address is changed SHOULD inform its peer such change by transmit a 2615 KEEP_ALIVE packet with the Sink Parameter extension header and the 2616 SNACK header so that the peer can retransmit the packets that were 2617 negatively acknowledged. 2619 Such informing KEEP_ALIVE packet SHALL be sent in the ACTIVE, 2620 COMMITTING, COMMITTED, PEER_COMMIT, COMMITING2 or CLOSABLE state. 2622 Informing KEEP_ALIVE packet SHOULD be sent more frequently than a 2623 normal heart-beat signaling KEEP_ALIVE packet. 2625 For this version of FSP informing KEEP_ALIVE packet SHALL be 2626 retransmitted every 4 RTT interval until the heuristic 2627 acknowledgement is received. 2629 10.3. Heuristic Remote Address Change Adaptation 2631 A participant of the FSP connection SHALL set the source address of 2632 the packet to transmit or retransmit to new IP address as soon as the 2633 near-end IPv4 address or IPv6 network prefix has changed. The ULTID 2634 field MUST remain the same. 2636 When a new packet with a later sequence number is received and the 2637 source IP address of the packet is found to be different with the 2638 preserved IP address of the remote end, the receiver SHOULD 2639 automatically update the preserved IP address of the remote end to 2640 the source IP address of the new packet, unless there is a Sink 2641 Parameter header in the packet. 2643 If the sequence number of the packet received is not the latest in 2644 the receive window the preserved IP address of the remote end SHALL 2645 NOT be updated even if the source address of the received packet has 2646 changed. 2648 10.4. Heuristic Address Change Acknowledgement 2650 The address change signaling KEEP_ALIVE packet is supposed to be 2651 acknowledged if a packet targeted at the new IP address that the 2652 KEEP_ALIVE packet has informed is received. 2654 10.5. NAT-traversal and Multihoming 2656 When FSP is implemented over UDP in the IPv4 network, each endpoint 2657 of the FSP connection is bound one and only one IPv4 address as soon 2658 as the connection is established. Each endpoint SHALL choose the 2659 source IPv4 address of the last packet received as the destination 2660 IPv4 address of the packet that it is to send later. By this mean 2661 FSP over UDP is NAT-friendly. 2663 When FSP is implemented over IPv6 as soon as the connection is 2664 established the IPv6 address may be changed dynamically, and one more 2665 alternate IP address may be added or removed dynamically for 2666 individual endpoint as well, provided that ULTID part keeps unchanged 2667 while the host IDs part of all IPv6 address of the endpoint are of 2668 the same value at any given moment. 2670 The sender may choose as the source IP address by selecting any 2671 network prefix that it has most-recently sent to its peer in the 2672 allowed address list field of the Sink Parameter header, joining with 2673 the host ID in the Sink Parameter header and the stable ULTID of the 2674 sender, and choose as the destination IP address by selecting any 2675 network prefix in the allowed address list field of the Sink 2676 Parameter header most-recently received from its peer, joining with 2677 the peer's host ID and the peer's ULTID. Thus multiple multi-homed 2678 paths MAY co-exist between the two FSP endpoints. 2680 10.6. Explicit Multi-home Informing 2682 If an FSP end node is configured with multiple IPv4 address other 2683 than the loop-back address, or with multiply global unicast IPv6 2684 address, it MAY advertise multiple underlying addresses to the remote 2685 end by put them in the addressable network prefix list of the Sink 2686 Parameter extension header. The Sink Parameter extension header may 2687 be carried in the CONNECT_REQUEST, ACK_CONNECT_REQ, NULCOMMIT, 2688 MULTIPLY or KEEP_ALIVE packet. 2690 Any participant of the communication SHALL NOT make discrimination of 2691 the source or destination IP address of any packet provided that both 2692 the source ULTID and the destination ULTID keep unchanged and the ICC 2693 field passes verification. 2695 11. Connection Multiplication 2697 Connection multiplication is the process of incarnating a new 2698 connection context by re-using security context of an established 2699 connection. 2701 11.1. Request to Multiply Connection 2703 (MULTIPLY, FREWS, SN, Salt, ICC [, Sink Parameter] [, payload]) 2705 The initiator's initial sequence number of the new connection is the 2706 sequence number of the packet that piggybacks the connection 2707 multiplication header. The ExpectedSN field of the normal packet 2708 store a Salt value instead. 2710 The FREWS field MUST be processed in the new connection context while 2711 the ICC MUST be calculated with the session key of the original 2712 connection. 2714 The new connection inherits the remaining key life. ULA SHOULD 2715 negotiate new session key and/or install new session key as soon as 2716 possible. 2718 The optional payload of the MULTIPLY packet MUST be processed in the 2719 new connection context. 2721 The MULTIPLY packet is an out-of-band command packet in the original 2722 connection context. 2724 11.2. Response to Connection Multiplication Request 2726 Case 1: (NULCOMMIT, FREWS, SN, ExpectedSN, ICC [, Sink Parameter]) 2727 Case 2: (PERSIST, FREWS, SN, ExpectedSN, ICC, Payload) 2728 Case 3: (RESET, Reason of Failure, SN, ExpectedSN, ICC) 2730 In all of these cases the ULTID of the remote-end MUST be the value 2731 of the initiator's ULTID in the connection multiplication header. 2733 It is REQUIRED that only a connection in the ESTABLISHED, COMMITTING, 2734 COMMITTED, PEER_COMMIT, COMMITTING2 or CLOSABLE state may accept a 2735 connection multiplication request. 2737 In case 1 the responder admits the multiplication request AND commit 2738 the transmit transaction, the new connection enters into the 2739 PEER_COMMIT or CLOSABLE state immediately, on request of ULA. 2741 In case 2 the responder admits the multiplication request and the new 2742 connection enters into the ESTABLISHED, PEER_COMMIT, COMMITTING or 2743 CLOSABLE state immediately, depending whether the ULA of the 2744 multiplication initiator has requested to commit the transmit 2745 transaction immediately and whether the ULA of the multiplication 2746 responder has requested to commit the transmit transaction in the 2747 reverse direction immediately. 2749 In case 3 the responder rejects the multiplication request. To 2750 defend against spoofing attack ICC MUST be valid. The value of the 2751 SN field MUST equal the value of the 'Expected SN' field of the 2752 requesting MULTIPLY packet while the value of ExpectedSN field MUST 2753 equal the value of the 'Sequence No' field. 2755 The new connection MUST derive new session key from the session key 2756 of the original connection where the out-of-band requesting MULTIPLY 2757 packet is received immediately. 2759 11.3. Duplicate Detection of Connection Multiplication Request 2761 Every time the responder of connection multiplication receives a 2762 MULTIPLY packet it MUST check the suggested responder's ULTID and the 2763 initiator's ULTID. 2765 The responder MUST reject the multiplication request if the suggested 2766 responder's ULTID equals the near-end ULTID of some connection and 2767 the remote-end ULTID of that connection does not equal the 2768 initiator's ULTID. 2770 The responder MUST recognize the MULTIPLY packet as a duplicate 2771 connection request if some connection matches the request and SHOULD 2772 response by retransmitting the head packet of the send queue of the 2773 matching connection, be it a PERSIST or a NULCOMMIT packet. A 2774 connection matches the MULTIPLY request if and only if the suggested 2775 responder's ULTID in the MULTIPLY packet equals the near-end ULTID of 2776 the connection and the initiator's ULTID equals the remote-end ULTID 2777 of the connection. 2779 11.4. Retransmission 2781 The initiating side SHALL retransmit the MULTIPLY packet if the 2782 corresponding PERSIST packet is not received in some limit time (by 2783 default 15 seconds). 2785 11.5. Key Derivation for Branch Connection 2787 Let K_out = BLAKE2(Km, [d] || Label || 0x00 || Context || L), where: 2789 * Km is the master key, 2790 * [d] is one octet of integer Depth. It is alike the KDF counter 2791 mode as the NIST SP800-108. For this version of FSP it is the 2792 fixed number 1, 2793 * Label is the fixed ASCII string "Multiply an FSP connection" 2794 which is 26-octet long for this version of FSP, 2795 * Context is concatenation of two 32-bit words idB and idR 2797 idB is the ULTID allocated for the branch connection in the 2798 context of the multiplication initiator. idB is byte-order 2799 neutral. 2801 idR is the receiver side ULTID of the original connection that 2802 is to accept the connection multiplication request. idI or idR 2803 is byte-order neutral. 2804 * L is a 32-bit network byte-order integer specifying the length 2805 in bits of the derived key K-out 2807 12. Timeouts and Abrupt Close 2809 12.1. Timeouts in End-to-End Negotiation 2811 Initially the initiator is in the CONNECT_BOOTSTRAP state. It 2812 migrates to the CONNECT_ AFFIRMING state after it received the 2813 legitimate ACK_INIT_CONNECT packet. Then it migrates to the 2814 PEER_COMMIT or CLOSABLE state after it received the legitimate 2815 ACK_CONNECT _REQ packet, depending on the hint of ULA. 2817 The responder incarnates a new connection context which is initially 2818 in the CHALLENGING state after accepting a legitimate Connect Request 2819 packet. Then it migrates to the COMMITTING or CLOSABLE state, 2820 depending on the packet received from its peer. 2822 If the initiator or the responder is unable to migrate to a new state 2823 in some limit time (by default 60 seconds, except in LISTENING state) 2824 it aborts the connection by recycling the connection context. 2826 12.2. Timeouts in Multiply 2828 Initially the initiating side of Connection Multiplication is in the 2829 CLONING state. It migrates to the ACTIVE, COMMITTED, PEER_COMMIT or 2830 CLOSABLE state after it received the legitimate PERSIST packet. 2831 Which state to migrated depends on the EoT flag of the initiating 2832 MULTIPLY packet and the responding PERSIST packet. 2834 If the initiating side is unable to migrate to a new state in some 2835 limit time (by default 60 seconds) it aborts multiplication by 2836 recycling the new connection context. 2838 12.3. Timeout of Transmit Transaction Commitment 2840 The FSP node MUST abort the connection if the time of no packet 2841 having arrived has exceed certain limit in the COMMITTING or 2842 COMMITTING2 state. 2844 In this FSP version, timeout of transmit transaction commitment is 2845 set to 5 minutes. 2847 12.4. Timeout of Graceful Shutdown 2849 It simply migrates to the NON_EXISTENT pseudo-state if timeout in the 2850 PRE_CLOSED state. 2852 In this FSP version, timeout of Graceful Shutdown is set to 1 minute. 2854 12.5. Idle Timeout 2856 If one participant has not received any packet nor has it sent any 2857 packet in some limit time, it MUST be abruptly closed. 2859 In this FSP version the time limit, or the idle timeout, is set to 4 2860 hours. 2862 12.6. Session Key Timeout 2864 For this FSP version if a secret key is applied for more than 2^30 2865 times the FSP node MUST abruptly closed instantly. 2867 12.7. Abrupt Close 2869 An FSP node abruptly shutdown a session by sending a RESET packet and 2870 release all of the resource occupied by the the session immediately. 2872 (RESET, Reason of Failure, SN, ExpectedSN, ICC) 2874 13. Issues for Further Study 2876 13.1. Resolution of ULTID in DNS 2878 There are two patterns of IP address resolution in FSP: the DNS- 2879 compatible pattern and the proxy pattern. The former pattern relies 2880 on some name service to resolve the IP address of the responder for 2881 the initiator before they exchange end-to-end negotiation packets. 2883 In the DNS-compatible pattern, the responder side of the FSP 2884 participants registered its address identifier, such as 'domain name' 2885 in some name service such as DNS [RFC1034][RFC1035], according to 2886 some pre-agreement at first. The initiator resolves the current IP 2887 address of the responder by consulting the name service, such as 2888 looking after the A or AAAA record [RFC3596] of the domain name in 2889 DNS. 2891 If UDP over IPv4 is exploited as the under layer data packet delivery 2892 service the port number of the responder is firstly resolved just 2893 alike normal network application such as HTTP. Then it is extended 2894 to 32-bit ULTID, and ULTIDs of FSP can be considered as the superset 2895 of TCP port numbers. 2897 If the string representation of IPv4/IPv6 address is applied directly 2898 as the peer's address identifier instead of the domain name there is 2899 no need for some real address resolution. But from the API caller's 2900 point of view it is a DNS-compatible mode address resolution. 2902 13.2. Proxy Pattern for Syndicated Name Resolution 2904 The proxy pattern of IP address resolution in FSP is to embed the 2905 address resolution information in the connection initialization 2906 packets and is designed to work in FSP over IPv6 mode only. 2908 In IPv6 network the rightmost 32 bits of the IPv6 address directly 2909 maps to the ULTID so FSP does not need additional multiplexing 2910 mechanism such as port number. And it needs not consult SRV record 2911 or look for some entry in some 'services' file. 2913 If the INIT_CONNECT packet carries the responder's host name it MUST 2914 take the link-local interface address as the source IPv6 address and 2915 the default link-local gateway address, FE80::1, as the destination 2916 IPv6 address no matter whether the global unicast IP address of the 2917 default gateway is configured. In such scenario the link-local 2918 gateway MUST be able to resolute the responder's host name to its 2919 global unicast IPv6 address, and the gateway MUST be able to map the 2920 initiator's link local address to its global unicast IPv6 address. 2922 If the gateway that relays the INIT_CONNECT packet finds that the 2923 responder is on the same link-local network with the initiator it 2924 SHALL change the source and the destination IP addresses of the 2925 INIT_CONNECT packet to the link-local IP addresses of the initiator 2926 and the responder respectively, and relay the packet onto the same 2927 link-local network. 2929 On receiving the INIT_CONNECT packet that carries the responder's 2930 host name the link-local gateway MUST resolute the responder's global 2931 unicast IPv6 address and map the initiator's global unicast IPv6 2932 address, and replace the destination and source address of the 2933 INIT_CONNECT packet respectively, unless it finds that the initiator 2934 and the responder are on the same link-local network, where the 2935 gateway SHALL process the packet as stated in the previous statement. 2937 13.3. Asymmetric Transmission 2939 If there is one participant whose receive interface is not the same 2940 as the send interface the participant is called an asymmetric- 2941 transmission node. 2943 Asymmetric transmission itself is asymmetric in the sense that one 2944 participant may be asymmetric-transmission node while its peer is a 2945 normal node that the send interface is the same receive interface. 2947 An end node is asymmetric-transmission if it received an 2948 ACK_CONNECT_REQ packet, NULCOMMIT or PERSIST packet whose source IP 2949 address that the network interface accepting the packets reported is 2950 not in the allowed IP address list in the Sink Parameter header of 2951 the packet. 2953 For an asymmetric-transmission remote end, the near end cannot rely 2954 on automatic IP address change detection. Instead IP address change 2955 notification mechanism shall be utilized. 2957 However for this version of FSP asymmetric transmission support is 2958 optional. 2960 14. Security Considerations 2962 14.1. Deny of Service Attack 2964 FSP is designed to mitigate effect of DoS attack by exploiting Cookie 2965 . 2967 However, resistance against distributed DoS attack relies on external 2968 mechanism such as Distributed-Denial-of-Service Open Threat Signaling 2969 [I-D.ietf-dots-architecture]. 2971 14.2. Replay Attack 2973 In-band sequence number and out-of-band sequence number are exploited 2974 to resist against replay attack. 2976 14.3. Passive Attacks 2978 AEAD MAY be exploited by the ULA to protect it against passive 2979 attacks such as eavesdropping, gaining advantage by analyzing the 2980 data sent. 2982 MAC only service MAY also be utilized. Together with application 2983 layer stream-mode encryption it protects the ULA against passive 2984 attacks as well. 2986 14.4. Masquerade Attack 2988 Both AEAD and MAC only service may be exploited to protect the 2989 endpoints against masquerade attack. 2991 If proxy pattern for syndicated name resolution is exploited for FSP 2992 over IPv6, secure neighbor discovery [RFC3971] SHOULD be applied 2993 instead of common neighbor discovery whenever it is feasible. 2995 14.5. Active Man-In-The-Middle Attack 2997 The ULA SHALL take account to protect itself against MITM attack when 2998 making client authentication and key establishment. 3000 14.6. Privacy Concerns 3002 It is beneficial for privacy protection that the ULTID of each 3003 endpoints of an FSP connection is generated randomly [RFC7721]. 3005 15. IANA Considerations 3007 It should be requested that the port number registered for UDP 3008 packets encapsulating FSP in the IPv4 network. The port number 18003 3009 is exploited in the concept prototype implementation. The number is 3010 the decimal presentation of ASCII codes of the character 'F' ('x46') 3011 and 'S' ('x53') concatenated in network byte order. 3013 It should be requested that the 'Next Header'/protocol number is 3014 assigned for FSP over IPv6. Decimal number 144 is exploited in the 3015 concept prototype implementation. 3017 16. References 3019 16.1. Normative References 3021 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 3023 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 3024 Cartridges - DLT1 Format Standard, Annex B", December 3025 1992. 3027 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 3028 Galois/Counter Mode (GCM) and GMAC", November 2007. 3030 [LZ4] "LZ4: Extremely Fast Compression algorithm", 3031 . 3033 [OSI_RM] ISO and IEC, "Information technology-Open Systems 3034 Interconnection - Basic Reference Model: The Basic Model", 3035 November 1994. 3037 [R01] Rogaway, P., "Authenticated encryption with Associated 3038 Data", 2002. 3040 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3041 Communication Layers", STD 3, RFC 1122, 3042 DOI 10.17487/RFC1122, October 1989, 3043 . 3045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3046 Requirement Levels", BCP 14, RFC 2119, 3047 DOI 10.17487/RFC2119, March 1997, 3048 . 3050 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 3051 RFC 3124, DOI 10.17487/RFC3124, June 2001, 3052 . 3054 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3055 of Explicit Congestion Notification (ECN) to IP", 3056 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3057 . 3059 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3060 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 3061 2003, . 3063 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3064 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3065 2006, . 3067 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 3068 Key Derivation Function (HKDF)", RFC 5869, 3069 DOI 10.17487/RFC5869, May 2010, 3070 . 3072 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 3073 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 3074 DOI 10.17487/RFC6887, April 2013, 3075 . 3077 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 3078 Cryptographic Hash and Message Authentication Code (MAC)", 3079 RFC 7693, DOI 10.17487/RFC7693, November 2015, 3080 . 3082 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 3083 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 3084 March 2017, . 3086 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3087 (IPv6) Specification", STD 86, RFC 8200, 3088 DOI 10.17487/RFC8200, July 2017, 3089 . 3091 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 3092 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 3093 . 3095 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 3096 1981. 3098 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3099 August 1980. 3101 [STD7] Postel, J., "Transmission Control Protocol", STD 7, 3102 RFC 793, September 1981. 3104 16.2. Informative References 3106 [Gao2002] Gao, J., "Fuzzy-layering and its suggestion", IETF Mail 3107 Archive, September 2002, 3108 . 3111 [I-D.ietf-dots-architecture] 3112 Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and 3113 R. Compton, "Distributed-Denial-of-Service Open Threat 3114 Signaling (DOTS) Architecture", draft-ietf-dots- 3115 architecture-18 (work in progress), March 2020. 3117 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 3118 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 3119 . 3121 [RFC1035] Mockapetris, P., "Domain names - implementation and 3122 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3123 November 1987, . 3125 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3126 Address Translator (Traditional NAT)", RFC 3022, 3127 DOI 10.17487/RFC3022, January 2001, 3128 . 3130 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 3131 "DNS Extensions to Support IP Version 6", STD 88, 3132 RFC 3596, DOI 10.17487/RFC3596, October 2003, 3133 . 3135 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 3136 "SEcure Neighbor Discovery (SEND)", RFC 3971, 3137 DOI 10.17487/RFC3971, March 2005, 3138 . 3140 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3141 "Randomness Requirements for Security", BCP 106, RFC 4086, 3142 DOI 10.17487/RFC4086, June 2005, 3143 . 3145 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 3146 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 3147 . 3149 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3150 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3151 DOI 10.17487/RFC4861, September 2007, 3152 . 3154 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3155 Address Autoconfiguration", RFC 4862, 3156 DOI 10.17487/RFC4862, September 2007, 3157 . 3159 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 3160 Model: The Relationship between Links and Subnet 3161 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 3162 . 3164 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 3165 Assignment to End Sites", BCP 157, RFC 6177, 3166 DOI 10.17487/RFC6177, March 2011, 3167 . 3169 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3170 "Computing TCP's Retransmission Timer", RFC 6298, 3171 DOI 10.17487/RFC6298, June 2011, 3172 . 3174 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 3175 the IPv6 Prefix Used for IPv6 Address Synthesis", 3176 RFC 7050, DOI 10.17487/RFC7050, November 2013, 3177 . 3179 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 3180 Considerations for IPv6 Address Generation Mechanisms", 3181 RFC 7721, DOI 10.17487/RFC7721, March 2016, 3182 . 3184 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 3185 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 3186 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3187 RFC 8415, DOI 10.17487/RFC8415, November 2018, 3188 . 3190 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 3191 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 3192 January 2019, . 3194 Appendix A. Acknowledgements 3196 Author's Address 3198 Jun-an Gao 3199 Beijing Capital Highway Development Group Co.,Ltd. 3200 Shoufa Plaza-A, Liuliqiao South, Fengtai 3201 Beijing 3202 People's Republic of China 3204 Email: jagao@outlook.com