draft-ietf-tsvwg-2960bis-04.txt   draft-ietf-tsvwg-2960bis-05.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Editor Internet-Draft Editor
Intended status: Standards Track April 5, 2007 Obsoletes: 2960,3309 June 12, 2007
Expires: October 7, 2007 (if approved)
Intended status: Standards Track
Expires: December 14, 2007
Stream Control Transmission Protocol Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-04.txt draft-ietf-tsvwg-2960bis-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as 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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on October 7, 2007. This Internet-Draft will expire on December 14, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document obsoletes RFC2960 [RFC2960] and describes the Stream This document obsoletes RFC2960 [RFC2960] and RFC3309 [RFC3309] it
Control Transmission Protocol (SCTP). SCTP is designed to transport describes the Stream Control Transmission Protocol (SCTP). SCTP is
PSTN signaling messages over IP networks, but is capable of broader designed to transport PSTN signaling messages over IP networks, but
applications. is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a SCTP is a reliable transport protocol operating on top of a
connectionless packet network such as IP. It offers the following connectionless packet network such as IP. It offers the following
services to its users: services to its users:
-- acknowledged error-free non-duplicated transfer of user data, -- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size, -- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with -- sequenced delivery of user messages within multiple streams, with
an option for order-of-arrival delivery of individual user an option for order-of-arrival delivery of individual user
messages, messages,
skipping to change at page 2, line 23 skipping to change at page 2, line 25
at either or both ends of an association. at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks. and resistance to flooding and masquerade attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Architectural View of SCTP . . . . . . . . . . . . . . . 6 1.2. Architectural View of SCTP . . . . . . . . . . . . . . . 6
1.3. Functional View of SCTP . . . . . . . . . . . . . . . . . 7 1.3. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. Association Startup and Takedown . . . . . . . . . . 8 1.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2. Sequenced Delivery within Streams . . . . . . . . . . 9 1.5. Functional View of SCTP . . . . . . . . . . . . . . . . . 11
1.3.3. User Data Fragmentation . . . . . . . . . . . . . . . 9 1.5.1. Association Startup and Takedown . . . . . . . . . . 12
1.3.4. Acknowledgement and Congestion Avoidance . . . . . . 9 1.5.2. Sequenced Delivery within Streams . . . . . . . . . . 13
1.3.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 10 1.5.3. User Data Fragmentation . . . . . . . . . . . . . . . 13
1.3.6. Packet Validation . . . . . . . . . . . . . . . . . . 10 1.5.4. Acknowledgement and Congestion Avoidance . . . . . . 13
1.3.7. Path Management . . . . . . . . . . . . . . . . . . . 10 1.5.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 14
1.4. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.6. Packet Validation . . . . . . . . . . . . . . . . . . 14
1.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 15 1.5.7. Path Management . . . . . . . . . . . . . . . . . . . 14
1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 15 1.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 15
1.7. Changes from RFC2960 . . . . . . . . . . . . . . . . . . 16 1.7. Changes from RFC2960 . . . . . . . . . . . . . . . . . . 16
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 16
3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 16 3. SCTP packet Format . . . . . . . . . . . . . . . . . . . . . 16
3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 17 3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 17
3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 18 3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 18
3.2.1. Optional/Variable-length Parameter Format . . . . . . 20 3.2.1. Optional/Variable-length Parameter Format . . . . . . 20
3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 22 3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 22
3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 23 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 23
3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 23 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 23
skipping to change at page 4, line 19 skipping to change at page 4, line 22
6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 90 6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 90
6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 91 6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 91
7. Congestion control . . . . . . . . . . . . . . . . . . . . . 92 7. Congestion control . . . . . . . . . . . . . . . . . . . . . 92
7.1. SCTP Differences from TCP Congestion control . . . . . . 93 7.1. SCTP Differences from TCP Congestion control . . . . . . 93
7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 94 7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 94
7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 95 7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 95
7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 96 7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 96
7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 97 7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 97
7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 97 7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 97
7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 99 7.3. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 99
8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 100 8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 99
8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 100 8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 99
8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 100 8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 100
8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 101 8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 101
8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 103 8.4. Handle "Out of the blue" Packets . . . . . . . . . . . . 103
8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 104 8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 104
8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 105 8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 104
9. Termination of Association . . . . . . . . . . . . . . . . . 106 9. Termination of Association . . . . . . . . . . . . . . . . . 105
9.1. Abort of an Association . . . . . . . . . . . . . . . . . 106 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 106
9.2. Shutdown of an Association . . . . . . . . . . . . . . . 107 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 106
10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 110 10. Interface with Upper Layer . . . . . . . . . . . . . . . . . 109
10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 110 10.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . . 109
10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 121 10.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . . 120
11. Security Considerations . . . . . . . . . . . . . . . . . . . 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 123
11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 124 11.1. Security Objectives . . . . . . . . . . . . . . . . . . . 123
11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 124 11.2. SCTP Responses To Potential Threats . . . . . . . . . . . 123
11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124
11.2.2. Protecting against Data Corruption in the Network . . 124 11.2.2. Protecting against Data Corruption in the Network . . 124
11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 125 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 124
11.2.4. Protecting against Blind Denial of Service Attacks . 125 11.2.4. Protecting against Blind Denial of Service Attacks . 125
11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 126 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 125
11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 127 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 126
11.2.4.3. Improper Monopolization of Services . . . . . . 128 11.2.4.3. Improper Monopolization of Services . . . . . . 127
11.3. Protection against Fraud and Repudiation . . . . . . . . 128 11.3. SCTP Interactions with Firewalls . . . . . . . . . . . . 127
11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 129 11.4. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 127
11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 129 12. Network Management Considerations . . . . . . . . . . . . . . 128
12. Network Management Considerations . . . . . . . . . . . . . . 130 13. Recommended Transmission Control Block (TCB) Parameters . . . 128
13. Recommended Transmission Control Block (TCB) Parameters . . . 130 13.1. Parameters necessary for the SCTP instance . . . . . . . 129
13.1. Parameters necessary for the SCTP instance . . . . . . . 130 13.2. Parameters necessary per association (i.e. the TCB) . . . 129
13.2. Parameters necessary per association (i.e. the TCB) . . . 130 13.3. Per Transport Address Data . . . . . . . . . . . . . . . 131
13.3. Per Transport Address Data . . . . . . . . . . . . . . . 132 13.4. General Parameters Needed . . . . . . . . . . . . . . . . 132
13.4. General Parameters Needed . . . . . . . . . . . . . . . . 133 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 133
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 134 14.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 133
14.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 134 14.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 133
14.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 134 14.3. IETF-defined Additional Error Causes . . . . . . . . . . 134
14.3. IETF-defined Additional Error Causes . . . . . . . . . . 135 14.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 134
14.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 135 15. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 135
15. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 136 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 135
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 136 Appendix A. Explicit Congestion Notification . . . . . . . . . . 136
Appendix A. Explicit Congestion Notification . . . . . . . . . . 137 Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 138
Appendix B. CRC32c Checksum Calculation . . . . . . . . . . . . 139 Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 140
Appendix C. ICMP Handling . . . . . . . . . . . . . . . . . . . 141 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 146
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 147 17.1. Normative references . . . . . . . . . . . . . . . . . . 146
17.1. Normative references . . . . . . . . . . . . . . . . . . 147 17.2. Informative References . . . . . . . . . . . . . . . . . 147
17.2. Informative References . . . . . . . . . . . . . . . . . 148 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 148
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 149
Intellectual Property and Copyright Statements . . . . . . . . . 150 Intellectual Property and Copyright Statements . . . . . . . . . 150
1. Introduction 1. Introduction
This section explains the reasoning behind the development of the This section explains the reasoning behind the development of the
Stream Control Transmission Protocol (SCTP), the services it offers, Stream Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description and the basic concepts needed to understand the detailed description
of the protocol. of the protocol.
1.1. Motivation 1.1. Motivation
skipping to change at page 7, line 11 skipping to change at page 7, line 11
user" for short) and a connectionless packet network service such as user" for short) and a connectionless packet network service such as
IP. The remainder of this document assumes SCTP runs on top of IP. IP. The remainder of this document assumes SCTP runs on top of IP.
The basic service offered by SCTP is the reliable transfer of user The basic service offered by SCTP is the reliable transfer of user
messages between peer SCTP users. It performs this service within messages between peer SCTP users. It performs this service within
the context of an association between two SCTP endpoints. Section 10 the context of an association between two SCTP endpoints. Section 10
of this document sketches the API which should exist at the boundary of this document sketches the API which should exist at the boundary
between the SCTP and the SCTP user layers. between the SCTP and the SCTP user layers.
SCTP is connection-oriented in nature, but the SCTP association is a SCTP is connection-oriented in nature, but the SCTP association is a
broader concept than the TCP connection. SCTP provides the means for broader concept than the TCP connection. SCTP provides the means for
each SCTP endpoint (Section 1.4) to provide the other endpoint each SCTP endpoint (Section 1.3) to provide the other endpoint
(during association startup) with a list of transport addresses (during association startup) with a list of transport addresses
(i.e., multiple IP addresses in combination with an SCTP port) (i.e., multiple IP addresses in combination with an SCTP port)
through which that endpoint can be reached and from which it will through which that endpoint can be reached and from which it will
originate SCTP packets. The association spans transfers over all of originate SCTP packets. The association spans transfers over all of
the possible source/destination combinations which may be generated the possible source/destination combinations which may be generated
from each endpoint's lists. from each endpoint's lists.
_____________ _____________ _____________ _____________
| SCTP User | | SCTP User | | SCTP User | | SCTP User |
| Application | | Application | | Application | | Application |
skipping to change at page 7, line 36 skipping to change at page 7, line 36
|-------------| |-------------| |-------------| |-------------|
| |One or more ---- One or more| | | |One or more ---- One or more| |
| IP Network |IP address \/ IP address| IP Network | | IP Network |IP address \/ IP address| IP Network |
| Service |appearances /\ appearances| Service | | Service |appearances /\ appearances| Service |
|_____________| ---- |_____________| |_____________| ---- |_____________|
SCTP Node A |<-------- Network transport ------->| SCTP Node B SCTP Node A |<-------- Network transport ------->| SCTP Node B
Figure 1: An SCTP Association Figure 1: An SCTP Association
1.3. Functional View of SCTP 1.3. Key Terms
The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the
remainder of this section.
SCTP User Application
-----------------------------------------------------
_____________ ____________________
| | | Sequenced delivery |
| Association | | within streams |
| | |____________________|
| startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
Figure 2: Functional View of the SCTP Transport Service
1.3.1. Association Startup and Takedown
An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in Section 10).
A cookie mechanism, similar to one described by Karn and Simpson in
[RFC2522] , is employed during the initialization to provide
protection against security attacks. The cookie mechanism uses a
four-way handshake, the last two legs of which are allowed to carry
user data for fast setup. The startup sequence is described in
Section 5 of this document.
SCTP provides for graceful close (i.e., shutdown) of an active
association on request from the SCTP user. See the description of
the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful
close (i.e., abort), either on request from the user (ABORT
primitive) or as a result of an error condition detected within the
SCTP layer. Section 9 describes both the graceful and the ungraceful
close procedures.
SCTP does not support a half-open state (like TCP) wherein one side
may continue sending data while the other end is closed. When either
endpoint performs a shutdown, the association on each peer will stop
accepting new data from its user and only deliver data in queue at
the time of the graceful close (see Section 9 ).
1.3.2. Sequenced Delivery within Streams
The term "stream" is used in SCTP to refer to a sequence of user
messages that are to be delivered to the upper-layer protocol in
order with respect to other messages within the same stream. This is
in contrast to its usage in TCP, where it refers to a sequence of
bytes (in this document a byte is assumed to be eight bits).
The SCTP user can specify at association startup time the number of
streams to be supported by the association. This number is
negotiated with the remote end (see Section 5.1.1). User messages
are associated with stream numbers (SEND, RECEIVE primitives,
Section 10). Internally, SCTP assigns a stream sequence number to
each message passed to it by the SCTP user. On the receiving side,
SCTP ensures that messages are delivered to the SCTP user in sequence
within a given stream. However, while one stream may be blocked
waiting for the next in-sequence user message, delivery from other
streams may proceed.
SCTP provides a mechanism for bypassing the sequenced delivery
service. User messages sent using this mechanism are delivered to
the SCTP user as soon as they are received.
1.3.3. User Data Fragmentation
When needed, SCTP fragments user messages to ensure that the SCTP
packet passed to the lower layer conforms to the path MTU. On
receipt, fragments are reassembled into complete messages before
being passed to the SCTP user.
1.3.4. Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number (TSN) to each user data
fragment or unfragmented message. The TSN is independent of any
stream sequence number assigned at the stream level. The receiving
end acknowledges all TSNs received, even if there are gaps in the
sequence. In this way, reliable delivery is kept functionally
separate from sequenced stream delivery.
The acknowledgement and congestion avoidance function is responsible
for packet retransmission when timely acknowledgement has not been
received. Packet retransmission is conditioned by congestion
avoidance procedures similar to those used for TCP. See Section 6
and Section 7 for a detailed description of the protocol procedures
associated with this function.
1.3.5. Chunk Bundling
As described in Section 3, the SCTP packet as delivered to the lower
layer consists of a common header followed by one or more chunks.
Each chunk may contain either user data or SCTP control information.
The SCTP user has the option to request bundling of more than one
user messages into a single SCTP packet. The chunk bundling function
of SCTP is responsible for assembly of the complete SCTP packet and
its disassembly at the receiving end.
During times of congestion an SCTP implementation MAY still perform
bundling even if the user has requested that SCTP not bundle. The
user's disabling of bundling only affects SCTP implementations that
may delay a small period of time before transmission (to attempt to
encourage bundling). When the user layer disables bundling, this
small delay is prohibited but not bundling that is performed during
congestion or retransmission.
1.3.6. Packet Validation
A mandatory Verification Tag field and a 32 bit checksum field (see
Appendix B for a description of the CRC32c checksum) are included in
the SCTP common header. The Verification Tag value is chosen by each
end of the association during association startup. Packets received
without the expected Verification Tag value are discarded, as a
protection against blind masquerade attacks and against stale SCTP
packets from a previous association. The CRC32c checksum should be
set by the sender of each SCTP packet to provide additional
protection against data corruption in the network. The receiver of
an SCTP packet with an invalid CRC32c checksum silently discards the
packet.
1.3.7. Path Management
The sending SCTP user is able to manipulate the set of transport
addresses used as destinations for SCTP packets through the
primitives described in Section 10. The SCTP path management
function chooses the destination transport address for each outgoing
SCTP packet based on the SCTP user's instructions and the currently
perceived reachability status of the eligible destination set. The
path management function monitors reachability through heartbeats
when other packet traffic is inadequate to provide this information
and advises the SCTP user when reachability of any far-end transport
address changes. The path management function is also responsible
for reporting the eligible set of local transport addresses to the
far end during association startup, and for reporting the transport
addresses returned from the far end to the SCTP user.
At association start-up, a primary path is defined for each SCTP
endpoint, and is used for normal sending of SCTP packets.
On the receiving end, the path management is responsible for
verifying the existence of a valid SCTP association to which the
inbound SCTP packet belongs before passing it for further processing.
Note: Path Management and Packet Validation are done at the same
time, so although described separately above, in reality they cannot
be performed as separate items.
1.4. Key Terms
Some of the language used to describe SCTP has been introduced in the Some of the language used to describe SCTP has been introduced in the
previous sections. This section provides a consolidated list of the previous sections. This section provides a consolidated list of the
key terms and their definitions. key terms and their definitions.
o Active destination transport address: A transport address on a o Active destination transport address: A transport address on a
peer endpoint which a transmitting endpoint considers available peer endpoint which a transmitting endpoint considers available
for receiving user messages. for receiving user messages.
o Bundling: An optional multiplexing operation, whereby more than o Bundling: An optional multiplexing operation, whereby more than
skipping to change at page 15, line 5 skipping to change at page 11, line 20
o User message: The unit of data delivery across the interface o User message: The unit of data delivery across the interface
between SCTP and its user. between SCTP and its user.
o Verification Tag: A 32 bit unsigned integer that is randomly o Verification Tag: A 32 bit unsigned integer that is randomly
generated. The Verification Tag provides a key that allows a generated. The Verification Tag provides a key that allows a
receiver to verify that the SCTP packet belongs to the current receiver to verify that the SCTP packet belongs to the current
association and is not an old or stale packet from a previous association and is not an old or stale packet from a previous
association. association.
1.5. Abbreviations 1.4. Abbreviations
MAC - Message Authentication Code [RFC2104] MAC - Message Authentication Code [RFC2104]
RTO - Retransmission Time-out RTO - Retransmission Time-out
RTT - Round-trip Time RTT - Round-trip Time
RTTVAR - Round-trip Time Variation RTTVAR - Round-trip Time Variation
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
skipping to change at page 15, line 27 skipping to change at page 11, line 42
SRTT - Smoothed RTT SRTT - Smoothed RTT
TCB - Transmission Control Block TCB - Transmission Control Block
TLV - Type-Length-Value Coding Format TLV - Type-Length-Value Coding Format
TSN - Transmission Sequence Number TSN - Transmission Sequence Number
ULP - Upper-layer Protocol ULP - Upper-layer Protocol
1.5. Functional View of SCTP
The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the
remainder of this section.
SCTP User Application
-----------------------------------------------------
_____________ ____________________
| | | Sequenced delivery |
| Association | | within streams |
| | |____________________|
| startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
Figure 2: Functional View of the SCTP Transport Service
1.5.1. Association Startup and Takedown
An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in Section 10).
A cookie mechanism, similar to one described by Karn and Simpson in
[RFC2522] , is employed during the initialization to provide
protection against synchronization attacks. The cookie mechanism
uses a four-way handshake, the last two legs of which are allowed to
carry user data for fast setup. The startup sequence is described in
Section 5 of this document.
SCTP provides for graceful close (i.e., shutdown) of an active
association on request from the SCTP user. See the description of
the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful
close (i.e., abort), either on request from the user (ABORT
primitive) or as a result of an error condition detected within the
SCTP layer. Section 9 describes both the graceful and the ungraceful
close procedures.
SCTP does not support a half-open state (like TCP) wherein one side
may continue sending data while the other end is closed. When either
endpoint performs a shutdown, the association on each peer will stop
accepting new data from its user and only deliver data in queue at
the time of the graceful close (see Section 9 ).
1.5.2. Sequenced Delivery within Streams
The term "stream" is used in SCTP to refer to a sequence of user
messages that are to be delivered to the upper-layer protocol in
order with respect to other messages within the same stream. This is
in contrast to its usage in TCP, where it refers to a sequence of
bytes (in this document a byte is assumed to be eight bits).
The SCTP user can specify at association startup time the number of
streams to be supported by the association. This number is
negotiated with the remote end (see Section 5.1.1). User messages
are associated with stream numbers (SEND, RECEIVE primitives,
Section 10). Internally, SCTP assigns a stream sequence number to
each message passed to it by the SCTP user. On the receiving side,
SCTP ensures that messages are delivered to the SCTP user in sequence
within a given stream. However, while one stream may be blocked
waiting for the next in-sequence user message, delivery from other
streams may proceed.
SCTP provides a mechanism for bypassing the sequenced delivery
service. User messages sent using this mechanism are delivered to
the SCTP user as soon as they are received.
1.5.3. User Data Fragmentation
When needed, SCTP fragments user messages to ensure that the SCTP
packet passed to the lower layer conforms to the path MTU. On
receipt, fragments are reassembled into complete messages before
being passed to the SCTP user.
1.5.4. Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number (TSN) to each user data
fragment or unfragmented message. The TSN is independent of any
stream sequence number assigned at the stream level. The receiving
end acknowledges all TSNs received, even if there are gaps in the
sequence. In this way, reliable delivery is kept functionally
separate from sequenced stream delivery.
The acknowledgement and congestion avoidance function is responsible
for packet retransmission when timely acknowledgement has not been
received. Packet retransmission is conditioned by congestion
avoidance procedures similar to those used for TCP. See Section 6
and Section 7 for a detailed description of the protocol procedures
associated with this function.
1.5.5. Chunk Bundling
As described in Section 3, the SCTP packet as delivered to the lower
layer consists of a common header followed by one or more chunks.
Each chunk may contain either user data or SCTP control information.
The SCTP user has the option to request bundling of more than one
user messages into a single SCTP packet. The chunk bundling function
of SCTP is responsible for assembly of the complete SCTP packet and
its disassembly at the receiving end.
During times of congestion an SCTP implementation MAY still perform
bundling even if the user has requested that SCTP not bundle. The
user's disabling of bundling only affects SCTP implementations that
may delay a small period of time before transmission (to attempt to
encourage bundling). When the user layer disables bundling, this
small delay is prohibited but not bundling that is performed during
congestion or retransmission.
1.5.6. Packet Validation
A mandatory Verification Tag field and a 32 bit checksum field (see
Appendix B for a description of the CRC32c checksum) are included in
the SCTP common header. The Verification Tag value is chosen by each
end of the association during association startup. Packets received
without the expected Verification Tag value are discarded, as a
protection against blind masquerade attacks and against stale SCTP
packets from a previous association. The CRC32c checksum should be
set by the sender of each SCTP packet to provide additional
protection against data corruption in the network. The receiver of
an SCTP packet with an invalid CRC32c checksum silently discards the
packet.
1.5.7. Path Management
The sending SCTP user is able to manipulate the set of transport
addresses used as destinations for SCTP packets through the
primitives described in Section 10. The SCTP path management
function chooses the destination transport address for each outgoing
SCTP packet based on the SCTP user's instructions and the currently
perceived reachability status of the eligible destination set. The
path management function monitors reachability through heartbeats
when other packet traffic is inadequate to provide this information
and advises the SCTP user when reachability of any far-end transport
address changes. The path management function is also responsible
for reporting the eligible set of local transport addresses to the
far end during association startup, and for reporting the transport
addresses returned from the far end to the SCTP user.
At association start-up, a primary path is defined for each SCTP
endpoint, and is used for normal sending of SCTP packets.
On the receiving end, the path management is responsible for
verifying the existence of a valid SCTP association to which the
inbound SCTP packet belongs before passing it for further processing.
Note: Path Management and Packet Validation are done at the same
time, so although described separately above, in reality they cannot
be performed as separate items.
1.6. Serial Number Arithmetic 1.6. Serial Number Arithmetic
It is essential to remember that the actual Transmission Sequence It is essential to remember that the actual Transmission Sequence
Number space is finite, though very large. This space ranges from 0 Number space is finite, though very large. This space ranges from 0
to 2**32 - 1. Since the space is finite, all arithmetic dealing with to 2**32 - 1. Since the space is finite, all arithmetic dealing with
Transmission Sequence Numbers must be performed modulo 2**32. This Transmission Sequence Numbers must be performed modulo 2**32. This
unsigned arithmetic preserves the relationship of sequence numbers as unsigned arithmetic preserves the relationship of sequence numbers as
they cycle from 2**32 - 1 to 0 again. There are some subtleties to they cycle from 2**32 - 1 to 0 again. There are some subtleties to
computer modulo arithmetic, so great care should be taken in computer modulo arithmetic, so great care should be taken in
programming the comparison of such values. When referring to TSNs, programming the comparison of such values. When referring to TSNs,
skipping to change at page 20, line 37 skipping to change at page 20, line 37
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.
The total length of a chunk (including Type, Length, and Value 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 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 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 zero bytes, and this padding is not included in the chunk length
field. The sender should never pad with more than 3 bytes. The field. The sender MUST NOT pad with more than 3 bytes. The receiver
receiver MUST ignore the padding bytes. MUST ignore the padding bytes.
SCTP defined chunks are described in detail in Section 3.3. The SCTP defined chunks are described in detail in Section 3.3. The
guidelines for IETF-defined chunk extensions can be found in guidelines for IETF-defined chunk extensions can be found in
Section 14.1 of this document. Section 14.1 of this document.
3.2.1. Optional/Variable-length Parameter Format 3.2.1. Optional/Variable-length Parameter Format
Chunk values of SCTP control chunks consist of a chunk-type-specific Chunk values of SCTP control chunks consist of a chunk-type-specific
header of required fields, followed by zero or more parameters. The header of required fields, followed by zero or more parameters. The
optional and variable-length parameters contained in a chunk are optional and variable-length parameters contained in a chunk are
skipping to change at page 21, line 42 skipping to change at page 21, line 42
Chunk Parameter Value: variable-length. Chunk Parameter Value: variable-length.
The Parameter Value field contains the actual information to be The Parameter Value field contains the actual information to be
transferred in the parameter. transferred in the parameter.
The total length of a parameter (including Type, Parameter Length The total length of a parameter (including Type, Parameter Length
and Value fields) MUST be a multiple of 4 bytes. If the length of and Value fields) MUST be a multiple of 4 bytes. If the length of
the parameter is not a multiple of 4 bytes, the sender pads the the parameter is not a multiple of 4 bytes, the sender pads the
Parameter at the end (i.e., after the Parameter Value field) with Parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is not included in the all zero bytes. The length of the padding is not included in the
parameter length field. A sender SHOULD NOT pad with more than 3 parameter length field. A sender MUST NOT pad with more than 3
bytes. The receiver MUST ignore the padding bytes. bytes. The receiver MUST ignore the padding bytes.
The Parameter Types are encoded such that the highest-order two The Parameter Types are encoded such that the highest-order two
bits specify the action that must be taken if the processing bits specify the action that must be taken if the processing
endpoint does not recognize the Parameter Type. endpoint does not recognize the Parameter Type.
00 - Stop processing this parameter; do not process any further 00 - Stop processing this parameter; do not process any further
parameters within this chunk. parameters within this chunk.
01 - Stop processing this parameter, do not process any further 01 - Stop processing this parameter, do not process any further
parameters within this chunk, and report the unrecognized parameters within this chunk, and report the unrecognized
parameter in an 'Unrecognized Parameter', as described in parameter in an 'Unrecognized Parameter', as described in
Section 3.2.2. Section 3.2.2.
10 - Skip this parameter and continue processing. 10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the 11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter', as unrecognized parameter in an 'Unrecognized Parameter', as
described in Section 3.2.2. described in Section 3.2.2.
Please note that in all four cases an INIT-ACK or COOKIE-ECHO
chunk is sent. In the 00 or 01 case the processing of the Please note that in all four cases an INIT-ACK or COOKIE-ECHO chunk
parameters after the unknown parameter is canceled, but no is sent. In the 00 or 01 case the processing of the parameters after
processing already done is rolled back. the unknown parameter is canceled, but no processing already done is
rolled back.
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 14.2. Note that a parameter type MUST be defined in Section 14.2. Note that a parameter type MUST be unique
unique across all chunks. For example, the parameter type '5' is across all chunks. For example, the parameter type '5' is used to
used to represent an IPv4 address (see Section 3.2.2). The value represent an IPv4 address (see Section 3.2.2). The value '5' then is
'5' then is reserved across all chunks to represent an IPv4 reserved across all chunks to represent an IPv4 address and MUST NOT
address and MUST NOT be reused with a different meaning in any be reused with a different meaning in any other chunk.
other chunk.
3.2.2. Reporting of Unrecognized Parameters 3.2.2. Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters and If the receiver of an INIT chunk detects unrecognized parameters and
has to report them according to Section 3.2.1, it MUST put the has to report them according to Section 3.2.1, it MUST put the
'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in
response to the INIT-chunk. Note that if the receiver of the INIT response to the INIT-chunk. Note that if the receiver of the INIT
chunk is NOT going to establish an association (e.g., due to lack of chunk is NOT going to establish an association (e.g., due to lack of
resources), an 'Unrecognized Parameter' would NOT be included with resources), an 'Unrecognized Parameter' would NOT be included with
any ABORT being sent to the sender of the INIT. any ABORT being sent to the sender of the INIT.
skipping to change at page 29, line 20 skipping to change at page 29, line 20
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 20 | | Type = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bit (unsigned integer) IPv6 Address: 128 bits (unsigned integer)
Contains an IPv6 address of the sending endpoint. It is binary Contains an IPv6 address of the sending endpoint. It is binary
encoded. encoded.
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291]. Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291].
but should instead use an IPv4 Address Parameter for an IPv4 but should instead use an IPv4 Address Parameter for an IPv4
address. address.
Combined with the Source Port Number in the SCTP common header, Combined with the Source Port Number in the SCTP common header,
the value passed in an IPv4 or IPv6 Address parameter indicates a the value passed in an IPv4 or IPv6 Address parameter indicates a
skipping to change at page 40, line 7 skipping to change at page 40, line 7
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length | | Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-specific Heartbeat Info / / Sender-specific Heartbeat Info /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sender-specific Heartbeat Info field should normally include The Sender-specific Heartbeat Info field should normally include
information about the sender's current time when this HEARTBEAT information about the sender's current time when this HEARTBEAT
chunk is sent and the destination transport address to which this chunk is sent and the destination transport address to which this
HEARTBEAT is sent (see Section 8.3). HEARTBEAT is sent (see Section 8.3). This information is simply
reflected back by the receiver in the HEARTBEAT ACK message (see
Section 3.3.6). Note also that the HEARTBEAT message is both for
reachability checking and for Path Verification (see Section 5.4).
When a HEARTBEAT chunk is being used for path verification
purposes it MUST hold a 64 bit random nonce.
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5):
An endpoint should send this chunk to its peer endpoint as a response An endpoint should send this chunk to its peer endpoint as a response
to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always
sent to the source IP address of the IP datagram containing the sent to the source IP address of the IP datagram containing the
HEARTBEAT chunk to which this ack is responding. HEARTBEAT chunk to which this ack is responding.
The parameter field contains a variable length opaque data structure. The parameter field contains a variable length opaque data structure.
skipping to change at page 53, line 32 skipping to change at page 53, line 32
o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT], o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],
o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control
chunks, or chunks, or
o Some timeout events. o Some timeout events.
The state diagram in the figures below illustrates state changes, The state diagram in the figures below illustrates state changes,
together with the causing events and resulting actions. Note that together with the causing events and resulting actions. Note that
some of the error conditions are not shown in the state diagram. some of the error conditions are not shown in the state diagram.
Full description of all special cases should be found in the text. Full description of all special cases are found in the text.
Note: Chunk names are given in all capital letters, while parameter Note: Chunk names are given in all capital letters, while parameter
names have the first letter capitalized, e.g., COOKIE ECHO chunk type names have the first letter capitalized, e.g., COOKIE ECHO chunk type
vs. State Cookie parameter. If more than one event/message can occur vs. State Cookie parameter. If more than one event/message can occur
which causes a state transition it is labeled (A), (B) etc. which causes a state transition it is labeled (A), (B) etc.
----- -------- (from any state) ----- -------- (from any state)
/ \ / rcv ABORT [ABORT] / \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ---------- rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT --------------- | v v delete TCB snd ABORT
skipping to change at page 61, line 44 skipping to change at page 61, line 44
when the State Cookie is created, and the lifespan of the State when the State Cookie is created, and the lifespan of the State
Cookie, along with all the information necessary for it to establish Cookie, along with all the information necessary for it to establish
the association. the association.
The following steps SHOULD be taken to generate the State Cookie: The following steps SHOULD be taken to generate the State Cookie:
1) Create an association TCB using information from both the 1) Create an association TCB using information from both the
received INIT and the outgoing INIT ACK chunk, received INIT and the outgoing INIT ACK chunk,
2) In the TCB, set the creation time to the current time of day, and 2) In the TCB, set the creation time to the current time of day, and
the lifespan to the protocol parameter 'Valid.Cookie.Life', the lifespan to the protocol parameter 'Valid.Cookie.Life' (see
Section 15 ),
3) From the TCB, identify and collect the minimal subset of 3) From the TCB, identify and collect the minimal subset of
information needed to re-create the TCB, and generate a MAC using information needed to re-create the TCB, and generate a MAC using
this subset of information and a secret key (see [RFC2104] for an this subset of information and a secret key (see [RFC2104] for an
example of generating a MAC), and example of generating a MAC), and
4) Generate the State Cookie by combining this subset of information 4) Generate the State Cookie by combining this subset of information
and the resultant MAC. and the resultant MAC.
After sending the INIT ACK with the State Cookie parameter, the After sending the INIT ACK with the State Cookie parameter, the
sender SHOULD delete the TCB and any other local resource related to sender SHOULD delete the TCB and any other local resource related to
skipping to change at page 62, line 34 skipping to change at page 62, line 34
When an endpoint (in the COOKIE WAIT state) receives an INIT ACK When an endpoint (in the COOKIE WAIT state) receives an INIT ACK
chunk with a State Cookie parameter, it MUST immediately send a chunk with a State Cookie parameter, it MUST immediately send a
COOKIE ECHO chunk to its peer with the received State Cookie. The COOKIE ECHO chunk to its peer with the received State Cookie. The
sender MAY also add any pending DATA chunks to the packet after the sender MAY also add any pending DATA chunks to the packet after the
COOKIE ECHO chunk. COOKIE ECHO chunk.
The endpoint shall also start the T1-cookie timer after sending out The endpoint shall also start the T1-cookie timer after sending out
the COOKIE ECHO chunk. If the timer expires, the endpoint shall the COOKIE ECHO chunk. If the timer expires, the endpoint shall
retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. retransmit the COOKIE ECHO chunk and restart the T1-cookie timer.
This is repeated until either a COOKIE ACK is received or This is repeated until either a COOKIE ACK is received or
'Max.Init.Retransmits' is reached causing the peer endpoint to be 'Max.Init.Retransmits' (see Section 15 is reached causing the peer
marked unreachable (and thus the association enters the CLOSED endpoint to be marked unreachable (and thus the association enters
state). the CLOSED state).
5.1.5. State Cookie Authentication 5.1.5. State Cookie Authentication
When an endpoint receives a COOKIE ECHO chunk from another endpoint When an endpoint receives a COOKIE ECHO chunk from another endpoint
with which it has no association, it shall take the following with which it has no association, it shall take the following
actions: actions:
1) Compute a MAC using the TCB data carried in the State Cookie and 1) Compute a MAC using the TCB data carried in the State Cookie and
the secret key (note the timestamp in the State Cookie MAY be the secret key (note the timestamp in the State Cookie MAY be
used to determine which secret key to use). Reference [RFC2104] used to determine which secret key to use). Reference [RFC2104]
skipping to change at page 93, line 46 skipping to change at page 93, line 46
homing. SCTP is designed to establish robust communication homing. SCTP is designed to establish robust communication
associations between two endpoints each of which may be reachable by associations between two endpoints each of which may be reachable by
more than one transport address. Potentially different addresses may more than one transport address. Potentially different addresses may
lead to different data paths between the two endpoints, thus ideally lead to different data paths between the two endpoints, thus ideally
one may need a separate set of congestion control parameters for each one may need a separate set of congestion control parameters for each
of the paths. The treatment here of congestion control for multi- of the paths. The treatment here of congestion control for multi-
homed receivers is new with SCTP and may require refinement in the homed receivers is new with SCTP and may require refinement in the
future. The current algorithms make the following assumptions: future. The current algorithms make the following assumptions:
o The sender usually uses the same destination address until being o The sender usually uses the same destination address until being
instructed by the upper layer otherwise; however, SCTP may change instructed by the upper layer to do otherwise; however, SCTP may
to an alternate destination in the event an address is marked change to an alternate destination in the event an address is
inactive (see Section 8.2). Also, SCTP may retransmit to a marked inactive (see Section 8.2). Also, SCTP may retransmit to a
different transport address than the original transmission. different transport address than the original transmission.
o The sender keeps a separate congestion control parameter set for o The sender keeps a separate congestion control parameter set for
each of the destination addresses it can send to (not each source- each of the destination addresses it can send to (not each source-
destination pair but for each destination). The parameters should destination pair but for each destination). The parameters should
decay if the address is not used for a long enough time period. decay if the address is not used for a long enough time period.
o For each of the destination addresses, an endpoint does slow-start o For each of the destination addresses, an endpoint does slow-start
upon the first transmission to that address. upon the first transmission to that address.
skipping to change at page 99, line 12 skipping to change at page 99, line 12
each TSN hole reported by a SACK. The counter increments for each each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 3 and consecutive SACK reporting the TSN hole. After reaching 3 and
starting the fast retransmit procedure, the counter resets to 0. starting the fast retransmit procedure, the counter resets 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.
7.3. Path MTU Discovery 7.3. Path MTU Discovery
[RFC1191] specifies "Path MTU Discovery", whereby an endpoint [RFC4821] specifies "Packetization Layer Path MTU Discovery", whereby
maintains an estimate of the maximum transmission unit (MTU) along a an endpoint maintains an estimate of the maximum transmission unit
given Internet path and refrains from sending packets along that path (MTU) along a given Internet path and refrains from sending packets
which exceed the MTU, other than occasional attempts to probe for a along that path which exceed the MTU, other than occasional attempts
change in the Path MTU (PMTU). [RFC1191] is thorough in its to probe for a change in the Path MTU (PMTU). [RFC4821] is thorough
discussion of the MTU discovery mechanism and strategies for in its discussion of the MTU discovery mechanism and strategies for
determining the current end-to-end MTU setting as well as detecting determining the current end-to-end MTU setting as well as detecting
changes in this value. [RFC1981] specifies the same mechanisms for changes in this value.
IPv6. An SCTP sender using IPv6 MUST use Path MTU Discovery unless
all packets are less than the minimum IPv6 MTU [RFC2460].
An endpoint SHOULD apply these techniques, and SHOULD do so on a per- An endpoint SHOULD apply these techniques, and SHOULD do so on a per-
destination-address basis. destination-address basis.
There are 4 ways in which SCTP differs from the description in There are 2 important SCTP specific points regarding path MTU
[RFC1191] of applying MTU discovery to TCP: discovery:
1) SCTP associations can span multiple addresses. An endpoint MUST 1) SCTP associations can span multiple addresses. An endpoint MUST
maintain separate MTU estimates for each destination address of maintain separate MTU estimates for each destination address of
its peer. its peer.
2) Elsewhere in this document, when the term "MTU" is discussed, it 2) The sender should track an association PMTU which will be the
refers to the MTU associated with the destination address
corresponding to the context of the discussion.
3) Unlike TCP, SCTP does not have a notion of "Maximum Segment
Size". Accordingly, the MTU for each destination address SHOULD
be initialized to a value no larger than the link MTU for the
local interface to which packets for that remote destination
address will be routed.
4) Since data transmission in SCTP is naturally structured in terms
of TSNs rather than bytes (as is the case for TCP), the
discussion in Section 6.5 of [RFC1191] applies: When
retransmitting an IP datagram to a remote address for which the
IP datagram appears too large for the path MTU to that address,
the IP datagram SHOULD be retransmitted without the DF bit set,
allowing it to possibly be fragmented. Transmissions of new IP
datagrams MUST have DF set.
5) The sender should track an association PMTU which will be the
smallest PMTU discovered for all of the peer's destination smallest PMTU discovered for all of the peer's destination
addresses. When fragmenting messages into multiple parts this addresses. When fragmenting messages into multiple parts this
association PMTU should be used to calculate the size of each association PMTU should be used to calculate the size of each
fragment. This will allow retransmissions to be seamlessly sent fragment. This will allow retransmissions to be seamlessly sent
to an alternate address without encountering IP fragmentation. to an alternate address without encountering IP fragmentation.
Other than these differences, the discussion of TCP's use of MTU
discovery in [RFC1191] and [RFC1981] applies to SCTP on a per-
destination-address basis.
Note: For IPv6 destination addresses the DF bit does not exist,
instead the IP datagram must be fragmented as described in [RFC2460].
8. Fault Management 8. Fault Management
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
skipping to change at page 111, line 29 skipping to change at page 110, line 46
Format: ASSOCIATE(local SCTP instance name, Format: ASSOCIATE(local SCTP instance name,
destination transport addr, outbound stream count) destination transport addr, outbound stream count)
-> association id [,destination transport addr list] -> association id [,destination transport addr list]
[,outbound stream count] [,outbound stream count]
This primitive allows the upper layer to initiate an association to a This primitive allows the upper layer to initiate an association to a
specific peer endpoint. specific peer endpoint.
The peer endpoint shall be specified by one of the transport The peer endpoint shall be specified by one of the transport
addresses which defines the endpoint (see Section 1.4). If the local addresses which defines the endpoint (see Section 1.3). If the local
SCTP instance has not been initialized, the ASSOCIATE is considered SCTP instance has not been initialized, the ASSOCIATE is considered
an error. an error.
An association id, which is a local handle to the SCTP association, An association id, which is a local handle to the SCTP association,
will be returned on successful establishment of the association. If will be returned on successful establishment of the association. If
SCTP is not able to open an SCTP association with the peer endpoint, SCTP is not able to open an SCTP association with the peer endpoint,
an error is returned. an error is returned.
Other association parameters may be returned, including the complete Other association parameters may be returned, including the complete
destination transport addresses of the peer as well as the outbound destination transport addresses of the peer as well as the outbound
skipping to change at page 124, line 50 skipping to change at page 124, line 25
lower layer transport services is considered to be too great, lower layer transport services is considered to be too great,
additional integrity protection is required. If this additional additional integrity protection is required. If this additional
protection were provided in the application-layer, the SCTP header protection were provided in the application-layer, the SCTP header
would remain vulnerable to deliberate integrity attacks. While the would remain vulnerable to deliberate integrity attacks. While the
existing SCTP mechanisms for detection of packet replays are existing SCTP mechanisms for detection of packet replays are
considered sufficient for normal operation, stronger protections are considered sufficient for normal operation, stronger protections are
needed to protect SCTP when the operating environment contains needed to protect SCTP when the operating environment contains
significant risk of deliberate attacks from a sophisticated significant risk of deliberate attacks from a sophisticated
adversary. adversary.
In order to promote software code-reuse, to avoid re-inventing the The SCTP Authentication extension SCTP-AUTH
wheel, and to avoid gratuitous complexity to SCTP, the IP [I-D.ietf-tsvwg-sctp-auth] MAY be used when the threat environment
Authentication Header [RFC4302] SHOULD be used when the threat requires stronger integrity protections, but does not require
environment requires stronger integrity protections, but does not confidentiality.
require confidentiality.
A widely implemented BSD Sockets API extension exists for
applications to request IP security services, such as AH or ESP from
an operating system kernel. Applications can use such an API to
request AH whenever AH use is appropriate.
11.2.3. Protecting Confidentiality 11.2.3. Protecting Confidentiality
In most cases, the risk of breach of confidentiality applies to the In most cases, the risk of breach of confidentiality applies to the
signaling data payload, not to the SCTP or lower-layer protocol signaling data payload, not to the SCTP or lower-layer protocol
overheads. If that is true, encryption of the SCTP user data only overheads. If that is true, encryption of the SCTP user data only
might be considered. As with the supplementary checksum service, might be considered. As with the supplementary checksum service,
user data encryption MAY be performed by the SCTP user application. user data encryption MAY be performed by the SCTP user application.
Alternately, the user application MAY use an implementation-specific Alternately, the user application MAY use an implementation-specific
API to request that the IP Encapsulating Security Payload (ESP) API to request that the IP Encapsulating Security Payload (ESP)
skipping to change at page 127, line 36 skipping to change at page 126, line 48
it. it.
- by deliberately allowing the impersonation to be detected, thereby - by deliberately allowing the impersonation to be detected, thereby
provoking counter-measures which cause the impersonated node to be provoking counter-measures which cause the impersonated node to be
locked out of the target SCTP node. locked out of the target SCTP node.
- by interfering with an established association by inserting - by interfering with an established association by inserting
extraneous content such as a SHUTDOWN request. extraneous content such as a SHUTDOWN request.
SCTP reduces the risk of blind masquerade attacks through IP spoofing SCTP reduces the risk of blind masquerade attacks through IP spoofing
by use of the four-way startup handshake. Man-in-the-middle by use of the four-way startup handshake. Because the initial
masquerade attacks are discussed in Section 11.3 below. Because the exchange is memory less, no lockout mechanism is triggered by blind
initial exchange is memory less, no lockout mechanism is triggered by masquerade attacks. In addition, the INIT ACK containing the State
blind masquerade attacks. In addition, the INIT ACK containing the Cookie is transmitted back to the IP address from which it received
State Cookie is transmitted back to the IP address from which it the INIT. Thus the attacker would not receive the INIT ACK
received the INIT. Thus the attacker would not receive the INIT ACK
containing the State Cookie. SCTP protects against insertion of containing the State Cookie. SCTP protects against insertion of
extraneous packets into the flow of an established association by use extraneous packets into the flow of an established association by use
of the Verification Tag. of the Verification Tag.
Logging of received INIT requests and abnormalities such as Logging of received INIT requests and abnormalities such as
unexpected INIT ACKs might be considered as a way to detect patterns unexpected INIT ACKs might be considered as a way to detect patterns
of hostile activity. However, the potential usefulness of such of hostile activity. However, the potential usefulness of such
logging must be weighed against the increased SCTP startup processing logging must be weighed against the increased SCTP startup processing
it implies, rendering the SCTP node more vulnerable to flooding it implies, rendering the SCTP node more vulnerable to flooding
attacks. Logging is pointless without the establishment of operating attacks. Logging is pointless without the establishment of operating
skipping to change at page 128, line 21 skipping to change at page 127, line 33
of associations between the attacker's node and the target, or of associations between the attacker's node and the target, or
transfer of large volumes of information within a legitimately- transfer of large volumes of information within a legitimately-
established association. established association.
Policy limits should be placed on the number of associations per Policy limits should be placed on the number of associations per
adjoining SCTP node. SCTP user applications should be capable of adjoining SCTP node. SCTP user applications should be capable of
detecting large volumes of illegitimate or "no-op" messages within a detecting large volumes of illegitimate or "no-op" messages within a
given association and either logging or terminating the association given association and either logging or terminating the association
as a result, based on local policy. as a result, based on local policy.
11.3. Protection against Fraud and Repudiation 11.3. SCTP Interactions with Firewalls
The objective of fraud is to obtain services without authorization
and specifically without paying for them. In order to achieve this
objective, the attacker must induce the SCTP user application at the
target SCTP node to provide the desired service while accepting
invalid billing data or failing to collect it. Repudiation is a
related problem, since it may occur as a deliberate act of fraud or
simply because the repudiating party kept inadequate records of
service received.
Potential fraudulent attacks include interception and misuse of
authorizing information such as credit card numbers, blind masquerade
and replay, and man-in-the middle attacks which modify the packets
passing through a target SCTP association in real time.
The interception attack is countered by the confidentiality measures
discussed in Section 11.2.3 above.
Section 11.2.4.2 describes how SCTP is resistant to blind masquerade
attacks, as a result of the four-way startup handshake and the
Verification Tag. The Verification Tag and TSN together are
protections against blind replay attacks, where the replay is into an
existing association.
However, SCTP does not protect against man-in-the-middle attacks
where the attacker is able to intercept and alter the packets sent
and received in an association. For example, the INIT ACK will have
sufficient information sent on the wire for an adversary in the
middle to hijack an existing SCTP association. Where a significant
possibility of such attacks is seen to exist, or where possible
repudiation is an issue, the use of the IPSEC AH service is
recommended to ensure both the integrity and the authenticity of the
SCTP packets passed.
SCTP also provides no protection against attacks originating at or
beyond the SCTP node and taking place within the context of an
existing association. Prevention of such attacks should be covered
by appropriate security policies at the host site, as discussed in
Section 11.2.1.
11.4. SCTP Interactions with Firewalls
It is helpful for some firewalls if they can inspect just the first It is helpful for some firewalls if they can inspect just the first
fragment of a fragmented SCTP packet and unambiguously determine fragment of a fragmented SCTP packet and unambiguously determine
whether it corresponds to an INIT chunk (for further information, whether it corresponds to an INIT chunk (for further information,
please refer to [RFC1858]). Accordingly, we stress the requirements, please refer to [RFC1858]). Accordingly, we stress the requirements,
stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled stated in Section 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 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 chunk MUST have a zero Verification Tag. Furthermore, we require that
the receiver of an INIT chunk MUST enforce these rules by silently the receiver of an INIT chunk MUST enforce these rules by silently
discarding an arriving packet with an INIT chunk that is bundled with discarding an arriving packet with an INIT chunk that is bundled with
other chunks. other chunks.
11.5. Protection of Non-SCTP Capable Hosts. 11.4. Protection of Non-SCTP Capable Hosts.
To provide a non-SCTP capable host with the same level of protection To provide a non-SCTP capable host with the same level of protection
against attacks as for SCTP-capable ones, all SCTP stacks MUST against attacks as for SCTP-capable ones, all SCTP stacks MUST
implement the ICMP handling described in Appendix C. implement the ICMP handling described in Appendix C.
When an SCTP stack receives a packet containing multiple control or When an SCTP stack receives a packet containing multiple control or
DATA chunks and the processing of the packet requires the sending of DATA chunks and the processing of the packet requires the sending of
multiple chunks in response, the sender of the response chunk(s) MUST multiple chunks in response, the sender of the response chunk(s) MUST
NOT send more than one packet. If bundling is supported, multiple NOT send more than one packet. If bundling is supported, multiple
response chunks that fit into a single packet MAY be bundled together response chunks that fit into a single packet MAY be bundled together
skipping to change at page 130, line 11 skipping to change at page 128, line 32
ERROR parameters to reduce the size of the INIT-ACK. Due to a ERROR parameters to reduce the size of the INIT-ACK. Due to a
combination of the size of the COOKIE parameter and the number of combination of the size of the COOKIE parameter and the number of
addresses a receiver of an INIT may be indicating to a peer, it is addresses a receiver of an INIT may be indicating to a peer, it is
always possible that the INIT-ACK will be larger than the original always possible that the INIT-ACK will be larger than the original
INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as
small as possible to reduce the possibility of byte amplification small as possible to reduce the possibility of byte amplification
attacks. attacks.
12. Network Management Considerations 12. Network Management Considerations
A MIB for SCTP is defined in [RFC3873]. The MIB module for SCTP defined in [RFC3873] applies for the version
of the protocol specified in this document.
13. Recommended Transmission Control Block (TCB) Parameters 13. Recommended Transmission Control Block (TCB) Parameters
This section details a recommended set of parameters that should be This section details a recommended set of parameters that should be
contained within the TCB for an implementation. This section is for contained within the TCB for an implementation. This section is for
illustrative purposes and should not be deemed as requirements on an illustrative purposes and should not be deemed as requirements on an
implementation or as an exhaustive list of all parameters inside an implementation or as an exhaustive list of all parameters inside an
SCTP TCB. Each implementation may need its own additional parameters SCTP TCB. Each implementation may need its own additional parameters
for optimization. for optimization.
skipping to change at page 148, line 27 skipping to change at page 147, line 27
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
17.2. Informative References 17.2. Informative References
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of [FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21, Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21,
July 1996. July 1996.
[SAVAGE99] [SAVAGE99]
Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communications Review 29(5), October 1999. Computer Communications Review 29(5), October 1999.
skipping to change at page 149, line 13 skipping to change at page 148, line 16
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,
September 1997. September 1997.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and
M. Tuexen, "Stream Control Transmission Protocol (SCTP) M. Tuexen, "Stream Control Transmission Protocol (SCTP)
Specification Errata and Issues", RFC 4460, April 2006. Specification Errata and Issues", RFC 4460, April 2006.
[I-D.ietf-tsvwg-sctp-auth]
Tuexen, M., "Authenticated Chunks for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctp-auth-08 (work in progress),
February 2007.
Author's Address Author's Address
Randall R. Stewart Randall R. Stewart
Editor Editor
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
US US
Email: rrs@cisco.com Email: rrs@cisco.com
 End of changes. 39 change blocks. 
350 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/