idnits 2.17.1 draft-gao-flexible-session-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: An FSP connection MAY be multiplied to get a branch or branches of the connection. In this version of FSP a branch connection MAY NOT be multiplied further, and only the connection where authenticity of the packets is cryptographically protected may be multiplied. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: RELEASE 11 Release the connection RELEASE packet MAY NOT carry payload but it always consumes a slot of the send sequence space. Only when each peer has committed the transmit transaction may a RELEASE packet sent under the request of the ULA. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The participant in COMMITTING state MAY NOT transmit further data until current transmit transaction commitment is acknowledged. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The participant in COMMITTING2 state MAY NOT transmit further data until current transmit transaction commitment is acknowledged. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In case 1 the responder is ready to accept the connection. It MUST not make state transition on receiving INIT_CONNECT packet. It just generates a cookie which is meant to be echoed back by the initiator. The responder MUST send the ACK_INIT_CONNECT packet with the new allocated local ULTID instead of the original listening ULTID. The initiator should be able to find out the original listening ULTID by searching its own connection context. -- The document date (July 15, 2018) is 2102 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3629' is defined on line 2635, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 2639, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 2831, but no explicit reference was found in the text == Unused Reference: 'STD6' is defined on line 2674, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 2687, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 2696, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 2700, but no explicit reference was found in the text == Unused Reference: 'RFC1644' is defined on line 2704, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 2708, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 2713, but no explicit reference was found in the text == Unused Reference: 'RFC3055' is defined on line 2718, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 2723, but no explicit reference was found in the text == Unused Reference: 'RFC3344' is defined on line 2733, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 2737, but no explicit reference was found in the text == Unused Reference: 'RFC3720' is defined on line 2747, but no explicit reference was found in the text == Unused Reference: 'RFC3828' is defined on line 2752, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 2757, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 2762, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 2767, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 2772, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 2777, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 2781, but no explicit reference was found in the text == Unused Reference: 'RFC4388' is defined on line 2785, but no explicit reference was found in the text == Unused Reference: 'RFC4422' is defined on line 2790, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 2799, but no explicit reference was found in the text == Unused Reference: 'RFC4960' is defined on line 2809, but no explicit reference was found in the text == Unused Reference: 'RFC5056' is defined on line 2813, but no explicit reference was found in the text == Unused Reference: 'RFC5061' is defined on line 2817, but no explicit reference was found in the text == Unused Reference: 'RFC5072' is defined on line 2823, but no explicit reference was found in the text == Unused Reference: 'RFC5116' is defined on line 2827, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 2836, but no explicit reference was found in the text == Unused Reference: 'RFC5889' is defined on line 2841, but no explicit reference was found in the text == Unused Reference: 'RFC5942' is defined on line 2845, but no explicit reference was found in the text == Unused Reference: 'RFC6177' is defined on line 2850, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 2855, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 2859, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 2863, but no explicit reference was found in the text == Unused Reference: 'RFC6740' is defined on line 2867, but no explicit reference was found in the text == Unused Reference: 'RFC6824' is defined on line 2872, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 2877, but no explicit reference was found in the text == Unused Reference: 'RFC7050' is defined on line 2882, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 2887, but no explicit reference was found in the text == Unused Reference: 'RFC7228' is defined on line 2892, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 2897, but no explicit reference was found in the text == Unused Reference: 'RFC7540' is defined on line 2902, but no explicit reference was found in the text == Unused Reference: 'RFC7608' is defined on line 2907, but no explicit reference was found in the text == Unused Reference: 'RFC7849' is defined on line 2917, but no explicit reference was found in the text == Unused Reference: 'RFC8084' is defined on line 2923, but no explicit reference was found in the text == Unused Reference: 'RFC8085' is defined on line 2927, but no explicit reference was found in the text == Unused Reference: 'RFC8087' is defined on line 2931, but no explicit reference was found in the text == Unused Reference: 'RFC8170' is defined on line 2936, but no explicit reference was found in the text == Unused Reference: 'I-D.ila-mobility' is defined on line 2940, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 2947, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 793 (ref. 'STD7') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1644 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 Summary: 3 errors (**), 0 flaws (~~), 60 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Gao 3 Intended Status: Experimental 4 Expires: January 16, 2019 July 15, 2018 6 Flexible Session Protocol 7 draft-gao-flexible-session-protocol-00 9 Abstract 11 FSP is a connection-oriented transport layer protocol that provides 12 support for mobility, multi-homing and multi-path by introducing the 13 concept of 'upper layer thread ID'. 15 It introduces the concept of transmit transaction to facilitate a 16 quad-party sub-protocol of shared secret installation. 18 It provides transport layer features of zero round-trip connection 19 multiplication and on-the-wire compression, in addition to ubiquitous 20 message authentication with optional encryption service. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 5 63 2.2. Abbreviations and Idioms . . . . . . . . . . . . . . . . . 6 64 3. Key Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1. Underlying Layer Services Required . . . . . . . . . . . . 8 66 3.1.1. High Mobility . . . . . . . . . . . . . . . . . . . . . 8 67 3.1.2. Packet Delivery . . . . . . . . . . . . . . . . . . . . 8 68 3.1.3. Network Address Change Notification . . . . . . . . . . 9 69 3.1.4. Network Congestion Control . . . . . . . . . . . . . . 9 70 3.2. Identifying Connection by Local ULTID . . . . . . . . . . . 9 71 3.3. Defending Against Connection Redirection with ICC . . . . . 10 72 3.4. Transmit Transaction . . . . . . . . . . . . . . . . . . . 10 73 3.5. Quad-party Session Key Installation Sub-protocol . . . . . 10 74 3.6. Zero Round-Trip Connection Multiplication . . . . . . . . . 12 75 4. Packet Structure . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. FSP over UDP/IPv4 . . . . . . . . . . . . . . . . . . . . . 12 77 4.2. FSP over IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.3. Generic FSP Header . . . . . . . . . . . . . . . . . . . . 15 79 4.4. FSP Header Signature . . . . . . . . . . . . . . . . . . . 15 80 4.4.1 Header Stack Pointer . . . . . . . . . . . . . . . . . . 15 81 4.4.2 Major . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 4.4.3 Operation Code . . . . . . . . . . . . . . . . . . . . . 16 83 4.5. Preliminary FSP Packets . . . . . . . . . . . . . . . . . . 18 84 4.5.1. Connect Initialization . . . . . . . . . . . . . . . . 18 85 4.5.2. Acknowledgment to Connect Initialization . . . . . . . 19 86 4.5.3. Connect Request . . . . . . . . . . . . . . . . . . . . 20 87 4.6. Normal Fixed Header . . . . . . . . . . . . . . . . . . . . 21 88 4.7. Sink Parameter . . . . . . . . . . . . . . . . . . . . . . 23 89 4.8. Selective Negative Acknowledgment . . . . . . . . . . . . . 24 90 4.9. RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 5. The Finite Set of States . . . . . . . . . . . . . . . . . . . 27 92 5.0. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 27 93 5.1. NON_EXISTENT . . . . . . . . . . . . . . . . . . . . . . . 27 94 5.2. LISTENING . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 5.3. CONNECT_BOOTSTRAP . . . . . . . . . . . . . . . . . . . . . 28 96 5.4. CHALLENGING . . . . . . . . . . . . . . . . . . . . . . . . 28 97 5.5. CONNECT_AFFIRMING . . . . . . . . . . . . . . . . . . . . . 28 98 5.6. ACTIVE{A.K.A. ESTABLISHED} . . . . . . . . . . . . . . . . 29 99 5.7. COMMITTING . . . . . . . . . . . . . . . . . . . . . . . . 29 100 5.8. PEER_COMMIT . . . . . . . . . . . . . . . . . . . . . . . . 30 101 5.9. COMMITTING2 . . . . . . . . . . . . . . . . . . . . . . . . 30 102 5.10 COMMITTED . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 5.11 CLOSABLE . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 5.12 PRE_CLOSED . . . . . . . . . . . . . . . . . . . . . . . . 32 105 5.13 CLOSED . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 5.14 CLONING . . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 6. End-to-End Negotiation . . . . . . . . . . . . . . . . . . . . 33 108 6.1. Connect Initialization . . . . . . . . . . . . . . . . . . 33 109 6.2. Response to Connect Initialization . . . . . . . . . . . . 33 110 6.3. Weak Key Agreement Request . . . . . . . . . . . . . . . . 34 111 6.4. Weak Key Agreement Response . . . . . . . . . . . . . . . . 35 112 6.5. The Last Confirmation . . . . . . . . . . . . . . . . . . . 35 113 6.6. Retransmission . . . . . . . . . . . . . . . . . . . . . . 36 114 7. Quad-party Session Key Installation . . . . . . . . . . . . . 36 115 7.1. API for Session Key Installation . . . . . . . . . . . . . 36 116 7.2. Time to Call API for Session Key Installation . . . . . . . 37 117 7.3. Time to Take New Session Key into Effect . . . . . . . . . 37 118 7.4. Generating the Initial Session Key . . . . . . . . . . . . 38 119 7.5. Internal Rekeying . . . . . . . . . . . . . . . . . . . . . 39 120 8. Send and Receive . . . . . . . . . . . . . . . . . . . . . . . 39 121 8.1. Packet Integrity Protection . . . . . . . . . . . . . . . . 39 122 8.1.1. Application of CRC64 . . . . . . . . . . . . . . . . . 39 123 8.1.2. Packet Authentication Only . . . . . . . . . . . . . . 40 124 8.1.3. Authenticated Encryption with Additional Data . . . . . 40 125 8.2. Start a New Transmit Transaction . . . . . . . . . . . . . 42 126 8.3. Send a Pure Data Packet . . . . . . . . . . . . . . . . . . 42 127 8.4. Commit a Transmit Transaction . . . . . . . . . . . . . . . 42 128 8.4.1. Initiate Transmit Transaction Commitment . . . . . . . 42 129 8.4.2. Respond to Transmit Transaction Commitment . . . . . . 42 130 8.4.3. Finalize Transmit Transaction Commitment . . . . . . . 42 131 8.4.4. Time-out for Committing Transmit Transaction . . . . . 43 132 8.5. Retransmission . . . . . . . . . . . . . . . . . . . . . . 43 133 8.5.1. Calculation of RTT . . . . . . . . . . . . . . . . . . 43 134 8.5.2. Generation and transmission of SNACK . . . . . . . . . 43 135 8.5.3. Negative acknowledgment of Packets Sent . . . . . . . . 44 136 8.6. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 44 137 8.7. On-the-Wire Compression . . . . . . . . . . . . . . . . . . 45 138 9. Graceful Shutdown . . . . . . . . . . . . . . . . . . . . . . 45 139 9.1. Initiation of Graceful Shutdown . . . . . . . . . . . . . . 45 140 9.2. Acknowledgment of Graceful Shutdown . . . . . . . . . . . . 45 141 9.3. Finalization of Graceful Shutdown . . . . . . . . . . . . . 46 142 9.4. Retransmission of RELEASE Packet . . . . . . . . . . . . . 46 143 10 Mobility and Multi-home Support . . . . . . . . . . . . . . . 46 144 10.1. Heartbeat Signals . . . . . . . . . . . . . . . . . . . . 46 145 10.2. Active Address Change Signaling . . . . . . . . . . . . . 47 146 10.3. Heuristic Remote Address Change Adaptation . . . . . . . . 47 147 10.4. Heuristic Address Change Acknowledgement . . . . . . . . . 47 148 10.5. Explicit Multi-home Informing . . . . . . . . . . . . . . 48 149 11 Connection Multiplication . . . . . . . . . . . . . . . . . . 48 150 11.1. Request to Multiply Connection . . . . . . . . . . . . . . 48 151 11.2. Response to Connection Multiplication Request . . . . . . 48 152 11.3. Duplicate Detection of Connection Multiplication Request . 49 153 11.4. Retransmission . . . . . . . . . . . . . . . . . . . . . . 50 154 11.5. Key Derivation for Branch Connection . . . . . . . . . . . 50 155 12 Timeouts and Abrupt Close . . . . . . . . . . . . . . . . . . 50 156 12.1. Timeouts in End-to-End Negotiation . . . . . . . . . . . . 50 157 12.2. Timeouts in Multiply . . . . . . . . . . . . . . . . . . . 51 158 12.3. Timeout of Transmit Transaction Commitment . . . . . . . . 51 159 12.4. Timeout of Graceful Shutdown . . . . . . . . . . . . . . . 51 160 12.5. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . . 51 161 12.6. Session Key Timeout . . . . . . . . . . . . . . . . . . . 51 162 12.7. Abrupt Close . . . . . . . . . . . . . . . . . . . . . . . 52 163 13 Issues for Further Study . . . . . . . . . . . . . . . . . . . 52 164 13.1. Milk-type Payload and Minimal Delay Service . . . . . . . 52 165 13.2. Resolution of ULTID in DNS . . . . . . . . . . . . . . . . 52 166 13.3. Optimizing FSP towards IPv6 . . . . . . . . . . . . . . . 53 167 13.4. Binding End-to-End Negotiation with Resource Reservation . 54 168 13.5. Path Selection and PMTU . . . . . . . . . . . . . . . . . 54 169 13.6. Host-Aggregated Congestion Control . . . . . . . . . . . . 54 170 13.7. Asymmetric Transmission . . . . . . . . . . . . . . . . . 54 171 13.8. Connection Resurrection . . . . . . . . . . . . . . . . . 55 172 13.9. Architectural evolutions to transit towards IPv6 . . . . . 55 173 14 Security Considerations . . . . . . . . . . . . . . . . . . . 56 174 14.1. Resistance against Deny of Service Attack . . . . . . . . 56 175 14.2. Resistance against Replay Attack . . . . . . . . . . . . . 56 176 14.3. Resistance against Passive Attacks . . . . . . . . . . . . 56 177 14.4. Resistance against Masquerade Attack . . . . . . . . . . . 56 178 14.5. Resistance against Active Man-In-The-Middle Attack . . . . 56 179 14.6. Privacy concerns . . . . . . . . . . . . . . . . . . . . . 56 180 15 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 181 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 182 16.1. Normative References . . . . . . . . . . . . . . . . . . . 57 183 16.2. Informative References . . . . . . . . . . . . . . . . . . 58 184 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 185 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 187 1. Introduction 189 Flexible Session Protocol is a connection-oriented transport layer 190 provides mobility, multi-homing and multi-path support by introducing 191 the concept of 'upper layer thread ID' (ULTID), which was firstly 192 suggested in [Gao2002]. 194 An integrity check code (ICC) field associated with the ULTID is 195 designed in the FSP header to protect authenticity and optionally 196 privacy of the FSP packet. An FSP packet is assumed to originate from 197 the same source if the ICC value associated with certain destination 198 ULTID passes validation, regardless of the source or destination 199 address in the underlying layer. 201 ICC is either calculated by [CRC64] which protects FSP against 202 unintended modification, or a cryptographic hash function, or 203 cryptographically calculated with some Authenticated Encryption with 204 Additional Data ([R01]) algorithm, each of which requires a shared 205 secret key. 207 In the former case a weak key meant to obfuscate the CRC64 checksum 208 is agreed by the FSP participants. In the latter two cases, the 209 shared secret key is assumed to be installed by the upper layer 210 application (ULA). 212 The ULTID is assigned roughly the same semantics with Security 213 Parameter Index (SPI) in MOBIKE [RFC4555]. Either the weak key or the 214 shared secret key is indexed by the source or destination ULTID in 215 the local context of the sender or the receiver, respectively. 217 FSP facilitates secret key installation by introducing the concept of 218 transmit transaction. Mechanism of transmit transaction also provides 219 the session-connection synchronization service to the upper layer. 221 FSP is a transport layer protocol as specified in [RFC1122], provides 222 services alike TCP [STD5] to ULA, with session layer features as 223 suggested in [OSI/RM], most noticeably session-connection 224 synchronization. It can be argued that FSP makes it much more 225 flexible for the application layer protocols to adopt new key 226 establishment protocol/algorithm while offloading routine 227 authentication and optionally encryption of the data to the 228 underlying layers where it may be much easier to exploit hardware- 229 acceleration. 231 2. Conventions and Definitions 233 2.1. Requirements Language 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in RFC 2119 [RFC2119]. 238 In this document, these words will appear with that interpretation 239 only when in ALL CAPS. Lower case uses of these words are not to be 240 interpreted as carrying significance described in RFC 2119. 242 2.2. Abbreviations and Idioms 244 o Connection 245 An FSP connection is the binding of two network nodes established 246 through some end-to-end negotiation process. It is identified by 247 the ULTID in the local context of each network node, respectively. 249 o EoT 250 A transmit transaction is said to reach End of Transaction (EoT) if 251 the EoT flag is set in a legitimate PURE_DATA, PERSIST or MULTIPLY 252 packet. We said that the packet terminates the transmit transaction 253 if the EoT flag is set. 255 An ACK_START packet both starts and marks end of a payload-less 256 transmit transaction. 258 In this version of FSP an ACK_CONNECT_REQ packet itself marks end 259 of the singular transmit transaction. 261 An FSP end node may not send further data if it has initiated EoT 262 of its transmit direction unless a particular ACK_FLUSH packet is 263 received. The particular AKC_FLUSH packet MUST acknowledge not only 264 the packet with the EoT flag set but all of the packets sent 265 before the packet as well. 267 EoT, i.e. termination of transmit transaction is unilateral. 269 o FREWS 270 It stands for the Flag and advertised REceive Window Size. It is 271 the 32-bit combined word next to the ICC field in the normal FSP 272 fixed header. 274 o ICC 275 The Identity Check Code is a 64-bit value that depends on both the 276 session key and all of the headers of the FSP packet to include the 277 ICC, calculated with the same algorithm in the context of each FSP 278 participant. 280 Only a packet with correct ICC can be accepted by any FSP 281 participant as soon as the connection has been established. 283 Initially CRC64 is exploited to make a checksum that weekly 284 protects the FSP packet against unintentional modification. The 285 checksum is obfuscated with the initial session key to get the ICC. 286 After the ULA installed the long-term session key either some 287 cryptographic hash function or some Authenticated Encryption with 288 Additional Data algorithm shall be applied to obtain or check the 289 ICC. 291 o Session 292 An FSP session is the transport-layer association of two network 293 nodes. A full FSP session consists of one connection that was 294 established from scratch and all of its branches. 296 However for this version of FSP specification the idioms session 297 and connection are interchangeable if not explicitly specified. 299 o Session Key 300 The session key is a bit string of at least 128 bits that means to 301 resist against masquerade attack. It is either initiated during the 302 end-to-end negotiation phase or installed by the ULA after the FSP 303 connection is established. 305 The session key installed by the ULA is called the long-term 306 session key. Here long-term means that the key could be used until 307 the packet sequence space is exhausted. The packet sequence space 308 is exhausted if the number of packets that use the same key reaches 309 or exceeds 2,147,483,647(2^31-1). 311 o SN 312 Sequence Number is the unsigned 32-bit integer number assigned to 313 every FSP packet except the preliminary packets. 315 Difference of two sequence number is represented by a 32-bit signed 316 integer. If the result of SN B subtracting SN A is greater than 317 zero, we say that B is greater than A and the packet of the 318 sequence number B is later than the packet of the sequence number 319 A, although the unsigned integer representation of B may be far 320 less that A. Consequently, as the result of A subtracting B is less 321 than zero, we say that A is less than B and the packet of the 322 sequence number A is earlier than the packet of the sequence number 323 A. 325 o Transmit Transaction 326 A transmit transaction of FSP is a sequence of FSP packets that 327 were sent and marked by the ULA as one continuous stream where all 328 packets in the stream must be acknowledged before any further 329 packet is allowed to be sent. 331 A PERSIST or MULTIPLY packet always starts a transmit transaction. 333 An ACK_START packet both starts and marks end of a payload-less 334 transmit transaction. 336 For this version of FSP an ACK_CONNECT_REQ packet itself makes a 337 singular particular transmit transaction. 339 o ULA 340 The Upper Layer Application. 342 o ULTID 343 The Upper Layer Thread Identifier (ULTID) is a 32-bit word that was 344 allocated by particular network end node of an FSP connection and 345 is unique in the local context of the network end node. 347 Theoretically all of the ULAs of a network end node MAY establish 348 up to 2^31-1 FSP connections totally. Each connection MUST have a 349 unique thread identifier (ULTID) assigned in the local context of 350 the network end node. 352 A session or connection of FSP does not require a global ID. 354 3. Key Mechanisms 356 3.1. Underlying Layer Services Required 358 3.1.1. High Mobility 360 Here high mobility refers to scenarios such as high-speed train or 361 airplane. 363 FSP solves somewhat coarse-grain or low-speed mobility problem. Fine- 364 grain or high-speed mobility is left to the underlying physical 365 network, which is semantics specified in [RFC1122]. To make mobility 366 support work effectively it is assumed that one end-node MUST keep 367 its lower layer address reasonably stable while the other end-node 368 SHOULD NOT change its lower layer address too frequently. 370 It is supposed that the packet to inform the remote end to update the 371 lower layer address association could reach its destination in a 372 satisfying success rate. 374 3.1.2. Packet Delivery 376 FSP requires that the underlying layer provides packet delivery 377 service. 379 In this version of FSP, when FSP is implemented in the IPv4 network, 380 every FSP packet MUST be encapsulated in a UDP datagram. 382 When FSP is implemented over IPv6, the FSP SHALL be the immediate 383 upper layer of IPv6 [RFC8200]. 385 3.1.3. Network Address Change Notification 387 Network address change notification is mandatory only in the IPv6 388 network. 390 We split the IPv6 address of the IPv6 packet underlying FSP into 391 three parts. The leftmost 64-bit long word is the network prefix, 392 which SHOULD be the unique IPv6 prefix assigned to the host 393 [RFC8273]. The centermost 32-bit word is called the aggregation host 394 ID, and the rightmost 32-bit word is the ULTID. While the ULTID MUST 395 be kept stable even during the life of an FSP session, the network 396 prefix part MAY change when an endpoint is roaming. The aggregation 397 host ID may change as well. The network prefix part together with the 398 aggregation host ID part act as the traditional routing locator at 399 the network layer. 401 It is supposed that the network layer immediately notify FSP of the 402 network prefix and/or aggregation host ID change. 404 An participant of an FSP connection SHALL immediately notify its peer 405 whenever its underlying IPv6 address is changed with a KEEP_ALIVE 406 packet. The peer shall send packet to the participant that has 407 notified the address change with the new address. 409 3.1.4. Network Congestion Control 411 It is supposed that end-to-end congestion control is provided at some 412 sub-layer of the network layer. However for initial versions of FSP 413 it is not expected that such sub-layer exists. Instead a TCP-friendly 414 congestion control algorithm embedded in the FSP implementation is 415 required. 417 3.2. Identifying Connection by Local ULTID 419 Each FSP connection prepares a pair of ULTIDs. ULTID is assigned 420 roughly the same semantics with the Security Parameter Index (SPI) in 421 IKE [RFC4301]. An ULTID uniquely indexes a connection in the local 422 context of an FSP end node. An FSP end node relies neither source IP 423 address nor destination IP address, except the ULTID part of the near 424 end's IPv6 address to identify an FSP connection. 426 Each ULTID is allocated in the local context of the two FSP 427 participant respectively. The source ULTID and the destination ULTID 428 of an FSP packet usually differ in their values. However, the secret 429 keys indexed in the local contexts of the two end-points must have 430 the same value. 432 3.3. Defending Against Connection Redirection with ICC 434 An integrity check code (ICC) field associated with the ULTID is 435 designed in the FSP header to protect authenticity and optionally 436 privacy of the FSP packet. An FSP packet is assumed to originate from 437 the same source if the ICC value associated with certain destination 438 ULTID passes validation, regardless of the source or destination 439 address in the underlying layer. 441 On initiating FSP takes use of [CRC64] to make checksum of the FSP 442 packet to protect it against unintentional modification. The checksum 443 is taken as the ICC. 445 After the ULA has installed a shared secret key, value of ICC is 446 calculated by firstly getting the secret key associated indexed by 447 the local ULTID, then calculating the tag value with the AES-GCM 448 [GCM] authenticated encryption with additional data algorithm [R01], 449 or calculating the message authentication code with the BLAKE2 450 algorithm [RFC7693]. 452 3.4. Transmit Transaction 454 FSP facilitates shared secret key installation by introducing the 455 concept of transmit transaction. 457 A transmit transaction of FSP is a sequence of FSP packets that were 458 sent and marked by ULA as one continuous stream where all packets in 459 the stream MUST be acknowledged before any further packet is allowed 460 to be sent. 462 A flag called 'End of Transaction' (EoT) is designed in the FSP 463 header. When it is set, it marks that the transmit transaction in the 464 direction from the source of the FSP packet towards the destination 465 of the FSP packet is committed. 467 3.5. Quad-party Session Key Installation Sub-protocol 469 It is proposed that it is the ULA to do key establishment and/or end- 470 point user-agent authentication while the FSP layer provides 471 authenticated, optionally encrypted data transfer service. It is 472 arguably much more flexible for the application layer protocols to 473 adopt new key establishment algorithm while offloading routine 474 authentication and optionally encryption of the data to the 475 underlying layers where it may be much easier to exploit hardware- 476 acceleration. 478 A dedicate application program interface (API) is designed for the 479 ULA to install the secret key established by the ULA participants. 481 Protocol for installation of the shared secret key is quad-party in 482 the sense that both the upper layer application and the FSP layer of 483 the two participant nodes MUST agree on the moment of certain state 484 to install the shared secret key. 486 The ULA installs the new secret key to the FSP layer. The FSP layer 487 SHALL make it sure that the new secret key is taken into effect 488 starting from the very first packet of the transmit transaction that 489 is immediately next to the transmit transaction where API for 490 installation of the new secret key is called. 492 By committing a transmit transaction a ULA participant clearly tells 493 the underlying FSP layer that the next packet sent MAY adopt a new 494 secret key. On receiving a packet with the EoT flag set the ULA is 495 informed that the next packet received MAY adopt a new shared secret 496 key. 498 The ULA participant that installs the new secret key firstly MUST be 499 the one that is committing a transmit transaction after it has 500 accepted peer's transmit transaction commitment. 502 After the ULA install a new secret key every packet sent later than 503 the one with the EoT flag set MUST adopt the new secret key. The peer 504 MUST have commit a transmit transaction and it SHALL install the same 505 secret key on receiving the FSP packet with the EoT flag set. 507 The ULA SHOULD have installed the new shared secret key, or install 508 it instantly after accepting the packet with the EoT flag set. 510 If the new secret key has ever been installed the packet received 511 after the one with the EoT flag set MUST adopt the new secret key. 513 In a typical scenario the ULA endpoints first setup the FSP 514 connection where resistance against connection redirection is weakly 515 enforced by CRC64. After the pair of ULA endpoints establish a shared 516 secret key, they install the secret key and commit current transmit 517 transactions. Authenticity of the FSP packets sent later is 518 cryptographically protected by the new secret key and resistance 519 against various attacks is secured. 521 Although transmit transaction is actually uni-directional the secret 522 key is shared bi-directionally in this version of FSP. 524 3.6. Zero Round-Trip Connection Multiplication 526 An FSP connection MAY be multiplied to get a branch or branches of 527 the connection. In this version of FSP a branch connection MAY NOT be 528 multiplied further, and only the connection where authenticity of the 529 packets is cryptographically protected may be multiplied. 531 The packet that carries the command to multiply an established FSP 532 connection MUST be sent from a new allocated local ULTID towards the 533 destination ULTID of the original connection. It is an out-of-band 534 packet in the context of the original connection and it MUST be 535 cryptographically protected by the secret key of the original 536 connection. The packet MAY carry payload. 538 The receiver of the packet MUST allocate a new local ULTID, accept 539 the optional payload in the new context associated with the new 540 ULTID, derive a new secret key from the secret key of the original 541 connection, and responds from the new context. The response MAY carry 542 payload. 544 The very first response packet MUST be protected by the new secret 545 key. The sender of the multiply command packet MUST automatically 546 inaugurate the same secret key, derived from the secret key of the 547 same original connection. And it MUST treat the response packet as 548 though a transmit transaction had been committed by the responder, 549 i.e. authenticity of the response packet is verified with the new 550 secret key. 552 Thus the branch connection of a new pair of ULTIDs is established 553 with zero round-trip overhead. This mechanism may be exploited to 554 provide expedited data transfer or parallel data transfer service. 556 4. Packet Structure 558 4.1. FSP over UDP/IPv4 560 In this version of FSP, when FSP is implemented in the IPv4 network, 561 every FSP packet MUST be encapsulated in a UDP datagram. The UDP 562 datagram encapsulated the FSP packet SHALL have the checksum 563 disabled. The Source and the destination ULTIDs are put at the 564 leading position of the UDP payload. FSP fixed header, optional 565 extension headers and FSP payload follow the ULTIDs: 567 0 15 16 31 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Source Port | Destination Port | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Length | 0 | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Source Upper Layer Thread ID | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Destination Upper Layer Thread ID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 ~ FSP Fix Header ~ 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 ~ Optional FSP Extension Headers ~ 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 ~ ~ 584 ~ Optional FSP payload ~ 585 ~ ~ 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 1 FSP over UDP 590 4.2. FSP over IPv6 592 When FSP is implemented over IPv6, the ULTID part is embedded in the 593 IPv6 address. FSP fixed header follows the IPv6 headers: 595 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 596 ~ IPv6 Header: ~ 597 0 15 16 31 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |Version| Traffic Class | Flow Label | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Payload Length | Next Header | Hop Limit | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | 604 + Source Network Prefix + 605 | | 606 + Source Address ----------------------------+ 607 | Source Aggregation Host ID | 608 + ----------------------------+ 609 | Source Upper Layer Thread ID | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | 612 + Destination Network Prefix + 613 | | 614 + Destination Address ---------------------------------+ 615 | Destination Aggregation Host ID | 616 + ---------------------------------+ 617 | Destination Upper Layer Thread ID | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 ~ ~ 620 ~ Optional IPv6 Headers ~ 621 ~ ~ 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | 624 ~ FSP Fix Header ~ 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 ~ Optional FSP Extension Headers ~ 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 ~ ~ 630 ~ Optional FSP payload ~ 631 ~ ~ 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 2 FSP over IPv6 636 o Network Prefix 637 The leftmost 64-bit of the IPv6 address which MAY and usually do 638 have different value at the difference interface of an IPv6 end- 639 node. 641 o Aggregation Host ID 642 The left 32-bit part of the rightmost 64-bit long word of the IPv6 643 address. All of the aggregation host ID parts of an IPv6 end-node's 644 IPv6 addresses MUST have the same value for this version of FSP. 646 4.3. Generic FSP Header 648 FSP headers include the fixed header and the extension headers. A 649 general fixed header consists of 20-byte operation-code specific 650 fields and a 32-bit FSP Header Signature. An extension header 651 consists an operation-code specific content and a 32-bit FSP Header 652 Signature. The length of the extension header content may be 653 variable, provided that the tail of the full extension header align 654 on 64-bit boundary. 656 0 31 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 ~ ~ 659 ~ Operation Code Specific Fields ~ 660 ~ ~ 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Header Signature | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Figure 3 FSP Header 667 4.4. FSP Header Signature 669 0 15 16 31 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Header Stack Pointer | Major | Operation Code| 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 4 FSP Header Signature 676 4.4.1 Header Stack Pointer 678 For the fixed header the header stack pointer is a 16-bit unsigned 679 integer that specifies the offset of the first octet of the payload. 681 For an extension header the header stack pointer is a 16-bit unsigned 682 integer that specifies the offset of the first octet of the very 683 extension header. 685 The offset that the header stack pointer specifies starts from the 686 begin of the FSP fixed header. If its value is 24 the header contains 687 it is the last extension header or the fix header without any 688 extension. 690 4.4.2 Major 691 It is an octet states current FSP major version. For this FSP version 692 it MUST be 0. 694 It is NOT mandatory for different major versions of FSP to be 695 compatible. 697 4.4.3 Operation Code 699 It is an octet that stores the code of the command which indicates 700 the function of the packet. 702 Synonym Code Meaning 704 INIT_CONNECT 1 Initialize Connection 706 ACK_INIT_CONNECT 2 Acknowledge Initialization of Connection 708 CONNECT_REQUEST 3 Formally Request to Connect 710 ACK_CONNECT_REQ 4 Acknowledge the Connection Request 712 RESET 5 Reset a connection 713 Refuse to 714 establish the connection, or abort 715 connection. 716 ACK_START 6 ACKnowledgement to start a connection 717 It is the acknowledgement to 718 ACK_CONNECT_REQ or MULTIPLY, to confirm 719 that the connection has been established 720 or multiplied. It MUST be payload-less, 721 and its EoT flag is always assumed to be 722 set. It MAY carry optional headers. It 723 always consumes a slot of the send 724 sequence space. It is supposed to both 725 start and commit a payload-less transmit 726 transaction which SHALL be skipped. 728 KEEP_ALIVE 7 Keep the peer alive 729 It is an out-of-band control packet 730 acting as the heart-beating signal. An 731 out-of-band control packet does not 732 consume send sequence space itself. FSP 733 takes use of the KEEP_ALIVE packet to 734 inform the peer about the change of the 735 source IP addresses. Besides, when the 736 MIND flag is set, the KEEP_ALIVE packet 737 is meant to tell the peer which packets 738 should be retransmitted. If the End of 739 Transaction flag of the KEEP_ ALIVE 740 packet is set it is meant to forcefully 741 commit current transmit transaction of 742 the sender of the KEEP_ALIVE packet. 744 PERSIST 8 Make a connection persistent 745 It is meant to start a new transmit 746 transaction after a connection migrated 747 to CLOSABLE state. It can also 748 acknowledge ACK_CONNECT_REQ or MULTIPLY. 749 It MUST either carry payload, or get the 750 EoT flag set with or without payload. It 751 always consumes a slot of the send 752 sequence space. 754 PURE_DATA 9 Pure Data 755 It does not carry any optional header. 757 ACK_FLUSH 10 ACKnowledge to remote end's commitment 758 (FLUSHing) of transmit transaction. It 759 is an out-of-band control packet like 760 KEEP_ALIVE. It is sent instantly on 761 having every packet of the last transmit 762 transaction received, meant to make 763 acknowledgment to the remote end and let 764 the remote end stop sending heart-beat 765 signals. If the End of Transaction flag 766 of the ACK_FLUSH packet is set it is 767 meant to commit current transmit 768 transaction of the sender of the 769 ACK_FLUSH packet as well. 771 RELEASE 11 Release the connection 772 RELEASE packet MAY NOT carry payload but 773 it always consumes a slot of the send 774 sequence space. Only when each peer has 775 committed the transmit transaction may a 776 RELEASE packet sent under the request of 777 the ULA. 779 MULTIPLY 12 Multiply the connection 780 It is sent in the context of the 781 original connection and may carry 782 payload and/or optional headers as an 783 out-of-band packet. 785 PEER_SUBNETS 17 Tell the remote end how to address 786 the sender of the packet in the reverse 787 direction. It is the code of the Sink 788 Parameter extension header. 790 SELECTIVE_NACK 18 Tell the remote end to retransmit 791 the packets that were negatively 792 acknowledged. It is the code of the 793 Selective Negative Acknowledgment 794 extension header. 796 4.5. Preliminary FSP Packets 798 Preliminary FSP packets are the packets exchanged during the end-to- 799 end negotiation phase of FSP connection establishment when it is 800 impossible to calculate ICC normally. 802 4.5.1. Connect Initialization 804 0 31 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | | 807 + Timestamp + 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | | 811 + Init-Check-Code + 812 | | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Salt | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Header Signature | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 ~ ~ 819 ~ Host Name of the Responder (optional) ~ 820 ~ ~ 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Figure 5 Connect Initialization 825 Operation Code of this type of packet is INIT_CONNECT. 827 o Timestamp 828 It is a 64-bit unsigned integer that represents number of 829 microseconds elapsed since 00:00, Jan.1, 1970, Coordinated 830 Universal Time. It may be exploited to synchronize the clocks of 831 the participants and/or estimate delay during data transmission in 832 the network. 834 o Init-Check-Code 835 It is a 64-bit random bit string that means to uniquely associated 836 with the connection initiated. 838 o Salt 839 It a 32-bit random bit string that may be exploited to make secret 840 key agreement. 842 o Host Name of the Responder 843 The optional payload of the Connect Initialization packet. 845 4.5.2. Acknowledgment to Connect Initialization 847 0 31 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | | 850 + Cookie + 851 | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | | 854 + Init-Check-Code + 855 | | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Time Delta | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Header Signature | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Figure 6 Acknowledgment to Connect Initialization 864 Operation Code of this type of packet is ACK_INIT_CONNECT. 866 o Cookie 867 It is a 64-bit bit string cryptographically generated by the 868 responder in a represent-transfer state manner. More specifically 869 when the same timestamp, time delta, Init-Check-Code, salt, source 870 and destination ULTIDs are sent to the responder, the responder 871 MUST be able to generate the identical cookie value. 873 o Init-Check-Code 874 It MUST be identical to the corresponding field in the Connect 875 Initialization packet acknowledged. 877 o Time Delta 878 It is a 32-bit signed integer which is the difference between the 879 near-end's time and the timestamp value sent in the Connection 880 Initialization packet. The units and the epoch of the near-end's 881 time value and the timestamp value MUST be the same. However, the 882 precision or resolution of the time delta value is chosen 883 arbitrarily by the responder. 885 4.5.3. Connect Request 887 0 31 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | | 890 + Time Stamp + 891 | | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | | 894 + Init-Check-Code + 895 | | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Salt | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Header Signature | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Initial Sequence Number | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Time Delta | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | 906 + Cookie + 907 | | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 ~ ~ 910 ~ Sink Parameter ~ 911 ~ ~ 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 ~ ~ 914 ~ Host Name of the Initiator (optional) ~ 915 ~ ~ 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Figure 7 Connect Request 920 Operation Code of this type of packet is CONNECT_REQUEST. 922 The value of each field that has the identical name with the one in 923 the associated Connect Initialization and Acknowledgment to Connect 924 Initialization packet MUST be assigned the same value as in these two 925 packets, except header signature in the packet. 927 o Sink Parameter 928 It is an extension header specified in 4.7. 930 o Host Name of the Initiator 931 It is optional and is stored in the payload part of the Connect 932 Request packet. It could be exploited by the responder to look up 933 the address of the initiator that may receive packets in the 934 reverse direction. 936 4.6. Normal Fixed Header 938 0 15 16 31 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Sequence Number | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Expected Sequence Number | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | | 945 + Integrity Check Code + 946 | | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Flags | Advertised Receive Window Size | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Header Signature | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Figure 8 FSP Fixed Header 955 Operation Code of a normal fixed header may be ACK_CONNECT_REQUEST, 956 PURE_DATA, PERSIST, KEEP_ALIVE, ACK_FLUSH, RELEASE or MULTIPLY. 958 o Sequence Number 959 Each in-band FSP packet is assigned a 32-bit unsigned integer as 960 the sequence number. The sequence number assigned for in-band FSP 961 packets MUST be in strict order. 963 An out-of-band packet that has the operation code of KEEP_ALIVE, 964 ACK_FLUSH or MULTIPLY MUST be assigned a sequence number that falls 965 in the receive window. 967 o Expected Sequence Number 968 It stores the earliest sequence number of the packets that were not 969 yet received in the receive window of the sender. It is an 970 accumulative acknowledgment. Any packet with the sequence number 971 before the received Expected Sequence Number is supposed to have 972 been received by the remote end. 974 o Integrity Check Code 975 The ICC. 977 o Flags 978 It is bit-field of width 8. From left to right: 980 - End of Transaction(EoT): 981 If the EoT flag of a packet is set, it is the last packet of a 982 transmit transaction. A packet with the EoT flag set MAY be the 983 start and the single packet of the transmit transaction as well. 985 - Minimal-Delay (MIND): 986 If the MIND flag of the Connect Request or Acknowledgment to 987 Connect Request packet is set, the ULA prefers minimal delay and 988 is willing to tolerate packet loss. FSP SHALL drop the packet 989 received earliest when there is no enough receive buffer so that 990 the latest packet received can be saved and the delay to deliver 991 data to ULA is minimized. 993 If the MIND flag has been set the EoT flag of any following 994 packet is simply ignored. 996 Payload of each FSP packet is delivered to the ULA as an 997 independent message if the MIND flag has been set. 999 - HMAC: 1000 If the HMAC flag of a packet is set the cryptographic hash 1001 algorithm SHALL be applied to get the message authentication code 1002 of the whole packet. Each FSP version MUST designate one 1003 particular cryptographic hash algorithm. 1005 - Explicit Congestion Notification(ECN): 1006 Currently yet to be studied. 1008 The remaining 4 bits are reserved. 1010 o Advertised Receive Window Size 1011 It is a 20-bit unsigned integer that stores number of the free 1012 blocks in the receive buffer of the sender of the packet that 1013 contains the receive window size field. It is count from the slot 1014 meant to accept the packet with the expected sequence number. 1016 The sender must ensure that the difference between the latest 1017 sequence number sent out and the largest expected sequence number 1018 received does not exceed the value of the latest advertised receive 1019 window size received. 1021 4.7. Sink Parameter 1023 0 31 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 ~ ~ 1026 ~ Addressable Network Prefixes ~ 1027 ~ ~ 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Listener ID/Host ID | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Header Signature | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Figure 9 Sink Parameter 1036 Operation Code in the Header Signature of this extension header is 1037 PEER_SUBNETS. 1039 o Addressable Network Prefixes 1040 These are up to 4 64-bit words that specify the network prefixes of 1041 the lower layer interfaces that are addressable by the receiver in 1042 the reverse direction. 1044 In this version of the FSP 'Addressable Network Prefixes' field is 1045 of fixed length. The last network prefix which is non-zero is the 1046 last resort one. There MUST be at least one non-zero network 1047 prefix. If there are more than one non-zero network prefixes those 1048 other than the last resort are load-balanced preferred. 1050 In an IPv6 network, the addressable network prefix is the leftmost 1051 64 bits of the IPv6 address. The receiver of the Addressable 1052 Network Prefixes SHALL send packet in the reverse direction, i.e. 1053 to the sender of the field with the destination IPv6 address 1054 generated by combining a preferred network prefix with the 1055 aggregation host id and the ULTID part of the source address in the 1056 IPv6 header of the received packet that eventually carries the 1057 Addressable Network Prefixes. 1059 Such feature MAY be exploited to handle links with unidirectional 1060 connectivity, but it is NOT RECOMMENTED. 1062 In an IPv4 network for compatibility with the IPv6 addressed ULA 1063 the 64-bit word of the addressable network prefix specified is 1064 composed as following Figure: 1066 0 15 16 31 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | 0x2002 (IPv6 6to4 prefix) |IPv4 address (leftmost 16 bits)| 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 |IPv4 address(rightmost 16 bits)| UDP port number (16 bits) | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 Figure 10 Addressable Network Prefix of FSP over UDP/IPv4 1075 Sender of the Sink Parameter packet SHOULD be NAT-aware. If it is 1076 able to obtain the from the NAT box [TODO: definition, phrase 1077 RFC1631] via protocol UPnP[RFC6970]SHOULD fill in the IPv4 address 1078 and UDP port number fields with the public IP value that were 1079 obtained. If it does not have such capability, it SHALL fill in the 1080 addressable network prefix with all binary zeroes. 1082 o Listener ID 1083 It is the ULTID of the responder that is in LISTENING state. 1085 o Host ID 1086 It is the aggregation host id of the sender. It SHALL be 0 if it is 1087 in the IPv4 network. 1089 4.8. Selective Negative Acknowledgment 1091 0 31 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Gap Width | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Data Length | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 ~ ~ 1098 ~ Further pairs of (Gap Width, Data Length) ~ 1099 ~ ~ 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | | 1102 + Acknowledgement Delay + 1103 | | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Out-band Serial Number | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Header Signature | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Figure 11 Selective Negative Acknowledgment 1112 The operation code of this type of extension header is SNACK. The 1113 SNACK header contains the descriptor of the receive window gaps: 1115 The descriptor itself is a list of entries. The length of the list 1116 can be zero which means that there is no gap in the receive window. 1117 If the list is not empty, each entry contains the width of one gap in 1118 the receive window and the length of the continuously received data 1119 following the gap, respectively. The unit of aforementioned length of 1120 gaps or number of packets is buffer block. 1122 o Acknowledgement Delay 1123 A 64-bit unsigned integer specifies the delay in microseconds 1124 between sending the packet containing the SNACK extension header 1125 and accepting the last packet that is accumulatively acknowledged 1126 by the SNACK extension header. 1128 o Out-band Serial Number 1129 The SNACK header contains a 32-bit out-band serial number as well. 1130 Each time a packet that contains the SNACK header is sent the out- 1131 band serial number shall increase by one. It is assumed that in the 1132 life of the session no two packets have the same sequence number 1133 and the same SNACK header serial number simultaneously. 1135 4.9. RESET 1137 The 'RESET' packet is a special command packet meant to interrupt 1138 connection setup process or disconnect abruptly. Operation Code of 1139 the packet is RESET. 1141 Structure of a RESET packet in C code snippet with unnamed union 1142 applied: 1144 struct FSP_RejectConnect 1145 { 1146 /* sequence numbers */ 1147 union 1148 { 1149 timestamp_t timeStamp; 1150 struct 1151 { 1152 uint32_t initial; 1153 uint32_t expected; 1154 } sn; 1155 }; 1156 /* uniqueness proof */ 1157 union 1158 { 1159 uint64_t integrityCode; 1160 uint64_t cookie; 1161 uint64_t initCheckCode; 1162 }; 1163 /* bit field to describe reasons for reset */ 1164 uint32_t reasons; 1165 $FSP_HeaderSignature hs; 1166 }; 1168 When the RESET packet is the response to a Connect Initialization 1169 packet both the timeStamp and the initCheckCode fields of the RESET 1170 packet MUST be set to the same values of Time Stamp and Init-Check- 1171 Code in the Connect Initialization packet, respectively. 1173 When the RESET packet is the response to a Connect Request packet 1174 both the timeStamp and the cookie fields of the RESET packet MUST be 1175 set to the same value of Time Stamp and Cookie in the Connect Request 1176 packet, respectively. 1178 When the RESET packet is the response to a packet with a normal fixed 1179 header, the sn.initial, the sn.expected and the integrityCode of the 1180 RESET packet MUST be set as to specification of normal fixed header 1181 field Sequence Number, Expected Sequence Number and Integrity Check 1182 Code, respectively. 1184 5. The Finite Set of States 1186 5.0. Conventions 1188 ESTABLISHED The string of alphabetic characters designates the 1189 name of the state 1191 [API: Reset] Upper Layer Application Programming Interface Call 1193 {Notify} Call back/notify the upper layer application 1195 {new context} Additional action before or after state transition 1197 [Send OPCODE_OF_FSP_PACKET] 1198 Send some FSP packet 1200 [Retransmit OPCODE_OF_FSP_PACKET] 1201 Retransmit some FSP packet 1203 {On transient state Timeout} 1204 Timed-out event 1206 {&& additional condition} 1207 Together with some additional condition 1209 --> state transition 1211 |-- branch 1213 5.1. NON_EXISTENT 1214 ---[API: Listen]-->LISTENING 1215 |--[API: Connect]-->CONNECT_BOOTSTRAP-->[Send INIT_CONNECT] 1216 |--[API: Multiply]-->CLONING-->[Send MULTIPLY] 1218 NON_EXISTENT is a pseudo-state before a connection is created by 1219 the ULA calling API Listen, Connect or Multiply (or after a 1220 connection is reset). 1222 5.2. LISTENING 1223 ---[API: Reset]-->NON_EXISTENT 1224 |<-->[Rcv.INIT_CONNECT]{&& accepted}[Send ACK_INIT_CONNECT] 1225 |<-->[Rcv.INIT_CONNECT]{&& rejected}[Send RESET] 1226 |<-->[Rcv.CONNECT_REQUEST]{&& duplication detected} 1227 [Retransmit ACK_CONNECT_REQ] 1228 |--[Rcv.CONNECT_REQUEST]-->{Notify} 1229 |-->[API: Accept] 1230 -->{new context}CHALLENGING-->[Send ACK_CONNECT_REQ] 1231 |-->[API: Reject]-->[Send RESET] {abort new context, if any} 1233 LISTENING is a state entered by the ULA calling API Listen. 1235 5.3. CONNECT_BOOTSTRAP 1236 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1237 |--[Rcv.ACK_INIT_CONNECT]-->CONNECT_AFFIRMING 1238 |-->[Send CONNECT_REQUEST] 1239 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1240 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1241 |--{On retransmission Timeout}<-->[Retransmit INIT_CONNECT] 1243 CONNECT_BOOTSTRAP is a state entered by the ULA calling API 1244 Connect, before receiving the acknowledgement of the remote end to 1245 the connection initialization packet. 1247 5.4. CHALLENGING 1248 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1249 |<-->[API: Send{new data}]{just prebuffer} 1250 |--[Rcv.ACK_START]-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1251 |--[Rcv.PERSIST] 1252 |--{Not EOT}-->COMMITTED-->[Send SNACK]-->[Notify] 1253 |--{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1254 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1255 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1257 CHALLENGING is a state entered by the ULA accepting the connection 1258 request after a new connection context has been incarnated. The new 1259 connection is incarnated by the FSP context of the near end in the 1260 LISTENING state as a legitimate CONNECT_REQUEST packet is received. 1262 5.5. CONNECT_AFFIRMING 1263 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1264 |<-->[API: Send{new data}]{just prebuffer} 1265 |--[Rcv.ACK_CONNECT_REQ]-->PEER_COMMIT-->[Notifiy] 1266 |-->[API: Accept] 1267 |-->{Not EOT}-->[Send PERSIST] 1268 |-->{EOT}-->COMMITTING2-->[Send PERSIST with EoT] 1269 |-->[API: Reject]-->NON_EXISTENT-->[Send RESET] 1270 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1271 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1272 |--{On retransmission Timeout}<-->[Retransmit CONNECT_REQUEST] 1274 CONNECT_AFFIRMING is a state entered by the ULA affirming to send 1275 connect request after receiving the acknowledgement to the 1276 connection initialization packet. 1278 5.6. ACTIVE{A.K.A. ESTABLISHED} 1279 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1280 |--[API: Send{transact}]-->COMMITTING{Urge to Commit} 1281 |<-->[API: Send{more data}][Send PURE_DATA] 1282 |--[Rcv.PURE_DATA] 1283 |--{Not EOT}-->[Send SNACK]-->[Notify] 1284 |--{EOT} 1285 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1286 |--[Rcv.PERSIST] 1287 |--{Not EOT}-->[Send SNACK early] 1288 |--[EOT] 1289 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1290 |--[Rcv.EOT] 1291 |-->PEER_COMMIT-->[Send ACK_FLUSH]-->[Notify] 1292 |--[Rcv.MULTIPLY]{passive multiplication} 1293 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1294 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1296 ACTIVE or ESTABLISHED is a state that the FSP participant has 1297 finished end-to-end negotiation but has not committed current 1298 transmit transaction nor fully received the latest transmit 1299 transaction of the remote end. 1301 5.7. COMMITTING 1302 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1303 |--[Rcv.ACK_FLUSH]-->COMMITTED-->[Notify] 1304 |--[Rcv.PURE_DATA] 1305 |--{Not EOT}-->[Send SNACK]-->[Notify] 1306 |--{EOT}-->COMMITTING2-->[Send ACK_FLUSH]-->[Notify] 1307 |--[Rcv.MULTIPLY]{passive multiplication} 1308 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1309 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1311 COMMITTING is a state that the FSP participant has committed the 1312 transmit transaction but has not fully received the latest transmit 1313 transaction of the remote end, nor the acknowledgement to the 1314 transmit transaction commitment has been received. 1316 The participant in COMMITTING state MAY NOT transmit further data 1317 until current transmit transaction commitment is acknowledged. 1319 5.8. PEER_COMMIT 1320 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1321 |--[API: Send{flush}]-->COMMITTING2-->[Urge COMMIT] 1322 |<-->[API: Send{more data}][Send PURE_DATA] 1323 |<-->[Rcv.PURE_DATA]{just prebuffer} 1324 |<-->[Rcv.ACK_START]--[Send ACK_FLUSH] 1325 |--[Rcv.PERSIST] 1326 |-->{Not EOT}-->ACTIVE-->[Send SNACK] 1327 |<-->{EOT}--[Send ACK_FLUSH] 1328 |--{&& is new transaction}-->[Notify] 1329 |--[Rcv.EOT]-->[Send ACK_FLUSH]-->[Notify] 1330 |--[Rcv.MULTIPLY]{passive multiplication} 1331 |--[Rcv.RELEASE]-->CLOSED-->[Send ACK_FLUSH]-->[Notify] 1332 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1333 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1335 PEER_COMMIT is a state that the FSP participant has not committed 1336 current transmit transaction but has fully received the latest 1337 transmit transaction of the remote end, and the acknowledgement to 1338 the transmit transaction commitment has not been received yet. 1340 5.9. COMMITTING2 1341 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1342 |<-->[Rcv.PURE_DATA]{just prebuffer} 1343 |--[Rcv.ACK_FLUSH]-->CLOSABLE-->[Notify] 1344 |--[Rcv.PERSIST] 1345 |-->{Not EOT}-->COMMITTING-->[Send SNACK] 1346 |-->{EOT}-->{keep state}-->[Send ACK_FLUSH] 1347 |--{&& is a new transaction}-->[Notify] 1348 |--[Rcv.EOT]-->[Send ACK_FLUSH]-->[Notify] 1349 |--[Rcv.MULTIPLY]{passive multiplication} 1350 |--[Rcv.RELEASE]-->CLOSED-->[Send RELEASE]-->[Notify] 1351 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1352 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1354 COMMITTING2 is a state that the FSP participant has committed 1355 current transmit transaction and has fully received the latest 1356 transmit transaction of the remote end, but the acknowledgement to 1357 the transmit transaction commitment has not been received yet. 1359 The participant in COMMITTING2 state MAY NOT transmit further data 1360 until current transmit transaction commitment is acknowledged. 1362 5.10 COMMITTED 1363 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1364 |--[API: Send{more data}]-->ACTIVE-->[Send PERSIST] 1365 |--[API: Send{flush}]-->COMMITTING{Urge COMMIT} 1366 |--[Rcv.PURE_DATA] 1367 |-->{Not EOT}-->[Send SNACK]-->[Notify] 1368 |-->{EOT} 1369 |-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1370 |--[Rcv.PERSIST] 1371 |-->{Not EOT}-->[Send SNACK] 1372 |-->{EOT}-->CLOSABLE-->[Send ACK_FLUSH]-->[Notify] 1373 |--[Rcv.MULTIPLY]{passive multiplication} 1374 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1375 |--{On Idle Timeout}-->NON_EXISTENT-->[Notify] 1377 COMMITTED is a state that the FSP participant has committed current 1378 transmit transaction and has received the acknowledgement to the 1379 transmit transaction commitment, but has not fully received the 1380 latest transmit transaction of the remote end. 1382 5.11 CLOSABLE 1383 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1384 |--[API: Send{more data}]-->PEER_COMMIT-->[Send PERSIST] 1385 |--[API: Send{flush}]-->COMMITTING2-->[Urge COMMIT] 1386 |--[API: Shutdown]-->[Send RELEASE]-->PRE_CLOSED-->[Notify] 1387 |<-->[Rcv.PURE_DATA]{just prebuffer} 1388 |<-->[Rcv.ACK_START]--[Send ACK_FLUSH] 1389 |--[Rcv.PERSIST] 1390 |-->{Not EOT}-->COMMITTED-->[Send SNACK] 1391 |-->{EOT}-->{[Send ACK_FLUSH] 1392 |--{&& is a new transaction}-->[Notify] 1393 |--[Rcv.MULTIPLY]{passive multiplication} 1394 |--[Rcv.RELEASE]-->CLOSED-->[Notify] 1395 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1396 |--{On Idle Timeout}-->CLOSED 1397 |--{On session key Timeout}-->NON_EXISTENT 1399 CLOSABLE is a state that the FSP participant has committed current 1400 transmit transaction and has received the acknowledgement to the 1401 transmit transaction commitment, and has fully received the latest 1402 transmit transaction of the remote end. 1404 5.12 PRE_CLOSED 1405 ---[API: Reset]-->NON_EXISTENT-->[Send RESET] 1406 |--[Rcv.RELEASE]-->CLOSED-->[Send RELEASE]-->[Notify] 1407 |--{On retransmission Timeout}<-->[Retransmit RELEASE] 1408 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1410 PRE_CLOSED is a state entered by the ULA calling the API Shutdown 1411 in CLOSABLE state. 1413 5.13 CLOSED 1414 |--{On session key Timeout}-->NON_EXISTENT 1416 CLOSED is a state migrated from PRE_CLOSED state on receiving a 1417 legitimate RELEASE packet from the remote end. 1419 Unlike TCP [STD7], CLOSED state in FSP is not fictional. Instead a 1420 connection context MAY persist in CLOSED state until the session 1421 key runs out of life. A connection in CLOSED state MAY be 1422 resurrected. 1424 5.14 CLONING 1425 ---[API: Reset]-->NON_EXISTENT 1426 |<-->[API: Send{new data}]{just prebuffer} 1427 |<-->[Rcv.PURE_DATA]{just prebuffer} 1428 |--[Rcv.ACK_START] 1429 |--{&& Not ULA-flushing}-->PEER_COMMIT 1430 |-->[Send ACK_FLUSH]-->[Notify] 1431 |--{&& ULA-flushing}-->CLOSABLE 1432 |-->[Send ACK_FLUSH]-->[Notify] 1433 |--[Rcv.PERSIST] 1434 |-->{Not EOT} 1435 |--{&& Not ULA-flushing}-->ACTIVE 1436 |-->[Send SNACK]-->[Notify] 1437 |--{&& ULA-flushing}-->COMMITTED 1438 |-->[Send SNACK]-->[Notify] 1439 |-->{EOT} 1440 |--{&& Not ULA-flushing}-->PEER_COMMIT 1441 |-->[Send ACK_FLUSH]-->[Notify] 1442 |--{&& ULA-flushing}-->CLOSABLE 1443 |-->[Send ACK_FLUSH]-->[Notify] 1444 |--[Rcv.RESET]-->NON_EXISTENT-->[Notify] 1445 |--{On retransmission Timeout}<-->[Retransmit MULTIPLY] 1446 |--{On transient state Timeout}-->NON_EXISTENT-->[Notify] 1448 CLONING is a state entered by ULA calling the API Multiply from any 1449 state that may accepting an out-of-band packet. 1451 6. End-to-End Negotiation 1452 End-to-end negotiation of FSP session occurs in the connection 1453 establishment phase. Connection establishment process of FSP consists 1454 of two and a half pairs of packet exchanges for connection 1455 initialization, weak key agreement and the last confirmation. During 1456 the process various optional header or payload MAY be carried in the 1457 FSP preliminary packets to negotiate end-to-end session parameters. 1459 6.1. Connect Initialization 1461 The initiator sends the INIT_CONNECT packet to the responder: 1462 (INIT_CONNECT, Timestamp, Init-Check-Code, Salt [, Responder's Host 1463 Name]) 1465 Connection initialization MAY be syndicated with optional address 1466 resolution at the gateway in the IPv6 network by carrying the 1467 responder's host name in the Connect Initialization packet. 1469 If it does carry the responder's host name it MUST take the link- 1470 local interface address as the source IPv6 address and the default 1471 link-local gateway address, FE80::1 as the destination IPv6 address 1472 no matter whether the global unicast IP address of the default 1473 gateway is configured. In such scenario the link-local gateway MUST 1474 be able to resolute the responder's host name to its global unicast 1475 IPv6 address, and the gateway MUST be able to map the initiator's 1476 link local address to its global unicast IPv6 address. 1478 If the gateway that relays the INIT_CONNECT packet finds that the 1479 responder is on the same link-local network with the initiator it 1480 SHALL change the source and the destination IP addresses of the 1481 INIT_CONNECT packet to the link-local IP addresses of the initiator 1482 and the responder, respectively, and relay the packet onto the same 1483 link-local network. 1485 On receiving the FSP Connect Initialization packet that carries the 1486 responder's host name the link-local gateway MUST resolute the 1487 responder's global unicast IPv6 address and map the initiator's 1488 global unicast IPv6 address, and replace the destination and source 1489 address of the FSP Connect Initialization packet, respectively. 1491 The gateway SHALL silently ignore the FSP Connect Initialization 1492 packet that does not carry the responder's host name payload if the 1493 destination address is the default link-local gateway address, or if 1494 the gateway is unable to resolve the IP address of the responder. 1496 6.2. Response to Connect Initialization 1498 The responder sends acknowledgment to the initiator: 1500 Case 1: (ACK_INIT_CONNECT, Cookie, Echo of Init-Check-Code, Time- 1501 delta) 1503 Case 2: (RESET, Echo of Timestamp, Echo of Init-Check-Code, Reason of 1504 Failure) 1506 In case 1 the responder is ready to accept the connection. It MUST 1507 not make state transition on receiving INIT_CONNECT packet. It just 1508 generates a cookie which is meant to be echoed back by the initiator. 1509 The responder MUST send the ACK_INIT_CONNECT packet with the new 1510 allocated local ULTID instead of the original listening ULTID. The 1511 initiator should be able to find out the original listening ULTID by 1512 searching its own connection context. 1514 In case 2 the responder refuses to accept the connection. It SHALL 1515 send back a RESET packet with the listening ULTID as the source 1516 ULTID. 1518 In either case the destination address of the packet sent back MUST 1519 be set to the source address of the corresponding Connect 1520 Initialization packet whose source and destination address MAY be 1521 updated by some intermediary such as the link-local gateway of the 1522 initiator. 1524 6.3. Weak Key Agreement Request 1526 (CONNECT_REQUEST, Timestamp, Init-Check-Code, Salt, Echo of Cookie, 1527 Echo of Time-delta, Initial SN, Initiator's Sink Parameter [, 1528 Initiator's Host Name]) 1530 The initiator accepts the Response to Connect Initialization packet 1531 if and only if both the destination ULTID of the response packet 1532 matches the source ULTID of the connect initialization packet and the 1533 echo of the Init-Check-Code in the response packet matches the Init- 1534 Check-Code in the connect initialization packet. 1536 If the response packet is accepted the initiator formally requests to 1537 establish the connection by sending the CONECT_REQUEST packet. 1539 In the CONNECT_REQUEST packet the value of the Timestamp, the Init- 1540 Check-Code and the Salt field MUST be the same as in the INIT_CONNECT 1541 packet while the value of the Echo of Cookie field and the Echo of 1542 Time-delta field MUST be the same as in the ACK_INIT_ CONNECT packet, 1543 respectively. 1545 The initiator MUST send the packet towards the remote ULTID that the 1546 responder has preserved and sent with the ACK_INIT_CONNECT packet. It 1547 MUST fill the original listener ID field in the Initiator's Sink 1548 Parameter with the right value. 1550 The source address of the CONNECT_REQUEST packet MUST be set to the 1551 destination address of the received ACK_INIT_CONNECT packet, while 1552 the network prefix and host-id part of the destination address MUST 1553 be set to the source address of the received ACK_INIT_CONNECT packet 1554 in the IPv6 network. 1556 The initiator SHALL save the cookie value that the responder has 1557 given to make up the weak session key. 1559 The initiator MUST fill the Initial SN field with the sequence number 1560 of the packet that will follow CONNECT_REQUEST. The CONNECT_REQUEST 1561 packet is payload free and does not consume the sequence space. 1563 6.4. Weak Key Agreement Response 1565 Case 1: (ACK_CONNECT_REQ, Initial SN, Expected SN, Timestamp, FREWS, 1566 Responder's Sink Parameter[, Payload]) 1568 Case 2: (RESET, Echo of Timestamp, Echo of Echo of Cookie, Reason of 1569 Failure) The responder responds as in case 1 if the echo of cookie 1570 was valid, resources were successfully allocated and the initial 1571 context of the connection was setup. Otherwise it SHOULD respond as 1572 in case 2. 1574 The Initial SN in case 1 is the initial sequence number of the 1575 responder. The responder should fill in the field with a random 32- 1576 bit unsigned integer. As the ACK_CONNECT_REQ packet may carry payload 1577 the sequence number of the responder starts from the ACK_CONNECT_REQ 1578 packet. 1580 The Expected SN MUST equal to the Initial SN specified in the 1581 corresponding CONNECT_ REQUEST packet. In the Responder's Sink 1582 Parameter the original listener ULTID MUST be set to the right value. 1584 6.5. The Last Confirmation 1586 Case 1: (ACK_Start, Initial SN, Expected SN, ICC, FREWS[, Initiator's 1587 Sink Parameter]) 1589 Case 2: (PERSIST, Initial SN, Expected SN, ICC, FREWS, payload) 1591 Case 3: (RESET, Initial SN, Expected SN, ICC, Reason of Failure) 1593 The initiator of the connection MUST eventually confirm to the 1594 responder that the connection is established by sending a payload- 1595 less ACK_START packet (case 1) or a PERSIST packet with payload (case 1596 2). 1598 Of course the initiator MAY quit to establish the connection by 1599 sending a legitimate RESET packet (case 3). 1601 6.6. Retransmission 1603 The initiator SHALL retransmit the INIT_CONNECT packet if the 1604 corresponding ACK_INIT_CONNECT packet is not received in some limit 1605 time (by default 15 seconds). 1607 The initiator SHALL retransmit the CONNECT_CONNECT packet if the 1608 corresponding ACK_CONNECT_REQ packet is not received in some limit 1609 time (by default 15 seconds). 1611 The responder SHALL NOT retransmit ACK_INIT_CONNECT or 1612 ACK_CONNECT_REQ packet. 1614 The initiator SHOULD retransmit the right INIT_CONNECT packet or 1615 CONNECT_CONNECT packet until the legitimate ACK_CONNECT_REQ packet is 1616 eventually received. 1618 It SHALL give up if the time starting from the very first 1619 INIT_CONNECT packet was sent has exceed a longer timed-out value (by 1620 default 60 seconds) before the legitimate ACK_CONNECT_REQ packet is 1621 received. 1623 7. Quad-party Session Key Installation 1625 It assumes that in the scenarios applying FSP it is the ULA to do key 1626 establishment and/or end-point authentication while the FSP layer 1627 provides authenticated, optionally encrypted data transfer service. 1628 Together they establish a secure channel between two application end- 1629 points. 1631 Protocol for installation of the shared secret key is quad-party in 1632 the sense that both the upper layer application and the FSP layer of 1633 both the participant nodes MUST agree on the moment of certain state 1634 to install the shared secret key. 1636 It is arguably much more flexible for the application layer protocols 1637 to adopt new key establishment algorithm while offloading routine 1638 authentication and optionally encryption of the data to the 1639 underlying layers where it may be much easier to exploit hardware- 1640 acceleration. 1642 7.1. API for Session Key Installation 1643 A dedicate application program interface (API) is designed for the 1644 ULA to install the secret key established by the ULA participants. 1645 The API SHOULD take four parameters: 1647 - A 'handle' to state the connection context for installing the 1648 session key 1649 - A octet string of initial key materials (IKM) 1650 - An integer to state the length of IKM. The unit is octet. 1651 - An integer to state the desired length of the effective session key 1652 if AEAD is applied. The unit is bit. For this version of FSP desired 1653 length of the effective session key is either 128 or 256. 1655 7.2. Time to Call API for Session Key Installation 1657 The ULA participant that installs the new secret key firstly MUST be 1658 the one that is committing a transmit transaction after it has 1659 accepted peer's transmit transaction commitment. 1661 In a typical scenario the ULA endpoints first setup the FSP 1662 connection where resistance against connection redirection is weakly 1663 enforced by CRC64. 1665 After the pair of ULA endpoints establish a shared secret key, they 1666 install the secret key and commit current transmit transactions. 1667 Authenticity of the FSP packets sent later is cryptographically 1668 protected by the new secret key and resistance against various 1669 attacks is secured. 1671 7.3. Time to Take New Session Key into Effect 1673 The FSP layer SHALL make it sure that the new secret key is taken 1674 into effect starting from the very first packet of the transmit 1675 transaction that is next to the transmit transaction whose context is 1676 where the new secret key is installed. Although transmit transaction 1677 is actually uni-directional the secret key is shared bi-directionally 1678 in this version of FSP. 1680 By committing a transmit transaction a ULA participant clearly tells 1681 the underlying FSP layer that the next packet sent MAY adopt a new 1682 secret key. On receiving a packet with the EoT flag set the ULA is 1683 informed that the next packet received MAY adopt a new shared secret 1684 key. 1686 After the ULA install a new secret key every packet sent later than 1687 the one with the EoT flag set MUST adopt the new secret key. The peer 1688 MUST have commit a transmit transaction and it SHALL install the same 1689 secret key on receiving the FSP packet with the EoT flag set. 1691 The ULA SHOULD have installed the new shared secret key, or install 1692 it instantly after accepting the packet with the EoT flag set. If the 1693 new secret key has ever been installed the packet received after the 1694 one with the EoT flag set MUST adopt the new secret key. 1696 7.4. Generating the Initial Session Key 1698 Given raw key material ikm, length of the ikm nB in octets, intended 1699 master key length lenb in bits, || is octet string concatenation, 1701 If HMAC only is designated, the nB octets of ikm is hashed into 64 1702 octets which is taken as the master key. 1704 If AEAD is designated, the initial session key, or the first secret 1705 key for packet authentication and payload encryption is obtained as 1706 specified in [RFC5869]: 1708 Key Extract phase, 1710 Let Km = BLAKE2(zeros || ikm) , where 1712 zeros is 32 octets of integer 0 1714 BLAKE2b algorithm without key is applied. 1716 The result Km is the master key. 1718 Key Expand phase, 1720 Let Ks = BLAKE2(Km, info) , where 1722 Km is the master key generated in previous phase, 1724 info is concatenation of the arbitrary ASCII string "Establishes 1725 an FSP session", which is 26-octet long, 3 octets of integer 0, 1726 and 1 octet of integer 1. 1728 BLAKE2b algorithm with key is applied. The key applied MUST be the 1729 master key Km. 1731 The result Ks is the initial session key, or the first secret key 1732 for packet authentication and payload encryption. 1734 For this version FSP Ks is a fixed-length AES key together with a 1735 4-octet salt. The salt is meant to be passed to AES-GCM as the 1736 initialization vector together with the sequence number and 1737 expected sequence number fields in the normal FSP fixed header: 1739 0 31 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | Salt | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Sequence Number | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | Expected Sequence Number | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 Figure 12 Constitution of Initialization Vector 1750 7.5. Internal Rekeying 1752 In this version of FSP it is forced to re-key on sending or receiving 1753 every 536870912? (2^29) packets. 1755 Let Ks' = BLAKE2(Km, H || info') , where: 1757 Km is the master key generated as in section 7.4. 1759 H is the 16-octet internal hash sub-key of AES-GCM of previous 1760 session key, 1762 info' is concatenation of the arbitrary ASCII string "Sustains an 1763 FSP connection", which is 26-octet long 1764 and the 4 octets in network order of the 32-bit unsigned integer 1765 that specifies the batch index of the session key. 1767 BLAKE2b algorithm with key is applied. The key applied MUST be the 1768 master key Km. 1770 The result Ks' is the new session key, together with the new salt 1771 meant to be form the IV. 1773 The batch index of the initial session key is 1, and it is increased 1774 by 1 every time before it is to re-key. 1776 8. Send and Receive 1778 8.1. Packet Integrity Protection 1780 8.1.1. Application of CRC64 1782 Starting from ACK_CONNECT_REQUEST, until the ULAs have installed the 1783 shared secret CRC64 is applied to calculate the value of the ICC 1784 field. The algorithm: 1786 1.Take pair of the ULDs as the initial value of accumulative CRC64 1787 The pair of the ULDs is composed of the near end's ULTID and the 1788 remote end's ULTID, where the former is the leftmost 32 bits and 1789 the latter is the rightmost 32 bits of initial value for the send 1790 direction, and the order is reversed for the receive direction. 1792 2.Accumulate the value of the Init-Check-Code field 1794 3.Accumulate the value of the Cookie field successively 1796 4.Accumulate the combined value of the salt and the timeDelta field 1797 where the former is the leftmost 32 bits and the latter is the 1798 rightmost 32 bits 1800 5.Accumulate the value of the Time Stamp field 1802 6.Save the accumulated CRC64 value 1803 as the pre-computed CRC64 value. 1805 When calculate the value ICC of a particular FSP packet, firstly set 1806 ICC to the pre-computed CRC64 value, then calculate the CRC64 1807 checksum of the whole FSP packet, while ULTIDs are NOT included if 1808 the FSP packet is encapsulated in UDP. The result is set as the final 1809 value of the ICC field. 1811 8.1.2. Packet Authentication Only 1813 The ULA designates the FSP layer to either applying HMAC only or 1814 applying AEAD. 1816 If the HMAC flag of a packet is set the pre-designated cryptographic 1817 hash function SHALL be applied to get the message authentication code 1818 (MAC) of the whole packet. Each FSP version MUST designate one and 1819 only one particular cryptographic hash function. 1821 For this FSP version, BLAKE2 [RFC7693] is designated as the 1822 cryptographic hash function. The input key is the secret key that has 1823 been derived from the master key installed by the ULA. The input data 1824 is the full FSP packet, where the ICC field is pre-filled the pair of 1825 the ULDs. As in making CRC64 checksum, the pair of the ULDs is 1826 composed of the near end's ULTID and the remote end's ULTID, where 1827 the former is the leftmost 32 bits and the latter is the rightmost 32 1828 bits of initial value for the send direction, and the order is 1829 reversed for the receive direction. 1831 The hash result is truncated to 64 bits to get the final ICC. 1833 8.1.3. Authenticated Encryption with Additional Data 1834 FSP provides per-packet authenticated encryption service. Only one 1835 authenticated encryption algorithm is allowed for a determined 1836 version of FSP. For this FSP version, the authenticated encryption 1837 algorithm selected is GCM-AES [GCM][AES], it is applied to protect 1838 integrity of the full FSP packets and privacy of the payload. The 1839 length of the session key is determined by the ULA. The four inputs 1840 to GCM-AES authenticated encryption are: 1842 K: the key derived by the master key installed by ULA. 1844 IV: the initial vector, 96-bit string made by concatenating a 32-bit 1845 salt, the 32-bit sequence number of the packet and the 32-bit 1846 expected sequence number field of the packet. The salt is derived by 1847 the master key installed by ULA. 1849 P: the plaintext are the bytes following the fixed header up to the 1850 end of the original payload 1852 AAD: additional authenticated data, from the source ULTID to the last 1853 byte of the fixed header. The source ULTID is stored in the leftmost 1854 32-bit of the ICC field while the destination ULTID is stored in the 1855 rightmost 32-bit of the ICC field before the ICC value is calculated. 1856 The length of the authentication tag MUST be 64 bits for FSP version 1857 0 and 1. The authentication tag is stored in the ICC finally. The 1858 inputs to GCM-AES decryption are: 1860 K: the key installed by ULA. 1862 IV: the initial vector, 96-bit string made by concating consisted of 1863 the salt, the 32-bit sequence number of the packet and the 32-bit 1864 expected sequence number field of the packet. The internal 32-bit 1865 salt MUST be the XOR result of the leftmost two 32-bit words of the 1866 hash sub-key. 1868 C: the ciphertext are the bytes following the fixed header up to the 1869 end of the received payload 1871 AAD: additional authenticated data, from the source ULTID to the last 1872 byte of the fixed header. The source ULTID is stored in the leftmost 1873 32-bit of the ICC field while the destination ULTID is stored in the 1874 rightmost 32-bit of the ICC field before the ICC value is calculated 1876 T: The authentication tag, which is fetched from the ICC field 1877 received Only when the outputs of GCM-AES decryption tell that the 1878 authentication tag passed verification may the receiver deliver the 1879 decrypted payload to the ULA. 1881 8.2. Start a New Transmit Transaction 1883 The responder starts AND terminates a transmit transaction by send 1884 the ACK_CONNECT_REQ packet. 1886 The initiator starts a new transmit transaction by sending a PERSIST 1887 packet: 1889 (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload) 1891 Or starts AND terminates a transmit transaction by send the ACK_START 1892 packet: 1894 (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter]) 1896 8.3. Send a Pure Data Packet 1898 (PURE_DATA, SN, ExpectedSN, ICC, FREWS, Payload) 1900 After a new transmit transaction has been started further PURE_DATA 1901 packet MAY be sent until a packet with EoT flag set is sent. 1903 8.4. Commit a Transmit Transaction 1905 8.4.1. Initiate Transmit Transaction Commitment 1907 A participant of an FSP connection MAY notify its peer that a 1908 transmit transaction shall be committed by setting the EoT flag of 1909 the last packet of the transmit transaction, be it PERSIST, 1910 ACK_START, PURE_DATA or MULTIPLY. 1912 8.4.2. Respond to Transmit Transaction Commitment 1914 (ACK_FLUSH, SN, ExpectedSN, ICC, FREWS) 1916 If and only if all of the packets in a transmit transaction has been 1917 received MAY ACK_FLUSH packet be sent. 1919 Whenever a legitimate packet falls in the receive window of the 1920 receiver, and the packet fills in the last gap of the sequence of 1921 current transmit transaction on receiving direction, or the packet 1922 with same sequence number has been accepted already, a responding 1923 ACK_FLUSH SHALL be sent back immediately, and the FSP layer MUST 1924 immediately notify the ULA that a transmit transaction has been 1925 committed. 1927 8.4.3. Finalize Transmit Transaction Commitment 1928 After receiving the ACK_FLUSH packet the sender of the EoT flag 1929 migrates to the COMMITTED or CLOSABLE state from the COMMITTING or 1930 COMMITTING2 state, respectively. 1932 8.4.4. Time-out for Committing Transmit Transaction 1934 The ULA SHALL be timed-out if there is no packet was acknowledged in 1935 some hard-coded time-out. For this version of FSP the time-out is set 1936 to 30 seconds. 1938 8.5. Retransmission 1940 Any packet sent 4RTT earlier that is negatively acknowledged MUST be 1941 retransmitted as soon as possible. 1943 8.5.1. Calculation of RTT 1945 Initial RTT for the Connection Initiator: Equals to the mean of the 1946 time elapsed when ACK_ INIT_CONNECT was received since INIT_CONNECT 1947 was sent, and the time elapsed till ACK_CONNECT_REQ was received 1948 since CONNECT_REQUEST was sent. 1950 Initial RTT for the Connection Responder: Equals to the time elapsed 1951 when the ACK_START or the first PERSIST packet was received since 1952 ACK_CONNECT_REQ was sent. 1954 Initial RTT for the Initiator of Connection Multiplication: Equals to 1955 the time elapsed when the first PERSIST packet was received since 1956 MULTIPLY was sent. 1958 Initial RTT for the Responder of Connection Multiplication: Equals to 1959 the most recent RTT of the multiplied connection. 1961 Each time a SNACK or an accumulated acknowledgment is received the 1962 round trip time of the packet with most expected SN is calculated. 1963 The round trip time is the difference between the time when the 1964 KEEP_ALIVE packet that carried the acknowledgement was received and 1965 the time when the original packet was sent, minus the delay given in 1966 the SNACK optional header of the KEEP_ALIVE packet. Suppose the 1967 result is RTT_now, then: 1969 RTT_new = (RTT_old + RTT_now) / 2 1971 8.5.2. Generation and transmission of SNACK 1973 Whenever the receiver receives a packet it SHALL shift the time to 1974 send next heartbeat signal earlier to the time of RTT since current 1975 time, if the time to send next heartbeat signal used to be later. If 1976 the time is already earlier than the time of RTT since current time, 1977 it needs not be shifted. 1979 On the time to send the heartbeat signal the FSP node generates the 1980 SNACK header, then generate and send a new KEEP_ALIVE or ACK_FLUSH 1981 packet to carry the SNACK header. It SHALL send an ACK_FLUSH if it is 1982 in PEER_COMMIT, COMMITTING2 or CLOSABLE state, otherwise it SHALL 1983 send a KEEP_ALIVE packet. 1985 8.5.3. Negative acknowledgment of Packets Sent 1987 Both the ACK_FLUSH and the KEEP_ALIVE packet in FSP carry the SNACK 1988 extension header, although number of gap descriptors in the SNACK 1989 extension header in the ACK_FLUSH packet MUST be 0. We call them 1990 SNACK packets. A SNACK packet P1 is said to be later than P0, if and 1991 only if SN of P1 is later than SN of P0, or SN of P1 equals SN of P0 1992 while the out-of-band sequence number of P1 is later than the out-of- 1993 band sequence number of P0. If the latest SNACK packet is ACK_FLUSH, 1994 all the packets with the sequence number later that the expected 1995 field of the packet are assumed to be negatively acknowledged. 1997 By convention when we specify the range, the left square bracket 1998 meant to be inclusive, while the right parenthesis meant to be 1999 exclusive, the packets with SN in the ranges: 2000 [expectedSN, expectedSN + 1st Gap Width), 2002 [expectedSN + 1st Gap Width + 1st Data Length, 2003 expectedSN + 1st Gap Width + 1st DataLength + 2nd Gap Width), 2005 ... 2007 [expectedSN + 1st Gap Width + 1st Data Length 2008 + ... + (n-1)th Gap Width + (n-1)th Data Length, 2009 expectedSN + 1st Gap Width + 1st DataLength 2010 + ... + n-th Gap Width), 2012 together with the packets with SN later than {expectedSN + 1st Gap 2013 Width + 1st DataLength + ... + n-th Gap Width} are assumed to be 2014 negatively acknowledged, if the latest SNACK packet is KEEP_ALIVE. 2016 8.6. Flow Control 2018 The participants of an FSP connection negotiate the initial receive 2019 window size with the FREWS field in the ACK_CONNECT_REQUEST packet 2020 and the first PERSIST packet, respectively. The receive window size 2021 SHALL NOT be less than 4 and SHALL be less than 2^24. 2023 An FSP participant advertises the receive window size in the FREWS 2024 field. 2026 An FSP participant SHALL NOT send a packet whose sequence number is 2027 later than its peer's ExpectedSN plus its peer's advertised receive 2028 window size. 2030 8.7. On-the-Wire Compression 2031 (Application of LZ4) 2032 Stream-mode 2033 Segment length 2034 Per-transaction 2036 9. Graceful Shutdown 2038 One participant of an FSP connection MAY initiate graceful shutdown 2039 of the connection if and only if its peer has committed the most 2040 recent transmit transaction. 2042 By initiating graceful shutdown the participant tells its peer that 2043 current transmit transaction is to be committed as well. 2045 9.1. Initiation of Graceful Shutdown 2047 (RELEASE, SN, ExpectedSN, ICC, FREWS) 2049 An FSP end node MAY initiate graceful shutdown if the connection is 2050 in the PEER_COMMIT, COMMITTING2 or CLOSABLE state only. 2052 Graceful shutdown is signaled to the remote end by sending a RELEASE 2053 command packet. The FSP connection SHALL migrate to the PRE_CLOSED 2054 state just before sending the RELEASE packet. 2056 9.2. Acknowledgment of Graceful Shutdown 2058 (RELEASE, SN, ExpectedSN, ICC, FREWS) 2060 The RELEASE packet may be accepted in the COMMITTING, COMMITTED, 2061 COMMITTING2, CLOSABLE or PRE_CLOSED state only. 2063 If it is accepted in the COMMITTING, COMMITTED, COMMITTING2 state the 2064 sender's current transmit transaction is supposed to be committed. 2065 The receiver automatically migrates to the CLOSABLE state. The ULA 2066 SHALL be notified with such migration and it SHOULD process the 2067 committed transmit transaction as soon as possible. 2069 If the receiver of the RELEASE packet is in CLOSABLE state the ULA 2070 SHALL be notified with the connection shutdown request. 2072 In all of these cases a reverse RELEASE packet MUST be sent 2073 immediately after the original RELEASE packet is received. 2075 If the RELEASE packet is received in the PRE_CLOSED state it is 2076 supposed that the grace shutdown request is acknowledged. The 2077 connection SHALL migrate to CLOSED state immediately. 2079 9.3. Finalization of Graceful Shutdown 2081 If a legitimate RELEASE command packet is received in the COMMITTING, 2082 COMMITTED, COMMITTING2 or CLOSABLE state the receiver is passively 2083 shutdown, and the shutdown is finalized in the sense that it does not 2084 expect any acknowledgement of the reverse RELEASE packet required to 2085 be sent, although race condition may occur. 2087 The FSP node in the PRE_CLOSED state migrates to the CLOSED state 2088 after the corresponding RELEASE packet is received. It is supposed 2089 that the original grace shutdown request is acknowledged and the 2090 shutdown is finalized. 2092 Graceful shutdown in FSP is asymmetric in the sense that it does not 2093 require both ULA participants to call the Shutdown API. 2095 9.4. Retransmission of RELEASE Packet 2097 The FSP end node in the PRE_CLOSED state SHALL retransmit the RELEASE 2098 packet until it migrates to CLOSED state or it is timed out. Interval 2099 between the retransmission is hard-coded to 4 times of RTT. 2101 The RELEASE packet that was sent in the COMMITTING, COMMITTED, 2102 COMMITTING2 or CLOSABLE state state shall never be retransmitted. 2104 10 Mobility and Multi-home Support 2106 10.1. Heartbeat Signals 2108 FSP requires that the participants periodically send the heartbeat 2109 signals. 2111 The participant in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2112 COMMITING2 or CLOSABLE state MUST send the KEEP_ ALIVE packet as the 2113 heart-beat signal periodically to retain the connection in case that 2114 underlying IP address has changed. 2116 (KEEP_ALIVE, SN, ExpectedSN, ICC, FREWS, Sink Parameter, SNACK) 2118 Heartbeat signal is an out-of-band control packet. It does not carry 2119 payload. The sequence number of the KEEP_ALIVE packet SHALL be set to 2120 the latest sequence number of all of the packets that have been sent. 2122 Only the FSP node in the ACTIVE, COMMITTING, COMMITTED, PEER_COMMIT, 2123 COMMITING2 or CLOSABLE state MAY process the heartbeat signal. 2125 In this version of FSP the heat-beat period is arbitrarily set to 600 2126 seconds. 2128 10.2. Active Address Change Signaling 2130 During communication process the FSP participant whose underlying IP 2131 address is changed SHOULD inform its peer such change by transmit a 2132 KEEP_ALIVE packet with the Sink Parameter extension header and the 2133 SNACK header so that the peer can retransmit the packets that were 2134 negatively acknowledged. 2136 Such informing KEEP_ALIVE packet SHALL be sent in the ACTIVE, 2137 COMMITTING, COMMITTED, PEER_COMMIT, COMMITING2 or CLOSABLE state. 2139 Informing KEEP_ALIVE packet SHOULD be sent more frequently than a 2140 normal heart-beat signaling KEEP_ALIVE packet. 2142 For this version of FSP informing KEEP_ALIVE packet SHALL be 2143 retransmitted every 4 RTT interval until the heuristic 2144 acknowledgement is received. 2146 10.3. Heuristic Remote Address Change Adaptation 2148 A participant of the FSP connection SHALL set the source address of 2149 the packet to transmit or retransmit to new IP address as soon as the 2150 near-end IPv4 address or IPv6 network prefix has changed. The ULTID 2151 field MUST remain the same. 2153 When a new packet with a later sequence number is received and the 2154 source IP address of the packet is found to be different with the 2155 preserved IP address of the remote end, the receiver SHOULD 2156 automatically update the preserved IP address of the remote end to 2157 the source IP address of the new packet, unless there is a Sink 2158 Parameter header in the packet. 2160 If the sequence number of the packet received is not the latest in 2161 the receive window the preserved IP address of the remote end SHALL 2162 NOT be updated even if the source address of the received packet has 2163 changed. 2165 10.4. Heuristic Address Change Acknowledgement 2167 The address change signaling KEEP_ALIVE packet is supposed to be 2168 acknowledged if a packet targeted at the new IP address that the 2169 KEEP_ALIVE packet has informed is received. 2171 10.5. Explicit Multi-home Informing 2173 If an FSP end node is configured with multiple IPv4 address other 2174 than the loop-back address, or with multiply global unicast IPv6 2175 address, it MAY advertise multiple underlying addresses to the remote 2176 end by put them in the addressable network prefix list of the Sink 2177 Parameter extension header. The Sink Parameter extension header may 2178 be carried in the CONNECT_REQUEST, ACK_CONNECT_REQ, ACK_START, 2179 MULTIPLY or KEEP_ALIVE packet. 2181 Any participant of the communication SHALL NOT make discrimination of 2182 the source or destination IP address of any packet provided that both 2183 the source ULTID and the destination ULTID keep unchanged and the ICC 2184 field passes verification. 2186 11 Connection Multiplication 2188 Connection multiplication is the process of incarnating a new 2189 connection context by re-using security context of an established 2190 connection. 2192 11.1. Request to Multiply Connection 2194 (MULTIPLY, SN, Salt, ICC, FREWS [, Sink Parameter] [, payload]) 2196 The initiator's initial sequence number of the new connection is the 2197 sequence number of the packet that piggybacks the connection 2198 multiplication header. The ExpectedSN field of the normal packet 2199 store a Salt value instead. 2201 The FREWS field MUST be processed in the new connection context while 2202 the ICC MUST be calculated with the session key of the original 2203 connection. 2205 The new connection inherits the remaining key life. ULA SHOULD 2206 negotiate new session key and/or install new session key as soon as 2207 possible. 2209 The optional payload of the MULTIPLY packet MUST be processed in the 2210 new connection context. 2212 The MULTIPLY packet is an out-of-band command packet in the original 2213 connection context. 2215 11.2. Response to Connection Multiplication Request 2216 Case 1: (ACK_START, SN, ExpectedSN, ICC, FREWS [, Sink Parameter]) 2218 Case 2: (PERSIST, SN, ExpectedSN, ICC, FREWS, Payload) 2220 Case 3: (RESET, SN, ExpectedSN, ICC, FREWS, Reason of Failure) 2222 In all of these cases the ULTID of the remote-end MUST be the value 2223 of the initiator's ULTID in the connection multiplication header. 2225 In case 1 the responder admits the multiplication request AND commit 2226 the transmit transaction, the new connection enters into the 2227 PEER_COMMIT or CLOSABLE state immediately, on request of ULA. 2229 In case 2 the responder admits the multiplication request and the new 2230 connection enters into the ESTABLISHED, PEER_COMMIT, or COMMITTING or 2231 CLOSABLE state immediately, depending whether the ULA of the 2232 multiplication initiator has requested to commit the transmit 2233 transaction immediately and whether the ULA of the multiplication 2234 responder has requested to commit the transmit transaction in the 2235 reverse direction immediately. 2237 In case 3 the responder rejects the multiplication request. To defend 2238 against spoofing attack ICC MUST be valid. The value of the SN field 2239 MUST equal the value of the 'Expected SN' field of the requesting 2240 MULTIPLY packet while the value of ExpectedSN field MUST equal the 2241 value of the 'Sequence No' field. 2243 The new connection MUST derive new session key from the session key 2244 of the original connection where the out-of-band requesting MULTIPLY 2245 packet is received immediately. 2247 11.3. Duplicate Detection of Connection Multiplication Request 2249 Every time the responder of connection multiplication receives a 2250 MULTIPLY packet it MUST check the suggested responder's ULTID and the 2251 initiator's ULTID. 2253 The responder MUST reject the multiplication request if the suggested 2254 responder's ULTID equals the near-end ULTID of some connection and 2255 the remote-end ULTID of that connection does not equal the 2256 initiator's ULTID. 2258 The responder MUST recognize the MULTIPLY packet as a duplicate 2259 connection request if some connection matches the request and SHOULD 2260 response by retransmitting the head packet of the send queue of the 2261 matching connection, be it a PERSIST or an COMMIT packet. A 2262 connection matches the MULTIPLY request if and only if the suggested 2263 responder's ULTID in the MULTIPLY packet equals the near-end ULTID of 2264 the connection and the initiator's ULTID equals the remote-end ULTID 2265 of the connection. 2267 11.4. Retransmission 2269 The initiating side SHALL retransmit the MULTIPLY packet if the 2270 corresponding PERSIST packet is not received in some limit time (by 2271 default 15 seconds). 2273 11.5. Key Derivation for Branch Connection 2275 Let K_out = BLAKE2(Km, [d] || Label || 0x00 || Context || L), where: 2277 - Km 2278 is the master key, 2280 - [d] 2281 is one octet of integer Depth. It is alike the KDF counter mode 2282 as the NIST SP800-108. For this version of FSP it is the fixed 2283 number 1, 2285 - Label 2286 is the fixed ASCII string "Multiply an FSP connection" which is 2287 26-octet long for this version of FSP, 2289 - Context 2290 is concatenation of two 32-bit words idB and idR 2292 idB is the ULTID allocated for the branch connection in the 2293 context of the multiplication initiator. idB is byte-order 2294 neutral. 2296 idR is the receiver side ULTID of the original connection that is 2297 to accept the connection multiplication request. idI or idR is 2298 byte-order neutral. 2300 - L 2301 is a 32-bit network byte-order integer specifying the length in 2302 bits of the derived key K-out 2304 12 Timeouts and Abrupt Close 2306 12.1. Timeouts in End-to-End Negotiation 2308 Initially the initiator is in the CONNECT_BOOTSTRAP state. It 2309 migrates to the CONNECT_ AFFIRMING state after it received the 2310 legitimate ACK_INIT_CONNECT packet. Then it migrates to the 2311 PEER_COMMIT or CLOSABLE state after it received the legitimate 2312 ACK_CONNECT _REQ packet, depending on the hint of ULA. 2314 The responder incarnates a new connection context which is initially 2315 in the CHALLENGING state after accepting a legitimate Connect Request 2316 packet. Then it migrates to the COMMITTING or CLOSABLE state, 2317 depending on the packet received from its peer. 2319 If the initiator or the responder is unable to migrate to a new state 2320 in some limit time (by default 60 seconds, except in LISTENING state) 2321 it aborts the connection by recycling the connection context. 2323 12.2. Timeouts in Multiply 2325 Initially the initiating side of Connection Multiplication is in the 2326 CLONING state. It migrates to the ACTIVE, COMMITTED, PEER_COMMIT or 2327 CLOSABLE state after it received the legitimate PERSIST packet. Which 2328 state to migrated depends on the EoT flag of the initiating MULTIPLY 2329 packet and the responding PERSIST packet. 2331 If the initiating side is unable to migrate to a new state in some 2332 limit time (by default 60 seconds) it aborts multiplication by 2333 recycling the new connection context. 2335 12.3. Timeout of Transmit Transaction Commitment 2337 The FSP node MUST abort the connection if the time of no packet 2338 having arrived has exceed certain limit in the COMMITTING or 2339 COMMITTING2 state. 2341 In this FSP version, timeout of transmit transaction commitment is 2342 set to 5 minutes. 2344 12.4. Timeout of Graceful Shutdown 2346 It simply migrates to the NON_EXISTENT pseudo-state if timeout in the 2347 PRE_CLOSED state. 2349 In this FSP version, timeout of Graceful Shutdown is set to 1 minute. 2351 12.5. Idle Timeout 2353 If one participant has not received any packet is a limit time, it 2354 MUST be abruptly closed. 2356 In this FSP version idle timeout is set to 4 hours. 2358 12.6. Session Key Timeout 2359 For this FSP version if a secret key is applied for more than 2^30 2360 times the FSP node MUST abruptly closed instantly. 2362 12.7. Abrupt Close 2364 An FSP node abruptly shutdown a session by sending a RESET packet and 2365 release all of the resource occupied by the the session immediately. 2367 (RESET, SN, ExpectedSN, ICC, Reason of Failure) 2369 13 Issues for Further Study 2371 13.1. Milk-type Payload and Minimal Delay Service 2373 An ordinary data flow is wine-type in the sense that the older data 2374 are of leftmost value. If it has to, data packet sent latest are 2375 dropped first. 2377 In the contrary, milk-type payload is that the newer data are more 2378 precious and outdated data packet can be discarded. 2380 When ULA is willing to accept incomplete message the peer of the 2381 underling FSP node should set the MIND flag of every FSP PURE_DATA 2382 packet, while set the Traffic Class of the underlying IPv6 packet to 2383 some registered value. 2385 In the transmission path, any relaying middle box, be it router or 2386 switch, should reserve a reasonably short queue for the packet flow 2387 of such flow to minimize delay. 2389 When the receive buffer overflows the receiver discards the 2390 undelivered packet received first to free buffer space for the latest 2391 packet received. However it keeps order on delivering the packets to 2392 he ULA. ULA may choose to discard packets received earlier than some 2393 threshold. 2395 Optional forward-error-correction feature should be exploited to 2396 enhance reliability of data transfer under MIND mode. 2398 13.2. Resolution of ULTID in DNS 2400 There are two patterns of IP address resolution in FSP: the DNS- 2401 compatible pattern and the proxy pattern. The former pattern relies 2402 on some name service to resolve the IP address of the responder for 2403 the initiator before they exchange end-to-end packets. 2405 The latter embeds the address resolution information in the 2406 connection bootstrap packets and works in the FSP over IPv6 only. 2408 In the DNS-compatible pattern, the responder side of the FSP 2409 participants registered its address identifier, such as 'domain name' 2410 in some name service such as DNS, according to some pre-agreement at 2411 first. The initiator resolves the current IP address of the responder 2412 by consulting the name service, such as looking after the A or AAAA 2413 record of the domain name in DNS. 2415 In IPv6 network the rightmost 32 bits of the IPv6 address directly 2416 maps to the ULTID so FSP does not need additional multiplexing 2417 mechanism such as port number. Here it needs not consult SRV record 2418 or look for some entry in some 'services' file. 2420 If UDP over IPv4 is exploited as the layer data packet delivery 2421 service the port number of the responder is firstly resolved just 2422 alike normal network application such as HTTP and is extended to 32- 2423 bit ULTID. Here ULTIDs of FSP can be considered as the superset of 2424 TCP port numbers. 2426 If the string representation of IPv4/IPv6 address is applied directly 2427 as the peer's address identifier instead of the domain name there is 2428 no need for some real address resolution. But from the API caller's 2429 point of view it is a DNS-compatible mode address resolution. 2431 13.3. Optimizing FSP towards IPv6 2433 There are some interesting points to integrated FSP with IPv6 in 2434 besides integrated proxy mode of host name resolution. 2436 Originally FSP is optimized towards IPv6 and 64-bit computing. In 2437 fact, the upper layer application is assumed to be addressed with 2438 IPv6-compatible address even in a pure IPv4 network. 2440 To utilize IPv6 address space more efficiently FSP makes some slight 2441 tuning of address architecture when working over the IPv6 network. In 2442 an IPv6 packet that carries FSP payload each of the source and 2443 destination 128-bit IPv6 address is split into three parts: the 64- 2444 bit network prefix, the 32-bit aggregation host id and the 32-bit 2445 ULTID. 2447 When FSP is applied in an IPv6 networks, the lower layer addresses 2448 SHALL be IPv6. The rightmost 32 bits of each IPv6 address is 2449 designated as the ULTID which MUST keep unchanged across IPv6 address 2450 migration or translation. The leftmost 96 bits still holds the 2451 routing locator semantics. It can be argued that the routing 2452 scalability problem in the IPv6 network is effectively eliminated by 2453 such tuning of IPv6. 2455 One FSP connection MAY associate with up to 4 lower layer addresses. 2457 Besides the IP addresses associated with an FSP connection MAY change 2458 after the FSP connection is established. 2460 13.4. Binding End-to-End Negotiation with Resource Reservation 2462 End-to-End resource reservation protocol packets MAY be piggybacked 2463 on preliminary FSP packets in the connection establishment process to 2464 provide determinant quality of service. 2466 13.5. Path Selection and PMTU 2468 When FSP is implemented over UDP in the IPv4 network, each endpoint 2469 of the FSP connection is bound one and only one IPv4 address as soon 2470 as the connection is established. Each endpoint SHALL choose the 2471 source IPv4 address of the last packet received as the destination 2472 IPv4 address of the packet that it is to send later. By this mean FSP 2473 over UDP is NAT-friendly. 2475 When FSP is implemented over IPv6 as soon as the connection is 2476 established the IPv6 address may be changed dynamically, and one more 2477 alternate IP address may be added or removed dynamically for 2478 individual endpoint as well, provided that ULTID part keeps unchanged 2479 while the host IDs part of all IPv6 address of the endpoint are of 2480 the same value at any given moment. 2482 The sender may choose as the source IP address by selecting any 2483 network prefix that it has most-recently sent to its peer in the 2484 allowed address list field of the Sink Parameter header, joining with 2485 the host ID in the Sink Parameter header and the stable ULTID of the 2486 sender, and choose as the destination IP address by selecting any 2487 network prefix in the allowed address list field of the Sink 2488 Parameter header most-recently received from its peer, joining with 2489 the peer's host ID and the peer's ULTID. Thus multiple multi-homed 2490 paths MAY co-exist between the two FSP endpoints. 2492 (PMTU to be discussed) 2494 13.6. Host-Aggregated Congestion Control 2496 (To be investigated further) 2498 13.7. Asymmetric Transmission 2500 If there is one participant whose receiving interface is not the same 2501 as the transmission interface the participant is called an 2502 asymmetric-transmission node. 2504 Asymmetric-transmission itself is asymmetric in the sense that one 2505 participant may be asymmetric-transmission node while its peer is 2506 normal node of symmetric transmission. 2508 An end node is of asymmetric-transmission if it received an 2509 ACK_CONNECT_REQ packet, ACK_START or PERSIST packet whose source IP 2510 address that the network interface accepting the packets reported is 2511 not in the allowed IP address list in the Sink Parameter header of 2512 the packet. 2514 For an asymmetric-transmission remote end, the near end cannot rely 2515 on automatic IP address change detection. Instead IP address change 2516 notification mechanism shall be utilized. 2518 13.8. Connection Resurrection 2520 A connection in CLOSED state MAY be resurrected provided that the 2521 session key has not run out of life. The ULA should be able to reuse 2522 the security context of a closed connection established between the 2523 two end nodes that are meant to negotiate a new connection. 2525 13.9. Architectural evolutions to transit towards IPv6 2527 To implement FSP, there is some subtle tuning of IPv6 network 2528 architecture: 2530 o Split of IPv6 address 2531 Each physically network interface that has IPv6 address configured 2532 SHALL NOT have the network prefix configured longer than 96 bits, 2533 no matter that the IPv6 address is assigned by Stateless Address 2534 Autoconfiguration ([RFC4862]), stateful Dynamic Host Configuration 2535 Protocol for IPv6 ([RFC3315], [RFC3633]) or by some other means. 2537 Whenever an IPv6 interface is reconfigured, the leftmost 64 bits of 2538 any IPv6 address MAY change freely, the centermost 32 bits SHOULD 2539 be stable while the rightmost 32 bits MUST keep unmodified. 2541 o The ULA is the ultimate IPv6 end-point 2543 o Every network node is effectively a router 2544 Especially when FSP over UDP in the IPv4 network is exploited if 2545 one network end node of the participants is not a router in the 2546 traditional sense, the node is treated as if it were a router 2547 connecting the IPv6 addressed ULAs across the IPv4 network. 2549 14 Security Considerations 2551 14.1. Resistance against Deny of Service Attack 2553 FSP is designed to resist against DoS attack by exploiting concept of 2554 Cookie. 2556 However, resistance against distributed DoS attack relies on external 2557 mechanism such as DOTS[DOTS architecture] 2559 14.2. Resistance against Replay Attack 2561 In-band sequence number and out-of-band sequence number are exploited 2562 to resist against replay attack. 2564 14.3. Resistance against Passive Attacks 2566 AEAD MAY be exploited by the ULA to protect it against passive 2567 attacks such as eavesdropping, gaining advantage by analyzing the 2568 data sent. 2570 MAC only service MAY also be utilized. Together with application 2571 layer stream-mode encryption it protects the ULA against passive 2572 attacks as well. 2574 14.4. Resistance against Masquerade Attack 2576 Both AEAD and MAC only service may be exploited to protect the 2577 endpoints against masquerade attack. 2579 14.5. Resistance against Active Man-In-The-Middle Attack 2581 The ULA SHALL take account to protect itself against MITM attack when 2582 making client authentication and key establishment. 2584 14.6. Privacy concerns 2586 It is beneficial for privacy protection that the ULTID of each 2587 endpoints of an FSP connection is generated randomly [RFC7721]. 2589 15 IANA Considerations 2591 It should be requested that the port number registered for UDP 2592 packets encapsulating FSP in the IPv4 network. The port number 18003 2593 is exploited in the concept prototype implementation. The number is 2594 the decimal presentation of ASCII codes of the character 'F' and 'S' 2595 concatenated in network byte order. 2597 It should be requested that the 'Next Header'/protocol number is 2598 assigned for FSP over IPv6. Decimal number 144 is exploited in the 2599 concept prototype implementation. 2601 16 References 2603 16.1. Normative References 2605 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 2606 2608 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 2609 Cartridges - DLT1 Format Standard, Annex B", ECMA-182, 2610 December 1992. 2612 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 2613 Galois/Counter Mode (GCM) and GMAC", November 2007. 2614 2616 [OSI/RM] ISO and IEC, "Information technology-Open Systems 2617 Interconnection - Basic Reference Model: The Basic Model", 2618 ISO/IEC 7498-1 Second edition, November 1994. 2619 2621 [R01] Rogaway, P., "Authenticated encryption with Associated- 2622 Data", ACM Conference on Computer and Communication 2623 Security (CCS'02), pp. 98-107, ACM Press, 2002. 2625 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2626 Communication Layers", STD 3, RFC 1122, DOI 2627 10.17487/RFC1122, October 1989, . 2630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2631 Requirement Levels", BCP 14, RFC 2119, DOI 2632 10.17487/RFC2119, March 1997, . 2635 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2636 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2637 2003, . 2639 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2640 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2641 2006, . 2643 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2644 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2645 December 2005, . 2647 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2648 IANA Considerations Section in RFCs", RFC 5226, DOI 2649 10.17487/RFC5226, May 2008, . 2652 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2653 Key Derivation Function (HKDF)", RFC 5869, DOI 2654 10.17487/RFC5869, May 2010, . 2657 [RFC7693] Saarinen, M-J., Ed., and J-P. Aumasson, "The BLAKE2 2658 Cryptographic Hash and Message Authentication Code (MAC)", 2659 RFC 7693, DOI 10.17487/RFC7693, November 2015, 2660 . 2662 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2663 (IPv6) Specification", STD 86, RFC 8200, DOI 2664 10.17487/RFC8200, July 2017, . 2667 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 2668 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 2669 . 2671 [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2672 1981. 2674 [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2675 August 1980. 2677 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 2678 793, September 1981. 2680 16.2. Informative References 2682 [Gao2002] Gao, J., "Fuzzy-layering and its suggestion", IETF Mail 2683 Archive, September 2002, 2684 https://mailarchive.ietf.org/arch/msg/ietf/u-6i-6f- 2685 Etuvh80-SUuRbSCDTwg 2687 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 2688 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 2689 pp. 1573-1583. 2691 [tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D. 2693 Boneh, "The case for ubiquitous transport-level 2694 encryption", USENIX Security , 2010. 2696 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2697 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2698 . 2700 [RFC1035] Mockapetris, P., "Domain names - implementation and 2701 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2702 November 1987, . 2704 [RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions 2705 Functional Specification", RFC 1644, DOI 10.17487/RFC1644, 2706 July 1994, . 2708 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2709 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2710 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2711 September 1997, . 2713 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2714 Defeating Denial of Service Attacks which employ IP Source 2715 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2716 May 2000, . 2718 [RFC3055] Krishnaswamy, M. and D. Romascanu, "Management Information 2719 Base for the PINT Services Architecture", RFC 3055, DOI 2720 10.17487/RFC3055, February 2001, . 2723 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2724 of Explicit Congestion Notification (ECN) to IP", 2725 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2726 . 2728 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2729 C., and M. Carney, "Dynamic Host Configuration Protocol 2730 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2731 2003, . 2733 [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", 2734 RFC 3344, DOI 10.17487/RFC3344, August 2002, 2735 . 2737 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2738 "DNS Extensions to Support IP Version 6", STD 88, 2739 RFC 3596, DOI 10.17487/RFC3596, October 2003, 2740 . 2742 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2743 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2744 DOI 10.17487/RFC3633, December 2003, . 2747 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 2748 and E. Zeidner, "Internet Small Computer Systems Interface 2749 (iSCSI)", RFC 3720, DOI 10.17487/RFC3720, April 2004, 2750 . 2752 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 2753 and G. Fairhurst, Ed., "The Lightweight User Datagram 2754 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2755 2004, . 2757 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 2758 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 2759 RFC 3963, DOI 10.17487/RFC3963, January 2005, 2760 . 2762 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2763 Resource Identifier (URI): Generic Syntax", STD 66, 2764 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2765 . 2767 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2768 "Randomness Requirements for Security", BCP 106, RFC 4086, 2769 DOI 10.17487/RFC4086, June 2005, . 2772 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2773 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2774 RFC 4106, DOI 10.17487/RFC4106, June 2005, 2775 . 2777 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 2778 10.17487/RFC4302, December 2005, . 2781 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2782 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2783 . 2785 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 2786 Protocol (DHCP) Leasequery", RFC 4388, DOI 2787 10.17487/RFC4388, February 2006, . 2790 [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple 2791 Authentication and Security Layer (SASL)", RFC 4422, DOI 2792 10.17487/RFC4422, June 2006, . 2795 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2796 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 2797 . 2799 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2800 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2801 DOI 10.17487/RFC4861, September 2007, . 2804 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2805 Address Autoconfiguration", RFC 4862, DOI 2806 10.17487/RFC4862, September 2007, . 2809 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2810 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2811 . 2813 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 2814 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 2815 . 2817 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2818 Kozuka, "Stream Control Transmission Protocol (SCTP) 2819 Dynamic Address Reconfiguration", RFC 5061, DOI 2820 10.17487/RFC5061, September 2007, . 2823 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 2824 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 2825 . 2827 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2828 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2829 . 2831 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2832 IANA Considerations Section in RFCs", RFC 5226, DOI 2833 10.17487/RFC5226, May 2008, . 2836 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2837 (TLS) Protocol Version 1.2", RFC 5246, DOI 2838 10.17487/RFC5246, August 2008, . 2841 [RFC5889] Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing 2842 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 2843 September 2010, . 2845 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 2846 Model: The Relationship between Links and Subnet 2847 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 2848 . 2850 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 2851 Assignment to End Sites", BCP 157, RFC 6177, DOI 2852 10.17487/RFC6177, March 2011, . 2855 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2856 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2857 2011, . 2859 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2860 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2861 January 2012, . 2863 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2864 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2865 2011, . 2867 [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 2868 Protocol (ILNP) Architectural Description", RFC 6740, DOI 2869 10.17487/RFC6740, November 2012, . 2872 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2873 "TCP Extensions for Multipath Operation with Multiple 2874 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 2875 . 2877 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2878 Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 2879 10.17487/RFC6830, January 2013, . 2882 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2883 the IPv6 Prefix Used for IPv6 Address Synthesis", 2884 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2885 . 2887 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 2888 and D. Wing, "IPv6 Multihoming without Network Address 2889 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 2890 . 2892 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2893 Constrained-Node Networks", RFC 7228, DOI 2894 10.17487/RFC7228, May 2014, . 2897 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2898 Kivinen, "Internet Key Exchange Protocol Version 2 2899 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2900 2014, . 2902 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2903 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 2904 10.17487/RFC7540, May 2015, . 2907 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 2908 Length Recommendation for Forwarding", BCP 198, RFC 7608, 2909 DOI 10.17487/RFC7608, July 2015, . 2912 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2913 Considerations for IPv6 Address Generation Mechanisms", 2914 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2915 . 2917 [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, 2918 N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, 2919 "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, DOI 2920 10.17487/RFC7849, May 2016, . 2923 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 2924 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 2925 . 2927 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2928 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2929 March 2017, . 2931 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 2932 Explicit Congestion Notification (ECN)", RFC 8087, DOI 2933 10.17487/RFC8087, March 2017, . 2936 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 2937 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 2938 May 2017, . 2940 [I-D.ila-mobility] 2941 Mueller, J. and T. Herbert, "Mobility Management Using 2942 Identifier Locator Addressing", Internet-Draft draft- 2943 mueller-ila-mobility-03, February 2017. 2944 2947 [I-D.ietf-quic-transport] 2948 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 2949 and Secure Transport", Internet-Draft draft-ietf-quic- 2950 transport-03, May 2017. 2953 17 Acknowledgements 2955 Authors' Addresses 2957 Jason Gao 2958 Beijing 2959 P.R.China 2961 EMail: jagao@outlook.com