idnits 2.17.1 draft-ietf-tsvwg-sctpimpguide-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 144 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document updates RFC2960, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use the slow start algorithm to increase cwnd only if the current congestion window is being fully utilized, an incoming SACK advances the Cumulative TSN Ack Point, and the data sender is not in Fast Recovery. Only when these three conditions are met can the cwnd be increased otherwise the cwnd MUST not be increased. If these conditions are met then cwnd MUST be increased by at most the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This protects against the ACK-Splitting attack outlined in [SAVAGE99]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 13, 2003) is 7470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2434' on line 447 -- Looks like a reference, but probably isn't: 'ALLMAN99' on line 1212 -- Looks like a reference, but probably isn't: 'FALL96' on line 1215 -- Looks like a reference, but probably isn't: 'RFC1750' on line 1219 -- Looks like a reference, but probably isn't: 'RFC1950' on line 1226 -- Looks like a reference, but probably isn't: 'RFC2104' on line 1229 -- Looks like a reference, but probably isn't: 'RFC2196' on line 1232 -- Looks like a reference, but probably isn't: 'RFC2522' on line 1235 -- Looks like a reference, but probably isn't: 'SAVAGE99' on line 1436 -- Looks like a reference, but probably isn't: 'RFC1858' on line 1222 == Unused Reference: '1' is defined on line 3259, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 3271, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2861 (ref. '4') (Obsoleted by RFC 7661) ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Stewart 2 Internet-Draft Cisco Systems, Inc. 3 Expires: May 13, 2004 I. Arias-Rodriguez 4 Nokia Research Center 5 K. Poon 6 Consultant 7 A. Caro 8 University of Delaware 9 M. Tuexen 10 Univ. of Applied Sciences Muenster 11 November 13, 2003 13 Stream Control Transmission Protocol (SCTP) Implementer's Guide 14 draft-ietf-tsvwg-sctpimpguide-10.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 13, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This document contains a compilation of all defects found up until 45 the publishing of this document for the Stream Control Transmission 46 Protocol (SCTP) RFC2960 [5]. These defects may be of an editorial or 47 technical nature. This document may be thought of as a companion 48 document to be used in the implementation of SCTP to clarify errors 49 in the original SCTP document. 51 This document updates RFC2960 [5] and text within this document 52 supersedes the text found in RFC2960 [5]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . 7 59 2.1 Incorrect error type during chunk processing. . . . . . . 7 60 2.1.1 Description of the problem . . . . . . . . . . . . . . . . 7 61 2.1.2 Text changes to the document . . . . . . . . . . . . . . . 7 62 2.1.3 Solution description . . . . . . . . . . . . . . . . . . . 7 63 2.2 Parameter processing issue . . . . . . . . . . . . . . . . 7 64 2.2.1 Description of the problem . . . . . . . . . . . . . . . . 7 65 2.2.2 Text changes to the document . . . . . . . . . . . . . . . 7 66 2.2.3 Solution description . . . . . . . . . . . . . . . . . . . 8 67 2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 8 68 2.3.1 Description of the problem . . . . . . . . . . . . . . . . 8 69 2.3.2 Text changes to the document . . . . . . . . . . . . . . . 8 70 2.3.3 Solution description . . . . . . . . . . . . . . . . . . . 10 71 2.4 Parameter types across all chunk types . . . . . . . . . . 10 72 2.4.1 Description of the problem . . . . . . . . . . . . . . . . 10 73 2.4.2 Text changes to the document . . . . . . . . . . . . . . . 10 74 2.4.3 Solution description . . . . . . . . . . . . . . . . . . . 11 75 2.5 Stream parameter clarification . . . . . . . . . . . . . . 12 76 2.5.1 Description of the problem . . . . . . . . . . . . . . . . 12 77 2.5.2 Text changes to the document . . . . . . . . . . . . . . . 12 78 2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 12 79 2.6 Restarting association security issue . . . . . . . . . . 13 80 2.6.1 Description of the problem . . . . . . . . . . . . . . . . 13 81 2.6.2 Text changes to the document . . . . . . . . . . . . . . . 13 82 2.6.3 Solution description . . . . . . . . . . . . . . . . . . . 17 83 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 17 84 2.7.1 Description of the problem . . . . . . . . . . . . . . . . 17 85 2.7.2 Text changes to the document . . . . . . . . . . . . . . . 17 86 2.7.3 Solution description . . . . . . . . . . . . . . . . . . . 18 87 2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 18 88 2.8.1 Description of the problem . . . . . . . . . . . . . . . . 18 89 2.8.2 Text changes to the document . . . . . . . . . . . . . . . 18 90 2.8.3 Solution description . . . . . . . . . . . . . . . . . . . 21 91 2.9 Missing statement about partial_bytes_acked update . . . . 21 92 2.9.1 Description of the problem . . . . . . . . . . . . . . . . 21 93 2.9.2 Text changes to the document . . . . . . . . . . . . . . . 22 94 2.9.3 Solution description . . . . . . . . . . . . . . . . . . . 23 95 2.10 Issues with Heartbeating and failure detection . . . . . . 23 96 2.10.1 Description of the problem . . . . . . . . . . . . . . . . 23 97 2.10.2 Text changes to the document . . . . . . . . . . . . . . . 23 98 2.10.3 Solution description . . . . . . . . . . . . . . . . . . . 26 99 2.11 Security interactions with firewalls . . . . . . . . . . . 26 100 2.11.1 Description of the problem . . . . . . . . . . . . . . . . 26 101 2.11.2 Text changes to the document . . . . . . . . . . . . . . . 26 102 2.11.3 Solution description . . . . . . . . . . . . . . . . . . . 28 103 2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . . 28 104 2.12.1 Description of the problem . . . . . . . . . . . . . . . . 28 105 2.12.2 Text changes to the document . . . . . . . . . . . . . . . 28 106 2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 29 107 2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 29 108 2.13.1 Description of the problem . . . . . . . . . . . . . . . . 30 109 2.13.2 Text changes to the document . . . . . . . . . . . . . . . 30 110 2.13.3 Solution description . . . . . . . . . . . . . . . . . . . 30 111 2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . . 31 112 2.14.1 Description of the problem . . . . . . . . . . . . . . . . 31 113 2.14.2 Text changes to the document . . . . . . . . . . . . . . . 31 114 2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 34 115 2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 34 116 2.15.1 Description of the problem . . . . . . . . . . . . . . . . 34 117 2.15.2 Text changes to the document . . . . . . . . . . . . . . . 34 118 2.15.3 Solution description . . . . . . . . . . . . . . . . . . . 36 119 2.16 Fragmentation and Path MTU issues . . . . . . . . . . . . 36 120 2.16.1 Description of the problem . . . . . . . . . . . . . . . . 36 121 2.16.2 Text changes to the document . . . . . . . . . . . . . . . 36 122 2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 37 123 2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 37 124 2.17.1 Description of the problem . . . . . . . . . . . . . . . . 37 125 2.17.2 Text changes to the document . . . . . . . . . . . . . . . 37 126 2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 38 127 2.18 Handling of address parameters within the INIT or 128 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . 38 129 2.18.1 Description of the problem . . . . . . . . . . . . . . . . 38 130 2.18.2 Text changes to the document . . . . . . . . . . . . . . . 38 131 2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 39 132 2.19 Handling of stream shortages . . . . . . . . . . . . . . . 39 133 2.19.1 Description of the problem . . . . . . . . . . . . . . . . 39 134 2.19.2 Text changes to the document . . . . . . . . . . . . . . . 39 135 2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 40 136 2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 40 137 2.20.1 Description of the problem . . . . . . . . . . . . . . . . 40 138 2.20.2 Text changes to the document . . . . . . . . . . . . . . . 40 139 2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 41 140 2.21 User initiated abort of an association . . . . . . . . . . 41 141 2.21.1 Description of the problem . . . . . . . . . . . . . . . . 41 142 2.21.2 Text changes to the document . . . . . . . . . . . . . . . 41 143 2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 47 144 2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 47 145 2.22.1 Description of the problem . . . . . . . . . . . . . . . . 47 146 2.22.2 Text changes to the document . . . . . . . . . . . . . . . 47 147 2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 48 148 2.23 ABORT sending in response to an INIT . . . . . . . . . . . 48 149 2.23.1 Description of the problem . . . . . . . . . . . . . . . . 48 150 2.23.2 Text changes to the document . . . . . . . . . . . . . . . 48 151 2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 48 152 2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 49 153 2.24.1 Description of the problem . . . . . . . . . . . . . . . . 49 154 2.24.2 Text changes to the document . . . . . . . . . . . . . . . 49 155 2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 49 156 2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 49 157 2.25.1 Description of the problem . . . . . . . . . . . . . . . . 49 158 2.25.2 Text changes to the document . . . . . . . . . . . . . . . 49 159 2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 50 160 2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 50 161 2.26.1 Description of the problem . . . . . . . . . . . . . . . . 50 162 2.26.2 Text changes to the document . . . . . . . . . . . . . . . 50 163 2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 52 164 2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 52 165 2.27.1 Description of the problem . . . . . . . . . . . . . . . . 52 166 2.27.2 Text changes to the document . . . . . . . . . . . . . . . 53 167 2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 54 168 2.28 Handling of IP Address Parameters . . . . . . . . . . . . 54 169 2.28.1 Description of the problem . . . . . . . . . . . . . . . . 54 170 2.28.2 Text changes to the document . . . . . . . . . . . . . . . 54 171 2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 55 172 2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 55 173 2.29.1 Description of the problem . . . . . . . . . . . . . . . . 55 174 2.29.2 Text changes to the document . . . . . . . . . . . . . . . 55 175 2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 56 176 2.30 The Initial Congestion Window Size . . . . . . . . . . . . 56 177 2.30.1 Description of the problem . . . . . . . . . . . . . . . . 56 178 2.30.2 Text changes to the document . . . . . . . . . . . . . . . 56 179 2.30.3 Solution description . . . . . . . . . . . . . . . . . . . 56 180 2.31 Stream Sequence Numbers in Figures . . . . . . . . . . . . 57 181 2.31.1 Description of the problem . . . . . . . . . . . . . . . . 57 182 2.31.2 Text changes to the document . . . . . . . . . . . . . . . 57 183 2.31.3 Solution description . . . . . . . . . . . . . . . . . . . 61 184 2.32 Unrecognized Parameters . . . . . . . . . . . . . . . . . 61 185 2.32.1 Description of the problem . . . . . . . . . . . . . . . . 61 186 2.32.2 Text changes to the document . . . . . . . . . . . . . . . 61 187 2.32.3 Solution description . . . . . . . . . . . . . . . . . . . 63 188 2.33 Handling of unrecognized parameters . . . . . . . . . . . 63 189 2.33.1 Description of the problem . . . . . . . . . . . . . . . . 63 190 2.33.2 Text changes to the document . . . . . . . . . . . . . . . 63 191 2.33.3 Solution description . . . . . . . . . . . . . . . . . . . 64 192 2.34 Tie Tags . . . . . . . . . . . . . . . . . . . . . . . . . 64 193 2.34.1 Description of the problem . . . . . . . . . . . . . . . . 64 194 2.34.2 Text changes to the document . . . . . . . . . . . . . . . 65 195 2.34.3 Solution description . . . . . . . . . . . . . . . . . . . 66 196 2.35 Port number verification in the COOKIE-ECHO . . . . . . . 66 197 2.35.1 Description of the problem . . . . . . . . . . . . . . . . 66 198 2.35.2 Text changes to the document . . . . . . . . . . . . . . . 67 199 2.35.3 Solution description . . . . . . . . . . . . . . . . . . . 68 200 2.36 Path Initialization . . . . . . . . . . . . . . . . . . . 68 201 2.36.1 Description of the problem . . . . . . . . . . . . . . . . 68 202 2.36.2 Text changes to the document . . . . . . . . . . . . . . . 68 203 2.36.3 Solution description . . . . . . . . . . . . . . . . . . . 69 204 2.37 ICMP handling procedures . . . . . . . . . . . . . . . . . 70 205 2.37.1 Description of the problem . . . . . . . . . . . . . . . . 70 206 2.37.2 Text changes to the document . . . . . . . . . . . . . . . 70 207 2.37.3 Solution description . . . . . . . . . . . . . . . . . . . 71 208 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 72 209 References . . . . . . . . . . . . . . . . . . . . . . . . 73 210 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 73 211 Intellectual Property and Copyright Statements . . . . . . 75 213 1. Introduction 215 This document contains a compilation of all defects found up until 216 the publishing of this document for the Stream Control Transmission 217 Protocol (SCTP) RFC2960 [5]. These defects may be of an editorial or 218 technical nature. This document may be thought of as a companion 219 document to be used in the implementation of SCTP to clarify errors 220 in the original SCTP document. 222 This document updates RFC2960 and text within this document, where 223 noted, supersedes the text found in RFC2960 [5]. Each error will be 224 detailed within this document in the form of: 226 o The problem description, 228 o The text quoted from RFC2960 [5], 230 o The replacement text, 232 o A description of the solution. 234 1.1 Conventions 236 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 237 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 238 they appear in this document, are to be interpreted as described in 239 RFC2119 [2]. 241 2. Corrections to RFC2960 243 2.1 Incorrect error type during chunk processing. 245 2.1.1 Description of the problem 247 A typo was discovered in RFC2960 [5] that incorrectly specifies an 248 action to be taken when processing chunks of unknown identity. 250 2.1.2 Text changes to the document 252 --------- 253 Old text: (Section 3.2) 254 --------- 256 01 - Stop processing this SCTP packet and discard it, do not process 257 any further chunks within it, and report the unrecognized 258 parameter in an 'Unrecognized Parameter Type' (in either an 259 ERROR or in the INIT ACK). 261 --------- 262 New text: (Section 3.2) 263 --------- 265 01 - Stop processing this SCTP packet and discard it, do not process 266 any further chunks within it, and report the unrecognized 267 chunk in an 'Unrecognized Chunk Type'. 269 2.1.3 Solution description 271 The receiver of an unrecognized Chunk should not send a 'parameter' 272 error but instead the appropriate chunk error as described above. 274 2.2 Parameter processing issue 276 2.2.1 Description of the problem 278 A typographical error was introduced through an improper cut and 279 paste in the use of the upper two bits to describe proper handling of 280 unknown parameters. 282 2.2.2 Text changes to the document 284 --------- 285 Old text: (Section 3.2.1) 286 --------- 287 00 - Stop processing this SCTP packet and discard it, do not process 288 any further chunks within it. 290 01 - Stop processing this SCTP packet and discard it, do not process 291 any further chunks within it, and report the unrecognized 292 parameter in an 'Unrecognized Parameter Type' (in either an 293 ERROR or in the INIT ACK). 295 --------- 296 New text: (Section 3.2.1) 297 --------- 299 00 - Stop processing this SCTP chunk and discard it, do not process 300 any further parameters within this chunk. 302 01 - Stop processing this SCTP chunk and discard it, do not process 303 any further parameters within this chunk, and report the 304 unrecognized parameter in an 'Unrecognized Parameter Type' (in 305 either an ERROR or in the INIT ACK). 307 2.2.3 Solution description 309 It was always the intent to stop processing at the level one was at 310 in an unknown chunk or parameter with the upper bit set to 0. Thus if 311 you are processing a chunk, you should drop the packet. If you are 312 processing a parameter, you should drop the chunk. 314 2.3 Padding issues 316 2.3.1 Description of the problem 318 A problem was found in that when a Chunk terminated in a TLV 319 parameter. If this last TLV was not on a 32 bit boundary (as 320 required), there was confusion as to if the last padding was included 321 in the chunk length. 323 2.3.2 Text changes to the document 325 --------- 326 Old text: (Section 3.2) 327 --------- 329 Chunk Length: 16 bits (unsigned integer) 331 This value represents the size of the chunk in bytes including the 332 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 333 Therefore, if the Chunk Value field is zero-length, the Length 334 field will be set to 4. The Chunk Length field does not count any 335 padding. 337 Chunk Value: variable length 339 The Chunk Value field contains the actual information to be 340 transferred in the chunk. The usage and format of this field is 341 dependent on the Chunk Type. 343 The total length of a chunk (including Type, Length and Value fields) 344 MUST be a multiple of 4 bytes. If the length of the chunk is not a 345 multiple of 4 bytes, the sender MUST pad the chunk with all zero 346 bytes and this padding is not included in the chunk length field. 347 The sender should never pad with more than 3 bytes. The receiver 348 MUST ignore the padding bytes. 350 --------- 351 New text: (Section 3.2) 352 --------- 354 Chunk Length: 16 bits (unsigned integer) 356 This value represents the size of the chunk in bytes including the 357 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 358 Therefore, if the Chunk Value field is zero-length, the Length 359 field will be set to 4. The Chunk Length field does not count any 360 chunk padding. 362 Chunks (including Type, Length and Value fields) are padded out by 363 the sender with all zero bytes to be a multiple of 4 bytes long. 364 This padding MUST NOT be more than 3 bytes in total. The Chunk 365 Length value does not include terminating padding of the Chunk. 366 However, it does include padding of any variable length parameter 367 except the last parameter in the Chunk. The receiver MUST ignore 368 the padding. 370 Note: A robust implementation should accept the Chunk whether 371 or not the final padding has been included in the Chunk Length. 373 Chunk Value: variable length 375 The Chunk Value field contains the actual information to be 376 transferred in the chunk. The usage and format of this field is 377 dependent on the Chunk Type. 379 2.3.3 Solution description 381 The above text makes clear that the padding of the last parameter is 382 not included in the Chunk Length field. It also clarifies that the 383 padding of parameters that are not the last one must be counted in 384 the Chunk Length field. 386 2.4 Parameter types across all chunk types 388 2.4.1 Description of the problem 390 A problem was noted when multiple errors are needed to be sent 391 regarding unknown or unrecognized parameters. Since often times the 392 error type does not hold the chunk type field, it may become 393 difficult to tell which error was associated with which chunk. 395 2.4.2 Text changes to the document 397 --------- 398 Old text: (Section 3.2.1) 399 --------- 401 The actual SCTP parameters are defined in the specific SCTP chunk 402 sections. The rules for IETF-defined parameter extensions are 403 defined in Section 13.2. 405 --------- 406 New text: (Section 3.2.1) 407 --------- 409 The actual SCTP parameters are defined in the specific SCTP chunk 410 sections. The rules for IETF-defined parameter extensions are 411 defined in Section 13.2. Note that a parameter type MUST be unique 412 across all chunks. For example, the parameter type '5' is used to 413 represent an IPv4 address (see section 3.3.2). The value '5' then is 414 reserved across all chunks to represent an IPv4 address and MUST NOT 415 be reused with a different meaning in any other chunk. 417 --------- 418 Old text: (Section 13.2) 419 --------- 421 13.2 IETF-defined Chunk Parameter Extension 423 The assignment of new chunk parameter type codes is done through an 424 IETF Consensus action as defined in [RFC2434]. Documentation of the 425 chunk parameter MUST contain the following information: 427 a) Name of the parameter type. 429 b) Detailed description of the structure of the parameter field. 430 This structure MUST conform to the general type-length-value 431 format described in Section 3.2.1. 433 c) Detailed definition of each component of the parameter type. 435 d) Detailed description of the intended use of this parameter type, 436 and an indication of whether and under what circumstances multiple 437 instances of this parameter type may be found within the same 438 chunk. 440 --------- 441 New text: (Section 13.2) 442 --------- 444 13.2 IETF-defined Chunk Parameter Extension 446 The assignment of new chunk parameter type codes is done through an 447 IETF Consensus action as defined in [RFC2434]. Documentation of the 448 chunk parameter MUST contain the following information: 450 a) Name of the parameter type. 452 b) Detailed description of the structure of the parameter field. This 453 structure MUST conform to the general type-length-value format 454 described in Section 3.2.1. 456 c) Detailed definition of each component of the parameter type. 458 d) Detailed description of the intended use of this parameter type, 459 and an indication of whether and under what circumstances multiple 460 instances of this parameter type may be found within the same 461 chunk. 463 e) Each parameter type MUST be unique across all chunks. 465 2.4.3 Solution description 467 By having all parameters unique across all chunk assignments (the 468 current assignment policy) no ambiguity exists as to what a parameter 469 means based on context. The trade off for this is a smaller parameter 470 space i.e. 65,536 parameters versus 65,536 * Number-of-chunks. 472 2.5 Stream parameter clarification 474 2.5.1 Description of the problem 476 A problem was found where the specification is unclear on the 477 legality of an endpoint asking for more stream resources than were 478 allowed in the MIS value of the INIT. In particular the value in the 479 INIT ACK requested in its OS value was larger than the MIS value 480 received in the INIT chunk. This behavior is illegal yet it was 481 unspecified in RFC2960 [5] 483 2.5.2 Text changes to the document 485 --------- 486 Old text: (Section 3.3.3) 487 --------- 489 Number of Outbound Streams (OS): 16 bits (unsigned integer) 491 Defines the number of outbound streams the sender of this INIT ACK 492 chunk wishes to create in this association. The value of 0 MUST 493 NOT be used. 495 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD 496 destroy the association discarding its TCB. 498 --------- 499 New text: (Section 3.3.3) 500 --------- 502 Number of Outbound Streams (OS): 16 bits (unsigned integer) 504 Defines the number of outbound streams the sender of this INIT ACK 505 chunk wishes to create in this association. The value of 0 MUST 506 NOT be used and the value MUST NOT be greater than the MIS value 507 sent in the INIT chunk. 509 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD 510 destroy the association discarding its TCB. 512 2.5.3 Solution description 514 The change in wording, above, changes it so that a responder to an 515 INIT chunk does not specify more streams in its OS value than was 516 represented to it in the MIS value i.e. its maximum. 518 2.6 Restarting association security issue 520 2.6.1 Description of the problem 522 A security problem was found when a restart occurs. It is possible 523 for an intruder to send an INIT to an endpoint of an existing 524 association. In the INIT the intruder would list one or more of the 525 current addresses of an association and its own. The normal restart 526 procedures would then occur and the intruder would have hi-jacked an 527 association. 529 2.6.2 Text changes to the document 531 --------- 532 Old text: (Section 3.3.10) 533 --------- 535 Cause Code 536 Value Cause Code 537 --------- ---------------- 538 1 Invalid Stream Identifier 539 2 Missing Mandatory Parameter 540 3 Stale Cookie Error 541 4 Out of Resource 542 5 Unresolvable Address 543 6 Unrecognized Chunk Type 544 7 Invalid Mandatory Parameter 545 8 Unrecognized Parameters 546 9 No User Data 547 10 Cookie Received While Shutting Down 549 Cause Length: 16 bits (unsigned integer) 551 Set to the size of the parameter in bytes, including the Cause 552 Code, Cause Length, and Cause-Specific Information fields 554 Cause-specific Information: variable length 556 This field carries the details of the error condition. 558 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. 559 Guidelines for the IETF to define new error cause values are 560 discussed in Section 13.3. 562 --------- 563 New text: (Section 3.3.10) 564 --------- 565 Cause Code 566 Value Cause Code 567 --------- ---------------- 568 1 Invalid Stream Identifier 569 2 Missing Mandatory Parameter 570 3 Stale Cookie Error 571 4 Out of Resource 572 5 Unresolvable Address 573 6 Unrecognized Chunk Type 574 7 Invalid Mandatory Parameter 575 8 Unrecognized Parameters 576 9 No User Data 577 10 Cookie Received While Shutting Down 578 11 Restart of an association with new addresses 580 Cause Length: 16 bits (unsigned integer) 582 Set to the size of the parameter in bytes, including the Cause 583 Code, Cause Length, and Cause-Specific Information fields 585 Cause-specific Information: variable length 587 This field carries the details of the error condition. 589 Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. 590 Guidelines for the IETF to define new error cause values are 591 discussed in Section 13.3. 593 --------- 594 New text: (Note no old text, new error cause added in section 3.3.10) 595 --------- 597 3.3.10.11 Restart of an association with new addresses (11) 599 Cause of error 600 -------------- 601 Restart of an association with new addresses: An INIT was received 602 on an existing association. But the INIT added addresses to the 603 association that were previously NOT part of the association. The 604 New addresses are listed in the error code. This ERROR is normally 605 sent as part of an ABORT refusing the INIT (see section 5.2). 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Cause Code=11 | Cause Length=Variable | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 / New Address TLVs / 611 \\ \\ 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 --------- 615 Old text: (Section 5.2.1) 616 --------- 618 Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an 619 endpoint MUST respond with an INIT ACK using the same parameters it 620 sent in its original INIT chunk (including its Initiation Tag, 621 unchanged). These original parameters are combined with those from 622 the newly received INIT chunk. The endpoint shall also generate a 623 State Cookie with the INIT ACK. The endpoint uses the parameters 624 sent in its INIT to calculate the State Cookie. 626 --------- 627 New text: (Section 5.2.1) 628 --------- 630 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 631 respond with an INIT ACK using the same parameters it sent in its 632 original INIT chunk (including its Initiation Tag, unchanged). When 633 responding the endpoint MUST send the INIT ACK back to the same 634 address that the original INIT (sent by this endpoint) was sent to. 636 Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST 637 respond with an INIT ACK using the same parameters it sent in its 638 original INIT chunk (including its Initiation Tag, unchanged) 639 provided that no NEW address have been added to the forming 640 association. If the INIT message indicates that a new address(es) 641 have been added to the association, then the entire INIT MUST be 642 discarded and NO changes should be made to the existing association. 643 An ABORT MUST be sent in response that SHOULD include the error 644 'Restart of an association with new addresses'. The error SHOULD list 645 the addresses that were added to the restarting association. 647 When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with 648 an INIT ACK the original parameters are combined with those from the 649 newly received INIT chunk. The endpoint shall also generate a State 650 Cookie with the INIT ACK. The endpoint uses the parameters sent in 651 its INIT to calculate the State Cookie. 653 --------- 654 Old text: (Section 5.2.2) 655 --------- 657 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 658 COOKIE-WAIT and SHUTDOWN-ACK-SENT 660 Unless otherwise stated, upon reception of an unexpected INIT for 661 this association, the endpoint shall generate an INIT ACK with a 662 State Cookie. In the outbound INIT ACK the endpoint MUST copy its 663 current Verification Tag and peer's Verification Tag into a reserved 664 place within the state cookie. We shall refer to these locations as 665 the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet 666 containing this INIT ACK MUST carry a Verification Tag value equal to 667 the Initiation Tag found in the unexpected INIT. And the INIT ACK 668 MUST contain a new Initiation Tag (randomly generated see Section 669 5.3.1). Other parameters for the endpoint SHOULD be copied from the 670 existing parameters of the association (e.g. number of outbound 671 streams) into the INIT ACK and cookie. 673 After sending out the INIT ACK, the endpoint shall take no further 674 actions, i.e., the existing association, including its current state, 675 and the corresponding TCB MUST NOT be changed. 677 Note: Only when a TCB exists and the association is not in a COOKIE- 678 WAIT state are the Tie-Tags populated. For a normal association INIT 679 (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be 680 set to 0 (indicating that no previous TCB existed). The INIT ACK and 681 State Cookie are populated as specified in section 5.2.1. 683 --------- 684 New text: (Section 5.2.2) 685 --------- 687 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 688 COOKIE-WAIT and SHUTDOWN-ACK-SENT 690 Unless otherwise stated, upon reception of an unexpected INIT for 691 this association, the endpoint shall generate an INIT ACK with a 692 State Cookie. Before responding the endpoint MUST check to see if the 693 unexpected INIT adds new addresses to the association. If new 694 addresses are added to the association, the endpoint MUST respond 695 with an ABORT copying the 'Initiation Tag' of the unexpected INIT 696 into the 'Verification Tag' of the outbound packet carrying the ABORT. 697 In the ABORT response the cause of error SHOULD be set to 'restart 698 of an association with new addresses'. The error SHOULD list the 699 addresses that were added to the restarting association. 701 If no new addresses are added, when responding to the INIT in the 702 outbound INIT ACK the endpoint MUST copy its current Verification Tag 703 and peer's Verification Tag into a reserved place within the state 704 cookie. We shall refer to these locations as the Peer's-Tie-Tag and 705 the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK 706 MUST carry a Verification Tag value equal to the Initiation Tag found 707 in the unexpected INIT. And the INIT ACK MUST contain a new 708 Initiation Tag (randomly generated see Section 5.3.1). Other 709 parameters for the endpoint SHOULD be copied from the existing 710 parameters of the association (e.g. number of outbound streams) into 711 the INIT ACK and cookie. 713 After sending out the INIT ACK or ABORT, the endpoint shall take no 714 further actions, i.e., the existing association, including its 715 current state, and the corresponding TCB MUST NOT be changed. 717 Note: Only when a TCB exists and the association is not in a COOKIE- 718 WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags 719 populated with a value other than 0. For a normal association INIT 720 (i.e. the endpoint is in the CLOSED state), the Tie-Tags MUST be set 721 to 0 (indicating that no previous TCB existed). 723 2.6.3 Solution description 725 A new error code is being added and specific instructions to send 726 back an ABORT to a new association in a restart case or collision 727 case, where new addresses have been added. The error code can be used 728 by a legitimate restart to inform the endpoint that it has made a 729 software error in adding a new address. The endpoint then can choose 730 to wait until the OOTB ABORT tears down the old association, or 731 restart without the new address. 733 Also the Note at the end of section 5.2.2 explaining the use of the 734 Tie-Tags was modified to properly explain the states in which the 735 Tie-Tags should be set to a value different than 0. 737 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes 739 2.7.1 Description of the problem 741 Some implementations were having difficulty growing their cwnd. This 742 was due to an improper enforcement of the congestion control rules. 743 The rules, as written, provided for a slop over of the cwnd value. 744 Without this slop over the sender would appear to NOT be using its 745 full cwnd value and thus never increase it. 747 2.7.2 Text changes to the document 749 --------- 750 Old text: (Section 6.1) 751 --------- 753 B) At any given time, the sender MUST NOT transmit new data to a 754 given transport address if it has cwnd or more bytes of data 755 outstanding to that transport address. 757 --------- 758 New text: (Section 6.1) 759 --------- 761 B) At any given time, the sender MUST NOT transmit new data to a 762 given transport address if it has cwnd or more bytes of data 763 outstanding to that transport address. The sender may exceed cwnd 764 by up to (PMTU-1) bytes on a new transmission if the cwnd is not 765 currently exceeded. 767 2.7.3 Solution description 769 The text changes make clear the ability to go over the cwnd value by 770 no more than (PMTU-1) bytes. 772 2.8 Issues with Fast Retransmit 774 2.8.1 Description of the problem 776 Several problems were found in the current specification of fast 777 retransmit. The current wording did not require GAP ACK blocks to be 778 sent, even though they are essential to the workings of SCTP's 779 congestion control. The specification left unclear how to handle the 780 fast retransmit cycle, having the implementation to wait on the cwnd 781 to retransmit a TSN that was marked for fast retransmit. No limit was 782 placed on how many times a TSN could be fast retransmitted. Fast 783 Recovery was not specified, causing the congestion window to be 784 reduced drastically when there are multiple losses in a single RTT. 786 2.8.2 Text changes to the document 788 --------- 789 Old text: (Section 6.2) 790 --------- 792 Acknowledgments MUST be sent in SACK chunks unless shutdown was 793 requested by the ULP in which case an endpoint MAY send an 794 acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge 795 the reception of multiple DATA chunks. See Section 3.3.4 for SACK 796 chunk format. In particular, the SCTP endpoint MUST fill in the 797 Cumulative TSN Ack field to indicate the latest sequential TSN (of a 798 valid DATA chunk) it has received. Any received DATA chunks with TSN 799 greater than the value in the Cumulative TSN Ack field SHOULD also be 800 reported in the Gap Ack Block fields. 802 --------- 803 New text: (Section 6.2) 804 --------- 806 Acknowledgments MUST be sent in SACK chunks unless shutdown was 807 requested by the ULP in which case an endpoint MAY send an 808 acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge 809 the reception of multiple DATA chunks. See Section 3.3.4 for SACK 810 chunk format. In particular, the SCTP endpoint MUST fill in the 811 Cumulative TSN Ack field to indicate the latest sequential TSN (of a 812 valid DATA chunk) it has received. Any received DATA chunks with 813 TSN greater than the value in the Cumulative TSN Ack field are reported 814 in the Gap Ack Block fields. The SCTP endpoint MUST report as many 815 Gap Ack Blocks that can fit in a single SACK chunk limited by the 816 current path MTU. 818 --------- 819 Old text: (Section 7.2.4) 820 --------- 822 Whenever an endpoint receives a SACK that indicates some TSN(s) 823 missing, it SHOULD wait for 3 further miss indications (via 824 subsequent SACK's) on the same TSN(s) before taking action with 825 regard to Fast Retransmit. 827 When the TSN(s) is reported as missing in the fourth consecutive 828 SACK, the data sender shall: 830 1) Mark the missing DATA chunk(s) for retransmission, 832 2) Adjust the ssthresh and cwnd of the destination address(es) to 833 which the missing DATA chunks were last sent, according to the 834 formula described in Section 7.2.3. 836 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 837 marked for retransmission will fit into a single packet, subject 838 to constraint of the path MTU of the destination transport address 839 to which the packet is being sent. Call this value K. Retransmit 840 those K DATA chunks in a single packet. 842 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 843 outstanding TSN number sent to that address, or the endpoint is 844 retransmitting the first outstanding DATA chunk sent to that 845 address. 847 Note: Before the above adjustments, if the received SACK also 848 acknowledges new DATA chunks and advances the Cumulative TSN Ack 849 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 850 must be applied first. 852 A straightforward implementation of the above keeps a counter for 853 each TSN hole reported by a SACK. The counter increments for each 854 consecutive SACK reporting the TSN hole. After reaching 4 and 855 starting the fast retransmit procedure, the counter resets to 0. 856 Because cwnd in SCTP indirectly bounds the number of outstanding 857 TSN's, the effect of TCP fast-recovery is achieved automatically with 858 no adjustment to the congestion control window size. 860 --------- 861 New text: (Section 7.2.4) 862 --------- 864 Whenever an endpoint receives a SACK that indicates some TSN(s) 865 missing, it SHOULD wait for 3 further miss indications (via 866 subsequent SACK's) on the same TSN(s) before taking action with 867 regard to Fast Retransmit. 869 Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged) 870 algorithm. For each incoming SACK, miss indications are incremented only 871 for missing TSNs prior to the highest TSN newly acknowledged in the 872 SACK. A newly acknowledged DATA chunk is one not previously acknowledged 873 in a SACK. If an endpoint is in Fast Recovery and a SACK arrives that 874 advances the Cumulative TSN Ack Point, the miss indications are 875 incremented for all TSNs reported missing in the SACK. 877 When the fourth consecutive miss indication is recieved for a TSN(s), the 878 data sender shall: 880 1) Mark the DATA chunk(s) with four miss indications for retransmission. 882 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the 883 destination address(es) to which the missing DATA chunks were last 884 sent, according to the formula described in Section 7.2.3. 886 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 887 marked for retransmission will fit into a single packet, subject 888 to constraint of the path MTU of the destination transport address 889 to which the packet is being sent. Call this value K. Retransmit 890 those K DATA chunks in a single packet. When a Fast Retransmit is 891 being performed the sender SHOULD ignore the value of cwnd and 892 SHOULD NOT delay retransmission for this single packet. 894 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 895 outstanding TSN number sent to that address, or the endpoint is 896 retransmitting the first outstanding DATA chunk sent to that 897 address. 899 5) Mark the DATA chunk(s) as being fast retransmitted and thus 900 ineligible for a subsequent fast retransmit. Those TSNs marked 901 for retransmission due to the Fast Retransmit algorithm that 902 did not fit in the sent datagram carrying K other TSNs are also 903 marked as ineligible for a subsequent fast retransmit. However, 904 as they are marked for retransmission they will be retransmitted 905 later on as soon as cwnd allows. 907 6) If not in Fast Recovery, enter Fast Recovery and mark the highest 908 outstanding TSN as the Fast Recovery exit point. When a SACK 909 acknowledges all TSNs up to and including this exit point, Fast 910 Recovery is exited. While in Fast Recovery, the ssthresh and cwnd 911 SHOULD NOT change for any destinations. 913 Note: Before the above adjustments, if the received SACK also 914 acknowledges new DATA chunks and advances the Cumulative TSN Ack 915 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 916 must be applied first. 918 2.8.3 Solution description 920 The effect of the above wording changes are as follows: 922 o It requires with a MUST the sending of GAP Ack blocks instead of 923 the current RFC2960 [5] SHOULD. 925 o It allows a TSN being Fast Retransmitted (FR) to be sent only once 926 via FR. 928 o It ends the delay in awaiting for the flight size to drop when a 929 TSN is identified ready to FR. 931 o It changes the way chunks are marked during fast retransmit, so 932 that only new reports are counted. 934 o It introduces a Fast Recovery period to avoid multiple congestion 935 window reductions when there are multiple losses in a single RTT 936 (as shown by Caro et al. [3]). 938 These changes will effectively allow SCTP to follow a similar model 939 as TCP+SACK in the handling of Fast Retransmit. 941 2.9 Missing statement about partial_bytes_acked update 943 2.9.1 Description of the problem 945 SCTP uses four control variables to regulate its transmission rate: 947 rwnd, cwnd, ssthresh and partial_bytes_acked. Upon detection of 948 packet losses from SACK or when the T3-rtx timer expires on an 949 address cwnd and ssthresh should be updated as stated in section 950 7.2.3. However, that section should also clarify that 951 partial_bytes_acked must be updated as well, having to be reset to 0. 953 2.9.2 Text changes to the document 955 --------- 956 Old text: (Section 7.2.3) 957 --------- 959 7.2.3 Congestion Control 961 Upon detection of packet losses from SACK (see Section 7.2.4), An 962 endpoint should do the following: 964 ssthresh = max(cwnd/2, 2*MTU) 965 cwnd = ssthresh 967 Basically, a packet loss causes cwnd to be cut in half. 969 When the T3-rtx timer expires on an address, SCTP should perform slow 970 start by: 972 ssthresh = max(cwnd/2, 2*MTU) 973 cwnd = 1*MTU 975 --------- 976 New text: (Section 7.2.3) 977 --------- 979 7.2.3 Congestion Control 981 Upon detection of packet losses from SACK (see Section 7.2.4), an 982 endpoint should do the following if not in Fast Recovery: 984 ssthresh = max(cwnd/2, 2*MTU) 985 cwnd = ssthresh 986 partial_bytes_acked = 0 988 Basically, a packet loss causes cwnd to be cut in half. 990 When the T3-rtx timer expires on an address, SCTP should perform slow 991 start by: 993 ssthresh = max(cwnd/2, 2*MTU) 994 cwnd = 1*MTU 995 partial_bytes_acked = 0 997 2.9.3 Solution description 999 The missing text added solves the doubts about what to do with 1000 partial_bytes_acked in the situations stated in section 7.2.3, making 1001 clear that along with ssthresh and cwnd, partial_bytes_acked should 1002 also be updated, having to be reset to 0. 1004 2.10 Issues with Heartbeating and failure detection 1006 2.10.1 Description of the problem 1008 Five basic problems have been discovered with the current heartbeat 1009 procedures: 1011 o The current specification does not specify that you should count a 1012 failed heartbeat as an error against the overall association. 1014 o The current specification is un-specific as to when you start 1015 sending heartbeats and when you should stop. 1017 o The current specification is un-specific as to when you should 1018 respond to heartbeats. 1020 o When responding to a Heartbeat it is unclear what to do if more 1021 than a single TLV is present. 1023 o The jitter applied to a heartbeat was meant to be a small variance 1024 of the RTO and is currently a wide variance due to the default 1025 delay time and incorrect wording within the RFC. 1027 2.10.2 Text changes to the document 1029 --------- 1030 Old text: (Section 8.1) 1031 --------- 1033 8.1 Endpoint Failure Detection 1035 An endpoint shall keep a counter on the total number of consecutive 1036 retransmissions to its peer (including retransmissions to all the 1037 destination transport addresses of the peer if it is multi-homed). 1038 If the value of this counter exceeds the limit indicated in the 1039 protocol parameter 'Association.Max.Retrans', the endpoint shall 1040 consider the peer endpoint unreachable and shall stop transmitting 1041 any more data to it (and thus the association enters the CLOSED 1042 state). In addition, the endpoint shall report the failure to the 1043 upper layer, and optionally report back all outstanding user data 1044 remaining in its outbound queue. The association is automatically 1045 closed when the peer endpoint becomes unreachable. 1047 The counter shall be reset each time a DATA chunk sent to that peer 1048 endpoint is acknowledged (by the reception of a SACK), or a 1049 HEARTBEAT-ACK is received from the peer endpoint. 1051 --------- 1052 New text: (Section 8.1) 1053 --------- 1055 8.1 Endpoint Failure Detection 1057 An endpoint shall keep a counter on the total number of consecutive 1058 retransmissions to its peer (this includes retransmissions to all the 1059 destination transport addresses of the peer if it is multi-homed), 1060 including unacknowledged HEARTBEAT Chunks. If the value of this 1061 counter exceeds the limit indicated in the protocol parameter 1062 'Association.Max.Retrans', the endpoint shall consider the peer 1063 endpoint unreachable and shall stop transmitting any more data to it 1064 (and thus the association enters the CLOSED state). In addition, the 1065 endpoint shall report the failure to the upper layer, and optionally 1066 report back all outstanding user data remaining in its outbound 1067 queue. The association is automatically closed when the peer 1068 endpoint becomes unreachable. 1070 The counter shall be reset each time a DATA chunk sent to that peer 1071 endpoint is acknowledged (by the reception of a SACK), or a 1072 HEARTBEAT-ACK is received from the peer endpoint. 1074 --------- 1075 Old text: (Section 8.3) 1076 --------- 1078 8.3 Path Heartbeat 1080 By default, an SCTP endpoint shall monitor the reachability of the 1081 idle destination transport address(es) of its peer by sending a 1082 HEARTBEAT chunk periodically to the destination transport 1083 address(es). 1085 --------- 1086 New text: (Section 8.3) 1087 --------- 1088 8.3 Path Heartbeat 1090 By default, an SCTP endpoint shall monitor the reachability of the 1091 idle destination transport address(es) of its peer by sending a 1092 HEARTBEAT chunk periodically to the destination transport 1093 address(es). HEARTBEAT sending MAY begin upon reaching the 1094 ESTABLISHED state, and is discontinued after sending either SHUTDOWN 1095 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 1096 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 1097 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 1098 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the 1099 SHUTDOWN-ACK-SENT state (SHUTDOWN receiver). 1101 --------- 1102 Old text: (Section 8.3) 1103 --------- 1105 The receiver of the HEARTBEAT should immediately respond with a 1106 HEARTBEAT ACK that contains the Heartbeat Information field copied 1107 from the received HEARTBEAT chunk. 1109 --------- 1110 New text: (Section 8.3) 1111 --------- 1113 The receiver of the HEARTBEAT should immediately respond with a 1114 HEARTBEAT ACK that contains the Heartbeat Information TLV, together 1115 with any other received TLVs, copied unchanged from the received 1116 HEARTBEAT chunk. 1118 --------- 1119 Old text: (Section 8.3) 1120 --------- 1122 On an idle destination address that is allowed to heartbeat, a 1123 HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that 1124 destination address plus the protocol parameter 'HB.interval' , with 1125 jittering of +/- 50%, and exponential back-off of the RTO if the 1126 previous HEARTBEAT is unanswered. 1128 --------- 1129 New text: (Section 8.3) 1130 --------- 1132 On an idle destination address that is allowed to heartbeat, a 1133 HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that 1134 destination address plus the protocol parameter 'HB.interval' , with 1135 jittering of +/- 50% of the RTO value, and exponential back-off 1136 of the RTO if the previous HEARTBEAT is unanswered. 1138 2.10.3 Solution description 1140 The above text provides guidance as to how to respond to the five 1141 issues mentioned in Section 2.10.1 In particular the wording changes 1142 provide guidance as to when to start and stop heartbeating, how to 1143 respond to a heartbeat with extra parameters, and clarifies the error 1144 counting procedures for the association. 1146 2.11 Security interactions with firewalls 1148 2.11.1 Description of the problem 1150 When dealing with firewalls it is advantageous to the firewall to be 1151 able to properly determine the initial startup sequence of a reliable 1152 transport protocol. With this in mind the following text is to be 1153 added to SCTP's security section. 1155 2.11.2 Text changes to the document 1157 --------- 1158 New text: (no old text, new section added) 1159 --------- 1161 11.4 SCTP interactions with firewalls 1163 It is helpful for some firewalls if they can inspect 1164 just the first fragment of a fragmented SCTP packet and unambiguously 1165 determine whether it corresponds to an INIT chunk (for further information 1166 please refer to RFC1858). Accordingly, we 1167 stress the requirements stated in 3.1 that (1) an INIT chunk MUST NOT 1168 be bundled with any other chunk in a packet, and (2) a packet 1169 containing an INIT chunk MUST have a zero Verification Tag. 1170 Furthermore, we require that the receiver of an INIT chunk MUST 1171 enforce these rules by silently discarding an arriving packet with an 1172 INIT chunk that is bundled with other chunks. 1174 --------- 1175 Old text: (Section 18) 1176 --------- 1178 18. Bibliography 1180 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 1181 Network Path Properties", Proc. SIGCOMM'99, 1999. 1183 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of 1184 Tahoe, Reno, and SACK TCP, Computer Communications Review, 1185 V. 26 N. 3, July 1996, pp. 5-21. 1187 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 1188 Security", RFC 1750, December 1994. 1190 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format 1191 Specification version 3.3", RFC 1950, May 1996. 1193 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 1194 Hashing for Message Authentication", RFC 2104, March 1997. 1196 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 1197 September 1997. 1199 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1200 Protocol", RFC 2522, March 1999. 1202 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 1203 "TCP Congestion Control with a Misbehaving Receiver", ACM 1204 Computer Communication Review, 29(5), October 1999. 1206 --------- 1207 New text: (Section 18) 1208 --------- 1210 18. References 1212 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 1213 Network Path Properties", Proc. SIGCOMM'99, 1999. 1215 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of 1216 Tahoe, Reno, and SACK TCP, Computer Communications Review, 1217 V. 26 N. 3, July 1996, pp. 5-21. 1219 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 1220 Security", RFC 1750, December 1994. 1222 [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security 1223 Considerations for IP Fragment Filtering", RFC 1858, 1224 October 1995. 1226 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format 1227 Specification version 3.3", RFC 1950, May 1996. 1229 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 1230 Hashing for Message Authentication", RFC 2104, March 1997. 1232 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 1233 September 1997. 1235 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1236 Protocol", RFC 2522, March 1999. 1238 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 1239 "TCP Congestion Control with a Misbehaving Receiver", ACM 1240 Computer Communication Review, 29(5), October 1999. 1242 2.11.3 Solution description 1244 The above text adding a new subsection to the Security Considerations 1245 section of RFC2960 [5] makes clear that, to make easier the 1246 interaction with firewalls, an INIT chunk must not be bundled in any 1247 case with any other chunk, being this rule enforced by the packet 1248 receiver, that will silently discard the packets that do not follow 1249 this rule. 1251 2.12 Shutdown ambiguity 1253 2.12.1 Description of the problem 1255 Currently there is an ambiguity between the statements in section 6.2 1256 and section 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk 1257 in place of a SACK when the sender is in the process of shutting 1258 down, while section 9.2 requires both a SHUTDOWN chunk and a SACK 1259 chunk to be sent. 1261 Along with this ambiguity there is a problem where in an errant 1262 SHUTDOWN receiver may fail to stop accepting user data. 1264 2.12.2 Text changes to the document 1266 --------- 1267 Old text: (Section 9.2) 1268 --------- 1270 If there are still outstanding DATA chunks left, the SHUTDOWN 1271 receiver shall continue to follow normal data transmission procedures 1272 defined in Section 6 until all outstanding DATA chunks are 1273 acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data 1274 from its SCTP user. 1276 While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately 1277 respond to each received packet containing one or more DATA chunk(s) 1278 with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If 1279 it has no more outstanding DATA chunks, the SHUTDOWN receiver shall 1280 send a SHUTDOWN ACK and start a T2-shutdown timer of its own, 1281 entering the SHUTDOWN-ACK-SENT state. If the timer expires, the 1282 endpoint must re-send the SHUTDOWN ACK. 1284 --------- 1285 New text: (Section 9.2) 1286 --------- 1288 If there are still outstanding DATA chunks left, the SHUTDOWN 1289 receiver shall continue to follow normal data transmission procedures 1290 defined in Section 6 until all outstanding DATA chunks are 1291 acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data 1292 from its SCTP user. 1294 While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately 1295 respond to each received packet containing one or more DATA chunk(s) 1296 with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a 1297 SHUTDOWN chunk by itself cannot acknowledge all of the received DATA 1298 chunks (i.e. there are TSN's that can be acknowledged that are larger 1299 than the cumulative TSN and thus gaps exist in the TSN sequence) or 1300 if duplicate TSN's have been recieved then a SACK chunk MUST also be sent. 1302 The sender of the SHUTDOWN MAY also start an overall guard timer 1303 'T5-shutdown-guard' to bound the overall time for shutdown sequence. 1304 At the expiration of this timer the sender SHOULD abort the 1305 association by sending an ABORT chunk. If the 'T5-shutdown-guard' 1306 timer is used, it SHOULD be set to the recommended value of 5 times 1307 'RTO.Max'. 1309 If the receiver of the SHUTDOWN has no more outstanding DATA chunks, 1310 the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a 1311 T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. 1312 If the timer expires, the endpoint must re-send the SHUTDOWN ACK. 1314 2.12.3 Solution description 1316 The above text clarifies the use of a SACK in conjunction with a 1317 SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown 1318 sequence to protect against errant receivers of SHUTDOWN chunks. 1320 2.13 Inconsistency in ABORT processing 1321 2.13.1 Description of the problem 1323 It was noted that the wording in section 8.5.1 did not give proper 1324 directions in the use of the 'T bit' with the verification tags. 1326 2.13.2 Text changes to the document 1328 --------- 1329 Old text: (Section 8.5.1) 1330 --------- 1332 B) Rules for packet carrying ABORT: 1334 - The endpoint shall always fill in the Verification Tag field of 1335 the outbound packet with the destination endpoint's tag value 1336 if it is known. 1338 - If the ABORT is sent in response to an OOTB packet, the 1339 endpoint MUST follow the procedure described in Section 8.4. 1341 - The receiver MUST accept the packet if the Verification Tag 1342 matches either its own tag, OR the tag of its peer. Otherwise, 1343 the receiver MUST silently discard the packet and take no 1344 further action. 1346 --------- 1347 New text: (Section 8.5.1) 1348 --------- 1350 B) Rules for packet carrying ABORT: 1352 - The endpoint shall always fill in the Verification Tag field of 1353 the outbound packet with the destination endpoint's tag value 1354 if it is known. 1356 - If the ABORT is sent in response to an OOTB packet, the 1357 endpoint MUST follow the procedure described in Section 8.4. 1359 - The receiver of a ABORT shall accept the packet if the 1360 Verification Tag field of the packet matches its own tag OR it 1361 is set to its peer's tag and the T bit is set in the Chunk 1362 Flags. Otherwise, the receiver MUST silently discard the packet 1363 and take no further action. 1365 2.13.3 Solution description 1367 The above text change clarifies that the T bit must be set before an 1368 implementation looks for the peers tag. 1370 2.14 Cwnd gated by its full use 1372 2.14.1 Description of the problem 1374 A problem was found with the current specification of the growth and 1375 decay of cwnd. The cwnd should only be increased if it is being fully 1376 utilized, and after periods of under utilization, the cwnd should be 1377 decreased. In some sections, the current wording is weak and is not 1378 clearly defined. Also, the current specification unnecessarily 1379 introduces the need for special case code to ensure cwnd degradation. 1380 Plus, the cwnd should not be increased during Fast Recovery since a 1381 full cwnd during Fast Recovery does not qualify the cwnd as being 1382 fully utilized. Additionally, multiple loss scenarios in a single 1383 window may cause the cwnd to grow more rapidly as the number of 1384 losses in a window increases [3]. 1386 2.14.2 Text changes to the document 1388 --------- 1389 Old text: (Section 6.1) 1390 --------- 1392 D) Then, the sender can send out as many new DATA chunks as Rule A 1393 and Rule B above allow. 1395 --------- 1396 New text: (Section 6.1) 1397 --------- 1399 D) When the time comes for the sender to transmit new DATA chunks, the 1400 protocol parameter Max.Burst MUST first be applied to limit how many 1401 new DATA chunks may be sent. The limit is applied by adjusting cwnd 1402 as follows: 1404 if((flightsize + Max.Burst*MTU) < cwnd) 1405 cwnd = flightsize + Max.Burst*MTU 1407 E) Then, the sender can send out as many new DATA chunks as Rule A 1408 and Rule B above allow. 1410 --------- 1411 Old text: (Section 7.2.1) 1412 --------- 1414 o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST 1415 use the slow start algorithm to increase cwnd (assuming the 1416 current congestion window is being fully utilized). If an 1417 incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be 1418 increased by at most the lesser of 1) the total size of the 1419 previously outstanding DATA chunk(s) acknowledged, and 2) the 1420 destination's path MTU. This protects against the ACK-Splitting 1421 attack outlined in [SAVAGE99]. 1423 --------- 1424 New text: (Section 7.2.1) 1425 --------- 1427 o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use 1428 the slow start algorithm to increase cwnd only if the current 1429 congestion window is being fully utilized, an incoming SACK advances 1430 the Cumulative TSN Ack Point, and the data sender is not in Fast 1431 Recovery. Only when these three conditions are met can the cwnd be 1432 increased otherwise the cwnd MUST not be increased. If these conditions 1433 are met then cwnd MUST be increased by at most the lesser of 1) the 1434 total size of the previously outstanding DATA chunk(s) acknowledged, 1435 and 2) the destination's path MTU. This protects against the 1436 ACK-Splitting attack outlined in [SAVAGE99]. 1438 --------- 1439 Old text: (Section 7.2.1) 1440 --------- 1442 o When the endpoint does not transmit data on a given transport 1443 address, the cwnd of the transport address should be adjusted to 1444 max(cwnd/2, 2*MTU) per RTO. 1446 --------- 1447 New text: (Section 7.2.1) 1448 --------- 1450 o When the association does not transmit data on a given transport address 1451 within an RTO, the cwnd of the transport address SHOULD be adjusted to 1452 2*MTU. 1454 --------- 1455 Old text: (Section 7.2.2) 1456 --------- 1458 o Same as in the slow start, when the sender does not transmit DATA 1459 on a given transport address, the cwnd of the transport address 1460 should be adjusted to max(cwnd / 2, 2*MTU) per RTO. 1462 --------- 1463 New text: (Section 7.2.2) 1464 --------- 1466 o Same as in the slow start, when the sender does not transmit DATA on 1467 a given transport address within an RTO, the cwnd of the transport 1468 address should be adjusted to 2*MTU. 1470 --------- 1471 Old text: (Section 14) 1472 --------- 1474 14. Suggested SCTP Protocol Parameter Values 1476 The following protocol parameters are RECOMMENDED: 1478 RTO.Initial - 3 seconds 1479 RTO.Min - 1 second 1480 RTO.Max - 60 seconds 1481 RTO.Alpha - 1/8 1482 RTO.Beta - 1/4 1483 Valid.Cookie.Life - 60 seconds 1484 Association.Max.Retrans - 10 attempts 1485 Path.Max.Retrans - 5 attempts (per destination address) 1486 Max.Init.Retransmits - 8 attempts 1487 HB.interval - 30 seconds 1489 --------- 1490 New text: (Section 14) 1491 --------- 1493 14. Suggested SCTP Protocol Parameter Values 1495 The following protocol parameters are RECOMMENDED: 1497 RTO.Initial - 3 seconds 1498 RTO.Min - 1 second 1499 RTO.Max - 60 seconds 1500 Max.Burst - 4 1501 RTO.Alpha - 1/8 1502 RTO.Beta - 1/4 1503 Valid.Cookie.Life - 60 seconds 1504 Association.Max.Retrans - 10 attempts 1505 Path.Max.Retrans - 5 attempts (per destination address) 1506 Max.Init.Retransmits - 8 attempts 1507 HB.Interval - 30 seconds 1509 2.14.3 Solution description 1511 The above changes strengthens the rules and makes it much more 1512 apparent as to the need to block cwnd growth when the full cwnd is 1513 not being utilized. The changes also applies cwnd degradation without 1514 introducing the need for complex special case code. 1516 2.15 Window probes in SCTP 1518 2.15.1 Description of the problem 1520 When a receiver clamps its rwnd to 0 to flow control the peer, the 1521 specification implies that one must continue to accept data from the 1522 remote peer. This is incorrect and needs clarification. 1524 2.15.2 Text changes to the document 1526 --------- 1527 Old text: (Section 6.2) 1528 --------- 1530 The SCTP endpoint MUST always acknowledge the reception of each valid 1531 DATA chunk. 1533 --------- 1534 New text: (Section 6.2) 1535 --------- 1537 The SCTP endpoint MUST always acknowledge the reception of each 1538 valid DATA chunk when the DATA chunk received is inside its receive 1539 window. 1541 When the receiver's advertised window is 0, the receiver MUST drop 1542 all new incoming DATA chunk and immediately send back a SACK with 1543 the current receive window showing only DATA chunks received and 1544 accepted so far. The dropped DATA chunk MUST NOT be included in the 1545 SACK as they were not accepted. The receiver MUST also have an 1546 algorithm for advertising its receive window to avoid receiver silly 1547 window syndrome (SWS) as described in RFC 813. The algorithm can be 1548 similar to the one described in Section 4.2.3.3 of RFC 1122. 1549 Because of receiver SWS avoidance, even when the receiver's internal 1550 buffer is not full anymore, as long as the advertised window is 1551 still 0, the receiver MUST still drop all new incoming DATA chunk. 1553 --------- 1554 Old text: (Section 6.1) 1555 --------- 1556 A) At any given time, the data sender MUST NOT transmit new data to 1557 any destination transport address if its peer's rwnd indicates 1558 that the peer has no buffer space (i.e. rwnd is 0, see Section 1559 6.2.1). However, regardless of the value of rwnd (including if it 1560 is 0), the data sender can always have one DATA chunk in flight to 1561 the receiver if allowed by cwnd (see rule B below). This rule 1562 allows the sender to probe for a change in rwnd that the sender 1563 missed due to the SACK having been lost in transit from the data 1564 receiver to the data sender. 1566 --------- 1567 New text: (Section 6.1) 1568 --------- 1570 A) At any given time, the data sender MUST NOT transmit new data to 1571 any destination transport address if its peer's rwnd indicates 1572 that the peer has no buffer space (i.e. rwnd is 0, see Section 1573 6.2.1). However, regardless of the value of rwnd (including if it 1574 is 0), the data sender can always have one DATA chunk in flight to 1575 the receiver if allowed by cwnd (see rule B below). This rule 1576 allows the sender to probe for a change in rwnd that the sender 1577 missed due to the SACK having been lost in transit from the data 1578 receiver to the data sender. 1580 When the receiver's advertised window is zero, this probe is called 1581 a zero window probe. Note that zero window probe SHOULD only be sent 1582 when all outstanding DATA chunks have been cumulatively acknowledged 1583 and no DATA chunk(s) are in flight. Zero window probing MUST 1584 be supported. 1586 When a sender is doing zero window probing, it should not time 1587 out the association if it continues to receive new packets from 1588 the receiver. The reason is that the receiver MAY keep its window 1589 closed for an indefinite time. Refer to Section 6.2 on the receiver 1590 behavior when it advertises a zero window. The sender SHOULD 1591 send the first zero window probe after 1 RTO when it detects that 1592 the receiver has closed its window, and SHOULD increase the probe 1593 interval exponentially afterwards. Also note that the cwnd SHOULD 1594 be adjusted according to Section 7.2.1. Zero window probing does 1595 not affect the calculation of cwnd. 1597 The sender MUST also have algorithm in sending new DATA chunks to 1598 avoid silly window syndrome (SWS) as described in RFC 813. The 1599 algorithm can be similar to the one described in Section 4.2.3.4 1600 of RFC 1122. 1602 2.15.3 Solution description 1604 The above allows a receiver to drop new data that arrives and yet 1605 still requires the receiver to send a SACK showing the conditions 1606 unchanged (with the possible exception of a new a_rwnd) and the 1607 dropped chunk as missing. This will allow the association to continue 1608 until the rwnd condition clears. 1610 2.16 Fragmentation and Path MTU issues 1612 2.16.1 Description of the problem 1614 The current wording of the Fragmentation and Reassembly forces an 1615 implementation that supports fragmentation to always fragment. This 1616 prohibits an implementation from offering its users an option to 1617 disable sends that exceed the SCTP fragmentation point. 1619 The restriction in RFC2960 [5] section 6.9 was never meant to 1620 restrict an implementations API from this behavior. 1622 2.16.2 Text changes to the document 1624 --------- 1625 Old text: (Section 6.1) 1626 --------- 1628 6.9 Fragmentation and Reassembly 1630 An endpoint MAY support fragmentation when sending DATA chunks, but 1631 MUST support reassembly when receiving DATA chunks. If an endpoint 1632 supports fragmentation, it MUST fragment a user message if the size 1633 of the user message to be sent causes the outbound SCTP packet size 1634 to exceed the current MTU. If an implementation does not support 1635 fragmentation of outbound user messages, the endpoint must return an 1636 error to its upper layer and not attempt to send the user message. 1638 IMPLEMENTATION NOTE: In this error case, the Send primitive 1639 discussed in Section 10.1 would need to return an error to the upper 1640 layer. 1642 --------- 1643 New text: (Section 6.1) 1644 --------- 1646 6.9 Fragmentation and Reassembly 1648 An endpoint MAY support fragmentation when sending DATA chunks, but 1649 MUST support reassembly when receiving DATA chunks. If an endpoint 1650 supports fragmentation, it MUST fragment a user message if the size 1651 of the user message to be sent causes the outbound SCTP packet size 1652 to exceed the current MTU. If an implementation does not support 1653 fragmentation of outbound user messages, the endpoint must return an 1654 error to its upper layer and not attempt to send the user message. 1656 Note: If an implementation that supports fragmentation makes 1657 available to its upper layer a mechanism to turn off fragmentation 1658 it may do so. However in so doing, it MUST react just like an 1659 implementation that does NOT support fragmentation i.e. it MUST 1660 reject sends that exceed the current P-MTU. 1662 IMPLEMENTATION NOTE: In this error case, the Send primitive 1663 discussed in Section 10.1 would need to return an error to the upper 1664 layer. 1666 2.16.3 Solution description 1668 The above wording will allow an implementation to offer the option of 1669 rejecting sends that exceed the P-MTU size even when the 1670 implementation supports fragmentation. 1672 2.17 Initial value of the cumulative TSN Ack 1674 2.17.1 Description of the problem 1676 The current description of the SACK chunk within the RFC does not 1677 clearly state the value that would be put within a SACK when no DATA 1678 chunk has been received. 1680 2.17.2 Text changes to the document 1682 --------- 1683 Old text: (Section 3.3.4) 1684 --------- 1686 Cumulative TSN Ack: 32 bits (unsigned integer) 1688 This parameter contains the TSN of the last DATA chunk received in 1689 sequence before a gap. 1691 --------- 1692 New text: (Section 3.3.4) 1693 --------- 1695 Cumulative TSN Ack: 32 bits (unsigned integer) 1696 This parameter contains the TSN of the last DATA chunk received in 1697 sequence before a gap. In the case where no DATA chunk has 1698 been received, this value is set to the peers Initial TSN minus 1699 one. 1701 2.17.3 Solution description 1703 This change clearly states what the initial value will be for a SACK 1704 sender. 1706 2.18 Handling of address parameters within the INIT or INIT-ACK 1708 2.18.1 Description of the problem 1710 The current description on handling address parameters contained 1711 within the INIT and INIT-ACK do not fully describe a requirement for 1712 their handling. 1714 2.18.2 Text changes to the document 1716 --------- 1717 Old text: (Section 5.1.2) 1718 --------- 1720 C) If there are only IPv4/IPv6 addresses present in the received INIT 1721 or INIT ACK chunk, the receiver shall derive and record all the 1722 transport address(es) from the received chunk AND the source IP 1723 address that sent the INIT or INIT ACK. The transport address(es) 1724 are derived by the combination of SCTP source port (from the 1725 common header) and the IP address parameter(s) carried in the INIT 1726 or INIT ACK chunk and the source IP address of the IP datagram. 1727 The receiver should use only these transport addresses as 1728 destination transport addresses when sending subsequent packets to 1729 its peer. 1731 --------- 1732 New text: (Section 5.1.2) 1733 --------- 1735 C) If there are only IPv4/IPv6 addresses present in the received INIT 1736 or INIT ACK chunk, the receiver shall derive and record all the 1737 transport address(es) from the received chunk AND the source IP 1738 address that sent the INIT or INIT ACK. The transport address(es) 1739 are derived by the combination of SCTP source port (from the 1740 common header) and the IP address parameter(s) carried in the INIT 1741 or INIT ACK chunk and the source IP address of the IP datagram. 1743 The receiver should use only these transport addresses as 1744 destination transport addresses when sending subsequent packets to 1745 its peer. 1747 D) An INIT or INIT ACK chunk MUST be treated as belonging 1748 to an already established association (or one in the 1749 process of being established) if the use of any of the 1750 valid address parameters contained within the chunk 1751 would identify an existing TCB. 1753 2.18.3 Solution description 1755 This new text clearly specifies to an implementor the need to look 1756 within the INIT or INIT ACK. Any implementation that does not do 1757 this, may for example not be able to recognize an INIT chunk coming 1758 from an already established association that adds new addresses (see 1759 section 2.6), or an incoming INIT ACK chunk sent from a source 1760 address different to the destination address used to send the INIT 1761 chunk. 1763 2.19 Handling of stream shortages 1765 2.19.1 Description of the problem 1767 The current wording in the RFC places the choice of sending an ABORT 1768 upon the SCTP stack when a stream shortage occurs. This decision 1769 should really be made by the upper layer not the SCTP stack. 1771 2.19.2 Text changes to the document 1773 --------- 1774 Old text: 1775 --------- 1777 5.1.1 Handle Stream Parameters 1779 In the INIT and INIT ACK chunks, the sender of the chunk shall 1780 indicate the number of outbound streams (OS) it wishes to have in the 1781 association, as well as the maximum inbound streams (MIS) it will 1782 accept from the other endpoint. 1784 After receiving the stream configuration information from the other 1785 side, each endpoint shall perform the following check: If the peer's 1786 MIS is less than the endpoint's OS, meaning that the peer is 1787 incapable of supporting all the outbound streams the endpoint wants 1788 to configure, the endpoint MUST either use MIS outbound streams, or 1789 abort the association and report to its upper layer the resources 1790 shortage at its peer. 1792 --------- 1793 New text: (Section 5.1.2) 1794 --------- 1796 5.1.1 Handle Stream Parameters 1798 In the INIT and INIT ACK chunks, the sender of the chunk shall 1799 indicate the number of outbound streams (OS) it wishes to have in the 1800 association, as well as the maximum inbound streams (MIS) it will 1801 accept from the other endpoint. 1803 After receiving the stream configuration information from the other 1804 side, each endpoint shall perform the following check: If the peer's 1805 MIS is less than the endpoint's OS, meaning that the peer is 1806 incapable of supporting all the outbound streams the endpoint wants 1807 to configure, the endpoint MUST use MIS outbound streams and MAY 1808 report any shortage to the upper layer. The upper layer can then 1809 choose to abort the association if the resource shortage 1810 is unacceptable. 1812 2.19.3 Solution description 1814 The above changes take the decision to ABORT out of the realm of the 1815 SCTP stack and places it into the users hands. 1817 2.20 Indefinite postponement 1819 2.20.1 Description of the problem 1821 The current RFC does not provide any guidance on the assignment of 1822 TSN sequence numbers to outbound message nor reception of these 1823 message. This could lead to a possible indefinite postponement. 1825 2.20.2 Text changes to the document 1827 --------- 1828 Old text: (Section 6.1) 1829 --------- 1831 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1832 1 above the beginning TSN of the current send window. 1834 6.2 Acknowledgment on Reception of DATA Chunks 1836 --------- 1837 New text: (Section 6.1) 1838 --------- 1840 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1841 1 above the beginning TSN of the current send window. 1843 The algorithm by which an implementation assigns sequential TSNs to 1844 messages on a particular association MUST ensure that no user 1845 message that has been accepted by SCTP is indefinitely postponed 1846 from being assigned a TSN. Acceptable algorithms for assigning TSNs 1847 include 1849 (a) assigning TSNs in round-robin order over all streams with 1850 pending data 1852 (b) preserving the linear order in which the user messages were 1853 submitted to the SCTP association. 1855 When an upper layer requests to read data on an SCTP association, 1856 the SCTP receiver SHOULD choose the message with the lowest TSN from 1857 among all deliverable messages. In SCTP implementations that allow a 1858 user to request data on a specific stream, this operation SHOULD NOT 1859 block if data is not available, since this can lead to a deadlock 1860 under certain conditions. 1862 6.2 Acknowledgment on Reception of DATA Chunks 1864 2.20.3 Solution description 1866 The above wording clarifies how TSNs SHOULD be assigned by the 1867 sender. 1869 2.21 User initiated abort of an association 1871 2.21.1 Description of the problem 1873 It is not possible for an upper layer to abort the association and 1874 provide the peer with an indication why the association is aborted. 1876 2.21.2 Text changes to the document 1878 Some of the changes given here already include changes suggested in 1879 section Section 2.6 of this document. 1881 --------- 1882 Old text: (Section 3.3.10) 1883 --------- 1885 Cause Code 1886 Value Cause Code 1887 --------- ---------------- 1888 1 Invalid Stream Identifier 1889 2 Missing Mandatory Parameter 1890 3 Stale Cookie Error 1891 4 Out of Resource 1892 5 Unresolvable Address 1893 6 Unrecognized Chunk Type 1894 7 Invalid Mandatory Parameter 1895 8 Unrecognized Parameters 1896 9 No User Data 1897 10 Cookie Received While Shutting Down 1899 Cause Length: 16 bits (unsigned integer) 1901 Set to the size of the parameter in bytes, including the Cause 1902 Code, Cause Length, and Cause-Specific Information fields 1904 Cause-specific Information: variable length 1906 This field carries the details of the error condition. 1908 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. 1909 Guidelines for the IETF to define new error cause values are 1910 discussed in Section 13.3. 1912 --------- 1913 New text: (Section 3.3.10) 1914 --------- 1916 Cause Code 1917 Value Cause Code 1918 --------- ---------------- 1919 1 Invalid Stream Identifier 1920 2 Missing Mandatory Parameter 1921 3 Stale Cookie Error 1922 4 Out of Resource 1923 5 Unresolvable Address 1924 6 Unrecognized Chunk Type 1925 7 Invalid Mandatory Parameter 1926 8 Unrecognized Parameters 1927 9 No User Data 1928 10 Cookie Received While Shutting Down 1929 11 Restart of an association with new addresses 1930 12 User Initiated Abort 1932 Cause Length: 16 bits (unsigned integer) 1934 Set to the size of the parameter in bytes, including the Cause 1935 Code, Cause Length, and Cause-Specific Information fields 1937 Cause-specific Information: variable length 1939 This field carries the details of the error condition. 1941 Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP. 1942 Guidelines for the IETF to define new error cause values are 1943 discussed in Section 13.3. 1945 --------- 1946 New text: (Note no old text, new error added in section 3.3.10) 1947 --------- 1949 3.3.10.12 User Initiated Abort (12) 1951 Cause of error 1952 -------------- 1954 This error cause MAY be included in ABORT chunks which are send 1955 because of an upper layer request. The upper layer can specify 1956 an Upper Layer Abort Reason which is transported by SCTP 1957 transparently and MAY be delivered to the upper layer protocol 1958 at the peer. 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Cause Code=12 | Cause Length=Variable | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 / Upper Layer Abort Reason / 1964 \\ \\ 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 --------- 1968 Old text: (Section 9.1) 1969 --------- 1971 9.1 Abort of an Association 1973 When an endpoint decides to abort an existing association, it shall 1974 send an ABORT chunk to its peer endpoint. The sender MUST fill in 1975 the peer's Verification Tag in the outbound packet and MUST NOT 1976 bundle any DATA chunk with the ABORT. 1978 An endpoint MUST NOT respond to any received packet that contains an 1979 ABORT chunk (also see Section 8.4). 1981 An endpoint receiving an ABORT shall apply the special Verification 1982 Tag check rules described in Section 8.5.1. 1984 After checking the Verification Tag, the receiving endpoint shall 1985 remove the association from its record, and shall report the 1986 termination to its upper layer. 1988 --------- 1989 New text: (Section 9.1) 1990 --------- 1992 9.1 Abort of an Association 1994 When an endpoint decides to abort an existing association, it shall 1995 send an ABORT chunk to its peer endpoint. The sender MUST fill in 1996 the peer's Verification Tag in the outbound packet and MUST NOT 1997 bundle any DATA chunk with the ABORT. If the association is aborted 1998 on request of the upper layer an User Initiated Abort error cause 1999 (see 3.3.10.12) SHOULD be present in the ABORT chunk. 2001 An endpoint MUST NOT respond to any received packet that contains an 2002 ABORT chunk (also see Section 8.4). 2004 An endpoint receiving an ABORT shall apply the special Verification 2005 Tag check rules described in Section 8.5.1. 2007 After checking the Verification Tag, the receiving endpoint shall 2008 remove the association from its record, and shall report the 2009 termination to its upper layer. If an User Initiated Abort error 2010 cause is present in the ABORT chunk the Upper Layer Abort Reason 2011 shall be made available to the upper layer. 2013 --------- 2014 Old text: (Section 10.1) 2015 --------- 2017 D) Abort 2019 Format: ABORT(association id [, cause code]) 2020 -> result 2022 Ungracefully closes an association. Any locally queued user data 2023 will be discarded and an ABORT chunk is sent to the peer. A success 2024 code will be returned on successful abortion of the association. If 2025 attempting to abort the association results in a failure, an error 2026 code shall be returned. 2028 Mandatory attributes: 2030 o association id - local handle to the SCTP association 2032 Optional attributes: 2034 o cause code - reason of the abort to be passed to the peer. 2036 --------- 2037 New text: (Section 10.1) 2038 --------- 2040 D) Abort 2042 Format: ABORT(association id [, Upper Layer Abort Reason]) 2043 -> result 2045 Ungracefully closes an association. Any locally queued user data 2046 will be discarded and an ABORT chunk is sent to the peer. A success 2047 code will be returned on successful abortion of the association. If 2048 attempting to abort the association results in a failure, an error 2049 code shall be returned. 2051 Mandatory attributes: 2053 o association id - local handle to the SCTP association 2055 Optional attributes: 2057 o Upper Layer Abort Reason - reason of the abort to be passed to the peer. 2059 None. 2061 --------- 2062 Old text: (Section 10.2) 2063 --------- 2065 E) COMMUNICATION LOST notification 2067 When SCTP loses communication to an endpoint completely (e.g., via 2068 Heartbeats) or detects that the endpoint has performed an abort 2069 operation, it shall invoke this notification on the ULP. 2071 The following shall be passed with the notification: 2073 o association id - local handle to the SCTP association 2075 o status - This indicates what type of event has occurred; The status 2076 may indicate a failure OR a normal termination event 2077 occurred in response to a shutdown or abort request. 2079 The following may be passed with the notification: 2081 o data retrieval id - an identification used to retrieve unsent and 2082 unacknowledged data. 2084 o last-acked - the TSN last acked by that peer endpoint; 2086 o last-sent - the TSN last sent to that peer endpoint; 2088 --------- 2089 New text: (Section 10.2) 2090 --------- 2092 E) COMMUNICATION LOST notification 2094 When SCTP loses communication to an endpoint completely (e.g., via 2095 Heartbeats) or detects that the endpoint has performed an abort 2096 operation, it shall invoke this notification on the ULP. 2098 The following shall be passed with the notification: 2100 o association id - local handle to the SCTP association 2102 o status - This indicates what type of event has occurred; The status 2103 may indicate a failure OR a normal termination event 2104 occurred in response to a shutdown or abort request. 2106 The following may be passed with the notification: 2108 o data retrieval id - an identification used to retrieve unsent and 2109 unacknowledged data. 2111 o last-acked - the TSN last acked by that peer endpoint; 2113 o last-sent - the TSN last sent to that peer endpoint; 2115 o Upper Layer Abort Reason - the abort reason specified if case of an user 2116 initiated abort. 2118 2.21.3 Solution description 2120 The above allows an upper layer to provide its peer with an 2121 indication why the association was aborted. Therefore an addition 2122 error cause was introduced. 2124 2.22 Handling of invalid Initiate Tag of INIT-ACK 2126 2.22.1 Description of the problem 2128 RFC 2960 requires that the receiver of an INIT-ACK with the Initiate 2129 Tag set to zero handles this as an error and sends back an ABORT. But 2130 the sender of the INIT-ACK normally has no TCB and so the ABORT is 2131 useless. 2133 2.22.2 Text changes to the document 2135 --------- 2136 Old text: (Section 3.3.3) 2137 --------- 2139 Initiate Tag: 32 bits (unsigned integer) 2141 The receiver of the INIT ACK records the value of the Initiate Tag 2142 parameter. This value MUST be placed into the Verification Tag 2143 field of every SCTP packet that the INIT ACK receiver transmits 2144 within this association. 2146 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for 2147 more on the selection of the Initiate Tag value. 2149 If the value of the Initiate Tag in a received INIT ACK chunk is 2150 found to be 0, the receiver MUST treat it as an error and close 2151 the association by transmitting an ABORT. 2153 --------- 2154 New text: (Section 3.3.3) 2155 --------- 2157 Initiate Tag: 32 bits (unsigned integer) 2159 The receiver of the INIT ACK records the value of the Initiate Tag 2160 parameter. This value MUST be placed into the Verification Tag 2161 field of every SCTP packet that the INIT ACK receiver transmits 2162 within this association. 2164 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for 2165 more on the selection of the Initiate Tag value. 2167 If the value of the Initiate Tag in a received INIT ACK chunk is 2168 found to be 0, the receiver MUST destroy the association discarding 2169 its TCB. The receiver MAY send an ABORT for debugging purpose. 2171 2.22.3 Solution description 2173 The new text does not require the receiver of the invalid INIT-ACK to 2174 send the ABORT. This behavior is in tune with the error case of 2175 invalid stream numbers in the INIT-ACK. However it is allowed to send 2176 an ABORT for debugging purposes. 2178 2.23 ABORT sending in response to an INIT 2180 2.23.1 Description of the problem 2182 Whenever the receiver of an INIT chunk has to send an ABORT chunk in 2183 response for whatever reason it is not stated clearly which 2184 Verification Tag and value of the T-bit should be used. 2186 2.23.2 Text changes to the document 2188 --------- 2189 Old text: (Section 8.4) 2190 --------- 2192 3) If the packet contains an INIT chunk with a Verification Tag set 2193 to '0', process it as described in Section 5.1. Otherwise, 2195 --------- 2196 New text: (Section 8.4) 2197 --------- 2199 3) If the packet contains an INIT chunk with a Verification Tag set 2200 to '0', process it as described in Section 5.1. If, for whatever 2201 reason, the INIT can not be processed normally and an ABORT has to be 2202 sent in response, the Verification Tag of the packet containing the 2203 ABORT chunk MUST be the Initiate tag of the received INIT chunk 2204 and the T-Bit of the ABORT chunk has to be set to 0 indicating that 2205 a TCB was destroyed. Otherwise, 2207 2.23.3 Solution description 2209 The new text stated clearly which value of the Verification Tag and 2210 T-bit have to be used. 2212 2.24 Stream Sequence Number (SSN) Initialization 2214 2.24.1 Description of the problem 2216 RFC 2960 does not describe the fact that the SSN have to be 2217 initialized to 0 in the way it is required by RFC2119. 2219 2.24.2 Text changes to the document 2221 --------- 2222 Old text: (Section 6.5) 2223 --------- 2225 The stream sequence number in all the streams shall start from 0 when 2226 the association is established. Also, when the stream sequence 2227 number reaches the value 65535 the next stream sequence number shall 2228 be set to 0. 2230 --------- 2231 New text: (Section 6.5) 2232 --------- 2234 The stream sequence number in all the streams MUST start from 0 when 2235 the association is established. Also, when the stream sequence 2236 number reaches the value 65535 the next stream sequence number MUST 2237 be set to 0. 2239 2.24.3 Solution description 2241 The 'shall' in the text is replaced by a 'MUST' to clearly state the 2242 required behavior. 2244 2.25 SACK packet format 2246 2.25.1 Description of the problem 2248 It is not clear in RFC 2960 whether a SACK must contain the fields 2249 Number of Gap Ack Blocks and Number of Duplicate TSNs or not. 2251 2.25.2 Text changes to the document 2253 --------- 2254 Old text: (Section 3.3.4) 2255 --------- 2257 The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver 2258 Window Credit (a_rwnd) parameters. 2260 --------- 2261 New text: (Section 3.3.4) 2262 --------- 2264 The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver 2265 Window Credit (a_rwnd), Number of Gap Ack Blocks, and 2266 Number of Duplicate TSNs fields. 2268 2.25.3 Solution description 2270 The text has been modified. It is now clear that a SACK always 2271 contains the fields Number of Gap Ack Blocks and Number of Duplicate 2272 TSNs. 2274 2.26 Protocol Violation Error Cause 2276 2.26.1 Description of the problem 2278 There are many situations a SCTP endpoints detects that the peer 2279 violates the protocol. Therefore the association has to be aborted. 2280 Currently there are only some error causes which could be used to 2281 indicate the reason of the abort but these do not cover all cases. 2283 2.26.2 Text changes to the document 2285 Some of the changes given here already include changes suggested in 2286 section Section 2.6 and Section 2.21 of this document. 2288 --------- 2289 Old text: (Section 3.3.10) 2290 --------- 2292 Cause Code 2293 Value Cause Code 2294 --------- ---------------- 2295 1 Invalid Stream Identifier 2296 2 Missing Mandatory Parameter 2297 3 Stale Cookie Error 2298 4 Out of Resource 2299 5 Unresolvable Address 2300 6 Unrecognized Chunk Type 2301 7 Invalid Mandatory Parameter 2302 8 Unrecognized Parameters 2303 9 No User Data 2304 10 Cookie Received While Shutting Down 2306 Cause Length: 16 bits (unsigned integer) 2308 Set to the size of the parameter in bytes, including the Cause 2309 Code, Cause Length, and Cause-Specific Information fields 2311 Cause-specific Information: variable length 2313 This field carries the details of the error condition. 2315 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. 2316 Guidelines for the IETF to define new error cause values are 2317 discussed in Section 13.3. 2319 --------- 2320 New text: (Section 3.3.10) 2321 --------- 2323 Cause Code 2324 Value Cause Code 2325 --------- ---------------- 2326 1 Invalid Stream Identifier 2327 2 Missing Mandatory Parameter 2328 3 Stale Cookie Error 2329 4 Out of Resource 2330 5 Unresolvable Address 2331 6 Unrecognized Chunk Type 2332 7 Invalid Mandatory Parameter 2333 8 Unrecognized Parameters 2334 9 No User Data 2335 10 Cookie Received While Shutting Down 2336 11 Restart of an association with new addresses 2337 12 User Initiated Abort 2338 13 Protocol Violation 2340 Cause Length: 16 bits (unsigned integer) 2342 Set to the size of the parameter in bytes, including the Cause 2343 Code, Cause Length, and Cause-Specific Information fields 2345 Cause-specific Information: variable length 2346 This field carries the details of the error condition. 2348 Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP. 2349 Guidelines for the IETF to define new error cause values are 2350 discussed in Section 13.3. 2352 --------- 2353 New text: (Note no old text, new error added in section 3.3.10) 2354 --------- 2356 3.3.10.13 Protocol Violation (13) 2358 Cause of error 2359 -------------- 2361 This error cause MAY be included in ABORT chunks which are send 2362 because a SCTP endpoint detects a protocol violation of the peer 2363 which is not covered by the error causes described in 3.3.10.1 to 2364 3.3.10.12. An implementation MAY provide Additional Information 2365 specifying what kind of protocol violation has been detected. 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | Cause Code=13 | Cause Length=Variable | 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 / Additional Information / 2371 \\ \\ 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 2.26.3 Solution description 2376 An additional error cause which can be used by an endpoint to 2377 indicate a protocol violation of the peer has been defined. 2379 2.27 Reporting of Unrecognized Parameters 2381 2.27.1 Description of the problem 2383 It is not stated clearly in RFC2960 [5] how unrecognized parameters 2384 should be reported. Unrecognized parameters in an INIT chunk could be 2385 reported in the INIT-ACK chunk or in a separate ERROR chunk which can 2386 get lost. Unrecognized parameters in an INIT-ACK chunk have to be 2387 reported in an ERROR-chunk. This can be bundled with the COOKIE-ERROR 2388 chunk or sent separately. If it is sent separately and received 2389 before the COOKIE-ECHO it will be handled as an OOTB packet resulting 2390 in sending out an ABORT chunk. Therefore the association would not be 2391 established. 2393 2.27.2 Text changes to the document 2395 Some of the changes given here already include changes suggested in 2396 section Section 2.2 of this document. 2398 --------- 2399 Old text: (Section 3.2.1) 2400 --------- 2402 00 - Stop processing this SCTP packet and discard it, do not process 2403 any further chunks within it. 2405 01 - Stop processing this SCTP packet and discard it, do not process 2406 any further chunks within it, and report the unrecognized 2407 parameter in an 'Unrecognized Parameter Type' (in either an 2408 ERROR or in the INIT ACK). 2410 10 - Skip this parameter and continue processing. 2412 11 - Skip this parameter and continue processing but report the 2413 unrecognized parameter in an 'Unrecognized Parameter Type' (in 2414 either an ERROR or in the INIT ACK). 2416 --------- 2417 New text: (Section 3.2.1) 2418 --------- 2420 00 - Stop processing this SCTP chunk and discard it, do not process 2421 any further parameters within this chunk. 2423 01 - Stop processing this SCTP chunk and discard it, do not process 2424 any further parameters within this chunk, and report the 2425 unrecognized parameter in an 'Unrecognized Parameter Type' as 2426 described in 3.2.2. 2428 10 - Skip this parameter and continue processing. 2430 11 - Skip this parameter and continue processing but report the 2431 unrecognized parameter in an 'Unrecognized Parameter Type' as 2432 described in 3.2.2. 2434 --------- 2435 New text: (Note no old text, clarification added in section 3.2) 2436 --------- 2437 3.2.2 Reporting of Unrecognized Parameters 2439 If the receiver of an INIT chunk detects unrecognized parameters 2440 and has to report them according to section 3.2.1 it MUST put 2441 the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk 2442 sent in response to the INIT-chunk. Note that if the receiver 2443 of the INIT chunk is NOT going to establish an association (e.g. 2444 due to lack of resources) then no report would be sent back. 2446 If the receiver of an INIT-ACK chunk detects unrecognized parameters 2447 and has to report them according to section 3.2.1 it SHOULD bundle 2448 the ERROR chunk containing the 'Unrecognized Parameters' error cause 2449 with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. 2450 If the receiver of the INIT-ACK can not bundle the COOKIE-ECHO chunk 2451 with the ERROR chunk the ERROR chunk MAY be sent separately but not 2452 before the COOKIE-ACK has been received. 2454 Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the 2455 first chunk. 2457 2.27.3 Solution description 2459 The procedure of reporting unrecognized parameters has been described 2460 clearly. 2462 2.28 Handling of IP Address Parameters 2464 2.28.1 Description of the problem 2466 It is not stated clearly in RFC2960 [5] how a SCTP endpoint which 2467 supports either IPv4 addresses or IPv6 addresses should respond if 2468 IPv4 and IPv6 addresses are presented by the peer in the INIT or 2469 INIT-ACK chunk. 2471 2.28.2 Text changes to the document 2473 --------- 2474 Old text: (Section 5.1.2) 2475 --------- 2477 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK 2478 fails to resolve the address parameter due to an unsupported type, it 2479 can abort the initiation process and then attempt a re-initiation by 2480 using a 'Supported Address Types' parameter in the new INIT to 2481 indicate what types of address it prefers. 2483 --------- 2484 New text: (Section 5.1.2) 2485 --------- 2487 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK 2488 fails to resolve the address parameter due to an unsupported type, it 2489 can abort the initiation process and then attempt a re-initiation by 2490 using a 'Supported Address Types' parameter in the new INIT to 2491 indicate what types of address it prefers. 2493 IMPLEMENTATION NOTE: If a SCTP endpoint only supporting either IPv4 2494 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk 2495 from its peer it MUST use all of the addresses belonging to the 2496 supported address family. The other addresses MAY be ignored. The 2497 endpoint SHOULD NOT respond with any kind of error indication. 2499 2.28.3 Solution description 2501 The procedure of handling IP address parameters has been described 2502 clearly. 2504 2.29 Handling of COOKIE ECHO chunks when a TCB exists 2506 2.29.1 Description of the problem 2508 The description of be behavior in RFC2960 [5] when a COOKIE ECHO 2509 chunk and a TCB exists could be misunderstood. When a COOKIE ECHO is 2510 received, a TCB exist and the local and peer's tag match it is stated 2511 that the endpoint should enter the ESTABLISHED state if it has not 2512 already done so and send a COOKIE ACK. It was not clear that in case 2513 the endpoint has already left again the ESTABLISHED state then it 2514 should not go back to established. In case D the endpoint can only 2515 enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it 2516 has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing 2517 about the peer's tag which is requested to match in this case. 2519 2.29.2 Text changes to the document 2521 --------- 2522 Old text: (Section 5.2.4) 2523 --------- 2524 D) When both local and remote tags match the endpoint should always 2525 enter the ESTABLISHED state, if it has not already done so. It 2526 should stop any init or cookie timers that may be running and send 2527 a COOKIE ACK. 2529 --------- 2530 New text: (Section 5.2.4) 2531 --------- 2532 D) When both local and remote tags match the endpoint should 2533 enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state. 2534 It should stop any cookie timer that may be running and send 2535 a COOKIE ACK. 2537 2.29.3 Solution description 2539 The procedure of handling of COOKIE-ECHO chunks when a TCB exists has 2540 been described clearly. 2542 2.30 The Initial Congestion Window Size 2544 2.30.1 Description of the problem 2546 RFC2960 was published with the intention of having the same 2547 congestion control properties as TCP. Since the publication of 2548 RFC2960, TCP's initial congestion window size as been increased via 2549 RFC3390. This same update will be needed for SCTP to keep SCTP's 2550 congestion control properties equivilant to that of TCP. 2552 2.30.2 Text changes to the document 2554 --------- 2555 Old text: (Section 7.2.1) 2556 --------- 2557 o The initial cwnd before DATA transmission or after a sufficiently 2558 long idle period MUST be <= 2*MTU. 2560 --------- 2561 New text: (Section 7.2.1) 2562 --------- 2563 o The initial cwnd before DATA transmission or after a sufficiently 2564 long idle period MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). 2566 2.30.3 Solution description 2568 The change to SCTP's initial congestion window will allow it to 2569 continue to maintain the same congestion control properties as TCP. 2571 2.31 Stream Sequence Numbers in Figures 2573 2.31.1 Description of the problem 2575 In Section 2.24 of this document it is clarified that the SSN are 2576 initialized with 0. Two figures in RFC2960 [5] illustrate that they 2577 start with 1. 2579 2.31.2 Text changes to the document 2581 --------- 2582 Old text: (Section 7.2.1) 2583 --------- 2585 Endpoint A Endpoint Z 2586 {app sets association with Z} 2587 (build TCB) 2588 INIT [I-Tag=Tag_A 2589 & other info] --------\ 2590 (Start T1-init timer) \ 2591 (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) 2593 /--- INIT ACK [Veri Tag=Tag_A, 2594 / I-Tag=Tag_Z, 2595 (Cancel T1-init timer) <------/ Cookie_Z, & other info] 2596 (destroy temp TCB) 2597 COOKIE ECHO [Cookie_Z] ------\ 2598 (Start T1-init timer) \ 2599 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 2600 state) 2602 /---- COOKIE-ACK 2603 / 2604 (Cancel T1-init timer, <-----/ 2605 Enter ESTABLISHED state) 2606 {app sends 1st user data; strm 0} 2607 DATA [TSN=initial TSN_A 2608 Strm=0,Seq=1 & user data]--\ 2609 (Start T3-rtx timer) \ 2610 \-> 2611 /----- SACK [TSN Ack=init 2612 TSN_A,Block=0] 2613 (Cancel T3-rtx timer) <------/ 2614 ... 2615 {app sends 2 messages;strm 0} 2616 /---- DATA 2617 / [TSN=init TSN_Z 2618 <--/ Strm=0,Seq=1 & user data 1] 2619 SACK [TSN Ack=init TSN_Z, /---- DATA 2620 Block=0] --------\ / [TSN=init TSN_Z +1, 2621 \/ Strm=0,Seq=2 & user data 2] 2622 <------/\ 2623 \ 2624 \------> 2626 Figure 4: INITiation Example 2628 --------- 2629 New text: (Section 7.2.1) 2630 --------- 2632 Endpoint A Endpoint Z 2633 {app sets association with Z} 2634 (build TCB) 2635 INIT [I-Tag=Tag_A 2636 & other info] --------\ 2637 (Start T1-init timer) \ 2638 (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) 2640 /--- INIT ACK [Veri Tag=Tag_A, 2641 / I-Tag=Tag_Z, 2642 (Cancel T1-init timer) <------/ Cookie_Z, & other info] 2643 (destroy temp TCB) 2644 COOKIE ECHO [Cookie_Z] ------\ 2645 (Start T1-init timer) \ 2646 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 2647 state) 2649 /---- COOKIE-ACK 2650 / 2651 (Cancel T1-init timer, <-----/ 2652 Enter ESTABLISHED state) 2653 {app sends 1st user data; strm 0} 2654 DATA [TSN=initial TSN_A 2655 Strm=0,Seq=0 & user data]--\ 2656 (Start T3-rtx timer) \ 2657 \-> 2658 /----- SACK [TSN Ack=init 2659 TSN_A,Block=0] 2660 (Cancel T3-rtx timer) <------/ 2662 ... 2663 {app sends 2 messages;strm 0} 2664 /---- DATA 2665 / [TSN=init TSN_Z 2666 <--/ Strm=0,Seq=0 & user data 1] 2667 SACK [TSN Ack=init TSN_Z, /---- DATA 2668 Block=0] --------\ / [TSN=init TSN_Z +1, 2669 \/ Strm=0,Seq=1 & user data 2] 2670 <------/\ 2671 \ 2672 \------> 2674 Figure 4: INITiation Example 2676 --------- 2677 Old text: (Section 5.2.4.1) 2678 --------- 2680 Endpoint A Endpoint Z 2681 <-------------- Association is established----------------------> 2682 Tag=Tag_A Tag=Tag_Z 2683 <---------------------------------------------------------------> 2684 {A crashes and restarts} 2685 {app sets up a association with Z} 2686 (build TCB) 2687 INIT [I-Tag=Tag_A' 2688 & other info] --------\ 2689 (Start T1-init timer) \ 2690 (Enter COOKIE-WAIT state) \---> (find a existing TCB 2691 compose temp TCB and Cookie_Z 2692 with Tie-Tags to previous 2693 association) 2694 /--- INIT ACK [Veri Tag=Tag_A', 2695 / I-Tag=Tag_Z', 2696 (Cancel T1-init timer) <------/ Cookie_Z[TieTags= 2697 Tag_A,Tag_Z 2698 & other info] 2699 (destroy temp TCB,leave original 2700 in place) 2701 COOKIE ECHO [Veri=Tag_Z', 2702 Cookie_Z 2703 Tie=Tag_A, 2704 Tag_Z]----------\ 2705 (Start T1-init timer) \ 2706 (Enter COOKIE-ECHOED state) \---> (Find existing association, 2707 Tie-Tags match old tags, 2708 Tags do not match i.e. 2709 case X X M M above, 2710 Announce Restart to ULP 2711 and reset association). 2712 /---- COOKIE-ACK 2713 / 2714 (Cancel T1-init timer, <-----/ 2715 Enter ESTABLISHED state) 2716 {app sends 1st user data; strm 0} 2717 DATA [TSN=initial TSN_A 2718 Strm=0,Seq=1 & user data]--\ 2719 (Start T3-rtx timer) \ 2720 \-> 2721 /----- SACK [TSN Ack=init TSN_A,Block=0] 2722 (Cancel T3-rtx timer) <------/ 2724 Figure 5: A Restart Example 2725 --------- 2726 New text: (Section 5.2.4.1) 2727 --------- 2729 Endpoint A Endpoint Z 2730 <-------------- Association is established----------------------> 2731 Tag=Tag_A Tag=Tag_Z 2732 <---------------------------------------------------------------> 2733 {A crashes and restarts} 2734 {app sets up a association with Z} 2735 (build TCB) 2736 INIT [I-Tag=Tag_A' 2737 & other info] --------\ 2738 (Start T1-init timer) \ 2739 (Enter COOKIE-WAIT state) \---> (find a existing TCB 2740 compose temp TCB and Cookie_Z 2741 with Tie-Tags to previous 2742 association) 2743 /--- INIT ACK [Veri Tag=Tag_A', 2744 / I-Tag=Tag_Z', 2745 (Cancel T1-init timer) <------/ Cookie_Z[TieTags= 2746 Tag_A,Tag_Z 2747 & other info] 2748 (destroy temp TCB,leave original 2749 in place) 2750 COOKIE ECHO [Veri=Tag_Z', 2751 Cookie_Z 2752 Tie=Tag_A, 2753 Tag_Z]----------\ 2755 (Start T1-init timer) \ 2756 (Enter COOKIE-ECHOED state) \---> (Find existing association, 2757 Tie-Tags match old tags, 2758 Tags do not match i.e. 2759 case X X M M above, 2760 Announce Restart to ULP 2761 and reset association). 2762 /---- COOKIE-ACK 2763 / 2764 (Cancel T1-init timer, <-----/ 2765 Enter ESTABLISHED state) 2766 {app sends 1st user data; strm 0} 2767 DATA [TSN=initial TSN_A 2768 Strm=0,Seq=0 & user data]--\ 2769 (Start T3-rtx timer) \ 2770 \-> 2771 /----- SACK [TSN Ack=init TSN_A,Block=0] 2772 (Cancel T3-rtx timer) <------/ 2774 Figure 5: A Restart Example 2776 2.31.3 Solution description 2778 Figure 4 and figure 5 were changed such that the SSN start with 0 2779 instead of 1. 2781 2.32 Unrecognized Parameters 2783 2.32.1 Description of the problem 2785 The RFC does not state clearly in section 3.3.3.1 if one or multiple 2786 unrecognized parameters are included in the 'Unrecognized Parameter' 2787 parameter. 2789 2.32.2 Text changes to the document 2791 --------- 2792 Old text: (Section 3.3.3) 2793 --------- 2794 Variable Parameters Status Type Value 2795 ------------------------------------------------------------- 2796 State Cookie Mandatory 7 2797 IPv4 Address (Note 1) Optional 5 2798 IPv6 Address (Note 1) Optional 6 2799 Unrecognized Parameters Optional 8 2800 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 2801 Host Name Address (Note 3) Optional 11 2803 --------- 2804 New text: (Section 3.3.3) 2805 --------- 2806 Variable Parameters Status Type Value 2807 ------------------------------------------------------------- 2808 State Cookie Mandatory 7 2809 IPv4 Address (Note 1) Optional 5 2810 IPv6 Address (Note 1) Optional 6 2811 Unrecognized Parameter Optional 8 2812 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 2813 Host Name Address (Note 3) Optional 11 2815 --------- 2816 Old text: (Section 3.3.3.1) 2817 --------- 2818 Unrecognized Parameters: 2820 Parameter Type Value: 8 2822 Parameter Length: Variable Size. 2824 Parameter Value: 2826 This parameter is returned to the originator of the INIT chunk 2827 when the INIT contains an unrecognized parameter which has a 2828 value that indicates that it should be reported to the sender. 2829 This parameter value field will contain unrecognized parameters 2830 copied from the INIT chunk complete with Parameter Type, Length 2831 and Value fields. 2833 --------- 2834 New text: (Section 3.3.3.1) 2835 --------- 2836 Unrecognized Parameter: 2838 Parameter Type Value: 8 2840 Parameter Length: Variable Size. 2842 Parameter Value: 2844 This parameter is returned to the originator of the INIT chunk 2845 when the INIT contains an unrecognized parameter which has a 2846 value that indicates that it should be reported to the sender. 2847 This parameter value field will contain the unrecognized parameter 2848 copied from the INIT chunk complete with Parameter Type, Length 2849 and Value fields. 2851 2.32.3 Solution description 2853 The new text states clearly that only one unrecognized parameter is 2854 reported per parameter. 2856 2.33 Handling of unrecognized parameters 2858 2.33.1 Description of the problem 2860 It is not stated clearly in RFC2960 [5] how unrecognized parameters 2861 should be handled. The problem came up when an INIT contains an 2862 unrecognized parameter with highest bits 00. It was not clear if an 2863 INIT-ACK should be sent or not. 2865 2.33.2 Text changes to the document 2867 Some of the changes given here already include changes suggested in 2868 section Section 2.27 of this document. 2870 --------- 2871 Old text: (Section 3.2.1) 2872 --------- 2874 00 - Stop processing this SCTP packet and discard it, do not process 2875 any further chunks within it. 2877 01 - Stop processing this SCTP packet and discard it, do not process 2878 any further chunks within it, and report the unrecognized 2879 parameter in an 'Unrecognized Parameter Type' (in either an 2880 ERROR or in the INIT ACK). 2882 10 - Skip this parameter and continue processing. 2884 11 - Skip this parameter and continue processing but report the 2885 unrecognized parameter in an 'Unrecognized Parameter Type' (in 2886 either an ERROR or in the INIT ACK). 2888 --------- 2889 New text: (Section 3.2.1) 2890 --------- 2892 00 - Stop processing this parameter, do not process 2893 any further parameters within this chunk. 2895 01 - Stop processing this parameter, do not process 2896 any further parameters within this chunk, and report the 2897 unrecognized parameter in an 'Unrecognized Parameter Type' as 2898 described in 3.2.2. 2900 10 - Skip this parameter and continue processing. 2902 11 - Skip this parameter and continue processing but report the 2903 unrecognized parameter in an 'Unrecognized Parameter Type' as 2904 described in 3.2.2. 2906 --------- 2907 New text: (Note no old text, clarification added in section 3.2) 2908 --------- 2910 3.2.2 Reporting of Unrecognized Parameters 2912 If the receiver of an INIT chunk detects unrecognized parameters 2913 and has to report them according to section 3.2.1 it MUST put 2914 the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk 2915 sent in response to the INIT-chunk. Note that if the receiver 2916 of the INIT chunk is NOT going to establish an association (e.g. 2917 due to lack of resources) an 'Unrecognized Parameters' would NOT 2918 be included with any ABORT being sent to the sender of the INIT. 2920 If the receiver of an INIT-ACK chunk detects unrecognized parameters 2921 and has to report them according to section 3.2.1 it SHOULD bundle 2922 the ERROR chunk containing the 'Unrecognized Parameters' error cause 2923 with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. 2924 If the receiver of the INIT-ACK can not bundle the COOKIE-ECHO chunk 2925 with the ERROR chunk the ERROR chunk MAY be sent separately but not 2926 before the COOKIE-ACK has been received. 2928 Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the 2929 first chunk. 2931 2.33.3 Solution description 2933 The procedure of handling unrecognized parameters has been described 2934 clearly. 2936 2.34 Tie Tags 2938 2.34.1 Description of the problem 2940 RFC2960 requires Tie-Tags to be included in the COOKIE. The cookie 2941 may not be encrypted. An attacker could discover the value of the 2942 verification tags by analyzing cookies received after sending an 2943 INIT. 2945 2.34.2 Text changes to the document 2947 --------- 2948 Old text: (Section 1.4) 2949 --------- 2951 o Tie-Tags: Verification Tags from a previous association. These 2952 Tags are used within a State Cookie so that the newly restarting 2953 association can be linked to the original association within the 2954 endpoint that did not restart. 2956 --------- 2957 New text: (Section 1.4) 2958 --------- 2960 o Tie-Tags: Two 32 bit random numbers which together make a 64 bit 2961 nonce. These Tags are used within a State Cookie and TCB so that 2962 a newly restarting association can be linked to the original 2963 association within the endpoint that did not restart and yet not 2964 reveal the true verification tags of an existing association. 2966 --------- 2967 Old text: (Section 5.2.1) 2968 --------- 2970 For an endpoint that is in the COOKIE-ECHOED state it MUST populate 2971 its Tie-Tags with the Tag information of itself and its peer (see 2972 section 5.2.2 for a description of the Tie-Tags). 2974 --------- 2975 New text: (Section 5.2.1) 2976 --------- 2978 For an endpoint that is in the COOKIE-ECHOED state it MUST populate 2979 its Tie-Tags within both the association TCB and populated inside 2980 the State Cookie (see section 5.2.2 for a description of the Tie-Tags). 2982 --------- 2983 Old text: (Section 5.2.2) 2984 --------- 2986 Unless otherwise stated, upon reception of an unexpected INIT for 2987 this association, the endpoint shall generate an INIT ACK with a 2988 State Cookie. In the outbound INIT ACK the endpoint MUST copy its 2989 current Verification Tag and peer's Verification Tag into a reserved 2990 place within the state cookie. We shall refer to these locations as 2991 the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet 2992 containing this INIT ACK MUST carry a Verification Tag value equal to 2993 the Initiation Tag found in the unexpected INIT. And the INIT ACK 2994 MUST contain a new Initiation Tag (randomly generated see Section 2995 5.3.1). Other parameters for the endpoint SHOULD be copied from the 2996 existing parameters of the association (e.g. number of outbound 2997 streams) into the INIT ACK and cookie. 2999 --------- 3000 New text: (Section 5.2.2) 3001 --------- 3003 Unless otherwise stated, upon reception of an unexpected INIT for 3004 this association, the endpoint shall generate an INIT ACK with a 3005 State Cookie. In the outbound INIT ACK the endpoint MUST copy its 3006 current Tie-Tags to a reserved place within the State Cookie and the 3007 association's TCB. We shall refer to these locations inside the 3008 cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer 3009 to the copy within an association's TCB as the Local Tag and Peer's Tag. 3010 The outbound SCTP packet containing this INIT ACK MUST carry 3011 a Verification Tag value equal to the Initiation Tag found in the 3012 unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag 3013 (randomly generated see Section 5.3.1). Other parameters for the 3014 endpoint SHOULD be copied from the existing parameters of the 3015 association (e.g. number of outbound streams) into the INIT ACK 3016 and cookie. 3018 2.34.3 Solution description 3020 The solution to this problem is not to use the real verification tags 3021 within the State Cookie as tie-tags. Instead two 32 bit random 3022 numbers are created to form one 64 bit nonces and stored both in the 3023 State Cookie and the existing association TCB. This prevents exposing 3024 the verification tags inadvertently. 3026 2.35 Port number verification in the COOKIE-ECHO 3028 2.35.1 Description of the problem 3030 The State Cookie sent by a listening SCTP endpoint may not contain 3031 the original port numbers or the local verification tag. It is then 3032 possible that the endpoint on reception of the COOKIE-ECHO will not 3033 be able to verify that these values match the original values found 3034 in the INIT and INIT-ACK that began the association setup. 3036 2.35.2 Text changes to the document 3038 --------- 3039 Old text: (Section 5.1.5) 3040 --------- 3042 3) Compare the creation timestamp in the State Cookie to the current 3043 local time. If the elapsed time is longer than the lifespan 3044 carried in the State Cookie, then the packet, including the COOKIE 3045 ECHO and any attached DATA chunks, SHOULD be discarded and the 3046 endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error 3047 cause to the peer endpoint, 3049 4) If the State Cookie is valid, create an association to the sender 3050 of the COOKIE ECHO chunk with the information in the TCB data 3051 carried in the COOKIE ECHO, and enter the ESTABLISHED state, 3053 5) Send a COOKIE ACK chunk to the peer acknowledging reception of the 3054 COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA 3055 chunk or SACK chunk; however, the COOKIE ACK MUST be the first 3056 chunk in the SCTP packet. 3058 6) Immediately acknowledge any DATA chunk bundled with the COOKIE 3059 ECHO with a SACK (subsequent DATA chunk acknowledgement should 3060 follow the rules defined in Section 6.2). As mentioned in step 3061 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK 3062 MUST appear first in the SCTP packet. 3064 --------- 3065 New text: (Section 5.1.5) 3066 --------- 3068 3) Compare the port numbers and the verification tag contained 3069 within the COOKIE ECHO chunk to the actual port numbers and the 3070 verification tag within the SCTP common header of the received 3071 packet. If these values do not match the packet MUST be silently 3072 discarded, 3074 4) Compare the creation timestamp in the State Cookie to the current 3075 local time. If the elapsed time is longer than the lifespan 3076 carried in the State Cookie, then the packet, including the COOKIE 3077 ECHO and any attached DATA chunks, SHOULD be discarded and the 3078 endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error 3079 cause to the peer endpoint, 3081 5) If the State Cookie is valid, create an association to the sender 3082 of the COOKIE ECHO chunk with the information in the TCB data 3083 carried in the COOKIE ECHO, and enter the ESTABLISHED state, 3085 6) Send a COOKIE ACK chunk to the peer acknowledging reception of the 3086 COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA 3087 chunk or SACK chunk; however, the COOKIE ACK MUST be the first 3088 chunk in the SCTP packet. 3090 7) Immediately acknowledge any DATA chunk bundled with the COOKIE 3091 ECHO with a SACK (subsequent DATA chunk acknowledgement should 3092 follow the rules defined in Section 6.2). As mentioned in step 3093 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK 3094 MUST appear first in the SCTP packet. 3096 2.35.3 Solution description 3098 By including both port numbers and the local verification tag within 3099 the State Cookie and verifying these during COOKIE-ECHO processing 3100 this issue is resolved. 3102 2.36 Path Initialization 3104 2.36.1 Description of the problem 3106 When an association enters the ESTABLISHED state the endpoint has no 3107 verification that all of the addresses presented by the peer are in 3108 fact belonging to the peer. This could cause various forms of denial 3109 of service attacks. 3111 2.36.2 Text changes to the document 3113 --------- 3114 Old text: None 3115 --------- 3117 --------- 3118 New text: (Section 5.4) 3119 --------- 3120 5.4 Path Verification 3122 During association estabilishment the two peers 3123 exchange a list of addresses. In the predominant case 3124 these lists accurately represent the addresses owned 3125 by each peer. However there exists the possibility that 3126 a mis-behaving peer may supply addresses that it does 3127 not own. To prevent this the following rules are applied 3128 to all addresses of the new association: 3130 1) Any address passed to the sender of the INIT by its 3131 upper layer is automatically considered to be CONFIRMED. 3133 2) For the receiver of the COOKIE-ECHO the only CONFIRMED 3134 address is the one that the INIT-ACK was sent to. 3136 3) All other addresses not covered by rules 1 and 2 are considered 3137 UNCONFIRMED and are subject to probing for verification. 3139 To probe an address for verification, an endpoint will send 3140 HEARTBEAT's including a new 64 bit random nonce and a path 3141 indicator (to identify the address that the HEARTBEAT 3142 is sent to) within the HEARTBEAT parameter. 3144 Upon reception of the HEARTBEAT-ACK a verification is 3145 made that the nonce included in the HEARTBEAT parameter 3146 is the one sent to the address indicated inside the 3147 HEARTBEAT parameter. When this match occurs, the address 3148 that the original HEARTBEAT was sent to is now considered 3149 CONFIRMED and available for normal data transfer. 3151 These probing proceedures are started when an association 3152 moves to the ESTABLISHED state and are ended when all 3153 paths are confirmed. 3155 Each RTO a probe may be sent on an active UNCONFIRMED path 3156 in an attempt to move it to to the CONFIRMED state. 3157 If during this probing the path becomes inactive this rate 3158 is lowered to the normal HEARTBEAT rate. At the expiration 3159 of the RTO timer the error counter of any path that was 3160 probed but not CONFIRMED is incremented by one and subjected 3161 to path failure detection defined in section 8.2. 3163 The number of HEARTBEATS sent at each RTO MUST be limted 3164 by the Max.Burst parameter. 3166 Whenever a path is confirmed an indication is given to 3167 to the upper layer. 3169 An UNCONFIRMED path MUST NOT be used as the primary path 3170 for the association. 3172 2.36.3 Solution description 3174 By properly setting up initial path state and accelerated probing via 3175 HEARTBEAT's an new association can verify that all addresses 3176 presented by a peer belong to that peer. 3178 2.37 ICMP handling procedures 3180 2.37.1 Description of the problem 3182 RFC2960 does not describe how ICMP messages should be processed by an 3183 SCTP endpoint. 3185 2.37.2 Text changes to the document 3187 --------- 3188 Old text: None 3189 --------- 3191 --------- 3192 New text: (Appendix C) 3193 --------- 3195 Appendix C ICMP Handling 3197 Whenever an ICMP message is received by an SCTP endpoint the 3198 following procedures should be followed to assure proper 3199 utilization of the information being provided by layer 3. 3201 ICMP1) Ignore all ICMPv4 messages where the type field is 3202 not set to "Destination Unreachable". 3204 ICMP2) Ignore all ICMPv6 messages where the type filed is 3205 not "Parameter Problem" or "Packet Too Big". 3207 ICMP3) Ignore any ICMPv4 messages where the code does not 3208 indicate "Protocol Unreachable" or "Fragmentation Needed". 3210 ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if 3211 the code is not "Unrecognized next header type encountered". 3213 ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the 3214 association which sent the message that ICMP is responding to. If 3215 the association cannot be found, ignore the ICMP message. 3217 ICMP6) Validate that the verification tag contained in the ICMP message 3218 matches the verification tag of the peer. 3220 ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 3221 "Fragmentation Needed" process this information as defined for 3222 PATH MTU discovery. 3224 ICMP8) If the ICMP code is a "Unrecognized next header type encountered" 3225 or a "Protocol Unreachable" treat this message as an abort 3226 with the T bit set. 3228 2.37.3 Solution description 3230 The new appendix now describes proper handling of ICMP messages in 3231 conjunction with SCTP. 3233 3. Acknowledgments 3235 The authors would like to thank the following people that have 3236 provided comments and input for this document: 3238 Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj 3239 Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon 3240 Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin, 3241 Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson, 3242 David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa 3243 Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred 3244 Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon, 3245 Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep 3246 Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep 3247 Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll, 3248 Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David 3249 Lehmann, Rob Brennan, Thomas Curran, Stan McClellan, Keyur Shah, 3250 Janardhan Iyengar, Serkan Cil and Caitlin Bestler. 3252 A special thanks to Mark Allman, who should actually be a co-author 3253 for his work on the max-burst, but managed to wiggle out due to a 3254 technicality. Also we would like to acknowledge Lyndon Ong and Phil 3255 Conrad for their valuable input and many contributions. 3257 References 3259 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 3260 9, RFC 2026, October 1996. 3262 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3263 Levels", BCP 14, RFC 2119, March 1997. 3265 [3] Caro, A., Shah, K., Iyengar, J., Amer, P. and R. Stewart, "SCTP 3266 and TCP Variants: Congestion Control Under Multiple Losses", 3267 Technical Report TR2003-04, Computer and Information Sciences 3268 Department, University of Delaware, February 2003, . 3271 [4] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window 3272 Validation", RFC 2861, June 2000. 3274 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 3275 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 3276 "Stream Control Transmission Protocol", RFC 2960, October 2000. 3278 Authors' Addresses 3280 Randall R. Stewart 3281 Cisco Systems, Inc. 3282 8725 West Higgins Road 3283 Suite 300 3284 Chicago, IL 60631 3285 USA 3287 Phone: 3288 EMail: rrs@cisco.com 3290 Ivan Arias-Rodriguez 3291 Nokia Research Center 3292 PO Box 407 3293 FIN-00045 Nokia Group 3294 Finland 3296 Phone: 3297 EMail: ivan.arias-rodriguez@nokia.com 3298 Kacheong Poon 3299 Consultant 3301 Milpitas, CA 3303 Phone: 3304 EMail: kcpoon@yahoo.com 3306 Armando L. Caro Jr. 3307 University of Delaware 3308 Department of Computer & Information Sciences 3309 103 Smith Hall 3310 Newark, DE 19716 3311 USA 3313 Phone: 3314 EMail: acaro@cis.udel.edu 3315 URI: http://www.cis.udel.edu/~acaro 3317 Michael Tuexen 3318 Univ. of Applied Sciences Muenster 3319 Stegerwaldstr. 39 3320 48565 Steinfurt 3321 Germany 3323 EMail: tuexen@fh-muenster.de 3325 Intellectual Property Statement 3327 The IETF takes no position regarding the validity or scope of any 3328 intellectual property or other rights that might be claimed to 3329 pertain to the implementation or use of the technology described in 3330 this document or the extent to which any license under such rights 3331 might or might not be available; neither does it represent that it 3332 has made any effort to identify any such rights. Information on the 3333 IETF's procedures with respect to rights in standards-track and 3334 standards-related documentation can be found in BCP-11. Copies of 3335 claims of rights made available for publication and any assurances of 3336 licenses to be made available, or the result of an attempt made to 3337 obtain a general license or permission for the use of such 3338 proprietary rights by implementors or users of this specification can 3339 be obtained from the IETF Secretariat. 3341 The IETF invites any interested party to bring to its attention any 3342 copyrights, patents or patent applications, or other proprietary 3343 rights which may cover technology that may be required to practice 3344 this standard. Please address the information to the IETF Executive 3345 Director. 3347 Full Copyright Statement 3349 Copyright (C) The Internet Society (2003). All Rights Reserved. 3351 This document and translations of it may be copied and furnished to 3352 others, and derivative works that comment on or otherwise explain it 3353 or assist in its implementation may be prepared, copied, published 3354 and distributed, in whole or in part, without restriction of any 3355 kind, provided that the above copyright notice and this paragraph are 3356 included on all such copies and derivative works. However, this 3357 document itself may not be modified in any way, such as by removing 3358 the copyright notice or references to the Internet Society or other 3359 Internet organizations, except as needed for the purpose of 3360 developing Internet standards in which case the procedures for 3361 copyrights defined in the Internet Standards process must be 3362 followed, or as required to translate it into languages other than 3363 English. 3365 The limited permissions granted above are perpetual and will not be 3366 revoked by the Internet Society or its successors or assignees. 3368 This document and the information contained herein is provided on an 3369 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3370 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3371 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3372 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3373 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3375 Acknowledgement 3377 Funding for the RFC Editor function is currently provided by the 3378 Internet Society.