idnits 2.17.1 draft-ietf-tsvwg-sctpimpguide-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4737. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 upper bound 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 (October 24, 2005) is 6752 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: 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 373 -- Looks like a reference, but probably isn't: 'ALLMAN99' on line 3698 -- Looks like a reference, but probably isn't: 'FALL96' on line 3701 -- Looks like a reference, but probably isn't: 'RFC1750' on line 3713 -- Looks like a reference, but probably isn't: 'RFC1950' on line 3720 -- Looks like a reference, but probably isn't: 'RFC2104' on line 3723 -- Looks like a reference, but probably isn't: 'RFC2196' on line 3726 -- Looks like a reference, but probably isn't: 'RFC2522' on line 3729 -- Looks like a reference, but probably isn't: 'SAVAGE99' on line 3732 -- Looks like a reference, but probably isn't: 'RFC1858' on line 3716 -- Looks like a reference, but probably isn't: 'ITU32' on line 3705 -- Looks like a reference, but probably isn't: 'PETERSON 72' on line 3578 -- Looks like a reference, but probably isn't: 'WILLIAMS93' on line 3736 -- Looks like a reference, but probably isn't: 'PETERSON 1972' on line 3709 == Unused Reference: '2' is defined on line 4643, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 4659, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2861 (ref. '6') (Obsoleted by RFC 7661) ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3309 (ref. '8') (Obsoleted by RFC 4960) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Cisco Systems, Inc. 4 Expires: April 27, 2006 I. Arias-Rodriguez 5 Nokia Research Center 6 K. Poon 7 Sun Microsystems, Inc. 8 A. Caro 9 University of Delaware 10 M. Tuexen 11 Muenster Univ. of Applied Sciences 12 October 24, 2005 14 Stream Control Transmission Protocol (SCTP) Specification Errata and 15 Issues 16 draft-ietf-tsvwg-sctpimpguide-16.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 27, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 This document is a compilation of issues found during six 49 interoperability events and 5 years of experience with implementing, 50 testing, and using SCTP along with the suggested fixes. This 51 document provides deltas to RFC 2960 and is organized in a time based 52 way. The issues are listed in the order they were brought up. 53 Because some text is changed several times the last delta in the text 54 is the one which should be applied. In addition to the delta a 55 description of the problem and the details of the solution are also 56 provided. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . . 5 63 2.1. Incorrect error type during chunk processing. . . . . . . 5 64 2.2. Parameter processing issue . . . . . . . . . . . . . . . 5 65 2.3. Padding issues . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Parameter types across all chunk types . . . . . . . . . 8 67 2.5. Stream parameter clarification . . . . . . . . . . . . . 10 68 2.6. Restarting association security issue . . . . . . . . . . 11 69 2.7. Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 15 70 2.8. Issues with Fast Retransmit . . . . . . . . . . . . . . . 16 71 2.9. Missing statement about partial_bytes_acked update . . . 21 72 2.10. Issues with Heartbeating and failure detection . . . . . 23 73 2.11. Security interactions with firewalls . . . . . . . . . . 26 74 2.12. Shutdown ambiguity . . . . . . . . . . . . . . . . . . . 28 75 2.13. Inconsistency in ABORT processing . . . . . . . . . . . . 30 76 2.14. Cwnd gated by its full use . . . . . . . . . . . . . . . 31 77 2.15. Window probes in SCTP . . . . . . . . . . . . . . . . . . 34 78 2.16. Fragmentation and Path MTU issues . . . . . . . . . . . . 36 79 2.17. Initial value of the cumulative TSN Ack . . . . . . . . . 38 80 2.18. Handling of address parameters within the INIT or 81 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . 38 82 2.19. Handling of stream shortages . . . . . . . . . . . . . . 40 83 2.20. Indefinite postponement . . . . . . . . . . . . . . . . . 42 84 2.21. User initiated abort of an association . . . . . . . . . 43 85 2.22. Handling of invalid Initiate Tag of INIT-ACK . . . . . . 48 86 2.23. ABORT sending in response to an INIT . . . . . . . . . . 50 87 2.24. Stream Sequence Number (SSN) Initialization . . . . . . . 50 88 2.25. SACK packet format . . . . . . . . . . . . . . . . . . . 51 89 2.26. Protocol Violation Error Cause . . . . . . . . . . . . . 52 90 2.27. Reporting of Unrecognized Parameters . . . . . . . . . . 54 91 2.28. Handling of IP Address Parameters . . . . . . . . . . . . 56 92 2.29. Handling of COOKIE ECHO chunks when a TCB exists . . . . 57 93 2.30. The Initial Congestion Window Size . . . . . . . . . . . 58 94 2.31. Stream Sequence Numbers in Figures . . . . . . . . . . . 60 95 2.32. Unrecognized Parameters . . . . . . . . . . . . . . . . . 65 96 2.33. Handling of unrecognized parameters . . . . . . . . . . . 66 97 2.34. Tie Tags . . . . . . . . . . . . . . . . . . . . . . . . 68 98 2.35. Port number verification in the COOKIE-ECHO . . . . . . . 70 99 2.36. Path Initialization . . . . . . . . . . . . . . . . . . . 71 100 2.37. ICMP handling procedures . . . . . . . . . . . . . . . . 74 101 2.38. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 77 102 2.39. Retransmission Policy . . . . . . . . . . . . . . . . . . 84 103 2.40. Port Number 0 . . . . . . . . . . . . . . . . . . . . . . 86 104 2.41. T Bit . . . . . . . . . . . . . . . . . . . . . . . . . . 87 105 2.42. Unknown Parameter Handling . . . . . . . . . . . . . . . 91 106 2.43. Cookie Echo Chunk . . . . . . . . . . . . . . . . . . . . 93 107 2.44. Partial Chunks . . . . . . . . . . . . . . . . . . . . . 94 108 2.45. Non-unicast addresses . . . . . . . . . . . . . . . . . . 95 109 2.46. Processing of ABORT chunks . . . . . . . . . . . . . . . 96 110 2.47. Sending of ABORT chunks . . . . . . . . . . . . . . . . . 97 111 2.48. Handling of Supported Address Types parameter . . . . . . 98 112 2.49. Handling of unexpected parameters . . . . . . . . . . . . 99 113 2.50. Payload Protocol Identifier . . . . . . . . . . . . . . . 101 114 2.51. Karns Algorithm . . . . . . . . . . . . . . . . . . . . . 102 115 2.52. Fast Retransmit algorithm . . . . . . . . . . . . . . . . 103 116 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 105 117 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 106 118 5. Security considerations . . . . . . . . . . . . . . . . . . . 107 119 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 120 6.1. Normative references . . . . . . . . . . . . . . . . . . 108 121 6.2. Informational References . . . . . . . . . . . . . . . . 108 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109 123 Intellectual Property and Copyright Statements . . . . . . . . . 111 125 1. Introduction 127 This document contains a compilation of all defects found up until 128 the publishing of this document for the Stream Control Transmission 129 Protocol (SCTP) RFC2960 [7]. These defects may be of an editorial or 130 technical nature. This document may be thought of as a companion 131 document to be used in the implementation of SCTP to clarify errors 132 in the original SCTP document. 134 This document provides a history of the changes that will be 135 compliled into RFC2960's [7] BIS document. Each error will be 136 detailed within this document in the form of: 138 o The problem description, 140 o The text quoted from RFC2960 [7], 142 o The replacement text that should be placed into the BIS document, 144 o A description of the solution. 146 Note that when reading this document one must use care to assure that 147 a field or item is not updated further on within the document. Each 148 section should be applied in sequence to the original RFC2960 [7] 149 since this document is a historical record of the sequential changes 150 that have been found necessary at various inter-op events and through 151 discussion on the list. 153 1.1. Conventions 155 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 156 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 157 they appear in this document, are to be interpreted as described in 158 RFC2119 [3]. 160 2. Corrections to RFC2960 162 2.1. Incorrect error type during chunk processing. 164 2.1.1. Description of the problem 166 A typo was discovered in RFC2960 [7] that incorrectly specifies an 167 action to be taken when processing chunks of unknown identity. 169 2.1.2. Text changes to the document 171 --------- 172 Old text: (Section 3.2) 173 --------- 175 01 - Stop processing this SCTP packet and discard it, do not process 176 any further chunks within it, and report the unrecognized 177 parameter in an 'Unrecognized Parameter Type' (in either an 178 ERROR or in the INIT ACK). 180 --------- 181 New text: (Section 3.2) 182 --------- 184 01 - Stop processing this SCTP packet and discard it, do not process 185 any further chunks within it, and report the unrecognized 186 chunk in an 'Unrecognized Chunk Type'. 188 2.1.3. Solution description 190 The receiver of an unrecognized Chunk should not send a 'parameter' 191 error but instead the appropriate chunk error as described above. 193 2.2. Parameter processing issue 195 2.2.1. Description of the problem 197 A typographical error was introduced through an improper cut and 198 paste in the use of the upper two bits to describe proper handling of 199 unknown parameters. 201 2.2.2. Text changes to the document 203 --------- 204 Old text: (Section 3.2.1) 205 --------- 207 00 - Stop processing this SCTP packet and discard it, do not process 208 any further chunks within it. 210 01 - Stop processing this SCTP packet and discard it, do not process 211 any further chunks within it, and report the unrecognized 212 parameter in an 'Unrecognized Parameter Type' (in either an 213 ERROR or in the INIT ACK). 215 --------- 216 New text: (Section 3.2.1) 217 --------- 219 00 - Stop processing this SCTP chunk and discard it, do not process 220 any further parameters within this chunk. 222 01 - Stop processing this SCTP chunk and discard it, do not process 223 any further parameters within this chunk, and report the 224 unrecognized parameter in an 'Unrecognized Parameter Type' (in 225 either an ERROR or in the INIT ACK). 227 2.2.3. Solution description 229 It was always the intent to stop processing at the level one was at 230 in an unknown chunk or parameter with the upper bit set to 0. Thus 231 if you are processing a chunk, you should drop the packet. If you 232 are processing a parameter, you should drop the chunk. 234 2.3. Padding issues 236 2.3.1. Description of the problem 238 A problem was found in that when a Chunk terminated in a TLV 239 parameter. If this last TLV was not on a 32 bit boundary (as 240 required), there was confusion as to if the last padding was included 241 in the chunk length. 243 2.3.2. Text changes to the document 245 --------- 246 Old text: (Section 3.2) 247 --------- 248 Chunk Length: 16 bits (unsigned integer) 250 This value represents the size of the chunk in bytes including the 251 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 252 Therefore, if the Chunk Value field is zero-length, the Length 253 field will be set to 4. The Chunk Length field does not count any 254 padding. 256 Chunk Value: variable length 258 The Chunk Value field contains the actual information to be 259 transferred in the chunk. The usage and format of this field is 260 dependent on the Chunk Type. 262 The total length of a chunk (including Type, Length and Value fields) 263 MUST be a multiple of 4 bytes. If the length of the chunk is not a 264 multiple of 4 bytes, the sender MUST pad the chunk with all zero 265 bytes and this padding is not included in the chunk length field. 266 The sender should never pad with more than 3 bytes. The receiver 267 MUST ignore the padding bytes. 269 --------- 270 New text: (Section 3.2) 271 --------- 273 Chunk Length: 16 bits (unsigned integer) 275 This value represents the size of the chunk in bytes including the 276 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 277 Therefore, if the Chunk Value field is zero-length, the Length 278 field will be set to 4. The Chunk Length field does not count any 279 chunk padding. 281 Chunks (including Type, Length and Value fields) are padded out by 282 the sender with all zero bytes to be a multiple of 4 bytes long. 283 This padding MUST NOT be more than 3 bytes in total. The Chunk 284 Length value does not include terminating padding of the Chunk. 285 However, it does include padding of any variable length parameter 286 except the last parameter in the Chunk. The receiver MUST ignore 287 the padding. 289 Note: A robust implementation should accept the Chunk whether 290 or not the final padding has been included in the Chunk Length. 292 Chunk Value: variable length 294 The Chunk Value field contains the actual information to be 295 transferred in the chunk. The usage and format of this field is 296 dependent on the Chunk Type. 298 The total length of a chunk (including Type, Length and Value fields) 299 MUST be a multiple of 4 bytes. If the length of the chunk is not a 300 multiple of 4 bytes, the sender MUST pad the chunk with all zero 301 bytes and this padding is not included in the chunk length field. 302 The sender should never pad with more than 3 bytes. The receiver 303 MUST ignore the padding bytes. 305 2.3.3. Solution description 307 The above text makes clear that the padding of the last parameter is 308 not included in the Chunk Length field. It also clarifies that the 309 padding of parameters that are not the last one must be counted in 310 the Chunk Length field. 312 2.4. Parameter types across all chunk types 314 2.4.1. Description of the problem 316 A problem was noted when multiple errors are needed to be sent 317 regarding unknown or unrecognized parameters. Since often times the 318 error type does not hold the chunk type field, it may become 319 difficult to tell which error was associated with which chunk. 321 2.4.2. Text changes to the document 323 --------- 324 Old text: (Section 3.2.1) 325 --------- 327 The actual SCTP parameters are defined in the specific SCTP chunk 328 sections. The rules for IETF-defined parameter extensions are 329 defined in Section 13.2. 331 --------- 332 New text: (Section 3.2.1) 333 --------- 335 The actual SCTP parameters are defined in the specific SCTP chunk 336 sections. The rules for IETF-defined parameter extensions are 337 defined in Section 13.2. Note that a parameter type MUST be unique 338 across all chunks. For example, the parameter type '5' is used to 339 represent an IPv4 address (see section 3.3.2). The value '5' then is 340 reserved across all chunks to represent an IPv4 address and MUST NOT 341 be reused with a different meaning in any other chunk. 343 --------- 344 Old text: (Section 13.2) 345 --------- 347 13.2 IETF-defined Chunk Parameter Extension 349 The assignment of new chunk parameter type codes is done through an 350 IETF Consensus action as defined in [RFC2434]. Documentation of the 351 chunk parameter MUST contain the following information: 353 a) Name of the parameter type. 355 b) Detailed description of the structure of the parameter field. 356 This structure MUST conform to the general type-length-value 357 format described in Section 3.2.1. 359 c) Detailed definition of each component of the parameter type. 361 d) Detailed description of the intended use of this parameter type, 362 and an indication of whether and under what circumstances multiple 363 instances of this parameter type may be found within the same 364 chunk. 366 --------- 367 New text: (Section 13.2) 368 --------- 370 13.2 IETF-defined Chunk Parameter Extension 372 The assignment of new chunk parameter type codes is done through an 373 IETF Consensus action as defined in [RFC2434]. Documentation of the 374 chunk parameter MUST contain the following information: 376 a) Name of the parameter type. 378 b) Detailed description of the structure of the parameter field. This 379 structure MUST conform to the general type-length-value format 380 described in Section 3.2.1. 382 c) Detailed definition of each component of the parameter type. 384 d) Detailed description of the intended use of this parameter type, 385 and an indication of whether and under what circumstances multiple 386 instances of this parameter type may be found within the same 387 chunk. 389 e) Each parameter type MUST be unique across all chunks. 391 2.4.3. Solution description 393 By having all parameters unique across all chunk assignments (the 394 current assignment policy) no ambiguity exists as to what a parameter 395 means based on context. The trade off for this is a smaller 396 parameter space i.e. 65,536 parameters versus 65,536 * Number-of- 397 chunks. 399 2.5. Stream parameter clarification 401 2.5.1. Description of the problem 403 A problem was found where the specification is unclear on the 404 legality of an endpoint asking for more stream resources than were 405 allowed in the MIS value of the INIT. In particular the value in the 406 INIT ACK requested in its OS value was larger than the MIS value 407 received in the INIT chunk. This behavior is illegal yet it was 408 unspecified in RFC2960 [7] 410 2.5.2. Text changes to the document 412 --------- 413 Old text: (Section 3.3.3) 414 --------- 416 Number of Outbound Streams (OS): 16 bits (unsigned integer) 418 Defines the number of outbound streams the sender of this INIT ACK 419 chunk wishes to create in this association. The value of 0 MUST 420 NOT be used. 422 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD 423 destroy the association discarding its TCB. 425 --------- 426 New text: (Section 3.3.3) 427 --------- 429 Number of Outbound Streams (OS): 16 bits (unsigned integer) 431 Defines the number of outbound streams the sender of this INIT ACK 432 chunk wishes to create in this association. The value of 0 MUST 433 NOT be used and the value MUST NOT be greater than the MIS value 434 sent in the INIT chunk. 436 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD 437 destroy the association discarding its TCB. 439 2.5.3. Solution description 441 The change in wording, above, changes it so that a responder to an 442 INIT chunk does not specify more streams in its OS value than was 443 represented to it in the MIS value i.e. its maximum. 445 2.6. Restarting association security issue 447 2.6.1. Description of the problem 449 A security problem was found when a restart occurs. It is possible 450 for an intruder to send an INIT to an endpoint of an existing 451 association. In the INIT the intruder would list one or more of the 452 current addresses of an association and its own. The normal restart 453 procedures would then occur and the intruder would have hi-jacked an 454 association. 456 2.6.2. Text changes to the document 458 --------- 459 Old text: (Section 3.3.10) 460 --------- 462 Cause Code 463 Value Cause Code 464 --------- ---------------- 465 1 Invalid Stream Identifier 466 2 Missing Mandatory Parameter 467 3 Stale Cookie Error 468 4 Out of Resource 469 5 Unresolvable Address 470 6 Unrecognized Chunk Type 471 7 Invalid Mandatory Parameter 472 8 Unrecognized Parameters 473 9 No User Data 474 10 Cookie Received While Shutting Down 476 Cause Length: 16 bits (unsigned integer) 478 Set to the size of the parameter in bytes, including the Cause 479 Code, Cause Length, and Cause-Specific Information fields 481 Cause-specific Information: variable length 483 This field carries the details of the error condition. 485 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. 487 Guidelines for the IETF to define new error cause values are 488 discussed in Section 13.3. 490 --------- 491 New text: (Section 3.3.10) 492 --------- 494 Cause Code 495 Value Cause Code 496 --------- ---------------- 497 1 Invalid Stream Identifier 498 2 Missing Mandatory Parameter 499 3 Stale Cookie Error 500 4 Out of Resource 501 5 Unresolvable Address 502 6 Unrecognized Chunk Type 503 7 Invalid Mandatory Parameter 504 8 Unrecognized Parameters 505 9 No User Data 506 10 Cookie Received While Shutting Down 507 11 Restart of an association with new addresses 509 Cause Length: 16 bits (unsigned integer) 511 Set to the size of the parameter in bytes, including the Cause 512 Code, Cause Length, and Cause-Specific Information fields 514 Cause-specific Information: variable length 516 This field carries the details of the error condition. 518 Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. 519 Guidelines for the IETF to define new error cause values are 520 discussed in Section 13.3. 522 --------- 523 New text: (Note no old text, new error cause added in section 3.3.10) 524 --------- 526 3.3.10.11 Restart of an association with new addresses (11) 528 Cause of error 529 -------------- 530 Restart of an association with new addresses: An INIT was received 531 on an existing association. But the INIT added addresses to the 532 association that were previously NOT part of the association. The 533 New addresses are listed in the error code. This ERROR is normally 534 sent as part of an ABORT refusing the INIT (see section 5.2). 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Cause Code=11 | Cause Length=Variable | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 / New Address TLVs / 540 \ \ 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Note: each New Address TLV is an exact copy of the TLV 544 that was found in the INIT chunk that was new including the 545 Parameter Type and the Parameter length. 547 --------- 548 Old text: (Section 5.2.1) 549 --------- 551 Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an 552 endpoint MUST respond with an INIT ACK using the same parameters it 553 sent in its original INIT chunk (including its Initiation Tag, 554 unchanged). These original parameters are combined with those from 555 the newly received INIT chunk. The endpoint shall also generate a 556 State Cookie with the INIT ACK. The endpoint uses the parameters 557 sent in its INIT to calculate the State Cookie. 559 --------- 560 New text: (Section 5.2.1) 561 --------- 563 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 564 respond with an INIT ACK using the same parameters it sent in its 565 original INIT chunk (including its Initiation Tag, unchanged). When 566 responding the endpoint MUST send the INIT ACK back to the same 567 address that the original INIT (sent by this endpoint) was sent to. 569 Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST 570 respond with an INIT ACK using the same parameters it sent in its 571 original INIT chunk (including its Initiation Tag, unchanged) 572 provided that no NEW address have been added to the forming 573 association. If the INIT message indicates that a new address(es) 574 have been added to the association, then the entire INIT MUST be 575 discarded and NO changes should be made to the existing association. 576 An ABORT SHOULD be sent in response that MAY include the error 577 'Restart of an association with new addresses'. The error SHOULD list 578 the addresses that were added to the restarting association. 580 When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with 581 an INIT ACK the original parameters are combined with those from the 582 newly received INIT chunk. The endpoint shall also generate a State 583 Cookie with the INIT ACK. The endpoint uses the parameters sent in 584 its INIT to calculate the State Cookie. 586 --------- 587 Old text: (Section 5.2.2) 588 --------- 590 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 591 COOKIE-WAIT and SHUTDOWN-ACK-SENT 593 Unless otherwise stated, upon reception of an unexpected INIT for 594 this association, the endpoint shall generate an INIT ACK with a 595 State Cookie. In the outbound INIT ACK the endpoint MUST copy its 596 current Verification Tag and peer's Verification Tag into a reserved 597 place within the state cookie. We shall refer to these locations as 598 the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet 599 containing this INIT ACK MUST carry a Verification Tag value equal to 600 the Initiation Tag found in the unexpected INIT. And the INIT ACK 601 MUST contain a new Initiation Tag (randomly generated see Section 602 5.3.1). Other parameters for the endpoint SHOULD be copied from the 603 existing parameters of the association (e.g. number of outbound 604 streams) into the INIT ACK and cookie. 606 After sending out the INIT ACK, the endpoint shall take no further 607 actions, i.e., the existing association, including its current state, 608 and the corresponding TCB MUST NOT be changed. 610 Note: Only when a TCB exists and the association is not in a COOKIE- 611 WAIT state are the Tie-Tags populated. For a normal association INIT 612 (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be 613 set to 0 (indicating that no previous TCB existed). The INIT ACK and 614 State Cookie are populated as specified in section 5.2.1. 616 --------- 617 New text: (Section 5.2.2) 618 --------- 620 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 621 COOKIE-WAIT and SHUTDOWN-ACK-SENT 623 Unless otherwise stated, upon reception of an unexpected INIT for 624 this association, the endpoint shall generate an INIT ACK with a 625 State Cookie. Before responding the endpoint MUST check to see if the 626 unexpected INIT adds new addresses to the association. If new 627 addresses are added to the association, the endpoint MUST respond 628 with an ABORT copying the 'Initiation Tag' of the unexpected INIT 629 into the 'Verification Tag' of the outbound packet carrying the 630 ABORT. In the ABORT response the cause of error MAY be set to 631 'restart of an association with new addresses'. The error SHOULD 632 list the addresses that were added to the restarting association. 634 If no new addresses are added, when responding to the INIT in the 635 outbound INIT ACK the endpoint MUST copy its current Verification Tag 636 and peer's Verification Tag into a reserved place within the state 637 cookie. We shall refer to these locations as the Peer's-Tie-Tag and 638 the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK 639 MUST carry a Verification Tag value equal to the Initiation Tag found 640 in the unexpected INIT. And the INIT ACK MUST contain a new 641 Initiation Tag (randomly generated see Section 5.3.1). Other 642 parameters for the endpoint SHOULD be copied from the existing 643 parameters of the association (e.g. number of outbound streams) into 644 the INIT ACK and cookie. 646 After sending out the INIT ACK or ABORT, the endpoint shall take no 647 further actions, i.e., the existing association, including its 648 current state, and the corresponding TCB MUST NOT be changed. 650 Note: Only when a TCB exists and the association is not in a COOKIE- 651 WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags 652 populated with a value other than 0. For a normal association INIT 653 (i.e. the endpoint is in the CLOSED state), the Tie-Tags MUST be set 654 to 0 (indicating that no previous TCB existed). 656 2.6.3. Solution description 658 A new error code is being added and specific instructions to send 659 back an ABORT to a new association in a restart case or collision 660 case, where new addresses have been added. The error code can be 661 used by a legitimate restart to inform the endpoint that it has made 662 a software error in adding a new address. The endpoint then can 663 choose to wait until the OOTB ABORT tears down the old association, 664 or restart without the new address. 666 Also the Note at the end of section 5.2.2 explaining the use of the 667 Tie-Tags was modified to properly explain the states in which the 668 Tie-Tags should be set to a value different than 0. 670 2.7. Implicit ability to exceed cwnd by PMTU-1 bytes 672 2.7.1. Description of the problem 674 Some implementations were having difficulty growing their cwnd. This 675 was due to an improper enforcement of the congestion control rules. 676 The rules, as written, provided for a slop over of the cwnd value. 677 Without this slop over the sender would appear to NOT be using its 678 full cwnd value and thus never increase it. 680 2.7.2. Text changes to the document 682 --------- 683 Old text: (Section 6.1) 684 --------- 686 B) At any given time, the sender MUST NOT transmit new data to a 687 given transport address if it has cwnd or more bytes of data 688 outstanding to that transport address. 690 --------- 691 New text: (Section 6.1) 692 --------- 694 B) At any given time, the sender MUST NOT transmit new data to a 695 given transport address if it has cwnd or more bytes of data 696 outstanding to that transport address. The sender may exceed cwnd 697 by up to (PMTU-1) bytes on a new transmission if the cwnd is not 698 currently exceeded. 700 2.7.3. Solution description 702 The text changes make clear the ability to go over the cwnd value by 703 no more than (PMTU-1) bytes. 705 2.8. Issues with Fast Retransmit 707 2.8.1. Description of the problem 709 Several problems were found in the current specification of fast 710 retransmit. The current wording did not require GAP ACK blocks to be 711 sent, even though they are essential to the workings of SCTP's 712 congestion control. The specification left unclear how to handle the 713 fast retransmit cycle, having the implementation to wait on the cwnd 714 to retransmit a TSN that was marked for fast retransmit. No limit 715 was placed on how many times a TSN could be fast retransmitted. Fast 716 Recovery was not specified, causing the congestion window to be 717 reduced drastically when there are multiple losses in a single RTT. 719 2.8.2. Text changes to the document 721 --------- 722 Old text: (Section 6.2) 723 --------- 725 Acknowledgments MUST be sent in SACK chunks unless shutdown was 726 requested by the ULP in which case an endpoint MAY send an 727 acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge 728 the reception of multiple DATA chunks. See Section 3.3.4 for SACK 729 chunk format. In particular, the SCTP endpoint MUST fill in the 730 Cumulative TSN Ack field to indicate the latest sequential TSN (of a 731 valid DATA chunk) it has received. Any received DATA chunks with TSN 732 greater than the value in the Cumulative TSN Ack field SHOULD also be 733 reported in the Gap Ack Block fields. 735 --------- 736 New text: (Section 6.2) 737 --------- 739 Acknowledgments MUST be sent in SACK chunks unless shutdown was 740 requested by the ULP in which case an endpoint MAY send an 741 acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge 742 the reception of multiple DATA chunks. See Section 3.3.4 for SACK 743 chunk format. In particular, the SCTP endpoint MUST fill in the 744 Cumulative TSN Ack field to indicate the latest sequential TSN (of a 745 valid DATA chunk) it has received. Any received DATA chunks with 746 TSN greater than the value in the Cumulative TSN Ack field are 747 reported in the Gap Ack Block fields. The SCTP endpoint MUST 748 report as many Gap Ack Blocks that can fit in a single SACK 749 chunk limited by the current path MTU. 751 --------- 752 Old text: (Section 6.2.1) 753 --------- 754 D) Any time a SACK arrives, the endpoint performs the following: 756 i) If Cumulative TSN Ack is less than the Cumulative TSN Ack 757 Point, then drop the SACK. Since Cumulative TSN Ack is 758 monotonically increasing, a SACK whose Cumulative TSN Ack is 759 less than the Cumulative TSN Ack Point indicates an out-of- 760 order SACK. 762 ii) Set rwnd equal to the newly received a_rwnd minus the 763 number of bytes still outstanding after processing the 764 Cumulative TSN Ack and the Gap Ack Blocks. 766 iii) If the SACK is missing a TSN that was previously 767 acknowledged via a Gap Ack Block (e.g., the data receiver 768 reneged on the data), then mark the corresponding DATA chunk 769 as available for retransmit: Mark it as missing for fast 770 retransmit as described in Section 7.2.4 and if no 771 retransmit timer is running for the destination address 772 to which the DATA chunk was originally transmitted, then 773 T3-rtx is started for that destination address. 775 --------- 776 New text: (Section 6.2.1) 777 --------- 779 D) Any time a SACK arrives, the endpoint performs the following: 781 i) If Cumulative TSN Ack is less than the Cumulative TSN Ack 782 Point, then drop the SACK. Since Cumulative TSN Ack is 783 monotonically increasing, a SACK whose Cumulative TSN Ack is 784 less than the Cumulative TSN Ack Point indicates an out-of- 785 order SACK. 787 ii) Set rwnd equal to the newly received a_rwnd minus the 788 number of bytes still outstanding after processing the 789 Cumulative TSN Ack and the Gap Ack Blocks. 791 iii) If the SACK is missing a TSN that was previously 792 acknowledged via a Gap Ack Block (e.g., the data receiver 793 reneged on the data), then consider the corresponding DATA 794 to be possibly missing: Count one miss indication towards 795 fast retransmit as described in Section 7.2.4 and if no 796 retransmit timer is running for the destination address to 797 which the DATA chunk was originally transmitted, then T3-rtx 798 is started for that destination address. 800 iv) If the Cumulative TSN Ack matches or exceeds the Fast 801 Recovery exitpoint (Section 7.2.4), Fast Recovery is exited. 803 --------- 804 Old text: (Section 7.2.4) 805 --------- 807 Whenever an endpoint receives a SACK that indicates some TSN(s) 808 missing, it SHOULD wait for 3 further miss indications (via 809 subsequent SACK's) on the same TSN(s) before taking action with 810 regard to Fast Retransmit. 812 When the TSN(s) is reported as missing in the fourth consecutive 813 SACK, the data sender shall: 815 1) Mark the missing DATA chunk(s) for retransmission, 817 2) Adjust the ssthresh and cwnd of the destination address(es) to 818 which the missing DATA chunks were last sent, according to the 819 formula described in Section 7.2.3. 821 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 822 marked for retransmission will fit into a single packet, subject 823 to constraint of the path MTU of the destination transport address 824 to which the packet is being sent. Call this value K. Retransmit 825 those K DATA chunks in a single packet. 827 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 828 outstanding TSN number sent to that address, or the endpoint is 829 retransmitting the first outstanding DATA chunk sent to that 830 address. 832 Note: Before the above adjustments, if the received SACK also 833 acknowledges new DATA chunks and advances the Cumulative TSN Ack 834 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 835 must be applied first. 837 A straightforward implementation of the above keeps a counter for 838 each TSN hole reported by a SACK. The counter increments for each 839 consecutive SACK reporting the TSN hole. After reaching 4 and 840 starting the fast retransmit procedure, the counter resets to 0. 841 Because cwnd in SCTP indirectly bounds the number of outstanding 842 TSN's, the effect of TCP fast-recovery is achieved automatically with 843 no adjustment to the congestion control window size. 845 --------- 846 New text: (Section 7.2.4) 847 --------- 849 Whenever an endpoint receives a SACK that indicates some TSN(s) 850 missing, it SHOULD wait for 3 further miss indications (via 851 subsequent SACK's) on the same TSN(s) before taking action with 852 regard to Fast Retransmit. 854 Miss indications SHOULD follow the HTNA (Highest TSN Newly 855 Acknowledged) algorithm. For each incoming SACK, miss 856 indications are incremented only for missing TSNs prior to 857 the highest TSN newly acknowledged in the SACK. A newly 858 acknowledged DATA chunk is one not previously acknowledged 859 in a SACK. If an endpoint is in Fast Recovery and a SACK 860 arrives that advances the Cumulative TSN Ack Point, the 861 miss indications are incremented for all TSNs reported 862 missing in the SACK. 864 When the fourth consecutive miss indication is recieved for a TSN(s), 865 the data sender shall: 867 1) Mark the DATA chunk(s) with four miss indications for 868 retransmission. 870 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the 871 destination address(es) to which the missing DATA chunks were 872 last sent, according to the formula described in Section 7.2.3. 874 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 875 marked for retransmission will fit into a single packet, subject 876 to constraint of the path MTU of the destination transport address 877 to which the packet is being sent. Call this value K. Retransmit 878 those K DATA chunks in a single packet. When a Fast Retransmit is 879 being performed the sender SHOULD ignore the value of cwnd and 880 SHOULD NOT delay retransmission for this single packet. 882 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 883 outstanding TSN number sent to that address, or the endpoint is 884 retransmitting the first outstanding DATA chunk sent to that 885 address. 887 5) Mark the DATA chunk(s) as being fast retransmitted and thus 888 ineligible for a subsequent fast retransmit. Those TSNs marked 889 for retransmission due to the Fast Retransmit algorithm that 890 did not fit in the sent datagram carrying K other TSNs are also 891 marked as ineligible for a subsequent fast retransmit. However, 892 as they are marked for retransmission they will be retransmitted 893 later on as soon as cwnd allows. 895 6) If not in Fast Recovery, enter Fast Recovery and mark the highest 896 outstanding TSN as the Fast Recovery exit point. When a SACK 897 acknowledges all TSNs up to and including this exit point, Fast 898 Recovery is exited. While in Fast Recovery, the ssthresh and cwnd 899 SHOULD NOT change for any destinations due to a subsequent Fast 900 Recovery event (i.e. one SHOULD NOT reduce the cwnd further due 901 to a subsequent fast retransmit). 903 Note: Before the above adjustments, if the received SACK also 904 acknowledges new DATA chunks and advances the Cumulative TSN Ack 905 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 906 must be applied first. 908 2.8.3. Solution description 910 The effect of the above wording changes are as follows: 912 o It requires with a MUST the sending of GAP Ack blocks instead of 913 the current RFC2960 [7] SHOULD. 915 o It allows a TSN being Fast Retransmitted (FR) to be sent only once 916 via FR. 918 o It ends the delay in awaiting for the flight size to drop when a 919 TSN is identified ready to FR. 921 o It changes the way chunks are marked during fast retransmit, so 922 that only new reports are counted. 924 o It introduces a Fast Recovery period to avoid multiple congestion 925 window reductions when there are multiple losses in a single RTT 926 (as shown by Caro et al. [4]). 928 These changes will effectively allow SCTP to follow a similar model 929 as TCP+SACK in the handling of Fast Retransmit. 931 2.9. Missing statement about partial_bytes_acked update 933 2.9.1. Description of the problem 935 SCTP uses four control variables to regulate its transmission rate: 936 rwnd, cwnd, ssthresh and partial_bytes_acked. Upon detection of 937 packet losses from SACK or when the T3-rtx timer expires on an 938 address cwnd and ssthresh should be updated as stated in section 939 7.2.3. However, that section should also clarify that 940 partial_bytes_acked must be updated as well, having to be reset to 0. 942 2.9.2. Text changes to the document 944 --------- 945 Old text: (Section 7.2.3) 946 --------- 948 7.2.3 Congestion Control 950 Upon detection of packet losses from SACK (see Section 7.2.4), An 951 endpoint should do the following: 953 ssthresh = max(cwnd/2, 2*MTU) 954 cwnd = ssthresh 956 Basically, a packet loss causes cwnd to be cut in half. 958 When the T3-rtx timer expires on an address, SCTP should perform slow 959 start by: 961 ssthresh = max(cwnd/2, 2*MTU) 962 cwnd = 1*MTU 964 --------- 965 New text: (Section 7.2.3) 966 --------- 968 7.2.3 Congestion Control 970 Upon detection of packet losses from SACK (see Section 7.2.4), an 971 endpoint should do the following if not in Fast Recovery: 973 ssthresh = max(cwnd/2, 2*MTU) 974 cwnd = ssthresh 975 partial_bytes_acked = 0 977 Basically, a packet loss causes cwnd to be cut in half. 979 When the T3-rtx timer expires on an address, SCTP should perform slow 980 start by: 982 ssthresh = max(cwnd/2, 2*MTU) 983 cwnd = 1*MTU 984 partial_bytes_acked = 0 986 2.9.3. Solution description 988 The missing text added solves the doubts about what to do with 989 partial_bytes_acked in the situations stated in section 7.2.3, making 990 clear that along with ssthresh and cwnd, partial_bytes_acked should 991 also be updated, having to be reset to 0. 993 2.10. Issues with Heartbeating and failure detection 995 2.10.1. Description of the problem 997 Five basic problems have been discovered with the current heartbeat 998 procedures: 1000 o The current specification does not specify that you should count a 1001 failed heartbeat as an error against the overall association. 1003 o The current specification is un-specific as to when you start 1004 sending heartbeats and when you should stop. 1006 o The current specification is un-specific as to when you should 1007 respond to heartbeats. 1009 o When responding to a Heartbeat it is unclear what to do if more 1010 than a single TLV is present. 1012 o The jitter applied to a heartbeat was meant to be a small variance 1013 of the RTO and is currently a wide variance due to the default 1014 delay time and incorrect wording within the RFC. 1016 2.10.2. Text changes to the document 1018 --------- 1019 Old text: (Section 8.1) 1020 --------- 1022 8.1 Endpoint Failure Detection 1024 An endpoint shall keep a counter on the total number of 1025 consecutive retransmissions to its peer (including 1026 retransmissions to all the destination transport addresses 1027 of the peer if it is multi-homed). If the value of this 1028 counter exceeds the limit indicated in the protocol 1029 parameter 'Association.Max.Retrans', the endpoint shall 1030 consider the peer endpoint unreachable and shall stop transmitting 1031 any more data to it (and thus the association enters the CLOSED 1032 state). In addition, the endpoint shall report the failure to the 1033 upper layer, and optionally report back all outstanding user data 1034 remaining in its outbound queue. The association is automatically 1035 closed when the peer endpoint becomes unreachable. 1037 The counter shall be reset each time a DATA chunk sent to that 1038 peer endpoint is acknowledged (by the reception of a SACK), or a 1039 HEARTBEAT-ACK is received from the peer endpoint. 1041 --------- 1042 New text: (Section 8.1) 1043 --------- 1045 8.1 Endpoint Failure Detection 1047 An endpoint shall keep a counter on the total number of 1048 consecutive retransmissions to its peer (this includes 1049 retransmissions to all the destination transport addresses 1050 of the peer if it is multi-homed), including unacknowledged 1051 HEARTBEAT Chunks. If the value of this counter exceeds the 1052 limit indicated in the protocol parameter 1053 'Association.Max.Retrans', the endpoint shall consider the peer 1054 endpoint unreachable and shall stop transmitting any more 1055 data to it (and thus the association enters the CLOSED state). 1056 In addition, the endpoint MAY report the failure to the upper 1057 layer, and optionally report back all outstanding user data 1058 remaining in its outbound queue. The association is 1059 automatically closed when the peer endpoint becomes 1060 unreachable. 1062 The counter shall be reset each time a DATA chunk sent to 1063 that peer endpoint is acknowledged (by the reception of a 1064 SACK), or a HEARTBEAT-ACK is received from the peer endpoint. 1066 --------- 1067 Old text: (Section 8.3) 1068 --------- 1070 8.3 Path Heartbeat 1072 By default, an SCTP endpoint shall monitor the reachability of 1073 the idle destination transport address(es) of its peer by 1074 sending a HEARTBEAT chunk periodically to the destination 1075 transport address(es). 1077 --------- 1078 New text: (Section 8.3) 1079 --------- 1081 8.3 Path Heartbeat 1083 By default, an SCTP endpoint SHOULD monitor the reachability of 1084 the idle destination transport address(es) of its peer by 1085 sending a HEARTBEAT chunk periodically to the destination 1086 transport address(es). HEARTBEAT sending MAY begin upon 1087 reaching the ESTABLISHED state, and is discontinued after 1088 sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a 1089 HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK 1090 after entering the COOKIE-ECHOED state (INIT sender) or the 1091 ESTABLISHED state (INIT receiver), up until reaching the 1092 SHUTDOWN-SENT state (SHUTDOWN sender) or the 1093 SHUTDOWN-ACK-SENT state (SHUTDOWN receiver). 1095 --------- 1096 Old text: (Section 8.3) 1097 --------- 1099 The receiver of the HEARTBEAT should immediately respond with a 1100 HEARTBEAT ACK that contains the Heartbeat Information field 1101 copied from the received HEARTBEAT chunk. 1103 --------- 1104 New text: (Section 8.3) 1105 --------- 1107 The receiver of the HEARTBEAT should immediately respond with a 1108 HEARTBEAT ACK that contains the Heartbeat Information TLV, 1109 together with any other received TLVs, copied unchanged from 1110 the received HEARTBEAT chunk. 1112 --------- 1113 Old text: (Section 8.3) 1114 --------- 1116 On an idle destination address that is allowed to heartbeat, a 1117 HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that 1118 destination address plus the protocol parameter 'HB.interval' , 1119 with jittering of +/- 50%, and exponential back-off of the RTO 1120 if the previous HEARTBEAT is unanswered. 1122 --------- 1123 New text: (Section 8.3) 1124 --------- 1126 On an idle destination address that is allowed to heartbeat, a 1127 HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that 1128 destination address plus the protocol parameter 'HB.interval' , 1129 with jittering of +/- 50% of the RTO value, and exponential 1130 back-off of the RTO if the previous HEARTBEAT is unanswered. 1132 2.10.3. Solution description 1134 The above text provides guidance as to how to respond to the five 1135 issues mentioned in Section 2.10.1 In particular the wording changes 1136 provide guidance as to when to start and stop heartbeating, how to 1137 respond to a heartbeat with extra parameters, and clarifies the error 1138 counting procedures for the association. 1140 2.11. Security interactions with firewalls 1142 2.11.1. Description of the problem 1144 When dealing with firewalls it is advantageous to the firewall to be 1145 able to properly determine the initial startup sequence of a reliable 1146 transport protocol. With this in mind the following text is to be 1147 added to SCTP's security section. 1149 2.11.2. Text changes to the document 1151 --------- 1152 New text: (no old text, new section added) 1153 --------- 1155 11.4 SCTP interactions with firewalls 1157 It is helpful for some firewalls if they can inspect 1158 just the first fragment of a fragmented SCTP packet and unambiguously 1159 determine whether it corresponds to an INIT chunk (for further 1160 information please refer to RFC1858). Accordingly, we 1161 stress the requirements stated in 3.1 that (1) an INIT chunk MUST NOT 1162 be bundled with any other chunk in a packet, and (2) a packet 1163 containing an INIT chunk MUST have a zero Verification Tag. 1164 Furthermore, we require that the receiver of an INIT chunk MUST 1165 enforce these rules by silently discarding an arriving packet with an 1166 INIT chunk that is bundled with other chunks. 1168 --------- 1169 Old text: (Section 18) 1170 --------- 1172 18. Bibliography 1174 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 1175 Network Path Properties", Proc. SIGCOMM'99, 1999. 1177 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of 1178 Tahoe, Reno, and SACK TCP, Computer Communications Review, 1179 V. 26 N. 3, July 1996, pp. 5-21. 1181 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 1182 Security", RFC 1750, December 1994. 1184 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format 1185 Specification version 3.3", RFC 1950, May 1996. 1187 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 1188 Hashing for Message Authentication", RFC 2104, March 1997. 1190 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 1191 September 1997. 1193 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1194 Protocol", RFC 2522, March 1999. 1196 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 1197 "TCP Congestion Control with a Misbehaving Receiver", ACM 1198 Computer Communication Review, 29(5), October 1999. 1200 --------- 1201 New text: (Section 18) 1202 --------- 1204 18. Bibliography 1206 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 1207 Network Path Properties", Proc. SIGCOMM'99, 1999. 1209 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of 1210 Tahoe, Reno, and SACK TCP, Computer Communications Review, 1211 V. 26 N. 3, July 1996, pp. 5-21. 1213 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 1214 Security", RFC 1750, December 1994. 1216 [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security 1217 Considerations for IP Fragment Filtering", RFC 1858, 1218 October 1995. 1220 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format 1221 Specification version 3.3", RFC 1950, May 1996. 1223 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 1224 Hashing for Message Authentication", RFC 2104, March 1997. 1226 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 1227 September 1997. 1229 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1230 Protocol", RFC 2522, March 1999. 1232 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 1233 "TCP Congestion Control with a Misbehaving Receiver", ACM 1234 Computer Communication Review, 29(5), October 1999. 1236 2.11.3. Solution description 1238 The above text adding a new subsection to the Security Considerations 1239 section of RFC2960 [7] makes clear that, to make easier the 1240 interaction with firewalls, an INIT chunk must not be bundled in any 1241 case with any other chunk, being this rule enforced by the packet 1242 receiver, that will silently discard the packets that do not follow 1243 this rule. 1245 2.12. Shutdown ambiguity 1247 2.12.1. Description of the problem 1249 Currently there is an ambiguity between the statements in section 6.2 1250 and section 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk 1251 in place of a SACK when the sender is in the process of shutting 1252 down, while section 9.2 requires both a SHUTDOWN chunk and a SACK 1253 chunk to be sent. 1255 Along with this ambiguity there is a problem where in an errant 1256 SHUTDOWN receiver may fail to stop accepting user data. 1258 2.12.2. Text changes to the document 1259 --------- 1260 Old text: (Section 9.2) 1261 --------- 1263 If there are still outstanding DATA chunks left, the SHUTDOWN 1264 receiver shall continue to follow normal data transmission procedures 1265 defined in Section 6 until all outstanding DATA chunks are 1266 acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data 1267 from its SCTP user. 1269 While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately 1270 respond to each received packet containing one or more DATA chunk(s) 1271 with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If 1272 it has no more outstanding DATA chunks, the SHUTDOWN receiver shall 1273 send a SHUTDOWN ACK and start a T2-shutdown timer of its own, 1274 entering the SHUTDOWN-ACK-SENT state. If the timer expires, the 1275 endpoint must re-send the SHUTDOWN ACK. 1277 --------- 1278 New text: (Section 9.2) 1279 --------- 1281 If there are still outstanding DATA chunks left, the SHUTDOWN 1282 receiver MUST continue to follow normal data transmission procedures 1283 defined in Section 6 until all outstanding DATA chunks are 1284 acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data 1285 from its SCTP user. 1287 While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately 1288 respond to each received packet containing one or more DATA chunk(s) 1289 with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a 1290 SHUTDOWN chunk by itself cannot acknowledge all of the received DATA 1291 chunks (i.e. there are TSN's that can be acknowledged that are larger 1292 than the cumulative TSN and thus gaps exist in the TSN sequence) or 1293 if duplicate TSN's have been recieved then a SACK chunk MUST also be 1294 sent. 1296 The sender of the SHUTDOWN MAY also start an overall guard timer 1297 'T5-shutdown-guard' to bound the overall time for shutdown sequence. 1298 At the expiration of this timer the sender SHOULD abort the 1299 association by sending an ABORT chunk. If the 'T5-shutdown-guard' 1300 timer is used, it SHOULD be set to the recommended value of 5 times 1301 'RTO.Max'. 1303 If the receiver of the SHUTDOWN has no more outstanding DATA chunks, 1304 the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a 1305 T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. 1306 If the timer expires, the endpoint must re-send the SHUTDOWN ACK. 1308 2.12.3. Solution description 1310 The above text clarifies the use of a SACK in conjunction with a 1311 SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown 1312 sequence to protect against errant receivers of SHUTDOWN chunks. 1314 2.13. Inconsistency in ABORT processing 1316 2.13.1. Description of the problem 1318 It was noted that the wording in section 8.5.1 did not give proper 1319 directions in the use of the 'T bit' with the verification tags. 1321 2.13.2. Text changes to the document 1323 --------- 1324 Old text: (Section 8.5.1) 1325 --------- 1327 B) Rules for packet carrying ABORT: 1329 - The endpoint shall always fill in the Verification Tag field 1330 of the outbound packet with the destination endpoint's tag 1331 value if it is known. 1333 - If the ABORT is sent in response to an OOTB packet, the 1334 endpoint MUST follow the procedure described in Section 8.4. 1336 - The receiver MUST accept the packet if the Verification Tag 1337 matches either its own tag, OR the tag of its peer. Otherwise, 1338 the receiver MUST silently discard the packet and take no 1339 further action. 1341 --------- 1342 New text: (Section 8.5.1) 1343 --------- 1345 B) Rules for packet carrying ABORT: 1347 - The endpoint MUST always fill in the Verification Tag field of 1348 the outbound packet with the destination endpoint's tag value 1349 if it is known. 1351 - If the ABORT is sent in response to an OOTB packet, the 1352 endpoint MUST follow the procedure described in Section 8.4. 1354 - The receiver of a ABORT MUST accept the packet if the 1355 Verification Tag field of the packet matches its own tag OR it 1356 is set to its peer's tag and the T bit is set in the Chunk 1357 Flags. Otherwise, the receiver MUST silently discard the packet 1358 and take no further action. 1360 2.13.3. Solution description 1362 The above text change clarifies that the T bit must be set before an 1363 implementation looks for the peers tag. 1365 2.14. Cwnd gated by its full use 1366 2.14.1. Description of the problem 1368 A problem was found with the current specification of the growth and 1369 decay of cwnd. The cwnd should only be increased if it is being 1370 fully utilized, and after periods of under utilization, the cwnd 1371 should be decreased. In some sections, the current wording is weak 1372 and is not clearly defined. Also, the current specification 1373 unnecessarily introduces the need for special case code to ensure 1374 cwnd degradation. Plus, the cwnd should not be increased during Fast 1375 Recovery since a full cwnd during Fast Recovery does not qualify the 1376 cwnd as being fully utilized. Additionally, multiple loss scenarios 1377 in a single window may cause the cwnd to grow more rapidly as the 1378 number of losses in a window increases [4]. 1380 2.14.2. Text changes to the document 1382 --------- 1383 Old text: (Section 6.1) 1384 --------- 1386 D) Then, the sender can send out as many new DATA chunks as Rule A 1387 and Rule B above allow. 1389 --------- 1390 New text: (Section 6.1) 1391 --------- 1393 D) When the time comes for the sender to transmit new DATA chunks, 1394 the protocol parameter Max.Burst SHOULD be used to limit the 1395 number of packets sent. The limit MAY be applied by adjusting 1396 cwnd as follows: 1398 if((flightsize + Max.Burst*MTU) < cwnd) 1399 cwnd = flightsize + Max.Burst*MTU 1401 Or it MAY be applied by strictly limiting the number of packets 1402 emitted by the output routine. 1404 E) Then, the sender can send out as many new DATA chunks as Rule A 1405 and Rule B above allow. 1407 --------- 1408 Old text: (Section 7.2.1) 1409 --------- 1411 o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST 1412 use the slow start algorithm to increase cwnd (assuming the 1413 current congestion window is being fully utilized). If an 1414 incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be 1415 increased by at most the lesser of 1) the total size of the 1416 previously outstanding DATA chunk(s) acknowledged, and 2) the 1417 destination's path MTU. This protects against the ACK-Splitting 1418 attack outlined in [SAVAGE99]. 1420 --------- 1421 New text: (Section 7.2.1) 1422 --------- 1424 o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST 1425 use the slow start algorithm to increase cwnd only if the current 1426 congestion window is being fully utilized, an incoming SACK 1427 advances the Cumulative TSN Ack Point, and the data sender is not 1428 in Fast Recovery. Only when these three conditions are met, can 1429 the cwnd be increased; otherwise the cwnd MUST not be increased. 1430 If these conditions are met then cwnd MUST be increased by at 1431 most the lesser of 1) the total size of the previously outstanding 1432 DATA chunk(s) acknowledged, and 2) the destination's path MTU. 1433 This upper bound protects against the ACK-Splitting attack 1434 outlined in [SAVAGE99]. 1436 --------- 1437 Old text: (Section 14) 1438 --------- 1440 14. Suggested SCTP Protocol Parameter Values 1442 The following protocol parameters are RECOMMENDED: 1444 RTO.Initial - 3 seconds 1445 RTO.Min - 1 second 1446 RTO.Max - 60 seconds 1447 RTO.Alpha - 1/8 1448 RTO.Beta - 1/4 1449 Valid.Cookie.Life - 60 seconds 1450 Association.Max.Retrans - 10 attempts 1451 Path.Max.Retrans - 5 attempts (per destination address) 1452 Max.Init.Retransmits - 8 attempts 1453 HB.interval - 30 seconds 1455 --------- 1456 New text: (Section 14) 1457 --------- 1458 14. Suggested SCTP Protocol Parameter Values 1460 The following protocol parameters are RECOMMENDED: 1462 RTO.Initial - 3 seconds 1463 RTO.Min - 1 second 1464 RTO.Max - 60 seconds 1465 Max.Burst - 4 1466 RTO.Alpha - 1/8 1467 RTO.Beta - 1/4 1468 Valid.Cookie.Life - 60 seconds 1469 Association.Max.Retrans - 10 attempts 1470 Path.Max.Retrans - 5 attempts (per destination address) 1471 Max.Init.Retransmits - 8 attempts 1472 HB.Interval - 30 seconds 1474 2.14.3. Solution description 1476 The above changes strengthens the rules and makes it much more 1477 apparent as to the need to block cwnd growth when the full cwnd is 1478 not being utilized. The changes also applies cwnd degradation 1479 without introducing the need for complex special case code. 1481 2.15. Window probes in SCTP 1483 2.15.1. Description of the problem 1485 When a receiver clamps its rwnd to 0 to flow control the peer, the 1486 specification implies that one must continue to accept data from the 1487 remote peer. This is incorrect and needs clarification. 1489 2.15.2. Text changes to the document 1491 --------- 1492 Old text: (Section 6.2) 1493 --------- 1495 The SCTP endpoint MUST always acknowledge the reception of each valid 1496 DATA chunk. 1498 --------- 1499 New text: (Section 6.2) 1500 --------- 1502 The SCTP endpoint MUST always acknowledge the reception of each 1503 valid DATA chunk when the DATA chunk received is inside its receive 1504 window. 1506 When the receiver's advertised window is 0, the receiver MUST drop 1507 any new incoming DATA chunk with a TSN larger than the largest TSN 1508 received so far. If the new incoming DATA chunk holds a TSN value 1509 less than the largest TSN received so far, then the receiver SHOULD 1510 drop the largest TSN held for reordering, and accept the new 1511 incoming DATA chunk. In either case, if such a DATA chunk is dropped, 1512 the receiver MUST immediately send back a SACK with the current 1513 receive window showing only DATA chunks received and accepted so 1514 far. The dropped DATA chunk(s) MUST NOT be included in the SACK as 1515 they were not accepted. The receiver MUST also have an algorithm 1516 for advertising its receive window to avoid receiver silly window 1517 syndrome (SWS) as described in RFC 813. The algorithm can be 1518 similar to the one described in Section 4.2.3.3 of RFC 1122. 1520 --------- 1521 Old text: (Section 6.1) 1522 --------- 1524 A) At any given time, the data sender MUST NOT transmit new data to 1525 any destination transport address if its peer's rwnd indicates 1526 that the peer has no buffer space (i.e. rwnd is 0, see Section 1527 6.2.1). However, regardless of the value of rwnd (including if it 1528 is 0), the data sender can always have one DATA chunk in flight to 1529 the receiver if allowed by cwnd (see rule B below). This rule 1530 allows the sender to probe for a change in rwnd that the sender 1531 missed due to the SACK having been lost in transit from the data 1532 receiver to the data sender. 1534 --------- 1535 New text: (Section 6.1) 1536 --------- 1538 A) At any given time, the data sender MUST NOT transmit new data to 1539 any destination transport address if its peer's rwnd indicates 1540 that the peer has no buffer space (i.e. rwnd is 0, see Section 1541 6.2.1). However, regardless of the value of rwnd (including if it 1542 is 0), the data sender can always have one DATA chunk in flight to 1543 the receiver if allowed by cwnd (see rule B below). This rule 1544 allows the sender to probe for a change in rwnd that the sender 1545 missed due to the SACK having been lost in transit from the data 1546 receiver to the data sender. 1548 When the receiver's advertised window is zero, this probe is 1549 called a zero window probe. Note that a zero window probe 1550 SHOULD only be sent when all outstanding DATA chunks have 1551 been cumulatively acknowledged and no DATA chunk(s) are in 1552 flight. Zero window probing MUST be supported. 1554 If the sender continues to receive new packets from the receiver 1555 while doing zero window probing, the unacknowledged window probes 1556 should not increment the error counter for the association or any 1557 destination transport address.The reason is that the receiver MAY 1558 keep its window closed for an indefinite time. Refer to 1559 Section 6.2 on the receiver behavior when it advertises a zero 1560 window. The sender SHOULD send the first zero window probe after 1561 1 RTO when it detects that the receiver has closed its window, 1562 and SHOULD increase the probe interval exponentially afterwards. 1563 Also note that the cwnd SHOULD be adjusted according to 1564 Section 7.2.1. Zero window probing does not affect the 1565 calculation of cwnd. 1567 The sender MUST also have an algorithm for sending new DATA chunks 1568 to avoid silly window syndrome (SWS) as described in RFC 813. The 1569 algorithm can be similar to the one described in Section 4.2.3.4 1570 of RFC 1122. 1572 2.15.3. Solution description 1574 The above allows a receiver to drop new data that arrives and yet 1575 still requires the receiver to send a SACK showing the conditions 1576 unchanged (with the possible exception of a new a_rwnd) and the 1577 dropped chunk as missing. This will allow the association to 1578 continue until the rwnd condition clears. 1580 2.16. Fragmentation and Path MTU issues 1582 2.16.1. Description of the problem 1584 The current wording of the Fragmentation and Reassembly forces an 1585 implementation that supports fragmentation to always fragment. This 1586 prohibits an implementation from offering its users an option to 1587 disable sends that exceed the SCTP fragmentation point. 1589 The restriction in RFC2960 [7] section 6.9 was never meant to 1590 restrict an implementations API from this behavior. 1592 2.16.2. Text changes to the document 1594 --------- 1595 Old text: (Section 6.1) 1596 --------- 1598 6.9 Fragmentation and Reassembly 1600 An endpoint MAY support fragmentation when sending DATA chunks, but 1601 MUST support reassembly when receiving DATA chunks. If an endpoint 1602 supports fragmentation, it MUST fragment a user message if the size 1603 of the user message to be sent causes the outbound SCTP packet size 1604 to exceed the current MTU. If an implementation does not support 1605 fragmentation of outbound user messages, the endpoint must return an 1606 error to its upper layer and not attempt to send the user message. 1608 IMPLEMENTATION NOTE: In this error case, the Send primitive 1609 discussed in Section 10.1 would need to return an error to the upper 1610 layer. 1612 --------- 1613 New text: (Section 6.1) 1614 --------- 1616 6.9 Fragmentation and Reassembly 1618 An endpoint MAY support fragmentation when sending DATA chunks, but 1619 MUST support reassembly when receiving DATA chunks. If an endpoint 1620 supports fragmentation, it MUST fragment a user message if the size 1621 of the user message to be sent causes the outbound SCTP packet size 1622 to exceed the current MTU. If an implementation does not support 1623 fragmentation of outbound user messages, the endpoint MUST return 1624 an error to its upper layer and not attempt to send the user 1625 message. 1627 Note: If an implementation that supports fragmentation makes 1628 available to its upper layer a mechanism to turn off fragmentation 1629 it may do so. However in so doing, it MUST react just like an 1630 implementation that does NOT support fragmentation i.e. it MUST 1631 reject sends that exceed the current P-MTU. 1633 IMPLEMENTATION NOTE: In this error case, the Send primitive 1634 discussed in Section 10.1 would need to return an error to the upper 1635 layer. 1637 2.16.3. Solution description 1639 The above wording will allow an implementation to offer the option of 1640 rejecting sends that exceed the P-MTU size even when the 1641 implementation supports fragmentation. 1643 2.17. Initial value of the cumulative TSN Ack 1645 2.17.1. Description of the problem 1647 The current description of the SACK chunk within the RFC does not 1648 clearly state the value that would be put within a SACK when no DATA 1649 chunk has been received. 1651 2.17.2. Text changes to the document 1653 --------- 1654 Old text: (Section 3.3.4) 1655 --------- 1657 Cumulative TSN Ack: 32 bits (unsigned integer) 1659 This parameter contains the TSN of the last DATA chunk received in 1660 sequence before a gap. 1662 --------- 1663 New text: (Section 3.3.4) 1664 --------- 1666 Cumulative TSN Ack: 32 bits (unsigned integer) 1668 This parameter contains the TSN of the last DATA chunk received in 1669 sequence before a gap. In the case where no DATA chunk has 1670 been received, this value is set to the peers Initial TSN minus 1671 one. 1673 2.17.3. Solution description 1675 This change clearly states what the initial value will be for a SACK 1676 sender. 1678 2.18. Handling of address parameters within the INIT or INIT-ACK 1680 2.18.1. Description of the problem 1682 The current description on handling address parameters contained 1683 within the INIT and INIT-ACK do not fully describe a requirement for 1684 their handling. 1686 2.18.2. Text changes to the document 1688 --------- 1689 Old text: (Section 5.1.2) 1690 --------- 1692 C) If there are only IPv4/IPv6 addresses present in the received INIT 1693 or INIT ACK chunk, the receiver shall derive and record all the 1694 transport address(es) from the received chunk AND the source IP 1695 address that sent the INIT or INIT ACK. The transport address(es) 1696 are derived by the combination of SCTP source port (from the 1697 common header) and the IP address parameter(s) carried in the INIT 1698 or INIT ACK chunk and the source IP address of the IP datagram. 1699 The receiver should use only these transport addresses as 1700 destination transport addresses when sending subsequent packets to 1701 its peer. 1703 --------- 1704 New text: (Section 5.1.2) 1705 --------- 1707 C) If there are only IPv4/IPv6 addresses present in the received INIT 1708 or INIT ACK chunk, the receiver MUST derive and record all the 1709 transport address(es) from the received chunk AND the source IP 1710 address that sent the INIT or INIT ACK. The transport address(es) 1711 are derived by the combination of SCTP source port (from the 1712 common header) and the IP address parameter(s) carried in the INIT 1713 or INIT ACK chunk and the source IP address of the IP datagram. 1714 The receiver should use only these transport addresses as 1715 destination transport addresses when sending subsequent packets to 1716 its peer. 1718 D) An INIT or INIT ACK chunk MUST be treated as belonging 1719 to an already established association (or one in the 1720 process of being established) if the use of any of the 1721 valid address parameters contained within the chunk 1722 would identify an existing TCB. 1724 2.18.3. Solution description 1726 This new text clearly specifies to an implementor the need to look 1727 within the INIT or INIT ACK. Any implementation that does not do 1728 this, may for example not be able to recognize an INIT chunk coming 1729 from an already established association that adds new addresses (see 1730 section 2.6), or an incoming INIT ACK chunk sent from a source 1731 address different than the destination address used to send the INIT 1732 chunk. 1734 2.19. Handling of stream shortages 1736 2.19.1. Description of the problem 1738 The current wording in the RFC places the choice of sending an ABORT 1739 upon the SCTP stack when a stream shortage occurs. This decision 1740 should really be made by the upper layer not the SCTP stack. 1742 2.19.2. Text changes to the document 1744 --------- 1745 Old text: 1746 --------- 1748 5.1.1 Handle Stream Parameters 1750 In the INIT and INIT ACK chunks, the sender of the chunk shall 1751 indicate the number of outbound streams (OS) it wishes to have in 1752 the association, as well as the maximum inbound streams (MIS) it 1753 will accept from the other endpoint. 1755 After receiving the stream configuration information from the other 1756 side, each endpoint shall perform the following check: If the peer's 1757 MIS is less than the endpoint's OS, meaning that the peer is 1758 incapable of supporting all the outbound streams the endpoint wants 1759 to configure, the endpoint MUST either use MIS outbound streams, or 1760 abort the association and report to its upper layer the resources 1761 shortage at its peer. 1763 --------- 1764 New text: (Section 5.1.2) 1765 --------- 1767 5.1.1 Handle Stream Parameters 1769 In the INIT and INIT ACK chunks, the sender of the chunk MUST 1770 indicate the number of outbound streams (OS) it wishes to have in 1771 the association, as well as the maximum inbound streams (MIS) it will 1772 accept from the other endpoint. 1774 After receiving the stream configuration information from the other 1775 side, each endpoint MUST perform the following check: If the peer's 1776 MIS is less than the endpoint's OS, meaning that the peer is 1777 incapable of supporting all the outbound streams the endpoint wants 1778 to configure, the endpoint MUST use MIS outbound streams and MAY 1779 report any shortage to the upper layer. The upper layer can then 1780 choose to abort the association if the resource shortage 1781 is unacceptable. 1783 2.19.3. Solution description 1785 The above changes take the decision to ABORT out of the realm of the 1786 SCTP stack and places it into the users hands. 1788 2.20. Indefinite postponement 1790 2.20.1. Description of the problem 1792 The current RFC does not provide any guidance on the assignment of 1793 TSN sequence numbers to outbound message nor reception of these 1794 message. This could lead to a possible indefinite postponement. 1796 2.20.2. Text changes to the document 1798 --------- 1799 Old text: (Section 6.1) 1800 --------- 1802 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1803 1 above the beginning TSN of the current send window. 1805 6.2 Acknowledgment on Reception of DATA Chunks 1807 --------- 1808 New text: (Section 6.1) 1809 --------- 1811 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1812 1 above the beginning TSN of the current send window. 1814 The algorithm by which an implementation assigns sequential TSNs to 1815 messages on a particular association MUST ensure that no user 1816 message that has been accepted by SCTP is indefinitely postponed 1817 from being assigned a TSN. Acceptable algorithms for assigning TSNs 1818 include 1820 (a) assigning TSNs in round-robin order over all streams with 1821 pending data 1823 (b) preserving the linear order in which the user messages were 1824 submitted to the SCTP association. 1826 When an upper layer requests to read data on an SCTP association, 1827 the SCTP receiver SHOULD choose the message with the lowest TSN from 1828 among all deliverable messages. In SCTP implementations that allow a 1829 user to request data on a specific stream, this operation SHOULD NOT 1830 block if data is not available, since this can lead to a deadlock 1831 under certain conditions. 1833 6.2 Acknowledgment on Reception of DATA Chunks 1835 2.20.3. Solution description 1837 The above wording clarifies how TSNs SHOULD be assigned by the 1838 sender. 1840 2.21. User initiated abort of an association 1842 2.21.1. Description of the problem 1844 It is not possible for an upper layer to abort the association and 1845 provide the peer with an indication why the association is aborted. 1847 2.21.2. Text changes to the document 1849 Some of the changes given here already include changes suggested in 1850 section Section 2.6 of this document. 1852 --------- 1853 Old text: (Section 3.3.10) 1854 --------- 1856 Cause Code 1857 Value Cause Code 1858 --------- ---------------- 1859 1 Invalid Stream Identifier 1860 2 Missing Mandatory Parameter 1861 3 Stale Cookie Error 1862 4 Out of Resource 1863 5 Unresolvable Address 1864 6 Unrecognized Chunk Type 1865 7 Invalid Mandatory Parameter 1866 8 Unrecognized Parameters 1867 9 No User Data 1868 10 Cookie Received While Shutting Down 1870 Cause Length: 16 bits (unsigned integer) 1872 Set to the size of the parameter in bytes, including the Cause 1873 Code, Cause Length, and Cause-Specific Information fields 1875 Cause-specific Information: variable length 1877 This field carries the details of the error condition. 1879 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. 1880 Guidelines for the IETF to define new error cause values are 1881 discussed in Section 13.3. 1883 --------- 1884 New text: (Section 3.3.10) 1885 --------- 1887 Cause Code 1888 Value Cause Code 1889 --------- ---------------- 1890 1 Invalid Stream Identifier 1891 2 Missing Mandatory Parameter 1892 3 Stale Cookie Error 1893 4 Out of Resource 1894 5 Unresolvable Address 1895 6 Unrecognized Chunk Type 1896 7 Invalid Mandatory Parameter 1897 8 Unrecognized Parameters 1898 9 No User Data 1899 10 Cookie Received While Shutting Down 1900 11 Restart of an association with new addresses 1901 12 User Initiated Abort 1903 Cause Length: 16 bits (unsigned integer) 1905 Set to the size of the parameter in bytes, including the Cause 1906 Code, Cause Length, and Cause-Specific Information fields 1908 Cause-specific Information: variable length 1910 This field carries the details of the error condition. 1912 Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP. 1913 Guidelines for the IETF to define new error cause values are 1914 discussed in Section 13.3. 1916 --------- 1917 New text: (Note no old text, new error added in section 3.3.10) 1918 --------- 1920 3.3.10.12 User Initiated Abort (12) 1922 Cause of error 1923 -------------- 1925 This error cause MAY be included in ABORT chunks which are send 1926 because of an upper layer request. The upper layer can specify 1927 an Upper Layer Abort Reason which is transported by SCTP 1928 transparently and MAY be delivered to the upper layer protocol 1929 at the peer. 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Cause Code=12 | Cause Length=Variable | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 / Upper Layer Abort Reason / 1935 \\ \\ 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 --------- 1939 Old text: (Section 9.1) 1940 --------- 1942 9.1 Abort of an Association 1944 When an endpoint decides to abort an existing association, 1945 it shall send an ABORT chunk to its peer endpoint. The 1946 sender MUST fill in the peer's Verification Tag in the 1947 outbound packet and MUST NOT bundle any DATA chunk 1948 with the ABORT. 1950 An endpoint MUST NOT respond to any received packet that contains 1951 an ABORT chunk (also see Section 8.4). 1953 An endpoint receiving an ABORT shall apply the special 1954 Verification Tag check rules described in Section 8.5.1. 1956 After checking the Verification Tag, the receiving endpoint shall 1957 remove the association from its record, and shall report the 1958 termination to its upper layer. 1960 --------- 1961 New text: (Section 9.1) 1962 --------- 1964 9.1 Abort of an Association 1966 When an endpoint decides to abort an existing association, it MUST 1967 send an ABORT chunk to its peer endpoint. The sender MUST fill in 1968 the peer's Verification Tag in the outbound packet and MUST NOT 1969 bundle any DATA chunk with the ABORT. If the association is 1970 aborted on request of the upper layer a User Initiated Abort error 1971 cause (see 3.3.10.12) SHOULD be present in the ABORT chunk. 1973 An endpoint MUST NOT respond to any received packet that contains 1974 an ABORT chunk (also see Section 8.4). 1976 An endpoint receiving an ABORT MUST apply the special Verification 1977 Tag check rules described in Section 8.5.1. 1979 After checking the Verification Tag, the receiving endpoint MUST 1980 remove the association from its record, and SHOULD report the 1981 termination to its upper layer. If an User Initiated Abort error 1982 cause is present in the ABORT chunk the Upper Layer Abort Reason 1983 SHOULD be made available to the upper layer. 1985 --------- 1986 Old text: (Section 10.1) 1987 --------- 1989 D) Abort 1991 Format: ABORT(association id [, cause code]) 1992 -> result 1994 Ungracefully closes an association. Any locally queued user 1995 data will be discarded and an ABORT chunk is sent to the peer. 1996 A success code will be returned on successful abortion of the 1997 association. If attempting to abort the association results 1998 in a failure, an error code shall be returned. 2000 Mandatory attributes: 2002 o association id - local handle to the SCTP association 2004 Optional attributes: 2006 o cause code - reason of the abort to be passed to the peer. 2008 --------- 2009 New text: (Section 10.1) 2010 --------- 2012 D) Abort 2014 Format: ABORT(association id [, Upper Layer Abort Reason]) 2015 -> result 2017 Ungracefully closes an association. Any locally queued user 2018 data will be discarded and an ABORT chunk is sent to the peer. 2019 A success code will be returned on successful abortion of the 2020 association. If attempting to abort the association results 2021 in a failure, an error code shall be returned. 2023 Mandatory attributes: 2025 o association id - local handle to the SCTP association 2026 Optional attributes: 2028 o Upper Layer Abort Reason - reason of the abort to be passed 2029 to the peer. 2031 None. 2033 --------- 2034 Old text: (Section 10.2) 2035 --------- 2037 E) COMMUNICATION LOST notification 2039 When SCTP loses communication to an endpoint completely (e.g., via 2040 Heartbeats) or detects that the endpoint has performed an abort 2041 operation, it shall invoke this notification on the ULP. 2043 The following shall be passed with the notification: 2045 o association id - local handle to the SCTP association 2047 o status - This indicates what type of event has occurred; The 2048 status may indicate a failure OR a normal termination 2049 event occurred in response to a shutdown or abort 2050 request. 2052 The following may be passed with the notification: 2054 o data retrieval id - an identification used to retrieve 2055 unsent and unacknowledged data. 2057 o last-acked - the TSN last acked by that peer endpoint; 2059 o last-sent - the TSN last sent to that peer endpoint; 2061 --------- 2062 New 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 2076 status may indicate a failure OR a normal termination 2077 event occurred in response to a shutdown or 2078 abort request. 2080 The following may be passed with the notification: 2082 o data retrieval id - an identification used to retrieve unsent 2083 and unacknowledged data. 2085 o last-acked - the TSN last acked by that peer endpoint; 2087 o last-sent - the TSN last sent to that peer endpoint; 2089 o Upper Layer Abort Reason - the abort reason specified if 2090 case of an user initiated abort. 2092 2.21.3. Solution description 2094 The above allows an upper layer to provide its peer with an 2095 indication why the association was aborted. Therefore an addition 2096 error cause was introduced. 2098 2.22. Handling of invalid Initiate Tag of INIT-ACK 2100 2.22.1. Description of the problem 2102 RFC 2960 requires that the receiver of an INIT-ACK with the Initiate 2103 Tag set to zero handles this as an error and sends back an ABORT. 2104 But the sender of the INIT-ACK normally has no TCB and so the ABORT 2105 is useless. 2107 2.22.2. Text changes to the document 2109 --------- 2110 Old text: (Section 3.3.3) 2111 --------- 2113 Initiate Tag: 32 bits (unsigned integer) 2115 The receiver of the INIT ACK records the value of the 2116 Initiate Tag parameter. This value MUST be placed into 2117 the Verification Tag field of every SCTP packet that the 2118 INIT ACK receiver transmits within this association. 2120 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 2121 for more on the selection of the Initiate Tag value. 2123 If the value of the Initiate Tag in a received INIT ACK chunk 2124 is found to be 0, the receiver MUST treat it as an error and 2125 close the association by transmitting an ABORT. 2127 --------- 2128 New text: (Section 3.3.3) 2129 --------- 2131 Initiate Tag: 32 bits (unsigned integer) 2133 The receiver of the INIT ACK records the value of the 2134 Initiate Tag parameter. This value MUST be placed into 2135 the Verification Tag field of every SCTP packet that the 2136 INIT ACK receiver transmits within this association. 2138 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 2139 for more on the selection of the Initiate Tag value. 2141 If the value of the Initiate Tag in a received INIT ACK 2142 chunk is found to be 0, the receiver MUST destroy the 2143 association discarding its TCB. The receiver MAY send an 2144 ABORT for debugging purpose. 2146 2.22.3. Solution description 2148 The new text does not require the receiver of the invalid INIT-ACK to 2149 send the ABORT. This behavior is in tune with the error case of 2150 invalid stream numbers in the INIT-ACK. However it is allowed to 2151 send an ABORT for debugging purposes. 2153 2.23. ABORT sending in response to an INIT 2155 2.23.1. Description of the problem 2157 Whenever the receiver of an INIT chunk has to send an ABORT chunk in 2158 response for whatever reason it is not stated clearly which 2159 Verification Tag and value of the T-bit should be used. 2161 2.23.2. Text changes to the document 2163 --------- 2164 Old text: (Section 8.4) 2165 --------- 2167 3) If the packet contains an INIT chunk with a Verification Tag 2168 set to '0', process it as described in Section 5.1. 2169 Otherwise, 2171 --------- 2172 New text: (Section 8.4) 2173 --------- 2175 3) If the packet contains an INIT chunk with a Verification Tag 2176 set to '0', process it as described in Section 5.1. If, for 2177 whatever reason, the INIT can not be processed normally and 2178 an ABORT has to be sent in response, the Verification Tag 2179 of the packet containing the ABORT chunk MUST be the 2180 Initiate tag of the received INIT chunk and the T-Bit of 2181 the ABORT chunk has to be set to 0 indicating that 2182 a TCB was destroyed. Otherwise, 2184 2.23.3. Solution description 2186 The new text stated clearly which value of the Verification Tag and 2187 T-bit have to be used. 2189 2.24. Stream Sequence Number (SSN) Initialization 2191 2.24.1. Description of the problem 2193 RFC 2960 does not describe the fact that the SSN have to be 2194 initialized to 0 in the way it is required by RFC2119. 2196 2.24.2. Text changes to the document 2198 --------- 2199 Old text: (Section 6.5) 2200 --------- 2202 The stream sequence number in all the streams shall start 2203 from 0 when the association is established. Also, when 2204 the stream sequence number reaches the value 65535 the 2205 next stream sequence number shall be set to 0. 2207 --------- 2208 New text: (Section 6.5) 2209 --------- 2211 The stream sequence number in all the streams MUST start 2212 from 0 when the association is established. Also, when 2213 the stream sequence number reaches the value 65535 the 2214 next stream sequence number MUST be set to 0. 2216 2.24.3. Solution description 2218 The 'shall' in the text is replaced by a 'MUST' to clearly state the 2219 required behavior. 2221 2.25. SACK packet format 2223 2.25.1. Description of the problem 2225 It is not clear in RFC 2960 whether a SACK must contain the fields 2226 Number of Gap Ack Blocks and Number of Duplicate TSNs or not. 2228 2.25.2. Text changes to the document 2230 --------- 2231 Old text: (Section 3.3.4) 2232 --------- 2234 The SACK MUST contain the Cumulative TSN Ack and 2235 Advertised Receiver Window Credit (a_rwnd) parameters. 2237 --------- 2238 New text: (Section 3.3.4) 2239 --------- 2241 The SACK MUST contain the Cumulative TSN Ack, 2242 Advertised Receiver Window Credit (a_rwnd), Number 2243 of Gap Ack Blocks, and Number of Duplicate TSNs fields. 2245 2.25.3. Solution description 2247 The text has been modified. It is now clear that a SACK always 2248 contains the fields Number of Gap Ack Blocks and Number of Duplicate 2249 TSNs. 2251 2.26. Protocol Violation Error Cause 2253 2.26.1. Description of the problem 2255 There are many situations where an SCTP endpoint may detect that its 2256 peer violates the protocol. The result of such detection often 2257 results in the association being destroyed by the sending of an 2258 ABORT. Currently there are only some error causes which could be 2259 used to indicate the reason of the abort but these do not cover all 2260 cases. 2262 2.26.2. Text changes to the document 2264 Some of the changes given here already include changes suggested in 2265 section Section 2.6 and Section 2.21 of this document. 2267 --------- 2268 Old text: (Section 3.3.10) 2269 --------- 2271 Cause Code 2272 Value Cause Code 2273 --------- ---------------- 2274 1 Invalid Stream Identifier 2275 2 Missing Mandatory Parameter 2276 3 Stale Cookie Error 2277 4 Out of Resource 2278 5 Unresolvable Address 2279 6 Unrecognized Chunk Type 2280 7 Invalid Mandatory Parameter 2281 8 Unrecognized Parameters 2282 9 No User Data 2283 10 Cookie Received While Shutting Down 2285 Cause Length: 16 bits (unsigned integer) 2287 Set to the size of the parameter in bytes, including the Cause 2288 Code, Cause Length, and Cause-Specific Information fields 2290 Cause-specific Information: variable length 2292 This field carries the details of the error condition. 2294 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. 2295 Guidelines for the IETF to define new error cause values are 2296 discussed in Section 13.3. 2298 --------- 2299 New text: (Section 3.3.10) 2300 --------- 2302 Cause Code 2303 Value Cause Code 2304 --------- ---------------- 2305 1 Invalid Stream Identifier 2306 2 Missing Mandatory Parameter 2307 3 Stale Cookie Error 2308 4 Out of Resource 2309 5 Unresolvable Address 2310 6 Unrecognized Chunk Type 2311 7 Invalid Mandatory Parameter 2312 8 Unrecognized Parameters 2313 9 No User Data 2314 10 Cookie Received While Shutting Down 2315 11 Restart of an association with new addresses 2316 12 User Initiated Abort 2317 13 Protocol Violation 2319 Cause Length: 16 bits (unsigned integer) 2320 Set to the size of the parameter in bytes, including the Cause 2321 Code, Cause Length, and Cause-Specific Information fields 2323 Cause-specific Information: variable length 2325 This field carries the details of the error condition. 2327 Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP. 2328 Guidelines for the IETF to define new error cause values are 2329 discussed in Section 13.3. 2331 --------- 2332 New text: (Note no old text, new error added in section 3.3.10) 2333 --------- 2335 3.3.10.13 Protocol Violation (13) 2337 Cause of error 2338 -------------- 2340 This error cause MAY be included in ABORT chunks which are sent 2341 because an SCTP endpoint detects a protocol violation of the peer 2342 which is not covered by the error causes described in 3.3.10.1 to 2343 3.3.10.12. An implementation MAY provide Additional Information 2344 specifying what kind of protocol violation has been detected. 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Cause Code=13 | Cause Length=Variable | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 / Additional Information / 2350 \\ \\ 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 2.26.3. Solution description 2355 An additional error cause which can be used by an endpoint to 2356 indicate a protocol violation of the peer has been defined. 2358 2.27. Reporting of Unrecognized Parameters 2360 2.27.1. Description of the problem 2362 It is not stated clearly in RFC2960 [7] how unrecognized parameters 2363 should be reported. Unrecognized parameters in an INIT chunk could 2364 be reported in the INIT-ACK chunk or in a separate ERROR chunk which 2365 can get lost. Unrecognized parameters in an INIT-ACK chunk have to 2366 be reported in an ERROR-chunk. This can be bundled with the COOKIE- 2367 ERROR chunk or sent separately. If it is sent separately and 2368 received before the COOKIE-ECHO it will be handled as an OOTB packet 2369 resulting in sending out an ABORT chunk. Therefore the association 2370 would not be established. 2372 2.27.2. Text changes to the document 2374 Some of the changes given here already include changes suggested in 2375 section Section 2.2 of this document. 2377 --------- 2378 Old text: (Section 3.2.1) 2379 --------- 2381 00 - Stop processing this SCTP packet and discard it, do not process 2382 any further chunks within it. 2384 01 - Stop processing this SCTP packet and discard it, do not process 2385 any further chunks within it, and report the unrecognized 2386 parameter in an 'Unrecognized Parameter Type' (in either an 2387 ERROR or in the INIT ACK). 2389 10 - Skip this parameter and continue processing. 2391 11 - Skip this parameter and continue processing but report the 2392 unrecognized parameter in an 'Unrecognized Parameter Type' (in 2393 either an ERROR or in the INIT ACK). 2395 --------- 2396 New text: (Section 3.2.1) 2397 --------- 2399 00 - Stop processing this SCTP chunk and discard it, do not process 2400 any further parameters within this chunk. 2402 01 - Stop processing this SCTP chunk and discard it, do not process 2403 any further parameters within this chunk, and report the 2404 unrecognized parameter in an 'Unrecognized Parameter Type' as 2405 described in 3.2.2. 2407 10 - Skip this parameter and continue processing. 2409 11 - Skip this parameter and continue processing but report the 2410 unrecognized parameter in an 'Unrecognized Parameter Type' as 2411 described in 3.2.2. 2413 --------- 2414 New text: (Note no old text, clarification added in section 3.2) 2415 --------- 2417 3.2.2 Reporting of Unrecognized Parameters 2419 If the receiver of an INIT chunk detects unrecognized parameters 2420 and has to report them according to section 3.2.1 it MUST put 2421 the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk 2422 sent in response to the INIT-chunk. Note that if the receiver 2423 of the INIT chunk is NOT going to establish an association (e.g. 2424 due to lack of resources) then no report would be sent back. 2426 If the receiver of an INIT-ACK chunk detects unrecognized 2427 parameters and has to report them according to section 3.2.1 2428 it SHOULD bundle the ERROR chunk containing the 2429 'Unrecognized Parameters' error cause with the COOKIE-ECHO 2430 chunk sent in response to the INIT-ACK chunk. If the 2431 receiver of the INIT-ACK can not bundle the COOKIE-ECHO chunk 2432 with the ERROR chunk the ERROR chunk MAY be sent separately 2433 but not before the COOKIE-ACK has been received. 2435 Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the 2436 first chunk. 2438 2.27.3. Solution description 2440 The procedure of reporting unrecognized parameters has been described 2441 clearly. 2443 2.28. Handling of IP Address Parameters 2445 2.28.1. Description of the problem 2447 It is not stated clearly in RFC2960 [7] how a SCTP endpoint which 2448 supports either IPv4 addresses or IPv6 addresses should respond if 2449 IPv4 and IPv6 addresses are presented by the peer in the INIT or 2450 INIT-ACK chunk. 2452 2.28.2. Text changes to the document 2454 --------- 2455 Old text: (Section 5.1.2) 2456 --------- 2458 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK 2459 fails to resolve the address parameter due to an unsupported type, 2460 it can abort the initiation process and then attempt a 2461 re-initiation by using a 'Supported Address Types' parameter in 2462 the new INIT to indicate what types of address it prefers. 2464 --------- 2465 New text: (Section 5.1.2) 2466 --------- 2468 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK 2469 fails to resolve the address parameter due to an unsupported type, 2470 it can abort the initiation process and then attempt a 2471 re-initiation by using a 'Supported Address Types' parameter 2472 in the new INIT to indicate what types of address it prefers. 2474 IMPLEMENTATION NOTE: If a SCTP endpoint only supporting either 2475 IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or 2476 INIT-ACK chunk from its peer it MUST use all of the addresses 2477 belonging to the supported address family. The other addresses 2478 MAY be ignored. The endpoint SHOULD NOT respond with any kind 2479 of error indication. 2481 2.28.3. Solution description 2483 The procedure of handling IP address parameters has been described 2484 clearly. 2486 2.29. Handling of COOKIE ECHO chunks when a TCB exists 2488 2.29.1. Description of the problem 2490 The description of the behavior in RFC2960 [7] when a COOKIE ECHO 2491 chunk and a TCB exists could be misunderstood. When a COOKIE ECHO is 2492 received, a TCB exist and the local and peer's tag match it is stated 2493 that the endpoint should enter the ESTABLISHED state if it has not 2494 already done so and send a COOKIE ACK. It was not clear that in case 2495 the endpoint has already left again the ESTABLISHED state then it 2496 should not go back to established. In case D the endpoint can only 2497 enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it 2498 has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing 2499 about the peer's tag which is requested to match in this case. 2501 2.29.2. Text changes to the document 2503 --------- 2504 Old text: (Section 5.2.4) 2505 --------- 2506 D) When both local and remote tags match the endpoint should 2507 always enter the ESTABLISHED state, if it has not already 2508 done so. It should stop any init or cookie timers that may 2509 be running and send a COOKIE ACK. 2511 --------- 2512 New text: (Section 5.2.4) 2513 --------- 2514 D) When both local and remote tags match the endpoint should 2515 enter the ESTABLISHED state, if it is in the COOKIE-ECHOED 2516 state. It should stop any cookie timer that may 2517 be running and send a COOKIE ACK. 2519 2.29.3. Solution description 2521 The procedure of handling of COOKIE-ECHO chunks when a TCB exists has 2522 been described clearly. 2524 2.30. The Initial Congestion Window Size 2526 2.30.1. Description of the problem 2528 RFC2960 was published with the intention of having the same 2529 congestion control properties as TCP. Since the publication of 2530 RFC2960, TCP's initial congestion window size as been increased via 2531 RFC3390. This same update will be needed for SCTP to keep SCTP's 2532 congestion control properties equivilant to that of TCP. 2534 2.30.2. Text changes to the document 2536 --------- 2537 Old text: (Section 7.2.1) 2538 --------- 2539 o The initial cwnd before DATA transmission or after a 2540 sufficiently long idle period MUST be <= 2*MTU. 2542 --------- 2543 New text: (Section 7.2.1) 2544 --------- 2545 o The initial cwnd before DATA transmission or after a 2546 sufficiently long idle period MUST be set to 2547 min(4*MTU, max (2*MTU, 4380 bytes)). 2549 --------- 2550 Old text: (Section 7.2.1) 2551 --------- 2553 o When the endpoint does not transmit data on a given transport 2554 address, the cwnd of the transport address should be adjusted 2555 to max(cwnd/2, 2*MTU) per RTO. 2557 --------- 2558 New text: (Section 7.2.1) 2559 --------- 2560 o When the endpoint does not transmit data on a given transport 2561 address, the cwnd of the transport address should be adjusted 2562 to max(cwnd/2, 4*MTU) per RTO. 2563 --------- 2564 Old text: (Section 7.2.2) 2565 --------- 2566 o Same as in the slow start, when the sender does not transmit 2567 DATA on a given transport address, the cwnd of the transport 2568 address should be adjusted to max(cwnd / 2, 4*MTU) per RTO. 2569 --------- 2570 New text: (Section 7.2.2) 2571 --------- 2573 o Same as in the slow start, when the sender does not transmit 2574 DATA on a given transport address, the cwnd of the transport 2575 address should be adjusted to max(cwnd / 2, 4*MTU) per RTO. 2576 --------- 2577 Old text: (Section 7.2.3) 2578 --------- 2579 7.2.3 Congestion Control 2581 Upon detection of packet losses from SACK (see Section 7.2.4), An 2582 endpoint should do the following: 2584 ssthresh = max(cwnd/2, 2*MTU) 2585 cwnd = ssthresh 2587 Basically, a packet loss causes cwnd to be cut in half. 2589 When the T3-rtx timer expires on an address, SCTP should perform 2590 slow start by: 2592 ssthresh = max(cwnd/2, 2*MTU) 2593 cwnd = 1*MTU 2595 --------- 2596 New text: (Section 7.2.3) 2597 --------- 2598 7.2.3 Congestion Control 2600 Upon detection of packet losses from SACK (see Section 7.2.4), An 2601 endpoint should do the following: 2603 ssthresh = max(cwnd/2, 4*MTU) 2604 cwnd = ssthresh 2606 Basically, a packet loss causes cwnd to be cut in half. 2608 When the T3-rtx timer expires on an address, SCTP should perform 2609 slow start by: 2611 ssthresh = max(cwnd/2, 4*MTU) 2612 cwnd = 1*MTU 2614 2.30.3. Solution description 2616 The change to SCTP's initial congestion window will allow it to 2617 continue to maintain the same congestion control properties as TCP. 2619 2.31. Stream Sequence Numbers in Figures 2621 2.31.1. Description of the problem 2623 In Section 2.24 of this document it is clarified that the SSN are 2624 initialized with 0. Two figures in RFC2960 [7] illustrate that they 2625 start with 1. 2627 2.31.2. Text changes to the document 2629 --------- 2630 Old text: (Section 7.2.1) 2631 --------- 2633 Endpoint A Endpoint Z 2634 {app sets association with Z} 2635 (build TCB) 2636 INIT [I-Tag=Tag_A 2637 & other info] ------\ 2638 (Start T1-init timer) \ 2639 (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) 2648 /---- COOKIE-ACK 2649 / 2650 (Cancel T1-init timer, <-----/ 2651 Enter ESTABLISHED state) 2652 {app sends 1st user data; strm 0} 2653 DATA [TSN=initial TSN_A 2654 Strm=0,Seq=1 & user data]--\ 2655 (Start T3-rtx timer) \ 2656 \-> 2657 /----- SACK [TSN Ack=init 2658 / TSN_A,Block=0] 2659 (Cancel T3-rtx timer) <------/ 2660 ... 2661 {app sends 2 messages;strm 0} 2662 /---- DATA 2663 / [TSN=init TSN_Z 2664 <--/ Strm=0,Seq=1 & user data 1] 2665 SACK [TSN Ack=init TSN_Z, / ---- DATA 2666 Block=0] --------\ / [TSN=init TSN_Z +1, 2667 \/ Strm=0,Seq=2 & user data 2] 2668 <------/\ 2669 \ 2670 \------> 2672 Figure 4: INITiation Example 2674 --------- 2675 New text: (Section 7.2.1) 2676 --------- 2678 Endpoint A Endpoint Z 2679 {app sets association with Z} 2680 (build TCB) 2681 INIT [I-Tag=Tag_A 2682 & other info] ------\ 2683 (Start T1-init timer) \ 2684 (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) 2685 /-- INIT ACK [Veri Tag=Tag_A, 2686 / I-Tag=Tag_Z, 2687 (Cancel T1-init timer) <------/ Cookie_Z, & other info] 2688 (destroy temp TCB) 2689 COOKIE ECHO [Cookie_Z] ------\ 2690 (Start T1-init timer) \ 2691 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 2692 state) 2693 /---- COOKIE-ACK 2694 / 2695 (Cancel T1-init timer, <-----/ 2696 Enter ESTABLISHED state) 2697 {app sends 1st user data; strm 0} 2698 DATA [TSN=initial TSN_A 2699 Strm=0,Seq=0 & user data]--\ 2700 (Start T3-rtx timer) \ 2701 \-> 2702 /----- SACK [TSN Ack=init 2703 / TSN_A,Block=0] 2704 (Cancel T3-rtx timer) <------/ 2705 ... 2706 {app sends 2 messages;strm 0} 2707 /---- DATA 2708 / [TSN=init TSN_Z 2709 <--/ Strm=0,Seq=0 & user data 1] 2710 SACK [TSN Ack=init TSN_Z, /---- DATA 2711 Block=0] --------\ / [TSN=init TSN_Z +1, 2712 \/ Strm=0,Seq=1 & user data 2] 2713 <------/\ 2714 \ 2715 \------> 2717 Figure 4: INITiation Example 2719 --------- 2720 Old text: (Section 5.2.4.1) 2721 --------- 2723 Endpoint A Endpoint Z 2724 <------------ Association is established----------------------> 2725 Tag=Tag_A Tag=Tag_Z 2726 <-------------------------------------------------------------> 2727 {A crashes and restarts} 2728 {app sets up a association with Z} 2729 (build TCB) 2730 INIT [I-Tag=Tag_A' 2731 & other info] --------\ 2732 (Start T1-init timer) \ 2733 (Enter COOKIE-WAIT state) \---> (find a existing TCB 2734 compose temp TCB and Cookie_Z 2735 with Tie-Tags to previous 2736 association) 2737 /--- INIT ACK [Veri Tag=Tag_A', 2738 / I-Tag=Tag_Z', 2739 (Cancel T1-init timer) <------/ Cookie_Z[TieTags= 2740 Tag_A,Tag_Z 2741 & other info] 2742 (destroy temp TCB,leave original 2743 in place) 2744 COOKIE ECHO [Veri=Tag_Z', 2745 Cookie_Z 2746 Tie=Tag_A, 2747 Tag_Z]----------\ 2748 (Start T1-init timer) \ 2749 (Enter COOKIE-ECHOED state) \---> (Find existing association, 2750 Tie-Tags match old tags, 2751 Tags do not match i.e. 2752 case X X M M above, 2753 Announce Restart to ULP 2754 and reset association). 2755 /---- COOKIE-ACK 2756 / 2757 (Cancel T1-init timer, <-----/ 2758 Enter ESTABLISHED state) 2759 {app sends 1st user data; strm 0} 2760 DATA [TSN=initial TSN_A 2761 Strm=0,Seq=1 & user data]--\ 2762 (Start T3-rtx timer) \ 2763 \-> 2764 /--- SACK [TSN Ack=init TSN_A,Block=0] 2765 (Cancel T3-rtx timer) <------/ 2767 Figure 5: A Restart Example 2768 --------- 2769 New text: (Section 5.2.4.1) 2770 --------- 2772 Endpoint A Endpoint Z 2773 <-------------- Association is established----------------------> 2774 Tag=Tag_A Tag=Tag_Z 2775 <---------------------------------------------------------------> 2776 {A crashes and restarts} 2777 {app sets up a association with Z} 2778 (build TCB) 2779 INIT [I-Tag=Tag_A' 2780 & other info] --------\ 2781 (Start T1-init timer) \ 2782 (Enter COOKIE-WAIT state) \---> (find a existing TCB 2783 compose temp TCB and Cookie_Z 2784 with Tie-Tags to previous 2785 association) 2786 /--- INIT ACK [Veri Tag=Tag_A', 2787 / I-Tag=Tag_Z', 2788 (Cancel T1-init timer) <------/ Cookie_Z[TieTags= 2789 Tag_A,Tag_Z 2790 & other info] 2791 (destroy temp TCB,leave original 2792 in place) 2793 COOKIE ECHO [Veri=Tag_Z', 2794 Cookie_Z 2795 Tie=Tag_A, 2796 Tag_Z]----------\ 2797 (Start T1-init timer) \ 2798 (Enter COOKIE-ECHOED state) \---> (Find existing association, 2799 Tie-Tags match old tags, 2800 Tags do not match i.e. 2801 case X X M M above, 2802 Announce Restart to ULP 2803 and reset association). 2804 /---- COOKIE-ACK 2805 / 2806 (Cancel T1-init timer, <-----/ 2807 Enter ESTABLISHED state) 2808 {app sends 1st user data; strm 0} 2809 DATA [TSN=initial TSN_A 2810 Strm=0,Seq=0 & user data]--\ 2811 (Start T3-rtx timer) \ 2812 \-> 2813 /--- SACK [TSN Ack=init TSN_A,Block=0] 2814 (Cancel T3-rtx timer) <------/ 2816 Figure 5: A Restart Example 2818 2.31.3. Solution description 2820 Figure 4 and figure 5 were changed such that the SSN start with 0 2821 instead of 1. 2823 2.32. Unrecognized Parameters 2825 2.32.1. Description of the problem 2827 The RFC does not state clearly in section 3.3.3.1 if one or multiple 2828 unrecognized parameters are included in the 'Unrecognized Parameter' 2829 parameter. 2831 2.32.2. Text changes to the document 2833 --------- 2834 Old text: (Section 3.3.3) 2835 --------- 2836 Variable Parameters Status Type Value 2837 ------------------------------------------------------------- 2838 State Cookie Mandatory 7 2839 IPv4 Address (Note 1) Optional 5 2840 IPv6 Address (Note 1) Optional 6 2841 Unrecognized Parameters Optional 8 2842 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 2843 Host Name Address (Note 3) Optional 11 2845 --------- 2846 New text: (Section 3.3.3) 2847 --------- 2848 Variable Parameters Status Type Value 2849 ------------------------------------------------------------- 2850 State Cookie Mandatory 7 2851 IPv4 Address (Note 1) Optional 5 2852 IPv6 Address (Note 1) Optional 6 2853 Unrecognized Parameter Optional 8 2854 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 2855 Host Name Address (Note 3) Optional 11 2857 --------- 2858 Old text: (Section 3.3.3.1) 2859 --------- 2860 Unrecognized Parameters: 2862 Parameter Type Value: 8 2864 Parameter Length: Variable Size. 2866 Parameter Value: 2867 This parameter is returned to the originator of the INIT 2868 chunk when the INIT contains an unrecognized parameter 2869 which has a value that indicates that it should be reported 2870 to the sender. This parameter value field will contain 2871 unrecognized parameters copied from the INIT chunk complete 2872 with Parameter Type, Length and Value fields. 2874 --------- 2875 New text: (Section 3.3.3.1) 2876 --------- 2877 Unrecognized Parameter: 2879 Parameter Type Value: 8 2881 Parameter Length: Variable Size. 2883 Parameter Value: 2885 This parameter is returned to the originator of the INIT 2886 chunk when the INIT contains an unrecognized parameter 2887 which has a value that indicates that it should be reported 2888 to the sender. This parameter value field will contain the 2889 unrecognized parameter copied from the INIT chunk complete 2890 with Parameter Type, Length and Value fields. 2892 2.32.3. Solution description 2894 The new text states clearly that only one unrecognized parameter is 2895 reported per parameter. 2897 2.33. Handling of unrecognized parameters 2899 2.33.1. Description of the problem 2901 It is not stated clearly in RFC2960 [7] how unrecognized parameters 2902 should be handled. The problem came up when an INIT contains an 2903 unrecognized parameter with highest bits 00. It was not clear if an 2904 INIT-ACK should be sent or not. 2906 2.33.2. Text changes to the document 2908 Some of the changes given here already include changes suggested in 2909 section Section 2.27 of this document. 2911 --------- 2912 Old text: (Section 3.2.1) 2913 --------- 2915 00 - Stop processing this SCTP packet and discard it, do not process 2916 any further chunks within it. 2918 01 - Stop processing this SCTP packet and discard it, do not process 2919 any further chunks within it, and report the unrecognized 2920 parameter in an 'Unrecognized Parameter Type' (in either an 2921 ERROR or in the INIT ACK). 2923 10 - Skip this parameter and continue processing. 2925 11 - Skip this parameter and continue processing but report the 2926 unrecognized parameter in an 'Unrecognized Parameter Type' (in 2927 either an ERROR or in the INIT ACK). 2929 --------- 2930 New text: (Section 3.2.1) 2931 --------- 2933 00 - Stop processing this parameter, do not process 2934 any further parameters within this chunk. 2936 01 - Stop processing this parameter, do not process 2937 any further parameters within this chunk, and report the 2938 unrecognized parameter in an 'Unrecognized Parameter Type' as 2939 described in 3.2.2. 2941 10 - Skip this parameter and continue processing. 2943 11 - Skip this parameter and continue processing but report the 2944 unrecognized parameter in an 'Unrecognized Parameter Type' as 2945 described in 3.2.2. 2946 --------- 2947 New text: (Note no old text, clarification added in section 3.2) 2948 --------- 2950 3.2.2 Reporting of Unrecognized Parameters 2952 If the receiver of an INIT chunk detects unrecognized parameters 2953 and has to report them according to section 3.2.1 it MUST put 2954 the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk 2955 sent in response to the INIT-chunk. Note that if the receiver 2956 of the INIT chunk is NOT going to establish an association (e.g. 2957 due to lack of resources) an 'Unrecognized Parameters' would NOT 2958 be included with any ABORT being sent to the sender of the INIT. 2960 If the receiver of an INIT-ACK chunk detects unrecognized 2961 parameters and has to report them according to section 3.2.1 it 2962 SHOULD bundle the ERROR chunk containing the 'Unrecognized 2963 Parameters' error cause with the COOKIE-ECHO chunk sent in 2964 response to the INIT-ACK chunk. If the receiver of the 2965 INIT-ACK can not bundle the COOKIE-ECHO chunk with the ERROR 2966 chunk the ERROR chunk MAY be sent separately but not 2967 before the COOKIE-ACK has been received. 2969 Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the 2970 first chunk. 2972 2.33.3. Solution description 2974 The procedure of handling unrecognized parameters has been described 2975 clearly. 2977 2.34. Tie Tags 2979 2.34.1. Description of the problem 2981 RFC2960 requires Tie-Tags to be included in the COOKIE. The cookie 2982 may not be encrypted. An attacker could discover the value of the 2983 verification tags by analyzing cookies received after sending an 2984 INIT. 2986 2.34.2. Text changes to the document 2988 --------- 2989 Old text: (Section 1.4) 2990 --------- 2991 o Tie-Tags: Verification Tags from a previous association. These 2992 Tags are used within a State Cookie so that the newly 2993 restarting association can be linked to the original 2994 association within the endpoint that did not restart. 2996 --------- 2997 New text: (Section 1.4) 2998 --------- 3000 o Tie-Tags: Two 32 bit random numbers which together make a 64 3001 bit nonce. These Tags are used within a State Cookie and TCB 3002 so that a newly restarting association can be linked to the 3003 original association within the endpoint that did not restart 3004 and yet not reveal the true verification tags of an existing 3005 association. 3007 --------- 3008 Old text: (Section 5.2.1) 3009 --------- 3011 For an endpoint that is in the COOKIE-ECHOED state it MUST 3012 populate its Tie-Tags with the Tag information of itself and 3013 its peer (see section 5.2.2 for a description of the Tie-Tags). 3015 --------- 3016 New text: (Section 5.2.1) 3017 --------- 3018 For an endpoint that is in the COOKIE-ECHOED state it MUST 3019 populate its Tie-Tags within both the association TCB and 3020 populated inside the State Cookie (see section 5.2.2 for a 3021 description of the Tie-Tags). 3023 --------- 3024 Old text: (Section 5.2.2) 3025 --------- 3026 Unless otherwise stated, upon reception of an unexpected INIT for 3027 this association, the endpoint shall generate an INIT ACK with a 3028 State Cookie. In the outbound INIT ACK the endpoint MUST copy its 3029 current Verification Tag and peer's Verification Tag into a 3030 reserved place within the state cookie. We shall refer to these 3031 locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The 3032 outbound SCTP packet containing this INIT ACK MUST carry a 3033 Verification Tag value equal to the Initiation Tag found in the 3034 unexpected INIT. And the INIT ACK MUST contain a new Initiation 3035 Tag (randomly generated see Section 5.3.1). Other parameters 3036 for the endpoint SHOULD be copied from the existing parameters 3037 of the association (e.g. number of outbound streams) into the 3038 INIT ACK and cookie. 3040 --------- 3041 New text: (Section 5.2.2) 3042 --------- 3043 Unless otherwise stated, upon reception of an unexpected INIT for 3044 this association, the endpoint MUST generate an INIT ACK with a 3045 State Cookie. In the outbound INIT ACK the endpoint MUST copy its 3046 current Tie-Tags to a reserved place within the State Cookie and 3047 the association's TCB. We shall refer to these locations inside 3048 the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will 3049 refer to the copy within an association's TCB as the Local Tag 3050 and Peer's Tag. The outbound SCTP packet containing this 3051 INIT ACK MUST carry a Verification Tag value equal to the 3052 Initiation Tag found in the unexpected INIT. And the INIT ACK 3053 MUST contain a new Initiation Tag (randomly generated see 3054 Section 5.3.1). Other parameters for the endpoint SHOULD 3055 be copied from the existing parameters of the association 3056 (e.g. number of outbound streams) into the INIT ACK and cookie. 3058 2.34.3. Solution description 3060 The solution to this problem is not to use the real verification tags 3061 within the State Cookie as tie-tags. Instead two 32 bit random 3062 numbers are created to form one 64 bit nonces and stored both in the 3063 State Cookie and the existing association TCB. This prevents 3064 exposing the verification tags inadvertently. 3066 2.35. Port number verification in the COOKIE-ECHO 3068 2.35.1. Description of the problem 3070 The State Cookie sent by a listening SCTP endpoint may not contain 3071 the original port numbers or the local verification tag. It is then 3072 possible that the endpoint on reception of the COOKIE-ECHO will not 3073 be able to verify that these values match the original values found 3074 in the INIT and INIT-ACK that began the association setup. 3076 2.35.2. Text changes to the document 3078 --------- 3079 Old text: (Section 5.1.5) 3080 --------- 3081 3) Compare the creation timestamp in the State Cookie to the 3082 current local time. If the elapsed time is longer than the 3083 lifespan carried in the State Cookie, then the packet, 3084 including the COOKIE ECHO and any attached DATA chunks, 3085 SHOULD be discarded and the endpoint MUST transmit an ERROR 3086 chunk with a "Stale Cookie" error cause to the peer endpoint, 3088 4) If the State Cookie is valid, create an association to the 3089 sender of the COOKIE ECHO chunk with the information in the 3090 TCB data carried in the COOKIE ECHO, and enter the 3091 ESTABLISHED state, 3093 5) Send a COOKIE ACK chunk to the peer acknowledging reception 3094 of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an 3095 outbound DATA chunk or SACK chunk; however, the COOKIE ACK 3096 MUST be the first chunk in the SCTP packet. 3098 6) Immediately acknowledge any DATA chunk bundled with the COOKIE 3099 ECHO with a SACK (subsequent DATA chunk acknowledgement should 3100 follow the rules defined in Section 6.2). As mentioned in step 3101 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK 3102 MUST appear first in the SCTP packet. 3104 --------- 3105 New text: (Section 5.1.5) 3106 --------- 3108 3) Compare the port numbers and the verification tag contained 3109 within the COOKIE ECHO chunk to the actual port numbers and the 3110 verification tag within the SCTP common header of the received 3111 packet. If these values do not match the packet MUST be 3112 silently discarded, 3114 4) Compare the creation timestamp in the State Cookie to the 3115 current local time. If the elapsed time is longer than the 3116 lifespan carried in the State Cookie, then the packet, 3117 including the COOKIE ECHO and any attached DATA chunks, 3118 SHOULD be discarded and the endpoint MUST transmit an 3119 ERROR chunk with a "Stale Cookie" error cause to the peer 3120 endpoint, 3122 5) If the State Cookie is valid, create an association to the 3123 sender of the COOKIE ECHO chunk with the information in the 3124 TCB data carried in the COOKIE ECHO, and enter the 3125 ESTABLISHED state, 3127 6) Send a COOKIE ACK chunk to the peer acknowledging reception of 3128 the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound 3129 DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the 3130 first chunk in the SCTP packet. 3132 7) Immediately acknowledge any DATA chunk bundled with the COOKIE 3133 ECHO with a SACK (subsequent DATA chunk acknowledgement should 3134 follow the rules defined in Section 6.2). As mentioned in step 3135 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK 3136 MUST appear first in the SCTP packet. 3138 2.35.3. Solution description 3140 By including both port numbers and the local verification tag within 3141 the State Cookie and verifying these during COOKIE-ECHO processing 3142 this issue is resolved. 3144 2.36. Path Initialization 3146 2.36.1. Description of the problem 3148 When an association enters the ESTABLISHED state the endpoint has no 3149 verification that all of the addresses presented by the peer are in 3150 fact belonging to the peer. This could cause various forms of denial 3151 of service attacks. 3153 2.36.2. Text changes to the document 3155 --------- 3156 Old text: None 3157 --------- 3159 --------- 3160 New text: (Section 5.4) 3161 --------- 3162 5.4 Path Verification 3164 During association estabilishment the two peers 3165 exchange a list of addresses. In the predominant case 3166 these lists accurately represent the addresses owned 3167 by each peer. However there exists the possibility that 3168 a mis-behaving peer may supply addresses that it does 3169 not own. To prevent this the following rules are applied 3170 to all addresses of the new association: 3172 1) Any address passed to the sender of the INIT by its 3173 upper layer is automatically considered to be CONFIRMED. 3175 2) For the receiver of the COOKIE-ECHO the only CONFIRMED 3176 address is the one that the INIT-ACK was sent to. 3178 3) All other addresses not covered by rules 1 and 2 are considered 3179 UNCONFIRMED and are subject to probing for verification. 3181 To probe an address for verification, an endpoint will send 3182 HEARTBEAT's including a 64 bit random nonce and a path 3183 indicator (to identify the address that the HEARTBEAT 3184 is sent to) within the HEARTBEAT parameter. 3186 Upon reception of the HEARTBEAT-ACK a verification is 3187 made that the nonce included in the HEARTBEAT parameter 3188 is the one sent to the address indicated inside the 3189 HEARTBEAT parameter. When this match occurs, the address 3190 that the original HEARTBEAT was sent to is now considered 3191 CONFIRMED and available for normal data transfer. 3193 These probing proceedures are started when an association 3194 moves to the ESTABLISHED state and are ended when all 3195 paths are confirmed. 3197 Each RTO a probe may be sent on an active UNCONFIRMED path 3198 in an attempt to move it to to the CONFIRMED state. 3199 If during this probing the path becomes inactive this rate 3200 is lowered to the normal HEARTBEAT rate. At the expiration 3201 of the RTO timer the error counter of any path that was 3202 probed but not CONFIRMED is incremented by one and subjected 3203 to path failure detection defined in section 8.2. When probing 3204 UNCONFIRMED addresses, however, the association overall error count 3205 is NOT incremented. 3207 The number of HEARTBEATS sent at each RTO SHOULD be limited 3208 by the HB.Max.Burst parameter. It is an implementation decision 3209 as to how to distribute HEARTBEATS to the peers addresses 3210 for path verification. 3212 Whenever a path is confirmed an indication MAY be given to 3213 to the upper layer. 3215 An endpoint MUST NOT send any chunks to an UNCONFIRMED 3216 address with the following exceptions: 3218 - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED 3219 address. 3221 - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. 3223 - A COOKIE-ACK MAY be sent to an UNCONFIRMED address but 3224 it MUST be bundled with a HEARTBEAT including a nonce. 3225 An implementation that does NOT support bundling MUST 3226 NOT send a COOKIE-ACK to an UNCONFIRMED address. 3228 - A COOKE-ECHO MAY be sent to an UNCONFIRMED address but 3229 it MUST be bundled with a HEARTBEAT including a nonce 3230 and the packet MUST NOT exceed the path MTU. If the 3231 implementation does NOT support bundling or the bundled 3232 COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed 3233 the path MTU, then the implemenation MUST NOT send 3234 a COOKIE-ECHO to an UNCONFIRMED address. 3236 --------- 3237 Old text: (Section 14) 3238 --------- 3240 14. Suggested SCTP Protocol Parameter Values 3242 The following protocol parameters are RECOMMENDED: 3244 RTO.Initial - 3 seconds 3245 RTO.Min - 1 second 3246 RTO.Max - 60 seconds 3247 RTO.Alpha - 1/8 3248 RTO.Beta - 1/4 3249 Valid.Cookie.Life - 60 seconds 3250 Association.Max.Retrans - 10 attempts 3251 Path.Max.Retrans - 5 attempts (per destination address) 3252 Max.Init.Retransmits - 8 attempts 3253 HB.interval - 30 seconds 3255 --------- 3256 New text: (Section 14) 3257 --------- 3259 14. Suggested SCTP Protocol Parameter Values 3261 The following protocol parameters are RECOMMENDED: 3263 RTO.Initial - 3 seconds 3264 RTO.Min - 1 second 3265 RTO.Max - 60 seconds 3266 Max.Burst - 4 3267 RTO.Alpha - 1/8 3268 RTO.Beta - 1/4 3269 Valid.Cookie.Life - 60 seconds 3270 Association.Max.Retrans - 10 attempts 3271 Path.Max.Retrans - 5 attempts (per destination address) 3272 Max.Init.Retransmits - 8 attempts 3273 HB.Interval - 30 seconds 3274 HB.Max.Burst - 1 3276 2.36.3. Solution description 3278 By properly setting up initial path state and accelerated probing via 3279 HEARTBEAT's an new association can verify that all addresses 3280 presented by a peer belong to that peer. 3282 2.37. ICMP handling procedures 3284 2.37.1. Description of the problem 3286 RFC2960 does not describe how ICMP messages should be processed by an 3287 SCTP endpoint. 3289 2.37.2. Text changes to the document 3291 -------- 3292 Old text: None 3293 -------- 3294 --------- 3295 New text 3296 --------- 3298 11.5 Protection of non-SCTP capable hosts. 3300 To provide non-SCTP capable host with the same level of 3301 protection against attacks as SCTP capable ones all SCTP 3302 stacks MUST implement the ICMP handling described in Appendix C. 3304 When an SCTP stack receives a packet containing multiple 3305 control or DATA chunks and the processing of the packet 3306 requires the sending of multiple chunks in response, 3307 the sender of the response chunk('s) MUST NOT send 3308 more than one packet. If bundling is supported multiple 3309 response chunks that fit into a single packet MAY be 3310 bundled together into one single response packet. If bundling 3311 is not supported then the sender MUST NOT send more 3312 than one response chunk and MUST discard all other 3313 responses. Note that this rule does NOT apply to a 3314 SACK chunk since a SACK chunk is, in itself, a response 3315 to DATA and a SACK does not require a response of more DATA. 3317 An SCTP implementation SHOULD abort the association if 3318 it receives a SACK acknowledging a TSN which has not been sent. 3320 An SCTP implementation that receives an INIT that would 3321 require a large packet in response, due to the inclusion 3322 of multiple ERROR parameters, MAY (at its discrection) 3323 elect to omit some or all of the ERROR parameters 3324 to reduce the size of the INIT-ACK. Due to a combination 3325 of the size of the COOKIE parameter and the number 3326 of addresses a receiver of an INIT may be indicating 3327 to a peer, it is always possible that the INIT-ACK will 3328 be larger than the original INIT. An SCTP implementation 3329 SHOULD attempt to make the INIT-ACK as small as possible 3330 to reduce the possibility of byte amplification attacks. 3332 --------- 3333 Old text: None 3334 --------- 3336 --------- 3337 New text: (Appendix C) 3338 --------- 3340 Appendix C ICMP Handling 3341 Whenever an ICMP message is received by an SCTP endpoint the 3342 following procedures MUST be followed to assure proper 3343 utilization of the information being provided by layer 3. 3345 ICMP1) An implementation MAY ignore all ICMPv4 messages 3346 where the type field is not set to "Destination 3347 Unreachable". 3349 ICMP2) An implementation MAY ignore all ICMPv6 messages 3350 where the type field is not "Destination Unreachable, 3351 "Parameter Problem" or "Packet Too Big". 3353 ICMP3) An implementation MAY ignore any ICMPv4 messages 3354 where the code does not indicate "Protocol Unreachable" 3355 or "Fragmentation Needed". 3357 ICMP4) An implementation MAY ignore all ICMPv6 messages 3358 of type "Parameter Problem" if the code is not 3359 "Unrecognized next header type encountered". 3361 ICMP5) An implementation MUST use the payload of the 3362 ICMP message (V4 or V6) to locate the association 3363 which sent the message that ICMP is responding to. 3364 If the association cannot be found, An implementation SHOULD 3365 ignore the ICMP message. 3367 ICMP6) An implementation MUST validate that the verification tag 3368 contained in the ICMP message matches the verification 3369 tag of the peer. If the verification tag is not 0 and does 3370 NOT match, discard the ICMP message. If it is 0 and the 3371 ICMP message contains enough bytes to verify that the chunk 3372 type is an INIT chunk and that the initiate tag matches 3373 the tag of the peer continue with ICMP7. If the ICMP 3374 message is too short or, the chunk type or the 3375 initiate tag does not match, silently discard the packet. 3377 ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 3378 "Fragmentation Needed" an implemenation MAY process this 3379 information as defined for PATH MTU discovery. 3381 ICMP8) If the ICMP code is a "Unrecognized next header type 3382 encountered" or a "Protocol Unreachable" an implementation 3383 MUST treat this message as an abort with the T bit set 3384 if it does not contain an INIT chunk. If it does contain 3385 an INIT chunk and the association is in COOKIE-WAIT state, 3386 handle the ICMP message like an ABORT. 3388 ICMP9) If the ICMPv6 code is "Destination Unreachable" the 3389 implementation MAY mark the destination into the unreachable 3390 state or alternatively increment the path error counter. 3392 Note that these procedures differ with RFC1122 [1] and its 3393 requirements for processing of port unreachable messages and the 3394 requirements that an implemenation MUST abort associations in 3395 response to a "protocol unreachable" message. Port unreachable 3396 messages are not processed since an implementation will send an ABORT 3397 not a port unreachable. The stricter handling of the "protocol 3398 unreachable" message is due to security concerns for hosts that do 3399 NOT support SCTP. 3401 2.37.3. Solution description 3403 The new appendix now describes proper handling of ICMP messages in 3404 conjunction with SCTP. 3406 2.38. Checksum 3408 2.38.1. Description of the problem 3410 RFC3309 [8] changes the SCTP checksum due to weaknesses in the 3411 original Adler 32 checksum for small messages. This document, being 3412 used as a guide for a cut and paste replacement to update RFC2960, 3413 thus needs to also incorporate the checksum changes. The idea being 3414 that one could apply all changes found in this guide to a copy of 3415 RFC2960 and have a "new" document that has ALL changes (including 3416 RFC3309). 3418 2.38.2. Text changes to the document 3420 --------- 3421 Old text: 3422 --------- 3424 6.8 Adler-32 Checksum Calculation 3426 When sending an SCTP packet, the endpoint MUST strengthen the data 3427 integrity of the transmission by including the Adler-32 checksum 3428 value calculated on the packet, as described below. 3430 After the packet is constructed (containing the SCTP common header 3431 and one or more control or DATA chunks), the transmitter shall: 3433 1) Fill in the proper Verification Tag in the SCTP common header 3434 and initialize the checksum field to 0's. 3436 2) Calculate the Adler-32 checksum of the whole packet, including 3437 the SCTP common header and all the chunks. Refer to 3438 appendix B for details of the Adler-32 algorithm. And, 3440 3) Put the resultant value into the checksum field in the common 3441 header, and leave the rest of the bits unchanged. 3443 When an SCTP packet is received, the receiver MUST first check the 3444 Adler-32 checksum: 3446 1) Store the received Adler-32 checksum value aside, 3448 2) Replace the 32 bits of the checksum field in the received SCTP 3449 packet with all '0's and calculate an Adler-32 checksum value 3450 of the whole received packet. And, 3452 3) Verify that the calculated Adler-32 checksum is the same as the 3453 received Adler-32 checksum. If not, the receiver MUST treat 3454 the packet as an invalid SCTP packet. 3456 The default procedure for handling invalid SCTP packets is to 3457 silently discard them. 3459 --------- 3460 New text: 3461 --------- 3463 6.8 CRC-32c Checksum Calculation 3465 When sending an SCTP packet, the endpoint MUST strengthen the data 3466 integrity of the transmission by including the CRC32c checksum 3467 value calculated on the packet, as described below. 3469 After the packet is constructed (containing the SCTP common header 3470 and one or more control or DATA chunks), the transmitter MUST: 3472 1) Fill in the proper Verification Tag in the SCTP common header 3473 and initialize the checksum field to 0's. 3475 2) Calculate the CRC32c checksum of the whole packet, including 3476 the SCTP common header and all the chunks. Refer to 3477 appendix B for details of the CRC32c algorithm. And, 3479 3) Put the resultant value into the checksum field in the common 3480 header, and leave the rest of the bits unchanged. 3482 When an SCTP packet is received, the receiver MUST first check the 3483 CRC32c checksum: 3485 1) Store the received CRC32c checksum value aside, 3487 2) Replace the 32 bits of the checksum field in the received SCTP 3488 packet with all '0's and calculate a CRC32c checksum value of 3489 the whole received packet. And, 3491 3) Verify that the calculated CRC32c checksum is the same as the 3492 received CRC32c checksum. If not, the receiver MUST treat 3493 the packet as an invalid SCTP packet. 3495 The default procedure for handling invalid SCTP packets is to 3496 silently discard them. 3498 Any hardware implementation SHOULD be done in a way that is 3499 verifiable by the software. 3501 --------- 3502 Old text: 3503 --------- 3505 Appendix B Alder 32 bit checksum calculation 3507 The Adler-32 checksum calculation given in this appendix is 3508 copied from [RFC1950]. 3510 Adler-32 is composed of two sums accumulated per byte: s1 is the 3511 sum of all bytes, s2 is the sum of all s1 values. Both sums are 3512 done modulo 65521. s1 is initialized to 1, s2 to zero. The 3513 Adler-32 checksum is stored as s2*65536 + s1 in network byte 3514 order. 3516 The following C code computes the Adler-32 checksum of a data 3517 buffer. It is written for clarity, not for speed. The sample 3518 code is in the ANSI C programming language. Non C users may 3519 find it easier to read with these hints: 3521 & Bitwise AND operator. 3522 >> Bitwise right shift operator. When applied to an 3523 unsigned quantity, as here, right shift inserts zero bit(s) 3524 at the left. 3525 << Bitwise left shift operator. Left shift inserts zero 3526 bit(s) at the right. 3527 ++ "n++" increments the variable n. 3528 % modulo operator: a % b is the remainder of a divided by b. 3529 #define BASE 65521 /* largest prime smaller than 65536 */ 3530 /* 3531 Update a running Adler-32 checksum with the bytes buf[0..len-1] 3532 and return the updated checksum. The Adler-32 checksum should 3533 be initialized to 1. 3535 Usage example: 3537 unsigned long adler = 1L; 3539 while (read_buffer(buffer, length) != EOF) { 3540 adler = update_adler32(adler, buffer, length); 3541 } 3542 if (adler != original_adler) error(); 3543 */ 3544 unsigned long update_adler32(unsigned long adler, 3545 unsigned char *buf, int len) 3546 { 3547 unsigned long s1 = adler & 0xffff; 3548 unsigned long s2 = (adler >> 16) & 0xffff; 3549 int n; 3551 for (n = 0; n < len; n++) { 3552 s1 = (s1 + buf[n]) % BASE; 3553 s2 = (s2 + s1) % BASE; 3554 } 3555 return (s2 << 16) + s1; 3556 } 3558 /* Return the adler32 of the bytes buf[0..len-1] */ 3559 unsigned long adler32(unsigned char *buf, int len) 3560 { 3561 return update_adler32(1L, buf, len); 3562 } 3564 --------- 3565 New text: 3566 --------- 3567 Appendix B CRC32c checksum calculation 3569 We define a 'reflected value' as one that is the opposite of the 3570 normal bit order of the machine. The 32 bit CRC is calculated as 3571 described for CRC-32c and uses the polynomial code 0x11EDC6F41 3572 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 3573 +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. 3574 The CRC is computed using a procedure similar to ETHERNET CRC 3575 [ITU32], modified to reflect transport level usage. 3576 CRC computation uses polynomial division. A message 3577 bit-string M is transformed to a polynomial, M(X), and the CRC 3578 is calculated from M(X) using polynomial arithmetic [PETERSON 72]. 3580 When CRCs are used at the link layer, the polynomial is derived 3581 from on-the-wire bit ordering: the first bit 'on the wire' is the 3582 high-order coefficient. Since SCTP is a transport-level protocol, 3583 it cannot know the actual serial-media bit ordering. Moreover, 3584 different links in the path between SCTP endpoints may use 3585 different link-level bit orders. 3587 A convention must therefore be established for mapping SCTP 3588 transport messages to polynomials for purposes of CRC computation. 3589 The bit-ordering for mapping SCTP messages to polynomials is that 3590 bytes are taken most-significant first; but within each byte, bits 3591 are taken least-significant first. The first byte of the message 3592 provides the eight highest coefficients. Within each byte, 3593 the least-significant SCTP bit gives the most significant 3594 polynomial coefficient within that byte, and the most-significant 3595 SCTP bit is the least significant polynomial coefficient in that 3596 byte. (This bit ordering is sometimes called 'mirrored' or 3597 'reflected' [WILLIAMS93].) CRC polynomials are to be transformed 3598 back into SCTP transport-level byte values, using a consistent 3599 mapping. 3601 The SCTP transport-level CRC value should be calculated as 3602 follows: 3604 - CRC input data are assigned to a byte stream, numbered from 3605 0 to N-1. 3607 - the transport-level byte-stream is mapped to a polynomial 3608 value. An N-byte PDU with j bytes numbered 0 to N-1, is 3609 considered as coefficients of a polynomial M(x) of order 3610 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8), 3611 bit 7 of byte j being coefficient x^(8(N-j)-1). 3613 - the CRC remainder register is initialized with all 1s and 3614 the CRC is computed with an algorithm that simultaneously 3615 multiplies by x^32 and divides by the CRC polynomial. 3617 - the polynomial is multiplied by x^32 and divided by G(x), 3618 the generator polynomial, producing a remainder R(x) of 3619 degree less than or equal to 31. 3621 - the coefficients of R(x) are considered a 32 bit sequence. 3623 - the bit sequence is complemented. The result is the CRC 3624 polynomial. 3626 - The CRC polynomial is mapped back into SCTP transport-level 3627 bytes. Coefficient of x^31 gives the value of bit 7 of 3628 SCTP byte 0, the coefficient of x^24 gives the value of 3629 bit 0 of byte 0. The coefficient of x^7 gives bit 7 of 3630 byte 3 and the coefficient of x^0 gives bit 0 of byte 3. 3631 The resulting four-byte transport-level sequence is the 3632 32-bit SCTP checksum value. 3634 IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor 3635 literature on CRCs often follow an alternative formulation, in 3636 which the register used to hold the remainder of the 3637 long-division algorithm is initialized to zero rather than 3638 all-1s, and instead the first 32 bits of the message are 3639 complemented. The long-division algorithm used in our 3640 formulation is specified, such that the the initial 3641 multiplication by 2^32 and the long-division are combined into 3642 one simultaneous operation. For such algorithms, and for 3643 messages longer than 64 bits, the two specifications are 3644 precisely equivalent. That equivalence is the intent of 3645 this document. 3647 Implementors of SCTP are warned that both specifications are to be 3648 found in the literature, sometimes with no restriction on the 3649 long-division algorithm. The choice of formulation in this 3650 document is to permit non-SCTP usage, where the same CRC 3651 algorithm may be used to protect messages shorter than 64 bits. 3653 There may be a computational advantage in validating the 3654 Association against the Verification Tag, prior to performing a 3655 checksum, as invalid tags will result in the same action as a bad 3656 checksum in most cases. The exceptions for this technique would 3657 be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale 3658 COOKIE-ECHO. These special case exchanges must represent small 3659 packets and will minimize the effect of the checksum calculation. 3661 --------- 3662 Old text: (Section 18) 3663 --------- 3664 18. Bibliography 3666 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 3667 Network Path Properties", Proc. SIGCOMM'99, 1999. 3669 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of 3670 Tahoe, Reno, and SACK TCP, Computer Communications Review, 3671 V. 26 N. 3, July 1996, pp. 5-21. 3673 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 3674 Security", RFC 1750, December 1994. 3676 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format 3677 Specification version 3.3", RFC 1950, May 1996. 3679 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 3680 Hashing for Message Authentication", RFC 2104, March 1997. 3682 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 3683 September 1997. 3685 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 3686 Protocol", RFC 2522, March 1999. 3688 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 3689 "TCP Congestion Control with a Misbehaving Receiver", ACM 3690 Computer Communication Review, 29(5), October 1999. 3692 --------- 3693 New text: (Section 18, including changes from 2.11) 3694 --------- 3696 18. Bibliography 3698 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 3699 Network Path Properties", Proc. SIGCOMM'99, 1999. 3701 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of 3702 Tahoe, Reno, and SACK TCP, Computer Communications Review, 3703 V. 26 N. 3, July 1996, pp. 5-21. 3705 [ITU32] ITU-T Recommendation V.42, "Error-correcting 3706 procedures for DCEs using asynchronous-to-synchronous 3707 conversion", section 8.1.1.6.2, October 1996. 3709 [PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting 3710 Codes, 2nd. edition, MIT Press, Cambridge, 3711 Massachusetts. 3713 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 3714 Security", RFC 1750, December 1994. 3716 [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security 3717 Considerations for IP Fragment Filtering", RFC 1858, 3718 October 1995. 3720 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format 3721 Specification version 3.3", RFC 1950, May 1996. 3723 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 3724 Hashing for Message Authentication", RFC 2104, March 1997. 3726 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 3727 September 1997. 3729 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 3730 Protocol", RFC 2522, March 1999. 3732 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 3733 "TCP Congestion Control with a Misbehaving Receiver", ACM 3734 Computer Communication Review, 29(5), October 1999. 3736 [WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR 3737 DETECTION ALGORITHMS" - Internet publication, August 3738 1993, 3739 http://www.geocities.com/SiliconValley/Pines/ 3740 8659/crc.htm. 3742 2.38.3. Solution description 3744 This change adds the implementors guide the complete set of changes 3745 that when combined with RFC2960 [7] encompasses the changes from 3746 RFC3309 [8]. 3748 2.39. Retransmission Policy 3750 2.39.1. Description of the problem 3752 The current retransmission policy (send all retransmissions an 3753 alternate destination) in the specification has performance issues 3754 under certain loss conditions with multihomed endpoints. Instead, 3755 fast retransmissions should be sent to the same destination, and only 3756 timeout retransmissions should be sent to an alternate destination 3757 [5]. 3759 2.39.2. Text changes to the document 3761 --------- 3762 Old text: (Section 6.4) 3763 --------- 3765 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 3766 retransmit a chunk to an active destination transport address that is 3767 different from the last destination address to which the DATA chunk 3768 was sent. 3770 --------- 3771 New text: (Section 6.4) 3772 --------- 3774 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 3775 retransmit a chunk that timed out to an active destination transport 3776 address that is different from the last destination address to which 3777 the DATA chunk was sent. 3779 --------- 3780 Old text: (Section 6.4.1) 3781 --------- 3783 When retransmitting data, if the endpoint is multi-homed, it should 3784 consider each source-destination address pair in its retransmission 3785 selection policy. When retransmitting the endpoint should attempt to 3786 pick the most divergent source-destination pair from the original 3787 source-destination pair to which the packet was transmitted. 3789 --------- 3790 New text: (Section 6.4.1) 3791 --------- 3793 When retransmitting data that timed out, if the endpoint is 3794 multi-homed, it should consider each source-destination address 3795 pair in its retransmission selection policy. When retransmitting 3796 timed out data, the endpoint should attempt to pick the most 3797 divergent source-destination pair from the original 3798 source-destination pair to which the packet was transmitted. 3800 2.39.3. Solution description 3802 The above wording changes clarifies that only timeout retransmissions 3803 should be sent to an alternate active destination. 3805 2.40. Port Number 0 3807 2.40.1. Description of the problem 3809 The port number 0 has a special semantic in various APIs. For 3810 example in the socket API, if the user specifies 0, the SCTP 3811 implementation choses an appropriate port number for the user. 3812 Therefore the port number 0 should not be used on the wire. 3814 2.40.2. Text changes to the document 3816 --------- 3817 Old text: (Section 3.1) 3818 --------- 3820 Source Port Number: 16 bits (unsigned integer) 3822 This is the SCTP sender's port number. It can be used by the 3823 receiver in combination with the source IP address, the SCTP 3824 destination port and possibly the destination IP address to 3825 identify the association to which this packet belongs. 3827 Destination Port Number: 16 bits (unsigned integer) 3829 This is the SCTP port number to which this packet is destined. 3830 The receiving host will use this port number to de-multiplex 3831 the SCTP packet to the correct receiving endpoint/application. 3833 --------- 3834 New text: (Section 3.1) 3835 --------- 3837 Source Port Number: 16 bits (unsigned integer) 3839 This is the SCTP sender's port number. It can be used by the 3840 receiver in combination with the source IP address, the SCTP 3841 destination port and possibly the destination IP address to 3842 identify the association to which this packet belongs. 3843 The port number 0 MUST NOT be used. 3845 Destination Port Number: 16 bits (unsigned integer) 3847 This is the SCTP port number to which this packet is destined. 3848 The receiving host will use this port number to de-multiplex 3849 the SCTP packet to the correct receiving endpoint/application. 3850 The port number 0 MUST NOT be used. 3852 2.40.3. Solution description 3854 It is clearly stated that the port number 0 is an invalid value on 3855 the wire. 3857 2.41. T Bit 3859 2.41.1. Description of the problem 3861 The description of the T bit as the bit describing whether a TCB has 3862 been destroyed or not is misleading. In addition, the procedure 3863 described in Section 2.13 is not as precise as needed. 3865 2.41.2. Text changes to the document 3867 --------- 3868 Old text: (Section 3.3.7) 3869 --------- 3871 T bit: 1 bit 3872 The T bit is set to 0 if the sender had a TCB that it 3873 destroyed. If the sender did not have a TCB it should set 3874 this bit to 1. 3876 --------- 3877 New text: (Section 3.3.7) 3878 --------- 3880 T bit: 1 bit 3881 The T bit is set to 0 if the sender filled in the 3882 Verification Tag expected by the peer. If the Verification 3883 Tag is reflected the T bit MUST be set to 1. Reflecting means 3884 that the sent Verification Tag is the same as the received 3885 one. 3887 --------- 3888 Old text: (Section 3.3.13) 3889 --------- 3891 T bit: 1 bit 3892 The T bit is set to 0 if the sender had a TCB that it 3893 destroyed. If the sender did not have a TCB it should set 3894 this bit to 1. 3896 --------- 3897 New text: (Section 3.3.13) 3898 --------- 3900 T bit: 1 bit 3901 The T bit is set to 0 if the sender filled in the 3902 Verification Tag expected by the peer. If the Verification 3903 Tag is reflected the T bit MUST be set to 1. Reflecting means 3904 that the sent Verification Tag is the same as the received 3905 one. 3907 --------- 3908 Old text: (Section 8.4) 3909 --------- 3911 3) If the packet contains an INIT chunk with a Verification Tag 3912 set to '0', process it as described in Section 5.1. 3913 Otherwise, 3915 --------- 3916 New text: (Section 8.4) 3917 --------- 3918 3) If the packet contains an INIT chunk with a Verification Tag 3919 set to '0', process it as described in Section 5.1. If, for 3920 whatever reason, the INIT can not be processed normally and 3921 an ABORT has to be sent in response, the Verification Tag of 3922 the packet containing the ABORT chunk MUST be the Initiate 3923 tag of the received INIT chunk and the T-Bit of the ABORT 3924 chunk has to be set to 0 indicating that the Verification 3925 Tag is NOT reflected. 3927 --------- 3928 Old text: (Section 8.4) 3929 --------- 3930 5) If the packet contains a SHUTDOWN ACK chunk, the receiver 3931 should respond to the sender of the OOTB packet with a 3932 SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the 3933 receiver of the OOTB packet must fill in the Verification 3934 Tag field of the outbound packet with the Verification Tag 3935 received in the SHUTDOWN ACK and set the T-bit in the Chunk 3936 Flags to indicate that no TCB was found. Otherwise, 3937 --------- 3938 New text: (Section 8.4) 3939 --------- 3941 5) If the packet contains a SHUTDOWN ACK chunk, the receiver 3942 should respond to the sender of the OOTB packet with a 3943 SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the 3944 receiver of the OOTB packet must fill in the Verification 3945 Tag field of the outbound packet with the Verification Tag 3946 received in the SHUTDOWN ACK and set the T-bit in the 3947 Chunk Flags to indicate that the Verification Tag is 3948 reflected. Otherwise, 3949 --------- 3950 Old text: (Section 8.4) 3951 --------- 3953 8) The receiver should respond to the sender of the OOTB packet 3954 with an ABORT. When sending the ABORT, the receiver of the 3955 OOTB packet MUST fill in the Verification Tag field of the 3956 outbound packet with the value found in the Verification 3957 Tag field of the OOTB packet and set the T-bit in the Chunk 3958 Flags to indicate that no TCB was found. After sending this 3959 ABORT, the receiver of the OOTB packet shall discard the 3960 OOTB packet and take no further action. 3962 --------- 3963 New text: (Section 8.4) 3964 --------- 3966 8) The receiver should respond to the sender of the OOTB packet 3967 with an ABORT. When sending the ABORT, the receiver of the 3968 OOTB packet MUST fill in the Verification Tag field of the 3969 outbound packet with the value found in the Verification Tag 3970 field of the OOTB packet and set the T-bit in the Chunk Flags 3971 to indicate that the Verification Tag is reflected. After 3972 sending this ABORT, the receiver of the OOTB packet shall 3973 discard the OOTB packet and take no further action. 3975 --------- 3976 Old text: (Section 8.5.1) 3977 --------- 3979 B) Rules for packet carrying ABORT: 3981 - The endpoint shall always fill in the Verification Tag 3982 field of the outbound packet with the destination 3983 endpoint's tag value if it is known. 3985 - If the ABORT is sent in response to an OOTB packet, the 3986 endpoint MUST follow the procedure described in 3987 Section 8.4. 3989 - The receiver MUST accept the packet if the Verification 3990 Tag matches either its own tag, OR the tag of its peer. 3991 Otherwise, the receiver MUST silently discard the packet 3992 and take no further action. 3994 --------- 3995 New text: (Section 8.5.1) 3996 --------- 3998 B) Rules for packet carrying ABORT: 4000 - The endpoint MUST always fill in the Verification Tag 4001 field of the outbound packet with the destination 4002 endpoint's tag value if it is known. 4004 - If the ABORT is sent in response to an OOTB packet, the 4005 endpoint MUST follow the procedure described in 4006 Section 8.4. 4008 - The receiver of an ABORT MUST accept the packet 4009 if the Verification Tag field of the packet matches its 4010 own tag and the T bit is not set 4011 OR 4012 it is set to its peer's tag and the T bit is set in 4013 the Chunk Flags. 4014 Otherwise, the receiver MUST silently discard the packet 4015 and take no further action. 4016 --------- 4017 Old text: (Section 8.5.1) 4018 --------- 4020 C) Rules for packet carrying SHUTDOWN COMPLETE: 4022 - When sending a SHUTDOWN COMPLETE, if the receiver of the 4023 SHUTDOWN ACK has a TCB then the destination endpoint's 4024 tag MUST be used. Only where no TCB exists should the 4025 sender use the Verification Tag from the SHUTDOWN ACK. 4027 - The receiver of a SHUTDOWN COMPLETE shall accept the 4028 packet if the Verification Tag field of the packet matches 4029 its own tag OR it is set to its peer's tag and the T bit 4030 is set in the Chunk Flags. Otherwise, the receiver MUST 4031 silently discard the packet and take no further action. 4032 An endpoint MUST ignore the SHUTDOWN COMPLETE if it is 4033 not in the SHUTDOWN-ACK-SENT state. 4035 --------- 4036 New text: (Section 8.5.1) 4037 --------- 4039 C) Rules for packet carrying SHUTDOWN COMPLETE: 4041 - When sending a SHUTDOWN COMPLETE, if the receiver of the 4042 SHUTDOWN ACK has a TCB then the destination endpoint's tag 4043 MUST be used and the T-bit MUST NOT be set. Only where no 4044 TCB exists should the sender use the Verification Tag from 4045 the SHUTDOWN ACK and MUST set the T-bit. 4047 - The receiver of a SHUTDOWN COMPLETE shall accept the packet 4048 if the Verification Tag field of the packet matches its own 4049 tag and the T bit is not set 4050 OR 4051 it is set to its peer's tag and the T bit is set in the 4052 Chunk Flags. 4053 Otherwise, the receiver MUST silently discard the packet 4054 and take no further action. An endpoint MUST ignore the 4055 SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT 4056 state. 4058 2.41.3. Solution description 4060 The description of the T bit now clearly describes the semantic of 4061 the bit. The procedures for the reception of the T bit have been 4062 clarified. 4064 2.42. Unknown Parameter Handling 4066 2.42.1. Description of the problem 4068 The description given in Section 2.33 does not state clearly if an 4069 INIT-ACK or COOKIE-ECHO is sent. 4071 2.42.2. Text changes to the document 4073 The changes given here already include changes suggested in sections 4074 Section 2.2, Section 2.27, and Section 2.33 of this document. 4076 --------- 4077 Old text: (Section 3.2.1) 4078 --------- 4080 00 - Stop processing this SCTP packet and discard it, do not process 4081 any further chunks within it. 4083 01 - Stop processing this SCTP packet and discard it, do not process 4084 any further chunks within it, and report the unrecognized 4085 parameter in an 'Unrecognized Parameter Type' (in either an 4086 ERROR or in the INIT ACK). 4088 10 - Skip this parameter and continue processing. 4090 11 - Skip this parameter and continue processing but report the 4091 unrecognized parameter in an 'Unrecognized Parameter Type' (in 4092 either an ERROR or in the INIT ACK). 4094 --------- 4095 New text: (Section 3.2.1) 4096 --------- 4098 00 - Stop processing this parameter, do not process 4099 any further parameters within this chunk. 4101 01 - Stop processing this parameter, do not process 4102 any further parameters within this chunk, and report the 4103 unrecognized parameter in an 'Unrecognized Parameter Type' as 4104 described in 3.2.2. 4106 10 - Skip this parameter and continue processing. 4108 11 - Skip this parameter and continue processing but report the 4109 unrecognized parameter in an 'Unrecognized Parameter Type' as 4110 described in 3.2.2. 4112 Please note, that in all four cases an INIT-ACK or COOKIE-ECHO 4113 chunk is sent. In the 00 or 01 case the processing of the 4114 parameters after the unknown parameter is canceled, but no 4115 processing already done is rolled back. 4117 --------- 4118 New text: (Note no old text, clarification added in section 3.2) 4119 --------- 4121 3.2.2 Reporting of Unrecognized Parameters 4123 If the receiver of an INIT chunk detects unrecognized parameters 4124 and has to report them according to section 3.2.1 it MUST put 4125 the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk 4126 sent in response to the INIT-chunk. Note that if the receiver 4127 of the INIT chunk is NOT going to establish an association (e.g. 4128 due to lack of resources) an 'Unrecognized Parameters' would NOT 4129 be included with any ABORT being sent to the sender of the INIT. 4131 If the receiver of an INIT-ACK chunk detects unrecognized 4132 parameters and has to report them according to section 3.2.1 it 4133 SHOULD bundle the ERROR chunk containing the 'Unrecognized 4134 Parameters' error cause with the COOKIE-ECHO chunk sent in 4135 response to the INIT-ACK chunk. If the receiver of the INIT-ACK 4136 can not bundle the COOKIE-ECHO chunk with the ERROR chunk the 4137 ERROR chunk MAY be sent separately but not before the COOKIE-ACK 4138 has been received. 4140 Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the 4141 first chunk. 4143 2.42.3. Solution description 4145 The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be 4146 sent. 4148 2.43. Cookie Echo Chunk 4150 2.43.1. Description of the problem 4152 The description given in section 3.3.11 of RFC2960 [7] is unclear as 4153 to how the COOKIE-ECHO is composed. 4155 2.43.2. Text changes to the document 4156 --------- 4157 Old text: (Section 3.3.11) 4158 --------- 4159 Cookie: variable size 4161 This field must contain the exact cookie received in the State 4162 Cookie parameter from the previous INIT ACK. 4164 An implementation SHOULD make the cookie as small as possible 4165 to insure interoperability. 4167 --------- 4168 New text: (Section 3.3.11) 4169 --------- 4170 Cookie: variable size 4172 This field must contain the exact cookie received in the State 4173 Cookie parameter from the previous INIT ACK. 4175 An implementation SHOULD make the cookie as small as possible 4176 to ensure interoperability. 4178 Note: A Cookie Echo does NOT contain a State Cookie 4179 Parameter, instead the data within the State Cookie's 4180 Parameter Value becomes the data within the Cookie Echo's 4181 Chunk Value. This allows an implementation to only change 4182 the first two bytes of the State Cookie parameter to become 4183 a Cookie Echo Chunk. 4185 2.43.3. Solution description 4187 The new text adds a note that helps clarify that a Cookie Echo chunk 4188 is nothing more than the State Cookie parameter with only two bytes 4189 modified. 4191 2.44. Partial Chunks 4193 2.44.1. Description of the problem 4195 Section 6.10 of RFC2960 [7] uses the notion of 'partial chunks' 4196 without defining it. 4198 2.44.2. Text changes to the document 4199 --------- 4200 Old text: (Section 6.10) 4201 --------- 4202 Partial chunks MUST NOT be placed in an SCTP packet. 4204 --------- 4205 New text: (Section 6.10) 4206 --------- 4207 Partial chunks MUST NOT be placed in an SCTP packet. A partial 4208 chunk is a chunk which is not completely contained in the SCTP 4209 packet, i.e. the SCTP packet is too short to contain all the bytes 4210 of the chunk as indicated by the chunk length. 4212 2.44.3. Solution description 4214 The new text adds a definition of 'partial chunks'. 4216 2.45. Non-unicast addresses 4218 2.45.1. Description of the problem 4220 Section 8.4 of RFC2960 [7] forces the OOTB handling to discard all 4221 non-unicast addresses. This MUST, leaves future use of any-cast 4222 addresses in question. With the addition of the add-ip feature SCTP 4223 should be able to easily handle any-cast INIT's that can be followed, 4224 after association setup, with a delete of the any-cast address from 4225 the association. 4227 2.45.2. Text changes to the document 4228 --------- 4229 Old text: (Section 8.4) 4230 --------- 4231 8.4 Handle "Out of the blue" Packets 4233 An SCTP packet is called an "out of the blue" (OOTB) packet if 4234 it is correctly formed, i.e., passed the receiver's Adler-32 4235 check (see Section 6.8), but the receiver is not able to 4236 identify the association to which this packet belongs. 4238 The receiver of an OOTB packet MUST do the following: 4240 1) If the OOTB packet is to or from a non-unicast address, 4241 silently discard the packet. Otherwise, 4243 --------- 4244 New text: (Section 8.4) 4245 --------- 4246 8.4 Handle "Out of the blue" Packets 4248 An SCTP packet is called an "out of the blue" (OOTB) packet if 4249 it is correctly formed, i.e., passed the receiver's Adler-32 check 4250 (see Section 6.8), but the receiver is not able to identify the 4251 association to which this packet belongs. 4253 The receiver of an OOTB packet MUST do the following: 4255 1) If the OOTB packet is to or from a non-unicast address, a 4256 receiver SHOULD silently discard the packet. Otherwise, 4258 2.45.3. Solution description 4260 The loosening of the wording to a SHOULD will now allow future use of 4261 anycast addresses. Note that no changes is made to section 11.2.4.1 4262 since responding to broadcast addresses could lead to flooding 4263 attacks and implementors should pay careful attention to these words. 4265 2.46. Processing of ABORT chunks 4267 2.46.1. Description of the problem 4269 Section 3.3.7 of RFC2960 [7] requires an SCTP endpoint to silently 4270 discard ABORT chunks received for associations that do not exist. It 4271 is not clear what this means in the COOKIE-WAIT state, for example. 4272 Therefore it was not clear if an ABORT sent in response to an INIT 4273 should be processed or silently discarded. 4275 2.46.2. Text changes to the document 4277 --------- 4278 Old text: (Section 3.3.7) 4279 --------- 4280 If an endpoint receives an ABORT with a format error or for an 4281 association that doesn't exist, it MUST silently discard it. 4283 --------- 4284 New text: (Section 3.3.7) 4285 --------- 4286 If an endpoint receives an ABORT with a format error or no 4287 TCB is found, it MUST silently discard it. 4289 2.46.3. Solution description 4291 It is now clearly stated that an ABORT chunk should be processed 4292 whenever a TCB is found. 4294 2.47. Sending of ABORT chunks 4296 2.47.1. Description of the problem 4298 Section 5.1 of RFC2960 [7] requires that an ABORT chunk is sent in 4299 response to an INIT chunk when there is no listening end point. To 4300 make port scanning harder someone might not want these ABORTs to be 4301 received by the sender of the INIT chunks. Currently the only way to 4302 enforce this is by using a firewall discarding the packets containing 4303 the INIT chunks or the packets containing the ABORT chunks. It is 4304 desirable that the same can be done without a middle box. 4306 2.47.2. Text changes to the document 4307 --------- 4308 Old text: (Section 5.1) 4309 --------- 4310 If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk 4311 but decides not to establish the new association due to missing 4312 mandatory parameters in the received INIT or INIT ACK, invalid 4313 parameter values, or lack of local resources, it MUST respond with 4314 an ABORT chunk. 4316 --------- 4317 New text: (Section 5.1) 4318 --------- 4320 If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk 4321 but decides not to establish the new association due to missing 4322 mandatory parameters in the received INIT or INIT ACK, invalid 4323 parameter values, or lack of local resources, it SHOULD respond 4324 with an ABORT chunk. 4326 2.47.3. Solution description 4328 The requirement of sending ABORT chunks is relaxed such that an 4329 implementation can decide not to send ABORT chunks. 4331 2.48. Handling of Supported Address Types parameter 4333 2.48.1. Description of the problem 4335 The sender of the INIT chunk can include a 'Supported Address Types' 4336 parameter to indicate which address families are supported. It is 4337 unclear how an INIT chunk should be processed where the source 4338 address of the packet containing the INIT chunk or listed addresses 4339 within the INIT chunk indicate that more address types are supported 4340 than listed in the 'Supported Address Types' parameter. 4342 2.48.2. Text changes to the document 4344 The changes given here already include changes suggested in 4345 Section 2.28 of this document. 4347 --------- 4348 Old text: (Section 5.1.2) 4349 --------- 4350 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK 4351 fails to resolve the address parameter due to an unsupported type, 4352 it can abort the initiation process and then attempt a 4353 re-initiation by using a 'Supported Address Types' parameter in 4354 the new INIT to indicate what types of address it prefers. 4356 --------- 4357 New text: (Section 5.1.2) 4358 --------- 4359 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK 4360 fails to resolve the address parameter due to an unsupported type, 4361 it can abort the initiation process and then attempt a 4362 re-initiation by using a 'Supported Address Types' parameter in 4363 the new INIT to indicate what types of address it prefers. 4365 IMPLEMENTATION NOTE: If an SCTP endpoint only supporting either 4366 IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or 4367 INIT-ACK chunk from its peer it MUST use all of the addresses 4368 belonging to the supported address family. The other addresses 4369 MAY be ignored. The endpoint SHOULD NOT respond with any kind of 4370 error indication. 4372 IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported 4373 Address Types' parameter only either IPv4 or IPv6 but uses the 4374 other family for sending the packet containing the INIT chunk or 4375 lists also addresses of the other family in the INIT chunk, then 4376 the address family which is not listed in the 'Supported Address 4377 Types' parameter SHOULD also be considered as supported by the 4378 receiver of the INIT chunk. The receiver of the INIT chunk 4379 SHOULD NOT respond with any kind of error indication. 4381 2.48.3. Solution description 4383 It is now clearly described how these Supported Address Types 4384 parameters with incorrect data should be handled. 4386 2.49. Handling of unexpected parameters 4388 2.49.1. Description of the problem 4390 RFC2960 [7] clearly describes how unknown parameters in the INIT and 4391 INIT-ACK chunk should be processed. But it is not described how 4392 unexpected parameters should be processed. A parameter is unexpected 4393 if it is known and an optional parameter in either the INIT or INIT- 4394 ACK chunk but received in the chunk for which it is not an optional 4395 parameter. For exmaple, the 'Supported Address Types' parameter 4396 would be an unexpected parameter if contained in an INIT-ACK chunk. 4398 2.49.2. Text changes to the document 4400 --------- 4401 Old text: (Section 3.3.2) 4402 --------- 4403 Note 4: This parameter, when present, specifies all the address 4404 types the sending endpoint can support. The absence of this 4405 parameter indicates that the sending endpoint can support any 4406 address type. 4408 --------- 4409 New text: (Section 3.3.2) 4410 --------- 4412 Note 4: This parameter, when present, specifies all the address 4413 types the sending endpoint can support. The absence of this 4414 parameter indicates that the sending endpoint can support any 4415 address type. 4417 IMPLEMENTATION NOTE: If an INIT chunk is received with known 4418 parameters which are not optional parameters of the INIT chunk 4419 then the receiver SHOULD process the INIT chunk and send back 4420 an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR 4421 chunk with the COOKIE-ACK chunk later. However, restrictive 4422 implementations MAY send back an ABORT chunk in response to 4423 the INIT chunk. 4425 --------- 4426 Old text: (Section 3.3.3) 4427 --------- 4429 IMPLEMENTATION NOTE: An implementation MUST be prepared to receive 4430 a INIT ACK that is quite large (more than 1500 bytes) due to the 4431 variable size of the state cookie AND the variable address list. 4432 For example if a responder to the INIT has 1000 IPv4 addresses 4433 it wishes to send, it would need at least 8,000 bytes to encode 4434 this in the INIT ACK. 4436 --------- 4437 New text: (Section 3.3.3) 4438 --------- 4439 IMPLEMENTATION NOTE: An implementation MUST be prepared to receive 4440 a INIT ACK that is quite large (more than 1500 bytes) due to the 4441 variable size of the state cookie AND the variable address list. 4442 For example if a responder to the INIT has 1000 IPv4 addresses 4443 it wishes to send, it would need at least 8,000 bytes to encode 4444 this in the INIT ACK. 4446 IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known 4447 parameters which are not optional parameters of the INIT-ACK 4448 chunk then the receiver SHOULD process the INIT-ACK chunk and 4449 send back an COOKIE-ECHO. The receiver of the INIT-ACK chunk 4450 MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. However, 4451 restrictive implementations MAY send back an ABORT chunk in 4452 response to the INIT-ACK chunk. 4454 2.49.3. Solution description 4456 It is now stated how unexpected parameters should be processed. 4458 2.50. Payload Protocol Identifier 4460 2.50.1. Description of the problem 4462 The current description of the payload protocol identifier does NOT 4463 highlight the fact that the field is NOT necessarily in network byte 4464 order. 4466 2.50.2. Text changes to the document 4467 --------- 4468 Old text: (Section 3.3.1) 4469 --------- 4470 Payload Protocol Identifier: 32 bits (unsigned integer) 4472 This value represents an application (or upper layer) specified 4473 protocol identifier. This value is passed to SCTP by its upper 4474 layer and sent to its peer. This identifier is not used by 4475 SCTP but can be used by certain network entities as well as 4476 the peer application to identify the type of information being 4477 carried in this DATA chunk. This field must be sent even in 4478 fragmented DATA chunks (to make sure it is available for agents 4479 in the middle of the network). 4481 The value 0 indicates no application identifier is specified by 4482 the upper layer for this payload data. 4484 --------- 4485 New text: (Section 3.3.1) 4486 --------- 4487 Payload Protocol Identifier: 32 bits (unsigned integer) 4489 This value represents an application (or upper layer) specified 4490 protocol identifier. This value is passed to SCTP by its upper 4491 layer and sent to its peer. This identifier is not used by 4492 SCTP but can be used by certain network entities as well as 4493 the peer application to identify the type of information being 4494 carried in this DATA chunk. This field must be sent even in 4495 fragmented DATA chunks (to make sure it is available for agents 4496 in the middle of the network). Note that this field is NOT 4497 touched by an SCTP implementation so that its byte order is 4498 NOT necessarily Big Endian. The upper layer is responsible 4499 for any byte order conversions to this field. 4501 The value 0 indicates no application identifier is specified by 4502 the upper layer for this payload data. 4504 2.50.3. Solution description 4506 It is now explicited stated that the upper layer is responsible for 4507 the byte order of this field. 4509 2.51. Karns Algorithm 4511 2.51.1. Description of the problem 4513 The current wording of the use of KARN's algorithm is not descriptive 4514 enough to assure that an implementation in a multi-homed association 4515 does not incorrectly mis-measure the RTT. 4517 2.51.2. Text changes to the document 4519 --------- 4520 Old text: (Section 6.3.1) 4521 --------- 4523 C5) Karn's algorithm: RTT measurements MUST NOT be made using 4524 packets that were retransmitted (and thus for which it is 4525 ambiguous whether the reply was for the first instance of the 4526 packet or a later instance) 4527 . 4528 --------- 4529 New text: (Section 6.3.1) 4530 --------- 4532 C5) Karn's algorithm: RTT measurements MUST NOT be made using 4533 chunks that were retransmitted (and thus for which it is 4534 ambiguous whether the reply was for the first instance of 4535 the chunk or a later instance) 4537 IMPLEMENTATION NOTE: RTT measurements should only be 4538 made using a chunk with TSN r if no chunk 4539 with TSN less than or equal to r is retransmitted 4540 since r was first sent. 4542 2.51.3. Solution description 4544 The above clarification adds an implementation note that will provide 4545 additional guidance in the application of KARN's algorithm. 4547 2.52. Fast Retransmit algorithm 4549 2.52.1. Description of the problem 4551 The original SCTP specification is overly conservative in requiring 4 4552 missing reports before fast retransmitting a segment. TCP uses 3 4553 missing reports or 4 acknowledgments indicating the same segment was 4554 received. 4556 2.52.2. Text changes to the document 4557 --------- 4558 Old text: 4559 --------- 4561 7.2.4 Fast Retransmit on Gap Reports 4563 In the absence of data loss, an endpoint performs delayed 4564 acknowledgement. However, whenever an endpoint notices a hole in 4565 the arriving TSN sequence, it SHOULD start sending a SACK back 4566 every time a packet arrives carrying data until the 4567 hole is filled. 4569 Whenever an endpoint receives a SACK that indicates some TSN(s) 4570 missing, it SHOULD wait for 3 further miss indications (via 4571 subsequent SACK's) on the same TSN(s) before taking action with 4572 regard to Fast Retransmit. 4574 --------- 4575 New text: 4576 --------- 4578 7.2.4 Fast Retransmit on Gap Reports 4580 In the absence of data loss, an endpoint performs delayed 4581 acknowledgement. However, whenever an endpoint notices a hole in 4582 the arriving TSN sequence, it SHOULD start sending a SACK back 4583 every time a packet arrives carrying data until the 4584 hole is filled. 4586 Whenever an endpoint receives a SACK that indicates some TSN(s) 4587 missing, it SHOULD wait for 2 further miss indications (via 4588 subsequent SACK's for a total of 3 missing reports) on the 4589 same TSN(s) before taking action with regard to Fast Retransmit. 4591 2.52.3. Solution description 4593 The above changes will make SCTP and TCP behave similarly in terms of 4594 how fast they engage the Fast Retansmission algorithm upon receiving 4595 missing reports. 4597 3. Acknowledgments 4599 The authors would like to thank the following people that have 4600 provided comments and input for this document: 4602 Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, 4603 Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina 4604 Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, 4605 Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC 4606 Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, 4607 Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, 4608 Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, 4609 Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth 4610 Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John 4611 Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent 4612 Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, 4613 Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob 4614 Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, 4615 Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar. 4617 A special thanks to Mark Allman, who should actually be a co-author 4618 for his work on the max-burst, but managed to wiggle out due to a 4619 technicality. Also we would like to acknowledge Lyndon Ong and Phil 4620 Conrad for their valuable input and many contributions. 4622 4. IANA considerations 4624 This document recommends changes for the RFC2960 [7] BIS document. 4625 As such, even though it lists new error cause code, this document in 4626 itself does NOT define those new codes. Instead, the BIS document 4627 will make the needed changes to RFC2960 [7] and thus it's IANA 4628 section will require changes to be made. 4630 5. Security considerations 4632 This document should add no additional security risks to SCTP and in 4633 fact SHOULD correct some original security flaws within the original 4634 document once incorporated into a RFC2960 [7] BIS document . 4636 6. References 4638 6.1. Normative references 4640 [1] Braden, R., "Requirements for Internet Hosts - Communication 4641 Layers", STD 3, RFC 1122, October 1989. 4643 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 4644 BCP 9, RFC 2026, October 1996. 4646 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4647 Levels", BCP 14, RFC 2119, March 1997. 4649 [4] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP 4650 and TCP Variants: Congestion Control Under Multiple Losses", 4651 Technical Report TR2003-04, Computer and Information Sciences 4652 Department, University of Delaware, February 2003, 4653 . 4655 [5] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for 4656 End-to-end Failover with Transport Layer Multihoming", 4657 GLOBECOM, November 2004., . 4659 [6] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window 4660 Validation", RFC 2861, June 2000. 4662 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 4663 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 4664 "Stream Control Transmission Protocol", RFC 2960, October 2000. 4666 [8] Stone, J., Stewart, R., and D. Otis, "Stream Control 4667 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 4668 September 2002. 4670 6.2. Informational References 4671 Authors' Addresses 4673 Randall R. Stewart 4674 Cisco Systems, Inc. 4675 4875 Forest Drive 4676 Suite 200 4677 Columbia, SC 29206 4678 USA 4680 Email: rrs@cisco.com 4682 Ivan Arias-Rodriguez 4683 Nokia Research Center 4684 PO Box 407 4685 FIN-00045 Nokia Group 4686 Finland 4688 Email: ivan.arias-rodriguez@nokia.com 4690 Kacheong Poon 4691 Sun Microsystems, Inc. 4692 3571 N. First St. 4693 San Jose, CA 95134 4694 USA 4696 Email: kacheong.poon@sun.com 4698 Armando L. Caro Jr. 4699 University of Delaware 4700 Department of Computer & Information Sciences 4701 103 Smith Hall 4702 Newark, DE 19716 4703 USA 4705 Email: me @ armandocaro . net 4706 URI: http://www.armandocaro.net 4707 Michael Tuexen 4708 Muenster Univ. of Applied Sciences 4709 Stegerwaldstr. 39 4710 48565 Steinfurt 4711 Germany 4713 Email: tuexen@fh-muenster.de 4715 Intellectual Property Statement 4717 The IETF takes no position regarding the validity or scope of any 4718 Intellectual Property Rights or other rights that might be claimed to 4719 pertain to the implementation or use of the technology described in 4720 this document or the extent to which any license under such rights 4721 might or might not be available; nor does it represent that it has 4722 made any independent effort to identify any such rights. Information 4723 on the procedures with respect to rights in RFC documents can be 4724 found in BCP 78 and BCP 79. 4726 Copies of IPR disclosures made to the IETF Secretariat and any 4727 assurances of licenses to be made available, or the result of an 4728 attempt made to obtain a general license or permission for the use of 4729 such proprietary rights by implementers or users of this 4730 specification can be obtained from the IETF on-line IPR repository at 4731 http://www.ietf.org/ipr. 4733 The IETF invites any interested party to bring to its attention any 4734 copyrights, patents or patent applications, or other proprietary 4735 rights that may cover technology that may be required to implement 4736 this standard. Please address the information to the IETF at 4737 ietf-ipr@ietf.org. 4739 Disclaimer of Validity 4741 This document and the information contained herein are provided on an 4742 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4743 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4744 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4745 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4746 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4747 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4749 Copyright Statement 4751 Copyright (C) The Internet Society (2005). This document is subject 4752 to the rights, licenses and restrictions contained in BCP 78, and 4753 except as set forth therein, the authors retain all their rights. 4755 Acknowledgment 4757 Funding for the RFC Editor function is currently provided by the 4758 Internet Society.