in Index   Prev   Next

RFC 2960

Stream Control Transmission Protocol

Pages: 134
Obsoleted by:  4960
Updated by:  3309
Part 5 of 5 – Pages 114 to 134
First   Prev   None

ToP   noToC   RFC2960 - Page 114   prevText

11. Security Considerations

11.1 Security Objectives

As a common transport protocol designed to reliably carry time- sensitive user messages, such as billing or signaling messages for telephony services, between two networked endpoints, SCTP has the following security objectives. - availability of reliable and timely data transport services - integrity of the user-to-user information carried by SCTP
ToP   noToC   RFC2960 - Page 115

11.2 SCTP Responses To Potential Threats

SCTP may potentially be used in a wide variety of risk situations. It is important for operator(s) of systems running SCTP to analyze their particular situations and decide on the appropriate counter- measures. Operators of systems running SCTP should consult [RFC2196] for guidance in securing their site.

11.2.1 Countering Insider Attacks

The principles of [RFC2196] should be applied to minimize the risk of theft of information or sabotage by insiders. Such procedures include publication of security policies, control of access at the physical, software, and network levels, and separation of services.

11.2.2 Protecting against Data Corruption in the Network

Where the risk of undetected errors in datagrams delivered by the lower layer transport services is considered to be too great, additional integrity protection is required. If this additional protection were provided in the application-layer, the SCTP header would remain vulnerable to deliberate integrity attacks. While the existing SCTP mechanisms for detection of packet replays are considered sufficient for normal operation, stronger protections are needed to protect SCTP when the operating environment contains significant risk of deliberate attacks from a sophisticated adversary. In order to promote software code-reuse, to avoid re-inventing the wheel, and to avoid gratuitous complexity to SCTP, the IP Authentication Header [RFC2402] SHOULD be used when the threat environment requires stronger integrity protections, but does not 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

In most cases, the risk of breach of confidentiality applies to the signaling data payload, not to the SCTP or lower-layer protocol overheads. If that is true, encryption of the SCTP user data only might be considered. As with the supplementary checksum service, user data encryption MAY be performed by the SCTP user application.
ToP   noToC   RFC2960 - Page 116
   Alternately, the user application MAY use an implementation-specific
   API to request that the IP Encapsulating Security Payload (ESP)
   [RFC2406] be used to provide confidentiality and integrity.

   Particularly for mobile users, the requirement for confidentiality
   might include the masking of IP addresses and ports.  In this case
   ESP SHOULD be used instead of application-level confidentiality.  If
   ESP is used to protect confidentiality of SCTP traffic, an ESP
   cryptographic transform that includes cryptographic integrity
   protection MUST be used, because if there is a confidentiality threat
   there will also be a strong integrity threat.

   Whenever ESP is in use, application-level encryption is not generally

   Regardless of where confidentiality is provided, the ISAKMP [RFC2408]
   and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key

   Operators should consult [RFC2401] for more information on the
   security services available at and immediately above the Internet
   Protocol layer.

11.2.4 Protecting against Blind Denial of Service Attacks

A blind attack is one where the attacker is unable to intercept or otherwise see the content of data flows passing to and from the target SCTP node. Blind denial of service attacks may take the form of flooding, masquerade, or improper monopolization of services. Flooding
The objective of flooding is to cause loss of service and incorrect behavior at target systems through resource exhaustion, interference with legitimate transactions, and exploitation of buffer-related software bugs. Flooding may be directed either at the SCTP node or at resources in the intervening IP Access Links or the Internet. Where the latter entities are the target, flooding will manifest itself as loss of network services, including potentially the breach of any firewalls in place. In general, protection against flooding begins at the equipment design level, where it includes measures such as: - avoiding commitment of limited resources before determining that the request for service is legitimate
ToP   noToC   RFC2960 - Page 117
   -  giving priority to completion of processing in progress over the
      acceptance of new work

   -  identification and removal of duplicate or stale queued requests
      for service.

   -  not responding to unexpected packets sent to non-unicast

   Network equipment should be capable of generating an alarm and log if
   a suspicious increase in traffic occurs.  The log should provide
   information such as the identity of the incoming link and source
   address(es) used which will help the network or SCTP system operator
   to take protective measures.  Procedures should be in place for the
   operator to act on such alarms if a clear pattern of abuse emerges.

   The design of SCTP is resistant to flooding attacks, particularly in
   its use of a four-way start-up handshake, its use of a cookie to
   defer commitment of resources at the responding SCTP node until the
   handshake is completed, and its use of a Verification Tag to prevent
   insertion of extraneous packets into the flow of an established

   The IP Authentication Header and Encapsulating Security Payload might
   be useful in reducing the risk of certain kinds of denial of service

   The use of the Host Name feature in the INIT chunk could be used to
   flood a target DNS server.  A large backlog of DNS queries, resolving
   the Host Name received in the INIT chunk to IP addresses, could be
   accomplished by sending INIT's to multiple hosts in a given domain.
   In addition, an attacker could use the Host Name feature in an
   indirect attack on a third party by sending large numbers of INITs to
   random hosts containing the host name of the target.  In addition to
   the strain on DNS resources, this could also result in large numbers
   of INIT ACKs being sent to the target.  One method to protect against
   this type of attack is to verify that the IP addresses received from
   DNS include the source IP address of the original INIT.  If the list
   of IP addresses received from DNS does not include the source IP
   address of the INIT, the endpoint MAY silently discard the INIT.
   This last option will not protect against the attack against the DNS.
