chunk. However, it does include padding of any variable-length
parameter except the last parameter in the chunk. The receiver
MUST ignore the padding.
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
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.
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.
---------
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.
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.
---------
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).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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
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.
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.
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.
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:
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.