The description given in Section 3.3.11 of RFC 2960 [5] is unclear as
to how the COOKIE-ECHO is composed.
2.43.2. Text Changes to the Document
---------
Old text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible
to insure interoperability.
---------
New text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible
to ensure interoperability.
Note: A Cookie Echo does NOT contain a State Cookie
Parameter; instead, the data within the State Cookie’s
Parameter Value becomes the data within the Cookie Echo’s
Chunk Value. This allows an implementation to change only
the first two bytes of the State Cookie parameter to become
a Cookie Echo Chunk.
2.43.3. Solution Description
The new text adds a note that helps clarify that a Cookie Echo chunk
is nothing more than the State Cookie parameter with only two bytes
modified.
2.44. Partial Chunks
2.44.1. Description of the Problem
Section 6.10 of RFC 2960 [5] uses the notion of ’partial chunks’
without defining it.
2.44.2. Text Changes to the Document
---------
Old text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet.
---------
New text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet. A partial
chunk is a chunk that is not completely contained in the SCTP
packet; i.e., the SCTP packet is too short to contain all the bytes
of the chunk as indicated by the chunk length.
2.44.3. Solution Description
The new text adds a definition of ’partial chunks’.
2.45. Non-unicast Addresses
2.45.1. Description of the Problem
Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all
non-unicast addresses. This leaves future use of anycast addresses
in question. With the addition of the add-ip feature, SCTP should be
able to easily handle anycast INIT s that can be followed, after
association setup, with a delete of the anycast address from the
association.
2.45.2. Text Changes to the Document
---------
Old text: (Section 8.4)
---------
8.4 Handle "Out of the blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if
it is correctly formed, i.e., passed the receiver’s Adler-32
check (see Section 6.8), but the receiver is not able to
identify the association to which this packet belongs.
The receiver of an OOTB packet MUST do the following:
1) If the OOTB packet is to or from a non-unicast address,
silently discard the packet. Otherwise,
---------
New text: (Section 8.4)
---------
8.4. Handle "Out of the Blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if
it is correctly formed (i.e., passed the receiver’s CRC32c
check; see Section 6.8), but the receiver is not able to identify
the association to which this packet belongs.
The receiver of an OOTB packet MUST do the following:
1) If the OOTB packet is to or from a non-unicast address, a
receiver SHOULD silently discard the packet. Otherwise,
2.45.3. Solution Description
The loosening of the wording to a SHOULD will now allow future use of
anycast addresses. Note that no changes are made to Section
11.2.4.1, since responding to broadcast addresses could lead to
flooding attacks and implementors should pay careful attention to
these words.
2.46. Processing of ABORT Chunks
2.46.1. Description of the Problem
Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently
discard ABORT chunks received for associations that do not exist. It
is not clear what this means in the COOKIE-WAIT state, for example.
Therefore, it was not clear whether an ABORT sent in response to an
INIT should be processed or silently discarded.
2.46.2. Text Changes to the Document
---------
Old text: (Section 3.3.7)
---------
If an endpoint receives an ABORT with a format error or for an
association that doesn’t exist, it MUST silently discard it.
---------
New text: (Section 3.3.7)
---------
If an endpoint receives an ABORT with a format error or no
TCB is found, it MUST silently discard it.
2.46.3. Solution Description
It is now clearly stated that an ABORT chunk should be processed
whenever a TCB is found.
2.47. Sending of ABORT Chunks
2.47.1. Description of the Problem
Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in
response to an INIT chunk when there is no listening end point. To
make port scanning harder, someone might not want these ABORTs to be
received by the sender of the INIT chunks. Currently, the only way
to enforce this is by using a firewall that discards the packets
containing the INIT chunks or the packets containing the ABORT
chunks. It is desirable that the same can be done without a middle
box.
2.47.2. Text Changes to the Document
---------
Old text: (Section 5.1)
---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
but decides not to establish the new association due to missing
mandatory parameters in the received INIT or INIT ACK, invalid
parameter values, or lack of local resources, it MUST respond with
an ABORT chunk.
---------
New text: (Section 5.1)
---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
but decides not to establish the new association due to missing
mandatory parameters in the received INIT or INIT ACK, invalid
parameter values, or lack of local resources, it SHOULD respond
with an ABORT chunk.
2.47.3. Solution Description
The requirement of sending ABORT chunks is relaxed such that an
implementation can decide not to send ABORT chunks.
2.48. Handling of Supported Address Types Parameter
2.48.1. Description of the Problem
The sender of the INIT chunk can include a ’Supported Address Types’
parameter to indicate which address families are supported. It is
unclear how an INIT chunk should be processed where the source
address of the packet containing the INIT chunk or listed addresses
within the INIT chunk indicate that more address types are supported
than those listed in the ’Supported Address Types’ parameter.
2.48.2. Text Changes to the Document
The changes given here already include changes suggested in Section
2.28 of this document.
---------
Old text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type,
it can abort the initiation process and then attempt a
re-initiation by using a ’Supported Address Types’ parameter in
the new INIT to indicate what types of address it prefers.
---------
New text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type,
it can abort the initiation process and then attempt a re-
initiation by using a ’Supported Address Types’ parameter in the
new INIT to indicate what types of address it prefers.
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
ACK chunk from its peer, it MUST use all the addresses belonging
to the supported address family. The other addresses MAY be
ignored. The endpoint SHOULD NOT respond with any kind of error
indication.
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the ’Supported
Address Types’ parameter either IPv4 or IPv6, but uses the other
family for sending the packet containing the INIT chunk, or if it
also lists addresses of the other family in the INIT chunk, then
the address family that is not listed in the ’Supported Address
Types’ parameter SHOULD also be considered as supported by the
receiver of the INIT chunk. The receiver of the INIT chunk SHOULD
NOT respond with any kind of error indication.
2.48.3. Solution Description
It is now clearly described how these Supported Address Types
parameters with incorrect data should be handled.
2.49. Handling of Unexpected Parameters
2.49.1. Description of the Problem
RFC 2960 [5] clearly describes how unknown parameters in the INIT and
INIT-ACK chunk should be processed. But it is not described how
unexpected parameters should be processed. A parameter is unexpected
if it is known and is an optional parameter in either the INIT or
INIT-ACK chunk but is received in the chunk for which it is not an
optional parameter. For example, the ’Supported Address Types’
parameter would be an unexpected parameter if contained in an INIT-
ACK chunk.
2.49.2. Text Changes to the Document
---------
Old text: (Section 3.3.2)
---------
Note 4: This parameter, when present, specifies all the address
types the sending endpoint can support. The absence of this
parameter indicates that the sending endpoint can support any
address type.
---------
New text: (Section 3.3.2)
---------
Note 4: This parameter, when present, specifies all the address
types the sending endpoint can support. The absence of this
parameter indicates that the sending endpoint can support any
address type.
IMPLEMENTATION NOTE: If an INIT chunk is received with known
parameters that are not optional parameters of the INIT chunk
then the receiver SHOULD process the INIT chunk and send back
an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR
chunk with the COOKIE-ACK chunk later. However, restrictive
implementations MAY send back an ABORT chunk in response to
the INIT chunk.
---------
Old text: (Section 3.3.3)
---------
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
a INIT ACK that is quite large (more than 1500 bytes) due to the
variable size of the state cookie AND the variable address list.
For example if a responder to the INIT has 1000 IPv4 addresses
it wishes to send, it would need at least 8,000 bytes to encode
this in the INIT ACK.
---------
New text: (Section 3.3.3)
---------
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
a INIT ACK that is quite large (more than 1500 bytes) due to the
variable size of the state cookie AND the variable address list.
For example, if a responder to the INIT has 1000 IPv4 addresses
it wishes to send, it would need at least 8,000 bytes to encode
this in the INIT ACK.
IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known
parameters that are not optional parameters of the INIT-ACK
chunk, then the receiver SHOULD process the INIT-ACK chunk and
send back a COOKIE-ECHO. The receiver of the INIT-ACK chunk
MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. However,
restrictive implementations MAY send back an ABORT chunk in
response to the INIT-ACK chunk.
2.49.3. Solution Description
It is now stated how unexpected parameters should be processed.
2.50. Payload Protocol Identifier
2.50.1. Description of the Problem
The current description of the payload protocol identifier does NOT
highlight the fact that the field is NOT necessarily in network byte
order.
2.50.2. Text Changes to the Document
---------
Old text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by
SCTP but can be used by certain network entities as well as
the peer application to identify the type of information being
carried in this DATA chunk. This field must be sent even in
fragmented DATA chunks (to make sure it is available for agents
in the middle of the network).
The value 0 indicates no application identifier is specified by
the upper layer for this payload data.
---------
New text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by
SCTP but can be used by certain network entities, as well as by
the peer application, to identify the type of information being
carried in this DATA chunk. This field must be sent even in
fragmented DATA chunks (to make sure it is available for agents
in the middle of the network). Note that this field is NOT
touched by an SCTP implementation, therefore its byte order is
NOT necessarily Big Endian. The upper layer is responsible
for any byte order conversions to this field.
The value 0 indicates that no application identifier is
specified by the upper layer for this payload data.
2.50.3. Solution Description
It is now explicitly stated that the upper layer is responsible for
the byte order of this field.
2.51. Karn’s Algorithm
2.51.1. Description of the Problem
The current wording of the use of Karn’s algorithm is not descriptive
enough to ensure that an implementation in a multi-homed association
does not incorrectly mismeasure the RTT.
2.51.2. Text Changes to the Document
---------
Old text: (Section 6.3.1)
---------
C5) Karn’s algorithm: RTT measurements MUST NOT be made using
packets that were retransmitted (and thus for which it is
ambiguous whether the reply was for the first instance of the
packet or a later instance)
---------
New text: (Section 6.3.1)
---------
C5) Karn’s algorithm: RTT measurements MUST NOT be made using
chunks that were retransmitted (and thus for which it is
ambiguous whether the reply was for the first instance of
the chunk or for a later instance)
IMPLEMENTATION NOTE: RTT measurements should only be
made using a chunk with TSN r if no chunk
with TSN less than or equal to r is retransmitted
since r is first sent.
2.51.3. Solution Description
The above clarification adds an implementation note that will provide
additional guidance in the application of Karn’s algorithm.
2.52. Fast Retransmit Algorithm
2.52.1. Description of the Problem
The original SCTP specification is overly conservative in requiring 4
missing reports before fast retransmitting a segment. TCP uses 3
missing reports or 4 acknowledgements indicating that the same
segment was received.
2.52.2. Text Changes to the Document
---------
Old text:
---------
7.2.4 Fast Retransmit on Gap Reports
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in
the arriving TSN sequence, it SHOULD start sending a SACK back
every time a packet arrives carrying data until the
hole is filled.
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.
---------
New text:
---------
7.2.4. Fast Retransmit on Gap Reports
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in
the arriving TSN sequence, it SHOULD start sending a SACK back
every time a packet arrives carrying data until the
hole is filled.
Whenever an endpoint receives a SACK that indicates that some
TSNs are missing, it SHOULD wait for 2 further miss indications
(via subsequent SACKs for a total of 3 missing reports) on the
same TSNs before taking action with regard to Fast Retransmit.
2.52.3. Solution Description
The above changes will make SCTP and TCP behave similarly in terms of
how fast they engage the Fast Retransmission algorithm upon receiving
missing reports.
3. Security Considerations
This document should add no additional security risks to SCTP and in
fact SHOULD correct some original security flaws within the original
document once it is incorporated into a RFC 2960 [5] BIS document.
4. Acknowledgements
The authors would like to thank the following people who have
provided comments and input for this document:
Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng,
Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina
Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte,
Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC
Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel,
Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan,
Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann,
Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth
Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John
Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent
Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
A special thanks to Mark Allman, who should actually be a co-author
for his work on the max-burst, but managed to wiggle out due to a
technicality. Also, we would like to acknowledge Lyndon Ong and Phil
Conrad for their valuable input and many contributions.
5. IANA Considerations
This document recommends changes for the RFC 2960 [5] BIS document.
As such, even though it lists new error cause code, this document in
itself does NOT define those new codes. Instead, the BIS document
will make the needed changes to RFC 2960 [5] and thus its IANA
section will require changes to be made.
6. Normative References
[1] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP
and TCP Variants: Congestion Control Under Multiple Losses",
Technical Report TR2003-04, Computer and Information Sciences
Department, University of Delaware, February 2003,
<http://www.armandocaro.net/papers>.
[4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for
End-to-end Failover with Transport Layer Multihoming", GLOBECOM,
November 2004., <http://www.armandocaro.net/papers>.
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[6] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
Authors’ Addresses
Randall R. Stewart
Cisco Systems, Inc.
4875 Forest Drive
Suite 200
Columbia, SC 29206
USA
EMail: rrs@cisco.com
Ivan Arias-Rodriguez
Nokia Research Center
PO Box 407
FIN-00045 Nokia Group
Finland
EMail: ivan.arias-rodriguez@nokia.com
Kacheong Poon
Sun Microsystems, Inc.
3571 N. First St.
San Jose, CA 95134
USA
EMail: kacheong.poon@sun.com
Armando L. Caro Jr.
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
EMail: acaro@bbn.com
URI: http://www.armandocaro.net
Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany
EMail: tuexen@fh-muenster.de
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).