idnits 2.17.1 draft-gao-flexible-session-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 73) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2020) is 1463 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC4801' is mentioned on line 812, but not defined == Unused Reference: 'RFC4106' is defined on line 3371, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 3380, but no explicit reference was found in the text == Unused Reference: 'RFC8084' is defined on line 3415, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 3419, but no explicit reference was found in the text == Unused Reference: 'RFC8170' is defined on line 3424, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. 'STD7') (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gao 3 Internet-Draft Individual 4 Intended status: Experimental April 17, 2020 5 Expires: October 19, 2020 7 Flexible Session Protocol 8 draft-gao-flexible-session-protocol-04 10 Abstract 12 FSP is a connection-oriented transport layer protocol that provides 13 mobility and multihoming support by introducing the concept of 'upper 14 layer thread ID', which is associated with some shared secret that is 15 applied with some secure hash or authenticated encryption algorithm 16 to protect authenticity of the origin of the FSP packets. It is able 17 to provide following services to the upper layer application: 19 o Stream-oriented send-receive with native message boundary 21 support 23 o Ubiquitous authenticated encryption 24 o 0-RTT multiplication of connections 25 o On-the-wire compression 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 19, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 62 1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 9 63 1.1.1. Transmit Transaction . . . . . . . . . . . . . . . . 9 64 1.1.2. Transport Layer Mobility Support . . . . . . . . . . 9 65 1.1.3. Ubiquitous Authenticated Encryption . . . . . . . . . 9 66 1.1.4. 0-RTT Multiplication of Connections . . . . . . . . . 9 67 1.1.5. On-the-wire Compression . . . . . . . . . . . . . . . 9 68 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 10 69 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 10 70 2. Abbreviations and Idioms . . . . . . . . . . . . . . . . . . 11 71 3. Key Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 13 72 3.1. Underlying Layer Services Required . . . . . . . . . . . 13 73 3.1.1. High Mobility . . . . . . . . . . . . . . . . . . . . 13 74 3.1.2. Network Address Change Notification . . . . . . . . . 13 75 3.1.3. Network Congestion Control . . . . . . . . . . . . . 14 76 3.2. Identifying Connection by Local ULTID . . . . . . . . . . 14 77 3.3. Defending Against Connection Hijacking with ICC . . . . . 14 78 3.4. Synchronizing Key Installation with Transmit Transaction 15 79 3.5. 0-RTT Connection Multiplication with OOB Packet . . . . . 15 80 4. Packet Structure . . . . . . . . . . . . . . . . . . . . . . 16 81 4.1. FSP over UDP/IPv4 . . . . . . . . . . . . . . . . . . . . 16 82 4.2. FSP over IPv6 . . . . . . . . . . . . . . . . . . . . . . 17 83 4.3. Generic FSP Header . . . . . . . . . . . . . . . . . . . 19 84 4.4. FSP Header Signature and Code-Mark-Length Prefix . . . . 19 85 4.4.1. Operation Code . . . . . . . . . . . . . . . . . . . 20 86 4.4.2. Major . . . . . . . . . . . . . . . . . . . . . . . . 21 87 4.4.3. Mark . . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.4.4. Offset . . . . . . . . . . . . . . . . . . . . . . . 22 89 4.4.5. Length . . . . . . . . . . . . . . . . . . . . . . . 22 90 4.5. Preliminary FSP Packets . . . . . . . . . . . . . . . . . 22 91 4.5.1. Connect Initialization . . . . . . . . . . . . . . . 22 92 4.5.2. Acknowledgment to Connect Initialization . . . . . . 23 93 4.5.3. Connect Request . . . . . . . . . . . . . . . . . . . 24 94 4.6. Normal Fixed Header . . . . . . . . . . . . . . . . . . . 26 95 4.7. Sink Parameter . . . . . . . . . . . . . . . . . . . . . 28 96 4.8. Selective Negative Acknowledgment . . . . . . . . . . . . 29 97 4.9. RESET . . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 5. The Finite State Machine . . . . . . . . . . . . . . . . . . 32 99 5.1. NON_EXISTENT ---:API: Listen:-->LISTENING |--:API: 100 Connect:-->CONNECT_BOOTSTRAP-->:Send INIT_CONNECT: 101 |--:API: Multiply:-->CLONING-->:Send MULTIPLY: . . . . . 32 102 5.2. LISTENING ---:API: Reset:-->NON_EXISTENT 103 |<-->:Rcv.INIT_CONNECT:{&& accepted}:Send 104 ACK_INIT_CONNECT: |<-->:Rcv.INIT_CONNECT:{&& 105 rejected}:Send RESET: |<-->:Rcv.CONNECT_REQUEST:{&& 106 duplication detected} _ _:Retransmit ACK_CONNECT_REQ: 107 |--:Rcv.CONNECT_REQUEST:-->{Notify} _ |-->:API: Accept: 108 _ -->{new context}CHALLENGING-->:Send 109 ACK_CONNECT_REQ: _ |-->:API: Reject:-->:Send RESET: 110 {abort new context, if any} . . . . . . . . . . . . . . . 32 111 5.3. CONNECT_BOOTSTRAP ---:API: Reset:-->NON_EXISTENT-->:Send 112 RESET: |--:Rcv.ACK_INIT_CONNECT:-->CONNECT_AFFIRMING _ 113 -->:Send CONNECT_REQUEST: 114 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On transient 115 state Timeout}-->NON_EXISTENT-->:Notify: . . . . . . . . 32 116 5.4. CONNECT_AFFIRMING ---:API: Reset:-->NON_EXISTENT-->:Send 117 RESET: |--:Rcv.ACK_CONNECT_REQ:-->:Notify: _ 118 |-->{Callback return to accept} _ -->{EOT} _ 119 |-->{No Payload to Send}-->COMMITTING2-->:Send ACK_START: 120 _ |-->{Has Payload to Send} _ 121 |-->{ULA-flushing}-->COMMITTING2 _ 122 -->:Send PERSIST with EoT: _ |-->{Not ULA- 123 flushing}-->PEER_COMMIT-->:Send PERSIST: _ |-->{Not 124 EOT} _ |-->{No Payload to Send}-->COMMITTING-->:Send 125 ACK_START: _ |-->{Has Payload to Send} _ 126 |-->{ULA-flushing}-->COMMITTING _ -->:Send 127 PERSIST with EoT: _ |-->{Not ULA- 128 flushing}-->ESTABLISHED-->:Send PERSIST: _ 129 |-->{Callback return to reject:-->NON_EXISTENT-->:Send 130 RESET: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On 131 transient state Timeout}-->NON_EXISTENT-->:Notify: . . . 33 132 5.5. CHALLENGING ---:API: Reset:-->NON_EXISTENT-->:Send RESET: 133 |<-->:API: Send{new data}:{just pre-buffer} 134 |--:Rcv.ACK_START: _ |-->{ULA- 135 flushing}-->CLOSABLE-->:Notify: _ -->:Send 136 ACK_FLUSH: _ |-->{Not ULA- 137 flushing}-->PEER_COMMIT-->:Notify: _ -->:Send 138 ACK_FLUSH: |--:Rcv.PERSIST: _ |-->{EOT} _ 139 |-->{ULA-flushing}-->CLOSABLE-->:Notify: _ 140 -->:Send ACK_FLUSH: _ |-->{Not ULA- 141 flushing}-->PEER_COMMIT-->:Notify: _ -->:Send 142 ACK_FLUSH: _ |-->{Not EoT} _ |-->{ULA- 143 flushing}-->COMMITTED-->:Notify: _ -->:Send 144 delay SNACK: _ |-->{Not ULA- 145 flushing}-->ESTABLISHED-->:Notify: _ -->:Send 146 delay SNACK: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: 147 |--{On transient state Timeout}-->NON_EXISTENT-->:Notify: 33 148 5.6. ACTIVE{A.K.A. ESTABLISHED} ---:API: 149 Reset:-->NON_EXISTENT-->:Send RESET: |--:API: 150 Send{flush}:-->COMMITTING{Urge to commit} |<-->:API: 151 Send{more data}::Send PURE_DATA: |--:Rcv.NULCOMMIT: _ 152 -->PEER_COMMIT-->:Send ACK_FLUSH:-->:Notify: 153 |--:Rcv.PURE_DATA: _ |--{Not EOT}-->:Send 154 SNACK:-->:Notify: _ |--{EOT} _ 155 -->PEER_COMMIT-->:Send ACK_FLUSH:-->:Notify: 156 |--:Rcv.PERSIST: _ |--{Not EOT}-->:Send SNACK early: _ 157 |--:EOT: _ -->PEER_COMMIT-->:Send 158 ACK_FLUSH:-->:Notify: |--:Rcv.MULTIPLY:{passive 159 multiplication} |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: 160 |--{On Idle Timeout}-->NON_EXISTENT-->:Notify: . . . . . 34 161 5.7. COMMITTING ---:API: Reset:-->NON_EXISTENT-->:Send RESET: 162 |--:Rcv.ACK_FLUSH:-->COMMITTED-->:Notify: 163 |--:Rcv.NULCOMMIT: _ -->COMMITTING2-->:Send 164 ACK_FLUSH:-->:Notify: |--:Rcv.PURE_DATA: _ |--{Not 165 EOT}-->:Send SNACK:-->:Notify: _ 166 |--{EOT}-->COMMITTING2-->:Send ACK_FLUSH:-->:Notify: 167 |--:Rcv.MULTIPLY:{passive multiplication} 168 |--:Rcv.RELEASE: _ |--{Not EOT}{ignore} _ 169 |--:EOT:-->SHUT_REQUESTED-->:Send ACK_FLUSH:-->:Notify: 170 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On Idle 171 Timeout}-->NON_EXISTENT-->:Notify: . . . . . . . . . . . 34 172 5.8. COMMITTED ---:API: Reset:-->NON_EXISTENT-->:Send RESET: 173 |--:API: Send{more data}:-->ACTIVE-->:Send PERSIST: 174 |--:API: Send{flush}:-->COMMITTING-->{Flush the send 175 queue} |--:Rcv.NULCOMMIT: _ -->CLOSABLE-->:Send 176 ACK_FLUSH:-->:Notify: |--:Rcv.PURE_DATA: _ |-->{Not 177 EOT}-->:Send SNACK:-->:Notify: _ 178 |-->{EOT}-->CLOSABLE-->:Send ACK_FLUSH:-->:Notify: 179 |--:Rcv.PERSIST: _ |-->{Not EOT}-->:Send SNACK: _ 180 |-->{EOT}-->CLOSABLE-->:Send ACK_FLUSH:-->:Notify: 181 |--:Rcv.MULTIPLY:{passive multiplication} 182 |--:Rcv.RELEASE: _ |--{Not EOT}{ignore} _ 183 |--:EOT:-->SHUT_REQUESTED-->:Send ACK_FLUSH:-->:Notify: 184 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On Idle 185 Timeout}-->NON_EXISTENT-->:Notify: . . . . . . . . . . . 35 186 5.9. PEER_COMMIT ---:API: Reset:-->NON_EXISTENT-->:Send RESET: 187 |--:API: Send{flush}:-->{Mark EoT or append NULCOMMIT} _ 188 -->COMMITTING2-->{Do Send} |--:API: Shutdown:-->{Append 189 RELEASE} _ -->COMMITTING2-->{Do Send} |<-->:API: 190 Send{more data}::Send PURE_DATA: 191 |<-->:Rcv.PURE_DATA:{just prebuffer} 192 |<-->:Rcv.NULCOMMIT:-->:Send ACK_FLUSH: |--:Rcv.PERSIST: 193 _ |-->{Not EOT}-->ACTIVE-->:Send SNACK: _ 194 |<-->{EOT}-->:Send ACK_FLUSH: _ --{&& is new 195 transaction}-->:Notify: |--:Rcv.MULTIPLY:{passive 196 multiplication} |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: 197 |--{On Idle Timeout}-->NON_EXISTENT-->:Notify: . . . . . 35 198 5.10. COMMITTING2 ---:API: Reset:-->NON_EXISTENT-->:Send RESET: 199 |--:API: Shutdown:-->{Append RELEASE}-->PRE_CLOSED-->{Do 200 Send} |<-->:Rcv.PURE_DATA:{just prebuffer} 201 |<-->:Rcv.NULCOMMIT:-->:Send ACK_FLUSH: 202 |--:Rcv.ACK_FLUSH:-->CLOSABLE-->:Notify: |--:Rcv.PERSIST: 203 _ |-->{Not EOT}-->COMMITTING-->:Send SNACK: _ 204 |-->{EOT}-->:Send ACK_FLUSH: _ --{&& is a new 205 transaction}-->:Notify: |--:Rcv.MULTIPLY:{passive 206 multiplication} |--:Rcv.RELEASE:-->SHUT_REQUESTED _ 207 -->:Send ACK_FLUSH:-->:Notify: 208 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On Idle 209 Timeout}-->NON_EXISTENT-->:Notify: . . . . . . . . . . . 36 210 5.11. CLOSABLE ---:API: Reset:-->NON_EXISTENT-->:Send RESET: 211 |--:API: Send{more data}:-->PEER_COMMIT-->:Send PERSIST: 212 |--:API: Send{flush}:-->COMMITTING2-->{Flush the send 213 queue} |--:API: Shutdown:-->{Append 214 RELEASE}-->PRE_CLOSED-->{Do Send} 215 |<-->:Rcv.PURE_DATA:{just prebuffer} 216 |<-->:Rcv.NULCOMMIT:-->:Send ACK_FLUSH: |--:Rcv.PERSIST: 217 _ |-->{Not EOT}-->COMMITTED-->:Send SNACK: _ 218 |-->{EOT}-->:Send ACK_FLUSH: _ --{&& is a new 219 transaction}-->:Notify: |--:Rcv.MULTIPLY:{passive 220 multiplication} |--:Rcv.RELEASE:-->SHUT_REQUESTED _ 221 -->:Send ACK_FLUSH:-->:Notify: 222 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: . . . . . . . . 36 223 5.12. SHUT_REQUESTED ---:API: Reset:-->NON_EXISTENT-->:Send 224 RESET: |--:API: Shutdown:-->CLOSED-->:Notify: 225 |<-->:Rcv.RELEASE:-->:Send ACK_FLUSH: 226 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: . . . . . . . . 36 227 5.13. PRE_CLOSED ---:API: Reset:-->NON_EXISTENT-->:Send RESET: 228 |--:Rcv.ACK_FLUSH:-->CLOSED-->:Notify: 229 |--:Rcv.RELEASE:-->:Notify:-->CLOSED 230 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On transient 231 state Timeout}-->CLOSED-->:Notify: . . . . . . . . . . . 37 232 5.14. CLOSED |--{On Recycling Needed}-->NON_EXISTENT . . . . . 37 233 5.15. CLONING ---:API: Reset:-->NON_EXISTENT |<-->:API: 234 Send{new data}:{just prebuffer} |<-->:Rcv.PURE_DATA:{just 235 prebuffer} |--:Rcv.ACK_START: _ |--{&& Not ULA- 236 flushing}-->PEER_COMMIT _ -->:Send 237 ACK_FLUSH:-->:Notify: _ |--{&& ULA-flushing}-->CLOSABLE 238 _ -->:Send ACK_FLUSH:-->:Notify: |--:Rcv.PERSIST: _ 239 |-->{Not EOT} _ |--{&& Not ULA-flushing}-->ACTIVE _ 240 -->:Send SNACK:-->:Notify: _ |--{&& ULA- 241 flushing}-->COMMITTED _ -->:Send 242 SNACK:-->:Notify: _ |-->{EOT} _ |--{&& Not ULA- 243 flushing}-->PEER_COMMIT _ -->:Send 244 ACK_FLUSH:-->:Notify: _ |--{&& ULA- 245 flushing}-->CLOSABLE _ -->:Send 246 ACK_FLUSH:-->:Notify: 247 |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On transient 248 state Timeout}-->NON_EXISTENT-->:Notify: . . . . . . . . 37 249 5.16. Passive Multiplication {ACTIVE, COMMITTING, COMMITTED, 250 PEER_COMMIT, COMMITTING2, CLOSABLE} 251 |-->/MULTIPLY/-->:API{Callback}:-->{new 252 context}CONNECT_AFFIRMING |--> :{Return Accept}: _ 253 |-->{has payload prebuffered}-->{do respond} _ 254 |-->{without payload}-->:Prebuffer ACK_START:-->{do 255 respond} |-->:{Return Reject}:-->{abort creating new 256 context}:Send RESET: . . . . . . . . . . . . . . . . . . 37 257 5.17. Typical State Transitions . . . . . . . . . . . . . . . . 38 258 5.17.1. Typical Main Connection . . . . . . . . . . . . . . 38 259 5.17.2. Typical Clone Connection for Get Resource . . . . . 40 260 5.17.3. Typical Clone Connection for Push Message . . . . . 41 261 5.17.4. Simultaneous Shutdown . . . . . . . . . . . . . . . 42 262 6. End-to-End Negotiation . . . . . . . . . . . . . . . . . . . 43 263 6.1. Connect Initialization . . . . . . . . . . . . . . . . . 43 264 6.2. Response to Connect Initialization . . . . . . . . . . . 44 265 6.3. Connection Incarnation Request . . . . . . . . . . . . . 44 266 6.4. Connection Incarnation Response . . . . . . . . . . . . . 45 267 6.5. The Last Confirmation . . . . . . . . . . . . . . . . . . 46 268 6.6. Retransmission . . . . . . . . . . . . . . . . . . . . . 46 269 7. Quad-party Session Key Installation . . . . . . . . . . . . . 46 270 7.1. API for Session Key Installation . . . . . . . . . . . . 47 271 7.2. Time to Call API for Session Key Installation . . . . . . 48 272 7.3. Time to Take New Session Key into Effect . . . . . . . . 48 273 7.4. Generating the Initial Session Key . . . . . . . . . . . 48 274 7.5. Internal Rekeying . . . . . . . . . . . . . . . . . . . . 49 275 7.6. Sample Sequence of Installing Session Key . . . . . . . . 50 276 8. Send and Receive . . . . . . . . . . . . . . . . . . . . . . 51 277 8.1. Packet Integrity Protection . . . . . . . . . . . . . . . 52 278 8.1.1. Application of CRC64 . . . . . . . . . . . . . . . . 52 279 8.1.2. Packet Authentication Only . . . . . . . . . . . . . 52 280 8.1.3. Authenticated Encryption with Additional Data . . . . 53 281 8.1.4. ICC of the Out-of-Band Packet . . . . . . . . . . . . 54 282 8.2. Start a New Transmit Transaction . . . . . . . . . . . . 54 283 8.3. Send a Pure Data Packet . . . . . . . . . . . . . . . . . 54 284 8.4. Commit a Transmit Transaction . . . . . . . . . . . . . . 55 285 8.4.1. Initiate Transmit Transaction Commitment . . . . . . 55 286 8.4.2. Respond to Transmit Transaction Commitment . . . . . 55 287 8.4.3. Finalize Transmit Transaction Commitment . . . . . . 55 288 8.4.4. Time-out for Committing Transmit Transaction . . . . 55 289 8.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 55 290 8.5.1. Calculation of RTT . . . . . . . . . . . . . . . . . 56 291 8.5.2. Generation and transmission of SNACK . . . . . . . . 57 292 8.5.3. Negative acknowledgment of Packets Sent . . . . . . . 57 293 8.5.4. Retransmission Interval . . . . . . . . . . . . . . . 58 294 8.6. Flow Control . . . . . . . . . . . . . . . . . . . . . . 59 295 8.7. Congestion Control . . . . . . . . . . . . . . . . . . . 59 296 8.8. On-the-Wire Compression . . . . . . . . . . . . . . . . . 60 297 8.9. Milk Like Payload and Minimal Delay Service . . . . . . . 61 298 9. Graceful Shutdown . . . . . . . . . . . . . . . . . . . . . . 62 299 9.1. Initiation of Graceful Shutdown . . . . . . . . . . . . . 62 300 9.2. Acknowledgment of Graceful Shutdown . . . . . . . . . . . 62 301 9.3. Finalization of Graceful Shutdown . . . . . . . . . . . . 63 302 9.4. Retransmission of RELEASE Packet . . . . . . . . . . . . 63 303 10. Mobility and Multi-home Support . . . . . . . . . . . . . . . 63 304 10.1. Heartbeat Signals . . . . . . . . . . . . . . . . . . . 63 305 10.2. Active Address Change Signaling . . . . . . . . . . . . 64 306 10.3. Heuristic Remote Address Change Adaptation . . . . . . . 64 307 10.4. Heuristic Address Change Acknowledgement . . . . . . . . 64 308 10.5. NAT-traversal and Multihoming . . . . . . . . . . . . . 65 309 10.6. Explicit Multi-home Informing . . . . . . . . . . . . . 65 310 11. Connection Multiplication . . . . . . . . . . . . . . . . . . 65 311 11.1. Request to Multiply Connection . . . . . . . . . . . . . 66 312 11.2. Response to Connection Multiplication Request . . . . . 66 313 11.3. Duplicate Detection of Connection Multiplication Request 67 314 11.4. Retransmission . . . . . . . . . . . . . . . . . . . . . 67 315 11.5. Key Derivation for Branch Connection . . . . . . . . . . 67 316 12. Timeouts and Abrupt Close . . . . . . . . . . . . . . . . . . 68 317 12.1. Timeouts in End-to-End Negotiation . . . . . . . . . . . 68 318 12.2. Timeouts in Multiply . . . . . . . . . . . . . . . . . . 68 319 12.3. Timeout of Transmit Transaction Commitment . . . . . . . 69 320 12.4. Timeout of Graceful Shutdown . . . . . . . . . . . . . . 69 321 12.5. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 69 322 12.6. Session Key Timeout . . . . . . . . . . . . . . . . . . 69 323 12.7. Abrupt Close . . . . . . . . . . . . . . . . . . . . . . 69 324 13. Issues for Further Study . . . . . . . . . . . . . . . . . . 69 325 13.1. Resolution of ULTID in DNS . . . . . . . . . . . . . . . 69 326 13.2. Proxy Pattern for Syndicated Name Resolution . . . . . . 70 327 13.3. Asymmetric Transmission . . . . . . . . . . . . . . . . 71 328 14. Security Considerations . . . . . . . . . . . . . . . . . . . 71 329 14.1. Deny of Service Attack . . . . . . . . . . . . . . . . . 71 330 14.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . 71 331 14.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . 72 332 14.4. Masquerade Attack . . . . . . . . . . . . . . . . . . . 72 333 14.5. Active Man-In-The-Middle Attack . . . . . . . . . . . . 72 334 14.6. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 72 335 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 336 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 337 16.1. Normative References . . . . . . . . . . . . . . . . . . 72 338 16.2. Informative References . . . . . . . . . . . . . . . . . 74 339 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 77 340 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 77 342 1. Introduction 344 Flexible Session Protocol is a connection-oriented transport layer 345 provides mobility, multi-homing and multi-path support by introducing 346 the concept of 'upper layer thread ID' (ULTID), which was firstly 347 suggested in [Gao2002]. 349 An integrity check code (ICC) field associated with the ULTID is 350 designed in the FSP header to protect authenticity and optionally 351 privacy of the FSP packet. An FSP packet is assumed to originate 352 from the same source if the ICC value associated with certain 353 destination ULTID passes validation, regardless of the source or 354 destination address of the packet in the underlying layer. 356 ICC is either calculated by [CRC64] which protects FSP against 357 unintended modification, or a cryptographic hash function, or 358 cryptographically calculated with some Authenticated Encryption with 359 Additional Data ([R01]) algorithm, each of which requires a shared 360 secret key. 362 In the former case a weak key meant to obfuscate the CRC64 checksum 363 is agreed by the FSP participants. In the latter two cases, the 364 shared secret key is assumed to be installed by the upper layer 365 application (ULA). 367 The ULTID is assigned roughly the same semantics as the Security 368 Parameter Index (SPI) in MOBIKE [RFC4555]. Either the weak key or 369 the shared secret key is indexed by the source or destination ULTID 370 in the local context of the sender or the receiver, respectively. 372 FSP facilitates secret key installation by introducing the concept of 373 transmit transaction. Mechanism of transmit transaction also 374 provides the session-connection synchronization service to the upper 375 layer. 377 FSP is a transport layer protocol as specified in [RFC1122], provides 378 services alike TCP [STD5] to ULA, with session layer features as 379 suggested in [OSI/RM], most noticeably session-connection 380 synchronization. 382 1.1. Features 384 1.1.1. Transmit Transaction 386 FSP introduces the concept of transmit transaction, which makes it 387 able to mark end of message inherently at the transport layer, 388 effectively eliminate the requirement of message delimiters at the 389 application layer. Besides, it still provides byte-stream-oriented 390 transfer service to its upper layer application which is familiar and 391 friendly to application developers. 393 1.1.2. Transport Layer Mobility Support 395 FSP is meant to be transport layer protocol that keeps the IP address 396 as the routing locator but keeps it from being the key constituent of 397 the FSP identifier or any upper layer protocol built upon FSP. It is 398 a solution to avoid the routing scalability problem. 400 The dominating transport layer protocols, TCP and UDP that take use 401 of the IP address to identifying the end node, introduce the 402 controversial role of IP address both as the identifier and as the 403 routing locator. We believe such a problem should be eventually 404 solved at its root. 406 1.1.3. Ubiquitous Authenticated Encryption 408 By applying authenticated encryption with additional data on each FSP 409 packet, FSP provides both authentication of message origin and 410 privacy protection service to the upper layer application. 412 1.1.4. 0-RTT Multiplication of Connections 414 With FSP the upper layer application is able to fork branch 415 connections of an established connection in zero round-trip mode, 416 without security compromise. 418 1.1.5. On-the-wire Compression 420 FSP provides on-the-wire compression service through the on-the-wire 421 compression and fragmentation function module. 423 1.2. Requirements Language 425 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 426 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 427 document are to be interpreted as described in RFC 2119 [RFC2119]. 429 In this document, these words will appear with that interpretation 430 only when in ALL CAPS. Lower case uses of these words are not to be 431 interpreted as carrying significance described in RFC 2119. 433 1.3. Conventions 435 Conventions in describing the finite state machine (FSM) of FSP are: 437 ESTABLISHED The string of alphabetic characters designates the name 438 of the state 440 [API: Reset] Upper Layer Application Programming Interface Call 442 {Notify} Call back/notify the upper layer application 444 {new context} Additional action before or after state transition 446 [Send OPCODE_OF_FSP_PACKET] 447 Send some FSP packet 449 [Retransmit OPCODE_OF_FSP_PACKET] 450 Retransmit some FSP packet 452 {On transient state Timeout} 453 Timed-out event 455 {&& additional condition} 456 Together with some additional condition 458 --> state transition 460 |-- branch 462 2. Abbreviations and Idioms 464 o Connection An FSP connection is the binding of two network nodes 465 established through some end-to-end negotiation process. It is 466 identified by the ULTID in the local context of each network node, 467 respectively. 469 o EoT End of Transaction. A transmit transaction is said to reach 470 EoT if the EoT flag is set in a legitimate PURE_DATA, PERSIST, 471 NULCOMMIT or MULTIPLY packet. We said that the packet terminates 472 the transmit transaction if the EoT flag is set. 474 An FSP end node SHALL NOT send further data if it has initiated 475 EoT of its transmit direction unless a particular ACK_FLUSH packet 476 is received. The particular AKC_FLUSH packet MUST acknowledge not 477 only the packet with the EoT flag set but all of the packets sent 478 before the packet as well. 480 EoT, i.e. termination of transmit transaction is unilateral. 482 o FREWS 484 The Flags and advertised REceive Window Size. It is the 32-bit 485 combined word next to the ICC field in the normal FSP fixed 486 header. 488 o ICC The Identity Check Code. It is a 64-bit value that depends on 489 both the session key and all of the headers of the FSP packet to 490 include the ICC, calculated with the same algorithm in the context 491 of each FSP participant. 493 Only a packet with correct ICC can be accepted by any FSP 494 participant as soon as the connection has been established. 496 Initially CRC64 is exploited to make a checksum that weekly 497 protects the FSP packet against unintentional modification. The 498 checksum is obfuscated with the initial session key to get the 499 ICC. After the ULA installed the long-term session key either 500 some cryptographic hash function or some Authenticated Encryption 501 with Additional Data algorithm shall be applied to obtain or check 502 the ICC. 504 o Session An FSP session is the transport-layer association of two 505 network nodes. A full FSP session consists of one connection that 506 was established from scratch and all of its branches. 508 However for this version of FSP specification the idioms session 509 and connection are interchangeable if not explicitly specified. 511 o Session Key The session key is a bit string of at least 128 bits 512 that means to resist against masquerade attack. It is either 513 initiated during the end-to-end negotiation phase or installed by 514 the ULA after the FSP connection is established. 516 The session key installed by the ULA is called the long-term 517 session key. Here long-term means that the key could be used 518 until the packet sequence space is exhausted. The packet sequence 519 space is exhausted if the number of packets that use the same key 520 reaches or exceeds 2,147,483,647(2^31-1). 522 o SN The Sequence Number. It is the unsigned 32-bit integer number 523 assigned to every FSP packet except the preliminary packets. 525 Difference of two sequence number is represented by a 32-bit 526 signed integer. If the result of SN B subtracting SN A is greater 527 than zero, we say that B is greater than A and the packet of the 528 sequence number B is later than the packet of the sequence number 529 A, although the unsigned integer representation of B may be far 530 less that A. Consequently, as the result of A subtracting B is 531 less than zero, we say that A is less than B and the packet of the 532 sequence number A is earlier than the packet of the sequence 533 number A. 535 o Transmit Transaction A transmit transaction in FSP is a sequence 536 of FSP packets that were sent and marked by the ULA as one 537 continuous stream where all packets in the stream must be 538 acknowledged before any further packet is allowed to be sent. 540 A ACK_CONNECT_REQ, PERSIST or MULTIPLY packet always starts a new 541 transmit transaction. 543 ACK_START both starts and terminates a payload-less transmit 544 transaction. 546 ACK_START is alias of NULCOMMIT when it is exploited to 547 acknowledge the ACK_CONNECT_REQ or MULTIPLY packet. 549 o ULA The Upper Layer Application. 551 o ULTID The Upper Layer Thread Identifier (ULTID). It is a 32-bit 552 word that was allocated by particular network end node of an FSP 553 connection and is unique in the local context of the network end 554 node. 556 Theoretically all of the ULAs of a network end node MAY establish 557 up to 2^31-1 FSP connections totally. Each connection MUST have a 558 unique thread identifier (ULTID) assigned in the local context of 559 the network end node. 561 A session or connection in FSP does not require a global ID. 563 3. Key Mechanisms 565 3.1. Underlying Layer Services Required 567 FSP requires that the underlying layer provides packet delivery 568 service. In addition to packet delivery, FSP suppose underlying 569 layer have following features: 571 3.1.1. High Mobility 573 Here high mobility refers to scenarios such as high-speed train or 574 airplane. 576 FSP solves somewhat coarse-grain or low-speed mobility problem. 577 Fine- grain or high-speed mobility is left to the underlying physical 578 network. To make mobility support work effectively it is assumed 579 that one end-node MUST keep its lower layer address reasonably stable 580 while the other end-node SHOULD NOT change its lower layer address 581 too frequently. 583 Here the meaning of physical network conforms to what was depicted in 584 [RFC1122]. 586 3.1.2. Network Address Change Notification 588 Network address change notification is mandatory only in the IPv6 589 network. 591 We split the IPv6 address of the IPv6 packet underlying FSP into 592 three parts. The leftmost 64-bit long word is the network prefix, 593 which SHOULD be the unique IPv6 prefix assigned to the host 594 [RFC8273]. The centermost 32-bit word is called the aggregation host 595 ID, and the rightmost 32-bit word is the ULTID. While the ULTID MUST 596 be kept stable even during the life of an FSP session, the network 597 prefix part MAY change when an endpoint is roaming. The aggregation 598 host ID may change as well. The network prefix part together with 599 the aggregation host ID part act as the traditional routing locator 600 at the network layer. 602 It is supposed that the network layer immediately notifies the FSP 603 layer if the network prefix or aggregation host ID changes. 605 An participant of an FSP connection SHALL immediately notify its peer 606 whenever its underlying IPv6 address is changed with a KEEP_ALIVE 607 packet. The peer shall send packet to the participant that has 608 notified the address change with the new address. 610 It is supposed that the packet to inform the remote end to update the 611 lower layer address association could reach its destination in a 612 satisfying success rate. 614 3.1.3. Network Congestion Control 616 Network layer congestion control is mandatory only in future IPv6 617 network. 619 It is supposed that end-to-end congestion control is provided at some 620 sub-layer of the network layer. Implementation of FSP MUST include a 621 congestion manager [RFC3124] if such sub-layer service of the network 622 layer is not provided. 624 3.2. Identifying Connection by Local ULTID 626 Each FSP connection prepares a pair of ULTIDs. ULTID is assigned 627 roughly the same semantics as the Security Parameter Index (SPI) in 628 IKE [RFC4301]. An ULTID uniquely indexes a connection in the local 629 context of an FSP end node. An FSP end node relies neither source IP 630 address nor destination IP address, except the ULTID part of the near 631 end's IPv6 address to identify an FSP connection. 633 Each ULTID is allocated in the local context of the two FSP 634 participant respectively. The source ULTID and the destination ULTID 635 of an FSP packet usually differ in their values. However, the secret 636 keys indexed in the local contexts of the two end-points must have 637 the same value. 639 3.3. Defending Against Connection Hijacking with ICC 641 An integrity check code (ICC) field associated with the ULTID is 642 designed in the FSP header to protect authenticity and optionally 643 privacy of the FSP packet. An FSP packet is assumed to originate 644 from the same source if the ICC value associated with certain 645 destination ULTID passes validation, regardless of the source or 646 destination address in the underlying layer. 648 On initiating FSP takes use of [CRC64] to make checksum of the FSP 649 packet to protect it against unintentional modification. The 650 checksum is taken as the ICC. 652 After the ULA has installed a shared secret key, value of ICC is 653 calculated by firstly getting the secret key associated indexed by 654 the local ULTID, then calculating the tag value with the AES-GCM 655 [GCM] authenticated encryption with additional data algorithm [R01], 656 or calculating the message authentication code with the BLAKE2 657 algorithm [RFC7693]. 659 3.4. Synchronizing Key Installation with Transmit Transaction 661 It is proposed that it is the ULA to do key establishment and/or end- 662 point user-agent authentication while the FSP layer provides 663 authenticated, optionally encrypted data transfer service. 665 A dedicate application program interface (API) is designed for the 666 ULA to install the secret key established by the ULA participants. 668 FSP facilitates shared secret key installation by introducing the 669 concept of transmit transaction. 671 A transmit transaction of FSP is a sequence of FSP packets that were 672 sent and requested by ULA as one continuous stream where all packets 673 in the stream MUST be acknowledged before any further packet is 674 allowed to be sent. 676 A flag called 'End of Transaction' (EoT) is designed in the FSP 677 header. When it is set, it marks that the transmit transaction in 678 the direction from the source of the FSP packet towards the 679 destination of the FSP packet is 'committed'. 681 As the FSP node knows when a transmit transaction at FSP layer is 682 terminated there is no ambiguity which packet is to be applied with 683 the new session key when the key is installed by ULA through the 684 dedicated API. 686 3.5. 0-RTT Connection Multiplication with OOB Packet 688 An FSP connection MAY be multiplied to get a branch or branches of 689 the connection. Multiplication of a connection is protected by 690 deriving new session key from the original security context of the 691 connection. 693 The packet that carries the command to multiply an established FSP 694 connection MUST be sent from a new allocated local ULTID towards the 695 destination ULTID of the original connection. It is an out-of-band 696 (OOB) packet in the context of the original connection and it MUST be 697 cryptographically protected by the secret key of the original 698 connection. The packet MAY carry payload. 700 The receiver of the packet MUST allocate a new local ULTID, accept 701 the optional payload in the new context associated with the new 702 ULTID, derive a new secret key from the secret key of the original 703 connection, and responds from the new context. The response MAY 704 carry payload. 706 The very first response packet MUST be protected by the new secret 707 key. The sender of the multiply command packet MUST automatically 708 inaugurate the same secret key, derived from the secret key of the 709 same original connection. And it MUST treat the response packet as 710 though a transmit transaction had been committed by the responder, 711 i.e. authenticity of the response packet is verified with the new 712 secret key. 714 Thus the branch connection of a new pair of ULTIDs is established 715 with zero round-trip overhead. This mechanism may be exploited to 716 provide expedited data transfer or parallel data transfer service. 718 4. Packet Structure 720 4.1. FSP over UDP/IPv4 722 In this version of FSP, when FSP is implemented in the IPv4 network, 723 every FSP packet MUST be encapsulated in a UDP [STD6] datagram. The 724 UDP datagram encapsulated the FSP packet SHALL have the checksum 725 disabled (i.e. set its value to 0) [RFC8085]. The Source and the 726 destination ULTIDs are put at the leading position of the UDP 727 payload. FSP fixed header, optional extension headers and FSP 728 payload follow the ULTIDs: 730 0 15 16 31 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Source Port | Destination Port | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Length | 0 | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Source Upper Layer Thread ID | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Destination Upper Layer Thread ID | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | | 741 ~ FSP Fix Header ~ 742 | | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 ~ Optional FSP Extension Headers ~ 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 ~ ~ 747 ~ Optional FSP payload ~ 748 ~ ~ 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 4.2. FSP over IPv6 753 When FSP is implemented over IPv6 [RFC8200], the ULTID part is 754 embedded in the IPv6 address. FSP fixed header follows the IPv6 755 headers: 757 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 758 ~ IPv6 Header: ~ 759 0 15 16 31 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 |Version| Traffic Class | Flow Label | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Payload Length | Next Header | Hop Limit | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 + Source Network Prefix + 767 | | 768 + Source Address ----------------------------+ 769 | Source Aggregation Host ID | 770 + ----------------------------+ 771 | Source Upper Layer Thread ID | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 + Destination Network Prefix + 775 | | 776 + Destination Address ---------------------------------+ 777 | Destination Aggregation Host ID | 778 + ---------------------------------+ 779 | Destination Upper Layer Thread ID | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 ~ ~ 782 ~ Optional IPv6 Headers ~ 783 ~ ~ 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | | 786 ~ FSP Fix Header ~ 787 | | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 ~ Optional FSP Extension Headers ~ 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 ~ ~ 792 ~ Optional FSP payload ~ 793 ~ ~ 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 o Network Prefix The leftmost 64-bit of the IPv6 address which MAY 797 and usually do have different value at the difference interface of 798 an IPv6 end- node. 800 o Aggregation Host ID 802 The left 32-bit part of the rightmost 64-bit long word of the IPv6 803 address. All of the aggregation host ID parts of an IPv6 end- 804 node's IPv6 addresses MUST have the same value for this version of 805 FSP. 807 Network prefix and aggregation host ID make the IPv6 prefix part of 808 the IPv6 address under the context of FSP. It is assumed that there 809 is a unique IPv6 prefix per host [RFC8273]. 811 RFCs related to IPv6 address configuration such as ND for IPv6 812 [RFC4801], SLAAC [RFC4862], 'IPv6 Subnet Model' [RFC5942], 'IPv6 813 Address Assignment to End Sites' [RFC6177], 'Discovery of the IPv6 814 Prefix Used for IPv6 Address Synthesis' [RFC7050], DHCP [RFC8415] and 815 'IPv6 Node Requirements' [RFC8504] would be reviewed in separate 816 document. 818 4.3. Generic FSP Header 820 FSP headers include the fixed header and the extension headers. A 821 general fixed header consists of a 32-bit FSP Header Signature and 822 20-byte operation-code specific fields. An extension header consists 823 of a 32-bit Code-Mark-Length Prefix and the operation-code specific 824 content. The length of the extension header content may be variable, 825 provided that the tail of the full extension header align on 64-bit 826 boundary. 828 Integers in the FSP fix header are transmitted in network byte order. 829 Otherwise, integers in the FSP headers are of little-endian. 831 0 31 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Header Signature | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 ~ ~ 836 ~ Operation Code Specific Fields ~ 837 ~ ~ 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 4.4. FSP Header Signature and Code-Mark-Length Prefix 842 0 7 8 15 16 31 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Operation Code| Major | Offset | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 0 7 8 15 16 31 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Operation Code| Mark | Length | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 4.4.1. Operation Code 854 The operation code is an octet that stores the code of the command 855 which indicates the function of the FSP packet, or specifies the type 856 of some extension header. 858 Synonym Code Meaning 860 INIT_CONNECT 1 Initialize Connection 862 ACK_INIT_CONNECT 2 Acknowledge Initialization of Connection 864 CONNECT_REQUEST 3 Formally Request to Connect 866 ACK_CONNECT_REQ 4 Acknowledge the Connection Request 868 RESET 5 Reset a connection 869 Refuse to establish the connection, or abort connection. NULCOMMIT 6 870 Commit without payload The NULCOMMIT packet MUST be payload- less, and 871 its EoT flag MUST be set. It MAY carry optional extension headers. 872 It always consumes a slot of the send sequence space. It is to commit 873 current transmit transaction, otherwise the NULCOMMIT packet itself 874 SHALL just be skipped when delivering data to ULA. 876 ACK_START 6 Alias of NULCOMMIT, ACKnowledgement to 877 start a connection It is the acknowledgement to ACK_CONNECT_REQ or 878 MULTIPLY, to confirm that the connection has been established or 879 multiplied. ACK_START, or NULCOMMIT, MAY both start a payload-less 880 transmit transaction and terminate the transmit transaction. 882 KEEP_ALIVE 7 Keep the peer alive 883 It is an out-of-band control packet acting as the heart-beating 884 signal. An out-of-band control packet does not consume send sequence 885 space itself. FSP takes use of the KEEP_ALIVE packet to inform the 886 peer about the change of the source IP addresses. Besides, when the 887 MIND flag is set, the KEEP_ALIVE packet is meant to tell the peer 888 which packets should be retransmitted. If the End of Transaction flag 889 of the KEEP_ ALIVE packet is set it is meant to forcefully commit 890 current transmit transaction of the sender of the KEEP_ALIVE packet. 892 PERSIST 8 Make a connection persistent 893 It is meant to start a new transmit transaction after a connection 894 migrated to CLOSABLE state. It can also acknowledge ACK_CONNECT_REQ 895 or MULTIPLY. It MUST carry payload. It always consumes a slot of the 896 send sequence space. 898 PURE_DATA 9 Pure Data 899 It does not carry any optional header. 901 ACK_FLUSH 10 ACKnowledge to remote end's commitment 902 (FLUSHing) of transmit transaction. It is an out-of-band control 903 packet like KEEP_ALIVE. It is sent instantly on having every packet 904 of the last transmit transaction received, meant to make 905 acknowledgment to the remote end and let the remote end stop sending 906 heart-beat signals. 908 RELEASE 11 Release the connection 909 RELEASE packet does not carry payload but it always consumes a slot of 910 the send sequence space. Only when each peer has committed current 911 transmit transaction may a RELEASE packet sent under the request of 912 the ULA. 914 MULTIPLY 12 Multiply the connection 915 It is sent in the context of the original connection and may carry 916 payload and/or optional headers as an out-of-band packet. 918 PEER_SUBNETS 17 Tell the remote end how to address 919 the sender of the packet in the reverse direction. It is the code of 920 the Sink Parameter extension header. 922 SELECTIVE_NACK 18 Tell the remote end to retransmit 923 the packets that were negatively acknowledged. It is the code of the 924 Selective Negative Acknowledgment extension header. 926 4.4.2. Major 928 It is an octet that states current FSP 929 major version. For this FSP version it 930 MUST be 0. 932 It is not mandatory for different major 933 versions of FSP to be compatible. 935 4.4.3. Mark 937 It is an octet that marks current minor 938 version of the extension header, under 939 the major FSP version specified in the 940 fixed header, and/or serves as the flag, 941 depending on the type of the extension 942 header. 944 It is mandatory for implementations to 945 be compatible with different minor 946 versions of FSP extension header under 947 the same major FSP version. 949 It is not mandatory for minor versions 950 of FSP extension header under the 951 different major FSP version to be 952 compatible, even if the minor versions 953 happen to be the same. 955 4.4.4. Offset 957 For the fixed header the offset field is 958 a 16-bit unsigned integer that specifies 959 the offset of the first octet of the 960 payload. It starts from the begin of 961 the FSP fixed header. If its value 962 equals the size of the fixed header the 963 packet has no any extension. 965 4.4.5. Length 967 For an extension header the length field 968 is a 16-bit unsigned integer that 969 specifies the length, including the 970 Type-Version-Length Header and the size 971 of the the operation code specific 972 content of the extension header. 974 4.5. Preliminary FSP Packets 976 Preliminary FSP packets are the packets exchanged during the end-to- 977 end negotiation phase of FSP connection establishment when it is 978 impossible to calculate ICC normally. 980 4.5.1. Connect Initialization 981 0 31 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Header Signature | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Salt | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | | 988 + Timestamp + 989 | | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | | 992 + Init-Check-Code + 993 | | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 ~ ~ 996 ~ Host Name of the Responder (optional) ~ 997 ~ ~ 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Operation Code of this type of packet is INIT_CONNECT. 1002 o Salt 1003 It a 32-bit random bit string that may be exploited to make secret 1004 key agreement. 1006 o Timestamp It is a 64-bit unsigned integer that represents number 1007 of microseconds elapsed since 00:00, Jan.1, 1970, Coordinated 1008 Universal Time. It may be exploited to synchronize the clocks of 1009 the participants and/or estimate delay during data transmission in 1010 the network. 1012 o Init-Check-Code It is a 64-bit random [RFC4086] bit string that 1013 means to uniquely associated with the connection initiated. 1015 o Host Name of the Responder The optional payload of the Connect 1016 Initialization packet is the host name, which is encoded in UTF-8 1017 [RFC3629] and SHOULD be resolvable in DNS, of the responder. 1019 4.5.2. Acknowledgment to Connect Initialization 1020 0 31 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Header Signature | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Time Delta | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | | 1027 + Cookie + 1028 | | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | | 1031 + Init-Check-Code + 1032 | | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 ~ ~ 1035 ~ Sink Parameter ~ 1036 ~ ~ 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Operation Code of this type of packet is ACK_INIT_CONNECT. 1041 o Time Delta 1043 It is a 32-bit signed integer which is the difference between the 1044 near-end's time and the timestamp value sent in the Connection 1045 Initialization packet. The units and the epoch of the near-end's 1046 time value and the timestamp value MUST be the same. However, the 1047 precision or resolution of the time delta value is chosen 1048 arbitrarily by the responder. 1050 o Cookie It is a 64-bit bit string cryptographically generated by 1051 the responder in a represent-transfer state manner. More 1052 specifically when the same timestamp, time delta, Init-Check-Code, 1053 salt, source and destination ULTIDs are sent to the responder, the 1054 responder MUST be able to generate the identical cookie value. 1056 o Init-Check-Code It MUST be identical to the corresponding field in 1057 the Connect Initialization packet acknowledged. 1059 o Sink Parameter 1060 It is an extension header specified in 4.7. 1062 4.5.3. Connect Request 1063 0 31 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Header Signature | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Salt | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | | 1070 + Time Stamp + 1071 | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | | 1074 + Init-Check-Code + 1075 | | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Initial Sequence Number | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Time Delta | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | | 1082 + Cookie + 1083 | | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 ~ ~ 1086 ~ Sink Parameter ~ 1087 ~ ~ 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 ~ ~ 1090 ~ Host Name of the Initiator (optional) ~ 1091 ~ ~ 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 Operation Code of this type of packet is CONNECT_REQUEST. 1096 The value of each field that has the identical name with the one in 1097 the associated Connect Initialization and Acknowledgment to Connect 1098 Initialization packet MUST be assigned the same value as in these two 1099 packets, except header signature in the packet. 1101 Note that the initiator SHALL fill in the time delta field as it is 1102 and SHALL NOT assume endian-ness of the time delta field. 1104 o Sink Parameter It is an extension header specified in 4.7. 1106 o Host Name of the Initiator The optional payload of the Connect 1107 Request packet is the host name, which is encoded in UTF-8 and 1108 SHOULD be resolvable in DNS, of the initiator. 1110 It could be exploited by the responder to look up the address of 1111 the initiator that may receive packets in the reverse direction. 1113 4.6. Normal Fixed Header 1115 0 15 16 31 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Header Signature | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Flags | Advertised Receive Window Size | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Sequence Number | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Expected Sequence Number/Out-of-Band Serial Number | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | | 1126 + Integrity Check Code + 1127 | | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 Operation Code of a normal fixed header may be ACK_CONNECT_REQ, 1131 PURE_DATA, PERSIST, KEEP_ALIVE, ACK_FLUSH, RELEASE or MULTIPLY. 1133 o Flags It is bit-field of width 8. From left to right: 1135 - End of Transaction (EoT): If the EoT flag of a packet is set, 1136 it is the last packet of a transmit transaction. A packet with 1137 the EoT flag set MAY be the start and the single packet of the 1138 transmit transaction as well. 1140 - Minimal-Delay (MIND): If the MIND flag of the Connect Request 1141 or Acknowledgment to Connect Request packet is set, the ULA 1142 prefers minimal delay and is willing to tolerate packet loss. 1143 FSP SHALL drop the packet received earliest when there is no 1144 enough receive buffer so that the latest packet received can be 1145 saved and the delay to deliver data to ULA is minimized. 1147 If the MIND flag has been set the EoT flag of any following 1148 packet is simply ignored. 1150 The MIND flag of an FSP packet may be set only if the packet 1151 does not belong to a compressed transmit transaction. 1153 Payload of each FSP packet is delivered to the ULA as an 1154 independent message if the MIND flag has been set. 1156 - Compressed (CPR) If the CPR flag of the first packet of a 1157 transmit transaction is set, compression is applied on the 1158 octet stream of the payloads of the continuous packets that 1159 constitute the transmit transaction, or to put it simply, the 1160 payload octet stream of the transaction transaction. Such 1161 transmit transaction is called a compressed transmit 1162 transaction. 1164 When the CPR flag of a packet is set, CPR flag of each 1165 following packet is ignored until reaching termination of the 1166 transmit transaction. 1168 If the payload octet stream of the transmit transaction is 1169 compressed the Minimal-Delay flag of any packet in the transmit 1170 transaction MUST be cleared. 1172 - ECN-Echo (ECE): The Explicit Congestion Notification Echo flag 1173 of a packet is set if the sender of the packet has received an 1174 underlying IPv6 packet with Congestion Experienced code point 1175 set for its peer as stated in "The Addition of Explicit 1176 Congestion Notification (ECN) to IP" [RFC3168]. 1178 - Send Rate Reduced (SRR): The SRR flag of each packet SHALL be 1179 set as soon as the sender has received a legitimate packet with 1180 ECE flag set and has informed the congestion manager to reduce 1181 the send rate, until a sent packet with SRR flag set is 1182 acknowledged. 1184 The remaining 3 bits are reserved. 1186 o Advertised Receive Window Size It is a 20-bit unsigned integer 1187 that stores number of the free blocks in the receive buffer of the 1188 sender of the packet that contains the receive window size field. 1189 It is count from the slot meant to accept the packet with the 1190 expected sequence number. 1192 The sender must ensure that the difference between the latest 1193 sequence number sent out and the largest expected sequence number 1194 received does not exceed the value of the latest advertised 1195 receive window size received. 1197 o Sequence Number Each in-band FSP packet is assigned a 32-bit 1198 unsigned integer as the sequence number. The sequence number 1199 assigned for in-band FSP packets MUST be in strict order. 1201 An out-of-band packet that has the operation code of KEEP_ALIVE, 1202 ACK_FLUSH or MULTIPLY MUST be assigned a sequence number that 1203 falls in the receive window. 1205 o Expected Sequence Number For in-band packet, the 'expected 1206 sequence number/out-of-band serial number' field stores the 1207 earliest sequence number of the packets that were not yet received 1208 in the receive window of the sender. It is an accumulative 1209 acknowledgment. Any packet with the sequence number before the 1210 received Expected Sequence Number is supposed to have been 1211 received by the remote end. 1213 o Out-of-band Serial Number For out-of-band packet, the 'expected 1214 sequence number/out-of-band serial number' field stores a 2-bit 1215 unsigned integer that numbers the out-of-band FSP packet 1216 separately from the sequence space of the in-band packets. 1218 Each time an out-of-band packet is sent the out-of-band serial 1219 number SHALL increase by one. 1221 It is assumed that in the life of the session no two packets have 1222 the same sequence number and the same out-of-band serial number 1223 simultaneously. 1225 o Integrity Check Code The ICC. 1227 4.7. Sink Parameter 1229 0 31 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Code-Mark-Length Prefix | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Listener ID/Host ID | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 ~ ~ 1236 ~ Addressable Network Prefixes ~ 1237 ~ ~ 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 Operation Code in the Header Signature of this extension header is 1241 PEER_SUBNETS. 1243 o Listener ID It is the ULTID of the responder that is in LISTENING 1244 state. 1246 o Host ID It is the aggregation host id of the sender. It SHALL be 1247 0 if it is in the IPv4 network. 1249 o Addressable Network Prefixes These are up to 4 64-bit words that 1250 specify the network prefixes of the lower layer interfaces that 1251 are addressable by the receiver in the reverse direction. 1253 In this version of the FSP 'Addressable Network Prefixes' field is 1254 of fixed length. The last network prefix which is non-zero is the 1255 last resort one. There MUST be at least one non-zero network 1256 prefix. If there are more than one non-zero network prefixes 1257 those other than the last resort are load-balanced preferred. 1259 In an IPv6 network, the addressable network prefix is the leftmost 1260 64 bits of the IPv6 address. The receiver of the Addressable 1261 Network Prefixes SHALL send packet in the reverse direction, i.e. 1262 to the sender of the field with the destination IPv6 address 1263 generated by combining a preferred network prefix with the 1264 aggregation host id and the ULTID part of the source address in 1265 the IPv6 header of the received packet that eventually carries the 1266 Addressable Network Prefixes. 1268 Such feature MAY be exploited to handle links with unidirectional 1269 connectivity, but it is NOT RECOMMENTED. 1271 In an IPv4 network for compatibility with the IPv6 addressed ULA 1272 the 64-bit word of the addressable network prefix specified is 1273 composed as following Figure: 1275 0 15 16 31 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | 0x2002 (IPv6 6to4 prefix) |IPv4 address (leftmost 16 bits)| 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 |IPv4 address(rightmost 16 bits)| UDP port number (16 bits) | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Sender of the Sink Parameter packet SHOULD be NAT-aware in the IPv4 1283 network. If it is able to obtain the from the NAT box (as defined 1284 in "Traditional IP Network Address Translator (Traditional NAT)" 1285 [RFC3022]) through Port Control Protocol (PCP) [RFC6887] SHOULD 1286 fill in the IPv4 address and UDP port number fields with the public 1287 IP value that were obtained. If it does not have such capability, 1288 it SHALL fill in the addressable network prefix with all binary 1289 zeroes. 1291 4.8. Selective Negative Acknowledgment 1292 0 31 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Code-Mark-Length Prefix | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | Expected Sequence Number | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Delay Sample Sequence Number | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Acknowledgement Delay | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Gap Width | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Data Length | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 ~ ~ 1307 ~ Further pairs of (Gap Width, Data Length) ~ 1308 ~ ~ 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 The operation code of this type of extension header is SNACK.block. 1313 o Expected Sequence Number It stores the earliest sequence number of 1314 the packets that were not yet received in the receive window of 1315 the sender. It is an accumulative acknowledgment. Any packet 1316 with the sequence number before the received Expected Sequence 1317 Number is supposed to have been received by the remote end. 1319 The expected sequence number is represented in little endian. 1321 o Delay Sample Sequence Number It stores the sequence number of the 1322 packet that the acknowledgement delay was calculated on. 1324 The delay sample sequence number is represented in little endian. 1326 o Acknowledgement Delay A 32-bit unsigned integer specifies the 1327 delay in microseconds between sending the packet containing the 1328 SNACK extension header and accepting the last packet that is 1329 accumulatively acknowledged by the SNACK extension header. 1331 The acknowledgement delay is represented in little endian. 1333 o Gap Width and Data Length The SNACK header contains the descriptor 1334 of the receive window gaps. The descriptor itself is a list of 1335 entries. The length of the list can be zero which means that 1336 there is no gap in the receive window. If the list is not empty, 1337 each entry contains the width of one gap (Gap Width) in the 1338 receive window and the length of the continuously received data 1339 following the gap (Data Length), respectively. 1341 The unit of aforementioned length of gaps or number of packets is 1342 buffer block which size is agreed upon connection establishment. 1344 Gap width and data length MUST be transmitted in little endian. 1346 4.9. RESET 1348 The 'RESET' packet is a special command packet meant to interrupt 1349 connection setup process or disconnect abruptly. Operation Code of 1350 the packet is RESET. 1352 Structure of a RESET packet in C code snippet with unnamed union 1353 applied: 1355 struct FSP_RejectConnect 1356 { 1357 FSP$HeaderSignature hs; 1358 /* bit field to describe reasons for reset */ 1359 uint32_t reasons; 1360 /* sequence numbers */ 1361 union 1362 { 1363 timestamp_t timeStamp; 1364 struct 1365 { 1366 uint32_t initial; 1367 uint32_t expected; 1368 } sn; 1369 }; 1370 /* uniqueness proof */ 1371 union 1372 { 1373 uint64_t integrityCode; 1374 uint64_t cookie; 1375 uint64_t initCheckCode; 1376 }; 1377 }; 1379 When the RESET packet is the response to a Connect Initialization 1380 packet both the timeStamp and the initCheckCode fields of the RESET 1381 packet MUST be set to the same values of Time Stamp and Init-Check- 1382 Code in the Connect Initialization packet, respectively. 1384 When the RESET packet is the response to a Connect Request packet 1385 both the timeStamp and the cookie fields of the RESET packet MUST be 1386 set to the same value of Time Stamp and Cookie in the Connect Request 1387 packet, respectively. 1389 When the RESET packet is the response to a packet with a normal fixed 1390 header, the sn.initial, the sn.expected and the integrityCode of the 1391 RESET packet MUST be set as to specification of normal fixed header 1392 field Sequence Number, Expected Sequence Number and Integrity Check 1393 Code, respectively. 1395 5. The Finite State Machine 1397 5.1. NON_EXISTENT ---:API: Listen:-->LISTENING |--:API: 1398 Connect:-->CONNECT_BOOTSTRAP-->:Send INIT_CONNECT: |--:API: 1399 Multiply:-->CLONING-->:Send MULTIPLY: 1401 NON_EXISTENT is a pseudo-state before a connection is created by the 1402 ULA calling API Listen, Connect or Multiply (or after a connection is 1403 reset). 1405 5.2. LISTENING ---:API: 1406 Reset:-->NON_EXISTENT |<-->:Rcv.INIT_CONNECT:{&& accepted}:Send 1407 ACK_INIT_CONNECT: |<-->:Rcv.INIT_CONNECT:{&& rejected}:Send 1408 RESET: |<-->:Rcv.CONNECT_REQUEST:{&& duplication detected} _ 1409 _:Retransmit ACK_CONNECT_REQ: |--:Rcv.CONNECT_REQUEST:-->{Notify} 1410 _ |-->:API: Accept: _ -->{new context}CHALLENGING-->:Send 1411 ACK_CONNECT_REQ: _ |-->:API: Reject:-->:Send RESET: {abort new 1412 context, if any} 1414 LISTENING is a state entered by the ULA calling API Listen. 1416 5.3. CONNECT_BOOTSTRAP ---:API: Reset:-->NON_EXISTENT-->:Send 1417 RESET: |--:Rcv.ACK_INIT_CONNECT:-->CONNECT_AFFIRMING _ -->:Send 1418 CONNECT_REQUEST: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On 1419 transient state Timeout}-->NON_EXISTENT-->:Notify: 1421 CONNECT_BOOTSTRAP is a state entered by the ULA calling API Connect, 1422 before receiving the acknowledgement of the remote end to the 1423 connection initialization packet. 1425 5.4. CONNECT_AFFIRMING ---:API: Reset:-->NON_EXISTENT-->:Send 1426 RESET: |--:Rcv.ACK_CONNECT_REQ:-->:Notify: _ |-->{Callback return 1427 to accept} _ -->{EOT} _ |-->{No Payload to 1428 Send}-->COMMITTING2-->:Send ACK_START: _ |-->{Has Payload to Send} 1429 _ |-->{ULA-flushing}-->COMMITTING2 _ -->:Send PERSIST with EoT: 1430 _ |-->{Not ULA-flushing}-->PEER_COMMIT-->:Send PERSIST: _ |-->{Not 1431 EOT} _ |-->{No Payload to Send}-->COMMITTING-->:Send ACK_START: 1432 _ |-->{Has Payload to Send} _ |-->{ULA-flushing}-->COMMITTING _ 1433 -->:Send PERSIST with EoT: _ |-->{Not ULA- 1434 flushing}-->ESTABLISHED-->:Send PERSIST: _ |-->{Callback return to 1435 reject:-->NON_EXISTENT-->:Send 1436 RESET: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On transient 1437 state Timeout}-->NON_EXISTENT-->:Notify: 1439 CONNECT_AFFIRMING is a state entered by the ULA affirming to send 1440 connect request after receiving the acknowledgement to the connection 1441 initialization packet. 1443 5.5. CHALLENGING ---:API: Reset:-->NON_EXISTENT-->:Send 1444 RESET: |<-->:API: Send{new data}:{just pre- 1445 buffer} |--:Rcv.ACK_START: _ |-->{ULA- 1446 flushing}-->CLOSABLE-->:Notify: _ -->:Send ACK_FLUSH: _ |-->{Not 1447 ULA-flushing}-->PEER_COMMIT-->:Notify: _ -->:Send 1448 ACK_FLUSH: |--:Rcv.PERSIST: _ |-->{EOT} _ |-->{ULA- 1449 flushing}-->CLOSABLE-->:Notify: _ -->:Send ACK_FLUSH: _ |-->{Not 1450 ULA-flushing}-->PEER_COMMIT-->:Notify: _ -->:Send ACK_FLUSH: 1451 _ |-->{Not EoT} _ |-->{ULA-flushing}-->COMMITTED-->:Notify: _ 1452 -->:Send delay SNACK: _ |-->{Not ULA- 1453 flushing}-->ESTABLISHED-->:Notify: _ -->:Send delay 1454 SNACK: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On transient 1455 state Timeout}-->NON_EXISTENT-->:Notify: 1457 CHALLENGING is a state entered by the ULA accepting the connection 1458 request after a new connection context has been incarnated. The new 1459 connection is incarnated by the FSP context of the near end in the 1460 LISTENING state as a legitimate CONNECT_REQUEST packet is received. 1462 5.6. ACTIVE{A.K.A. ESTABLISHED} ---:API: Reset:-->NON_EXISTENT-->:Send 1463 RESET: |--:API: Send{flush}:-->COMMITTING{Urge to 1464 commit} |<-->:API: Send{more data}::Send 1465 PURE_DATA: |--:Rcv.NULCOMMIT: _ -->PEER_COMMIT-->:Send 1466 ACK_FLUSH:-->:Notify: |--:Rcv.PURE_DATA: _ |--{Not EOT}-->:Send 1467 SNACK:-->:Notify: _ |--{EOT} _ -->PEER_COMMIT-->:Send 1468 ACK_FLUSH:-->:Notify: |--:Rcv.PERSIST: _ |--{Not EOT}-->:Send 1469 SNACK early: _ |--:EOT: _ -->PEER_COMMIT-->:Send 1470 ACK_FLUSH:-->:Notify: |--:Rcv.MULTIPLY:{passive 1471 multiplication} |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On 1472 Idle Timeout}-->NON_EXISTENT-->:Notify: 1474 ACTIVE or ESTABLISHED is a state that the FSP participant has 1475 finished end-to-end negotiation but has not committed current 1476 transmit transaction nor fully received the latest transmit 1477 transaction of the remote end. 1479 5.7. COMMITTING ---:API: Reset:-->NON_EXISTENT-->:Send RESET: |--:Rcv.A 1480 CK_FLUSH:-->COMMITTED-->:Notify: |--:Rcv.NULCOMMIT: _ 1481 -->COMMITTING2-->:Send ACK_FLUSH:-->:Notify: |--:Rcv.PURE_DATA: 1482 _ |--{Not EOT}-->:Send SNACK:-->:Notify: 1483 _ |--{EOT}-->COMMITTING2-->:Send 1484 ACK_FLUSH:-->:Notify: |--:Rcv.MULTIPLY:{passive 1485 multiplication} |--:Rcv.RELEASE: _ |--{Not EOT}{ignore} 1486 _ |--:EOT:-->SHUT_REQUESTED-->:Send ACK_FLUSH:-->:Notify: |--:Rcv. 1487 RESET:-->NON_EXISTENT-->:Notify: |--{On Idle 1488 Timeout}-->NON_EXISTENT-->:Notify: 1490 COMMITTING is a state that the FSP participant has committed the 1491 transmit transaction but has not fully received the latest transmit 1492 transaction of the remote end, nor the acknowledgement to the 1493 transmit transaction commitment has been received. 1495 The participant in COMMITTING state SHALL NOT transmit further data 1496 until current transmit transaction commitment is acknowledged. 1498 5.8. COMMITTED ---:API: Reset:-->NON_EXISTENT-->:Send RESET: |--:API: 1499 Send{more data}:-->ACTIVE-->:Send PERSIST: |--:API: 1500 Send{flush}:-->COMMITTING-->{Flush the send 1501 queue} |--:Rcv.NULCOMMIT: _ -->CLOSABLE-->:Send 1502 ACK_FLUSH:-->:Notify: |--:Rcv.PURE_DATA: _ |-->{Not EOT}-->:Send 1503 SNACK:-->:Notify: _ |-->{EOT}-->CLOSABLE-->:Send 1504 ACK_FLUSH:-->:Notify: |--:Rcv.PERSIST: _ |-->{Not EOT}-->:Send 1505 SNACK: _ |-->{EOT}-->CLOSABLE-->:Send 1506 ACK_FLUSH:-->:Notify: |--:Rcv.MULTIPLY:{passive 1507 multiplication} |--:Rcv.RELEASE: _ |--{Not EOT}{ignore} 1508 _ |--:EOT:-->SHUT_REQUESTED-->:Send ACK_FLUSH:-->:Notify: |--:Rcv. 1509 RESET:-->NON_EXISTENT-->:Notify: |--{On Idle 1510 Timeout}-->NON_EXISTENT-->:Notify: 1512 COMMITTED is a state that the FSP participant has committed current 1513 transmit transaction and has received the acknowledgement to the 1514 transmit transaction commitment, but has not fully received the 1515 latest transmit transaction of the remote end. 1517 5.9. PEER_COMMIT ---:API: Reset:-->NON_EXISTENT-->:Send RESET: |--:API: 1518 Send{flush}:-->{Mark EoT or append NULCOMMIT} _ 1519 -->COMMITTING2-->{Do Send} |--:API: Shutdown:-->{Append RELEASE} _ 1520 -->COMMITTING2-->{Do Send} |<-->:API: Send{more data}::Send 1521 PURE_DATA: |<-->:Rcv.PURE_DATA:{just 1522 prebuffer} |<-->:Rcv.NULCOMMIT:-->:Send 1523 ACK_FLUSH: |--:Rcv.PERSIST: _ |-->{Not EOT}-->ACTIVE-->:Send 1524 SNACK: _ |<-->{EOT}-->:Send ACK_FLUSH: _ --{&& is new 1525 transaction}-->:Notify: |--:Rcv.MULTIPLY:{passive 1526 multiplication} |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On 1527 Idle Timeout}-->NON_EXISTENT-->:Notify: 1529 PEER_COMMIT is a state that the FSP participant has not committed 1530 current transmit transaction but has fully received the latest 1531 transmit transaction of the remote end, and the acknowledgement to 1532 the transmit transaction commitment has not been received yet. 1534 5.10. COMMITTING2 ---:API: Reset:-->NON_EXISTENT-->:Send 1535 RESET: |--:API: Shutdown:-->{Append RELEASE}-->PRE_CLOSED-->{Do 1536 Send} |<-->:Rcv.PURE_DATA:{just 1537 prebuffer} |<-->:Rcv.NULCOMMIT:-->:Send ACK_FLUSH: |--:Rcv.ACK_FL 1538 USH:-->CLOSABLE-->:Notify: |--:Rcv.PERSIST: _ |-->{Not 1539 EOT}-->COMMITTING-->:Send SNACK: _ |-->{EOT}-->:Send ACK_FLUSH: _ 1540 --{&& is a new transaction}-->:Notify: |--:Rcv.MULTIPLY:{passive 1541 multiplication} |--:Rcv.RELEASE:-->SHUT_REQUESTED _ -->:Send ACK_ 1542 FLUSH:-->:Notify: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On 1543 Idle Timeout}-->NON_EXISTENT-->:Notify: 1545 COMMITTING2 is a state that the FSP participant has committed current 1546 transmit transaction and has fully received the latest transmit 1547 transaction of the remote end, but the acknowledgement to the 1548 transmit transaction commitment has not been received yet. 1550 The participant in COMMITTING2 state SHALL NOT transmit further data 1551 until current transmit transaction commitment is acknowledged. 1553 5.11. CLOSABLE ---:API: Reset:-->NON_EXISTENT-->:Send RESET: |--:API: 1554 Send{more data}:-->PEER_COMMIT-->:Send PERSIST: |--:API: 1555 Send{flush}:-->COMMITTING2-->{Flush the send queue} |--:API: 1556 Shutdown:-->{Append RELEASE}-->PRE_CLOSED-->{Do 1557 Send} |<-->:Rcv.PURE_DATA:{just 1558 prebuffer} |<-->:Rcv.NULCOMMIT:-->:Send 1559 ACK_FLUSH: |--:Rcv.PERSIST: _ |-->{Not EOT}-->COMMITTED-->:Send 1560 SNACK: _ |-->{EOT}-->:Send ACK_FLUSH: _ --{&& is a new 1561 transaction}-->:Notify: |--:Rcv.MULTIPLY:{passive 1562 multiplication} |--:Rcv.RELEASE:-->SHUT_REQUESTED _ -->:Send 1563 ACK_FLUSH:-->:Notify: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: 1565 CLOSABLE is a state that the FSP participant has committed current 1566 transmit transaction and has received the acknowledgement to the 1567 transmit transaction commitment, and has fully received the latest 1568 transmit transaction of the remote end. 1570 5.12. SHUT_REQUESTED ---:API: Reset:-->NON_EXISTENT-->:Send 1571 RESET: |--:API: 1572 Shutdown:-->CLOSED-->:Notify: |<-->:Rcv.RELEASE:-->:Send 1573 ACK_FLUSH: |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: 1575 SHUT_REQUESTED is a state entered when a legitimate RELEASE packet 1576 was received. 1578 A connection context MAY persist in SHUT_REQUESTED state until the 1579 session key runs out of life, or the host system needs to recycle the 1580 resource allocated. A connection in SHUT_REQUESTED state MAY be 1581 resurrected. 1583 5.13. PRE_CLOSED ---:API: Reset:-->NON_EXISTENT-->:Send RESET: |--:Rcv. 1584 ACK_FLUSH:-->CLOSED-->:Notify: |--:Rcv.RELEASE:-->:Notify:-->CLOS 1585 ED |--:Rcv.RESET:-->NON_EXISTENT-->:Notify: |--{On transient 1586 state Timeout}-->CLOSED-->:Notify: 1588 PRE_CLOSED is a state entered on the ULA calling the API Shutdown in 1589 COMMITTING2 or CLOSABLE state. 1591 5.14. CLOSED |--{On Recycling Needed}-->NON_EXISTENT 1593 CLOSED is a state migrated from PRE_CLOSED state on receiving a 1594 legitimate ACK_FLUSH packet from the remote end, or from 1595 SHUT_REQUESTED state on the ULA calling the API Shutdown. 1597 Unlike TCP [STD7], CLOSED state in FSP is not fictional. Instead a 1598 connection context MAY persist in CLOSED state until the session key 1599 runs out of life, or the host system needs to recycle the resource 1600 allocated to the CLOSED session. A connection in CLOSED state MAY be 1601 resurrected. 1603 5.15. CLONING ---:API: Reset:-->NON_EXISTENT |<-->:API: Send{new 1604 data}:{just prebuffer} |<-->:Rcv.PURE_DATA:{just 1605 prebuffer} |--:Rcv.ACK_START: _ |--{&& Not ULA- 1606 flushing}-->PEER_COMMIT _ -->:Send ACK_FLUSH:-->:Notify: _ |--{&& 1607 ULA-flushing}-->CLOSABLE _ -->:Send 1608 ACK_FLUSH:-->:Notify: |--:Rcv.PERSIST: _ |-->{Not EOT} _ |--{&& 1609 Not ULA-flushing}-->ACTIVE _ -->:Send SNACK:-->:Notify: _ |--{&& 1610 ULA-flushing}-->COMMITTED _ -->:Send SNACK:-->:Notify: 1611 _ |-->{EOT} _ |--{&& Not ULA-flushing}-->PEER_COMMIT _ -->:Send 1612 ACK_FLUSH:-->:Notify: _ |--{&& ULA-flushing}-->CLOSABLE _ 1613 -->:Send ACK_FLUSH:-->:Notify: |--:Rcv.RESET:-->NON_EXISTENT-->:N 1614 otify: |--{On transient state Timeout}-->NON_EXISTENT-->:Notify: 1616 CLONING is a state entered by ULA calling the API Multiply from any 1617 state that may accepting an out-of-band packet. 1619 5.16. Passive Multiplication {ACTIVE, COMMITTING, COMMITTED, 1620 PEER_COMMIT, COMMITTING2, 1621 CLOSABLE} |-->/MULTIPLY/-->:API{Callback}:-->{new 1622 context}CONNECT_AFFIRMING |--> :{Return Accept}: _ |-->{has 1623 payload prebuffered}-->{do respond} _ |-->{without 1624 payload}-->:Prebuffer ACK_START:-->{do respond} |-->:{Return 1625 Reject}:-->{abort creating new context}:Send RESET: 1627 In the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, COMMITTING2 or 1628 CLOSABLE state an FSP end node MAY accept its peer's connection 1629 multiplication request and transit to the unnamed, temporary passive 1630 multiplication state. 1632 5.17. Typical State Transitions 1634 This section is informative. 1636 5.17.1. Typical Main Connection 1638 Initiator Responder 1639 *** Bootstrapping *** 1641 CONNECT_BOOTSTRAP ------ INIT_CONNECT -------> LISTENING 1642 | <---- ACK_CONNECT_INIT ----- 1643 CONNECT_AFFIRMING ------ CONNECT_REQUEST ----> | 1645 *** Connection affirmation, carrying welcome messages *** 1646 | 1647 {Accept} 1648 {and send a single packet welcome message immediately} 1649 | 1650 | <- ACK_CONNECT_REQ c/w EoT - CHALLENGING 1651 PEER_COMMITTED 1652 | 1653 {Callback, to send ticket immediately} 1654 {(a fictional identification token of a single packet)} 1655 | 1656 COMMITTING2 ----- PERSIST c/w EoT -----> | 1657 CLOSABLE 1658 | <-------- ACK_FLUSH -------- | 1659 CLOSABLE 1660 | 1661 {Send Server's Challenge} 1662 | 1663 | <----- PERSIST w/o EoT ----- PEER_COMMITED 1664 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1665 . 1666 . 1668 . | 1669 {Flush} 1670 | 1671 | <---- PURE_DATA c/w EoT ---- COMMITTING2 1672 CLOSABLE 1673 --------- ACK_FLUSH -------> | 1674 CLOSABLE 1675 | 1676 {Send Client's Response} 1677 | 1678 PEER_COMMITTED ----- PERSIST w/o EoT -----> | 1679 COMMITTED 1681 | <--- KEEP_ALIVE(SNACK) ----- | 1682 . 1683 | ---- PURE_DATA w/o EoT ----> COMMITTED 1684 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ---- | 1685 . 1686 . 1687 | . 1688 {Flush} 1689 | 1690 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1691 CLOSABLE 1692 | <-------- ACK_FLUSH -------- 1693 CLOSABLE 1695 *** Typical C/S request-response exchanges at application layer *** 1696 | 1697 {Send Request} 1698 | 1699 PEER_COMMITTED ----- PERSIST w/o EoT -----> | 1700 COMMITTED 1701 | <--- KEEP_ALIVE(SNACK) ----- | 1702 . 1703 | ---- PURE_DATA w/o EoT ----> COMMITTED 1704 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ----- | 1705 . 1706 . 1707 | . 1708 {Flush} 1709 | 1710 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1711 CLOSABLE 1712 | <-------- ACK_FLUSH -------- 1713 CLOSALBE 1714 {Send Response} 1715 | 1716 | <----- PERSIST w/o EoT ----- PEER_COMMITED 1717 COMMITTED 1718 ---- KEEP_ALIVE(SNACK) ----> | 1719 . 1720 | <---- PURE_DATA w/o EoT ---- PEER_COMMITED 1721 COMMITTED ---- KEEP_ALIVE(SNACK) ----> | 1722 . 1723 . 1724 . 1725 {Flush} 1726 | 1727 | <---- PURE_DATA c/w EoT ---- COMMITTING2 1728 CLOSABLE 1729 --------- ACK_FLUSH -------> | 1730 CLOSALBE 1731 . 1732 . 1733 . 1734 *** Following request-responses, e.g. HTTP pipelining *** 1735 . 1736 . 1737 . 1739 CLOSABLE CLOSALBE 1740 . 1741 . 1742 *** End of connection, in a typical C/S application *** 1743 | 1744 {Shutdown} 1745 | 1746 | <---------- RELEASE -------- PRE_CLOSED 1747 SHUT_REQUESTED 1748 --------- ACK_FLUSH -------> | 1749 | CLOSED 1750 {Shutdown} 1751 | 1752 CLOSED 1754 5.17.2. Typical Clone Connection for Get Resource 1756 Client Server 1757 *** Suppose the browser fork a new connection to request *** 1758 *** some resource and the URI is short enough to be *** 1759 *** encapsulated in a single packet *** 1761 {MultiplyAndWrite} 1762 | {In Clonable State} 1763 CLONING ---- MULTIPLY c/w EoT ----> * 1764 {Make Clone Connection} 1765 {and return resource data immediately} 1766 | 1767 | <---- PERSIST w/o EoT ------ PEER_COMMITTED 1768 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1770 <---- PUER_DATA w/o EoT ---- PEER_COMMITTED 1771 COMMITTED ---- KEEP_ALIVE(SNACK) ----> 1772 . 1773 . 1774 . | 1775 {Flush} 1776 | 1777 | <--- PURE_DATA c/w EoT ----- COMMITTING2 1778 CLOSABLE 1779 --------- ACK_FLUSH -------> | 1780 CLOSABLE 1781 . 1782 . 1783 *** End of Connection *** 1785 5.17.3. Typical Clone Connection for Push Message 1787 Initiator of Multiplication Responder of Multiplication 1788 *** Suppose the server fork a new connection to push message *** 1790 (Used to be server side) (Used to be client side) 1791 | 1792 {MultiplyAndWrite} 1793 | {In Clonable State} 1794 CLONING ---- MULTIPLY w/o EoT ----> * 1795 {Make Clone Connection} 1796 *** suppose no immediately available responding data *** 1797 | 1798 COMMITTING 1799 | <--- NULCOMMIT(c/w EoT) ---- | 1800 PEER_COMMITTED 1801 | --------- ACK_FLUSH -------> COMMITTED 1802 . 1803 | ---- PURE_DATA w/o EoT ----> COMMITTED 1804 PEER_COMMITTED <--- KEEP_ALIVE(SNACK) ---- | 1805 . 1806 . 1807 | . 1808 {Flush} 1809 | 1811 COMMITTING2 ---- PURE_DATA c/w EoT ----> | 1812 CLOSABLE 1813 | <-------- ACK_FLUSH -------- 1814 CLOSABLE 1815 . 1816 . 1817 *** End of Connection *** 1819 5.17.4. Simultaneous Shutdown 1821 CLOSABLE CLOSABLE 1822 | | 1823 {Shutdown} {Shutdown} 1824 | | 1825 PRE_CLOSED PRE_CLOSED 1826 | \ / | 1827 | \ / | 1828 | \ / | 1829 | \------------- RELEASE --------------/----->+ 1830 +<------------------- RELEASE ------------/ | 1831 | CLOSED 1832 CLOSED 1834 6. End-to-End Negotiation 1836 End-to-end negotiation of FSP session occurs in the connection 1837 establishment phase. Connection establishment process of FSP 1838 consists of two and a half pairs of packet exchanges for connection 1839 initialization, connection incarnation and the last confirmation. 1840 During the process various optional header or payload MAY be carried 1841 in the FSP preliminary packets to negotiate end-to-end session 1842 parameters. 1844 6.1. Connect Initialization 1846 The initiator sends the INIT_CONNECT packet to the responder: 1847 (INIT_CONNECT, Salt, Timestamp, Init-Check-Code [, Responder's Host 1848 Name]) 1850 Connection initialization MAY be syndicated with optional address 1851 resolution at the gateway in the IPv6 network by carrying the 1852 responder's host name in the INIT_CONNECT packet. 1854 If it does carry the responder's host name it MUST take the link- 1855 local interface address [RFC4291] as the source IPv6 address and the 1856 default link-local gateway address, FE80::1, as the destination IPv6 1857 address no matter whether the global unicast IP address of the 1858 default gateway is configured. 1860 If the gateway that relays the INIT_CONNECT packet finds that the 1861 responder is on the same link-local network with the initiator it 1862 SHALL change the source and the destination IP addresses of the 1863 INIT_CONNECT packet to the link-local IP addresses of the initiator 1864 and the responder respectively, and relay the packet onto the same 1865 link-local network. 1867 On receiving the INIT_CONNECT packet that carries the responder's 1868 host name the link-local gateway MUST resolute the responder's global 1869 unicast IPv6 address and map the initiator's global unicast IPv6 1870 address, and replace the destination and source address of the 1871 INIT_CONNECT packet respectively, unless it finds that the initiator 1872 and the responder are on the same link-local network, where the 1873 gateway SHALL process the packet as stated in the previous statement. 1875 The gateway SHALL silently ignore the INIT_CONNECT packet if it is 1876 unable to resolve the IP address of the responder. 1878 If the destination address is the default link-local gateway address 1879 while the INIT_CONNECT does not carry the responder's host name 1880 payload, it is supposed that the gateway is the intent destination of 1881 the connection to initialize. 1883 6.2. Response to Connect Initialization 1885 The responder sends acknowledgment to the initiator: 1887 Case 1: (ACK_INIT_CONNECT, Time-delta, Cookie, Init-Check-Code 1888 Reflected, Responder's Sink Parameter) 1890 Case 2: (RESET, Reason of Failure, Timestamp Reflected, Init-Check- 1891 Code Reflected) 1893 In case 1 the responder is ready to accept the connection. It SHALL 1894 NOT make state transition on receiving INIT_CONNECT packet. It SHALL 1895 generate a cookie which is meant to be reflected by the initiator. 1896 The responder MUST send the ACK_INIT_CONNECT packet with the new 1897 allocated local ULTID instead of the original listening ULTID. The 1898 initiator should be able to find out the original listening ULTID by 1899 searching its own connection context. 1901 In the Responder's Sink Parameter the original listener ULTID MUST be 1902 set to the right value. 1904 In case 2 the responder refuses to accept the connection. It SHALL 1905 send back a RESET packet with the listening ULTID as the source 1906 ULTID. 1908 In either case the destination address of the packet sent back MUST 1909 be set to the source address of the corresponding Connect 1910 Initialization packet whose source and destination address MAY be 1911 updated by some intermediary such as the link-local gateway of the 1912 initiator. 1914 6.3. Connection Incarnation Request 1916 (CONNECT_REQUEST, Salt, Timestamp, Init-Check-Code, Initial SN, Time- 1917 delta Reflected, Cookie Reflected, Initiator's Sink Parameter [, 1918 Initiator's Host Name]) 1920 The initiator accepts the Response to Connect Initialization packet 1921 if and only if both the destination ULTID of the response packet 1922 matches the source ULTID of the connect initialization packet and the 1923 Init-Check-Code reflected in the response packet matches the Init- 1924 Check-Code in the connect initialization packet. 1926 If the response packet is accepted the initiator formally requests to 1927 establish the connection by sending the CONECT_REQUEST packet. 1929 In the CONNECT_REQUEST packet the value of the Timestamp, the Init- 1930 Check-Code and the Salt field MUST be the same as in the INIT_CONNECT 1931 packet while the value of the Cookie Reflected field and the Time- 1932 delta Reflected field MUST be the same as in the ACK_INIT_ CONNECT 1933 packet, respectively. 1935 The initiator MUST send the packet towards the remote ULTID that the 1936 responder has preserved and sent with the ACK_INIT_CONNECT packet. 1937 It MUST fill the original listener ID field in the Initiator's Sink 1938 Parameter with the right value. 1940 The source address of the CONNECT_REQUEST packet MUST be set to the 1941 destination address of the received ACK_INIT_CONNECT packet, while 1942 the network prefix and host-id part of the destination address MUST 1943 be set to the source address of the received ACK_INIT_CONNECT packet 1944 in the IPv6 network. 1946 The initiator SHALL save the cookie value that the responder has 1947 given to make up the weak session key. 1949 The initiator MUST fill the Initial SN field with the sequence number 1950 of the packet that will follow CONNECT_REQUEST. The CONNECT_REQUEST 1951 packet is payload free and does not consume the sequence space. 1953 The optional fields Initiator's Host Name is put as the payload of 1954 the CONNECT_REQUEST packet. If presented it MAY be exploited by the 1955 responder as the last resort to resolute the most recent IP address 1956 of the initiator in some extraordinary scenarios such as the 1957 initiator has hibernated for a considerably long time. 1959 6.4. Connection Incarnation Response 1961 Case 1: (ACK_CONNECT_REQ, FREWS, Initial SN, Expected SN, ICC[, 1962 Payload]) 1964 Case 2: (RESET, Reason of Failure, Timestamp Reflected, Copy of 1965 Cookie Reflected) 1967 The responder responds as in case 1 if the reflected cookie was 1968 validated, resources were successfully allocated and the initial 1969 context of the connection was setup. Otherwise it SHOULD respond as 1970 in case 2. 1972 The Initial SN in case 1 is the initial sequence number of the 1973 responder. The responder should fill in the field with a random 32- 1974 bit unsigned integer. As the ACK_CONNECT_REQ packet may carry 1975 payload the sequence number of the responder starts from the 1976 ACK_CONNECT_REQ packet. 1978 The Expected SN MUST equal to the Initial SN specified in the 1979 corresponding CONNECT_ REQUEST packet. 1981 6.5. The Last Confirmation 1983 Case 1: (ACK_START, FREWS, Initial SN, Expected SN, ICC) 1985 Case 2: (PERSIST, FREWS, Initial SN, Expected SN, ICC, payload) 1987 Case 3: (RESET, Reason of Failure, Initial SN, Expected SN, ICC) 1989 The initiator of the connection MUST eventually confirm to the 1990 responder that the connection is established by sending a payload- 1991 less ACK_START packet (case 1) or a PERSIST packet with payload (case 1992 2). 1994 Of course the initiator MAY quit to establish the connection by 1995 sending a legitimate RESET packet (case 3). 1997 6.6. Retransmission 1999 The initiator SHALL retransmit the INIT_CONNECT packet if the 2000 corresponding ACK_INIT_CONNECT packet is not received in some limit 2001 time (by default 15 seconds). 2003 The initiator SHALL retransmit the CONNECT_CONNECT packet if the 2004 corresponding ACK_CONNECT_REQ packet is not received in some limit 2005 time (by default 15 seconds). 2007 The responder SHALL NOT retransmit ACK_INIT_CONNECT or 2008 ACK_CONNECT_REQ packet. 2010 The initiator SHOULD retransmit the right INIT_CONNECT packet or 2011 CONNECT_CONNECT packet until the legitimate ACK_CONNECT_REQ packet is 2012 eventually received. 2014 It SHALL give up if the time starting from the very first 2015 INIT_CONNECT packet was sent has exceed a longer timed-out value (by 2016 default 60 seconds) before the legitimate ACK_CONNECT_REQ packet is 2017 received. 2019 7. Quad-party Session Key Installation 2021 It is assumed that in the scenarios applying FSP it is the ULA to do 2022 key establishment and/or end-point authentication while the FSP layer 2023 provides authenticated, optionally encrypted data transfer service. 2024 The ULA installs the established shared secret key as the new session 2025 key of the FSP layer. Together they establish a secure channel 2026 between two application end-points. 2028 In a typical scenario the ULA endpoints first setup the FSP 2029 connection where resistance against connection redirection is weakly 2030 enforced by CRC64. After the pair of ULA endpoints have established 2031 a shared secret key, they install the secret key. Authenticity of 2032 the FSP packets sent later is cryptographically protected by the new 2033 secret key and resistance against various attacks is secured. 2035 Although transmit transaction is actually uni-directional the secret 2036 key is shared bi-directionally in this version of FSP. 2038 Protocol for installation of the shared secret key is quad-party in 2039 the sense that both the upper layer application and the FSP layer of 2040 both the participant nodes MUST agree on the moment of certain state 2041 to install the shared secret key. 2043 It is arguably much more flexible for the application layer protocols 2044 to adopt new key establishment algorithm while offloading routine 2045 authentication and optionally encryption of the data to the 2046 underlying layers where it may be much easier to exploit hardware- 2047 acceleration. 2049 7.1. API for Session Key Installation 2051 A dedicate application program interface (API) is designed for the 2052 ULA to install the secret key established by the ULA participants. 2053 The API SHOULD take four parameters: 2055 - A 'handle' to state the connection context for installing the 2056 session key 2057 - A octet string of initial key materials (IKM) 2058 - An integer to state the length of IKM. The unit is octet. 2060 The peer MUST have commit a transmit transaction and it SHALL install 2061 the same secret key on receiving the FSP packet with the EoT flag 2062 set. 2064 The ULA SHOULD have installed the new shared secret key, or install 2065 it instantly after accepting the packet with the EoT flag set. If 2066 the new secret key has ever been installed the packet received after 2067 the one with the EoT flag set MUST adopt the new secret key. 2069 - An integer to state the desired length of the effective session key 2070 if AEAD is applied. The unit is bit. For this version of FSP 2071 desired length of the effective session key is either 128 or 256. 2073 7.2. Time to Call API for Session Key Installation 2075 A participant MAY install new session key if and only if the packet 2076 with the latest sequence number it has received has EoT flag marked. 2078 7.3. Time to Take New Session Key into Effect 2080 By committing a transmit transaction a ULA participant clearly tells 2081 the underlying FSP layer that the next packet sent MAY adopt a new 2082 secret key. On receiving a packet with the EoT flag set the ULA is 2083 informed that the next packet received MAY adopt a new shared secret 2084 key. 2086 After the ULA of a network node installed a new session key, every 2087 packet to send with sequence number later than the one with the EoT 2088 flag set just before the API to install session key was called MUST 2089 adopt the new session key in the FSP layer of the network node. 2091 Every packet received with the sequence number later than the one 2092 with EoT flag set when the ULA called the API to install session key 2093 MUST be validated with the new session key. If the new secret key 2094 has ever been installed the packet received after the one with the 2095 EoT flag set MUST adopt the new secret key. 2097 7.4. Generating the Initial Session Key 2099 When the ULA install the secret key, it is required to provide the 2100 initial key material which might have unbalanced bit randomness, not 2101 the session key itself. HMAC-based Extract-and-Expand Key Derivation 2102 Function (HKDF) [RFC5869] is applied to generate the initial session 2103 key. 2105 Given raw key material ikm, length of the ikm nB in octets, intended 2106 master key length lenb in bits, || is octet string concatenation, 2108 If HMAC only is designated, the nB octets of ikm is hashed into 64 2109 octets which is taken as the master key. 2111 If AEAD is designated, the initial session key, or the first secret 2112 key for packet authentication and payload encryption is obtained as 2113 specified in [RFC5869]: 2115 Key Extract phase, 2117 Let Km = BLAKE2(zeros || ikm) , where 2119 zeros is 32 octets of integer 0 2120 BLAKE2b algorithm without key is applied. 2122 The result Km is the master key. 2124 Key Expand phase, 2126 Let Ks = BLAKE2(Km, info) , where 2128 Km is the master key generated in previous phase, 2130 info is concatenation of the arbitrary ASCII string "Establishes an 2131 FSP session", which is 26-octet long, 3 octets of integer 0, and 1 2132 octet of integer 1. 2134 BLAKE2b algorithm with key is applied. The key applied MUST be the 2135 master key Km. 2137 The result Ks is the initial session key, or the first secret key 2138 for packet authentication and payload encryption. 2140 For this version FSP the generated Ks is a fixed-length AES key 2141 together with a 4-octet salt. The salt is meant to be passed to 2142 AES-GCM as the initialization vector together with the sequence 2143 number and expected sequence number fields in the normal FSP fixed 2144 header: 2146 0 31 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Salt | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | Sequence Number | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Expected Sequence Number/Out-of-band Serial Number | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 The salt is called 'the original salt', separated from 'the second 2156 salt' in the out-of-band packet. 2158 7.5. Internal Rekeying 2160 In this version of FSP it is forced to re-key on sending or receiving 2161 every 536870912? (2^29) packets. 2163 Let Ks' = BLAKE2(Km, H || info') , where: 2165 Km is the master key generated as in section 7.4. 2167 H is the 16-octet internal hash sub-key of AES-GCM of previous 2168 session key, 2170 info' is concatenation of the arbitrary ASCII string "Sustains an 2171 FSP connection", which is 26-octet long and the 4 octets in network 2172 order of the 32-bit unsigned integer that specifies the batch index 2173 of the session key. 2175 BLAKE2b algorithm with key is applied. The key applied MUST be the 2176 master key Km. 2178 The result Ks' is the new session key, together with the new salt 2179 meant to be form the IV. 2181 The batch index of the initial session key is 1, and it is increased 2182 by 1 every time before it is to re-key. 2184 7.6. Sample Sequence of Installing Session Key 2186 This section is informative. 2188 Node A Node B 2189 ULA-A FSP-A FSP-B ULA-B 2190 {Send Km-A} 2191 ->[seq_a2b_0] -> 2192 {Send Km-B} 2193 <- [seq_b2a_0]<- 2194 . 2195 . 2196 . 2197 {Commit} 2198 ->[seq_a2b_m c/w EoT] -> 2199 {Install Key} 2200 . 2201 {Wait} . 2202 . 2203 {Commit} 2204 <- [seq_b2a_n c/w EoT]<- 2205 {Install Key} 2206 . 2207 . {Send Further} 2208 <- [seq_b2a_n+1]<- 2209 . 2210 {Send Further} . 2211 ->[seq_a2b_m+1] -> 2213 o Send Km-A, Send Km-B 2214 ULA of node A and node B send there key material for key 2215 establishment, respectively. 2217 - Commit 2219 ULA of node A or node B informs the FSP layer to set the End of 2220 Transaction flag of the last packet to send and flush the send 2221 buffer. 2223 - Install Key 2225 ULA of node A or node B informs the FSP layer to install new 2226 session key, giving key materials for deriving the session key. 2228 A node may call Install Key if and only if its peer has just 2229 committed a transmit transaction. 2231 - Wait 2233 The ULA MUST wait until it has received some packet with EoT 2234 set from its peer before it may install new session key. 2236 There is no mandatory calling order of Commit and Install Key. 2237 However, if a node Commit before Install Key and it wants to 2238 apply new session key for the transmit transaction next to the 2239 one it has just committed, it SHALL NOT send further data until 2240 Install Key has returned successfully. 2242 In the above example, for node A packet with sequence number 2243 [seq_a2b_m+1] will be sent by applying the new session key, for 2244 node B packet with sequence number [seq_b2a_n+1] will be sent 2245 by applying the new session key. 2247 - Send Further 2249 ULA of node A or node B sends further data in the new transmit 2250 transaction, respectively. 2252 There is no mandatory order on which node should start new 2253 transmit transaction firstly. 2255 8. Send and Receive 2256 8.1. Packet Integrity Protection 2258 8.1.1. Application of CRC64 2260 Starting from ACK_CONNECT_REQUEST, until the ULAs have installed the 2261 shared secret CRC64 is applied to calculate the value of the ICC 2262 field. The algorithm: 2264 1.Take pair of the ULDs as the initial value of accumulative CRC64 2265 The pair of the ULDs is composed of the near end's ULTID and the 2266 remote end's ULTID, where the former is the leftmost 32 bits and 2267 the latter is the rightmost 32 bits of initial value for the send 2268 direction, and the order is reversed for the receive direction. 2270 2.Accumulate the value of the Init-Check-Code field 2272 3.Accumulate the value of the Cookie field successively 2274 4.Accumulate the combined value of the salt and the timeDelta field 2275 where the former is the leftmost 32 bits and the latter is the 2276 rightmost 32 bits 2278 5.Accumulate the value of the Time Stamp field 2280 6.Save the accumulated CRC64 value 2281 as the pre-computed CRC64 value. 2283 When calculate the value ICC of a particular FSP packet, firstly set 2284 ICC to the pre-computed CRC64 value, then calculate the CRC64 2285 checksum of the whole FSP packet, while ULTIDs are NOT included if 2286 the FSP packet is encapsulated in UDP. The result is set as the 2287 final value of the ICC field. 2289 8.1.2. Packet Authentication Only 2291 The ULA designates the FSP layer to either applying HMAC only or 2292 applying AEAD. 2294 If the HMAC flag of a packet is set the pre-designated cryptographic 2295 hash function SHALL be applied to get the message authentication code 2296 (MAC) of the whole packet. Each FSP version MUST designate one and 2297 only one particular cryptographic hash function. 2299 For this FSP version, BLAKE2 [RFC7693] is designated as the 2300 cryptographic hash function. The input key is the secret key that 2301 has been derived from the master key installed by the ULA. The input 2302 data is the full FSP packet, where the ICC field is pre-filled the 2303 pair of the ULDs. As in making CRC64 checksum, the pair of the ULDs 2304 is composed of the near end's ULTID and the remote end's ULTID, where 2305 the former is the leftmost 32 bits and the latter is the rightmost 32 2306 bits of initial value for the send direction, and the order is 2307 reversed for the receive direction. 2309 The hash result is truncated to 64 bits to get the final ICC. 2311 8.1.3. Authenticated Encryption with Additional Data 2313 FSP provides per-packet authenticated encryption service. Only one 2314 authenticated encryption algorithm is allowed for a determined 2315 version of FSP. For this FSP version, the authenticated encryption 2316 algorithm selected is GCM-AES [GCM][AES], it is applied to protect 2317 integrity of the full FSP packets, and privacy of the payload 2318 together with the extension headers, if any. The four inputs to GCM- 2319 AES authenticated encryption are: 2321 K: the key derived by the master key installed by ULA. The length of 2322 the session key is determined by the ULA. 2324 IV: the initial vector, 96-bit string made by concatenating a 32-bit 2325 salt, the 32-bit sequence number of the packet and the 32-bit 2326 expected sequence number field of the packet. The salt is derived by 2327 the master key installed by ULA. 2329 P: the plaintext are the bytes following the fixed header up to the 2330 end of the original payload. 2332 AAD: additional authenticated data, for this version of FSP it is the 2333 fixed header of the FSP packet. The source ULTID MUST be stored in 2334 the leftmost 32-bit of the ICC field while the destination ULTID MUST 2335 be stored in the rightmost 32-bit of the ICC field before the ICC 2336 value is calculated. 2338 The length of the authentication tag MUST be 64 bits for FSP version 2339 0 and 1. The authentication tag is stored in the ICC finally. 2341 The inputs to GCM-AES decryption are: 2343 K: the key derived by the master key installed by ULA. The length of 2344 the session key is determined by the ULA. 2346 IV: the initial vector, 96-bit string made by concatenating consisted 2347 of the 32-bit salt, the 32-bit sequence number of the packet and the 2348 32-bit expected sequence number field of the packet. 2350 C: the ciphertext are the bytes following the fixed header up to the 2351 end of the received payload. 2353 AAD: additional authenticated data, for this version of FSP it is the 2354 fixed header of the FSP packet. The source ULTID MUST be stored in 2355 the leftmost 32-bit of the ICC field while the destination ULTID MUST 2356 be stored in the rightmost 32-bit of the ICC field before the ICC 2357 value is calculated. 2359 T: The authentication tag, which is fetched from the ICC field 2360 received. 2362 Only when the outputs of GCM-AES decryption tell that the 2363 authentication tag passed verification may the receiver deliver the 2364 decrypted payload to the ULA. 2366 8.1.4. ICC of the Out-of-Band Packet 2368 When calculating the ICC of an out-band packet (KEEP_ALIVE, ACK_FLUSH 2369 or MULTIPLY), the ExpectedSN field SHALL be filled with the out-of- 2370 band serial number. The first 32-bit word of the fixed header is 2371 taken as the second salt. 2373 To get or check the ICC of the out-of-band packet the original salt 2374 value that is set on deriving the session key and stored in the 2375 internal security context MUST be XORed with the second salt value 2376 before applying GCM-AES. The original salt value MUST be recovered 2377 instantly after GCM-AES is applied. 2379 8.2. Start a New Transmit Transaction 2381 The responder starts AND terminates a transmit transaction by send 2382 the ACK_CONNECT_REQ packet. 2384 The initiator starts a new transmit transaction by sending a PERSIST 2385 packet: 2387 (PERSIST, FREWS, SN, ExpectedSN, ICC, Payload) 2389 Or starts AND terminates a transmit transaction by send the ACK_START 2390 packet: 2392 (ACK_START, FREWS, SN, ExpectedSN, ICC [, Sink Parameter]) 2394 8.3. Send a Pure Data Packet 2396 (PURE_DATA, FREWS, SN, ExpectedSN, ICC, Payload) 2398 After a new transmit transaction has been started further PURE_DATA 2399 packet MAY be sent until a packet with EoT flag set is sent. 2401 8.4. Commit a Transmit Transaction 2403 8.4.1. Initiate Transmit Transaction Commitment 2405 A participant of an FSP connection MAY notify its peer that a 2406 transmit transaction shall be committed by setting the EoT flag of 2407 the last packet of the transmit transaction, be it PERSIST, 2408 ACK_START, PURE_DATA or MULTIPLY. 2410 8.4.2. Respond to Transmit Transaction Commitment 2412 (ACK_FLUSH, FREWS, SN, ExpectedSN, ICC) 2414 If and only if all of the packets in a transmit transaction has been 2415 received MAY ACK_FLUSH packet be sent. 2417 Whenever a legitimate packet falls in the receive window of the 2418 receiver, and the packet fills in the last gap of the sequence of 2419 current transmit transaction on receiving direction, or the packet 2420 with same sequence number has been accepted already, a responding 2421 ACK_FLUSH SHALL be sent back immediately, and the FSP layer MUST 2422 immediately notify the ULA that a transmit transaction has been 2423 committed. 2425 The sequence number (SN) of the ACK_FLUSH packet MUST equal the 2426 latest sequence number of the legitimate packets that have been sent. 2428 The out-of-band serial number SHALL increase by one whenever a new 2429 ACK_FLUSH packet is sent. 2431 8.4.3. Finalize Transmit Transaction Commitment 2433 After receiving the ACK_FLUSH packet the sender of the EoT flag 2434 migrates to the COMMITTED or CLOSABLE state from the COMMITTING or 2435 COMMITTING2 state, respectively. 2437 8.4.4. Time-out for Committing Transmit Transaction 2439 The ULA SHALL be timed-out if there is no packet was acknowledged in 2440 some hard-coded time-out. For this version of FSP the time-out is 2441 set to 30 seconds. 2443 8.5. Retransmission 2444 8.5.1. Calculation of RTT 2446 We borrows specifications for calculating RTT (and RTO) considerably 2447 from Computing TCP's Retransmission Timer [RFC6298] to calculate 2448 Retransmission Time Out (RTO). 2450 The sender maintains two state variables, SRTT (smoothed round-trip 2451 time) and RTTVAR (round-trip time variation). In addition, we assume 2452 a clock granularity of G seconds. 2454 Initial round trip time (RTT) for the Connection Initiator: Equals to 2455 the mean of the time elapsed when ACK_ INIT_CONNECT was received 2456 since INIT_CONNECT was sent, and the time elapsed till 2457 ACK_CONNECT_REQ was received since CONNECT_REQUEST was sent. 2459 Initial RTT for the Connection Responder: Equals to the time elapsed 2460 when the ACK_START or the first PERSIST packet was received since 2461 ACK_CONNECT_REQ was sent. 2463 Initial RTT for the Initiator of Connection Multiplication: Equals to 2464 the time elapsed when the first PERSIST packet was received since 2465 MULTIPLY was sent. 2467 Initial RTT for the Responder of Connection Multiplication: Equals to 2468 the most recent RTT of the multiplied connection. 2470 o When the Initial RTT measurement R is made, the host MUST set 2472 SRTT <- R 2473 RTTVAR <- R/2 2475 o When a subsequent RTT measurement R' is made, a host MUST set 2477 RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| 2478 SRTT <- (1 - alpha) * SRTT + alpha * R' 2480 The value of SRTT used in the update to RTTVAR is its value before 2481 updating SRTT itself using the second assignment. That is, 2482 updating RTTVAR and SRTT MUST be computed in the above order. 2484 The above SHOULD be computed using alpha=1/8 and beta=1/4. 2486 R' SHOULD be measured whenever a packet with the SNACK extension 2487 header is received. 2489 Suppose the packet with the latest SN that is accumulatively 2490 acknowledged is P-latest, R' equals the time when the SNACK header 2491 is received, minus the time when P-latest was sent, minus the 2492 delay that the acknowledgment was made. 2494 The delay that the acknowledgment was made is stored in the 2495 "Acknowledgement Delay" field of the SNACK header. It equals the 2496 time difference between the time when the acknowledgement was sent 2497 and the time when P-latest was received. 2499 Note that the no packet with SN later than any gap described in 2500 the SNACK header is considered as the packet with the latest SN 2501 that is accumulatively acknowledged. 2503 8.5.2. Generation and transmission of SNACK 2505 Whenever the receiver receives a packet it SHALL shift the time to 2506 send next heartbeat signal earlier to the time of RTT since current 2507 time, if the time to send next heartbeat signal used to be later. If 2508 the time is already earlier than the time of RTT since current time, 2509 it needs not be shifted. 2511 On the time to send the heartbeat signal the FSP node generates the 2512 SNACK header, then generate and send a new KEEP_ALIVE or ACK_FLUSH 2513 packet to carry the SNACK header. It SHALL send an ACK_FLUSH if it 2514 is in PEER_COMMIT, COMMITTING2 or CLOSABLE state, otherwise it SHALL 2515 send a KEEP_ALIVE packet. 2517 8.5.3. Negative acknowledgment of Packets Sent 2519 Both the ACK_FLUSH and the KEEP_ALIVE packet in FSP carry the SNACK 2520 extension header, although number of gap descriptors in the SNACK 2521 extension header in the ACK_FLUSH packet MUST be 0. We call them 2522 SNACK packets. A SNACK packet P1 is said to be later than P0, if and 2523 only if SN of P1 is later than SN of P0, or SN of P1 equals SN of P0 2524 while the out-of-band sequence number of P1 is later than the out-of- 2525 band sequence number of P0. If the latest SNACK packet is ACK_FLUSH, 2526 all the packets with the sequence number later that the expected 2527 field of the packet are assumed to be negatively acknowledged. 2529 By convention when we specify the range, the left square bracket 2530 meant to be inclusive, while the right parenthesis meant to be 2531 exclusive, the packets with SN in the ranges: [expectedSN, 2532 expectedSN + 1st Gap Width), 2534 [expectedSN + 1st Gap Width + 1st Data Length, 2535 expectedSN + 1st Gap Width + 1st DataLength + 2nd Gap Width), 2537 ... 2539 [expectedSN + 1st Gap Width + 1st Data Length 2541 o ... + (n-1)th Gap Width + (n-1)th Data Length, 2543 expectedSN + 1st Gap Width + 1st DataLength 2545 + ... + n-th Gap Width), 2547 together with the packets with SN later than {expectedSN + 1st Gap 2548 Width + 1st DataLength + ... + n-th Gap Width} are assumed to be 2549 negatively acknowledged, if the latest SNACK packet is KEEP_ALIVE. 2551 8.5.4. Retransmission Interval 2553 o Until RTT measurement has been made for a packet sent between the 2555 sender and receiver, the sender SHOULD set 2557 RTO <- 1 second. 2559 o After computing new SRTT, a host MUST update 2561 RTO <- SRTT + max (G, K*RTTVAR) 2563 where K = 4. 2565 o Clock granularity SHOULD be finer than 100msec, that is, it SHOULD 2566 be that G <= 0.1 second. 2568 o Whenever RTO is computed, if it is less than 1 second, then the 2569 RTO SHOULD be rounded up to 1 second. 2571 o An implementation MUST manage the retransmission timer(s) in such 2572 a way that 2574 - A packet is never retransmitted less than one RTO after the 2575 previous transmission of that packet. 2577 - Every time an in-band packet is sent (including a 2578 retransmission), if the timer is not running, start it running 2579 so that it will expire after RTO seconds (for the current value 2580 of RTO). 2582 - When all outstanding data has been acknowledged, turn off the 2583 retransmission timer. 2585 - When the retransmission timer expires, retransmit the packets 2586 that have not been acknowledged by the receiver, but limit by 2587 the rate throttling mechanism. 2589 o Rate of retransmission MUST be throttled in a way that 2591 - No more that M/2 packets may be retransmitted in a clock 2592 interval, suppose in each clock interval M packets were sent 2593 averagely. 2595 - Packet retransmission SHALL be subjected to congestion control 2596 as well. 2598 - However, at least one packet MAY be retransmitted in one clock 2599 interval, provide that the retransmission timer expires for the 2600 first packet that has not been acknowledged yet. 2602 8.6. Flow Control 2604 The participants of an FSP connection negotiate the initial receive 2605 window size with the FREWS field in the ACK_CONNECT_REQUEST packet, 2606 and the first PERSIST or ACK_START packet that acknowledges the 2607 ACK_CONNECT_REQUEST packet, respectively. The receive window size 2608 SHALL NOT be less than 4 and SHALL be less than 2^24. 2610 An FSP participant advertises current receive window size in the 2611 FREWS field. 2613 An FSP participant SHALL NOT send a packet whose sequence number is 2614 later than the value of the ExpectedSN field plus the advertised 2615 receive window size, where both value come from the very packet 2616 received with the latest sequence number. 2618 8.7. Congestion Control 2620 FSP supposes that end-to-end congestion control is provided by some 2621 shim layer, such as the congestion manager [RFC3124] between the 2622 "traditional" IP layer and the FSP transport layer. The shim layer 2623 is considered as a sub-layer of the network layer. Implementation of 2624 FSP MUST provide such shim layer if the network layer of the end node 2625 does not provide end-to-end congestion management service. 2627 FSP layer SHALL provide following information to the congestion 2628 manager as soon as the first packet on the fly was acknowledged by 2629 any mean, or a legitimate packet falling in the receive window with 2630 the ECE flag set is received: 2632 o The local interface number that the packet carrying the ECE signal 2633 is accepted. 2635 o The remote network prefix that the congestion information is meant 2636 to associate. Note that the aggregated host ID part is NOT 2637 included in the prefix. 2639 o The traffic class. For FSP it is bisected: MIND flag set or not. 2641 o Number of outstanding octets, including all of those in the 2642 payload AND the FSP headers. 2644 o The effective round trip time calculated in the most recent 2645 period. Note that retransmitted packets MUST be excluded on 2646 calculating the effective RTT. 2648 o Whether an ECN-Echo signal was received. The ECE flag of a 2649 legitimate packet falling in the receive window is the ECN-Echo 2650 signal. 2652 o Whether a sent packet with SRR flag set is acknowledged. 2654 The congestion manager SHOULD reduce the send rate if the FSP sender 2655 informed it that an ECN-Echo signal was received. 2657 The sender SHALL NOT inform the congestion manager to reduce the send 2658 rate again even if further packet with ECE flag set is received, 2659 until at least one sent packet with SRR flag set is acknowledged. 2661 A packet with ECE flag set received after the packet with SRR flag 2662 set is acknowledged SHOULD make the congestion manager reduce the 2663 send rate again. 2665 Retransmitted packet SHALL be subjected to send rate control at the 2666 underlying congestion management service sub-layer as well. 2668 Quota or other means to enforce fairness among various FSP 2669 connections SHOULD be provided directly to the ULA by the congestion 2670 management service. 2672 Requirement of an FSP congestion manager would be detailed in a 2673 separate document. 2675 8.8. On-the-Wire Compression 2677 FSP exploits the lossless compression algorithm as per [LZ4]. 2679 If the CPR flag of the first packet of a transmit transaction is set, 2680 compression is applied on the payload octet stream of the transaction 2681 transaction. 2683 When applying compression FSP divides source stream into multiple 2684 blocks. For this version of FSP length of each block is 128KiB 2685 (131072 octets), except the final block whose length may be less than 2686 or equal to 128KiB. The final block is the one that terminate the 2687 transmit transaction, i.e. which contains the last FSP packet of the 2688 transmit transaction. The last FSP packet of the transmit 2689 transaction has the EoT flag set. The "LZ4_compress_fast_continue" 2690 method SHALL be applied on each block. That is, data from previous 2691 compressed blocks are taken use for better compression ratio. 2693 When transferring the result data of compressing each block, the 2694 result data is prefixed with its length. The length is expressed by 2695 a 4-octets little-endian integer. 2697 On-the-wire compression of each transmit transactions is independent. 2698 It is the upper layer application that SHALL make agreement on which 2699 transmit transaction utilizes on-the-wire compression. 2701 8.9. Milk Like Payload and Minimal Delay Service 2703 An ordinary data flow is wine-like in the sense that the older data 2704 are more valuable. If it has to, data packet sent latest are dropped 2705 first. In the contrary, milk-like payload is that the newer data are 2706 more precious and outdated data packet can be discarded. 2708 When ULA is willing to accept incomplete message the peer of the 2709 underling FSP node SHALL set the MIND flag of the first PERSIST 2710 packet that starts the first transmit transaction, and set the MIND 2711 flag of every following PURE_DATA packet, while set the Traffic Class 2712 of the underlying IPv6 packet to some registered value. 2714 In the transmission path, any relaying middle box, be it router or 2715 switch, should reserve a reasonably short queue for the packet flow 2716 of such flow to minimize delay. 2718 When the receive buffer overflows the receiver discards the 2719 undelivered packet received first to free buffer space for the latest 2720 packet received. However it keeps order on delivering the packets to 2721 he ULA. ULA may choose to discard packets received earlier than some 2722 threshold. 2724 The receiver SHOULD NOT make any acknowledgement to the packet 2725 received with the MIND flag set. 2727 Minimal delay service is asymmetric in the sense that one 2728 transmission direction the data flow may be milk-like while in the 2729 reverse direction the data flow may be wine-like. 2731 A minimal delay service data flow is terminated by ULA via some out- 2732 of-band control mechanism. 2734 9. Graceful Shutdown 2736 One participant of an FSP connection MAY initiate graceful shutdown 2737 of the connection if and only if its peer has committed the most 2738 recent transmit transaction. 2740 By initiating graceful shutdown the participant tells its peer that 2741 current transmit transaction is to be committed as well. 2743 9.1. Initiation of Graceful Shutdown 2745 (RELEASE, FREWS, SN, ExpectedSN, ICC) 2747 An FSP end node MAY initiate graceful shutdown if it is in the 2748 PEER_COMMIT, COMMITTING2 or CLOSABLE state. It SHALL NOT initiate 2749 graceful shutdown if its peer has not committed current transmit 2750 transaction. 2752 Graceful shutdown is signaled to the remote end by sending a RELEASE 2753 command packet. The FSP end node SHALL migrate to the PRE_CLOSED 2754 state just before sending the RELEASE packet. 2756 9.2. Acknowledgment of Graceful Shutdown 2758 The RELEASE packet may be accepted in the COMMITTING, COMMITTED, 2759 COMMITTING2, CLOSABLE or PRE_CLOSED state. 2761 If the legitimate RELEASE packet is received in the COMMITTING or 2762 COMMITTED state, the FSP end node SHALL buffer the RELEASE packet, 2763 wait each packet of the last transmit transaction of its peer has 2764 been received, deliver all the buffered payload and then migrate to 2765 the SHUT_REQUESTED state. 2767 If the legitimate RELEASE packet is received in the COMMITTING2 or 2768 CLOSABLE state, the FSP end node SHALL migrate to the SHUT_REQUESTED 2769 state immediately. 2771 In either of the two cases the receiver of the RELEASE packet SHALL 2772 acknowledge the sender of the RELEASE packet with a legitimate out- 2773 of-band ACK_FLUSH packet. 2775 If the RELEASE packet is received in the PRE_CLOSED state, it is to 2776 finalize the graceful shutdown procedure. 2778 9.3. Finalization of Graceful Shutdown 2780 If either the legitimate RELEASE packet or the legitimate ACK_FLUSH 2781 packet is received in the PRE_CLOSED state the grace shutdown request 2782 is supposed to be acknowledged and the shutdown procedure SHALL be 2783 finalized by that the FSP end node migrates to the CLOSED state 2784 immediately. 2786 In SHUT_REQUESTED state the FSP node SHALL migrate to CLOSED state 2787 immediately on the Shutdown API called by the ULA. 2789 9.4. Retransmission of RELEASE Packet 2791 The FSP end node in the PRE_CLOSED state SHALL retransmit the RELEASE 2792 packet until it migrates to CLOSED state or it is timed out. 2794 As RELEASE is the in-band packet retransmission of the RELEASE packet 2795 is subjected to the normal retransmission rule. 2797 10. Mobility and Multi-home Support 2799 10.1. Heartbeat Signals 2801 FSP requires that the participants periodically send the heartbeat 2802 signals. 2804 The participant in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2805 COMMITING2 or CLOSABLE state MUST send the KEEP_ ALIVE packet as the 2806 heart-beat signal periodically to retain the connection in case that 2807 underlying IP address has changed. 2809 (KEEP_ALIVE, FREWS, SN, ExpectedSN, ICC, Sink Parameter, SNACK) 2811 Heartbeat signal is an out-of-band control packet. It does not carry 2812 payload. The sequence number of the KEEP_ALIVE packet SHALL be set 2813 to the latest sequence number of all of the packets that have been 2814 sent. 2816 Only the FSP node in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2817 COMMITING2 or CLOSABLE state MAY process the heartbeat signal. 2819 In this version of FSP the heat-beat period is arbitrarily set to 600 2820 seconds. 2822 The sequence number (SN) of the KEEP_ALIVE packet MUST equal the 2823 latest sequence number of the legitimate packets that have been sent. 2825 The out-of-band serial number SHALL increase by one whenever a new 2826 KEEP_ALIVE packet is sent. 2828 10.2. Active Address Change Signaling 2830 During communication process the FSP participant whose underlying IP 2831 address is changed SHOULD inform its peer such change by transmit a 2832 KEEP_ALIVE packet with the Sink Parameter extension header and the 2833 SNACK header so that the peer can retransmit the packets that were 2834 negatively acknowledged. 2836 Such informing KEEP_ALIVE packet SHALL be sent in the ACTIVE, 2837 COMMITTING, COMMITTED, PEER_COMMIT, COMMITING2 or CLOSABLE state. 2839 Informing KEEP_ALIVE packet SHOULD be sent more frequently than a 2840 normal heart-beat signaling KEEP_ALIVE packet. 2842 For this version of FSP informing KEEP_ALIVE packet SHALL be 2843 retransmitted every 4 RTT interval until the heuristic 2844 acknowledgement is received. 2846 10.3. Heuristic Remote Address Change Adaptation 2848 A participant of the FSP connection SHALL set the source address of 2849 the packet to transmit or retransmit to new IP address as soon as the 2850 near-end IPv4 address or IPv6 network prefix has changed. The ULTID 2851 field MUST remain the same. 2853 When a new packet with a later sequence number is received and the 2854 source IP address of the packet is found to be different with the 2855 preserved IP address of the remote end, the receiver SHOULD 2856 automatically update the preserved IP address of the remote end to 2857 the source IP address of the new packet, unless there is a Sink 2858 Parameter header in the packet. 2860 If the sequence number of the packet received is not the latest in 2861 the receive window the preserved IP address of the remote end SHALL 2862 NOT be updated even if the source address of the received packet has 2863 changed. 2865 10.4. Heuristic Address Change Acknowledgement 2867 The address change signaling KEEP_ALIVE packet is supposed to be 2868 acknowledged if a packet targeted at the new IP address that the 2869 KEEP_ALIVE packet has informed is received. 2871 10.5. NAT-traversal and Multihoming 2873 When FSP is implemented over UDP in the IPv4 network, each endpoint 2874 of the FSP connection is bound one and only one IPv4 address as soon 2875 as the connection is established. Each endpoint SHALL choose the 2876 source IPv4 address of the last packet received as the destination 2877 IPv4 address of the packet that it is to send later. By this mean 2878 FSP over UDP is NAT-friendly. 2880 When FSP is implemented over IPv6 as soon as the connection is 2881 established the IPv6 address may be changed dynamically, and one more 2882 alternate IP address may be added or removed dynamically for 2883 individual endpoint as well, provided that ULTID part keeps unchanged 2884 while the host IDs part of all IPv6 address of the endpoint are of 2885 the same value at any given moment. 2887 The sender may choose as the source IP address by selecting any 2888 network prefix that it has most-recently sent to its peer in the 2889 allowed address list field of the Sink Parameter header, joining with 2890 the host ID in the Sink Parameter header and the stable ULTID of the 2891 sender, and choose as the destination IP address by selecting any 2892 network prefix in the allowed address list field of the Sink 2893 Parameter header most-recently received from its peer, joining with 2894 the peer's host ID and the peer's ULTID. Thus multiple multi-homed 2895 paths MAY co-exist between the two FSP endpoints. 2897 10.6. Explicit Multi-home Informing 2899 If an FSP end node is configured with multiple IPv4 address other 2900 than the loop-back address, or with multiply global unicast IPv6 2901 address, it MAY advertise multiple underlying addresses to the remote 2902 end by put them in the addressable network prefix list of the Sink 2903 Parameter extension header. The Sink Parameter extension header may 2904 be carried in the CONNECT_REQUEST, ACK_CONNECT_REQ, NULCOMMIT, 2905 MULTIPLY or KEEP_ALIVE packet. 2907 Any participant of the communication SHALL NOT make discrimination of 2908 the source or destination IP address of any packet provided that both 2909 the source ULTID and the destination ULTID keep unchanged and the ICC 2910 field passes verification. 2912 11. Connection Multiplication 2914 Connection multiplication is the process of incarnating a new 2915 connection context by re-using security context of an established 2916 connection. 2918 11.1. Request to Multiply Connection 2920 (MULTIPLY, FREWS, SN, Salt, ICC [, Sink Parameter] [, payload]) 2922 The initiator's initial sequence number of the new connection is the 2923 sequence number of the packet that piggybacks the connection 2924 multiplication header. The ExpectedSN field of the normal packet 2925 store a Salt value instead. 2927 The FREWS field MUST be processed in the new connection context while 2928 the ICC MUST be calculated with the session key of the original 2929 connection. 2931 The new connection inherits the remaining key life. ULA SHOULD 2932 negotiate new session key and/or install new session key as soon as 2933 possible. 2935 The optional payload of the MULTIPLY packet MUST be processed in the 2936 new connection context. 2938 The MULTIPLY packet is an out-of-band command packet in the original 2939 connection context. 2941 11.2. Response to Connection Multiplication Request 2943 Case 1: (ACK_START, FREWS, SN, ExpectedSN, ICC [, Sink Parameter]) 2945 Case 2: (PERSIST, FREWS, SN, ExpectedSN, ICC, Payload) 2947 Case 3: (RESET, Reason of Failure, SN, ExpectedSN, ICC) 2949 In all of these cases the ULTID of the remote-end MUST be the value 2950 of the initiator's ULTID in the connection multiplication header. 2952 It is REQUIRED that only a connection in the ESTABLISHED, COMMITTING, 2953 COMMITTED, PEER_COMMIT, COMMITTING2 or CLOSABLE state may accept a 2954 connection multiplication request. 2956 In case 1 the responder admits the multiplication request AND commit 2957 the transmit transaction, the new connection enters into the 2958 PEER_COMMIT or CLOSABLE state immediately, on request of ULA. 2960 In case 2 the responder admits the multiplication request and the new 2961 connection enters into the ESTABLISHED, PEER_COMMIT, COMMITTING or 2962 CLOSABLE state immediately, depending whether the ULA of the 2963 multiplication initiator has requested to commit the transmit 2964 transaction immediately and whether the ULA of the multiplication 2965 responder has requested to commit the transmit transaction in the 2966 reverse direction immediately. 2968 In case 3 the responder rejects the multiplication request. To 2969 defend against spoofing attack ICC MUST be valid. The value of the 2970 SN field MUST equal the value of the 'Expected SN' field of the 2971 requesting MULTIPLY packet while the value of ExpectedSN field MUST 2972 equal the value of the 'Sequence No' field. 2974 The new connection MUST derive new session key from the session key 2975 of the original connection where the out-of-band requesting MULTIPLY 2976 packet is received immediately. 2978 11.3. Duplicate Detection of Connection Multiplication Request 2980 Every time the responder of connection multiplication receives a 2981 MULTIPLY packet it MUST check the suggested responder's ULTID and the 2982 initiator's ULTID. 2984 The responder MUST reject the multiplication request if the suggested 2985 responder's ULTID equals the near-end ULTID of some connection and 2986 the remote-end ULTID of that connection does not equal the 2987 initiator's ULTID. 2989 The responder MUST recognize the MULTIPLY packet as a duplicate 2990 connection request if some connection matches the request and SHOULD 2991 response by retransmitting the head packet of the send queue of the 2992 matching connection, be it a PERSIST or a NULCOMMIT packet. A 2993 connection matches the MULTIPLY request if and only if the suggested 2994 responder's ULTID in the MULTIPLY packet equals the near-end ULTID of 2995 the connection and the initiator's ULTID equals the remote-end ULTID 2996 of the connection. 2998 11.4. Retransmission 3000 The initiating side SHALL retransmit the MULTIPLY packet if the 3001 corresponding PERSIST packet is not received in some limit time (by 3002 default 15 seconds). 3004 11.5. Key Derivation for Branch Connection 3006 Let K_out = BLAKE2(Km, [d] || Label || 0x00 || Context || L), where: 3008 - Km is the master key, 3009 - [d] is one octet of integer Depth. It is alike the KDF counter 3010 mode as the NIST SP800-108. For this version of FSP it is the 3011 fixed number 1, 3013 - Label is the fixed ASCII string "Multiply an FSP connection" 3014 which is 26-octet long for this version of FSP, 3016 - Context is concatenation of two 32-bit words idB and idR 3018 idB is the ULTID allocated for the branch connection in the 3019 context of the multiplication initiator. idB is byte-order 3020 neutral. 3022 idR is the receiver side ULTID of the original connection that 3023 is to accept the connection multiplication request. idI or idR 3024 is byte-order neutral. 3026 - L is a 32-bit network byte-order integer specifying the length 3027 in bits of the derived key K-out 3029 12. Timeouts and Abrupt Close 3031 12.1. Timeouts in End-to-End Negotiation 3033 Initially the initiator is in the CONNECT_BOOTSTRAP state. It 3034 migrates to the CONNECT_ AFFIRMING state after it received the 3035 legitimate ACK_INIT_CONNECT packet. Then it migrates to the 3036 PEER_COMMIT or CLOSABLE state after it received the legitimate 3037 ACK_CONNECT _REQ packet, depending on the hint of ULA. 3039 The responder incarnates a new connection context which is initially 3040 in the CHALLENGING state after accepting a legitimate Connect Request 3041 packet. Then it migrates to the COMMITTING or CLOSABLE state, 3042 depending on the packet received from its peer. 3044 If the initiator or the responder is unable to migrate to a new state 3045 in some limit time (by default 60 seconds, except in LISTENING state) 3046 it aborts the connection by recycling the connection context. 3048 12.2. Timeouts in Multiply 3050 Initially the initiating side of Connection Multiplication is in the 3051 CLONING state. It migrates to the ACTIVE, COMMITTED, PEER_COMMIT or 3052 CLOSABLE state after it received the legitimate PERSIST packet. 3053 Which state to migrated depends on the EoT flag of the initiating 3054 MULTIPLY packet and the responding PERSIST packet. 3056 If the initiating side is unable to migrate to a new state in some 3057 limit time (by default 60 seconds) it aborts multiplication by 3058 recycling the new connection context. 3060 12.3. Timeout of Transmit Transaction Commitment 3062 The FSP node MUST abort the connection if the time of no packet 3063 having arrived has exceed certain limit in the COMMITTING or 3064 COMMITTING2 state. 3066 In this FSP version, timeout of transmit transaction commitment is 3067 set to 5 minutes. 3069 12.4. Timeout of Graceful Shutdown 3071 It simply migrates to the NON_EXISTENT pseudo-state if timeout in the 3072 PRE_CLOSED state. 3074 In this FSP version, timeout of Graceful Shutdown is set to 1 minute. 3076 12.5. Idle Timeout 3078 If one participant has not received any packet nor has it sent any 3079 packet in some limit time, it MUST be abruptly closed. 3081 In this FSP version the time limit, or the idle timeout, is set to 4 3082 hours. 3084 12.6. Session Key Timeout 3086 For this FSP version if a secret key is applied for more than 2^30 3087 times the FSP node MUST abruptly closed instantly. 3089 12.7. Abrupt Close 3091 An FSP node abruptly shutdown a session by sending a RESET packet and 3092 release all of the resource occupied by the the session immediately. 3094 (RESET, Reason of Failure, SN, ExpectedSN, ICC) 3096 13. Issues for Further Study 3098 13.1. Resolution of ULTID in DNS 3100 There are two patterns of IP address resolution in FSP: the DNS- 3101 compatible pattern and the proxy pattern. The former pattern relies 3102 on some name service to resolve the IP address of the responder for 3103 the initiator before they exchange end-to-end negotiation packets. 3105 In the DNS-compatible pattern, the responder side of the FSP 3106 participants registered its address identifier, such as 'domain name' 3107 in some name service such as DNS [RFC1034][RFC1035], according to 3108 some pre-agreement at first. The initiator resolves the current IP 3109 address of the responder by consulting the name service, such as 3110 looking after the A or AAAA record [RFC3596] of the domain name in 3111 DNS. 3113 If UDP over IPv4 is exploited as the under layer data packet delivery 3114 service the port number of the responder is firstly resolved just 3115 alike normal network application such as HTTP. Then it is extended 3116 to 32-bit ULTID, and ULTIDs of FSP can be considered as the superset 3117 of TCP port numbers. 3119 If the string representation of IPv4/IPv6 address is applied directly 3120 as the peer's address identifier instead of the domain name there is 3121 no need for some real address resolution. But from the API caller's 3122 point of view it is a DNS-compatible mode address resolution. 3124 13.2. Proxy Pattern for Syndicated Name Resolution 3126 The proxy pattern of IP address resolution in FSP is to embed the 3127 address resolution information in the connection initialization 3128 packets and is designed to work in FSP over IPv6 mode only. 3130 In IPv6 network the rightmost 32 bits of the IPv6 address directly 3131 maps to the ULTID so FSP does not need additional multiplexing 3132 mechanism such as port number. And it needs not consult SRV record 3133 or look for some entry in some 'services' file. 3135 If the INIT_CONNECT packet carries the responder's host name it MUST 3136 take the link-local interface address as the source IPv6 address and 3137 the default link-local gateway address, FE80::1, as the destination 3138 IPv6 address no matter whether the global unicast IP address of the 3139 default gateway is configured. In such scenario the link-local 3140 gateway MUST be able to resolute the responder's host name to its 3141 global unicast IPv6 address, and the gateway MUST be able to map the 3142 initiator's link local address to its global unicast IPv6 address. 3144 If the gateway that relays the INIT_CONNECT packet finds that the 3145 responder is on the same link-local network with the initiator it 3146 SHALL change the source and the destination IP addresses of the 3147 INIT_CONNECT packet to the link-local IP addresses of the initiator 3148 and the responder respectively, and relay the packet onto the same 3149 link-local network. 3151 On receiving the INIT_CONNECT packet that carries the responder's 3152 host name the link-local gateway MUST resolute the responder's global 3153 unicast IPv6 address and map the initiator's global unicast IPv6 3154 address, and replace the destination and source address of the 3155 INIT_CONNECT packet respectively, unless it finds that the initiator 3156 and the responder are on the same link-local network, where the 3157 gateway SHALL process the packet as stated in the previous statement. 3159 13.3. Asymmetric Transmission 3161 If there is one participant whose receive interface is not the same 3162 as the send interface the participant is called an asymmetric- 3163 transmission node. 3165 Asymmetric transmission itself is asymmetric in the sense that one 3166 participant may be asymmetric-transmission node while its peer is a 3167 normal node that the send interface is the same receive interface. 3169 An end node is asymmetric-transmission if it received an 3170 ACK_CONNECT_REQ packet, NULCOMMIT or PERSIST packet whose source IP 3171 address that the network interface accepting the packets reported is 3172 not in the allowed IP address list in the Sink Parameter header of 3173 the packet. 3175 For an asymmetric-transmission remote end, the near end cannot rely 3176 on automatic IP address change detection. Instead IP address change 3177 notification mechanism shall be utilized. 3179 However for this version of FSP asymmetric transmission support is 3180 optional. 3182 14. Security Considerations 3184 14.1. Deny of Service Attack 3186 FSP is designed to mitigate effect of DoS attack by exploiting Cookie 3187 . 3189 However, resistance against distributed DoS attack relies on external 3190 mechanism such as Distributed-Denial-of-Service Open Threat Signaling 3191 [I-D.ietf-dots-architecture]. 3193 14.2. Replay Attack 3195 In-band sequence number and out-of-band sequence number are exploited 3196 to resist against replay attack. 3198 14.3. Passive Attacks 3200 AEAD MAY be exploited by the ULA to protect it against passive 3201 attacks such as eavesdropping, gaining advantage by analyzing the 3202 data sent. 3204 MAC only service MAY also be utilized. Together with application 3205 layer stream-mode encryption it protects the ULA against passive 3206 attacks as well. 3208 14.4. Masquerade Attack 3210 Both AEAD and MAC only service may be exploited to protect the 3211 endpoints against masquerade attack. 3213 If proxy pattern for syndicated name resolution is exploited for FSP 3214 over IPv6, secure neighbor discovery [RFC3971] SHOULD be applied 3215 instead of common neighbor discovery whenever it is feasible. 3217 14.5. Active Man-In-The-Middle Attack 3219 The ULA SHALL take account to protect itself against MITM attack when 3220 making client authentication and key establishment. 3222 14.6. Privacy Concerns 3224 It is beneficial for privacy protection that the ULTID of each 3225 endpoints of an FSP connection is generated randomly [RFC7721]. 3227 15. IANA Considerations 3229 It should be requested that the port number registered for UDP 3230 packets encapsulating FSP in the IPv4 network. The port number 18003 3231 is exploited in the concept prototype implementation. The number is 3232 the decimal presentation of ASCII codes of the character 'F' ('x46') 3233 and 'S' ('x53') concatenated in network byte order. 3235 It should be requested that the 'Next Header'/protocol number is 3236 assigned for FSP over IPv6. Decimal number 144 is exploited in the 3237 concept prototype implementation. 3239 16. References 3241 16.1. Normative References 3243 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 3245 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 3246 Cartridges - DLT1 Format Standard, Annex B", December 3247 1992. 3249 [LZ4] , . 3251 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 3252 Galois/Counter Mode (GCM) and GMAC", November 2007. 3254 [OSI/RM] ISO and IEC, "Information technology-Open Systems 3255 Interconnection - Basic Reference Model: The Basic Model", 3256 ISO/IEC 7498-1 Second edition, November 1994. 3258 [R01] Rogaway, P., "Authenticated encryption with Associated- 3259 Data", ACM Conference on Computer and Communication 3260 Security (CCS'02), pp. 98-107, ACM Press, 2002. 3262 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3263 August 1980. 3265 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3266 Communication Layers", STD 3, RFC 1122, 3267 DOI 10.17487/RFC1122, October 1989, 3268 . 3270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3271 Requirement Levels", BCP 14, RFC 2119, 3272 DOI 10.17487/RFC2119, March 1997, 3273 . 3275 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 3276 RFC 3124, DOI 10.17487/RFC3124, June 2001, 3277 . 3279 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3280 of Explicit Congestion Notification (ECN) to IP", 3281 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3282 . 3284 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3285 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 3286 2003, . 3288 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3289 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3290 2006, . 3292 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3293 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 3294 December 2005, . 3296 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 3297 Key Derivation Function (HKDF)", RFC 5869, 3298 DOI 10.17487/RFC5869, May 2010, 3299 . 3301 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 3302 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 3303 DOI 10.17487/RFC6887, April 2013, 3304 . 3306 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 3307 Cryptographic Hash and Message Authentication Code (MAC)", 3308 RFC 7693, DOI 10.17487/RFC7693, November 2015, 3309 . 3311 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 3312 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 3313 March 2017, . 3315 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3316 (IPv6) Specification", STD 86, RFC 8200, 3317 DOI 10.17487/RFC8200, July 2017, 3318 . 3320 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 3321 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 3322 . 3324 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 3325 1981. 3327 [STD7] Postel, J., "Transmission Control Protocol", STD 7, 3328 RFC 793, September 1981. 3330 16.2. Informative References 3332 [I-D.ietf-dots-architecture] 3333 Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and 3334 R. Compton, "Distributed-Denial-of-Service Open Threat 3335 Signaling (DOTS) Architecture", draft-ietf-dots- 3336 architecture-18 (work in progress), March 2020. 3338 [Gao2002] Gao, J., "Fuzzy-layering and its suggestion", IETF Mail 3339 Archive, September 2002, 3340 . 3343 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 3344 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 3345 . 3347 [RFC1035] Mockapetris, P., "Domain names - implementation and 3348 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3349 November 1987, . 3351 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3352 Address Translator (Traditional NAT)", RFC 3022, 3353 DOI 10.17487/RFC3022, January 2001, 3354 . 3356 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 3357 "DNS Extensions to Support IP Version 6", STD 88, 3358 RFC 3596, DOI 10.17487/RFC3596, October 2003, 3359 . 3361 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 3362 "SEcure Neighbor Discovery (SEND)", RFC 3971, 3363 DOI 10.17487/RFC3971, March 2005, 3364 . 3366 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3367 "Randomness Requirements for Security", BCP 106, RFC 4086, 3368 DOI 10.17487/RFC4086, June 2005, 3369 . 3371 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 3372 (GCM) in IPsec Encapsulating Security Payload (ESP)", 3373 RFC 4106, DOI 10.17487/RFC4106, June 2005, 3374 . 3376 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 3377 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 3378 . 3380 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3381 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3382 DOI 10.17487/RFC4861, September 2007, 3383 . 3385 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3386 Address Autoconfiguration", RFC 4862, 3387 DOI 10.17487/RFC4862, September 2007, 3388 . 3390 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 3391 Model: The Relationship between Links and Subnet 3392 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 3393 . 3395 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 3396 Assignment to End Sites", BCP 157, RFC 6177, 3397 DOI 10.17487/RFC6177, March 2011, 3398 . 3400 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3401 "Computing TCP's Retransmission Timer", RFC 6298, 3402 DOI 10.17487/RFC6298, June 2011, 3403 . 3405 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 3406 the IPv6 Prefix Used for IPv6 Address Synthesis", 3407 RFC 7050, DOI 10.17487/RFC7050, November 2013, 3408 . 3410 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 3411 Considerations for IPv6 Address Generation Mechanisms", 3412 RFC 7721, DOI 10.17487/RFC7721, March 2016, 3413 . 3415 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 3416 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 3417 . 3419 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3420 Writing an IANA Considerations Section in RFCs", BCP 26, 3421 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3422 . 3424 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 3425 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 3426 May 2017, . 3428 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 3429 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 3430 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3431 RFC 8415, DOI 10.17487/RFC8415, November 2018, 3432 . 3434 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 3435 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 3436 January 2019, . 3438 [tcpcrypt] 3439 Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D. 3440 Boneh, "The case for ubiquitous transport-level 3441 encryption", USENIX Security , 2010. 3443 Appendix A. Acknowledgements 3445 Author's Address 3447 Jun-an Gao 3448 Beijing Capital Highway Development Group Co.,Ltd. 3449 Shoufa Plaza-A, Liuliqiao South, Fengtai 3450 Beijing 3451 People's Republic of China 3453 Email: jagao@outlook.com