| draft-ietf-tsvwg-sctpimpguide-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-tsvwg-sctpimpguide-00.txt.
Network Working Group R. Stewart
Request for Comments: 2960 Cisco Systems
Category: Internet Draft L. Ong
Ciena Systems
June 8 2001
SCTP Implementors Guide
draft-ietf-tsvwg-sctpimpguide-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document contains a compilation of all defects found up until
June 2001 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be
used in the implementation of SCTP to clearify errors in the
original SCTP document.
This document updates RFC2960 and text within this document
supersedes the text found in RFC2960.
Table of Contents
1. Introduction......................................... 2
1.1 Conventions....................................... 2
2. Corrections to RFC2960............................... 2
2.1 Incorrect error type during chunk processing....... 2
2.2 Parameter processing issue......................... 3
Stewart&Ong [Page 1]
Internet Draft SCTP Implementors Guide June 2001
2.3 Padding issues.................................... 4
2.4 Parameter types across all chunk type.............. 5
2.5 Stream parameter clarification..................... 6
2.6 Restarting association security issue.............. 8
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....10
2.8 Issues with Fast Retransmit........................11
2.9 Issues with Heartbeating and failure detection.....14
2.10 Security interactions with firewalls..............16
3. Acknowledgments......................................17
4. Authors' Addresse....................................17
5. References...........................................18
6. Bibliography.........................................18
1. Introduction
This document contains a compilation of all defects found up until
May 2001 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be
used in the implementation of SCTP.
This document updates RFC2960 and text within this document, where
noted, supersedes the text found in RFC2960. Each error will
be detailed within this document in the form of:
- The problem description,
- The text quoted from RFC2960,
- The replacement text,
- A description of the solution.
1.1 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[RFC2119].
2.0 Corrections to RFC2960
2.1 Incorrect error type during chunk processing.
2.1.1 Description of the problem
A typo was discovered in [RFC2960] that incorrectly specifies
an action to be taken when processing chunks of unknown identity.
2.1.2 Text changes to the document
---------
Old text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process
Stewart&Ong [Page 2]
Internet Draft SCTP Implementors Guide June 2001
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
---------
New text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Chunk Type' (in either an
ERROR or in the INIT ACK).
2.1.3 Solution description
The receiver of an unrecognized Chunk should not send a
'parameter' error but instead the appropriate chunk error
as described above.
2.2 Parameter processing issue
2.2.1 Description of the problem
A typographical error was introduced through an improper cut
and paste in the use of the upper two bits to describe proper
handling of unknown parameters.
2.2.2 Text changes to the document
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunks, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
Stewart&Ong [Page 3]
Internet Draft SCTP Implementors Guide June 2001
2.2.3 Solution description
It was always the intent to stop processing at the level one
was at in an unknown chunk or parameter with the upper bit
set to 0. Thus if you are processing a chunk, you should drop
the packet. If you are processing a parameter, you should
drop the chunk.
2.3 Padding issues
2.3.1 Description of the problem
A problem was found in that when a Chunk was composed of
only TLV parameters. If the last TLV was not on an even
4 byte boundary, there was confusion as to if the last
padding was included in the chunk length.
2.3.2 Text changes to the document
---------
Old text: (Section 3.2)
---------
Chunk Value: variable length
The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields)
MUST be a multiple of 4 bytes. If the length of the chunk is not a
multiple of 4 bytes, the sender MUST pad the chunk with all zero
bytes and this padding is not included in the chunk length field.
The sender should never pad with more than 3 bytes. The receiver
MUST ignore the padding bytes.
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)
---------
Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
padding.
Stewart&Ong [Page 4]
Internet Draft SCTP Implementors Guide June 2001
Chunks (including Type, Length and Value fields) are padded out
by the sender with all zero bytes to be a multiple of 4 bytes
long. This padding MUST NOT be more than 3 bytes in total.
The Chunk Length value does not include terminating padding
of the Chunk. However, it does include padding of any variable
length parameter except the last parameter in the Chunk. The
receiver MUST ignore the padding.
Note: A robust implementation should accept the Chunk whether
or not the final padding has been included in the Chunk Length.
2.3.3 Solution description
The above text makes clear that the padding is neither included
in the chunk length or parameter length in such a case.
2.4 Parameter types across all chunk types
2.4.1 Description of the problem
A problem was noted when multiple errors are needed
to be sent regarding unknown or unrecognized parameters.
Since often times the error type does not hold the chunk
type field, it may becomes difficult to tell which error
was associated with which chunk.
2.4.2 Text changes to the document
---------
Old text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2.
---------
New text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2. Note that a parameter value MUST be unique
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
is reserved across all chunks to represent an IPv4 address and
MUST NOT be reused with a different meaning in any other chunk.
---------
Old text:
---------
Stewart&Ong [Page 5]
Internet Draft SCTP Implementors Guide June 2001
13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information:
a) Name of the parameter type.
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.1.
c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
---------
New text:
---------
13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information:
a) Name of the parameter type.
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.1.
c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
e) Each parameter type MUST be unique across all chunks.
2.4.3 Solution description
By having all parameters unique across all chunk assignments
(the current assignment policy) no ambiguity exists as to
what a parameter means based on context. The trade off for
this is a smaller parameter space i.e. 65,535 parameters
versus 65,535 * Number-of-chunks.
2.5 Stream parameter clarification
Stewart&Ong [Page 6]
Internet Draft SCTP Implementors Guide June 2001
2.5.1 Description of the problem
A problem was found where the specification is unclear
on the legality of an endpoint asking for more stream
resources then were allowed in the OS value of the INIT.
In particular the value in the INIT-ACK requested in
its MIS value was larger than the OS value received in
the INIT chunk. This behavior is illegal yet it was
unspecified in [RFC2960].
2.5.2 Text changes to the document
---------
Old 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
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
instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details.
Note: A receiver of an INIT ACK with the MIS value set to 0
SHOULD destroy the association discarding its TCB.
---------
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
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
instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details. The Number of Inbound Streams
sent in the INIT-ACK MUST NOT be greater than the value found
in the number of outbound streams received in the INIT.
Note: A receiver of an INIT ACK with the MIS value set to 0
SHOULD destroy the association discarding its TCB.
2.5.3 Solution description
Stewart&Ong [Page 7]
Internet Draft SCTP Implementors Guide June 2001
The change in wording, above, changes it so that a responder
to an INIT chunk does not specify more streams in it's
MIS value then was represented to it in the OS value i.e.
its maximum.
2.6 Restarting association security issue
2.6.1 Description of the problem
A security problem was found when a restart occurs. It is
possible for an intruder to send an INIT to an endpoint
of an existing association. In the INIT the intruder would
list all of the current addresses of an association and
its own. The normal restart procedures would then occur
and the intruder would have hi-jacked an association.
2.6.2 Text changes to the document
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text:
---------
Cause Code
Stewart&Ong [Page 8]
Internet Draft SCTP Implementors Guide June 2001
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an association with new addresses
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note no old text, new error added)
---------
3.3.10.11 Restart of an association with new addresses (11)
Cause of error
--------------
Restart of an association with new addresses: A COOKIE ECHO was
received on an existing association. But the COOKIE ECHO added
addresses to the association that were previously NOT part
of the association. The New addresses are listed in the
error code. This ERROR is normally sent as part of an ABORT
refusing the Cookie Echo (see section 5.2.4).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------
Old text: (Section 5.2.4)
---------
All the congestion control parameters (e.g., cwnd, ssthresh)
Stewart&Ong [Page 9]
Internet Draft SCTP Implementors Guide June 2001
related to this peer MUST be reset to their initial values (see
Section 6.2.1).
After this the endpoint shall enter the ESTABLISHED state.
---------
New text: (Section 5.2.4)
---------
All the congestion control parameters (e.g., cwnd, ssthresh)
related to this peer MUST be reset to their initial values (see
Section 6.2.1).
If the cookie indicates that a new address(es) have been added
to a restarting association, then the entire cookie MUST be discarded.
An ABORT MUST be sent that SHOULD include the error 'restart
of an association with new addresses'. The error SHOULD list the
addresses that were added to the restarting association.
This error should also list the TLV(s) with the new address(es)
that was/were not present in the old association. This would allow
a true restarting association to go through a recovery procedure
(if it desired) to bring back the association.
After this the endpoint shall enter the ESTABLISHED state.
2.6.3 Solution description
A new error code is being added and specific instructions
to send back an ABORT to a new association in a restart
case where new addresses have been added. The error code
can be used by a legitimate restart to inform the endpoint
that it has made a software error in adding a new address.
The endpoint then can choose to wait until the OOTB ABORT
tears down the old association, or restart without the
new address.
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes
2.7.1 Description of the problem
Some implementations were having difficulty growing there
cwnd. This was due to an improper enforcement of the congestion
control rules. The rules, as written, provided for a slop
over of the cwnd value. Without this slop over the sender
would appear to NOT be using its full cwnd value and thus
never increase it.
2.7.2 Text changes to the document
---------
Old text: (Section 6.1)
Stewart&Ong [Page 10]
Internet Draft SCTP Implementors Guide June 2001
---------
B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data
outstanding to that transport address.
---------
New text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data
outstanding to that transport address. The sender may exceed
cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd
is not currently exceeded.
2.7.3 Solution description
The text changes make clear the ability to go over the cwnd value
by no more than (PMTU-1) bytes.
2.8 Issues with Fast Retransmit
2.8.1 Description of the problem
A problem was found in the current specification of fast retransmit.
In particular in a high bandwidth * delay network. The current wording
did require GAP ACK blocks to be sent, even though they are essential
to the workings of SCTP's congestion control. Also the specification
left unclear how to handle the fast retransmit cycle. Waiting to
retransmit a TSN needing fast retransmit. Also no limit was placed
on how many times a TSN could be fast retransmitted. When recovering
from a 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
---------
Old text: (Section 6.2)
---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an
acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN
greater than the value in the Cumulative TSN Ack field SHOULD also be
reported in the Gap Ack Block fields.
---------
Stewart&Ong [Page 11]
Internet Draft SCTP Implementors Guide June 2001
New text: (Section 6.2)
---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an
acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN
greater than the value in the Cumulative TSN Ack field MUST also be
reported in the Gap Ack Block fields.
---------
Old text: (Section 7.2.4)
---------
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
---------
New text: (Section 7.2.4)
---------
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. When a Fast Retransmit
is being performed the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission.
Stewart&Ong [Page 12]
Internet Draft SCTP Implementors Guide June 2001
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit until after the
T3-rxt timer expires.
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
Upon acknowledgment of a DATA chunk that has been fast retransmitted,
the protocol parameter 'Max.Burst' MUST be applied to limit
how many SCTP packets may be sent upon the completion of SACK
processing.
---------
Old text:
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
---------
New text:
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Stewart&Ong [Page 13]
Internet Draft SCTP Implementors Guide June 2001
Max.Burst - 4 packets
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
2.8.3 Solution description
The effect of the above wording changes is four-fold:
- It requires with a MUST the sending of GAP Ack blocks
instead of the current [RFC2960] SHOULD.
- It allows a TSN being Fast Retransmitted (FR) to be sent
only once via FR until a subsequent timer expiration.
- It ends the delay in awaiting for the flight size to
drop when a TSN is identified ready to FR.
- It applies a Max.Burst parameter to prevent a FR from
flooding the network with packets after rwnd has been
clamped to '0' for a period of time.
These changes will effectively allow SCTP to follow
the same model as TCP in the handling of Fast Retransmit.
2.9 Issues with Heartbeating and failure detection
2.9.1 Description of the problem
Four basic problems have been discovered with the
current heartbeat procedures.
o The current specification does not specify that you
should count a failed heartbeat as an error against the
overall association.
o The current specification is un-specific as to when
you start sending heartbeats and when you should stop.
o The current specification is un-specific as to when
you should respond to heartbeats.
o When responding to a Heartbeat it is unclear what to
do if more than a single TLV is present.
2.9.2 Text changes to the document
---------
Old text:
Stewart&Ong [Page 14]
Internet Draft SCTP Implementors Guide June 2001
---------
8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed).
If the value of this counter exceeds the limit indicated in the
protocol parameter 'Association.Max.Retrans', the endpoint shall
consider the peer endpoint unreachable and shall stop transmitting
any more data to it (and thus the association enters the CLOSED
state). In addition, the endpoint shall report the failure to the
upper layer, and optionally report back all outstanding user data
remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint.
---------
New text:
---------
8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed,
and unacknowledged HEARTBEAT Chunks). If the value of this counter
exceeds the limit indicated in the protocol parameter
'Association.Max.Retrans', the endpoint shall consider the peer
endpoint unreachable and shall stop transmitting any more data to it
(and thus the association enters the CLOSED state). In addition,
the endpoint shall report the failure to the upper layer, and
optionally report back all outstanding user data remaining in its
outbound queue. The association is automatically closed when the
peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint.
---------
Old text:
---------
8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport
address(es).
---------
New text:
---------
Stewart&Ong [Page 15]
Internet Draft SCTP Implementors Guide June 2001
8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport
address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state, and is discontinued after sending either
SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST
respond to a HEARTBEAT with a HEARTBEAT-ACK after entering
the COOKIE-SENT state up until reaching the CLOSED state.
---------
Old text: (Section 8.3):
---------
The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information field copied
from the received HEARTBEAT chunk.
---------
New text: (Section 8.3):
---------
The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information TLV, together
with any other received TLVs, copied unchanged from the received
HEARTBEAT chunk.
2.9.3 Solution description
The above text provides guidance as to how to respond to the
four issues mentioned in 2.10.1. In particular the wording
changes provide guidance as to when to start and stop heart beating,
how to respond to a heartbeat with extra parameters, and clarifies
the error counting procedures for the association.
2.10 Security interactions with firewalls
2.10.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 added to SCTP's security section.
2.10.2 Text changes to the document
---------
New text: (no old text, new section added)
---------
11.4 SCTP interactions with firewalls
Per [RFC1858], it is helpful for some firewalls if they can inspect
Stewart&Ong [Page 16]
Internet Draft SCTP Implementors Guide June 2001
just the first fragment of a fragmented SCTP packet and
unambiguously determine whether it corresponds to an INIT chunk.
Accordingly, we stress the requirements stated in 3.1 that (1) an
INIT chunk MUST NOT be bundled with any other chunk in a packet, and
(2) a packet containing an INIT chunk MUST have a zero Verification
Tag. Furthermore, we require that the receiver of an INIT chunk
MUST enforce these rules by silently discarding an arriving packet
with an INIT chunk that is bundled with other chunks.
3. Acknowledgments
The authors would like to thank the following people that have
provided comments and input for this document:
For their comments on the list, Atsushi Fukumoto.
For their participation in the RTP Bakeoff number 2 and all of their
input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss,
Manoj Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent
Glaude, Jon Berger, Dan Harrison, Sabina Torrente, Tomas Ort�
Mart�n, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben
Robinson, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan,
Melissa Campbell, Sujith Radhakrishnan, Michael Tuexen, Andreas
Jungmaier, Mitch Miers, Fred Hasle, Oliver Mayor, Cliff Thomas,
Jonathan Wood, Kacheong Poon, Sverre Slotte, Wang Xiaopeng, Ivan
Rodriguez, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee,
Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel,
Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian
Periam, Nathalie Mouellic, and Stan McClellan.
For their comments on the list and his detailed analysis and
simulations of SCTP.
Rob Brennan and Thomas Curran.
4. Authors' Addresses
Randall R. Stewart
Cisco Systems Inc.
24 Burning Bush Trail.
Crystal Lake, IL 60012
USA
EMail: [email protected]
Lyndon Ong
Ciena Systems
10480 Ridgeview Ct
Cupertino, CA 95014
EMail: [email protected]
Stewart&Ong [Page 17]
Internet Draft SCTP Implementors Guide June 2001
5. References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
and, V. Paxson, "Stream Control Transmission Protocol," 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
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stewart&Ong [Page 18]
| ||||||||||||||||
| Last modified: Wed, 27 Nov 2024 19:34:41 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||