ToP   noToC   RFC2960 - Page 118 Blind Masquerade
Masquerade can be used to deny service in several ways: - by tying up resources at the target SCTP node to which the impersonated node has limited access. For example, the target node may by policy permit a maximum of one SCTP association with the impersonated SCTP node. The masquerading attacker may attempt to establish an association purporting to come from the impersonated node so that the latter cannot do so when it requires it. - by deliberately allowing the impersonation to be detected, thereby provoking counter-measures which cause the impersonated node to be locked out of the target SCTP node. - by interfering with an established association by inserting extraneous content such as a SHUTDOWN request. SCTP reduces the risk of blind masquerade attacks through IP spoofing by use of the four-way startup handshake. Man-in-the-middle masquerade attacks are discussed in Section 11.3 below. Because the initial exchange is memoryless, no lockout mechanism is triggered by blind masquerade attacks. In addition, the INIT ACK containing the State Cookie is transmitted back to the IP address from which it received the INIT. Thus the attacker would not receive the INIT ACK containing the State Cookie. SCTP protects against insertion of extraneous packets into the flow of an established association by use of the Verification Tag. Logging of received INIT requests and abnormalities such as unexpected INIT ACKs might be considered as a way to detect patterns of hostile activity. However, the potential usefulness of such logging must be weighed against the increased SCTP startup processing it implies, rendering the SCTP node more vulnerable to flooding attacks. Logging is pointless without the establishment of operating procedures to review and analyze the logs on a routine basis. Improper Monopolization of Services
Attacks under this heading are performed openly and legitimately by the attacker. They are directed against fellow users of the target SCTP node or of the shared resources between the attacker and the target node. Possible attacks include the opening of a large number of associations between the attacker's node and the target, or transfer of large volumes of information within a legitimately- established association.
ToP   noToC   RFC2960 - Page 119
   Policy limits should be placed on the number of associations per
   adjoining SCTP node.  SCTP user applications should be capable of
   detecting large volumes of illegitimate or "no-op" messages within a
   given association and either logging or terminating the association
   as a result, based on local policy.

11.3 Protection against Fraud and Repudiation

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 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.
ToP   noToC   RFC2960 - Page 120

12. Recommended Transmission Control Block (TCB) Parameters

This section details a recommended set of parameters that should be contained within the TCB for an implementation. This section is for illustrative purposes and should not be deemed as requirements on an implementation or as an exhaustive list of all parameters inside an SCTP TCB. Each implementation may need its own additional parameters for optimization.

12.1 Parameters necessary for the SCTP instance

Associations: A list of current associations and mappings to the data consumers for each association. This may be in the form of a hash table or other implementation dependent structure. The data consumers may be process identification information such as file descriptors, named pipe pointer, or table pointers dependent on how SCTP is implemented. Secret Key: A secret key used by this endpoint to compute the MAC. This SHOULD be a cryptographic quality random number with a sufficient length. Discussion in [RFC1750] can be helpful in selection of the key. Address List: The list of IP addresses that this instance has bound. This information is passed to one's peer(s) in INIT and INIT ACK chunks. SCTP Port: The local SCTP port number the endpoint is bound to.

