[RFCs/IDs] [Plain Text] [From draft-ietf-tsvwg-sctpimpguide]
INFORMATIONAL
Network Working Group R. Stewart
Request for Comments: 4460 Cisco Systems, Inc.
Category: Informational I. Arias-Rodriguez
Nokia Research Center
K. Poon
Sun Microsystems, Inc.
A. Caro
BBN Technologies
M. Tuexen
Muenster Univ. of Applied Sciences
April 2006
Stream Control Transmission Protocol (SCTP) Specification
Errata and Issues
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document is a compilation of issues found during six
interoperability events and 5 years of experience with implementing,
testing, and using Stream Control Transmission Protocol (SCTP) along
with the suggested fixes. This document provides deltas to RFC 2960
and is organized in a time-based way. The issues are listed in the
order they were brought up. Because some text is changed several
times, the last delta in the text is the one that should be applied.
In addition to the delta, a description of the problem and the
details of the solution are also provided.
Table of Contents
1. Introduction ....................................................6
1.1. Conventions ................................................7
2. Corrections to RFC 2960 .........................................7
2.1. Incorrect Error Type During Chunk Processing. ..............7
2.1.1. Description of the Problem ..........................7
2.1.2. Text changes to the document ........................7
2.1.3. Solution Description ................................7
Stewart, et al. Informational [Page 1]
RFC 4460 SCTP Errata April 2006
2.2. Parameter Processing Issue .................................7
2.2.1. Description of the Problem ..........................7
2.2.2. Text Changes to the Document ........................8
2.2.3. Solution Description ................................8
2.3. Padding Issues .............................................8
2.3.1. Description of the Problem ..........................8
2.3.2. Text Changes to the Document ........................9
2.3.3. Solution Description ...............................10
2.4. Parameter Types across All Chunk Types ....................10
2.4.1. Description of the Problem .........................10
2.4.2. Text Changes to the Document .......................10
2.4.3. Solution Description ...............................12
2.5. Stream Parameter Clarification ............................12
2.5.1. Description of the problem .........................12
2.5.2. Text Changes to the Document .......................12
2.5.3. Solution Description ...............................13
2.6. Restarting Association Security Issue .....................13
2.6.1. Description of the Problem .........................13
2.6.2. Text Changes to the Document .......................14
2.6.3. Solution Description ...............................18
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
2.7.1. Description of the Problem .........................19
2.7.2. Text Changes to the Document .......................19
2.7.3. Solution Description ...............................19
2.8. Issues with Fast Retransmit ...............................19
2.8.1. Description of the Problem .........................19
2.8.2. Text Changes to the Document .......................20
2.8.3. Solution Description ...............................23
2.9. Missing Statement about partial_bytes_acked Update ........24
2.9.1. Description of the Problem .........................24
2.9.2. Text Changes to the Document .......................24
2.9.3. Solution Description ...............................25
2.10. Issues with Heartbeating and Failure Detection ...........25
2.10.1. Description of the Problem ........................25
2.10.2. Text Changes to the Document ......................26
2.10.3. Solution Description ..............................28
2.11. Security interactions with firewalls .....................29
2.11.1. Description of the Problem ........................29
2.11.2. Text Changes to the Document ......................29
2.11.3. Solution Description ..............................31
2.12. Shutdown Ambiguity .......................................31
2.12.1. Description of the Problem ........................31
2.12.2. Text Changes to the Document ......................31
2.12.3. Solution Description ..............................32
2.13. Inconsistency in ABORT Processing ........................32
2.13.1. Description of the Problem ........................32
2.13.2. Text changes to the document ......................33
2.13.3. Solution Description ..............................33
Stewart, et al. Informational [Page 2]
RFC 4460 SCTP Errata April 2006
2.14. Cwnd Gated by Its Full Use ...............................34
2.14.1. Description of the Problem ........................34
2.14.2. Text Changes to the Document ......................34
2.14.3. Solution Description ..............................36
2.15. Window Probes in SCTP ....................................36
2.15.1. Description of the Problem ........................36
2.15.2. Text Changes to the Document ......................36
2.15.3. Solution Description ..............................38
2.16. Fragmentation and Path MTU Issues ........................39
2.16.1. Description of the Problem ........................39
2.16.2. Text Changes to the Document ......................39
2.16.3. Solution Description ..............................40
2.17. Initial Value of the Cumulative TSN Ack ..................40
2.17.1. Description of the Problem ........................40
2.17.2. Text Changes to the Document ......................40
2.17.3. Solution Description ..............................41
2.18. Handling of Address Parameters within the INIT or
INIT-ACK .................................................41
2.18.1. Description of the Problem ........................41
2.18.2. Text Changes to the Document ......................41
2.18.3. Solution description ..............................42
2.19. Handling of Stream Shortages .............................42
2.19.1. Description of the Problem ........................42
2.19.2. Text Changes to the Document ......................42
2.19.3. Solution Description ..............................43
2.20. Indefinite Postponement ..................................43
2.20.1. Description of the Problem ........................43
2.20.2. Text Changes to the Document ......................43
2.20.3. Solution Description ..............................44
2.21. User-Initiated Abort of an Association ...................44
2.21.1. Description of the Problem ........................44
2.21.2. Text changes to the document ......................44
2.21.3. Solution Description ..............................50
2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
2.22.1. Description of the Problem ........................50
2.22.2. Text Changes to the Document ......................50
2.22.3. Solution Description ..............................51
2.23. Sending an ABORT in Response to an INIT ..................51
2.23.1. Description of the Problem ........................51
2.23.2. Text Changes to the Document ......................51
2.23.3. Solution Description ..............................52
2.24. Stream Sequence Number (SSN) Initialization ..............52
2.24.1. Description of the Problem ........................52
2.24.2. Text Changes to the Document ......................52
2.24.3. Solution Description ..............................53
2.25. SACK Packet Format .......................................53
2.25.1. Description of the Problem ........................53
2.25.2. Text Changes to the Document ......................53
Stewart, et al. Informational [Page 3]
RFC 4460 SCTP Errata April 2006
2.25.3. Solution Description ..............................53
2.26. Protocol Violation Error Cause ...........................53
2.26.1. Description of the Problem ........................53
2.26.2. Text Changes to the Document ......................54
2.26.3. Solution Description ..............................56
2.27. Reporting of Unrecognized Parameters .....................56
2.27.1. Description of the Problem ........................56
2.27.2. Text Changes to the Document ......................56
2.27.3. Solution Description ..............................57
2.28. Handling of IP Address Parameters ........................58
2.28.1. Description of the Problem ........................58
2.28.2. Text Changes to the Document ......................58
2.28.3. Solution Description ..............................58
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
2.29.1. Description of the Problem ........................59
2.29.2. Text Changes to the Document ......................59
2.29.3. Solution Description ..............................59
2.30. The Initial Congestion Window Size .......................59
2.30.1. Description of the Problem ........................59
2.30.2. Text Changes to the Document ......................60
2.30.3. Solution Description ..............................61
2.31. Stream Sequence Numbers in Figures .......................62
2.31.1. Description of the Problem ........................62
2.31.2. Text Changes to the Document ......................63
2.31.3. Solution description ..............................67
2.32. Unrecognized Parameters ..................................67
2.32.1. Description of the Problem ........................67
2.32.2. Text Changes to the Document ......................67
2.32.3. Solution Description ..............................68
2.33. Handling of Unrecognized Parameters ......................68
2.33.1. Description of the Problem ........................68
2.33.2. Text Changes to the Document ......................68
2.33.3. Solution Description ..............................70
2.34. Tie Tags .................................................70
2.34.1. Description of the Problem ........................70
2.34.2. Text Changes to the Document ......................70
2.34.3. Solution Description ..............................72
2.35. Port Number Verification in the COOKIE-ECHO ..............72
2.35.1. Description of the Problem ........................72
2.35.2. Text Changes to the Document ......................72
2.35.3. Solution Description ..............................73
2.36. Path Initialization ......................................74
2.36.1. Description of the Problem ........................74
2.36.2. Text Changes to the Document ......................74
2.36.3. Solution Description ..............................76
2.37. ICMP Handling Procedures .................................76
2.37.1. Description of the Problem ........................76
2.37.2. Text Changes to the Document ......................77
Stewart, et al. Informational [Page 4]
RFC 4460 SCTP Errata April 2006
2.37.3. Solution Description ..............................79
2.38. Checksum .................................................79
2.38.1. Description of the problem ........................79
2.38.2. Text Changes to the Document ......................79
2.38.3. Solution Description ..............................86
2.39. Retransmission Policy ....................................86
2.39.1. Description of the Problem ........................86
2.39.2. Text Changes to the Document ......................87
2.39.3. Solution Description ..............................87
2.40. Port Number 0 ............................................88
2.40.1. Description of the Problem ........................88
2.40.2. Text Changes to the Document ......................88
2.40.3. Solution Description ..............................89
2.41. T Bit ....................................................89
2.41.1. Description of the Problem ........................89
2.41.2. Text Changes to the Document ......................89
2.41.3. Solution Description ..............................93
2.42. Unknown Parameter Handling ...............................93
2.42.1. Description of the Problem ........................93
2.42.2. Text Changes to the Document ......................93
2.42.3. Solution Description ..............................95
2.43. Cookie Echo Chunk ........................................95
2.43.1. Description of the Problem ........................95
2.43.2. Text Changes to the Document ......................95
2.43.3. Solution Description ..............................96
2.44. Partial Chunks ...........................................96
2.44.1. Description of the Problem ........................96
2.44.2. Text Changes to the Document ......................96
2.44.3. Solution Description ..............................97
2.45. Non-unicast Addresses ....................................97
2.45.1. Description of the Problem ........................97
2.45.2. Text Changes to the Document ......................97
2.45.3. Solution Description ..............................98
2.46. Processing of ABORT Chunks ...............................98
2.46.1. Description of the Problem ........................98
2.46.2. Text Changes to the Document ......................98
2.46.3. Solution Description ..............................98
2.47. Sending of ABORT Chunks ..................................99
2.47.1. Description of the Problem ........................99
2.47.2. Text Changes to the Document ......................99
2.47.3. Solution Description ..............................99
2.48. Handling of Supported Address Types Parameter ............99
2.48.1. Description of the Problem ........................99
2.48.2. Text Changes to the Document .....................100
2.48.3. Solution Description .............................100
2.49. Handling of Unexpected Parameters .......................101
2.49.1. Description of the Problem .......................101
2.49.2. Text Changes to the Document .....................101
Stewart, et al. Informational [Page 5]
RFC 4460 SCTP Errata April 2006
2.49.3. Solution Description .............................102
2.50. Payload Protocol Identifier .............................102
2.50.1. Description of the Problem .......................102
2.50.2. Text Changes to the Document .....................103
2.50.3. Solution Description .............................103
2.51. Karn's Algorithm ........................................104
2.51.1. Description of the Problem .......................104
2.51.2. Text Changes to the Document .....................104
2.51.3. Solution Description .............................104
2.52. Fast Retransmit Algorithm ...............................104
2.52.1. Description of the Problem .......................104
2.52.2. Text Changes to the Document .....................105
2.52.3. Solution Description .............................105
3. Security Considerations .......................................105
4. Acknowledgements ..............................................106
5. IANA Considerations ...........................................106
6. Normative References ..........................................106
1. Introduction
This document contains a compilation of all defects found up until
the publishing of this document for the Stream Control Transmission
Protocol (SCTP), RFC 2960 [5]. These defects may be of an editorial
or technical nature. This document may be thought of as a companion
document to be used in the implementation of SCTP to clarify errors
in the original SCTP document.
This document provides a history of the changes that will be compiled
into RFC 2960's [5] BIS document. Each error will be detailed within
this document in the form of
o the problem description,
o the text quoted from RFC 2960 [5],
o the replacement text that should be placed into the BIS document,
and
o a description of the solution.
This document is a historical record of sequential changes what have
been found necessary at various interop events and through discussion
on this list.
Note that because some text is changed several times, the last delta
for a text in the document is the erratum for that text in RFC 2960.
Stewart, et al. Informational [Page 6]
RFC 4460 SCTP Errata April 2006
1.1. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
RFC 2119 [2].
2. Corrections to RFC 2960
2.1. Incorrect Error Type During Chunk Processing.
2.1.1. Description of the Problem
A typo was discovered in RFC 2960 [5] that incorrectly specifies an
action to be taken when processing chunks of unknown identity.
2.1.2. Text changes to the document
---------
Old text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
---------
New text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
chunk in an 'Unrecognized Chunk Type'.
2.1.3. Solution Description
The receiver of an unrecognized chunk should not send a 'parameter'
error but instead should send the appropriate chunk error as
described above.
2.2. Parameter Processing Issue
2.2.1. Description of the Problem
A typographical error was introduced through an improper cut and
paste in the use of the upper two bits to describe proper handling of
unknown parameters.
Stewart, et al. Informational [Page 7]
RFC 4460 SCTP Errata April 2006
2.2.2. Text Changes to the Document
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it; do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk, and report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK).
2.2.3. Solution Description
It was always the intent to stop processing at the level one was at
in an unknown chunk or parameter with the upper bit set to 0. Thus,
if you are processing a chunk, you should drop the packet. If you
are processing a parameter, you should drop the chunk.
2.3. Padding Issues
2.3.1. Description of the Problem
A problem was found when a Chunk terminated in a TLV parameter. If
this last TLV was not on a 32-bit boundary (as required), there was
confusion as to whether the last padding was included in the chunk
length.
Stewart, et al. Informational [Page 8]
RFC 4460 SCTP Errata April 2006
2.3.2. Text Changes to the Document
---------
Old text: (Section 3.2)
---------
Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
padding.
Chunk Value: variable length
The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields)
MUST be a multiple of 4 bytes. If the length of the chunk is not a
multiple of 4 bytes, the sender MUST pad the chunk with all zero
bytes and this padding is not included in the chunk length field.
The sender should never pad with more than 3 bytes. The receiver
MUST ignore the padding bytes.
---------
New text: (Section 3.2)
---------
Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes, including
the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
chunk padding.
Chunks (including Type, Length, and Value fields) are padded out
by the sender with all zero bytes to be a multiple of 4 bytes
long. This padding MUST NOT be more than 3 bytes in total. The
Chunk Length value does not include terminating padding of the
chunk. However, it does include padding of any variable-length
parameter except the last parameter in the chunk. The receiver
MUST ignore the padding.
Stewart, et al. Informational [Page 9]
RFC 4460 SCTP Errata April 2006
Note: A robust implementation should accept the Chunk whether or
not the final padding has been included in the Chunk Length.
Chunk Value: variable length
The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type.
The total length of a chunk (including Type, Length, and Value
fields) MUST be a multiple of 4 bytes. If the length of the chunk is
not a multiple of 4 bytes, the sender MUST pad the chunk with all
zero bytes, and this padding is not included in the chunk length
field. The sender should never pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
2.3.3. Solution Description
The above text makes clear that the padding of the last parameter is
not included in the Chunk Length field. It also clarifies that the
padding of parameters that are not the last one must be counted in
the Chunk Length field.
2.4. Parameter Types across All Chunk Types
2.4.1. Description of the Problem
A problem was noted when multiple errors are needed to be sent
regarding unknown or unrecognized parameters. Since often the error
type does not hold the chunk type field, it may become difficult to
tell which error was associated with which chunk.
2.4.2. Text Changes to the Document
---------
Old text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2.
---------
New text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
Stewart, et al. Informational [Page 10]
RFC 4460 SCTP Errata April 2006
defined in Section 13.2. Note that a parameter type MUST be unique
across all chunks. For example, the parameter type '5' is used to
represent an IPv4 address (see Section 3.3.2). The value '5' then is
reserved across all chunks to represent an IPv4 address and MUST NOT
be reused with a different meaning in any other chunk.
---------
Old text: (Section 13.2)
---------
13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information:
a) Name of the parameter type.
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.1.
c) Detailed definition of each component of the parameter type.
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
---------
New text: (Section 13.2)
---------
13.2. IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an
IETF Consensus action, as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information:
a) Name of the parameter type.
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.1.
c) Detailed definition of each component of the parameter type.
Stewart, et al. Informational [Page 11]
RFC 4460 SCTP Errata April 2006
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
e) Each parameter type MUST be unique across all chunks.
2.4.3. Solution Description
By having all parameters unique across all chunk assignments (the
current assignment policy), no ambiguity exists as to what a
parameter means in different contexts. The trade-off for this is a
smaller parameter space, i.e., 65,536 parameters versus 65,536 *
Number-of- chunks.
2.5. Stream Parameter Clarification
2.5.1. Description of the problem
A problem was found where the specification is unclear on the
legality of an endpoint asking for more stream resources than were
allowed in the MIS value of the INIT. In particular, the value in
the INIT ACK requested in its OS value was larger than the MIS value
received in the INIT chunk. This behavior is illegal, yet it was
unspecified in RFC 2960 [5]
2.5.2. Text Changes to the Document
---------
Old text: (Section 3.3.3)
---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used.
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association discarding its TCB.
Stewart, et al. Informational [Page 12]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 3.3.3)
---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used, and the value MUST NOT be greater than the MIS value
sent in the INIT chunk.
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association, discarding its TCB.
2.5.3. Solution Description
The change in wording, above, changes it so that a responder to an
INIT chunk does not specify more streams in its OS value than were
represented to it in the MIS value, i.e., its maximum.
2.6. Restarting Association Security Issue
2.6.1. Description of the Problem
A security problem was found when a restart occurs. It is possible
for an intruder to send an INIT to an endpoint of an existing
association. In the INIT the intruder would list one or more of the
current addresses of an association and its own. The normal restart
procedures would then occur, and the intruder would have hijacked an
association.
Stewart, et al. Informational [Page 13]
RFC 4460 SCTP Errata April 2006
2.6.2. Text Changes to the Document
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
Stewart, et al. Informational [Page 14]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields.
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note no old text, new error cause added in section 3.3.10)
---------
3.3.10.11. Restart of an Association with New Addresses (11)
Cause of error
--------------
Restart of an association with new addresses: An INIT was received
on an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The
new addresses are listed in the error code. This ERROR is normally
sent as part of an ABORT refusing the INIT (see Section 5.2).
Stewart, et al. Informational [Page 15]
RFC 4460 SCTP Errata April 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Each New Address TLV is an exact copy of the TLV
that was found in the INIT chunk that was new, including the
Parameter Type and the Parameter length.
---------
Old text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
endpoint MUST respond with an INIT ACK using the same parameters it
sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from
the newly received INIT chunk. The endpoint shall also generate a
State Cookie with the INIT ACK. The endpoint uses the parameters
sent in its INIT to calculate the State Cookie.
---------
New text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
respond with an INIT ACK using the same parameters it sent in its
original INIT chunk (including its Initiation Tag, unchanged). When
responding, the endpoint MUST send the INIT ACK back to the same
address that the original INIT (sent by this endpoint) was sent to.
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
respond with an INIT ACK using the same parameters it sent in its
original INIT chunk (including its Initiation Tag, unchanged),
provided that no NEW address has been added to the forming
association. If the INIT message indicates that a new address has
been added to the association, then the entire INIT MUST be
discarded, and NO changes should be made to the existing association.
An ABORT SHOULD be sent in response that MAY include the error
'Restart of an association with new addresses'. The error SHOULD
list the addresses that were added to the restarting association.
Stewart, et al. Informational [Page 16]
RFC 4460 SCTP Errata April 2006
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
an INIT ACK, the original parameters are combined with those from the
newly received INIT chunk. The endpoint shall also generate a State
Cookie with the INIT ACK. The endpoint uses the parameters sent in
its INIT to calculate the State Cookie.
---------
Old text: (Section 5.2.2)
---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Verification Tag and peer's Verification Tag into a reserved
place within the state cookie. We shall refer to these locations as
the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet
containing this INIT ACK MUST carry a Verification Tag value equal to
the Initiation Tag found in the unexpected INIT. And the INIT ACK
MUST contain a new Initiation Tag (randomly generated see Section
5.3.1). Other parameters for the endpoint SHOULD be copied from the
existing parameters of the association (e.g., number of outbound
streams) into the INIT ACK and cookie.
After sending out the INIT ACK, the endpoint shall take no further
actions, i.e., the existing association, including its current state,
and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT state are the Tie-Tags populated. For a normal association INIT
(i.e., the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be
set to 0 (indicating that no previous TCB existed). The INIT ACK and
State Cookie are populated as specified in section 5.2.1.
---------
New text: (Section 5.2.2)
---------
5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT, and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon receipt of an unexpected INIT for this
association, the endpoint shall generate an INIT ACK with a State
Cookie. Before responding, the endpoint MUST check to see if the
unexpected INIT adds new addresses to the association. If new
addresses are added to the association, the endpoint MUST respond
Stewart, et al. Informational [Page 17]
RFC 4460 SCTP Errata April 2006
with an ABORT, copying the 'Initiation Tag' of the unexpected INIT
into the 'Verification Tag' of the outbound packet carrying the
ABORT. In the ABORT response, the cause of error MAY be set to
'restart of an association with new addresses'. The error SHOULD
list the addresses that were added to the restarting association.
If no new addresses are added, when responding to the INIT in the
outbound INIT ACK, the endpoint MUST copy its current Verification
Tag and peer's Verification Tag into a reserved place within the
state cookie. We shall refer to these locations as the Peer's-Tie-
Tag and the Local-Tie-Tag. The outbound SCTP packet containing this
INIT ACK MUST carry a Verification Tag value equal to the Initiation
Tag found in the unexpected INIT. And the INIT ACK MUST contain a
new Initiation Tag (randomly generated; see Section 5.3.1). Other
parameters for the endpoint SHOULD be copied from the existing
parameters of the association (e.g., number of outbound streams) into
the INIT ACK and cookie.
After sending out the INIT ACK or ABORT, the endpoint shall take no
further actions; i.e., the existing association, including its
current state, and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a
value other than 0. For a normal association INIT (i.e., the
endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0
(indicating that no previous TCB existed).
2.6.3. Solution Description
A new error code is being added, along with specific instructions to
send back an ABORT to a new association in a restart case or
collision case, where new addresses have been added. The error code
can be used by a legitimate restart to inform the endpoint that it
has made a software error in adding a new address. The endpoint then
can choose to wait until the OOTB ABORT tears down the old
association, or to restart without the new address.
Also, the note at the end of Section 5.2.2 explaining the use of the
Tie-Tags was modified to properly explain the states in which the
Tie-Tags should be set to a value different than 0.
Stewart, et al. Informational [Page 18]
RFC 4460 SCTP Errata April 2006
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes
2.7.1. Description of the Problem
Some implementations were having difficulty growing their cwnd. This
was due to an improper enforcement of the congestion control rules.
The rules, as written, provided for a slop over of the cwnd value.
Without this slop over, the sender would appear NOT to be using its
full cwnd value and thus would never increase it.
2.7.2. Text Changes to the Document
---------
Old text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data
outstanding to that transport address.
---------
New text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data
outstanding to that transport address. The sender may exceed cwnd
by up to (PMTU-1) bytes on a new transmission if the cwnd is not
currently exceeded.
2.7.3. Solution Description
The text changes make clear the ability to go over the cwnd value by
no more than (PMTU-1) bytes.
2.8. Issues with Fast Retransmit
2.8.1. Description of the Problem
Several problems were found in the current specification of fast
retransmit. The current wording did not require GAP ACK blocks to be
sent, even though they are essential to the workings of SCTP's
congestion control. The specification left unclear how to handle the
fast retransmit cycle, having the implementation wait on the cwnd to
retransmit a TSN that was marked for fast retransmit. No limit was
placed on how many times a TSN could be fast retransmitted. Fast
Recovery was not specified, causing the congestion window to be
reduced drastically when there are multiple losses in a single RTT.
Stewart, et al. Informational [Page 19]
RFC 4460 SCTP Errata April 2006
2.8.2. Text Changes to the Document
---------
Old text: (Section 6.2)
---------
Acknowledgements MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an
acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN
greater than the value in the Cumulative TSN Ack field SHOULD also be
reported in the Gap Ack Block fields.
---------
New text: (Section 6.2)
---------
Acknowledegments MUST be sent in SACK chunks unless shutdown was
requested by the ULP, in which case an endpoint MAY send an
acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with
TSN greater than the value in the Cumulative TSN Ack field are
reported in the Gap Ack Block fields. The SCTP endpoint MUST
report as many Gap Ack Blocks as can fit in a single SACK
chunk limited by the current path MTU.
---------
Old text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of-
order SACK.
ii) Set rwnd equal to the newly received a_rwnd minus the
number of bytes still outstanding after processing the
Cumulative TSN Ack and the Gap Ack Blocks.
Stewart, et al. Informational [Page 20]
RFC 4460 SCTP Errata April 2006
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then mark the corresponding DATA chunk
as available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no
retransmit timer is running for the destination address
to which the DATA chunk was originally transmitted, then
T3-rtx is started for that destination address.
---------
New text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of-
order SACK.
ii) Set rwnd equal to the newly received a_rwnd minus the
number of bytes still outstanding after processing the
Cumulative TSN Ack and the Gap Ack Blocks.
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then consider the corresponding DATA
that might be possibly missing: Count one miss indication
towards fast retransmit as described in Section 7.2.4, and
if no retransmit timer is running for the destination
address to which the DATA chunk was originally transmitted,
then T3-rtx is started for that destination address.
iv) If the Cumulative TSN Ack matches or exceeds the Fast
Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
---------
Old text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit.
When the TSN(s) is reported as missing in the fourth consecutive
SACK, the data sender shall:
Stewart, et al. Informational [Page 21]
RFC 4460 SCTP Errata April 2006
1) Mark the missing DATA chunk(s) for retransmission,
2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
---------
New text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates that some TSNs
are missing, it SHOULD wait for 3 further miss indications (via
subsequent SACKs) on the same TSN(s) before taking action with
regard to Fast Retransmit.
Miss indications SHOULD follow the HTNA (Highest TSN Newly
Acknowledged) algorithm. For each incoming SACK, miss
indications are incremented only for missing TSNs prior to
the highest TSN newly acknowledged in the SACK. A newly
acknowledged DATA chunk is one not previously acknowledged
in a SACK. If an endpoint is in Fast Recovery and a SACK
arrives that advances the Cumulative TSN Ack Point, the
miss indications are incremented for all TSNs reported
missing in the SACK.
Stewart, et al. Informational [Page 22]
RFC 4460 SCTP Errata April 2006
When the fourth consecutive miss indication is received for a TSN(s),
the data sender shall do the following:
1) Mark the DATA chunk(s) with four miss indications for
retransmission.
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
destination address(es) to which the missing DATA chunks were
last sent, according to the formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. When a Fast Retransmit is
being performed, the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission for this single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. Those TSNs marked
for retransmission due to the Fast Retransmit algorithm that
did not fit in the sent datagram carrying K other TSNs are also
marked as ineligible for a subsequent fast retransmit. However,
as they are marked for retransmission they will be retransmitted
later on as soon as cwnd allows.
6) If not in Fast Recovery, enter Fast Recovery and mark the highest
outstanding TSN as the Fast Recovery exit point. When a SACK
acknowledges all TSNs up to and including this exit point, Fast
Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
SHOULD NOT change for any destinations due to a subsequent Fast
Recovery event (i.e., one SHOULD NOT reduce the cwnd further due
to a subsequent fast retransmit).
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
2.8.3. Solution Description
The effect of the above wording changes are as follows:
Stewart, et al. Informational [Page 23]
RFC 4460 SCTP Errata April 2006
o It requires with a MUST the sending of GAP Ack blocks instead of
the current RFC 2960 [5] SHOULD.
o It allows a TSN being Fast Retransmitted (FR) to be sent only once
via FR.
o It ends the delay in waiting for the flight size to drop when a
TSN is identified as being ready to FR.
o It changes the way chunks are marked during fast retransmit, so
that only new reports are counted.
o It introduces a Fast Recovery period to avoid multiple congestion
window reductions when there are multiple losses in a single RTT
(as shown by Caro et al. [3]).
These changes will effectively allow SCTP to follow a similar model
as TCP+SACK in the handling of Fast Retransmit.
2.9. Missing Statement about partial_bytes_acked Update
2.9.1. Description of the Problem
SCTP uses four control variables to regulate its transmission rate:
rwnd, cwnd, ssthresh, and partial_bytes_acked. Upon detection of
packet losses from SACK, or when the T3-rtx timer expires on an
address, cwnd and ssthresh should be updated as stated in Section
7.2.3. However, that section should also clarify that
partial_bytes_acked must be updated as well; it has to be reset to 0.
2.9.2. Text Changes to the Document
---------
Old text: (Section 7.2.3)
---------
7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by:
Stewart, et al. Informational [Page 24]
RFC 4460 SCTP Errata April 2006
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
7.2.3. Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), an
endpoint should do the following if not in Fast Recovery:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
2.9.3. Solution Description
The missing text added solves the doubts about what to do with
partial_bytes_acked in the situations stated in Section 7.2.3, making
clear that, along with ssthresh and cwnd, partial_bytes_acked should
also be updated by being reset to 0.
2.10. Issues with Heartbeating and Failure Detection
2.10.1. Description of the Problem
Five basic problems have been discovered with the current heartbeat
procedures:
o The current specification does not specify that you should count a
failed heartbeat as an error against the overall association.
o The current specification is not specific as to when you start
sending heartbeats and when you should stop.
o The current specification is not specific as to when you should
respond to heartbeats.
Stewart, et al. Informational [Page 25]
RFC 4460 SCTP Errata April 2006
o When responding to a Heartbeat, it is unclear what to do if more
than a single TLV is present.
o The jitter applied to a heartbeat was meant to be a small variance
of the RTO and is currently a wide variance, due to the default
delay time and incorrect wording within the RFC.
2.10.2. Text Changes to the Document
---------
Old text: (Section 8.1)
---------
8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed).
If the value of this counter exceeds the limit indicated in the
protocol parameter 'Association.Max.Retrans', the endpoint shall
consider the peer endpoint unreachable and shall stop transmitting
any more data to it (and thus the association enters the CLOSED
state). In addition, the endpoint shall report the failure to the
upper layer, and optionally report back all outstanding user data
remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint.
Stewart, et al. Informational [Page 26]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 8.1)
---------
8.1. Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (this includes retransmissions to all the
destination transport addresses of the peer if it is multi-homed),
including unacknowledged HEARTBEAT Chunks. If the value of this
counter exceeds the limit indicated in the protocol parameter
'Association.Max.Retrans', the endpoint shall consider the peer
endpoint unreachable and shall stop transmitting any more data to it
(and thus the association enters the CLOSED state). In addition, the
endpoint MAY report the failure to the upper layer and optionally
report back all outstanding user data remaining in its outbound
queue. The association is automatically closed when the peer
endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint.
---------
Old text: (Section 8.3)
---------
8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport
address(es).
---------
New text: (Section 8.3)
---------
8.3 Path Heartbeat
By default, an SCTP endpoint SHOULD monitor the reachability of the
idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport
address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state and is discontinued after sending either SHUTDOWN
or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state
Stewart, et al. Informational [Page 27]
RFC 4460 SCTP Errata April 2006
(INIT sender) or the ESTABLISHED state (INIT receiver), up until
reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
ACK-SENT state (SHUTDOWN receiver).
---------
Old text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information field copied
from the received HEARTBEAT chunk.
---------
New text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information TLV, together
with any other received TLVs, copied unchanged from the received
HEARTBEAT chunk.
---------
Old text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, a
HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
destination address plus the protocol parameter 'HB.interval' , with
jittering of +/- 50%, and exponential back-off of the RTO if the
previous HEARTBEAT is unanswered.
---------
New text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, it is
recommended that a HEARTBEAT chunk is sent once per RTO of that
destination address plus the protocol parameter 'HB.interval', with
jittering of +/- 50% of the RTO value, and exponential back-off of
the RTO if the previous HEARTBEAT is unanswered.
2.10.3. Solution Description
The above text provides guidance as to how to respond to the five
issues mentioned in Section 2.10.1. In particular, the wording
changes provide guidance as to when to start and stop heartbeating,
Stewart, et al. Informational [Page 28]
RFC 4460 SCTP Errata April 2006
how to respond to a heartbeat with extra parameters, and it clarifies
the error counting procedures for the association.
2.11. Security interactions with firewalls
2.11.1. Description of the Problem
When dealing with firewalls, it is advantageous for the firewall to
be able to properly determine the initial startup sequence of a
reliable transport protocol. With this in mind, the following text
is to be added to SCTP's security section.
2.11.2. Text Changes to the Document
---------
New text: (no old text, new section added)
---------
11.4 SCTP Interactions with Firewalls
It is helpful for some firewalls if they can inspect
just the first fragment of a fragmented SCTP packet and unambiguously
determine whether it corresponds to an INIT chunk (for further
information, please refer to RFC1858). Accordingly, we
stress the requirements, stated in 3.1, that (1) an INIT chunk MUST
NOT be bundled with any other chunk in a packet, and (2) a packet
containing an INIT chunk MUST have a zero Verification Tag.
Furthermore, we require that the receiver of an INIT chunk MUST
enforce these rules by silently discarding an arriving packet with an
INIT chunk that is bundled with other chunks.
---------
Old text: (Section 18)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
Stewart, et al. Informational [Page 29]
RFC 4460 SCTP Errata April 2006
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
---------
New text: (Section 18)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
Stewart, et al. Informational [Page 30]
RFC 4460 SCTP Errata April 2006
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
2.11.3. Solution Description
The above text, which adds a new subsection to the Security
Considerations section of RFC 2960 [5] makes clear that, to make
easier the interaction with firewalls, an INIT chunk must not be
bundled in any case with any other chunk that will silently discard
the packets that do not follow this rule (this rule is enforced by
the packet receiver).
2.12. Shutdown Ambiguity
2.12.1. Description of the Problem
Currently, there is an ambiguity between the statements in Sections
6.2 and 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in
place of a SACK when the sender is in the process of shutting down,
while section 9.2 requires that both a SHUTDOWN chunk and a SACK
chunk be sent.
Along with this ambiguity there is a problem wherein an errant
SHUTDOWN receiver may fail to stop accepting user data.
2.12.2. Text Changes to the Document
---------
Old text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN
receiver shall continue to follow normal data transmission procedures
defined in Section 6 until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunk(s)
with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
entering the SHUTDOWN-ACK-SENT state. If the timer expires, the
endpoint must re-send the SHUTDOWN ACK.
Stewart, et al. Informational [Page 31]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN
receiver MUST continue to follow normal data transmission procedures
defined in Section 6, until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunks
with a SHUTDOWN chunk and restart the T2-shutdown timer. If a
SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
chunks (i.e., there are TSNs that can be acknowledged that are larger
than the cumulative TSN, and thus gaps exist in the TSN sequence), or
if duplicate TSNs have been received, then a SACK chunk MUST also be
sent.
The sender of the SHUTDOWN MAY also start an overall guard timer
'T5-shutdown-guard' to bound the overall time for shutdown sequence.
At the expiration of this timer, the sender SHOULD abort the
association by sending an ABORT chunk. If the 'T5-shutdown-guard'
timer is used, it SHOULD be set to the recommended value of 5 times
'RTO.Max'.
If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a
T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.
If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
2.12.3. Solution Description
The above text clarifies the use of a SACK in conjunction with a
SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown
sequence to protect against errant receivers of SHUTDOWN chunks.
2.13. Inconsistency in ABORT Processing
2.13.1. Description of the Problem
It was noted that the wording in Section 8.5.1 did not give proper
directions in the use of the 'T bit' with the Verification Tags.
Stewart, et al. Informational [Page 32]
RFC 4460 SCTP Errata April 2006
2.13.2. Text changes to the document
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field
of the outbound packet with the destination endpoint's tag
value if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver MUST accept the packet if the Verification Tag
matches either its own tag, OR the tag of its peer. Otherwise,
the receiver MUST silently discard the packet and take no
further action.
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint MUST always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value,
if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver of a ABORT MUST accept the packet if the
Verification Tag field of the packet matches its own tag OR if
it is set to its peer's tag and the T bit is set in the Chunk
Flags. Otherwise, the receiver MUST silently discard the
packet and take no further action.
2.13.3. Solution Description
The above text change clarifies that the T bit must be set before an
implementation looks for the peer's tag.
Stewart, et al. Informational [Page 33]
RFC 4460 SCTP Errata April 2006
2.14. Cwnd Gated by Its Full Use
2.14.1. Description of the Problem
A problem was found with the current specification of the growth and
decay of cwnd. The cwnd should only be increased if it is being
fully utilized, and after periods of underutilization, the cwnd
should be decreased. In some sections, the current wording is weak
and is not clearly defined. Also, the current specification
unnecessarily introduces the need for special case code to ensure
cwnd degradation. Plus, the cwnd should not be increased during Fast
Recovery, since a full cwnd during Fast Recovery does not qualify the
cwnd as being fully utilized. Additionally, multiple loss scenarios
in a single window may cause the cwnd to grow more rapidly as the
number of losses in a window increases [3].
2.14.2. Text Changes to the Document
---------
Old text: (Section 6.1)
---------
D) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow.
---------
New text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks,
the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting
cwnd as follows:
if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine.
E) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B allow.
Stewart, et al. Informational [Page 34]
RFC 4460 SCTP Errata April 2006
---------
Old text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
use the slow start algorithm to increase cwnd (assuming the
current congestion window is being fully utilized). If an
incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
increased by at most the lesser of 1) the total size of the
previously outstanding DATA chunk(s) acknowledged, and 2) the
destination's path MTU. This protects against the ACK-Splitting
attack outlined in [SAVAGE99].
---------
New text: (Section 7.2.1)
---------
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].
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
Stewart, et al. Informational [Page 35]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.Interval - 30 seconds
2.14.3. Solution Description
The above changes strengthen the rules and make it much more apparent
as to the need to block cwnd growth when the full cwnd is not being
utilized. The changes also apply cwnd degradation without
introducing the need for complex special case code.
2.15. Window Probes in SCTP
2.15.1. Description of the Problem
When a receiver clamps its rwnd to 0 to flow control the peer, the
specification implies that one must continue to accept data from the
remote peer. This is incorrect and needs clarification.
2.15.2. Text Changes to the Document
---------
Old text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the receipt of each valid
DATA chunk.
Stewart, et al. Informational [Page 36]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the reception of each valid
DATA chunk when the DATA chunk received is inside its receive window.
When the receiver's advertised window is 0, the receiver MUST drop
any new incoming DATA chunk with a TSN larger than the largest TSN
received so far. If the new incoming DATA chunk holds a TSN value
less than the largest TSN received so far, then the receiver SHOULD
drop the largest TSN held for reordering and accept the new incoming
DATA chunk. In either case, if such a DATA chunk is dropped, the
receiver MUST immediately send back a SACK with the current receive
window showing only DATA chunks received and accepted so far. The
dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
not accepted. The receiver MUST also have an algorithm for
advertising its receive window to avoid receiver silly window
syndrome (SWS), as described in RFC 813. The algorithm can be
similar to the one described in Section 4.2.3.3 of RFC 1122.
---------
Old text: (Section 6.1)
---------
A) At any given time, the data sender MUST NOT transmit new data to
any destination transport address if its peer's rwnd indicates
that the peer has no buffer space (i.e., rwnd is 0, see Section
6.2.1). However, regardless of the value of rwnd (including if it
is 0), the data sender can always have one DATA chunk in flight to
the receiver if allowed by cwnd (see rule B below). This rule
allows the sender to probe for a change in rwnd that the sender
missed due to the SACK having been lost in transit from the data
receiver to the data sender.
Stewart, et al. Informational [Page 37]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 6.1)
---------
A) At any given time, the data sender MUST NOT transmit new data to
any destination transport address if its peer's rwnd indicates
that the peer has no buffer space (i.e., rwnd is 0; see Section
6.2.1). However, regardless of the value of rwnd (including if it
is 0), the data sender can always have one DATA chunk in flight to
the receiver if allowed by cwnd (see rule B, below). This rule
allows the sender to probe for a change in rwnd that the sender
missed due to the SACK's having been lost in transit from the data
receiver to the data sender.
When the receiver's advertised window is zero, this probe is
called a zero window probe. Note that a zero window probe
SHOULD only be sent when all outstanding DATA chunks have
been cumulatively acknowledged and no DATA chunks are in
flight. Zero window probing MUST be supported.
If the sender continues to receive new packets from the receiver
while doing zero window probing, the unacknowledged window probes
should not increment the error counter for the association or any
destination transport address.This is because the receiver MAY
keep its window closed for an indefinite time. Refer to
Section 6.2 on the receiver behavior when it advertises a zero
window. The sender SHOULD send the first zero window probe after
1 RTO when it detects that the receiver has closed its window
and SHOULD increase the probe interval exponentially afterwards.
Also note that the cwnd SHOULD be adjusted according to
Section 7.2.1. Zero window probing does not affect the
calculation of cwnd.
The sender MUST also have an algorithm for sending new DATA chunks
to avoid silly window syndrome (SWS) as described in RFC 813. The
algorithm can be similar to the one described in Section 4.2.3.4
of RFC 1122.
2.15.3. Solution Description
The above allows a receiver to drop new data that arrives and yet
still requires the receiver to send a SACK showing the conditions
unchanged (with the possible exception of a new a_rwnd) and the
dropped chunk as missing. This will allow the association to
continue until the rwnd condition clears.
Stewart, et al. Informational [Page 38]
RFC 4460 SCTP Errata April 2006
2.16. Fragmentation and Path MTU Issues
2.16.1. Description of the Problem
The current wording of the Fragmentation and Reassembly forces an
implementation that supports fragmentation to always fragment. This
prohibits an implementation from offering its users an option to
disable sends that exceed the SCTP fragmentation point.
The restriction in RFC 2960 [5], Section 6.9, was never meant to
restrict an implementations API from this behavior.
2.16.2. Text Changes to the Document
---------
Old text: (Section 6.1)
---------
6.9 Fragmentation and Reassembly
An endpoint MAY support fragmentation when sending DATA chunks, but
MUST support reassembly when receiving DATA chunks. If an endpoint
supports fragmentation, it MUST fragment a user message if the size
of the user message to be sent causes the outbound SCTP packet size
to exceed the current MTU. If an implementation does not support
fragmentation of outbound user messages, the endpoint must return an
error to its upper layer and not attempt to send the user message.
IMPLEMENTATION NOTE: In this error case, the Send primitive
discussed in Section 10.1 would need to return an error to the upper
layer.
---------
New text: (Section 6.1)
---------
6.9. Fragmentation and Reassembly
An endpoint MAY support fragmentation when sending DATA chunks, but
it MUST support reassembly when receiving DATA chunks. If an
endpoint supports fragmentation, it MUST fragment a user message if
the size of the user message to be sent causes the outbound SCTP
packet size to exceed the current MTU. If an implementation does not
support fragmentation of outbound user messages, the endpoint MUST
return an error to its upper layer and not attempt to send the user
message.
Stewart, et al. Informational [Page 39]
RFC 4460 SCTP Errata April 2006
Note: If an implementation that supports fragmentation makes
available to its upper layer a mechanism to turn off fragmentation it
may do so. However, in so doing, it MUST react just like an
implementation that does NOT support fragmentation, i.e., it MUST
reject sends that exceed the current P-MTU.
IMPLEMENTATION NOTE: In this error case, the Send primitive
discussed in Section 10.1 would need to return an error to the upper
layer.
2.16.3. Solution Description
The above wording will allow an implementation to offer the option of
rejecting sends that exceed the P-MTU size even when the
implementation supports fragmentation.
2.17. Initial Value of the Cumulative TSN Ack
2.17.1. Description of the Problem
The current description of the SACK chunk within the RFC does not
clearly state the value that would be put within a SACK when no DATA
chunk has been received.
2.17.2. Text Changes to the Document
---------
Old text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap.
---------
New text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. In the case where no DATA chunk has
been received, this value is set to the peer's Initial TSN minus
one.
Stewart, et al. Informational [Page 40]
RFC 4460 SCTP Errata April 2006
2.17.3. Solution Description
This change clearly states what the initial value will be for a SACK
sender.
2.18. Handling of Address Parameters within the INIT or INIT-ACK
2.18.1. Description of the Problem
The current description on handling address parameters contained
within the INIT and INIT-ACK does not fully describe a requirement
for their handling.
2.18.2. Text Changes to the Document
---------
Old text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver shall derive and record all the
transport address(es) from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport address(es)
are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
---------
New text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver MUST derive and record all the
transport addresses from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport addresses
are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
Stewart, et al. Informational [Page 41]
RFC 4460 SCTP Errata April 2006
D) An INIT or INIT ACK chunk MUST be treated as belonging
to an already established association (or one in the
process of being established) if the use of any of the
valid address parameters contained within the chunk
would identify an existing TCB.
2.18.3. Solution description
This new text clearly specifies to an implementor the need to look
within the INIT or INIT ACK. Any implementation that does not do
this may (for example) not be able to recognize an INIT chunk coming
from an already established association that adds new addresses (see
Section 2.6) or an incoming INIT ACK chunk sent from a source address
different from the destination address used to send the INIT chunk.
2.19. Handling of Stream Shortages
2.19.1. Description of the Problem
The current wording in the RFC places the choice of sending an ABORT
upon the SCTP stack when a stream shortage occurs. This decision
should really be made by the upper layer, not the SCTP stack.
2.19.2. Text Changes to the Document
---------
Old text:
---------
5.1.1 Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk shall
indicate the number of outbound streams (OS) it wishes to have in
the association, as well as the maximum inbound streams (MIS) it
will accept from the other endpoint.
After receiving the stream configuration information from the other
side, each endpoint shall perform the following check: If the peer's
MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants
to configure, the endpoint MUST either use MIS outbound streams, or
abort the association and report to its upper layer the resources
shortage at its peer.
Stewart, et al. Informational [Page 42]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 5.1.2)
---------
5.1.1. Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk MUST
indicate the number of outbound streams (OS) it wishes to have in
the association, as well as the maximum inbound streams (MIS) it will
accept from the other endpoint.
After receiving the stream configuration information from the other
side, each endpoint MUST perform the following check: If the peer's
MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants
to configure, the endpoint MUST use MIS outbound streams and MAY
report any shortage to the upper layer. The upper layer can then
choose to abort the association if the resource shortage
is unacceptable.
2.19.3. Solution Description
The above changes take the decision to ABORT out of the realm of the
SCTP stack and place it into the user's hands.
2.20. Indefinite Postponement
2.20.1. Description of the Problem
The current RFC does not provide any guidance on the assignment of
TSN sequence numbers to outbound messages nor reception of these
messages. This could lead to a possible indefinite postponement.
2.20.2. Text Changes to the Document
---------
Old text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
1 above the beginning TSN of the current send window.
6.2 Acknowledgement on Reception of DATA Chunks
Stewart, et al. Informational [Page 43]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
1 above the beginning TSN of the current send window.
The algorithm by which an implementation assigns sequential TSNs to
messages on a particular association MUST ensure that no user
message that has been accepted by SCTP is indefinitely postponed
from being assigned a TSN. Acceptable algorithms for assigning TSNs
include
(a) assigning TSNs in round-robin order over all streams with
pending data; and
(b) preserving the linear order in which the user messages were
submitted to the SCTP association.
When an upper layer requests to read data on an SCTP association,
the SCTP receiver SHOULD choose the message with the lowest TSN from
among all deliverable messages. In SCTP implementations that allow a
user to request data on a specific stream, this operation SHOULD NOT
block if data is not available, since this can lead to a deadlock
under certain conditions.
6.2. Acknowledgement on Receipt of DATA Chunks
2.20.3. Solution Description
The above wording clarifies how TSNs SHOULD be assigned by the
sender.
2.21. User-Initiated Abort of an Association
2.21.1. Description of the Problem
It is not possible for an upper layer to abort the association and
provide the peer with an indication of why the association is
aborted.
2.21.2. Text changes to the document
Some of the changes given here already include changes suggested in
Section 2.6 of this document.
Stewart, et al. Informational [Page 44]
RFC 4460 SCTP Errata April 2006
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
Stewart, et al. Informational [Page 45]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User-Initiated Abort
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note: no old text, new error added in Section 3.3.10)
---------
3.3.10.12. User-Initiated Abort (12)
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent
because of an upper layer request. The upper layer can specify
an Upper Layer Abort Reason that is transported by SCTP
transparently and MAY be delivered to the upper layer protocol
at the peer.
Stewart, et al. Informational [Page 46]
RFC 4460 SCTP Errata April 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------
Old text: (Section 9.1)
---------
9.1 Abort of an Association
When an endpoint decides to abort an existing association, it
shall send an ABORT chunk to its peer endpoint. The sender MUST
fill in the peer's Verification Tag in the outbound packet and
MUST NOT bundle any DATA chunk with the ABORT.
An endpoint MUST NOT respond to any received packet that contains
an ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT shall apply the special
Verification Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint shall
remove the association from its record and shall report the
termination to its upper layer.
---------
New text: (Section 9.1)
---------
9.1. Abort of an Association
When an endpoint decides to abort an existing association, it MUST
send an ABORT chunk to its peer endpoint. The sender MUST fill in
the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT. If the association is
aborted on request of the upper layer, a User-Initiated Abort
error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk.
An endpoint MUST NOT respond to any received packet that contains
an ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT MUST apply the special Verification
Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint MUST
Stewart, et al. Informational [Page 47]
RFC 4460 SCTP Errata April 2006
remove the association from its record and SHOULD report the
termination to its upper layer. If a User-Initiated Abort error
cause is present in the ABORT chunk, the Upper Layer Abort Reason
SHOULD be made available to the upper layer.
---------
Old text: (Section 10.1)
---------
D) Abort
Format: ABORT(association id [, cause code])
-> result
Ungracefully closes an association. Any locally queued user
data will be discarded and an ABORT chunk is sent to the peer.
A success code will be returned on successful abortion of the
association. If attempting to abort the association results
in a failure, an error code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association
Optional attributes:
o cause code - reason of the abort to be passed to the peer.
---------
New text: (Section 10.1)
---------
D) Abort
Format: ABORT(association id [, Upper Layer Abort Reason])
-> result
Ungracefully closes an association. Any locally queued user
data will be discarded, and an ABORT chunk is sent to the peer.
A success code will be returned on successful abortion of the
association. If attempting to abort the association results
in a failure, an error code shall be returned.
Mandatory attributes:
o association id - Local handle to the SCTP association.
Stewart, et al. Informational [Page 48]
RFC 4460 SCTP Errata April 2006
Optional attributes:
o Upper Layer Abort Reason - Reason of the abort to be passed
to the peer.
None.
---------
Old text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred; The
status may indicate a failure OR a normal termination
event occurred in response to a shutdown or abort
request.
The following may be passed with the notification:
o data retrieval id - an identification used to retrieve
unsent and unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint;
o last-sent - the TSN last sent to that peer endpoint;
---------
New text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - Local handle to the SCTP association.
Stewart, et al. Informational [Page 49]
RFC 4460 SCTP Errata April 2006
o status - This indicates what type of event has occurred; The
status may indicate that a failure OR a normal
termination event occurred in response to a shutdown
or abort request.
The following may be passed with the notification:
o data retrieval id - An identification used to retrieve unsent
and unacknowledged data.
o last-acked - The TSN last acked by that peer endpoint.
o last-sent - The TSN last sent to that peer endpoint.
o Upper Layer Abort Reason - The abort reason specified in
case of a user-initiated abort.
2.21.3. Solution Description
The above allows an upper layer to provide its peer with an
indication of why the association was aborted. Therefore, an
addition error cause was introduced.
2.22. Handling of Invalid Initiate Tag of INIT-ACK
2.22.1. Description of the Problem
RFC 2960 requires that the receiver of an INIT-ACK with the Initiate
Tag set to zero handles this as an error and sends back an ABORT.
But the sender of the INIT-ACK normally has no TCB, and thus the
ABORT is useless.
2.22.2. Text Changes to the Document
---------
Old text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the
Initiate Tag parameter. This value MUST be placed into
the Verification Tag field of every SCTP packet that the
INIT ACK receiver transmits within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
for more on the selection of the Initiate Tag value.
Stewart, et al. Informational [Page 50]
RFC 4460 SCTP Errata April 2006
If the value of the Initiate Tag in a received INIT ACK chunk
is found to be 0, the receiver MUST treat it as an error and
close the association by transmitting an ABORT.
---------
New text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the
Initiate Tag parameter. This value MUST be placed into
the Verification Tag field of every SCTP packet that the
INIT ACK receiver transmits within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
for more on the selection of the Initiate Tag value.
If the value of the Initiate Tag in a received INIT ACK
chunk is found to be 0, the receiver MUST destroy the
association discarding its TCB. The receiver MAY send an
ABORT for debugging purpose.
2.22.3. Solution Description
The new text does not require that the receiver of the invalid INIT-
ACK send the ABORT. This behavior is in tune with the error case of
invalid stream numbers in the INIT-ACK. However, sending an ABORT
for debugging purposes is allowed.
2.23. Sending an ABORT in Response to an INIT
2.23.1. Description of the Problem
Whenever the receiver of an INIT chunk has to send an ABORT chunk in
response, for whatever reason, it is not stated clearly which
Verification Tag and value of the T-bit should be used.
2.23.2. Text Changes to the Document
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1.
Otherwise,
Stewart, et al. Informational [Page 51]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1. If, for
whatever reason, the INIT cannot be processed normally and
an ABORT has to be sent in response, the Verification Tag
of the packet containing the ABORT chunk MUST be the
Initiate tag of the received INIT chunk, and the T-Bit of
the ABORT chunk has to be set to 0, indicating that
a TCB was destroyed. Otherwise,
2.23.3. Solution Description
The new text stated clearly which value of the Verification Tag and
T-bit have to be used.
2.24. Stream Sequence Number (SSN) Initialization
2.24.1. Description of the Problem
RFC 2960 does not describe the fact that the SSN has to be
initialized to 0, as required by RFC 2119.
2.24.2. Text Changes to the Document
---------
Old text: (Section 6.5)
---------
The stream sequence number in all the streams shall start from 0
when the association is established. Also, when the stream
sequence number reaches the value 65535 the next stream sequence
number shall be set to 0.
---------
New text: (Section 6.5)
---------
The stream sequence number in all the streams MUST start from 0
when the association is established. Also, when the stream
sequence number reaches the value 65535 the next stream sequence
number MUST be set to 0.
Stewart, et al. Informational [Page 52]
RFC 4460 SCTP Errata April 2006
2.24.3. Solution Description
The 'shall' in the text is replaced by a 'MUST' to clearly state the
required behavior.
2.25. SACK Packet Format
2.25.1. Description of the Problem
It is not clear in RFC 2960 whether a SACK must contain the fields
Number of Gap Ack Blocks and Number of Duplicate TSNs.
2.25.2. Text Changes to the Document
---------
Old text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack and
Advertised Receiver Window Credit (a_rwnd) parameters.
---------
New text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack,
Advertised Receiver Window Credit (a_rwnd), Number
of Gap Ack Blocks, and Number of Duplicate TSNs fields.
2.25.3. Solution Description
The text has been modified. It is now clear that a SACK always
contains the fields Number of Gap Ack Blocks and Number of Duplicate
TSNs.
2.26. Protocol Violation Error Cause
2.26.1. Description of the Problem
There are many situations where an SCTP endpoint may detect that its
peer violates the protocol. The result of such detection often
results in the association being destroyed by the sending of an
ABORT. Currently, there are only some error causes that could be
used to indicate the reason for the abort, but these do not cover all
cases.
Stewart, et al. Informational [Page 53]
RFC 4460 SCTP Errata April 2006
2.26.2. Text Changes to the Document
Some of the changes given here already include changes suggested in
Section 2.6 and 2.21 of this document.
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
Stewart, et al. Informational [Page 54]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note: no old text; new error added in section 3.3.10)
---------
3.3.10.13. Protocol Violation (13)
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent
because an SCTP endpoint detects a protocol violation of the peer
that is not covered by the error causes described in 3.3.10.1 to
3.3.10.12. An implementation MAY provide additional information
specifying what kind of protocol violation has been detected.
Stewart, et al. Informational [Page 55]
RFC 4460 SCTP Errata April 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.26.3. Solution Description
An additional error cause has been defined that can be used by an
endpoint to indicate a protocol violation of the peer.
2.27. Reporting of Unrecognized Parameters
2.27.1. Description of the Problem
It is not stated clearly in RFC 2960 [5] how unrecognized parameters
should be reported. Unrecognized parameters in an INIT chunk could
be reported in the INIT-ACK chunk or in a separate ERROR chunk, which
can get lost. Unrecognized parameters in an INIT-ACK chunk have to
be reported in an ERROR-chunk. This can be bundled with the COOKIE-
ERROR chunk or sent separately. If it is sent separately and
received before the COOKIE-ECHO, it will be handled as an OOTB
packet, resulting in sending out an ABORT chunk. Therefore, the
association would not be established.
2.27.2. Text Changes to the Document
Some of the changes given here already include changes suggested in
Section 2.2 of this document.
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK).
Stewart, et al. Informational [Page 56]
RFC 4460 SCTP Errata April 2006
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it; do not process
any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk, and report the
unrecognized parameter in an 'Unrecognized Parameter Type', as
described in 3.2.2.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type', as
described in 3.2.2.
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters
and has to report them according to Section 3.2.1, it MUST put
the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
sent in response to the INIT-chunk. Note that if the receiver
of the INIT chunk is NOT going to establish an association (e.g.,
due to lack of resources), then no report would be sent back.
If the receiver of an INIT-ACK chunk detects unrecognized
parameters and has to report them according to Section 3.2.1,
it SHOULD bundle the ERROR chunk containing the
'Unrecognized Parameter' error cause with the COOKIE-ECHO
chunk sent in response to the INIT-ACK chunk. If the
receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
with the ERROR chunk, the ERROR chunk MAY be sent separately
but not before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
first chunk.
2.27.3. Solution Description
The procedure of reporting unrecognized parameters has been described
clearly.
Stewart, et al. Informational [Page 57]
RFC 4460 SCTP Errata April 2006
2.28. Handling of IP Address Parameters
2.28.1. Description of the Problem
It is not stated clearly in RFC 2960 [5] how an SCTP endpoint that
supports either IPv4 addresses or IPv6 addresses should respond if
IPv4 and IPv6 addresses are presented by the peer in th