RFC 4460
Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
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 the INIT or INIT-ACK chunk.2.28.2. Text Changes to the Document
--------- Old text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. --------- New text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re- initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT- ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication.2.28.3. Solution Description
The procedure of handling IP address parameters has been described clearly.
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists
2.29.1. Description of the Problem
The description of the behavior in RFC 2960 [5] when a COOKIE ECHO chunk and a TCB exist could be misunderstood. When a COOKIE ECHO is received, a TCB exists and the local tag and peer's tag match, it is stated that the endpoint should enter the ESTABLISHED state if it has not already done so and send a COOKIE ACK. It was not clear that, in the case the endpoint has already left the ESTABLISHED state again, then it should not go back to established. In case D, the endpoint can only enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing about the peer's tag, which is requested to match in this case.2.29.2. Text Changes to the Document
--------- Old text: (Section 5.2.4) --------- D) When both local and remote tags match the endpoint should always enter the ESTABLISHED state, if it has not already done so. It should stop any init or cookie timers that may be running and send a COOKIE ACK. --------- New text: (Section 5.2.4) --------- D) When both local and remote tags match, the endpoint should enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It should stop any cookie timer that may be running and send a COOKIE ACK.2.29.3. Solution Description
The procedure of handling of COOKIE-ECHO chunks when a TCB exists has been described clearly.2.30. The Initial Congestion Window Size
2.30.1. Description of the Problem
RFC 2960 was published with the intention of having the same congestion control properties as TCP. Since the publication of RFC 2960, TCP's initial congestion window size has been increased via RFC> 3390. This same update will be needed for SCTP to keep SCTP's congestion control properties equivalent to that of TCP.
2.30.2. Text Changes to the Document
--------- Old text: (Section 7.2.1) --------- o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be <= 2*MTU. --------- New text: (Section 7.2.1) --------- o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)). --------- Old text: (Section 7.2.1) --------- o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 2*MTU) per RTO. --------- New text: (Section 7.2.1) --------- o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 4*MTU) per RTO. --------- Old text: (Section 7.2.2) --------- o Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd / 2, 2*MTU) per RTO. --------- New text: (Section 7.2.2) --------- o Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
--------- 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 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: ssthresh = max(cwnd/2, 4*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: ssthresh = max(cwnd/2, 4*MTU) cwnd = 1*MTU2.30.3. Solution Description
The change to SCTP's initial congestion window will allow it to continue to maintain the same congestion control properties as TCP.
2.31. Stream Sequence Numbers in Figures
2.31.1. Description of the Problem
In Section 2.24 of this document, it is clarified that the SSN are initialized with 0. Two figures in RFC 2960 [5] illustrate that they start with 1.
2.31.2. Text Changes to the Document
--------- Old text: (Section 7.2.1) --------- Endpoint A Endpoint Z {app sets association with Z} (build TCB) INIT [I-Tag=Tag_A & other info] ------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) /-- INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Cancel T1-init timer) <-----/ Cookie_Z, & other info] (destroy temp TCB) COOKIE ECHO [Cookie_Z] ------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED state) /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]--\ (Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init / TSN_A,Block=0] (Cancel T3-rtx timer) <------/ ... {app sends 2 messages;strm 0} /---- DATA / [TSN=init TSN_Z <--/ Strm=0,Seq=1 & user data 1] SACK [TSN Ack=init TSN_Z, / ---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=2 & user data 2] <------/\ \ \------> Figure 4: INITiation Example
--------- New text: (Section 7.2.1) --------- Endpoint A Endpoint Z {app sets association with Z} (build TCB) INIT [I-Tag=Tag_A & other info] ------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) /-- INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Cancel T1-init timer) <------/ Cookie_Z, & other info] (destroy temp TCB) COOKIE ECHO [Cookie_Z] ------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED state) /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=0 & user data]--\ (Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init / TSN_A,Block=0] (Cancel T3-rtx timer) <------/ ... {app sends 2 messages;strm 0} /---- DATA / [TSN=init TSN_Z <--/ Strm=0,Seq=0 & user data 1] SACK [TSN Ack=init TSN_Z, /---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=1 & user data 2] <------/\ \ \------> Figure 4: INITiation Example
--------- Old text: (Section 5.2.4.1) --------- Endpoint A Endpoint Z <------------ Association is established----------------------> Tag=Tag_A Tag=Tag_Z <-------------------------------------------------------------> {A crashes and restarts} {app sets up a association with Z} (build TCB) INIT [I-Tag=Tag_A' & other info] --------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (find a existing TCB compose temp TCB and Cookie_Z with Tie-Tags to previous association) /--- INIT ACK [Veri Tag=Tag_A', / I-Tag=Tag_Z', (Cancel T1-init timer) <------/ Cookie_Z[TieTags= Tag_A,Tag_Z & other info] (destroy temp TCB,leave original in place) COOKIE ECHO [Veri=Tag_Z', Cookie_Z Tie=Tag_A, Tag_Z]----------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (Find existing association, Tie-Tags match old tags, Tags do not match i.e., case X X M M above, Announce Restart to ULP and reset association). /---- COOKIE-ACK (Cancel T1-init timer, <------/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]--\ (Start T3-rtx timer) \ \-> /--- SACK [TSN Ack=init TSN_A,Block=0] (Cancel T3-rtx timer) <------/ Figure 5: A Restart Example
--------- New text: (Section 5.2.4.1) --------- Endpoint A Endpoint Z <-------------- Association is established----------------------> Tag=Tag_A Tag=Tag_Z <---------------------------------------------------------------> {A crashes and restarts} {app sets up a association with Z} (build TCB) INIT [I-Tag=Tag_A' & other info] --------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (find a existing TCB compose temp TCB and Cookie_Z with Tie-Tags to previous association) /--- INIT ACK [Veri Tag=Tag_A', / I-Tag=Tag_Z', (Cancel T1-init timer) <------/ Cookie_Z[TieTags= Tag_A,Tag_Z & other info] (destroy temp TCB,leave original in place) COOKIE ECHO [Veri=Tag_Z', Cookie_Z Tie=Tag_A, Tag_Z]----------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (Find existing association, Tie-Tags match old tags, Tags do not match i.e., case X X M M above, Announce Restart to ULP and reset association). /---- COOKIE-ACK (Cancel T1-init timer, <------/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=0 & user data]--\ (Start T3-rtx timer) \ \-> /--- SACK [TSN Ack=init TSN_A,Block=0] (Cancel T3-rtx timer) <------/ Figure 5: A Restart Example
2.31.3. Solution description
Figure 4 and 5 were changed so that the SSN starts with 0 instead of 1.2.32. Unrecognized Parameters
2.32.1. Description of the Problem
The RFC does not state clearly in Section 3.3.3.1 whether one or multiple unrecognized parameters are included in the 'Unrecognized Parameter' parameter.2.32.2. Text Changes to the Document
--------- Old text: (Section 3.3.3) --------- Variable Parameters Status Type Value ------------------------------------------------------------- State Cookie Mandatory 7 IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Unrecognized Parameters Optional 8 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 --------- New text: (Section 3.3.3) --------- Variable Parameters Status Type Value ------------------------------------------------------------- State Cookie Mandatory 7 IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Unrecognized Parameter Optional 8 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 --------- Old text: (Section 3.3.3.1) --------- Unrecognized Parameters: Parameter Type Value: 8 Parameter Length: Variable Size.
Parameter Value:
This parameter is returned to the originator of the INIT
chunk when the INIT contains an unrecognized parameter
which has a value that indicates that it should be reported
to the sender. This parameter value field will contain
unrecognized parameters copied from the INIT chunk complete
with Parameter Type, Length and Value fields.
---------
New text: (Section 3.3.3.1)
---------
Unrecognized Parameter:
Parameter Type Value: 8
Parameter Length: Variable Size.
Parameter Value:
This parameter is returned to the originator of the INIT
chunk when the INIT contains an unrecognized parameter
that has a value that indicates that it should be reported
to the sender. This parameter value field will contain the
unrecognized parameter copied from the INIT chunk complete
with Parameter Type, Length, and Value fields.
2.32.3. Solution Description
The new text states clearly that only one unrecognized parameter is
reported per parameter.
2.33. Handling of Unrecognized Parameters
2.33.1. Description of the Problem
It is not stated clearly in RFC 2960 [5] how unrecognized parameters
should be handled. The problem comes up when an INIT contains an
unrecognized parameter with highest bits 00. It was not clear
whether an INIT-ACK should be sent.
2.33.2. Text Changes to the Document
Some of the changes given here already include changes suggested in
Section 2.27 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). --------- New text: (Section 3.2.1) --------- 00 - Stop processing this parameter; do not process any further parameters within this chunk. 01 - Stop processing this parameter, 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), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT. 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.33.3. Solution Description
The procedure of handling unrecognized parameters has been described clearly.2.34. Tie Tags
2.34.1. Description of the Problem
RFC 2960 requires that Tie-Tags be included in the COOKIE. The cookie may not be encrypted. An attacker could discover the value of the Verification Tags by analyzing cookies received after sending an INIT.2.34.2. Text Changes to the Document
--------- Old text: (Section 1.4) --------- o Tie-Tags: Verification Tags from a previous association. These Tags are used within a State Cookie so that the newly restarting association can be linked to the original association within the endpoint that did not restart. --------- New text: (Section 1.4) --------- o Tie-Tags: Two 32-bit random numbers that together make a 64- bit nonce. These Tags are used within a State Cookie and TCB so that a newly restarting association can be linked to the original association within the endpoint that did not restart and yet not reveal the true Verification Tags of an existing association.
--------- Old text: (Section 5.2.1) --------- For an endpoint that is in the COOKIE-ECHOED state it MUST populate its Tie-Tags with the Tag information of itself and its peer (see Section 5.2.2 for a description of the Tie-Tags). --------- New text: (Section 5.2.1) --------- For an endpoint that is in the COOKIE-ECHOED state it MUST populate its Tie-Tags within both the association TCB and inside the State Cookie (see section 5.2.2 for a description of the Tie-Tags). --------- Old text: (Section 5.2.2) --------- 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. --------- New text: (Section 5.2.2) --------- Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint MUST generate an INIT ACK with a State Cookie. In the outbound INIT ACK, the endpoint MUST copy its current Tie-Tags to a reserved place within the State Cookie and the association's TCB. We shall refer to these locations inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy within an association's TCB as the Local Tag and Peer's 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.
2.34.3. Solution Description
The solution to this problem is not to use the real Verification Tags
within the State Cookie as tie-tags. Instead, two 32-bit random
numbers are created to form one 64-bit nonce and stored both in the
State Cookie and the existing association TCB. This prevents
exposing the Verification Tags inadvertently.
2.35. Port Number Verification in the COOKIE-ECHO
2.35.1. Description of the Problem
The State Cookie sent by a listening SCTP endpoint may not contain
the original port numbers or the local Verification Tag. It is then
possible that the endpoint, on receipt of the COOKIE-ECHO, will not
be able to verify that these values match the original values found
in the INIT and INIT-ACK that began the association setup.
2.35.2. Text Changes to the Document
---------
Old text: (Section 5.1.5)
---------
3) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded and the endpoint MUST transmit an ERROR
chunk with a "Stale Cookie" error cause to the peer endpoint,
4) If the State Cookie is valid, create an association to the
sender of the COOKIE ECHO chunk with the information in the
TCB data carried in the COOKIE ECHO, and enter the
ESTABLISHED state,
5) Send a COOKIE ACK chunk to the peer acknowledging reception
of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
outbound DATA chunk or SACK chunk; however, the COOKIE ACK
MUST be the first chunk in the SCTP packet.
6) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
---------
New text: (Section 5.1.5)
---------
3) Compare the port numbers and the Verification Tag contained
within the COOKIE ECHO chunk to the actual port numbers and the
Verification Tag within the SCTP common header of the received
packet. If these values do not match, the packet MUST be
silently discarded.
4) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded, and the endpoint MUST transmit an
ERROR chunk with a "Stale Cookie" error cause to the peer
endpoint.
5) If the State Cookie is valid, create an association to the
sender of the COOKIE ECHO chunk with the information in the
TCB data carried in the COOKIE ECHO and enter the
ESTABLISHED state.
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of
the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
outbound DATA chunk or SACK chunk; however, the COOKIE ACK
MUST be the first chunk in the SCTP packet.
7) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
2.35.3. Solution Description
By including both port numbers and the local Verification Tag within
the State Cookie and verifying these during COOKIE-ECHO processing,
this issue is resolved.
2.36. Path Initialization
2.36.1. Description of the Problem
When an association enters the ESTABLISHED state, the endpoint has no verification that all of the addresses presented by the peer do in fact belong to the peer. This could cause various forms of denial of service attacks.2.36.2. Text Changes to the Document
--------- Old text: None --------- --------- New text: (Section 5.4) --------- 5.4. Path Verification During association establishment, the two peers exchange a list of addresses. In the predominant case, these lists accurately represent the addresses owned by each peer. However, it is possible that a misbehaving peer may supply addresses that it does not own. To prevent this, the following rules are applied to all addresses of the new association: 1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED. 2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is the one that the INIT-ACK was sent to. 3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification. To probe an address for verification, an endpoint will send HEARTBEATs including a 64-bit random nonce and a path indicator (to identify the address that the HEARTBEAT is sent to) within the HEARTBEAT parameter. Upon receipt of the HEARTBEAT-ACK, a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer.
These probing procedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed. Each RTO a probe may be sent on an active UNCONFIRMED path in an attempt to move it to the CONFIRMED state. If during this probing the path becomes inactive, this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer, the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection, as defined in section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented. The number of HEARTBEATS sent at each RTO SHOULD be limited by the HB.Max.Burst parameter. It is an implementation decision as to how to distribute HEARTBEATS to the peer's addresses for path verification. Whenever a path is confirmed, an indication MAY be given to the upper layer. An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with the following exceptions: - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED address. - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. - A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce. An implementation that does NOT support bundling MUST NOT send a COOKIE-ACK to an UNCONFIRMED address. - A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce, and the packet MUST NOT exceed the path MTU. If the implementation does NOT support bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed the path MTU, then the implementation MUST NOT send a COOKIE-ECHO to an UNCONFIRMED address. --------- 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 --------- 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 HB.Max.Burst - 12.36.3. Solution Description
By properly setting up initial path state and accelerated probing via HEARTBEAT's, a new association can verify that all addresses presented by a peer belong to that peer.2.37. ICMP Handling Procedures
2.37.1. Description of the Problem
RFC 2960 does not describe how ICMP messages should be processed by an SCTP endpoint.
2.37.2. Text Changes to the Document
-------- Old text: None -------- --------- New text --------- 11.5. Protection of Non-SCTP Capable Hosts. To provide a non-SCTP capable host with the same level of protection against attacks as for SCTP-capable ones, all SCTP stacks MUST implement the ICMP handling described in Appendix C. When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk(s) MUST NOT send more than one packet. If bundling is supported, multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported, then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk, since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA. An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN that has not been sent. An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discretion) elect to omit some or all of the ERROR parameters to reduce the size of the INIT-ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT-ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as small as possible to reduce the possibility of byte amplification attacks. --------- Old text: None ---------
---------
New text: (Appendix C)
---------
Appendix C ICMP Handling
Whenever an ICMP message is received by an SCTP endpoint the
following procedures MUST be followed to ensure proper utilization of
the information being provided by layer 3.
ICMP1) An implementation MAY ignore all ICMPv4 messages where the
type field is not set to "Destination Unreachable".
ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable, "Parameter
Problem" or "Packet Too Big".
ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or
"Fragmentation Needed".
ICMP4) An implementation MAY ignore all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized next
header type encountered".
ICMP5) An implementation MUST use the payload of the ICMP message (V4
or V6) to locate the association that sent the message that
ICMP is responding to. If the association cannot be found, an
implementation SHOULD ignore the ICMP message.
ICMP6) An implementation MUST validate that the Verification Tag
contained in the ICMP message matches the verification tag of
the peer. If the Verification Tag is not 0 and does NOT
match, discard the ICMP message. If it is 0 and the ICMP
message contains enough bytes to verify that the chunk type is
an INIT chunk and that the initiate tag matches the tag of the
peer, continue with ICMP7. If the ICMP message is too short
or the chunk type or the initiate tag does not match, silently
discard the packet.
ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP8) If the ICMP code is a "Unrecognized next header type
encountered" or a "Protocol Unreachable", an implementation
MUST treat this message as an abort with the T bit set if it
does not contain an INIT chunk. If it does contain an INIT
chunk and the association is in COOKIE-WAIT state, handle the
ICMP message like an ABORT.
ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
Note that these procedures differ from RFC 1122 [1] and from its
requirements for processing of port-unreachable messages and the
requirements that an implementation MUST abort associations in
response to a "protocol unreachable" message. Port unreachable
messages are not processed, since an implementation will send an
ABORT, not a port unreachable. The stricter handling of the
"protocol unreachable" message is due to security concerns for hosts
that do NOT support SCTP.
2.37.3. Solution Description
The new appendix now describes proper handling of ICMP messages in
conjunction with SCTP.
2.38. Checksum
2.38.1. Description of the problem
RFC 3309 [6] changes the SCTP checksum due to weaknesses in the
original Adler 32 checksum for small messages. This document, being
used as a guide for a cut and paste replacement to update RFC 2960,
thus also needs to incorporate the checksum changes. The idea is
that one could apply all changes found in this guide to a copy of RFC
2960 and have a "new" document that has ALL changes (including RFC
3309).
2.38.2. Text Changes to the Document
---------
Old text:
---------
6.8 Adler-32 Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the Adler-32 checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter shall:
1) Fill in the proper Verification Tag in the SCTP common header
and initialize the checksum field to 0's.
2) Calculate the Adler-32 checksum of the whole packet, including
the SCTP common header and all the chunks. Refer to
appendix B for details of the Adler-32 algorithm. And,
3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the
Adler-32 checksum:
1) Store the received Adler-32 checksum value aside,
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate an Adler-32 checksum value
of the whole received packet. And,
3) Verify that the calculated Adler-32 checksum is the same as the
received Adler-32 checksum. If not, the receiver MUST treat
the packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to
silently discard them.
---------
New text:
---------
6.8 CRC-32c Checksum Calculation
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the CRC32c checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter MUST
1) fill in the proper Verification Tag in the SCTP common header
and initialize the checksum field to '0's,
2) calculate the CRC32c checksum of the whole packet, including
the SCTP common header and all the chunks (refer to
appendix B for details of the CRC32c algorithm); and
3) put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the
CRC32c checksum as follows:
1) Store the received CRC32c checksum value aside.
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate a CRC32c checksum value of
the whole received packet.
3) Verify that the calculated CRC32c checksum is the same as the
received CRC32c checksum. If it is not, the receiver MUST
treat the packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to
silently discard them.
Any hardware implementation SHOULD be done in a way that is
verifiable by the software.
---------
Old text:
---------
Appendix B Alder 32 bit checksum calculation
The Adler-32 checksum calculation given in this appendix is
copied from [RFC1950].
Adler-32 is composed of two sums accumulated per byte: s1 is the
sum of all bytes, s2 is the sum of all s1 values. Both sums are
done modulo 65521. s1 is initialized to 1, s2 to zero. The
Adler-32 checksum is stored as s2*65536 + s1 in network byte
order.
The following C code computes the Adler-32 checksum of a data
buffer. It is written for clarity, not for speed. The sample
code is in the ANSI C programming language. Non C users may
find it easier to read with these hints:
& Bitwise AND operator.
>> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s)
at the left.
<< Bitwise left shift operator. Left shift inserts zero
bit(s) at the right.
++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should
be initialized to 1.
Usage example:
unsigned long adler = 1L;
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
---------
New text:
---------
Appendix B CRC32c Checksum Calculation
We define a 'reflected value' as one that is the opposite of the
normal bit order of the machine. The 32-bit CRC is calculated as
described for CRC-32c and uses the polynomial code 0x11EDC6F41
(Castagnoli93) or x^32+x^28+x^27+x^26+x^25
+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0.
The CRC is computed using a procedure similar to ETHERNET CRC
[ITU32], modified to reflect transport level usage.
CRC computation uses polynomial division. A message
bit-string M is transformed to a polynomial, M(X), and the CRC
is calculated from M(X) using polynomial arithmetic [PETERSON 72].
When CRCs are used at the link layer, the polynomial is derived
from on-the-wire bit ordering: the first bit 'on the wire' is the
high-order coefficient. Since SCTP is a transport-level protocol,
it cannot know the actual serial-media bit ordering. Moreover,
different links in the path between SCTP endpoints may use
different link-level bit orders.
A convention must therefore be established for mapping SCTP
transport messages to polynomials for purposes of CRC computation.
The bit-ordering for mapping SCTP messages to polynomials is that
bytes are taken most-significant first; but within each byte, bits
are taken least-significant first. The first byte of the message
provides the eight highest coefficients. Within each byte,
the least-significant SCTP bit gives the most significant
polynomial coefficient within that byte, and the most-significant
SCTP bit is the least significant polynomial coefficient in that
byte. (This bit ordering is sometimes called 'mirrored' or
'reflected' [WILLIAMS93].) CRC polynomials are to be transformed
back into SCTP transport-level byte values, using a consistent
mapping.
The SCTP transport-level CRC value should be calculated as
follows:
- CRC input data are assigned to a byte stream, numbered from
0 to N-1.
- The transport-level byte-stream is mapped to a polynomial
value. An N-byte PDU with j bytes numbered 0 to N-1 is
considered as coefficients of a polynomial M(x) of order
8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8),
and bit 7 of byte j being coefficient x^(8(N-j)-1).
- The CRC remainder register is initialized with all 1s and
the CRC is computed with an algorithm that simultaneously
multiplies by x^32 and divides by the CRC polynomial.
- The polynomial is multiplied by x^32 and divided by G(x),
the generator polynomial, producing a remainder R(x) of
degree less than or equal to 31.
- The coefficients of R(x) are considered a 32-bit sequence.
- The bit sequence is complemented. The result is the CRC
polynomial.
- The CRC polynomial is mapped back into SCTP transport-level
bytes. The coefficient of x^31 gives the value of bit 7 of
SCTP byte 0, and the coefficient of x^24 gives the value of
bit 0 of byte 0. The coefficient of x^7 gives bit 7 of
byte 3, and the coefficient of x^0 gives bit 0 of byte 3.
The resulting four-byte transport-level sequence is the
32-bit SCTP checksum value.
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
literature on CRCs often follow an alternative formulation, in
which the register used to hold the remainder of the
long-division algorithm is initialized to zero rather than
all-1s, and instead the first 32 bits of the message are
complemented. The long-division algorithm used in our
formulation is specified such that the initial
multiplication by 2^32 and the long-division are combined into
one simultaneous operation. For such algorithms, and for
messages longer than 64 bits, the two specifications are
precisely equivalent. That equivalence is the intent of
this document.
Implementors of SCTP are warned that both specifications are to be
found in the literature, sometimes with no restriction on the
long-division algorithm. The choice of formulation in this
document is to permit non-SCTP usage, where the same CRC
algorithm may be used to protect messages shorter than 64 bits.
There may be a computational advantage in validating the
Association against the Verification Tag, prior to performing a
checksum, as invalid tags will result in the same action as a bad
checksum in most cases. The exceptions for this technique would
be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale
COOKIE-ECHO. These special case exchanges must represent small
packets and will minimize the effect of the checksum calculation.
---------
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.
[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, including changes from 2.11)
---------
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.
[ITU32] ITU-T Recommendation V.42, "Error-correcting
procedures for DCEs using asynchronous-to-synchronous
conversion", Section 8.1.1.6.2, October 1996.
[PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting
Codes, 2nd Edition, MIT Press, Cambridge,
Massachusetts.
[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. [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. [WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" - Internet publication, August 1993, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm.2.38.3. Solution Description
This change adds to the implementor's guide the complete set of changes that, when combined with RFC 2960 [5], encompasses the changes from RFC 3309 [6].2.39. Retransmission Policy
2.39.1. Description of the Problem
The current retransmission policy (send all retransmissions an alternate destination) in the specification has performance issues under certain loss conditions with multihomed endpoints. Instead, fast retransmissions should be sent to the same destination, and only timeout retransmissions should be sent to an alternate destination [4].
2.39.2. Text Changes to the Document
--------- Old text: (Section 6.4) --------- Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk to an active destination transport address that is different from the last destination address to which the DATA chunk was sent. --------- New text: (Section 6.4) --------- Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent. --------- Old text: (Section 6.4.1) --------- When retransmitting data, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted. --------- New text: (Section 6.4.1) --------- When retransmitting data that timed out, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting timed out data, the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.2.39.3. Solution Description
The above wording changes clarify that only timeout retransmissions should be sent to an alternate active destination.