Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

in Index   Prev   Next  

RFC 2960

Stream Control Transmission Protocol

Pages: 134
Group: RSVP

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-

   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

   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

   -  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-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

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

   Phone: +1-815-477-2127

   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, #2309
   Arlington Heights, IL 60004

   Phone: +1-847-632-3028

   Ken Morneault
   Cisco Systems Inc.
   13615 Dulles Technology Drive
   Herndon, VA. 20171

   Phone: +1-703-484-3323
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.


   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      |


   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

   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.