12.2 Parameters necessary per association (i.e. the TCB)

Peer : Tag value to be sent in every packet and is received Verification: in the INIT or INIT ACK chunk. Tag : My : Tag expected in every inbound packet and sent in the Verification: INIT or INIT ACK chunk. Tag : State : A state variable indicating what state the association : is in, i.e. COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, : SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, : SHUTDOWN-ACK-SENT. Note: No "CLOSED" state is illustrated since if a association is "CLOSED" its TCB SHOULD be removed.
ToP   noToC   RFC2960 - Page 121
   Peer        : A list of SCTP transport addresses that the peer is
   Transport   : bound to.  This information is derived from the INIT or
   Address     : INIT ACK and is used to associate an inbound packet
   List        : with a given association.  Normally this information is
               : hashed or keyed for quick lookup and access of the TCB.

   Primary     : This is the current primary destination transport
   Path        : address of the peer endpoint.  It may also specify a
               : source transport address on this endpoint.

   Overall     : The overall association error count.
   Error Count :

   Overall     : The threshold for this association that if the Overall
   Error       : Error Count reaches will cause this association to be
   Threshold   : torn down.

   Peer Rwnd   : Current calculated value of the peer's rwnd.

   Next TSN    : The next TSN number to be assigned to a new DATA chunk.
               : This is sent in the INIT or INIT ACK chunk to the peer
               : and incremented each time a DATA chunk is assigned a
               : TSN (normally just prior to transmit or during
               : fragmentation).

   Last Rcvd   : This is the last TSN received in sequence.  This value
   TSN         : is set initially by taking the peer's Initial TSN,
               : received in the INIT or INIT ACK chunk, and
               : subtracting one from it.

   Mapping     : An array of bits or bytes indicating which out of
   Array       : order TSN's have been received (relative to the
               : Last Rcvd TSN).  If no gaps exist, i.e. no out of order
               : packets have been received, this array will be set to
               : all zero.  This structure may be in the form of a
               : circular buffer or bit array.

   Ack State   : This flag indicates if the next received packet
               : is to be responded to with a SACK.  This is initialized
               : to 0.  When a packet is received it is incremented.
               : If this value reaches 2 or more, a SACK is sent and the
               : value is reset to 0.  Note: This is used only when no
               : DATA chunks are received out of order.  When DATA chunks
               : are out of order, SACK's are not delayed (see Section
               : 6).
ToP   noToC   RFC2960 - Page 122
   Inbound     : An array of structures to track the inbound streams.
   Streams     : Normally including the next sequence number expected
               : and possibly the stream number.

   Outbound    : An array of structures to track the outbound streams.
   Streams     : Normally including the next sequence number to
               : be sent on the stream.

   Reasm Queue : A re-assembly queue.

   Local       : The list of local IP addresses bound in to this
   Transport   : association.
   Address     :
   List        :

   Association : The smallest PMTU discovered for all of the
   PMTU        : peer's transport addresses.

12.3 Per Transport Address Data

