draft-ietf-tsvwg-sctpimpguide-01.txt   draft-ietf-tsvwg-sctpimpguide-02.txt 
Network Working Group R. Stewart Internet Engineering Task Force R. Stewart
Request for Comments: 2960 Cisco Systems INTERNET DRAFT Cisco Systems
Category: Internet Draft L. Ong L. Ong
Ciena Systems Ciena Systems
Ivan Arias Rodriguez I. Arias-Rodriguez
Nokia Nokia
K. Poon
Sun Microsystems
June 29 2001 expires in six months November 19 2001
SCTP Implementors Guide SCTP Implementors Guide
draft-ietf-tsvwg-sctpimpguide-01.txt <draft-ietf-tsvwg-sctpimpguide-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet- Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
June 2001 for the Stream Control Transmission Protocol (SCTP) November 2001 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature. [RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be This document may be thought of as a companion document to be used in
used in the implementation of SCTP to clearify errors in the the implementation of SCTP to clarify errors in the original SCTP
original SCTP document. document.
This document updates RFC2960 and text within this document This document updates RFC2960 and text within this document
supersedes the text found in RFC2960. supersedes the text found in RFC2960.
Table of Contents Table of Contents
1. Introduction......................................... 2 1. Introduction......................................... 2
1.1 Conventions....................................... 2 1.1 Conventions........................................ 2
2. Corrections to RFC2960............................... 2 2. Corrections to RFC2960............................... 2
2.1 Incorrect error type during chunk processing....... 2 2.1 Incorrect error type during chunk processing....... 3
2.2 Parameter processing issue......................... 3 2.2 Parameter processing issue......................... 3
2.3 Padding issues.................................... 4 2.3 Padding issues..................................... 4
2.4 Parameter types across all chunk type.............. 5 2.4 Parameter types across all chunk types............. 5
2.5 Stream parameter clarification..................... 7 2.5 Stream parameter clarification..................... 7
2.6 Restarting association security issue.............. 8 2.6 Restarting association security issue.............. 8
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....12 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....12
2.8 Issues with Fast Retransmit........................13 2.8 Issues with Fast Retransmit........................12
2.9 Issues with Heartbeating and failure detection.....17 2.9 Missing statement about partial_bytes_acked update.17
2.10 Security interactions with firewalls..............19 2.10 Issues with Heartbeating and failure detection....18
2.11 Shutdown ambiguity................................19 2.11 Security interactions with firewalls..............21
2.12 Inconsistency in ABORT processing.................21 2.12 Shutdown ambiguity................................22
3. Acknowledgments......................................22 2.13 Inconsistency in ABORT processing.................24
4. Authors' Addresses...................................22 2.14 Cwnd gated by its full use in Slow start..........24
5. References...........................................23 2.15 Window probes in SCTP.............................25
6. Bibliography.........................................23 3. Acknowledgments......................................27
4. Authors' Addresses...................................28
5. References...........................................28
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
May 2001 for the Stream Control Transmission Protocol (SCTP) November 2001 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature. [RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be This document may be thought of as a companion document to be used in
used in the implementation of SCTP. the implementation of SCTP to clarify errors in the original SCTP
document.
This document updates RFC2960 and text within this document, where This document updates RFC2960 and text within this document, where
noted, supersedes the text found in RFC2960. Each error will noted, supersedes the text found in RFC2960. Each error will be
be detailed within this document in the form of: detailed within this document in the form of:
- The problem description, - The problem description,
- The text quoted from RFC2960, - The text quoted from RFC2960,
- The replacement text, - The replacement text,
- A description of the solution. - A description of the solution.
1.1 Conventions 1.1 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[RFC2119]. [RFC2119].
2.0 Corrections to RFC2960 2. Corrections to RFC2960
2.1 Incorrect error type during chunk processing. 2.1 Incorrect error type during chunk processing.
2.1.1 Description of the problem 2.1.1 Description of the problem
A typo was discovered in [RFC2960] that incorrectly specifies A typo was discovered in [RFC2960] that incorrectly specifies an
an action to be taken when processing chunks of unknown identity. action to be taken when processing chunks of unknown identity.
2.1.2 Text changes to the document 2.1.2 Text changes to the document
--------- ---------
Old text: (Section 3.2) Old text: (Section 3.2)
--------- ---------
01 - Stop processing this SCTP packet and discard it, do not process 01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK). ERROR or in the INIT ACK).
--------- ---------
skipping to change at page 3, line 18 skipping to change at page 3, line 29
any further chunks within it, and report the unrecognized any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK). ERROR or in the INIT ACK).
--------- ---------
New text: (Section 3.2) New text: (Section 3.2)
--------- ---------
01 - Stop processing this SCTP packet and discard it, do not process 01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Chunk Type' (in either an chunk in an 'Unrecognized Chunk Type'.
ERROR or in the INIT ACK).
2.1.3 Solution description 2.1.3 Solution description
The receiver of an unrecognized Chunk should not send a The receiver of an unrecognized Chunk should not send a 'parameter'
'parameter' error but instead the appropriate chunk error error but instead the appropriate chunk error as described above.
as described above.
2.2 Parameter processing issue 2.2 Parameter processing issue
2.2.1 Description of the problem 2.2.1 Description of the problem
A typographical error was introduced through an improper cut A typographical error was introduced through an improper cut
and paste in the use of the upper two bits to describe proper and paste in the use of the upper two bits to describe proper
handling of unknown parameters. handling of unknown parameters.
2.2.2 Text changes to the document 2.2.2 Text changes to the document
skipping to change at page 4, line 4 skipping to change at page 4, line 13
ERROR or in the INIT ACK). ERROR or in the INIT ACK).
--------- ---------
New text: (Section 3.2.1) New text: (Section 3.2.1)
--------- ---------
00 - Stop processing this SCTP chunk and discard it, do not process 00 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk. any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, do not process 01 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunks, and report the unrecognized any further parameters within this chunks, and report the
parameter in an 'Unrecognized Parameter Type' (in either an unrecognized parameter in an 'Unrecognized Parameter Type' (in
ERROR or in the INIT ACK). either an ERROR or in the INIT ACK).
2.2.3 Solution description 2.2.3 Solution description
It was always the intent to stop processing at the level one It was always the intent to stop processing at the level one was at
was at in an unknown chunk or parameter with the upper bit in an unknown chunk or parameter with the upper bit set to 0. Thus if
set to 0. Thus if you are processing a chunk, you should drop you are processing a chunk, you should drop the packet. If you are
the packet. If you are processing a parameter, you should processing a parameter, you should drop the chunk.
drop the chunk.
2.3 Padding issues 2.3 Padding issues
2.3.1 Description of the problem 2.3.1 Description of the problem
A problem was found in that when a Chunk terminated in a A problem was found in that when a Chunk terminated in a TLV
TLV parameter. If this last TLV was not on a 32 bit parameter. If this last TLV was not on a 32 bit boundary (as
boundary (as required), there was confusion as to if the last required), there was confusion as to if the last padding was included
padding was included in the chunk length. in the chunk length.
2.3.2 Text changes to the document 2.3.2 Text changes to the document
--------- ---------
Old text: (Section 3.2) Old text: (Section 3.2)
--------- ---------
Chunk Length: 16 bits (unsigned integer) Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the This value represents the size of the chunk in bytes including the
skipping to change at page 4, line 52 skipping to change at page 5, line 6
transferred in the chunk. The usage and format of this field is transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type. dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields) 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 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 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. bytes and this padding is not included in the chunk length field.
The sender should never pad with more than 3 bytes. The receiver The sender should never pad with more than 3 bytes. The receiver
MUST ignore the padding bytes. MUST ignore the padding bytes.
SCTP defined chunks are described in detail in Section 3.3. The
guidelines for IETF-defined chunk extensions can be found in Section
13.1 of this document.
--------- ---------
New text: (Section 3.2) New text: (Section 3.2)
--------- ---------
Chunk Length: 16 bits (unsigned integer) Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length 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 field will be set to 4. The Chunk Length field does not count any
chunk padding. chunk padding.
Chunks (including Type, Length and Value fields) are padded out Chunks (including Type, Length and Value fields) are padded out by
by the sender with all zero bytes to be a multiple of 4 bytes the sender with all zero bytes to be a multiple of 4 bytes long.
long. This padding MUST NOT be more than 3 bytes in total. This padding MUST NOT be more than 3 bytes in total. The Chunk
The Chunk Length value does not include terminating padding Length value does not include terminating padding of the Chunk.
of the Chunk. However, it does include padding of any variable However, it does include padding of any variable length parameter
length parameter except the last parameter in the Chunk. The except the last parameter in the Chunk. The receiver MUST ignore
receiver MUST ignore the padding. the padding.
Note: A robust implementation should accept the Chunk whether Note: A robust implementation should accept the Chunk whether
or not the final padding has been included in the Chunk Length. or not the final padding has been included in the Chunk Length.
Chunk Value: variable length Chunk Value: variable length
The Chunk Value field contains the actual information to be The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type. dependent on the Chunk Type.
skipping to change at page 5, line 45 skipping to change at page 5, line 46
The above text makes clear that the padding of the last parameter is 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 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 padding of parameters that are not the last one must be counted in
the Chunk Length field. the Chunk Length field.
2.4 Parameter types across all chunk types 2.4 Parameter types across all chunk types
2.4.1 Description of the problem 2.4.1 Description of the problem
A problem was noted when multiple errors are needed A problem was noted when multiple errors are needed to be sent
to be sent regarding unknown or unrecognized parameters. regarding unknown or unrecognized parameters. Since often times the
Since often times the error type does not hold the chunk error type does not hold the chunk type field, it may become
type field, it may become difficult to tell which error difficult to tell which error was associated with which chunk.
was associated with which chunk.
2.4.2 Text changes to the document 2.4.2 Text changes to the document
--------- ---------
Old text: (Section 3.2.1) Old text: (Section 3.2.1)
--------- ---------
The actual SCTP parameters are defined in the specific SCTP chunk The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2. defined in Section 13.2.
--------- ---------
New text: (Section 3.2.1) New text: (Section 3.2.1)
--------- ---------
The actual SCTP parameters are defined in the specific SCTP chunk The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2. Note that a parameter value MUST be unique defined in Section 13.2. Note that a parameter value MUST be unique
across all chunks. For example, the parameter value '5' is used to across all chunks. For example, the parameter value '5' is used to
represent an IPv4 address (see section 3.3.2). The value '5' then represent an IPv4 address (see section 3.3.2). The value '5' then is
is reserved across all chunks to represent an IPv4 address and reserved across all chunks to represent an IPv4 address and MUST NOT
MUST NOT be reused with a different meaning in any other chunk. be reused with a different meaning in any other chunk.
--------- ---------
Old text: (Section 13.2) Old text: (Section 13.2)
--------- ---------
13.2 IETF-defined Chunk Parameter Extension 13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
skipping to change at page 6, line 55 skipping to change at page 6, line 55
--------- ---------
13.2 IETF-defined Chunk Parameter Extension 13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) Name of the parameter type. a) Name of the parameter type.
b) Detailed description of the structure of the parameter field. b) Detailed description of the structure of the parameter field. This
This structure MUST conform to the general type-length-value structure MUST conform to the general type-length-value format
format described in Section 3.2.1. described in Section 3.2.1.
c) Detailed definition of each component of the parameter value. c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type, d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same instances of this parameter type may be found within the same
chunk. chunk.
e) Each parameter type MUST be unique across all chunks. e) Each parameter type MUST be unique across all chunks.
2.4.3 Solution description 2.4.3 Solution description
By having all parameters unique across all chunk assignments By having all parameters unique across all chunk assignments (the
(the current assignment policy) no ambiguity exists as to current assignment policy) no ambiguity exists as to what a parameter
what a parameter means based on context. The trade off for means based on context. The trade off for this is a smaller parameter
this is a smaller parameter space i.e. 65,535 parameters space i.e. 65,535 parameters versus 65,535 * Number-of-chunks.
versus 65,535 * Number-of-chunks.
2.5 Stream parameter clarification 2.5 Stream parameter clarification
2.5.1 Description of the problem 2.5.1 Description of the problem
A problem was found where the specification is unclear A problem was found where the specification is unclear on the
on the legality of an endpoint asking for more stream legality of an endpoint asking for more stream resources than were
resources than were allowed in the OS value of the INIT. allowed in the MIS value of the INIT. In particular the value in the
In particular the value in the INIT ACK requested in INIT ACK requested in its OS value was larger than the MIS value
its MIS value was larger than the OS value received in received in the INIT chunk. This behavior is illegal yet it was
the INIT chunk. This behavior is illegal yet it was
unspecified in [RFC2960]. unspecified in [RFC2960].
2.5.2 Text changes to the document 2.5.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.3) Old text: (Section 3.3.3)
--------- ---------
Number of Inbound Streams (MIS) : 16 bits (unsigned integer) Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT ACK
chunk allows the peer end to create in this association. The
value 0 MUST NOT be used.
Note: There is no negotiation of the actual number of streams but Defines the number of outbound streams the sender of this INIT ACK
instead the two endpoints will use the min(requested, offered). chunk wishes to create in this association. The value of 0 MUST
See Section 5.1.1 for details. NOT be used.
Note: A receiver of an INIT ACK with the MIS value set to 0 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
SHOULD destroy the association discarding its TCB. destroy the association discarding its TCB.
--------- ---------
New text: (Section 3.3.3) New text: (Section 3.3.3)
--------- ---------
Number of Inbound Streams (MIS) : 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT ACK Number of Outbound Streams (OS): 16 bits (unsigned integer)
chunk allows the peer end to create in this association. The
value 0 MUST NOT be used.
Note: There is no negotiation of the actual number of streams but Defines the number of outbound streams the sender of this INIT ACK
instead the two endpoints will use the min(requested, offered). chunk wishes to create in this association. The value of 0 MUST
See Section 5.1.1 for details. The Number of Inbound Streams NOT be used and the value MUST NOT be greater than the MIS value
sent in the INIT ACK MUST NOT be greater than the value found sent in the INIT chunk.
in the number of outbound streams received in the INIT.
Note: A receiver of an INIT ACK with the MIS value set to 0 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
SHOULD destroy the association discarding its TCB. destroy the association discarding its TCB.
2.5.3 Solution description 2.5.3 Solution description
The change in wording, above, changes it so that a responder The change in wording, above, changes it so that a responder to an
to an INIT chunk does not specify more streams in it's INIT chunk does not specify more streams in it's OS value than was
MIS value then was represented to it in the OS value i.e. represented to it in the MIS value i.e. its maximum.
its maximum.
2.6 Restarting association security issue 2.6 Restarting association security issue
2.6.1 Description of the problem 2.6.1 Description of the problem
A security problem was found when a restart occurs. It is A security problem was found when a restart occurs. It is possible
possible for an intruder to send an INIT to an endpoint for an intruder to send an INIT to an endpoint of an existing
of an existing association. In the INIT the intruder would association. In the INIT the intruder would list one or more of
list all of the current addresses of an association and the current addresses of an association and its own. The normal restart
its own. The normal restart procedures would then occur procedures would then occur and the intruder would have hi-jacked an
and the intruder would have hi-jacked an association. association.
2.6.2 Text changes to the document 2.6.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.10) Old text: (Section 3.3.10)
--------- ---------
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
1 Invalid Stream Identifier 1 Invalid Stream Identifier
2 Missing Mandatory Parameter 2 Missing Mandatory Parameter
3 Stale Cookie Error 3 Stale Cookie Error
4 Out of Resource 4 Out of Resource
5 Unresolvable Address 5 Unresolvable Address
6 Unrecognized Chunk Type 6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter 7 Invalid Mandatory Parameter
skipping to change at page 10, line 5 skipping to change at page 9, line 45
discussed in Section 13.3. discussed in Section 13.3.
--------- ---------
New text: (Note no old text, new error added in section 3.3.10) New text: (Note no old text, new error added in section 3.3.10)
--------- ---------
3.3.10.11 Restart of an association with new addresses (11) 3.3.10.11 Restart of an association with new addresses (11)
Cause of error Cause of error
-------------- --------------
Restart of an association with new addresses: A INIT was Restart of an association with new addresses: An INIT was received
received on an existing association. But the INIT added on an existing association. But the INIT added addresses to the
addresses to the association that were previously NOT part association that were previously NOT part of the association. The
of the association. The New addresses are listed in the New addresses are listed in the error code. This ERROR is normally
error code. This ERROR is normally sent as part of an ABORT sent as part of an ABORT refusing the INIT (see section 5.2).
refusing the Cookie Echo (see section 5.2.4).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable | | Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs / / New Address TLVs /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--------- ---------
Old text: (Section 5.2.1) Old text: (Section 5.2.1)
--------- ---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an 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 endpoint MUST respond with an INIT ACK using the same parameters it
sent in its original INIT chunk (including its Initiation Tag, sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from unchanged). These original parameters are combined with those from
the newly received INIT chunk. The endpoint shall also generate a the newly received INIT chunk. The endpoint shall also generate a
State Cookie with the INIT ACK. The endpoint uses the parameters State Cookie with the INIT ACK. The endpoint uses the parameters
skipping to change at page 10, line 35 skipping to change at page 10, line 20
sent in its original INIT chunk (including its Initiation Tag, sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from unchanged). These original parameters are combined with those from
the newly received INIT chunk. The endpoint shall also generate a the newly received INIT chunk. The endpoint shall also generate a
State Cookie with the INIT ACK. The endpoint uses the parameters State Cookie with the INIT ACK. The endpoint uses the parameters
sent in its INIT to calculate the State Cookie. sent in its INIT to calculate the State Cookie.
--------- ---------
New text: (Section 5.2.1) New text: (Section 5.2.1)
--------- ---------
Upon receipt of an INIT in the COOKIE-WAIT state, an Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
endpoint MUST respond with an INIT ACK using the same parameters it respond with an INIT ACK using the same parameters it sent in its
sent in its original INIT chunk (including its Initiation Tag, original INIT chunk (including its Initiation Tag, unchanged). When
unchanged). When responding the endpoint MUST send the INIT ACK responding the endpoint MUST send the INIT ACK back to the same
back to the same address that the original INIT (sent by this address that the original INIT (sent by this endpoint) was sent to.
endpoint) was sent to.
Upon receipt of an INIT in the COOKIE-ECHOED state, an Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
endpoint MUST respond with an INIT ACK using the same parameters it respond with an INIT ACK using the same parameters it sent in its
sent in its original INIT chunk (including its Initiation Tag, original INIT chunk (including its Initiation Tag, unchanged)
unchanged) provided that no NEW address have been added to provided that no NEW address have been added to the forming
the forming association. If the INIT message indicates that association. If the INIT message indicates that a new address(es)
a new address(es) have been added to the association, have been added to the association, then the entire INIT MUST be
then the entire INIT MUST be discarded and NO changes should discarded and NO changes should be made to the existing association.
be made to the existing association. An ABORT MUST be sent An ABORT MUST be sent in response that SHOULD include the error
in response that SHOULD include the error 'restart of an 'Restart of an association with new addresses'. The error SHOULD list
association with new addresses'. The error SHOULD list the the addresses that were added to the restarting association.
addresses that were added to the restarting association.
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
with an INIT ACK the original parameters are combined with those an INIT ACK the original parameters are combined with those from the
from the newly received INIT chunk. The endpoint shall also generate a newly received INIT chunk. The endpoint shall also generate a State
State Cookie with the INIT ACK. The endpoint uses the parameters Cookie with the INIT ACK. The endpoint uses the parameters sent in
sent in its INIT to calculate the State Cookie. its INIT to calculate the State Cookie.
--------- ---------
Old text: (Section 5.2.2) Old text: (Section 5.2.2)
--------- ---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT and SHUTDOWN-ACK-SENT COOKIE-WAIT and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon reception of an unexpected INIT for Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a this association, the endpoint shall generate an INIT ACK with a
skipping to change at page 11, line 31 skipping to change at page 11, line 13
the Initiation Tag found in the unexpected INIT. And the INIT ACK the Initiation Tag found in the unexpected INIT. And the INIT ACK
MUST contain a new Initiation Tag (randomly generated see Section MUST contain a new Initiation Tag (randomly generated see Section
5.3.1). Other parameters for the endpoint SHOULD be copied from the 5.3.1). Other parameters for the endpoint SHOULD be copied from the
existing parameters of the association (e.g. number of outbound existing parameters of the association (e.g. number of outbound
streams) into the INIT ACK and cookie. streams) into the INIT ACK and cookie.
After sending out the INIT ACK, the endpoint shall take no further After sending out the INIT ACK, the endpoint shall take no further
actions, i.e., the existing association, including its current state, actions, i.e., the existing association, including its current state,
and the corresponding TCB MUST NOT be changed. 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) New text: (Section 5.2.2)
--------- ---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT and SHUTDOWN-ACK-SENT COOKIE-WAIT and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon reception of an unexpected INIT for Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a this association, the endpoint shall generate an INIT ACK with a
State Cookie. Before responding the endpoint MUST check to see if State Cookie. Before responding the endpoint MUST check to see if the
the unexpected INIT adds new addresses to the association. If new unexpected INIT adds new addresses to the association. If new
addresses are added to the association, the endpoint MUST respond addresses are added to the association, the endpoint MUST respond
with an ABORT copying the 'Initiation Tag' of the unexpected INIT with an ABORT copying the 'Initiation Tag' of the unexpected INIT
into the 'Verification Tag' of the outbound ABORT. In the ABORT into the 'Verification Tag' of the outbound packet carrying the ABORT.
response the cause of error SHOULD be set to 'restart of an In the ABORT response the cause of error SHOULD be set to 'restart
association with new addresses'. The error SHOULD list the addresses of an association with new addresses'. The error SHOULD list the
that were added to the restarting association. addresses that were added to the restarting association.
If no new addresses are added, when responding to the INIT in the If no new addresses are added, when responding to the INIT in the
outbound INIT ACK the endpoint MUST copy its current Verification outbound INIT ACK the endpoint MUST copy its current Verification Tag
Tag and peer's Verification Tag into a reserved place within the and peer's Verification Tag into a reserved place within the state
state cookie. We shall refer to these locations as the cookie. We shall refer to these locations as the Peer's-Tie-Tag and
Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK
containing this INIT ACK MUST carry a Verification Tag value equal MUST carry a Verification Tag value equal to the Initiation Tag found
to the Initiation Tag found in the unexpected INIT. And the INIT in the unexpected INIT. And the INIT ACK MUST contain a new
ACK MUST contain a new Initiation Tag (randomly generated see Initiation Tag (randomly generated see Section 5.3.1). Other
Section 5.3.1). Other parameters for the endpoint SHOULD be copied parameters for the endpoint SHOULD be copied from the existing
from the existing parameters of the association (e.g. number of parameters of the association (e.g. number of outbound streams) into
outbound streams) into the INIT ACK and cookie. the INIT ACK and cookie.
After sending out the INIT ACK or ABORT, the endpoint shall take no After sending out the INIT ACK or ABORT, the endpoint shall take no
further actions, i.e., the existing association, including its further actions, i.e., the existing association, including its
current state, and the corresponding TCB MUST NOT be changed. 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, COOKIE-ECHOED 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 2.6.3 Solution description
A new error code is being added and specific instructions to send A new error code is being added and specific instructions to send
back an ABORT to a new association in a restart case or collision 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 case, where new addresses have been added. The error code can be used
used by a legitimate restart to inform the endpoint that it has made by a legitimate restart to inform the endpoint that it has made a
a software error in adding a new address. The endpoint then can software error in adding a new address. The endpoint then can choose
choose to wait until the OOTB ABORT tears down the old association, to wait until the OOTB ABORT tears down the old association, or
or restart without the new address. 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 Implicit ability to exceed cwnd by PMTU-1 bytes
2.7.1 Description of the problem 2.7.1 Description of the problem
Some implementations were having difficulty growing there Some implementations were having difficulty growing their cwnd. This
cwnd. This was due to an improper enforcement of the congestion was due to an improper enforcement of the congestion control rules.
control rules. The rules, as written, provided for a slop The rules, as written, provided for a slop over of the cwnd value.
over of the cwnd value. Without this slop over the sender Without this slop over the sender would appear to NOT be using its
would appear to NOT be using its full cwnd value and thus full cwnd value and thus never increase it.
never increase it.
2.7.2 Text changes to the document 2.7.2 Text changes to the document
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
B) At any given time, the sender MUST NOT transmit new data to a 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 given transport address if it has cwnd or more bytes of data
outstanding to that transport address. outstanding to that transport address.
--------- ---------
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
B) At any given time, the sender MUST NOT transmit new data to a 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 given transport address if it has cwnd or more bytes of data
outstanding to that transport address. The sender may exceed outstanding to that transport address. The sender may exceed cwnd
cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd is not
is not currently exceeded. currently exceeded.
2.7.3 Solution description 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. 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 Issues with Fast Retransmit
2.8.1 Description of the problem 2.8.1 Description of the problem
A problem was found in the current specification of fast retransmit. A problem was found in the current specification of fast retransmit.
In particular in a high bandwidth * delay network. The current wording In particular in a high bandwidth * delay network. The current
did not require GAP ACK blocks to be sent, even though they are essential wording did not require GAP ACK blocks to be sent, even though they
to the workings of SCTP's congestion control. Also the specification are essential to the workings of SCTP's congestion control. Also the
left unclear how to handle the fast retransmit cycle. Waiting to specification left unclear how to handle the fast retransmit cycle,
retransmit a TSN needing fast retransmit. Also no limit was placed having the implementation to wait on the cwnd to retransmit a TSN
on how many times a TSN could be fast retransmitted. When recovering that was marked for fast retransmit. Also no limit was placed on how
from a fast retransmit no burst limit was applied as well to prevent many times a TSN could be fast retransmitted. When recovering from a
an rwnd clamp down from causing an excessive burst of traffic. fast retransmit no burst limit was applied as well to prevent an rwnd
clamp down from causing an excessive burst of traffic.
2.8.2 Text changes to the document 2.8.2 Text changes to the document
--------- ---------
Old text: (Section 6.2) Old text: (Section 6.2)
--------- ---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an requested by the ULP in which case an endpoint MAY send an
acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
skipping to change at page 14, line 54 skipping to change at page 14, line 48
below in M1-M3, below in M1-M3,
2) Adjust the ssthresh and cwnd of the destination address(es) to 2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3. formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. When a Fast Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is
is being performed the sender SHOULD ignore the value of cwnd and being performed the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission. SHOULD NOT delay retransmission.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that retransmitting the first outstanding DATA chunk sent to that
address. address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus 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.
5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. ineligible for a subsequent fast retransmit.
Note: Before the above adjustments, if the received SACK also Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack 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 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first. must be applied first.
A straightforward implementation of the above is as follows: A straightforward implementation of the above is as follows:
M1) Each time a new DATA chunk is transmited set the M1) Each time a new DATA chunk is transmitted set the
'TSN.Missing.Report' count for that TSN to 0. The 'TSN.Missing.Report' count for that TSN to 0. The
'TSN.Missing.Report' count will be used to determine 'TSN.Missing.Report' count will be used to determine missing
missing segments and when to fast retransmit. segments and when to fast retransmit.
M2) Each time a SACK arrives reporting 'Stray DATA chunk(s)' M2) Each time a SACK arrives reporting 'Stray DATA chunk(s)' record
record the highest new TSN reported as newly acknowledged, the highest new TSN reported as newly acknowledged, call this
call this value 'HighestTSNinSack'. A newly acknowledged value 'HighestTSNinSack'. A newly acknowledged DATA chunk is one
DATA chunk is one not previously acknowledged in a SACK. not previously acknowledged in a SACK.
A 'Stray Data chunk', is when the SCTP sender of data receives When the SCTP sender of data receives a SACK chunk that
a SACK chunk that acknowledges, for the first time, the acknowledges, for the first time, the receipt of a DATA chunk,
receipt of a DATA chunk. All the still unacknowledged DATA all the still unacknowledged DATA chunks whose TSN is older than
chunks whose TSN is older than that newly acknowledged DATA that newly acknowledged DATA chunk, are qualified as
chunk, are qualified as stray. 'Stray DATA chunks'.
M3) Examine all 'Unacknowledged TSN's', if the TSN number M3) Examine all 'Unacknowledged TSN's', if the TSN number of an
of an 'Unaknowledged TSN' is smaller than the 'HigestTSNinSack' 'Unacknowledged TSN' is smaller than the 'HighestTSNinSack'
value, increment the 'TSN.Missing.Report' count on that value, increment the 'TSN.Missing.Report' count on that chunk if
chunk if it has NOT been fast retransmitted or marked it has NOT been fast retransmitted or marked for fast retransmit
for fast retransmit already. already.
M4) If any DATA chunk is found to have a 'TSN.Missing.Report' value M4) If any DATA chunk is found to have a 'TSN.Missing.Report' value
larger than or equal to 4, mark that chunk for larger than or equal to 4, mark that chunk for retransmission and
retransmission and start the fast retransmit procuedure start the fast retransmit procedure (steps 2-5 above).
(steps 2-5 above).
M5) If a T3-rxt timer expires,the 'TSN.Missing.Report' of all M5) If a T3-rtx timer expires, the 'TSN.Missing.Report' of all
affected TSNs is set to 0. affected TSNs is set to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size. no adjustment to the congestion control window size.
Upon acknowledgment of a DATA chunk that has been fast retransmitted, Upon acknowledgment of a DATA chunk that has been fast retransmitted,
the protocol parameter 'Max.Burst' MUST be applied to limit the protocol parameter 'Max.Burst' MUST be applied to limit how many
how many SCTP packets may be sent upon the completion of SACK SCTP packets may be sent upon the completion of SACK processing.
processing.
--------- ---------
Old text: (Section 14) Old text: (Section 14)
--------- ---------
14. Suggested SCTP Protocol Parameter Values 14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED: The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
RTO.Alpha - 1/8 RTO.Alpha - 1/8
RTO.Beta - 1/4 RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds Valid.Cookie.Life - 60 seconds
skipping to change at page 16, line 39 skipping to change at page 16, line 43
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
Max.Burst - 4 packets Max.Burst - 4 packets
RTO.Alpha - 1/8 RTO.Alpha - 1/8
RTO.Beta - 1/4 RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address) Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds HB.Interval - 30 seconds
2.8.3 Solution description 2.8.3 Solution description
The effect of the above wording changes are as follows: The effect of the above wording changes are as follows:
- It requires with a MUST the sending of GAP Ack blocks - It requires with a MUST the sending of GAP Ack blocks instead of
instead of the current [RFC2960] SHOULD. the current [RFC2960] SHOULD.
- It allows a TSN being Fast Retransmitted (FR) to be sent - It allows a TSN being Fast Retransmitted (FR) to be sent only once
only once via FR. via FR.
- It ends the delay in awaiting for the flight size to - It ends the delay in awaiting for the flight size to drop when a
drop when a TSN is identified ready to FR. TSN is identified ready to FR.
- It applies a Max.Burst parameter to prevent a FR from - It applies a Max.Burst parameter to prevent a FR from flooding the
flooding the network with packets after rwnd has been network with packets after rwnd has been clamped to '0' for a
clamped to '0' for a period of time. period of time.
- It changes the way chunks are marked during fast retransmit, - It changes the way chunks are marked during fast retransmit, so
so that only new reports are counted (using M1-M4 above). that only new reports are counted (using M1-M4 above).
These changes will effectively allow SCTP to follow a These changes will effectively allow SCTP to follow a similar model
similar model as TCP+SACK in the handling of Fast Retransmit. as TCP+SACK in the handling of Fast Retransmit.
2.9 Issues with Heartbeating and failure detection 2.9 Missing statement about partial_bytes_acked update
2.9.1 Description of the problem 2.9.1 Description of the problem
Four basic problems have been discovered with the SCTP uses four control variables to regulate its transmission rate:
current heartbeat procedures. 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, having to be reset to 0.
o The current specification does not specify that you 2.9.2 Text changes to the document
should count a failed heartbeat as an error against the
overall association.
o The current specification is un-specific as to when ---------
you start sending heartbeats and when you should stop. Old text: (Section 7.2.3)
---------
o The current specification is un-specific as to when 7.2.3 Congestion Control
you should respond to heartbeats.
o When responding to a Heartbeat it is unclear what to Upon detection of packet losses from SACK (see Section 7.2.4), An
do if more than a single TLV is present. endpoint should do the following:
2.9.2 Text changes to the document 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, 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, having to be 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:
- The current specification does not specify that you should count a
failed heartbeat as an error against the overall association.
- The current specification is un-specific as to when you start
sending heartbeats and when you should stop.
- The current specification is un-specific as to when you should
respond to heartbeats.
- When responding to a Heartbeat it is unclear what to do if more
than a single TLV is present.
- 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) Old text: (Section 8.1)
--------- ---------
8.1 Endpoint Failure Detection 8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed). destination transport addresses of the peer if it is multi-homed).
If the value of this counter exceeds the limit indicated in the If the value of this counter exceeds the limit indicated in the
protocol parameter 'Association.Max.Retrans', the endpoint shall protocol parameter 'Association.Max.Retrans', the endpoint shall
consider the peer endpoint unreachable and shall stop transmitting consider the peer endpoint unreachable and shall stop transmitting
any more data to it (and thus the association enters the CLOSED any more data to it (and thus the association enters the CLOSED
state). In addition, the endpoint shall report the failure to the state). In addition, the endpoint shall report the failure to the
upper layer, and optionally report back all outstanding user data upper layer, and optionally report back all outstanding user data
remaining in its outbound queue. The association is automatically remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable. closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer The counter shall be reset each time a DATA chunk sent to that peer
skipping to change at page 17, line 55 skipping to change at page 19, line 21
remaining in its outbound queue. The association is automatically remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable. closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer 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 endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint. HEARTBEAT-ACK is received from the peer endpoint.
--------- ---------
New text: (Section 8.1) New text: (Section 8.1)
--------- ---------
8.1 Endpoint Failure Detection 8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (this includes retransmissions to all the retransmissions to its peer (this includes retransmissions to all the
destination transport addresses of the peer if it is multi-homed), destination transport addresses of the peer if it is multi-homed),
including unacknowledged HEARTBEAT Chunks. If the value of this including unacknowledged HEARTBEAT Chunks. If the value of this
counter exceeds the limit indicated in the protocol parameter counter exceeds the limit indicated in the protocol parameter
'Association.Max.Retrans', the endpoint shall consider the peer 'Association.Max.Retrans', the endpoint shall consider the peer
endpoint unreachable and shall stop transmitting any more data to it endpoint unreachable and shall stop transmitting any more data to it
(and thus the association enters the CLOSED state). In addition, (and thus the association enters the CLOSED state). In addition, the
the endpoint shall report the failure to the upper layer, and endpoint shall report the failure to the upper layer, and optionally
optionally report back all outstanding user data remaining in its report back all outstanding user data remaining in its outbound
outbound queue. The association is automatically closed when the queue. The association is automatically closed when the peer
peer endpoint becomes unreachable. endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer 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 endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint. HEARTBEAT-ACK is received from the peer endpoint.
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
--------- ---------
8.3 Path Heartbeat 8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). address(es).
--------- ---------
New text: (Section 8.3) New text: (Section 8.3)
--------- ---------
skipping to change at page 18, line 34 skipping to change at page 19, line 55
8.3 Path Heartbeat 8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). address(es).
--------- ---------
New text: (Section 8.3) New text: (Section 8.3)
--------- ---------
8.3 Path Heartbeat 8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). HEARTBEAT sending MAY begin upon reaching the address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state, and is discontinued after sending either ESTABLISHED state, and is discontinued after sending either SHUTDOWN
SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
respond to a HEARTBEAT with a HEARTBEAT-ACK after entering HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-SENT state
the COOKIE-SENT state (INIT sender) or the ESTABLISHED (INIT sender) or the ESTABLISHED state (INIT receiver), up until
state (INIT receiver), up until reaching the SHUTDOWN-SENT reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the
state (SHUTDOWN sender) of the SHUTDOWN-ACK-SENT state SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
(SHUTDOWN receiver).
--------- ---------
Old text: (Section 8.3): Old text: (Section 8.3)
--------- ---------
The receiver of the HEARTBEAT should immediately respond with a The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information field copied HEARTBEAT ACK that contains the Heartbeat Information field copied
from the received HEARTBEAT chunk. from the received HEARTBEAT chunk.
--------- ---------
New text: (Section 8.3): New text: (Section 8.3)
--------- ---------
The receiver of the HEARTBEAT should immediately respond with a The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information TLV, together HEARTBEAT ACK that contains the Heartbeat Information TLV, together
with any other received TLVs, copied unchanged from the received with any other received TLVs, copied unchanged from the received
HEARTBEAT chunk. HEARTBEAT chunk.
2.9.3 Solution description ---------
Old text: (Section 8.3)
---------
The above text provides guidance as to how to respond to the On an idle destination address that is allowed to heartbeat, a
four issues mentioned in 2.10.1. In particular the wording HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
changes provide guidance as to when to start and stop heart beating, destination address plus the protocol parameter 'HB.interval' , with
how to respond to a heartbeat with extra parameters, and clarifies jittering of +/- 50%, and exponential back-off of the RTO if the
the error counting procedures for the association. previous HEARTBEAT is unanswered.
2.10 Security interactions with firewalls ---------
New text: (Section 8.3)
---------
2.10.1 Description of the problem 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% of the RTO value, and exponential back-off
of the RTO if the previous HEARTBEAT is unanswered.
When dealing with firewalls it is advantageous to the firewall 2.10.3 Solution description
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.10.2 Text changes to the document The above text provides guidance as to how to respond to the five
issues mentioned in 2.10.1. In particular the wording changes provide
guidance as to when to start and stop heartbeating, how to respond to
a heartbeat with extra parameters, and 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 to 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) New text: (no old text, new section added)
--------- ---------
11.4 SCTP interactions with firewalls 11.4 SCTP interactions with firewalls
Per [RFC1858], it is helpful for some firewalls if they can inspect Per [RFC1858], it is helpful for some firewalls if they can inspect
just the first fragment of a fragmented SCTP packet and just the first fragment of a fragmented SCTP packet and unambiguously
unambiguously determine whether it corresponds to an INIT chunk. determine whether it corresponds to an INIT chunk. Accordingly, we
Accordingly, we stress the requirements stated in 3.1 that (1) an stress the requirements stated in 3.1 that (1) an INIT chunk MUST NOT
INIT chunk MUST NOT be bundled with any other chunk in a packet, and be bundled with any other chunk in a packet, and (2) a packet
(2) a packet containing an INIT chunk MUST have a zero Verification containing an INIT chunk MUST have a zero Verification Tag.
Tag. Furthermore, we require that the receiver of an INIT chunk Furthermore, we require that the receiver of an INIT chunk MUST
MUST enforce these rules by silently discarding an arriving packet enforce these rules by silently discarding an arriving packet with an
with an INIT chunk that is bundled with other chunks. INIT chunk that is bundled with other chunks.
2.11 Shutdown ambiguity ---------
Old text: (Section 17)
---------
2.11.1 Description of the problem 17. References
Currently there is an ambiguity between the statements in [RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC
section 6.2 and section 9.2. Section 6.2 allows the sending 768, August 1980.
of a SHUTDOWN chunk in place of a SACK when the sender
is in the process of shutting down. Section 9.2 which
requires a SHUTDOWN chunk and a SACK chunk to be sent.
Along with this ambiguity there is a problem where in [RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7,
a errant SHUTDOWN reciever may fail to stop accepting RFC 793, September 1981.
user data.
2.11.2 Text changes to the document [RFC1123] Braden, R., "Requirements for Internet hosts - application
and support", STD 3, RFC 1123, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
---------
New text: (Section 17)
---------
17. References
[RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC
768, August 1980.
[RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1123] Braden, R., "Requirements for Internet hosts - application
and support", STD 3, RFC 1123, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
2.11.3 Solution description
The above text adding a new subsection to the Security Considerations
section of RFC 2960 makes clear that, to make easier the interaction
with firewalls, an INIT chunk must not be bundled in any case with
any other chunk, being this rule enforced by the packet receiver,
that will silently discard the packets that do not follow this rule.
2.12 Shutdown ambiguity
2.12.1 Description of the problem
Currently there is an ambiguity between the statements in section 6.2
and section 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 both a SHUTDOWN chunk and a SACK
chunk to be sent.
Along with this ambiguity there is a problem where in an errant
SHUTDOWN receiver may fail to stop accepting user data.
2.12.2 Text changes to the document
--------- ---------
Old text: (Section 9.2) Old text: (Section 9.2)
--------- ---------
If there are still outstanding DATA chunks left, the SHUTDOWN If there are still outstanding DATA chunks left, the SHUTDOWN
receiver shall continue to follow normal data transmission procedures receiver shall continue to follow normal data transmission procedures
defined in Section 6 until all outstanding DATA chunks are defined in Section 6 until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user. from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunk(s) 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 with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
it has no more outstanding DATA chunks, the SHUTDOWN receiver shall it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
skipping to change at page 20, line 40 skipping to change at page 23, line 33
--------- ---------
If there are still outstanding DATA chunks left, the SHUTDOWN If there are still outstanding DATA chunks left, the SHUTDOWN
receiver shall continue to follow normal data transmission procedures receiver shall continue to follow normal data transmission procedures
defined in Section 6 until all outstanding DATA chunks are defined in Section 6 until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user. from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunk(s) respond to each received packet containing one or more DATA chunk(s)
with a SHUTDOWN chunk, and restart the T2-shutdown timer. If with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a
a SHUTDOWN chunk by itself cannot acknowledge all of the received SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
DATA chunks (i.e. there are TSN's that can be acknowledged that are chunks (i.e. there are TSN's that can be acknowledged that are larger
larger than the cumulative TSN and thus gaps exist in the than the cumulative TSN and thus gaps exist in the TSN sequence) then
TNS sequence) then a SACK chunk MUST also be sent. a SACK chunk MUST also be sent.
The sender of the SHUTDOWN MAY also start an overall guard timer The sender of the SHUTDOWN MAY also start an overall guard timer
'T5-shutdown-guard' to bound the overall time for shutdown sequence. 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
At the expiration of this timer the sender SHOULD abort the At the expiration of this timer the sender SHOULD abort the
association by sending an ABORT chunk. If the 'T5-shutdown-guard' 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 timer is used, it SHOULD be set to the recommended value of 5 times
'RTO.Max'. 'RTO.Max'.
If it the receiver of the SHUTDOWN has no more outstanding DATA If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a
T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.
If the timer expires, the endpoint must re-send the SHUTDOWN ACK. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
2.11.3 Solution description 2.12.3 Solution description
The above text clearifies the use of a SACK in conjunction with
a SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown 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. sequence to protect against errant receivers of SHUTDOWN chunks.
2.12 Inconsistency in ABORT processing 2.13 Inconsistency in ABORT processing
2.12.1 Description of the problem 2.13.1 Description of the problem
It was noted that the wording in section 8.5.1 did not give It was noted that the wording in section 8.5.1 did not give proper
proper directions in the use of the 'T bit' with the directions in the use of the 'T bit' with the verification tags.
verification tags.
2.12.2 Text changes to the document 2.13.2 Text changes to the document
--------- ---------
Old text (section 8.5.1) Old text: (Section 8.5.1)
--------- ---------
B) Rules for packet carrying ABORT: B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field of - The endpoint shall always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value the outbound packet with the destination endpoint's tag value
if it is known. if it is known.
- If the ABORT is sent in response to an OOTB packet, the - If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4. endpoint MUST follow the procedure described in Section 8.4.
- The receiver MUST accept the packet if the Verification Tag - The receiver MUST accept the packet if the Verification Tag
matches either its own tag, OR the tag of its peer. Otherwise, matches either its own tag, OR the tag of its peer. Otherwise,
the receiver MUST silently discard the packet and take no the receiver MUST silently discard the packet and take no
further action. further action.
--------- ---------
New text: (section 8.5.1) New text: (Section 8.5.1)
--------- ---------
B) Rules for packet carrying ABORT: B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field of - The endpoint shall always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value the outbound packet with the destination endpoint's tag value
if it is known. if it is known.
- If the ABORT is sent in response to an OOTB packet, the - If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4. endpoint MUST follow the procedure described in Section 8.4.
- The receiver of a ABORT shall accept the packet if - The receiver of a ABORT shall accept the packet if the
the Verification Tag field of the packet matches its own tag OR Verification Tag field of the packet matches its own tag OR it
it is set to its peer's tag and the T bit is set in the Chunk 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 Flags. Otherwise, the receiver MUST silently discard the packet
and take no further action. and take no further action.
2.12.3 Solution description 2.13.3 Solution description
The above text change clearifies that the T bit must be set The above text change clarifies that the T bit must be set before an
before an implementation looks for the peers tag. implementation looks for the peers tag.
2.14 Cwnd gated by its full use in Slow start
2.14.1 Description of the problem
The current wording in section 7.2.1 requires that the cwnd only
be increased if all of the cwnd is being used. The current wording
however is weak and is not cleary defined.
2.14.2 Text changes to the document
---------
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 and an
incoming SACK advances the Cumulative TSN Ack Point. Only when
these two conditions are met can the cwnd be increased otherwise
the cwnd MUST not be increased. If these conditions are met then
cwnd MUST be increased by at most the lesser of 1) the total
size of the previously outstanding DATA chunk(s) acknowledged,
and 2) the destination's path MTU. This protects against the
ACK-Splitting attack outlined in [SAVAGE99].
2.14.3 Solution description
The above change to the paragraph strengths the rules and makes
it much more apparent as to the need to block cwnd growth when
the full cwnd is not being utilized.
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
clearification.
2.15.2 Text changes to the document
---------
Old text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the reception of each valid
DATA chunk.
---------
New text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the reception of each valid
DATA chunk even if the DATA chunk received is outside its receive
window.
Note: When the receiver's advertised window is 0, the receiver MUST
drop all new incoming DATA chunk and immediately send back a SACK
with the current receive window and showing only DATA chunks received
and accepted so far. The dropped DATA chunk 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. Because of receiver SWS
avoidance, even when the receiver's internal buffer is not full anymore,
as long as the advertised window is still 0, the receiver MUST still drop
all new incoming DATA chunk.
---------
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.
---------
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 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 zero window probe SHOULD only be sent
when all outstanding DATA chunks have been cumulatively acknowledged
and no DATA chunk(s) are in flight. Zero window probing MUST
be supported.
When a sender is doing zero window probing, it should not time
out the association if it continues to receive new packets from
the receiver. The reason is that 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 algorithm in 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.
3. Acknowledgments 3. Acknowledgments
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided comments and input for this document: provided comments and input for this document:
For their comments on the list, Atsushi Fukumoto. For their comments on the list, Atsushi Fukumoto.
For their participation in the RTP Bakeoff number 2 and all of their For their participation in the RTP Bakeoff number 2 and all of their
input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj
Manoj Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon
Glaude, Jon Berger, Dan Harrison, Sabina Torrente, Tomas Ort¨ Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin,
Mart¨n, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson,
Robinson, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa Campbell,
Melissa Campbell, Sujith Radhakrishnan, Michael Tuexen, Andreas Sujith Radhakrishnan, Michael Tuexen, Andreas Jungmaier, Mitch Miers,
Jungmaier, Mitch Miers, Fred Hasle, Oliver Mayor, Cliff Thomas, Fred Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood,
Jonathan Wood, Kacheong Poon, Sverre Slotte, Wang Xiaopeng, Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep
John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep
Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel, Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll,
Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian Gareth Keily, Ian Periam, Nathalie Mouellic, and Stan McClellan.
Periam, Nathalie Mouellic, and Stan McClellan.
For their comments on the list and his detailed analysis and For their comments on the list and his detailed analysis and
simulations of SCTP. simulations of SCTP, Rob Brennan and Thomas Curran.
Rob Brennan and Thomas Curran.
4. Authors' Addresses 4. Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems Inc. Cisco Systems Inc.
24 Burning Bush Trail. 24 Burning Bush Trail.
Crystal Lake, IL 60012 Crystal Lake, IL 60012
USA USA
EMail: rrs@cisco.com EMail: rrs@cisco.com
Lyndon Ong Lyndon Ong
Ciena Systems Ciena Systems
10480 Ridgeview Ct 10480 Ridgeview Ct
Cupertino, CA 95014 Cupertino, CA 95014
USA
EMail: lyong@ciena.com EMail: lyong@ciena.com
Ivan Arias Rodriguez Tel: +358-50-483-9494 Ivan Arias-Rodriguez
Nokia Research Center EMail: ivan.arias-rodriguez@nokia.com Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
EMail: ivan.arias-rodriguez@nokia.com
Kacheong Poon
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
USA
Email: kacheong.poon@sun.com
5. References 5. References
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J.
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
and, V. Paxson, "Stream Control Transmission Protocol," RFC and V. Paxson, "Stream Control Transmission Protocol,"
2960, October 2000. RFC 2960, October 2000.
6. Bibliography
[RFC1858] G. Ziemba, D. Reed, P. Traina, "Security Considerations
for IP Fragment Filtering.", RFC 1858, October 1995.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/