idnits 2.17.1 draft-gao-flexible-session-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2018) is 2009 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3315' is defined on line 2802, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 2812, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 2827, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 2836, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 2841, but no explicit reference was found in the text == Unused Reference: 'RFC5072' is defined on line 2846, but no explicit reference was found in the text == Unused Reference: 'RFC5116' is defined on line 2850, but no explicit reference was found in the text == Unused Reference: 'RFC5942' is defined on line 2854, but no explicit reference was found in the text == Unused Reference: 'RFC6059' is defined on line 2859, but no explicit reference was found in the text == Unused Reference: 'RFC6177' is defined on line 2864, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 2869, but no explicit reference was found in the text == Unused Reference: 'RFC7050' is defined on line 2873, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 2878, but no explicit reference was found in the text == Unused Reference: 'RFC7323' is defined on line 2883, but no explicit reference was found in the text == Unused Reference: 'RFC7608' is defined on line 2888, but no explicit reference was found in the text == Unused Reference: 'RFC8084' is defined on line 2898, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 2906, but no explicit reference was found in the text == Unused Reference: 'RFC8170' is defined on line 2911, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. 'STD7') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 2 errors (**), 0 flaws (~~), 19 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Gao 3 Intended Status: Experimental 4 Expires: April 19, 2019 October 16, 2018 6 Flexible Session Protocol 7 draft-gao-flexible-session-protocol-01 9 Abstract 11 FSP is a connection-oriented transport layer protocol that provides 12 mobility and multihoming support by introducing the concept of 'upper 13 layer thread ID', which is associated with some shared secret that is 14 applied to protect authenticity of the origin of the FSP packets. 16 It introduces the concept of transmit transaction to facilitate a 17 quad-party sub-protocol for shared secret installation. 19 It provides transport layer features of zero round-trip connection 20 multiplication and on-the-wire compression, in addition to ubiquitous 21 message authentication with optional encryption service. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.1. High Mobility . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 6 63 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2. Abbreviations and Idioms . . . . . . . . . . . . . . . . . . . 7 65 3. Key Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Underlying Layer Services Required . . . . . . . . . . . . 9 67 3.1.1. Packet Delivery . . . . . . . . . . . . . . . . . . . . 9 68 3.1.2. Network Address Change Notification . . . . . . . . . . 9 69 3.1.3. Network Congestion Control . . . . . . . . . . . . . . 10 70 3.2. Identifying Connection by Local ULTID . . . . . . . . . . . 10 71 3.3. Defending Against Connection Redirection with ICC . . . . . 10 72 3.4. Transmit Transaction . . . . . . . . . . . . . . . . . . . 11 73 3.5. Quad-party Session Key Installation Sub-protocol . . . . . 11 74 3.6. Zero Round-Trip Connection Multiplication . . . . . . . . . 12 75 4. Packet Structure . . . . . . . . . . . . . . . . . . . . . . . 13 76 4.1. FSP over UDP/IPv4 . . . . . . . . . . . . . . . . . . . . . 13 77 4.2. FSP over IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.3. Generic FSP Header . . . . . . . . . . . . . . . . . . . . 15 79 4.4. FSP Header Signature . . . . . . . . . . . . . . . . . . . 15 80 4.4.1 Header Stack Pointer . . . . . . . . . . . . . . . . . . 15 81 4.4.2 Major . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.4.3 Operation Code . . . . . . . . . . . . . . . . . . . . . 16 83 4.5. Preliminary FSP Packets . . . . . . . . . . . . . . . . . . 18 84 4.5.1. Connect Initialization . . . . . . . . . . . . . . . . 18 85 4.5.2. Acknowledgment to Connect Initialization . . . . . . . 19 86 4.5.3. Connect Request . . . . . . . . . . . . . . . . . . . . 20 87 4.6. Normal Fixed Header . . . . . . . . . . . . . . . . . . . . 21 88 4.7. Sink Parameter . . . . . . . . . . . . . . . . . . . . . . 23 89 4.8. Selective Negative Acknowledgment . . . . . . . . . . . . . 25 90 4.9. RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5. The Finite State Machine . . . . . . . . . . . . . . . . . . . 27 93 5.1. NON_EXISTENT . . . . . . . . . . . . . . . . . . . . . . . 27 94 5.2. LISTENING . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 5.3. CONNECT_BOOTSTRAP . . . . . . . . . . . . . . . . . . . . . 27 96 5.4. CONNECT_AFFIRMING . . . . . . . . . . . . . . . . . . . . . 27 97 5.5. CHALLENGING . . . . . . . . . . . . . . . . . . . . . . . . 28 98 5.6. ACTIVE{A.K.A. ESTABLISHED} . . . . . . . . . . . . . . . . 28 99 5.7. COMMITTING . . . . . . . . . . . . . . . . . . . . . . . . 28 100 5.8 COMMITTED . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 5.9. PEER_COMMIT . . . . . . . . . . . . . . . . . . . . . . . . 29 102 5.10. COMMITTING2 . . . . . . . . . . . . . . . . . . . . . . . 30 103 5.11 CLOSABLE . . . . . . . . . . . . . . . . . . . . . . . . . 30 104 5.12 PRE_CLOSED . . . . . . . . . . . . . . . . . . . . . . . . 31 105 5.13 CLOSED . . . . . . . . . . . . . . . . . . . . . . . . . . 31 106 5.14 CLONING . . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 6. End-to-End Negotiation . . . . . . . . . . . . . . . . . . . . 32 108 6.1. Connect Initialization . . . . . . . . . . . . . . . . . . 32 109 6.2. Response to Connect Initialization . . . . . . . . . . . . 32 110 6.3. Weak Key Agreement Request . . . . . . . . . . . . . . . . 33 111 6.4. Weak Key Agreement Response . . . . . . . . . . . . . . . . 34 112 6.5. The Last Confirmation . . . . . . . . . . . . . . . . . . . 34 113 6.6. Retransmission . . . . . . . . . . . . . . . . . . . . . . 35 114 7. Quad-party Session Key Installation . . . . . . . . . . . . . 35 115 7.1. API for Session Key Installation . . . . . . . . . . . . . 36 116 7.2. Time to Call API for Session Key Installation . . . . . . . 36 117 7.3. Time to Take New Session Key into Effect . . . . . . . . . 36 118 7.4. Generating the Initial Session Key . . . . . . . . . . . . 37 119 7.5. Internal Rekeying . . . . . . . . . . . . . . . . . . . . . 38 120 8. Send and Receive . . . . . . . . . . . . . . . . . . . . . . . 39 121 8.1. Packet Integrity Protection . . . . . . . . . . . . . . . . 39 122 8.1.1. Application of CRC64 . . . . . . . . . . . . . . . . . 39 123 8.1.2. Packet Authentication Only . . . . . . . . . . . . . . 39 124 8.1.3. Authenticated Encryption with Additional Data . . . . . 40 125 8.2. Start a New Transmit Transaction . . . . . . . . . . . . . 41 126 8.3. Send a Pure Data Packet . . . . . . . . . . . . . . . . . . 41 127 8.4. Commit a Transmit Transaction . . . . . . . . . . . . . . . 41 128 8.4.1. Initiate Transmit Transaction Commitment . . . . . . . 41 129 8.4.2. Respond to Transmit Transaction Commitment . . . . . . 41 130 8.4.3. Finalize Transmit Transaction Commitment . . . . . . . 42 131 8.4.4. Time-out for Committing Transmit Transaction . . . . . 42 132 8.5. Retransmission . . . . . . . . . . . . . . . . . . . . . . 42 133 8.5.1. Calculation of RTT . . . . . . . . . . . . . . . . . . 42 134 8.5.2. Generation and transmission of SNACK . . . . . . . . . 43 135 8.5.3. Negative acknowledgment of Packets Sent . . . . . . . . 43 136 8.5.4. Retransmission Interval . . . . . . . . . . . . . . . . 44 137 8.6. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 44 138 8.7. Congestion Control . . . . . . . . . . . . . . . . . . . . 44 139 8.8. On-the-Wire Compression . . . . . . . . . . . . . . . . . . 45 140 8.9. Milk Like Payload and Minimal Delay Service . . . . . . . . 46 141 9. Graceful Shutdown . . . . . . . . . . . . . . . . . . . . . . 47 142 9.1. Initiation of Graceful Shutdown . . . . . . . . . . . . . . 47 143 9.2. Acknowledgment of Graceful Shutdown . . . . . . . . . . . . 47 144 9.3. Finalization of Graceful Shutdown . . . . . . . . . . . . . 47 145 9.4. Retransmission of RELEASE Packet . . . . . . . . . . . . . 48 146 10 Mobility and Multi-home Support . . . . . . . . . . . . . . . 48 147 10.1. Heartbeat Signals . . . . . . . . . . . . . . . . . . . . 48 148 10.2. Active Address Change Signaling . . . . . . . . . . . . . 48 149 10.3. Heuristic Remote Address Change Adaptation . . . . . . . . 49 150 10.4. Heuristic Address Change Acknowledgement . . . . . . . . . 49 151 10.5. NAT-traversal and Multihoming . . . . . . . . . . . . . . 49 152 10.6. Explicit Multi-home Informing . . . . . . . . . . . . . . 50 153 11 Connection Multiplication . . . . . . . . . . . . . . . . . . 50 154 11.1. Request to Multiply Connection . . . . . . . . . . . . . . 50 155 11.2. Response to Connection Multiplication Request . . . . . . 51 156 11.3. Duplicate Detection of Connection Multiplication Request . 51 157 11.4. Retransmission . . . . . . . . . . . . . . . . . . . . . . 52 158 11.5. Key Derivation for Branch Connection . . . . . . . . . . . 52 159 12 Timeouts and Abrupt Close . . . . . . . . . . . . . . . . . . 53 160 12.1. Timeouts in End-to-End Negotiation . . . . . . . . . . . . 53 161 12.2. Timeouts in Multiply . . . . . . . . . . . . . . . . . . . 53 162 12.3. Timeout of Transmit Transaction Commitment . . . . . . . . 53 163 12.4. Timeout of Graceful Shutdown . . . . . . . . . . . . . . . 53 164 12.5. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . . 54 165 12.6. Session Key Timeout . . . . . . . . . . . . . . . . . . . 54 166 12.7. Abrupt Close . . . . . . . . . . . . . . . . . . . . . . . 54 167 13 Issues for Further Study . . . . . . . . . . . . . . . . . . . 54 168 13.1. Resolution of ULTID in DNS . . . . . . . . . . . . . . . . 54 169 13.2. Proxy Pattern for Syndicated Name Resolution . . . . . . . 55 170 13.3. Asymmetric Transmission . . . . . . . . . . . . . . . . . 55 171 14 Security Considerations . . . . . . . . . . . . . . . . . . . 57 172 14.1. Deny of Service Attack . . . . . . . . . . . . . . . . . . 57 173 14.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 57 174 14.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 57 175 14.4. Masquerade Attack . . . . . . . . . . . . . . . . . . . . 57 176 14.5. Active Man-In-The-Middle Attack . . . . . . . . . . . . . 57 177 14.6. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 57 178 15 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 179 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 180 16.1. Normative References . . . . . . . . . . . . . . . . . . . 58 181 16.2. Informative References . . . . . . . . . . . . . . . . . . 60 182 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 183 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 185 1. Introduction 187 Flexible Session Protocol is a connection-oriented transport layer 188 provides mobility, multi-homing and multi-path support by introducing 189 the concept of 'upper layer thread ID' (ULTID), which was firstly 190 suggested in [Gao2002]. 192 An integrity check code (ICC) field associated with the ULTID is 193 designed in the FSP header to protect authenticity and optionally 194 privacy of the FSP packet. An FSP packet is assumed to originate from 195 the same source if the ICC value associated with certain destination 196 ULTID passes validation, regardless of the source or destination 197 address in the underlying layer. 199 ICC is either calculated by [CRC64] which protects FSP against 200 unintended modification, or a cryptographic hash function, or 201 cryptographically calculated with some Authenticated Encryption with 202 Additional Data ([R01]) algorithm, each of which requires a shared 203 secret key. 205 In the former case a weak key meant to obfuscate the CRC64 checksum 206 is agreed by the FSP participants. In the latter two cases, the 207 shared secret key is assumed to be installed by the upper layer 208 application (ULA). 210 The ULTID is assigned roughly the same semantics with Security 211 Parameter Index (SPI) in MOBIKE [RFC4555]. Either the weak key or the 212 shared secret key is indexed by the source or destination ULTID in 213 the local context of the sender or the receiver, respectively. 215 FSP facilitates secret key installation by introducing the concept of 216 transmit transaction. Mechanism of transmit transaction also provides 217 the session-connection synchronization service to the upper layer. 219 FSP is a transport layer protocol as specified in [RFC1122], provides 220 services alike TCP [STD5] to ULA, with session layer features as 221 suggested in [OSI/RM], most noticeably session-connection 222 synchronization. It can be argued that FSP makes it much more 223 flexible for the application layer protocols to adopt new key 224 establishment protocol/algorithm while offloading routine 225 authentication and optionally encryption of the data to the 226 underlying layers where it may be much easier to exploit hardware- 227 acceleration. 229 1.1. High Mobility 231 Here high mobility refers to scenarios such as high-speed train or 232 airplane. 234 FSP solves somewhat coarse-grain or low-speed mobility problem. Fine- 235 grain or high-speed mobility is left to the underlying physical 236 network, which is semantics specified in [RFC1122]. To make mobility 237 support work effectively it is assumed that one end-node MUST keep 238 its lower layer address reasonably stable while the other end-node 239 SHOULD NOT change its lower layer address too frequently. 241 1.2. Requirements Language 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in RFC 2119 [RFC2119]. 247 In this document, these words will appear with that interpretation 248 only when in ALL CAPS. Lower case uses of these words are not to be 249 interpreted as carrying significance described in RFC 2119. 251 1.3. Conventions 253 Conventions in describing the finite state machine (FSM) of FSP are: 255 ESTABLISHED The string of alphabetic characters designates the 256 name of the state 258 [API: Reset] Upper Layer Application Programming Interface Call 260 {Notify} Call back/notify the upper layer application 262 {new context} Additional action before or after state transition 264 [Send OPCODE_OF_FSP_PACKET] 265 Send some FSP packet 267 [Retransmit OPCODE_OF_FSP_PACKET] 268 Retransmit some FSP packet 270 {On transient state Timeout} 271 Timed-out event 273 {&& additional condition} 274 Together with some additional condition 276 --> state transition 278 |-- branch 280 2. Abbreviations and Idioms 282 o Connection 283 An FSP connection is the binding of two network nodes established 284 through some end-to-end negotiation process. It is identified by 285 the ULTID in the local context of each network node, respectively. 287 o EoT 288 A transmit transaction is said to reach End of Transaction (EoT) if 289 the EoT flag is set in a legitimate PURE_DATA, PERSIST or MULTIPLY 290 packet. We said that the packet terminates the transmit transaction 291 if the EoT flag is set. 293 An ACK_START packet both starts and marks end of a payload-less 294 transmit transaction. 296 In this version of FSP an ACK_CONNECT_REQ packet itself marks end 297 of the singular transmit transaction. 299 An FSP end node SHALL NOT send further data if it has initiated EoT 300 of its transmit direction unless a particular ACK_FLUSH packet is 301 received. The particular AKC_FLUSH packet MUST acknowledge not only 302 the packet with the EoT flag set but all of the packets sent 303 before the packet as well. 305 EoT, i.e. termination of transmit transaction is unilateral. 307 o FREWS 308 It stands for the Flag and advertised REceive Window Size. It is 309 the 32-bit combined word next to the ICC field in the normal FSP 310 fixed header. 312 o ICC 313 The Identity Check Code is a 64-bit value that depends on both the 314 session key and all of the headers of the FSP packet to include the 315 ICC, calculated with the same algorithm in the context of each FSP 316 participant. 318 Only a packet with correct ICC can be accepted by any FSP 319 participant as soon as the connection has been established. 321 Initially CRC64 is exploited to make a checksum that weekly 322 protects the FSP packet against unintentional modification. The 323 checksum is obfuscated with the initial session key to get the ICC. 324 After the ULA installed the long-term session key either some 325 cryptographic hash function or some Authenticated Encryption with 326 Additional Data algorithm shall be applied to obtain or check the 327 ICC. 329 o Session 330 An FSP session is the transport-layer association of two network 331 nodes. A full FSP session consists of one connection that was 332 established from scratch and all of its branches. 334 However for this version of FSP specification the idioms session 335 and connection are interchangeable if not explicitly specified. 337 o Session Key 338 The session key is a bit string of at least 128 bits that means to 339 resist against masquerade attack. It is either initiated during the 340 end-to-end negotiation phase or installed by the ULA after the FSP 341 connection is established. 343 The session key installed by the ULA is called the long-term 344 session key. Here long-term means that the key could be used until 345 the packet sequence space is exhausted. The packet sequence space 346 is exhausted if the number of packets that use the same key reaches 347 or exceeds 2,147,483,647(2^31-1). 349 o SN 350 Sequence Number is the unsigned 32-bit integer number assigned to 351 every FSP packet except the preliminary packets. 353 Difference of two sequence number is represented by a 32-bit signed 354 integer. If the result of SN B subtracting SN A is greater than 355 zero, we say that B is greater than A and the packet of the 356 sequence number B is later than the packet of the sequence number 357 A, although the unsigned integer representation of B may be far 358 less that A. Consequently, as the result of A subtracting B is less 359 than zero, we say that A is less than B and the packet of the 360 sequence number A is earlier than the packet of the sequence number 361 A. 363 o Transmit Transaction 364 A transmit transaction of FSP is a sequence of FSP packets that 365 were sent and marked by the ULA as one continuous stream where all 366 packets in the stream must be acknowledged before any further 367 packet is allowed to be sent. 369 A PERSIST or MULTIPLY packet always starts a transmit transaction. 371 An ACK_START packet both starts and marks end of a payload-less 372 transmit transaction. 374 For this version of FSP an ACK_CONNECT_REQ packet itself makes a 375 singular particular transmit transaction. 377 o ULA 378 The Upper Layer Application. 380 o ULTID 381 The Upper Layer Thread Identifier (ULTID) is a 32-bit word that was 382 allocated by particular network end node of an FSP connection and 383 is unique in the local context of the network end node. 385 Theoretically all of the ULAs of a network end node MAY establish 386 up to 2^31-1 FSP connections totally. Each connection MUST have a 387 unique thread identifier (ULTID) assigned in the local context of 388 the network end node. 390 A session or connection of FSP does not require a global ID. 392 3. Key Mechanisms 394 3.1. Underlying Layer Services Required 396 3.1.1. Packet Delivery 398 FSP requires that the underlying layer provides packet delivery 399 service. 401 In this version of FSP, when FSP is implemented in the IPv4 network, 402 every FSP packet MUST be encapsulated in a UDP [STD6] datagram 403 [RFC8085]. 405 When FSP is implemented over IPv6, the FSP SHALL be the immediate 406 upper layer of IPv6 [RFC8200]. 408 3.1.2. Network Address Change Notification 410 Network address change notification is mandatory only in the IPv6 411 network. 413 We split the IPv6 address of the IPv6 packet underlying FSP into 414 three parts. The leftmost 64-bit long word is the network prefix, 415 which SHOULD be the unique IPv6 prefix assigned to the host 416 [RFC8273]. The centermost 32-bit word is called the aggregation host 417 ID, and the rightmost 32-bit word is the ULTID. While the ULTID MUST 418 be kept stable even during the life of an FSP session, the network 419 prefix part MAY change when an endpoint is roaming. The aggregation 420 host ID may change as well. The network prefix part together with the 421 aggregation host ID part act as the traditional routing locator at 422 the network layer. 424 It is supposed that the network layer immediately notify FSP of the 425 network prefix and/or aggregation host ID change. 427 An participant of an FSP connection SHALL immediately notify its peer 428 whenever its underlying IPv6 address is changed with a KEEP_ALIVE 429 packet. The peer shall send packet to the participant that has 430 notified the address change with the new address. 432 It is supposed that the packet to inform the remote end to update the 433 lower layer address association could reach its destination in a 434 satisfying success rate. 436 3.1.3. Network Congestion Control 438 It is supposed that end-to-end congestion control is provided at some 439 sub-layer of the network layer. Implementation of FSP MUST include a 440 congestion manager [RFC3124] if such sub-layer service of the network 441 layer is not provided. 443 3.2. Identifying Connection by Local ULTID 445 Each FSP connection prepares a pair of ULTIDs. ULTID is assigned 446 roughly the same semantics with the Security Parameter Index (SPI) in 447 IKE [RFC4301]. An ULTID uniquely indexes a connection in the local 448 context of an FSP end node. An FSP end node relies neither source IP 449 address nor destination IP address, except the ULTID part of the near 450 end's IPv6 address to identify an FSP connection. 452 Each ULTID is allocated in the local context of the two FSP 453 participant respectively. The source ULTID and the destination ULTID 454 of an FSP packet usually differ in their values. However, the secret 455 keys indexed in the local contexts of the two end-points must have 456 the same value. 458 3.3. Defending Against Connection Redirection with ICC 460 An integrity check code (ICC) field associated with the ULTID is 461 designed in the FSP header to protect authenticity and optionally 462 privacy of the FSP packet. An FSP packet is assumed to originate from 463 the same source if the ICC value associated with certain destination 464 ULTID passes validation, regardless of the source or destination 465 address in the underlying layer. 467 On initiating FSP takes use of [CRC64] to make checksum of the FSP 468 packet to protect it against unintentional modification. The checksum 469 is taken as the ICC. 471 After the ULA has installed a shared secret key, value of ICC is 472 calculated by firstly getting the secret key associated indexed by 473 the local ULTID, then calculating the tag value with the AES-GCM 474 [GCM] authenticated encryption with additional data algorithm [R01], 475 or calculating the message authentication code with the BLAKE2 476 algorithm [RFC7693]. 478 3.4. Transmit Transaction 480 FSP facilitates shared secret key installation by introducing the 481 concept of transmit transaction. 483 A transmit transaction of FSP is a sequence of FSP packets that were 484 sent and marked by ULA as one continuous stream where all packets in 485 the stream MUST be acknowledged before any further packet is allowed 486 to be sent. 488 A flag called 'End of Transaction' (EoT) is designed in the FSP 489 header. When it is set, it marks that the transmit transaction in the 490 direction from the source of the FSP packet towards the destination 491 of the FSP packet is committed. 493 3.5. Quad-party Session Key Installation Sub-protocol 495 It is proposed that it is the ULA to do key establishment and/or end- 496 point user-agent authentication while the FSP layer provides 497 authenticated, optionally encrypted data transfer service. It is 498 arguably much more flexible for the application layer protocols to 499 adopt new key establishment algorithm while offloading routine 500 authentication and optionally encryption of the data to the 501 underlying layers where it may be much easier to exploit hardware- 502 acceleration. 504 A dedicate application program interface (API) is designed for the 505 ULA to install the secret key established by the ULA participants. 507 Protocol for installation of the shared secret key is quad-party in 508 the sense that both the upper layer application and the FSP layer of 509 the two participant nodes MUST agree on the moment of certain state 510 to install the shared secret key. 512 The ULA installs the new secret key to the FSP layer. The FSP layer 513 SHALL make it sure that the new secret key is taken into effect 514 starting from the very first packet of the transmit transaction that 515 is immediately next to the transmit transaction where API for 516 installation of the new secret key is called. 518 By committing a transmit transaction a ULA participant clearly tells 519 the underlying FSP layer that the next packet sent MAY adopt a new 520 secret key. On receiving a packet with the EoT flag set the ULA is 521 informed that the next packet received MAY adopt a new shared secret 522 key. 524 The ULA participant that installs the new secret key firstly MUST be 525 the one that is committing a transmit transaction after it has 526 accepted peer's transmit transaction commitment. 528 After the ULA install a new secret key every packet sent later than 529 the one with the EoT flag set MUST adopt the new secret key. The peer 530 MUST have commit a transmit transaction and it SHALL install the same 531 secret key on receiving the FSP packet with the EoT flag set. 533 The ULA SHOULD have installed the new shared secret key, or install 534 it instantly after accepting the packet with the EoT flag set. 536 If the new secret key has ever been installed the packet received 537 after the one with the EoT flag set MUST adopt the new secret key. 539 In a typical scenario the ULA endpoints first setup the FSP 540 connection where resistance against connection redirection is weakly 541 enforced by CRC64. After the pair of ULA endpoints establish a shared 542 secret key, they install the secret key and commit current transmit 543 transactions. Authenticity of the FSP packets sent later is 544 cryptographically protected by the new secret key and resistance 545 against various attacks is secured. 547 Although transmit transaction is actually uni-directional the secret 548 key is shared bi-directionally in this version of FSP. 550 3.6. Zero Round-Trip Connection Multiplication 552 An FSP connection MAY be multiplied to get a branch or branches of 553 the connection. In this version of FSP a branch connection SHALL NOT 554 be multiplied further, and only the connection where authenticity of 555 the packets is cryptographically protected may be multiplied. 557 The packet that carries the command to multiply an established FSP 558 connection MUST be sent from a new allocated local ULTID towards the 559 destination ULTID of the original connection. It is an out-of-band 560 packet in the context of the original connection and it MUST be 561 cryptographically protected by the secret key of the original 562 connection. The packet MAY carry payload. 564 The receiver of the packet MUST allocate a new local ULTID, accept 565 the optional payload in the new context associated with the new 566 ULTID, derive a new secret key from the secret key of the original 567 connection, and responds from the new context. The response MAY carry 568 payload. 570 The very first response packet MUST be protected by the new secret 571 key. The sender of the multiply command packet MUST automatically 572 inaugurate the same secret key, derived from the secret key of the 573 same original connection. And it MUST treat the response packet as 574 though a transmit transaction had been committed by the responder, 575 i.e. authenticity of the response packet is verified with the new 576 secret key. 578 Thus the branch connection of a new pair of ULTIDs is established 579 with zero round-trip overhead. This mechanism may be exploited to 580 provide expedited data transfer or parallel data transfer service. 582 4. Packet Structure 584 4.1. FSP over UDP/IPv4 586 In this version of FSP, when FSP is implemented in the IPv4 network, 587 every FSP packet MUST be encapsulated in a UDP datagram. The UDP 588 datagram encapsulated the FSP packet SHALL have the checksum 589 disabled. The Source and the destination ULTIDs are put at the 590 leading position of the UDP payload. FSP fixed header, optional 591 extension headers and FSP payload follow the ULTIDs: 593 0 15 16 31 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Source Port | Destination Port | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Length | 0 | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Source Upper Layer Thread ID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Destination Upper Layer Thread ID | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | 604 ~ FSP Fix Header ~ 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 ~ Optional FSP Extension Headers ~ 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 ~ ~ 610 ~ Optional FSP payload ~ 611 ~ ~ 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 1 FSP over UDP 616 4.2. FSP over IPv6 617 When FSP is implemented over IPv6, the ULTID part is embedded in the 618 IPv6 address. FSP fixed header follows the IPv6 headers: 620 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 621 ~ IPv6 Header: ~ 622 0 15 16 31 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |Version| Traffic Class | Flow Label | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Payload Length | Next Header | Hop Limit | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | | 629 + Source Network Prefix + 630 | | 631 + Source Address ----------------------------+ 632 | Source Aggregation Host ID | 633 + ----------------------------+ 634 | Source Upper Layer Thread ID | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | | 637 + Destination Network Prefix + 638 | | 639 + Destination Address ---------------------------------+ 640 | Destination Aggregation Host ID | 641 + ---------------------------------+ 642 | Destination Upper Layer Thread ID | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 ~ ~ 645 ~ Optional IPv6 Headers ~ 646 ~ ~ 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | | 649 ~ FSP Fix Header ~ 650 | | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 ~ Optional FSP Extension Headers ~ 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 ~ ~ 655 ~ Optional FSP payload ~ 656 ~ ~ 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Figure 2 FSP over IPv6 661 o Network Prefix 662 The leftmost 64-bit of the IPv6 address which MAY and usually do 663 have different value at the difference interface of an IPv6 end- 664 node. 666 o Aggregation Host ID 667 The left 32-bit part of the rightmost 64-bit long word of the IPv6 668 address. All of the aggregation host ID parts of an IPv6 end-node's 669 IPv6 addresses MUST have the same value for this version of FSP. 671 4.3. Generic FSP Header 673 FSP headers include the fixed header and the extension headers. A 674 general fixed header consists of 20-byte operation-code specific 675 fields and a 32-bit FSP Header Signature. An extension header 676 consists an operation-code specific content and a 32-bit FSP Header 677 Signature. The length of the extension header content may be 678 variable, provided that the tail of the full extension header align 679 on 64-bit boundary. 681 0 31 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 ~ ~ 684 ~ Operation Code Specific Fields ~ 685 ~ ~ 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Header Signature | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Figure 3 FSP Header 692 4.4. FSP Header Signature 694 0 15 16 31 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Header Stack Pointer | Major | Operation Code| 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 Figure 4 FSP Header Signature 701 4.4.1 Header Stack Pointer 703 For the fixed header the header stack pointer is a 16-bit unsigned 704 integer that specifies the offset of the first octet of the payload. 706 For an extension header the header stack pointer is a 16-bit unsigned 707 integer that specifies the offset of the first octet of the very 708 extension header. 710 The offset that the header stack pointer specifies starts from the 711 begin of the FSP fixed header. If its value is 24 the header contains 712 it is the last extension header or the fix header without any 713 extension. 715 4.4.2 Major 717 It is an octet states current FSP major version. For this FSP version 718 it MUST be 0. 720 It is not mandatory for different major versions of FSP to be 721 compatible. 723 4.4.3 Operation Code 725 It is an octet that stores the code of the command which indicates 726 the function of the packet. 728 Synonym Code Meaning 730 INIT_CONNECT 1 Initialize Connection 732 ACK_INIT_CONNECT 2 Acknowledge Initialization of Connection 734 CONNECT_REQUEST 3 Formally Request to Connect 736 ACK_CONNECT_REQ 4 Acknowledge the Connection Request 738 RESET 5 Reset a connection 739 Refuse to 740 establish the connection, or abort 741 connection. 742 ACK_START 6 ACKnowledgement to start a connection 743 It is the acknowledgement to 744 ACK_CONNECT_REQ or MULTIPLY, to confirm 745 that the connection has been established 746 or multiplied. It MUST be payload-less, 747 and its EoT flag is always assumed to be 748 set. It MAY carry optional headers. It 749 always consumes a slot of the send 750 sequence space. It is supposed to both 751 start and commit a payload-less transmit 752 transaction which SHALL be skipped. 754 KEEP_ALIVE 7 Keep the peer alive 755 It is an out-of-band control packet 756 acting as the heart-beating signal. An 757 out-of-band control packet does not 758 consume send sequence space itself. FSP 759 takes use of the KEEP_ALIVE packet to 760 inform the peer about the change of the 761 source IP addresses. Besides, when the 762 MIND flag is set, the KEEP_ALIVE packet 763 is meant to tell the peer which packets 764 should be retransmitted. If the End of 765 Transaction flag of the KEEP_ ALIVE 766 packet is set it is meant to forcefully 767 commit current transmit transaction of 768 the sender of the KEEP_ALIVE packet. 770 PERSIST 8 Make a connection persistent 771 It is meant to start a new transmit 772 transaction after a connection migrated 773 to CLOSABLE state. It can also 774 acknowledge ACK_CONNECT_REQ or MULTIPLY. 775 It MUST either carry payload, or get the 776 EoT flag set with or without payload. It 777 always consumes a slot of the send 778 sequence space. 780 PURE_DATA 9 Pure Data 781 It does not carry any optional header. 783 ACK_FLUSH 10 ACKnowledge to remote end's commitment 784 (FLUSHing) of transmit transaction. It 785 is an out-of-band control packet like 786 KEEP_ALIVE. It is sent instantly on 787 having every packet of the last transmit 788 transaction received, meant to make 789 acknowledgment to the remote end and let 790 the remote end stop sending heart-beat 791 signals. If the End of Transaction flag 792 of the ACK_FLUSH packet is set it is 793 meant to commit current transmit 794 transaction of the sender of the 795 ACK_FLUSH packet as well. 797 RELEASE 11 Release the connection 798 RELEASE packet does not carry payload 799 but it always consumes a slot of the 800 send sequence space. Only when each peer 801 has committed the transmit transaction 802 may a RELEASE packet sent under the 803 request of the ULA. 805 MULTIPLY 12 Multiply the connection 806 It is sent in the context of the 807 original connection and may carry 808 payload and/or optional headers as an 809 out-of-band packet. 811 PEER_SUBNETS 17 Tell the remote end how to address 812 the sender of the packet in the reverse 813 direction. It is the code of the Sink 814 Parameter extension header. 816 SELECTIVE_NACK 18 Tell the remote end to retransmit 817 the packets that were negatively 818 acknowledged. It is the code of the 819 Selective Negative Acknowledgment 820 extension header. 822 4.5. Preliminary FSP Packets 824 Preliminary FSP packets are the packets exchanged during the end-to- 825 end negotiation phase of FSP connection establishment when it is 826 impossible to calculate ICC normally. 828 4.5.1. Connect Initialization 830 0 31 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 + Timestamp + 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | | 837 + Init-Check-Code + 838 | | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Salt | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Header Signature | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 ~ ~ 845 ~ Host Name of the Responder (optional) ~ 846 ~ ~ 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Figure 5 Connect Initialization 851 Operation Code of this type of packet is INIT_CONNECT. 853 o Timestamp 854 It is a 64-bit unsigned integer that represents number of 855 microseconds elapsed since 00:00, Jan.1, 1970, Coordinated 856 Universal Time. It may be exploited to synchronize the clocks of 857 the participants and/or estimate delay during data transmission in 858 the network. 860 o Init-Check-Code 861 It is a 64-bit random [RFC4086] bit string that means to uniquely 862 associated with the connection initiated. 864 o Salt 865 It a 32-bit random bit string that may be exploited to make secret 866 key agreement. 868 o Host Name of the Responder 869 The optional payload of the Connect Initialization packet is the 870 host name, which is encoded in UTF-8 [RFC3629] and SHOULD be 871 resolvable in DNS, of the responder. 873 4.5.2. Acknowledgment to Connect Initialization 875 0 31 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 + Cookie + 879 | | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 + Init-Check-Code + 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Time Delta | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Header Signature | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Figure 6 Acknowledgment to Connect Initialization 892 Operation Code of this type of packet is ACK_INIT_CONNECT. 894 o Cookie 895 It is a 64-bit bit string cryptographically generated by the 896 responder in a represent-transfer state manner. More specifically 897 when the same timestamp, time delta, Init-Check-Code, salt, source 898 and destination ULTIDs are sent to the responder, the responder 899 MUST be able to generate the identical cookie value. 901 o Init-Check-Code 902 It MUST be identical to the corresponding field in the Connect 903 Initialization packet acknowledged. 905 o Time Delta 906 It is a 32-bit signed integer which is the difference between the 907 near-end's time and the timestamp value sent in the Connection 908 Initialization packet. The units and the epoch of the near-end's 909 time value and the timestamp value MUST be the same. However, the 910 precision or resolution of the time delta value is chosen 911 arbitrarily by the responder. 913 4.5.3. Connect Request 915 0 31 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | | 918 + Time Stamp + 919 | | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | | 922 + Init-Check-Code + 923 | | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Salt | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Header Signature | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Initial Sequence Number | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Time Delta | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | | 934 + Cookie + 935 | | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 ~ ~ 938 ~ Sink Parameter ~ 939 ~ ~ 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 ~ ~ 942 ~ Host Name of the Initiator (optional) ~ 943 ~ ~ 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 Figure 7 Connect Request 948 Operation Code of this type of packet is CONNECT_REQUEST. 950 The value of each field that has the identical name with the one in 951 the associated Connect Initialization and Acknowledgment to Connect 952 Initialization packet MUST be assigned the same value as in these two 953 packets, except header signature in the packet. 955 o Sink Parameter 956 It is an extension header specified in 4.7. 958 o Host Name of the Initiator 959 The optional payload of the Connect Request packet is the host 960 name, which is encoded in UTF-8 and SHOULD be resolvable in DNS, of 961 the initiator. 963 It could be exploited by the responder to look up the address of 964 the initiator that may receive packets in the reverse direction. 966 4.6. Normal Fixed Header 968 0 15 16 31 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Sequence Number | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Expected Sequence Number | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | | 975 + Integrity Check Code + 976 | | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Flags | Advertised Receive Window Size | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Header Signature | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 Figure 8 FSP Fixed Header 985 Operation Code of a normal fixed header may be ACK_CONNECT_REQUEST, 986 PURE_DATA, PERSIST, KEEP_ALIVE, ACK_FLUSH, RELEASE or MULTIPLY. 988 o Sequence Number 989 Each in-band FSP packet is assigned a 32-bit unsigned integer as 990 the sequence number. The sequence number assigned for in-band FSP 991 packets MUST be in strict order. 993 An out-of-band packet that has the operation code of KEEP_ALIVE, 994 ACK_FLUSH or MULTIPLY MUST be assigned a sequence number that falls 995 in the receive window. 997 o Expected Sequence Number 998 It stores the earliest sequence number of the packets that were not 999 yet received in the receive window of the sender. It is an 1000 accumulative acknowledgment. Any packet with the sequence number 1001 before the received Expected Sequence Number is supposed to have 1002 been received by the remote end. 1004 o Integrity Check Code 1005 The ICC. 1007 o Flags 1008 It is bit-field of width 8. From left to right: 1010 - End of Transaction (EoT): If the EoT flag of a packet is set, it 1011 is the last packet of a transmit transaction. A packet with the 1012 EoT flag set MAY be the start and the single packet of the 1013 transmit transaction as well. 1015 - Minimal-Delay (MIND): If the MIND flag of the Connect Request or 1016 Acknowledgment to Connect Request packet is set, the ULA prefers 1017 minimal delay and is willing to tolerate packet loss. FSP SHALL 1018 drop the packet received earliest when there is no enough receive 1019 buffer so that the latest packet received can be saved and the 1020 delay to deliver data to ULA is minimized. 1022 If the MIND flag has been set the EoT flag of any following 1023 packet is simply ignored. 1025 The MIND flag of an FSP packet may be set only if the packet does 1026 not belong to a compressed transmit transaction. 1028 Payload of each FSP packet is delivered to the ULA as an 1029 independent message if the MIND flag has been set. 1031 - Compressed (CPR) If the CPR flag of the first packet of a 1032 transmit transaction is set, compression is applied on the octet 1033 stream of the payloads of the continuous packets that constitute 1034 the transmit transaction, or to put it simply, the payload octet 1035 stream of the transaction transaction. Such transmit transaction 1036 is called a compressed transmit transaction. 1038 When the CPR flag of a packet is set, CPR flag of each following 1039 packet is ignored until reaching termination of the transmit 1040 transaction. 1042 If the payload octet stream of the transmit transaction is 1043 compressed the Minimal-Delay flag of any packet in the transmit 1044 transaction MUST be cleared. 1046 - ECN-Echo (ECE): The Explicit Congestion Notification Echo flag of 1047 a packet is set if the sender of the packet has received an 1048 underlying IPv6 packet with Congestion Experienced code point set 1049 for its peer as stated in "The Addition of Explicit Congestion 1050 Notification (ECN) to IP" [RFC3168]. 1052 - Send Rate Reduced (SRR): The SRR flag of each packet SHALL be set 1053 as soon as the sender has received a legitimate packet with ECE 1054 flag set and has informed the congestion manager to reduce the 1055 send rate, until a sent packet with SRR flag set is acknowledged. 1057 The remaining 3 bits are reserved. 1059 o Advertised Receive Window Size 1060 It is a 20-bit unsigned integer that stores number of the free 1061 blocks in the receive buffer of the sender of the packet that 1062 contains the receive window size field. It is count from the slot 1063 meant to accept the packet with the expected sequence number. 1065 The sender must ensure that the difference between the latest 1066 sequence number sent out and the largest expected sequence number 1067 received does not exceed the value of the latest advertised receive 1068 window size received. 1070 4.7. Sink Parameter 1072 0 31 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 ~ ~ 1075 ~ Addressable Network Prefixes ~ 1076 ~ ~ 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Listener ID/Host ID | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Header Signature | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 Figure 9 Sink Parameter 1085 Operation Code in the Header Signature of this extension header is 1086 PEER_SUBNETS. 1088 o Addressable Network Prefixes 1089 These are up to 4 64-bit words that specify the network prefixes of 1090 the lower layer interfaces that are addressable by the receiver in 1091 the reverse direction. 1093 In this version of the FSP 'Addressable Network Prefixes' field is 1094 of fixed length. The last network prefix which is non-zero is the 1095 last resort one. There MUST be at least one non-zero network 1096 prefix. If there are more than one non-zero network prefixes those 1097 other than the last resort are load-balanced preferred. 1099 In an IPv6 network, the addressable network prefix is the leftmost 1100 64 bits of the IPv6 address. The receiver of the Addressable 1101 Network Prefixes SHALL send packet in the reverse direction, i.e. 1102 to the sender of the field with the destination IPv6 address 1103 generated by combining a preferred network prefix with the 1104 aggregation host id and the ULTID part of the source address in the 1105 IPv6 header of the received packet that eventually carries the 1106 Addressable Network Prefixes. 1108 Such feature MAY be exploited to handle links with unidirectional 1109 connectivity, but it is NOT RECOMMENTED. 1111 In an IPv4 network for compatibility with the IPv6 addressed ULA 1112 the 64-bit word of the addressable network prefix specified is 1113 composed as following Figure: 1115 0 15 16 31 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | 0x2002 (IPv6 6to4 prefix) |IPv4 address (leftmost 16 bits)| 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 |IPv4 address(rightmost 16 bits)| UDP port number (16 bits) | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Figure 10 Addressable Network Prefix of FSP over UDP/IPv4 1124 Sender of the Sink Parameter packet SHOULD be NAT-aware. If it is 1125 able to obtain the from the NAT box (as defined in "Traditional IP 1126 Network Address Translator (Traditional NAT)" [RFC3022]) through Port 1127 Control Protocol (PCP) [RFC6887] SHOULD fill in the IPv4 address and 1128 UDP port number fields with the public IP value that were obtained. 1129 If it does not have such capability, it SHALL fill in the addressable 1130 network prefix with all binary zeroes. 1132 o Listener ID 1133 It is the ULTID of the responder that is in LISTENING state. 1135 o Host ID 1136 It is the aggregation host id of the sender. It SHALL be 0 if it is 1137 in the IPv4 network. 1139 4.8. Selective Negative Acknowledgment 1141 0 31 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Gap Width | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Data Length | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 ~ ~ 1148 ~ Further pairs of (Gap Width, Data Length) ~ 1149 ~ ~ 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | | 1152 + Acknowledgement Delay + 1153 | | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Out-band Serial Number | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Header Signature | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 Figure 11 Selective Negative Acknowledgment 1162 The operation code of this type of extension header is SNACK. The 1163 SNACK header contains the descriptor of the receive window gaps: 1165 The descriptor itself is a list of entries. The length of the list 1166 can be zero which means that there is no gap in the receive window. 1167 If the list is not empty, each entry contains the width of one gap in 1168 the receive window and the length of the continuously received data 1169 following the gap, respectively. The unit of aforementioned length of 1170 gaps or number of packets is buffer block. 1172 o Acknowledgement Delay 1173 A 64-bit unsigned integer specifies the delay in microseconds 1174 between sending the packet containing the SNACK extension header 1175 and accepting the last packet that is accumulatively acknowledged 1176 by the SNACK extension header. 1178 o Out-band Serial Number 1179 The SNACK header contains a 32-bit out-band serial number as well. 1180 Each time a packet that contains the SNACK header is sent the out- 1181 band serial number shall increase by one. It is assumed that in the 1182 life of the session no two packets have the same sequence number 1183 and the same SNACK header serial number simultaneously. 1185 4.9. RESET 1186 The 'RESET' packet is a special command packet meant to interrupt 1187 connection setup process or disconnect abruptly. Operation Code of 1188 the packet is RESET. 1190 Structure of a RESET packet in C code snippet with unnamed union 1191 applied: 1193 struct FSP_RejectConnect 1194 { 1195 /* sequence numbers */ 1196 union 1197 { 1198 timestamp_t timeStamp; 1199 struct 1200 { 1201 uint32_t initial; 1202 uint32_t expected; 1203 } sn; 1204 }; 1205 /* uniqueness proof */ 1206 union 1207 { 1208 uint64_t integrityCode; 1209 uint64_t cookie; 1210 uint64_t initCheckCode; 1211 }; 1212 /* bit field to describe reasons for reset */ 1213 uint32_t reasons; 1214 $FSP_HeaderSignature hs; 1215 }; 1217 When the RESET packet is the response to a Connect Initialization 1218 packet both the timeStamp and the initCheckCode fields of the RESET 1219 packet MUST be set to the same values of Time Stamp and Init-Check- 1220 Code in the Connect Initialization packet, respectively. 1222 When the RESET packet is the response to a Connect Request packet 1223 both the timeStamp and the cookie fields of the RESET packet MUST be 1224 set to the same value of Time Stamp and Cookie in the Connect Request 1225 packet, respectively. 1227 When the RESET packet is the response to a packet with a normal fixed 1228 header, the sn.initial, the sn.expected and the integrityCode of the 1229 RESET packet MUST be set as to specification of normal fixed header 1230 field Sequence Number, Expected Sequence Number and Integrity Check 1231 Code, respectively. 1233 5. The Finite State Machine 1235 5.1. NON_EXISTENT 1236 ---[API: Listen]-->LISTENING 1237 |--[API: Connect]-->CONNECT_BOOTSTRAP-->[Send INIT_CONNECT] 1238 |--[API: Multiply]-->CLONING-->[Send MULTIPLY] 1240 NON_EXISTENT is a pseudo-state before a connection is created by the 1241 ULA calling API Listen, Connect or Multiply (or after a connection is 1242 reset). 1244 5.2. LISTENING 1245 ---[API: Reset]-->NON_EXISTENT 1246 |<-->[Rcv.INIT_CONNECT]{&& accepted}[Send ACK_INIT_CONNECT] 1247 |<-->[Rcv.INIT_CONNECT]{&& rejected}[Send RESET] 1248 |<-->[Rcv.CONNECT_REQUEST]{&& duplication detected} 1249 [Retransmit ACK_CONNECT_REQ] 1250 |--[Rcv.CONNECT_REQUEST]-->{Notify} 1251 |-->[API: Accept] 1252 -->{new context}CHALLENGING-->[Send ACK_CONNECT_REQ] 1253 |-->[API: Reject]-->[Send RESET] {abort new context, if any} 1255 LISTENING is a state entered by the ULA calling API Listen. 1257 5.3. CONNECT_BOOTSTRAP 1258 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1259 |--[Rcv.ACK_INIT_CONNECT]-->CONNECT_AFFIRMING 1260 |-->[Send CONNECT_REQUEST] 1261 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1262 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1264 CONNECT_BOOTSTRAP is a state entered by the ULA calling API Connect, 1265 before receiving the acknowledgement of the remote end to the 1266 connection initialization packet. 1268 5.4. CONNECT_AFFIRMING 1269 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1270 |--[Rcv.ACK_CONNECT_REQ]-->[Notifiy] 1271 |-->{Callback return to accept} 1272 |-->{No Payload}-->COMMITTING2-->[Send ACK_START] 1273 |-->{Has Payload} 1274 |-->{EOT}-->COMMITTING2-->[Send PERSIST with EoT] 1275 |-->{Not EOT}-->PEER_COMMIT-->[Send PERSIST] 1276 |-->{Callback return to reject]-->NON_EXISTENT-->[Send RESET] 1277 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1278 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1280 CONNECT_AFFIRMING is a state entered by the ULA affirming to send 1281 connect request after receiving the acknowledgement to the connection 1282 initialization packet. 1284 5.5. CHALLENGING 1285 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1286 |<-->[API: Send{new data}]{just prebuffer} 1287 |--[Rcv.ACK_START]-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1288 |--[Rcv.PERSIST] 1289 |--{Not EOT}-->COMMITTED-->[Send SNACK]-->[Notify] 1290 |--{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1291 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1292 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1294 CHALLENGING is a state entered by the ULA accepting the connection 1295 request after a new connection context has been incarnated. The new 1296 connection is incarnated by the FSP context of the near end in the 1297 LISTENING state as a legitimate CONNECT_REQUEST packet is received. 1299 5.6. ACTIVE{A.K.A. ESTABLISHED} 1300 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1301 |--[API: Send{flush}]-->COMMITTING{Urge to commit} 1302 |<-->[API: Send{more data}][Send PURE_DATA] 1303 |--[Rcv.PURE_DATA] 1304 |--{Not EOT}-->[Send SNACK]-->[Notify] 1305 |--{EOT} 1306 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1307 |--[Rcv.PERSIST] 1308 |--{Not EOT}-->[Send SNACK early] 1309 |--[EOT] 1310 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1311 |--[Rcv.MULTIPLY]{passive multiplication} 1312 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1313 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1315 ACTIVE or ESTABLISHED is a state that the FSP participant has 1316 finished end-to-end negotiation but has not committed current 1317 transmit transaction nor fully received the latest transmit 1318 transaction of the remote end. 1320 5.7. COMMITTING 1321 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1322 |--[Rcv.ACK_FLUSH]-->COMMITTED-->[Notify] 1323 |--[Rcv.PURE_DATA] 1324 |--{Not EOT}-->[Send SNACK]-->[Notify] 1325 |--{EOT}-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1326 |--[Rcv.MULTIPLY]{passive multiplication} 1327 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1328 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1329 COMMITTING is a state that the FSP participant has committed the 1330 transmit transaction but has not fully received the latest transmit 1331 transaction of the remote end, nor the acknowledgement to the 1332 transmit transaction commitment has been received. 1334 The participant in COMMITTING state SHALL NOT transmit further data 1335 until current transmit transaction commitment is acknowledged. 1337 5.8 COMMITTED 1338 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1339 |--[API: Send{more data}]-->ACTIVE-->[Send PERSIST] 1340 |--[API: Send{flush}]-->COMMITTING{Urge to commit} 1341 |--[Rcv.PURE_DATA] 1342 |-->{Not EOT}-->[Send SNACK]-->[Notify] 1343 |-->{EOT} 1344 |-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1345 |--[Rcv.PERSIST] 1346 |-->{Not EOT}-->[Send SNACK] 1347 |-->{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1348 |--[Rcv.MULTIPLY]{passive multiplication} 1349 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1350 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1352 COMMITTED is a state that the FSP participant has committed current 1353 transmit transaction and has received the acknowledgement to the 1354 transmit transaction commitment, but has not fully received the 1355 latest transmit transaction of the remote end. 1357 5.9. PEER_COMMIT 1358 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1359 |--[API: Send{flush}]-->COMMITTING2-->[Urge to commit] 1360 |<-->[API: Send{more data}][Send PURE_DATA] 1361 |<-->[Rcv.PURE_DATA]{just prebuffer} 1362 |<-->[Rcv.ACK_START]--[Send ACK_FLUSH] 1363 |--[Rcv.PERSIST] 1364 |-->{Not EOT}-->ACTIVE-->[Send SNACK] 1365 |<-->{EOT}--[Send ACK_FLUSH] 1366 |--{&& is new transaction}-->[Notify] 1367 |--[Rcv.MULTIPLY]{passive multiplication} 1368 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1369 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1371 PEER_COMMIT is a state that the FSP participant has not committed 1372 current transmit transaction but has fully received the latest 1373 transmit transaction of the remote end, and the acknowledgement to 1374 the transmit transaction commitment has not been received yet. 1376 5.10. COMMITTING2 1377 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1378 |<-->[Rcv.PURE_DATA]{just prebuffer} 1379 |<-->[Rcv.ACK_START]--[Send ACK_FLUSH] 1380 |--[Rcv.ACK_FLUSH]-->CLOSABLE-->[Notify] 1381 |--[Rcv.PERSIST] 1382 |-->{Not EOT}-->COMMITTING-->[Send SNACK] 1383 |-->{EOT}-->{keep state}-->[Send ACK_FLUSH] 1384 |--{&& is a new transaction}-->[Notify] 1385 |--[Rcv.MULTIPLY]{passive multiplication} 1386 |--[Rcv.RELEASE]-->CLOSED-->[Send RELEASE]-->[Notify] 1387 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1388 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1390 COMMITTING2 is a state that the FSP participant has committed current 1391 transmit transaction and has fully received the latest transmit 1392 transaction of the remote end, but the acknowledgement to the 1393 transmit transaction commitment has not been received yet. 1395 The participant in COMMITTING2 state SHALL NOT transmit further data 1396 until current transmit transaction commitment is acknowledged. 1398 5.11 CLOSABLE 1399 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1400 |--[API: Send{more data}]-->PEER_COMMIT-->[Send PERSIST] 1401 |--[API: Send{flush}]-->COMMITTING2-->[Urge to commit] 1402 |--[API: Shutdown]-->[Send RELEASE]-->PRE_CLOSED-->[Notify] 1403 |<-->[Rcv.PURE_DATA]{just prebuffer} 1404 |<-->[Rcv.ACK_START]--[Send ACK_FLUSH] 1405 |--[Rcv.PERSIST] 1406 |-->{Not EOT}-->COMMITTED-->[Send SNACK] 1407 |-->{EOT}-->{[Send ACK_FLUSH] 1408 |--{&& is a new transaction}-->[Notify] 1409 |--[Rcv.MULTIPLY]{passive multiplication} 1410 |--[Rcv.RELEASE]-->CLOSED-->[Notify] 1411 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1413 CLOSABLE is a state that the FSP participant has committed current 1414 transmit transaction and has received the acknowledgement to the 1415 transmit transaction commitment, and has fully received the latest 1416 transmit transaction of the remote end. 1418 5.12 PRE_CLOSED 1419 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1420 |--[Rcv.RELEASE]-->CLOSED-->[Send RELEASE]-->[Notify] 1421 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1422 |--{On retransmission Timeout}<-->[Retransmit RELEASE] 1424 PRE_CLOSED is a state entered by the ULA calling the API Shutdown in 1425 CLOSABLE state. 1427 5.13 CLOSED 1428 |--{On Recycling Needed}-->NON_EXISTENT 1430 CLOSED is a state migrated from PRE_CLOSED state on receiving a 1431 legitimate RELEASE packet from the remote end. 1433 Unlike TCP [STD7], CLOSED state in FSP is not fictional. Instead a 1434 connection context MAY persist in CLOSED state until the session key 1435 runs out of life, or the host system needs to recycle the resource 1436 allocated to the CLOSED session. A connection in CLOSED state MAY be 1437 resurrected. 1439 5.14 CLONING 1440 ---[API: Reset]-->NON_EXISTENT 1441 |<-->[API: Send{new data}]{just prebuffer} 1442 |<-->[Rcv.PURE_DATA]{just prebuffer} 1443 |--[Rcv.ACK_START] 1444 |--{&& Not ULA-flushing}-->PEER_COMMIT 1445 |-->[Send ACK_FLUSH]-->[Notify] 1446 |--{&& ULA-flushing}-->CLOSABLE 1447 |-->[Send ACK_FLUSH]-->[Notify] 1448 |--[Rcv.PERSIST] 1449 |-->{Not EOT} 1450 |--{&& Not ULA-flushing}-->ACTIVE 1451 |-->[Send SNACK]-->[Notify] 1452 |--{&& ULA-flushing}-->COMMITTED 1453 |-->[Send SNACK]-->[Notify] 1454 |-->{EOT} 1455 |--{&& Not ULA-flushing}-->PEER_COMMIT 1456 |-->[Send ACK_FLUSH]-->[Notify] 1457 |--{&& ULA-flushing}-->CLOSABLE 1458 |-->[Send ACK_FLUSH]-->[Notify] 1459 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1460 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1462 CLONING is a state entered by ULA calling the API Multiply from any 1463 state that may accepting an out-of-band packet. 1465 6. End-to-End Negotiation 1466 End-to-end negotiation of FSP session occurs in the connection 1467 establishment phase. Connection establishment process of FSP consists 1468 of two and a half pairs of packet exchanges for connection 1469 initialization, weak key agreement and the last confirmation. During 1470 the process various optional header or payload MAY be carried in the 1471 FSP preliminary packets to negotiate end-to-end session parameters. 1473 6.1. Connect Initialization 1475 The initiator sends the INIT_CONNECT packet to the responder: 1476 (INIT_CONNECT, Timestamp, Init-Check-Code, Salt [, Responder's Host 1477 Name]) 1479 Connection initialization MAY be syndicated with optional address 1480 resolution at the gateway in the IPv6 network by carrying the 1481 responder's host name in the INIT_CONNECT packet. 1483 If it does carry the responder's host name it MUST take the link- 1484 local interface address [RFC4291] as the source IPv6 address and the 1485 default link-local gateway address, FE80::1, as the destination IPv6 1486 address no matter whether the global unicast IP address of the 1487 default gateway is configured. 1489 If the gateway that relays the INIT_CONNECT packet finds that the 1490 responder is on the same link-local network with the initiator it 1491 SHALL change the source and the destination IP addresses of the 1492 INIT_CONNECT packet to the link-local IP addresses of the initiator 1493 and the responder respectively, and relay the packet onto the same 1494 link-local network. 1496 On receiving the INIT_CONNECT packet that carries the responder's 1497 host name the link-local gateway MUST resolute the responder's global 1498 unicast IPv6 address and map the initiator's global unicast IPv6 1499 address, and replace the destination and source address of the 1500 INIT_CONNECT packet respectively, unless it finds that the initiator 1501 and the responder are on the same link-local network, where the 1502 gateway SHALL process the packet as stated in the previous statement. 1504 The gateway SHALL silently ignore the INIT_CONNECT packet if it is 1505 unable to resolve the IP address of the responder. 1507 If the destination address is the default link-local gateway address 1508 while the INIT_CONNECT does not carry the responder's host name 1509 payload, it is supposed that the gateway is the intent destination of 1510 the connection to initialize. 1512 6.2. Response to Connect Initialization 1513 The responder sends acknowledgment to the initiator: 1515 Case 1: (ACK_INIT_CONNECT, Cookie, Init-Check-Code Reflected, Time- 1516 delta) 1518 Case 2: (RESET, Timestamp Reflected, Init-Check-Code Reflected, 1519 Reason of Failure) 1521 In case 1 the responder is ready to accept the connection. It SHALL 1522 NOT make state transition on receiving INIT_CONNECT packet. It SHALL 1523 generate a cookie which is meant to be reflected by the initiator. 1524 The responder MUST send the ACK_INIT_CONNECT packet with the new 1525 allocated local ULTID instead of the original listening ULTID. The 1526 initiator should be able to find out the original listening ULTID by 1527 searching its own connection context. 1529 In case 2 the responder refuses to accept the connection. It SHALL 1530 send back a RESET packet with the listening ULTID as the source 1531 ULTID. 1533 In either case the destination address of the packet sent back MUST 1534 be set to the source address of the corresponding Connect 1535 Initialization packet whose source and destination address MAY be 1536 updated by some intermediary such as the link-local gateway of the 1537 initiator. 1539 6.3. Weak Key Agreement Request 1541 (CONNECT_REQUEST, Timestamp, Init-Check-Code, Salt, Cookie Reflected, 1542 Time-delta Reflected, Initial SN, Initiator's Sink Parameter [, 1543 Initiator's Host Name]) 1545 The initiator accepts the Response to Connect Initialization packet 1546 if and only if both the destination ULTID of the response packet 1547 matches the source ULTID of the connect initialization packet and the 1548 Init-Check-Code reflected in the response packet matches the Init- 1549 Check-Code in the connect initialization packet. 1551 If the response packet is accepted the initiator formally requests to 1552 establish the connection by sending the CONECT_REQUEST packet. 1554 In the CONNECT_REQUEST packet the value of the Timestamp, the Init- 1555 Check-Code and the Salt field MUST be the same as in the INIT_CONNECT 1556 packet while the value of the Cookie Reflected field and the Time- 1557 delta Reflected field MUST be the same as in the ACK_INIT_ CONNECT 1558 packet, respectively. 1560 The initiator MUST send the packet towards the remote ULTID that the 1561 responder has preserved and sent with the ACK_INIT_CONNECT packet. It 1562 MUST fill the original listener ID field in the Initiator's Sink 1563 Parameter with the right value. 1565 The source address of the CONNECT_REQUEST packet MUST be set to the 1566 destination address of the received ACK_INIT_CONNECT packet, while 1567 the network prefix and host-id part of the destination address MUST 1568 be set to the source address of the received ACK_INIT_CONNECT packet 1569 in the IPv6 network. 1571 The initiator SHALL save the cookie value that the responder has 1572 given to make up the weak session key. 1574 The initiator MUST fill the Initial SN field with the sequence number 1575 of the packet that will follow CONNECT_REQUEST. The CONNECT_REQUEST 1576 packet is payload free and does not consume the sequence space. 1578 The optional fields Initiator's Host Name is put as the payload of 1579 the CONNECT_REQUEST packet. If presented it MAY be exploited by the 1580 responder as the last resort to resolute the most recent IP address 1581 of the initiator in some extraordinary scenarios such as the 1582 initiator has hibernated for a considerably long time. 1584 6.4. Weak Key Agreement Response 1586 Case 1: (ACK_CONNECT_REQ, Initial SN, Expected SN, ICC, FREWS, 1587 Responder's Sink Parameter[, Payload]) 1589 Case 2: (RESET, Timestamp Reflected, Copy of Cookie Reflected, Reason 1590 of Failure) 1592 The responder responds as in case 1 if the reflected cookie was 1593 validated, resources were successfully allocated and the initial 1594 context of the connection was setup. Otherwise it SHOULD respond as 1595 in case 2. 1597 The Initial SN in case 1 is the initial sequence number of the 1598 responder. The responder should fill in the field with a random 32- 1599 bit unsigned integer. As the ACK_CONNECT_REQ packet may carry payload 1600 the sequence number of the responder starts from the ACK_CONNECT_REQ 1601 packet. 1603 The Expected SN MUST equal to the Initial SN specified in the 1604 corresponding CONNECT_ REQUEST packet. In the Responder's Sink 1605 Parameter the original listener ULTID MUST be set to the right value. 1607 6.5. The Last Confirmation 1608 Case 1: (ACK_Start, Initial SN, Expected SN, ICC, FREWS) 1610 Case 2: (PERSIST, Initial SN, Expected SN, ICC, FREWS, payload) 1612 Case 3: (RESET, Initial SN, Expected SN, ICC, Reason of Failure) 1614 The initiator of the connection MUST eventually confirm to the 1615 responder that the connection is established by sending a payload- 1616 less ACK_START packet (case 1) or a PERSIST packet with payload (case 1617 2). 1619 Of course the initiator MAY quit to establish the connection by 1620 sending a legitimate RESET packet (case 3). 1622 6.6. Retransmission 1624 The initiator SHALL retransmit the INIT_CONNECT packet if the 1625 corresponding ACK_INIT_CONNECT packet is not received in some limit 1626 time (by default 15 seconds). 1628 The initiator SHALL retransmit the CONNECT_CONNECT packet if the 1629 corresponding ACK_CONNECT_REQ packet is not received in some limit 1630 time (by default 15 seconds). 1632 The responder SHALL NOT retransmit ACK_INIT_CONNECT or 1633 ACK_CONNECT_REQ packet. 1635 The initiator SHOULD retransmit the right INIT_CONNECT packet or 1636 CONNECT_CONNECT packet until the legitimate ACK_CONNECT_REQ packet is 1637 eventually received. 1639 It SHALL give up if the time starting from the very first 1640 INIT_CONNECT packet was sent has exceed a longer timed-out value (by 1641 default 60 seconds) before the legitimate ACK_CONNECT_REQ packet is 1642 received. 1644 7. Quad-party Session Key Installation 1646 It assumes that in the scenarios applying FSP it is the ULA to do key 1647 establishment and/or end-point authentication while the FSP layer 1648 provides authenticated, optionally encrypted data transfer service. 1649 Together they establish a secure channel between two application end- 1650 points. 1652 Protocol for installation of the shared secret key is quad-party in 1653 the sense that both the upper layer application and the FSP layer of 1654 both the participant nodes MUST agree on the moment of certain state 1655 to install the shared secret key. 1657 It is arguably much more flexible for the application layer protocols 1658 to adopt new key establishment algorithm while offloading routine 1659 authentication and optionally encryption of the data to the 1660 underlying layers where it may be much easier to exploit hardware- 1661 acceleration. 1663 7.1. API for Session Key Installation 1665 A dedicate application program interface (API) is designed for the 1666 ULA to install the secret key established by the ULA participants. 1667 The API SHOULD take four parameters: 1669 - A 'handle' to state the connection context for installing the 1670 session key 1671 - A octet string of initial key materials (IKM) 1672 - An integer to state the length of IKM. The unit is octet. 1673 - An integer to state the desired length of the effective session key 1674 if AEAD is applied. The unit is bit. For this version of FSP desired 1675 length of the effective session key is either 128 or 256. 1677 7.2. Time to Call API for Session Key Installation 1679 The ULA participant that installs the new secret key firstly MUST be 1680 the one that is committing a transmit transaction after it has 1681 accepted peer's transmit transaction commitment. 1683 In a typical scenario the ULA endpoints first setup the FSP 1684 connection where resistance against connection redirection is weakly 1685 enforced by CRC64. 1687 After the pair of ULA endpoints establish a shared secret key, they 1688 install the secret key and commit current transmit transactions. 1689 Authenticity of the FSP packets sent later is cryptographically 1690 protected by the new secret key and resistance against various 1691 attacks is secured. 1693 7.3. Time to Take New Session Key into Effect 1695 The FSP layer SHALL make it sure that the new secret key is taken 1696 into effect starting from the very first packet of the transmit 1697 transaction that is next to the transmit transaction whose context is 1698 where the new secret key is installed. Although transmit transaction 1699 is actually uni-directional the secret key is shared bi-directionally 1700 in this version of FSP. 1702 By committing a transmit transaction a ULA participant clearly tells 1703 the underlying FSP layer that the next packet sent MAY adopt a new 1704 secret key. On receiving a packet with the EoT flag set the ULA is 1705 informed that the next packet received MAY adopt a new shared secret 1706 key. 1708 After the ULA install a new secret key every packet sent later than 1709 the one with the EoT flag set MUST adopt the new secret key. The peer 1710 MUST have commit a transmit transaction and it SHALL install the same 1711 secret key on receiving the FSP packet with the EoT flag set. 1713 The ULA SHOULD have installed the new shared secret key, or install 1714 it instantly after accepting the packet with the EoT flag set. If the 1715 new secret key has ever been installed the packet received after the 1716 one with the EoT flag set MUST adopt the new secret key. 1718 7.4. Generating the Initial Session Key 1720 When the ULA install the secret key, it is required to provide the 1721 initial key material which might have unbalanced bit randomness, not 1722 the session key itself. HMAC-based Extract-and-Expand Key Derivation 1723 Function (HKDF) [RFC5869] is applied to generate the initial session 1724 key. 1726 Given raw key material ikm, length of the ikm nB in octets, intended 1727 master key length lenb in bits, || is octet string concatenation, 1729 If HMAC only is designated, the nB octets of ikm is hashed into 64 1730 octets which is taken as the master key. 1732 If AEAD is designated, the initial session key, or the first secret 1733 key for packet authentication and payload encryption is obtained as 1734 specified in [RFC5869]: 1736 Key Extract phase, 1738 Let Km = BLAKE2(zeros || ikm) , where 1740 zeros is 32 octets of integer 0 1742 BLAKE2b algorithm without key is applied. 1744 The result Km is the master key. 1746 Key Expand phase, 1748 Let Ks = BLAKE2(Km, info) , where 1750 Km is the master key generated in previous phase, 1751 info is concatenation of the arbitrary ASCII string "Establishes 1752 an FSP session", which is 26-octet long, 3 octets of integer 0, 1753 and 1 octet of integer 1. 1755 BLAKE2b algorithm with key is applied. The key applied MUST be the 1756 master key Km. 1758 The result Ks is the initial session key, or the first secret key 1759 for packet authentication and payload encryption. 1761 For this version FSP Ks is a fixed-length AES key together with a 1762 4-octet salt. The salt is meant to be passed to AES-GCM as the 1763 initialization vector together with the sequence number and 1764 expected sequence number fields in the normal FSP fixed header: 1766 0 31 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Salt | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Sequence Number | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | Expected Sequence Number | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 Figure 12 Formation of Initialization Vector 1777 7.5. Internal Rekeying 1779 In this version of FSP it is forced to re-key on sending or receiving 1780 every 536870912? (2^29) packets. 1782 Let Ks' = BLAKE2(Km, H || info') , where: 1784 Km is the master key generated as in section 7.4. 1786 H is the 16-octet internal hash sub-key of AES-GCM of previous 1787 session key, 1789 info' is concatenation of the arbitrary ASCII string "Sustains an 1790 FSP connection", which is 26-octet long 1791 and the 4 octets in network order of the 32-bit unsigned integer 1792 that specifies the batch index of the session key. 1794 BLAKE2b algorithm with key is applied. The key applied MUST be the 1795 master key Km. 1797 The result Ks' is the new session key, together with the new salt 1798 meant to be form the IV. 1800 The batch index of the initial session key is 1, and it is increased 1801 by 1 every time before it is to re-key. 1803 8. Send and Receive 1805 8.1. Packet Integrity Protection 1807 8.1.1. Application of CRC64 1809 Starting from ACK_CONNECT_REQUEST, until the ULAs have installed the 1810 shared secret CRC64 is applied to calculate the value of the ICC 1811 field. The algorithm: 1813 1.Take pair of the ULDs as the initial value of accumulative CRC64 1814 The pair of the ULDs is composed of the near end's ULTID and the 1815 remote end's ULTID, where the former is the leftmost 32 bits and 1816 the latter is the rightmost 32 bits of initial value for the send 1817 direction, and the order is reversed for the receive direction. 1819 2.Accumulate the value of the Init-Check-Code field 1821 3.Accumulate the value of the Cookie field successively 1823 4.Accumulate the combined value of the salt and the timeDelta field 1824 where the former is the leftmost 32 bits and the latter is the 1825 rightmost 32 bits 1827 5.Accumulate the value of the Time Stamp field 1829 6.Save the accumulated CRC64 value 1830 as the pre-computed CRC64 value. 1832 When calculate the value ICC of a particular FSP packet, firstly set 1833 ICC to the pre-computed CRC64 value, then calculate the CRC64 1834 checksum of the whole FSP packet, while ULTIDs are NOT included if 1835 the FSP packet is encapsulated in UDP. The result is set as the final 1836 value of the ICC field. 1838 8.1.2. Packet Authentication Only 1840 The ULA designates the FSP layer to either applying HMAC only or 1841 applying AEAD. 1843 If the HMAC flag of a packet is set the pre-designated cryptographic 1844 hash function SHALL be applied to get the message authentication code 1845 (MAC) of the whole packet. Each FSP version MUST designate one and 1846 only one particular cryptographic hash function. 1848 For this FSP version, BLAKE2 [RFC7693] is designated as the 1849 cryptographic hash function. The input key is the secret key that has 1850 been derived from the master key installed by the ULA. The input data 1851 is the full FSP packet, where the ICC field is pre-filled the pair of 1852 the ULDs. As in making CRC64 checksum, the pair of the ULDs is 1853 composed of the near end's ULTID and the remote end's ULTID, where 1854 the former is the leftmost 32 bits and the latter is the rightmost 32 1855 bits of initial value for the send direction, and the order is 1856 reversed for the receive direction. 1858 The hash result is truncated to 64 bits to get the final ICC. 1860 8.1.3. Authenticated Encryption with Additional Data 1862 FSP provides per-packet authenticated encryption service. Only one 1863 authenticated encryption algorithm is allowed for a determined 1864 version of FSP. For this FSP version, the authenticated encryption 1865 algorithm selected is GCM-AES [GCM][AES], it is applied to protect 1866 integrity of the full FSP packets and privacy of the payload. The 1867 length of the session key is determined by the ULA. The four inputs 1868 to GCM-AES authenticated encryption are: 1870 K: the key derived by the master key installed by ULA. 1872 IV: the initial vector, 96-bit string made by concatenating a 32-bit 1873 salt, the 32-bit sequence number of the packet and the 32-bit 1874 expected sequence number field of the packet. The salt is derived by 1875 the master key installed by ULA. 1877 P: the plaintext are the bytes following the fixed header up to the 1878 end of the original payload 1880 AAD: additional authenticated data, from the source ULTID to the last 1881 byte of the fixed header. The source ULTID is stored in the leftmost 1882 32-bit of the ICC field while the destination ULTID is stored in the 1883 rightmost 32-bit of the ICC field before the ICC value is calculated. 1884 The length of the authentication tag MUST be 64 bits for FSP version 1885 0 and 1. The authentication tag is stored in the ICC finally. The 1886 inputs to GCM-AES decryption are: 1888 K: the key installed by ULA. 1890 IV: the initial vector, 96-bit string made by concating consisted of 1891 the salt, the 32-bit sequence number of the packet and the 32-bit 1892 expected sequence number field of the packet. The internal 32-bit 1893 salt MUST be the XOR result of the leftmost two 32-bit words of the 1894 hash sub-key. 1896 C: the ciphertext are the bytes following the fixed header up to the 1897 end of the received payload 1899 AAD: additional authenticated data, from the source ULTID to the last 1900 byte of the fixed header. The source ULTID is stored in the leftmost 1901 32-bit of the ICC field while the destination ULTID is stored in the 1902 rightmost 32-bit of the ICC field before the ICC value is calculated 1904 T: The authentication tag, which is fetched from the ICC field 1905 received Only when the outputs of GCM-AES decryption tell that the 1906 authentication tag passed verification may the receiver deliver the 1907 decrypted payload to the ULA. 1909 8.2. Start a New Transmit Transaction 1911 The responder starts AND terminates a transmit transaction by send 1912 the ACK_CONNECT_REQ packet. 1914 The initiator starts a new transmit transaction by sending a PERSIST 1915 packet: 1917 (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload) 1919 Or starts AND terminates a transmit transaction by send the ACK_START 1920 packet: 1922 (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter]) 1924 8.3. Send a Pure Data Packet 1926 (PURE_DATA, SN, ExpectedSN, ICC, FREWS, Payload) 1928 After a new transmit transaction has been started further PURE_DATA 1929 packet MAY be sent until a packet with EoT flag set is sent. 1931 8.4. Commit a Transmit Transaction 1933 8.4.1. Initiate Transmit Transaction Commitment 1935 A participant of an FSP connection MAY notify its peer that a 1936 transmit transaction shall be committed by setting the EoT flag of 1937 the last packet of the transmit transaction, be it PERSIST, 1938 ACK_START, PURE_DATA or MULTIPLY. 1940 8.4.2. Respond to Transmit Transaction Commitment 1941 (ACK_FLUSH, SN, ExpectedSN, ICC, FREWS) 1943 If and only if all of the packets in a transmit transaction has been 1944 received MAY ACK_FLUSH packet be sent. 1946 Whenever a legitimate packet falls in the receive window of the 1947 receiver, and the packet fills in the last gap of the sequence of 1948 current transmit transaction on receiving direction, or the packet 1949 with same sequence number has been accepted already, a responding 1950 ACK_FLUSH SHALL be sent back immediately, and the FSP layer MUST 1951 immediately notify the ULA that a transmit transaction has been 1952 committed. 1954 8.4.3. Finalize Transmit Transaction Commitment 1956 After receiving the ACK_FLUSH packet the sender of the EoT flag 1957 migrates to the COMMITTED or CLOSABLE state from the COMMITTING or 1958 COMMITTING2 state, respectively. 1960 8.4.4. Time-out for Committing Transmit Transaction 1962 The ULA SHALL be timed-out if there is no packet was acknowledged in 1963 some hard-coded time-out. For this version of FSP the time-out is set 1964 to 30 seconds. 1966 8.5. Retransmission 1968 8.5.1. Calculation of RTT 1970 Initial round trip time (RTT) for the Connection Initiator: Equals to 1971 the mean of the time elapsed when ACK_ INIT_CONNECT was received 1972 since INIT_CONNECT was sent, and the time elapsed till 1973 ACK_CONNECT_REQ was received since CONNECT_REQUEST was sent. 1975 Initial RTT for the Connection Responder: Equals to the time elapsed 1976 when the ACK_START or the first PERSIST packet was received since 1977 ACK_CONNECT_REQ was sent. 1979 Initial RTT for the Initiator of Connection Multiplication: Equals to 1980 the time elapsed when the first PERSIST packet was received since 1981 MULTIPLY was sent. 1983 Initial RTT for the Responder of Connection Multiplication: Equals to 1984 the most recent RTT of the multiplied connection. 1986 Each time a SNACK or an accumulated acknowledgment is received the 1987 round trip time of the packet with most expected SN is calculated. 1988 The round trip time is the difference between the time when the 1989 KEEP_ALIVE packet that carried the acknowledgement was received and 1990 the time when the original packet was sent, minus the delay given in 1991 the SNACK optional header of the KEEP_ALIVE packet. Suppose the 1992 result is RTT_now, then: 1994 RTT_new = (RTT_old + RTT_now) / 2 1996 8.5.2. Generation and transmission of SNACK 1998 Whenever the receiver receives a packet it SHALL shift the time to 1999 send next heartbeat signal earlier to the time of RTT since current 2000 time, if the time to send next heartbeat signal used to be later. If 2001 the time is already earlier than the time of RTT since current time, 2002 it needs not be shifted. 2004 On the time to send the heartbeat signal the FSP node generates the 2005 SNACK header, then generate and send a new KEEP_ALIVE or ACK_FLUSH 2006 packet to carry the SNACK header. It SHALL send an ACK_FLUSH if it is 2007 in PEER_COMMIT, COMMITTING2 or CLOSABLE state, otherwise it SHALL 2008 send a KEEP_ALIVE packet. 2010 8.5.3. Negative acknowledgment of Packets Sent 2012 Both the ACK_FLUSH and the KEEP_ALIVE packet in FSP carry the SNACK 2013 extension header, although number of gap descriptors in the SNACK 2014 extension header in the ACK_FLUSH packet MUST be 0. We call them 2015 SNACK packets. A SNACK packet P1 is said to be later than P0, if and 2016 only if SN of P1 is later than SN of P0, or SN of P1 equals SN of P0 2017 while the out-of-band sequence number of P1 is later than the out-of- 2018 band sequence number of P0. If the latest SNACK packet is ACK_FLUSH, 2019 all the packets with the sequence number later that the expected 2020 field of the packet are assumed to be negatively acknowledged. 2022 By convention when we specify the range, the left square bracket 2023 meant to be inclusive, while the right parenthesis meant to be 2024 exclusive, the packets with SN in the ranges: 2025 [expectedSN, expectedSN + 1st Gap Width), 2027 [expectedSN + 1st Gap Width + 1st Data Length, 2028 expectedSN + 1st Gap Width + 1st DataLength + 2nd Gap Width), 2030 ... 2032 [expectedSN + 1st Gap Width + 1st Data Length 2033 + ... + (n-1)th Gap Width + (n-1)th Data Length, 2034 expectedSN + 1st Gap Width + 1st DataLength 2035 + ... + n-th Gap Width), 2037 together with the packets with SN later than {expectedSN + 1st Gap 2038 Width + 1st DataLength + ... + n-th Gap Width} are assumed to be 2039 negatively acknowledged, if the latest SNACK packet is KEEP_ALIVE. 2041 8.5.4. Retransmission Interval 2043 Any packet sent 4 times RTT earlier that is unacknowledged SHALL be 2044 retransmitted as soon as possible. 2046 FSP does not exploit Exponential backoff on setting retransmission 2047 interval. However, retransmission is subjected to send rate control 2048 at the underlying congestion management service sub-layer. 2050 8.6. Flow Control 2052 The participants of an FSP connection negotiate the initial receive 2053 window size with the FREWS field in the ACK_CONNECT_REQUEST packet, 2054 and the first PERSIST or ACK_START packet that acknowledges the 2055 ACK_CONNECT_REQUEST packet, respectively. The receive window size 2056 SHALL NOT be less than 4 and SHALL be less than 2^24. 2058 An FSP participant advertises current receive window size in the 2059 FREWS field. 2061 An FSP participant SHALL NOT send a packet whose sequence number is 2062 later than the value of the ExpectedSN field plus the advertised 2063 receive window size, where both value come from the very packet 2064 received with the latest sequence number. 2066 8.7. Congestion Control 2068 FSP supposes that end-to-end congestion control is provided by some 2069 shim layer, such as the congestion manager [RFC3124] between the 2070 "traditional" IP layer and the FSP transport layer. The shim layer is 2071 considered as a sub-layer of the network layer. Implementation of FSP 2072 MUST provide such shim layer if the network layer of the end node 2073 does not provide end-to-end congestion management service. 2075 FSP layer SHALL provide following information to the congestion 2076 manager as soon as the first packet on the fly was acknowledged by 2077 any mean, or a legitimate packet falling in the receive window with 2078 the ECE flag set is received: 2080 - The local interface number that the packet carrying the ECE signal 2081 is accepted. 2083 - The remote network prefix that the congestion information is meant 2084 to associate. Note that the aggregated host ID part is NOT included 2085 in the prefix. 2087 - The traffic class. For FSP it is bisected: MIND flag set or not. 2089 - Number of outstanding octets, including all of those in the payload 2090 AND the FSP headers. 2092 - The effective round trip time calculated in the most recent period. 2093 Note that retransmitted packets MUST be excluded on calculating the 2094 effective RTT. 2096 - Whether an ECN-Echo signal was received. The ECE flag of a 2097 legitimate packet falling in the receive window is the ECN-Echo 2098 signal. 2100 - Whether a sent packet with SRR flag set is acknowledged. 2102 The congestion manager SHOULD reduce the send rate if the FSP sender 2103 informed it that an ECN-Echo signal was received. 2105 The sender SHALL NOT inform the congestion manager to reduce the send 2106 rate again even if further packet with ECE flag set is received, 2107 until at least one sent packet with SRR flag set is acknowledged. 2109 A packet with ECE flag set received after the packet with SRR flag 2110 set is acknowledged SHOULD make the congestion manager reduce the 2111 send rate again. 2113 Retransmitted packet SHALL be subjected to send rate control at the 2114 underlying congestion management service sub-layer as well. 2116 Quota or other means to enforce fairness among various FSP 2117 connections SHOULD be provided directly to the ULA by the congestion 2118 management service. 2120 Requirement of an FSP congestion manager would be detailed in a 2121 separate document. 2123 8.8. On-the-Wire Compression 2125 FSP exploits the lossless compression algorithm as per [LZ4]. 2127 If the CPR flag of the first packet of a transmit transaction is set, 2128 compression is applied on the payload octet stream of the transaction 2129 transaction. 2131 When applying compression FSP divides source stream into multiple 2132 blocks. For this version of FSP length of each block is 128KiB 2133 (131072 octets), except the final block whose length may be less than 2134 or equal to 128KiB. The final block is the one that terminate the 2135 transmit transaction, i.e. which contains the last FSP packet of the 2136 transmit transaction. The last FSP packet of the transmit transaction 2137 has the EoT flag set. The "LZ4_compress_fast_continue" method SHALL 2138 be applied on each block. That is, data from previous compressed 2139 blocks are taken use for better compression ratio. 2141 When transferring the result data of compressing each block, the 2142 result data is prefixed with its length. The length is expressed by a 2143 4-octets little-endian integer. 2145 On-the-wire compression of each transmit transactions is independent. 2146 It is the upper layer application that SHALL make agreement on which 2147 transmit transaction utilizes on-the-wire compression. 2149 8.9. Milk Like Payload and Minimal Delay Service 2151 An ordinary data flow is wine-like in the sense that the older data 2152 are more valuable. If it has to, data packet sent latest are dropped 2153 first. In the contrary, milk-like payload is that the newer data are 2154 more precious and outdated data packet can be discarded. 2156 When ULA is willing to accept incomplete message the peer of the 2157 underling FSP node SHALL set the MIND flag of the first PERSIST 2158 packet that starts the first transmit transaction, and set the MIND 2159 flag of every following PURE_DATA packet, while set the Traffic Class 2160 of the underlying IPv6 packet to some registered value. 2162 In the transmission path, any relaying middle box, be it router or 2163 switch, should reserve a reasonably short queue for the packet flow 2164 of such flow to minimize delay. 2166 When the receive buffer overflows the receiver discards the 2167 undelivered packet received first to free buffer space for the latest 2168 packet received. However it keeps order on delivering the packets to 2169 he ULA. ULA may choose to discard packets received earlier than some 2170 threshold. 2172 The receiver SHOULD NOT make any acknowledgement to the packet 2173 received with the MIND flag set. 2175 Minimal delay service is asymmetric in the sense that one 2176 transmission direction the data flow may be milk-like while in the 2177 reverse direction the data flow may be wine-like. 2179 A minimal delay service data flow is terminated by ULA via some out- 2180 of-band control mechanism. 2182 9. Graceful Shutdown 2184 One participant of an FSP connection MAY initiate graceful shutdown 2185 of the connection if and only if its peer has committed the most 2186 recent transmit transaction. 2188 By initiating graceful shutdown the participant tells its peer that 2189 current transmit transaction is to be committed as well. 2191 9.1. Initiation of Graceful Shutdown 2193 (RELEASE, SN, ExpectedSN, ICC, FREWS) 2195 An FSP end node may initiate graceful shutdown only if the connection 2196 is in the CLOSABLE state. 2198 Graceful shutdown is signaled to the remote end by sending a RELEASE 2199 command packet. The FSP connection SHALL migrate to the PRE_CLOSED 2200 state just before sending the RELEASE packet. 2202 9.2. Acknowledgment of Graceful Shutdown 2204 (RELEASE, SN, ExpectedSN, ICC, FREWS) 2206 The RELEASE packet may be accepted in the COMMITTING2, CLOSABLE or 2207 PRE_CLOSED state only. 2209 The receiver of the RELEASE packet automatically migrates to the 2210 CLOSABLE state when the packet is received in the COMMITTING2 state. 2212 If the receiver of the RELEASE packet is in COMMITTING2 or CLOSABLE 2213 state the ULA SHALL be notified with the connection shutdown request. 2215 In all of these cases a reverse RELEASE packet MUST be sent 2216 immediately after the original RELEASE packet is received. 2218 If the RELEASE packet is received in the PRE_CLOSED state it is 2219 supposed that the grace shutdown request is acknowledged. The 2220 connection SHALL migrate to CLOSED state immediately. 2222 9.3. Finalization of Graceful Shutdown 2224 If a legitimate RELEASE command packet is received in the COMMITTING2 2225 or CLOSABLE state the receiver is passively shutdown, and the 2226 shutdown is finalized in the sense that it does not expect any 2227 acknowledgement of the reverse RELEASE packet required to be sent, 2228 although race condition may occur. 2230 The FSP node in the PRE_CLOSED state migrates to the CLOSED state 2231 after the corresponding RELEASE packet is received. It is supposed 2232 that the original grace shutdown request is acknowledged and the 2233 shutdown is finalized. 2235 Graceful shutdown in FSP is asymmetric in the sense that it does not 2236 require both ULA participants to call the Shutdown API. 2238 9.4. Retransmission of RELEASE Packet 2240 The FSP end node in the PRE_CLOSED state SHALL retransmit the RELEASE 2241 packet until it migrates to CLOSED state or it is timed out. Interval 2242 between the retransmission is hard-coded to 4 times of RTT. 2244 The RELEASE packet that was sent in the COMMITTING2 or CLOSABLE state 2245 state shall never be retransmitted. 2247 10 Mobility and Multi-home Support 2249 10.1. Heartbeat Signals 2251 FSP requires that the participants periodically send the heartbeat 2252 signals. 2254 The participant in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2255 COMMITING2 or CLOSABLE state MUST send the KEEP_ ALIVE packet as the 2256 heart-beat signal periodically to retain the connection in case that 2257 underlying IP address has changed. 2259 (KEEP_ALIVE, SN, ExpectedSN, ICC, FREWS, Sink Parameter, SNACK) 2261 Heartbeat signal is an out-of-band control packet. It does not carry 2262 payload. The sequence number of the KEEP_ALIVE packet SHALL be set to 2263 the latest sequence number of all of the packets that have been sent. 2265 Only the FSP node in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2266 COMMITING2 or CLOSABLE state MAY process the heartbeat signal. 2268 In this version of FSP the heat-beat period is arbitrarily set to 600 2269 seconds. 2271 10.2. Active Address Change Signaling 2273 During communication process the FSP participant whose underlying IP 2274 address is changed SHOULD inform its peer such change by transmit a 2275 KEEP_ALIVE packet with the Sink Parameter extension header and the 2276 SNACK header so that the peer can retransmit the packets that were 2277 negatively acknowledged. 2279 Such informing KEEP_ALIVE packet SHALL be sent in the ACTIVE, 2280 COMMITTING, COMMITTED, PEER_COMMIT, COMMITING2 or CLOSABLE state. 2282 Informing KEEP_ALIVE packet SHOULD be sent more frequently than a 2283 normal heart-beat signaling KEEP_ALIVE packet. 2285 For this version of FSP informing KEEP_ALIVE packet SHALL be 2286 retransmitted every 4 RTT interval until the heuristic 2287 acknowledgement is received. 2289 10.3. Heuristic Remote Address Change Adaptation 2291 A participant of the FSP connection SHALL set the source address of 2292 the packet to transmit or retransmit to new IP address as soon as the 2293 near-end IPv4 address or IPv6 network prefix has changed. The ULTID 2294 field MUST remain the same. 2296 When a new packet with a later sequence number is received and the 2297 source IP address of the packet is found to be different with the 2298 preserved IP address of the remote end, the receiver SHOULD 2299 automatically update the preserved IP address of the remote end to 2300 the source IP address of the new packet, unless there is a Sink 2301 Parameter header in the packet. 2303 If the sequence number of the packet received is not the latest in 2304 the receive window the preserved IP address of the remote end SHALL 2305 NOT be updated even if the source address of the received packet has 2306 changed. 2308 10.4. Heuristic Address Change Acknowledgement 2310 The address change signaling KEEP_ALIVE packet is supposed to be 2311 acknowledged if a packet targeted at the new IP address that the 2312 KEEP_ALIVE packet has informed is received. 2314 10.5. NAT-traversal and Multihoming 2316 When FSP is implemented over UDP in the IPv4 network, each endpoint 2317 of the FSP connection is bound one and only one IPv4 address as soon 2318 as the connection is established. Each endpoint SHALL choose the 2319 source IPv4 address of the last packet received as the destination 2320 IPv4 address of the packet that it is to send later. By this mean FSP 2321 over UDP is NAT-friendly. 2323 When FSP is implemented over IPv6 as soon as the connection is 2324 established the IPv6 address may be changed dynamically, and one more 2325 alternate IP address may be added or removed dynamically for 2326 individual endpoint as well, provided that ULTID part keeps unchanged 2327 while the host IDs part of all IPv6 address of the endpoint are of 2328 the same value at any given moment. 2330 The sender may choose as the source IP address by selecting any 2331 network prefix that it has most-recently sent to its peer in the 2332 allowed address list field of the Sink Parameter header, joining with 2333 the host ID in the Sink Parameter header and the stable ULTID of the 2334 sender, and choose as the destination IP address by selecting any 2335 network prefix in the allowed address list field of the Sink 2336 Parameter header most-recently received from its peer, joining with 2337 the peer's host ID and the peer's ULTID. Thus multiple multi-homed 2338 paths MAY co-exist between the two FSP endpoints. 2340 10.6. Explicit Multi-home Informing 2342 If an FSP end node is configured with multiple IPv4 address other 2343 than the loop-back address, or with multiply global unicast IPv6 2344 address, it MAY advertise multiple underlying addresses to the remote 2345 end by put them in the addressable network prefix list of the Sink 2346 Parameter extension header. The Sink Parameter extension header may 2347 be carried in the CONNECT_REQUEST, ACK_CONNECT_REQ, ACK_START, 2348 MULTIPLY or KEEP_ALIVE packet. 2350 Any participant of the communication SHALL NOT make discrimination of 2351 the source or destination IP address of any packet provided that both 2352 the source ULTID and the destination ULTID keep unchanged and the ICC 2353 field passes verification. 2355 11 Connection Multiplication 2357 Connection multiplication is the process of incarnating a new 2358 connection context by re-using security context of an established 2359 connection. 2361 11.1. Request to Multiply Connection 2363 (MULTIPLY, SN, Salt, ICC, FREWS [, Sink Parameter] [, payload]) 2365 The initiator's initial sequence number of the new connection is the 2366 sequence number of the packet that piggybacks the connection 2367 multiplication header. The ExpectedSN field of the normal packet 2368 store a Salt value instead. 2370 The FREWS field MUST be processed in the new connection context while 2371 the ICC MUST be calculated with the session key of the original 2372 connection. 2374 The new connection inherits the remaining key life. ULA SHOULD 2375 negotiate new session key and/or install new session key as soon as 2376 possible. 2378 The optional payload of the MULTIPLY packet MUST be processed in the 2379 new connection context. 2381 The MULTIPLY packet is an out-of-band command packet in the original 2382 connection context. 2384 11.2. Response to Connection Multiplication Request 2386 Case 1: (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter]) 2388 Case 2: (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload) 2390 Case 3: (RESET, SN, ExpectedSN, ICC, FREWS, Reason of Failure) 2392 In all of these cases the ULTID of the remote-end MUST be the value 2393 of the initiator's ULTID in the connection multiplication header. 2395 It is REQUIRED that only a connection in the ESTABLISHED, COMMITTING, 2396 COMMITTED, PEER_COMMIT, COMMITTING2 or CLOSABLE state may accept a 2397 connection multiplication request. 2399 In case 1 the responder admits the multiplication request AND commit 2400 the transmit transaction, the new connection enters into the 2401 PEER_COMMIT or CLOSABLE state immediately, on request of ULA. 2403 In case 2 the responder admits the multiplication request and the new 2404 connection enters into the ESTABLISHED, PEER_COMMIT, or COMMITTING or 2405 CLOSABLE state immediately, depending whether the ULA of the 2406 multiplication initiator has requested to commit the transmit 2407 transaction immediately and whether the ULA of the multiplication 2408 responder has requested to commit the transmit transaction in the 2409 reverse direction immediately. 2411 In case 3 the responder rejects the multiplication request. To defend 2412 against spoofing attack ICC MUST be valid. The value of the SN field 2413 MUST equal the value of the 'Expected SN' field of the requesting 2414 MULTIPLY packet while the value of ExpectedSN field MUST equal the 2415 value of the 'Sequence No' field. 2417 The new connection MUST derive new session key from the session key 2418 of the original connection where the out-of-band requesting MULTIPLY 2419 packet is received immediately. 2421 11.3. Duplicate Detection of Connection Multiplication Request 2422 Every time the responder of connection multiplication receives a 2423 MULTIPLY packet it MUST check the suggested responder's ULTID and the 2424 initiator's ULTID. 2426 The responder MUST reject the multiplication request if the suggested 2427 responder's ULTID equals the near-end ULTID of some connection and 2428 the remote-end ULTID of that connection does not equal the 2429 initiator's ULTID. 2431 The responder MUST recognize the MULTIPLY packet as a duplicate 2432 connection request if some connection matches the request and SHOULD 2433 response by retransmitting the head packet of the send queue of the 2434 matching connection, be it a PERSIST or an COMMIT packet. A 2435 connection matches the MULTIPLY request if and only if the suggested 2436 responder's ULTID in the MULTIPLY packet equals the near-end ULTID of 2437 the connection and the initiator's ULTID equals the remote-end ULTID 2438 of the connection. 2440 11.4. Retransmission 2442 The initiating side SHALL retransmit the MULTIPLY packet if the 2443 corresponding PERSIST packet is not received in some limit time (by 2444 default 15 seconds). 2446 11.5. Key Derivation for Branch Connection 2448 Let K_out = BLAKE2(Km, [d] || Label || 0x00 || Context || L), where: 2450 - Km 2451 is the master key, 2453 - [d] 2454 is one octet of integer Depth. It is alike the KDF counter mode 2455 as the NIST SP800-108. For this version of FSP it is the fixed 2456 number 1, 2458 - Label 2459 is the fixed ASCII string "Multiply an FSP connection" which is 2460 26-octet long for this version of FSP, 2462 - Context 2463 is concatenation of two 32-bit words idB and idR 2465 idB is the ULTID allocated for the branch connection in the 2466 context of the multiplication initiator. idB is byte-order 2467 neutral. 2469 idR is the receiver side ULTID of the original connection that is 2470 to accept the connection multiplication request. idI or idR is 2471 byte-order neutral. 2473 - L 2474 is a 32-bit network byte-order integer specifying the length in 2475 bits of the derived key K-out 2477 12 Timeouts and Abrupt Close 2479 12.1. Timeouts in End-to-End Negotiation 2481 Initially the initiator is in the CONNECT_BOOTSTRAP state. It 2482 migrates to the CONNECT_ AFFIRMING state after it received the 2483 legitimate ACK_INIT_CONNECT packet. Then it migrates to the 2484 PEER_COMMIT or CLOSABLE state after it received the legitimate 2485 ACK_CONNECT _REQ packet, depending on the hint of ULA. 2487 The responder incarnates a new connection context which is initially 2488 in the CHALLENGING state after accepting a legitimate Connect Request 2489 packet. Then it migrates to the COMMITTING or CLOSABLE state, 2490 depending on the packet received from its peer. 2492 If the initiator or the responder is unable to migrate to a new state 2493 in some limit time (by default 60 seconds, except in LISTENING state) 2494 it aborts the connection by recycling the connection context. 2496 12.2. Timeouts in Multiply 2498 Initially the initiating side of Connection Multiplication is in the 2499 CLONING state. It migrates to the ACTIVE, COMMITTED, PEER_COMMIT or 2500 CLOSABLE state after it received the legitimate PERSIST packet. Which 2501 state to migrated depends on the EoT flag of the initiating MULTIPLY 2502 packet and the responding PERSIST packet. 2504 If the initiating side is unable to migrate to a new state in some 2505 limit time (by default 60 seconds) it aborts multiplication by 2506 recycling the new connection context. 2508 12.3. Timeout of Transmit Transaction Commitment 2510 The FSP node MUST abort the connection if the time of no packet 2511 having arrived has exceed certain limit in the COMMITTING or 2512 COMMITTING2 state. 2514 In this FSP version, timeout of transmit transaction commitment is 2515 set to 5 minutes. 2517 12.4. Timeout of Graceful Shutdown 2518 It simply migrates to the NON_EXISTENT pseudo-state if timeout in the 2519 PRE_CLOSED state. 2521 In this FSP version, timeout of Graceful Shutdown is set to 1 minute. 2523 12.5. Idle Timeout 2525 If one participant has not received any packet nor has it sent any 2526 packet in some limit time, it MUST be abruptly closed. 2528 In this FSP version the time limit, or the idle timeout, is set to 4 2529 hours. 2531 12.6. Session Key Timeout 2533 For this FSP version if a secret key is applied for more than 2^30 2534 times the FSP node MUST abruptly closed instantly. 2536 12.7. Abrupt Close 2538 An FSP node abruptly shutdown a session by sending a RESET packet and 2539 release all of the resource occupied by the the session immediately. 2541 (RESET, SN, ExpectedSN, ICC, Reason of Failure) 2543 13 Issues for Further Study 2545 13.1. Resolution of ULTID in DNS 2547 There are two patterns of IP address resolution in FSP: the DNS- 2548 compatible pattern and the proxy pattern. The former pattern relies 2549 on some name service to resolve the IP address of the responder for 2550 the initiator before they exchange end-to-end negotiation packets. 2552 In the DNS-compatible pattern, the responder side of the FSP 2553 participants registered its address identifier, such as 'domain name' 2554 in some name service such as DNS [RFC1034][RFC1035], according to 2555 some pre-agreement at first. The initiator resolves the current IP 2556 address of the responder by consulting the name service, such as 2557 looking after the A or AAAA record [RFC3596] of the domain name in 2558 DNS. 2560 If UDP over IPv4 is exploited as the under layer data packet delivery 2561 service the port number of the responder is firstly resolved just 2562 alike normal network application such as HTTP. Then it is extended to 2563 32-bit ULTID, and ULTIDs of FSP can be considered as the superset of 2564 TCP port numbers. 2566 If the string representation of IPv4/IPv6 address is applied directly 2567 as the peer's address identifier instead of the domain name there is 2568 no need for some real address resolution. But from the API caller's 2569 point of view it is a DNS-compatible mode address resolution. 2571 13.2. Proxy Pattern for Syndicated Name Resolution 2573 The proxy pattern of IP address resolution in FSP is to embed the 2574 address resolution information in the connection initialization 2575 packets and is designed to work in FSP over IPv6 mode only. 2577 In IPv6 network the rightmost 32 bits of the IPv6 address directly 2578 maps to the ULTID so FSP does not need additional multiplexing 2579 mechanism such as port number. And it needs not consult SRV record or 2580 look for some entry in some 'services' file. 2582 If the INIT_CONNECT packet carries the responder's host name it MUST 2583 take the link-local interface address as the source IPv6 address and 2584 the default link-local gateway address, FE80::1, as the destination 2585 IPv6 address no matter whether the global unicast IP address of the 2586 default gateway is configured. In such scenario the link-local 2587 gateway MUST be able to resolute the responder's host name to its 2588 global unicast IPv6 address, and the gateway MUST be able to map the 2589 initiator's link local address to its global unicast IPv6 address. 2591 If the gateway that relays the INIT_CONNECT packet finds that the 2592 responder is on the same link-local network with the initiator it 2593 SHALL change the source and the destination IP addresses of the 2594 INIT_CONNECT packet to the link-local IP addresses of the initiator 2595 and the responder respectively, and relay the packet onto the same 2596 link-local network. 2598 On receiving the INIT_CONNECT packet that carries the responder's 2599 host name the link-local gateway MUST resolute the responder's global 2600 unicast IPv6 address and map the initiator's global unicast IPv6 2601 address, and replace the destination and source address of the 2602 INIT_CONNECT packet respectively, unless it finds that the initiator 2603 and the responder are on the same link-local network, where the 2604 gateway SHALL process the packet as stated in the previous statement. 2606 13.3. Asymmetric Transmission 2608 If there is one participant whose receive interface is not the same 2609 as the send interface the participant is called an asymmetric- 2610 transmissioned node. 2612 Asymmetric transmission itself is asymmetric in the sense that one 2613 participant may be asymmetric-transmissioned node while its peer is a 2614 normal node that the send interface is the same receive interface. 2616 An end node is asymmetric-transmissioned if it received an 2617 ACK_CONNECT_REQ packet, ACK_START or PERSIST packet whose source IP 2618 address that the network interface accepting the packets reported is 2619 not in the allowed IP address list in the Sink Parameter header of 2620 the packet. 2622 For an asymmetric-transmissioned remote end, the near end cannot rely 2623 on automatic IP address change detection. Instead IP address change 2624 notification mechanism shall be utilized. 2626 However for this version of FSP asymmetric transmission support is 2627 optional. 2629 14 Security Considerations 2631 14.1. Deny of Service Attack 2633 FSP is designed to mitigate effect of DoS attack by exploiting Cookie 2634 . 2636 However, resistance against distributed DoS attack relies on external 2637 mechanism such as Distributed-Denial-of-Service Open Threat Signaling 2638 [DOTS]. 2640 14.2. Replay Attack 2642 In-band sequence number and out-of-band sequence number are exploited 2643 to resist against replay attack. 2645 14.3. Passive Attacks 2647 AEAD MAY be exploited by the ULA to protect it against passive 2648 attacks such as eavesdropping, gaining advantage by analyzing the 2649 data sent. 2651 MAC only service MAY also be utilized. Together with application 2652 layer stream-mode encryption it protects the ULA against passive 2653 attacks as well. 2655 14.4. Masquerade Attack 2657 Both AEAD and MAC only service may be exploited to protect the 2658 endpoints against masquerade attack. 2660 If proxy pattern for syndicated name resolution is exploited for FSP 2661 over IPv6, secure neighbor discovery [RFC3971] SHOULD be applied 2662 instead of common neighbor discovery whenever it is feasible. 2664 14.5. Active Man-In-The-Middle Attack 2666 The ULA SHALL take account to protect itself against MITM attack when 2667 making client authentication and key establishment. 2669 14.6. Privacy Concerns 2671 It is beneficial for privacy protection that the ULTID of each 2672 endpoints of an FSP connection is generated randomly [RFC7721]. 2674 15 IANA Considerations 2676 It should be requested that the port number registered for UDP 2677 packets encapsulating FSP in the IPv4 network. The port number 18003 2678 is exploited in the concept prototype implementation. The number is 2679 the decimal presentation of ASCII codes of the character 'F' ('x46') 2680 and 'S' ('x53') concatenated in network byte order. 2682 It should be requested that the 'Next Header'/protocol number is 2683 assigned for FSP over IPv6. Decimal number 144 is exploited in the 2684 concept prototype implementation. 2686 16 References 2688 16.1. Normative References 2690 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 2691 2693 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 2694 Cartridges - DLT1 Format Standard, Annex B", ECMA-182, 2695 December 1992. 2697 [LZ4] https://lz4.github.io/lz4/ 2699 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 2700 Galois/Counter Mode (GCM) and GMAC", November 2007. 2701 2703 [OSI/RM] ISO and IEC, "Information technology-Open Systems 2704 Interconnection - Basic Reference Model: The Basic Model", 2705 ISO/IEC 7498-1 Second edition, November 1994. 2706 2708 [R01] Rogaway, P., "Authenticated encryption with Associated- 2709 Data", ACM Conference on Computer and Communication 2710 Security (CCS'02), pp. 98-107, ACM Press, 2002. 2712 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2713 Communication Layers", STD 3, RFC 1122, DOI 2714 10.17487/RFC1122, October 1989, . 2717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2718 Requirement Levels", BCP 14, RFC 2119, DOI 2719 10.17487/RFC2119, March 1997, . 2722 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 2723 RFC 3124, DOI 10.17487/RFC3124, June 2001, 2724 . 2726 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2727 of Explicit Congestion Notification (ECN) to IP", 2728 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2729 . 2731 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2732 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2733 2003, . 2735 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2736 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2737 2006, . 2739 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2740 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2741 December 2005, . 2743 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2744 Key Derivation Function (HKDF)", RFC 5869, DOI 2745 10.17487/RFC5869, May 2010, . 2748 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2749 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 2750 10.17487/RFC6887, April 2013, . 2753 [RFC7693] Saarinen, M-J., Ed., and J-P. Aumasson, "The BLAKE2 2754 Cryptographic Hash and Message Authentication Code (MAC)", 2755 RFC 7693, DOI 10.17487/RFC7693, November 2015, 2756 . 2758 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2759 (IPv6) Specification", STD 86, RFC 8200, DOI 2760 10.17487/RFC8200, July 2017, . 2763 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 2764 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 2765 . 2767 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2768 1981. 2770 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2771 August 1980. 2773 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 2774 793, September 1981. 2776 16.2. Informative References 2778 [DOTS] Mortensen, A., Andreasen, F., Reddy, T., Gray, C., Compton 2779 R., and N. Teague, "Distributed-Denial-of-Service Open 2780 Threat Signaling (DOTS) Architecture", March 2018, 2781 2784 [Gao2002] Gao, J., "Fuzzy-layering and its suggestion", IETF Mail 2785 Archive, September 2002, 2786 https://mailarchive.ietf.org/arch/msg/ietf/u-6i-6f- 2787 Etuvh80-SUuRbSCDTwg 2789 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2790 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2791 . 2793 [RFC1035] Mockapetris, P., "Domain names - implementation and 2794 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2795 November 1987, . 2797 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2798 Address Translator (Traditional NAT)", RFC 3022, DOI 2799 10.17487/RFC3022, January 2001, . 2802 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2803 C., and M. Carney, "Dynamic Host Configuration Protocol 2804 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2805 2003, . 2807 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2808 "DNS Extensions to Support IP Version 6", STD 88, 2809 RFC 3596, DOI 10.17487/RFC3596, October 2003, 2810 . 2812 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2813 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2814 DOI 10.17487/RFC3633, December 2003, . 2817 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2818 "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 2819 10.17487/RFC3971, March 2005, . 2822 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2823 "Randomness Requirements for Security", BCP 106, RFC 4086, 2824 DOI 10.17487/RFC4086, June 2005, . 2827 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2828 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2829 RFC 4106, DOI 10.17487/RFC4106, June 2005, 2830 . 2832 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2833 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 2834 . 2836 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2837 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2838 DOI 10.17487/RFC4861, September 2007, . 2841 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2842 Address Autoconfiguration", RFC 4862, DOI 2843 10.17487/RFC4862, September 2007, . 2846 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 2847 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 2848 . 2850 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2851 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2852 . 2854 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 2855 Model: The Relationship between Links and Subnet 2856 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 2857 . 2859 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 2860 Detecting Network Attachment in IPv6", RFC 6059, DOI 2861 10.17487/RFC6059, November 2010, . 2864 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 2865 Assignment to End Sites", BCP 157, RFC 6177, DOI 2866 10.17487/RFC6177, March 2011, . 2869 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2870 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2871 2011, . 2873 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2874 the IPv6 Prefix Used for IPv6 Address Synthesis", 2875 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2876 . 2878 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 2879 and D. Wing, "IPv6 Multihoming without Network Address 2880 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 2881 . 2883 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2884 Scheffenegger, Ed., "TCP Extensions for High Performance", 2885 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2886 . 2888 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 2889 Length Recommendation for Forwarding", BCP 198, RFC 7608, 2890 DOI 10.17487/RFC7608, July 2015, . 2893 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2894 Considerations for IPv6 Address Generation Mechanisms", 2895 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2896 . 2898 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 2899 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 2900 . 2902 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2903 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2904 March 2017, . 2906 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2907 Writing an IANA Considerations Section in RFCs", BCP 26, 2908 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2909 . 2911 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 2912 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 2913 May 2017, . 2915 [tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D. 2916 Boneh, "The case for ubiquitous transport-level 2917 encryption", USENIX Security , 2010. 2919 17 Acknowledgements 2921 Authors' Addresses 2923 Jason Gao 2924 Beijing Static Traffic Investment and Operation Co.,Ltd. 2925 Shouke Plaza-A, Liuliqiao South, Fengtai 2926 Beijing 2927 People's Republic of China 2929 EMail: jagao@outlook.com