For each destination transport address in the peer's address list derived from the INIT or INIT ACK chunk, a number of data elements needs to be maintained including: Error count : The current error count for this destination. Error : Current error threshold for this destination i.e. Threshold : what value marks the destination down if Error count : reaches this value. cwnd : The current congestion window. ssthresh : The current ssthresh value. RTO : The current retransmission timeout value. SRTT : The current smoothed round trip time. RTTVAR : The current RTT variation. partial : The tracking method for increase of cwnd when in bytes acked : congestion avoidance mode (see Section 6.2.2) state : The current state of this destination, i.e. DOWN, UP, : ALLOW-HB, NO-HEARTBEAT, etc. PMTU : The current known path MTU.
ToP   noToC   RFC2960 - Page 123
   Per         : A timer used by each destination.
   Destination :
   Timer       :

   RTO-Pending : A flag used to track if one of the DATA chunks sent to
                 this address is currently being used to compute a
                 RTT.  If this flag is 0, the next DATA chunk sent to this
                 destination should be used to compute a RTT and this
                 flag should be set.  Every time the RTT calculation
                 completes (i.e. the DATA chunk is SACK'd) clear this

   last-time   : The time this destination was last sent to.  This can be
   used        : used to determine if a HEARTBEAT is needed.

12.4 General Parameters Needed

Out Queue : A queue of outbound DATA chunks. In Queue : A queue of inbound DATA chunks.

13. IANA Considerations

This protocol will require port reservation like TCP for the use of "well known" servers within the Internet. All current TCP ports shall be automatically reserved in the SCTP port address space. New requests should follow IANA's current mechanisms for TCP. This protocol may also be extended through IANA in three ways: -- through definition of additional chunk types, -- through definition of additional parameter types, or -- through definition of additional cause codes within ERROR chunks In the case where a particular ULP using SCTP desires to have its own ports, the ULP should be responsible for registering with IANA for getting its ports assigned.

13.1 IETF-defined Chunk Extension

The definition and use of new chunk types is an integral part of SCTP. Thus, new chunk types are assigned by IANA through an IETF Consensus action as defined in [RFC2434]. The documentation for a new chunk code type must include the following information:
ToP   noToC   RFC2960 - Page 124
   a) A long and short name for the new chunk type;

   b) A detailed description of the structure of the chunk, which MUST
      conform to the basic structure defined in Section 3.2;

   c) A detailed definition and description of intended use of each
      field within the chunk, including the chunk flags if any;

   d) A detailed procedural description of the use of the new chunk type
      within the operation of the protocol.

   The last chunk type (255) is reserved for future extension if

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.

13.3 IETF-defined Additional Error Causes

Additional cause codes may be allocated in the range 11 to 65535 through a Specification Required action as defined in [RFC2434]. Provided documentation must include the following information: a) Name of the error condition. b) Detailed description of the conditions under which an SCTP endpoint should issue an ERROR (or ABORT) with this cause code. c) Expected action by the SCTP endpoint which receives an ERROR (or ABORT) chunk containing this cause code.
ToP   noToC   RFC2960 - Page 125
   d) Detailed description of the structure and content of data fields
      which accompany this cause code.

   The initial word (32 bits) of a cause code parameter MUST conform to
   the format shown in Section 3.3.10, i.e.:

   -- first two bytes contain the cause code value
   -- last two bytes contain length of the Cause Parameter.

13.4 Payload Protocol Identifiers

Except for value 0 which is reserved by SCTP to indicate an unspecified payload protocol identifier in a DATA chunk, SCTP will not be responsible for standardizing or verifying any payload protocol identifiers; SCTP simply receives the identifier from the upper layer and carries it with the corresponding payload data. The upper layer, i.e., the SCTP user, SHOULD standardize any specific protocol identifier with IANA if it is so desired. The use of any specific payload protocol identifier is out of the scope of SCTP.

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 IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10). Note: RTO.Min SHOULD be set as recommended above.
ToP   noToC   RFC2960 - Page 126

15. Acknowledgements

The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their invaluable comments.

16. Authors' Addresses

Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012 USA Phone: +1-815-477-2127 EMail: Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Phone: +1-847-632-3028 EMail: Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA Phone: +1-703-484-3323 EMail:
ToP   noToC   RFC2960 - Page 127
   Chip Sharp
   Cisco Systems Inc.
   7025 Kit Creek Road
   Research Triangle Park, NC  27709

   Phone: +1-919-392-3121

   Hanns Juergen Schwarzbauer
   Hofmannstr. 51
   81359 Munich

   Phone: +49-89-722-24236

   Tom Taylor
   Nortel Networks
   1852 Lorraine Ave.
   Ottawa, Ontario
   Canada K1H 6Z8

   Phone: +1-613-736-0961

   Ian Rytina
   Ericsson Australia
   37/360 Elizabeth Street
   Melbourne, Victoria 3000

   Phone: +61-3-9301-6164
ToP   noToC   RFC2960 - Page 128
   Malleswar Kalla
   Telcordia Technologies
   3 Corporate Place
   Piscataway, NJ  08854

   Phone: +1-732-699-3728

   Lixia Zhang
   UCLA Computer Science Department
   4531G Boelter Hall
   Los Angeles, CA 90095-1596

   Phone: +1-310-825-2695

   Vern Paxson
   1947 Center St., Suite 600,
   Berkeley, CA 94704-1198

   Phone: +1-510-666-2882

17. References

[RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1123] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
ToP   noToC   RFC2960 - Page 129
   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401,  November 1998.

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC
              2402, November 1998.

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

   [RFC2408]  Maughan, D., Schertler, M., Schneider, M. and J. Turner,
              "Internet Security Association and Key Management
              Protocol", RFC 2408, November 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2581]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
              Control", RFC 2581, April 1999.

18. Bibliography

[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999. [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21. [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
ToP   noToC   RFC2960 - Page 130
   [RFC1950]  Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
              Hashing for Message Authentication", RFC 2104, March 1997.

   [RFC2196]  Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
              September 1997.

   [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
              Protocol", RFC 2522, March 1999.

   [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
              "TCP Congestion Control with a Misbehaving Receiver",  ACM
              Computer Communication Review, 29(5), October 1999.
ToP   noToC   RFC2960 - Page 131

Appendix A: Explicit Congestion Notification

ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification", RFC 2481, January 1999) describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss. This is an optional feature that an implementation MAY choose to add to SCTP. This appendix details the minor differences implementers will need to be aware of if they choose to implement this feature. In general RFC 2481 should be followed with the following exceptions. Negotiation: RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection. The sender of the SYN sets two bits in the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning behind this is to assure both sides are truly ECN capable. For SCTP this is not necessary. To indicate that an endpoint is ECN capable an endpoint SHOULD add to the INIT and or INIT ACK chunk the TLV reserved for ECN. This TLV contains no parameters, and thus has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 32768 | Parameter Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ECN-Echo: RFC 2481 details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network. For SCTP this same indication is made by including the ECNE chunk. This chunk contains one data element, i.e. the lowest TSN associated with the IP datagram marked with the CE bit, and looks as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type=12 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The ECNE is considered a Control chunk.
ToP   noToC   RFC2960 - Page 132

   RFC 2481 details a specific bit for a sender to send in the header of
   its next outbound TCP segment to indicate to its peer that it has
   reduced its congestion window.  This is termed the CWR bit.  For
   SCTP the same indication is made by including the CWR chunk.
   This chunk contains one data element, i.e. the TSN number that
   was sent in the ECNE chunk.  This element represents the lowest
   TSN number in the datagram that was originally marked with the
   CE bit.

       0                   1                   2                   3
       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
      | Chunk Type=13 | Flags=00000000|    Chunk Length = 8           |
      |                      Lowest TSN Number                        |

      Note: The CWR is considered a Control chunk.

Appendix B Alder 32 bit checksum calculation

The Adler-32 checksum calculation given in this appendix is copied from [RFC1950]. Adler-32 is composed of two sums accumulated per byte: s1 is the sum of all bytes, s2 is the sum of all s1 values. Both sums are done modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 checksum is stored as s2*65536 + s1 in network byte order. The following C code computes the Adler-32 checksum of a data buffer. It is written for clarity, not for speed. The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
ToP   noToC   RFC2960 - Page 133
   &      Bitwise AND operator.
   >>     Bitwise right shift operator.  When applied to an
          unsigned quantity, as here, right shift inserts zero bit(s)
          at the left.
   <<     Bitwise left shift operator.  Left shift inserts zero
          bit(s) at the right.
   ++     "n++" increments the variable n.
   %      modulo operator: a % b is the remainder of a divided by b.
    #define BASE 65521 /* largest prime smaller than 65536 */
      Update a running Adler-32 checksum with the bytes buf[0..len-1]
      and return the updated checksum.  The Adler-32 checksum should be
      initialized to 1.

       Usage example:

         unsigned long adler = 1L;

         while (read_buffer(buffer, length) != EOF) {
           adler = update_adler32(adler, buffer, length);
         if (adler != original_adler) error();
      unsigned long update_adler32(unsigned long adler,
         unsigned char *buf, int len)
        unsigned long s1 = adler & 0xffff;
        unsigned long s2 = (adler >> 16) & 0xffff;
        int n;

        for (n = 0; n < len; n++) {
          s1 = (s1 + buf[n]) % BASE;
          s2 = (s2 + s1)     % BASE;
        return (s2 << 16) + s1;

      /* Return the adler32 of the bytes buf[0..len-1] */
      unsigned long adler32(unsigned char *buf, int len)
        return update_adler32(1L, buf, len);
ToP   noToC   RFC2960 - Page 134
Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.