Network Working Group S. Ladha Internet-Draft Qualcomm Expires: March 17, 2005 N. Spring University Of Maryland R. Stewart Cisco Systems, Inc. September 16, 2004 ECN Nonces for Stream Control Transmission Protocol (SCTP) draft-ladha-sctp-nonce-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes the addition of the ECN-nonce RFC3540 [5] to the Stream Control Transmission Protocol (SCTP) RFC2960 [8]. The ECN-nonce reduces the vulnerability of ECN senders to misbehaving receivers that conceal congestion signals like ECN marks and packet Ladha, et al. Expires March 17, 2005 [Page 1] Internet-Draft ECN-nonce for SCTP September 2004 losses. The ECN-nonce approach is different in SCTP because SCTP uses chunks for extensible protocol features and is selective acknowlegement (SACK)-based; this document describes those differences. In particular this document describes (1) protocol extensions in the form of a single new parameter for the INIT/ INIT-ACK chunks, and a single bit flag in the SACK chunk, and (2) rules governing the sender and receiver side implementation. This document outlines a minimum response that an SCTP sender should apply after detecting a misbehaving receiver. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview of Protocol Extensions . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Extension to SCTP . . . . . . . . . . . . . . . . . . 4 3.1 Nonce-Supported Parameter Definition . . . . . . . . . . . 4 3.2 Nonce Sum (NS) flag Definition . . . . . . . . . . . . . . 4 4. Nonce-Supported Parameter Negotiation . . . . . . . . . . . . 5 5. ECN-nonce Operation . . . . . . . . . . . . . . . . . . . . . 6 5.1 State Information . . . . . . . . . . . . . . . . . . . . 6 5.2 Sender Behavior (Transmit) . . . . . . . . . . . . . . . . 6 5.3 Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 5.4 Receiver Behavior (Receive and Transmit) . . . . . . . . . 7 5.5 Sender Side (Receive) . . . . . . . . . . . . . . . . . . 8 5.6 Re-synchronization of the Nonce Sum . . . . . . . . . . . 9 6. Sender's Response . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Response to a peer that does not support the ECN-nonce . . 9 6.2 Response to a misbehaving receiver . . . . . . . . . . . . 9 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Ladha, et al. Expires March 17, 2005 [Page 2] Internet-Draft ECN-nonce for SCTP September 2004 1. Introduction Like TCP, SCTP RFC2960 [8] supports Explicit Congestion Notification (ECN) RFC3168 [3], and therefore is exposed to misbehaving receivers that conceal congestion signals. The misbehavior includes concealing of ECN Echo (ECNE) signals which may cause an SCTP sender to be agressive and unfair to compliant flows. The ECN-nonce RFC3540 [5] adds robustness to ECN signaling for TCP. This document analogously applies ECN-nonce to SCTP. ECN-nonce can be used to protect against other misbehaviors as well, such as optimistic acknowledgements [4], and false Duplicate TSN notifications [1]. The reader should be familiar with the ECN-Nonce as described in RFC3540 [5]. This document describes only the SCTP-specific aspects of the ECN-nonce. 1.1 Overview of Protocol Extensions This document specifies the following: 1. A single new Nonce-Supported parameter in the INIT/INIT-ACK chunks exchanged during the association establishment to indicate to the peer whether ECN-nonce is supported. 2. A single bit flag in the SACK chunk called the Nonce Sum (NS), and the rules governing the sending, calculating and checking of the nonce sum. The ECN-nonce does not change the existing ECN protocol. The ECN-nonce utilizes two bits of the IP header called the ECN Capable Transport (ECT) bits. The sender randomly generates a single bit nonce and encodes it in the ECT codepoints, ECT(0) or ECT(1). To indicate congestion in the network, routers may overwrite the ECT codepoints with a Congestion Experienced (CE) marking. The nonce sum is a cumulative one bit addition of the nonces received so far. The receiver calculates the nonce sum and returns it in the NS flag of the SACK chunk. The sender verifies the value of the NS flag in the SACK chunk. Since all the nonces are required to calculate the correct nonce sum, an incorrect nonce sum implies that one or more nonces are missing at the receiver. If an incorrect nonce sum is received by the sender without ECNE signals the sender can infer that the receiver is misbehaving and concealing congestion notifications. It is beyond the scope of this document to specify a sender's complete response after detecting a misbehaving receiver. However this document outlines the minimum response that a sender SHOULD apply to a receiver's misbehavior. Ladha, et al. Expires March 17, 2005 [Page 3] Internet-Draft ECN-nonce for SCTP September 2004 2. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [2]. 3. Protocol Extension to SCTP 3.1 Nonce-Supported Parameter Definition Endpoints supporting ECN-nonce SHOULD use the following OPTIONAL parameter to indicate that the ECN-nonce extension is supported. Fixed Parameter Status Type Value ------------------------------------------------------------- Nonce-Supported OPTIONAL 0x8001 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 = 0x8001 | Parameter Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 bit u_int 0x8001, Indicating the Nonce-Supported parameter. Length: 16 bit u_int 4, Indicating the size of the parameter. 3.2 Nonce Sum (NS) flag Definition A single bit flag (NS) in the SACK chunk is defined as follows: Ladha, et al. Expires March 17, 2005 [Page 4] Internet-Draft ECN-nonce for SCTP September 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Chunk Flags |N| Chunk Length | | | |S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: Reserved: 7 bits Set to 0 on transmit and ignored on receipt. NS: 1 bit The Nonce Sum (NS) flag is set by the sender of the SACK chunk with the apropriate calculated value (1 bit cumulative nonce sum). If either peer does not support the ECN-nonce, then the NS flag is always set to 0. 4. Nonce-Supported Parameter Negotiation An SCTP endpoint supporting the ECN-nonce SHOULD include the Nonce-Supported Parameter in the INIT chunk when initializing the association to indicate this to the peer. Ladha, et al. Expires March 17, 2005 [Page 5] Internet-Draft ECN-nonce for SCTP September 2004 When a receiver supports the ECN-nonce and detects a Nonce-Supported parameter in the INIT chunk, the receiver SHOULD respond with a Nonce-supported parameter in the INIT-ACK chunk. When an SCTP endpoint that supports the ECN-nonce receives an INIT chunk without the Nonce-Supported parameter, that SCTP endpoint: o MAY include the Nonce-Supported parameter in the INIT-ACK chunk. o SHOULD NOT set the NS flag in the SACK chunk during the lifetime of the association. An SCTP endpoint that supports the ECN-nonce SHOULD disable ECN (i.e., stop setting the ECT codepoints for the association) if its peer does not support the ECN-nonce. An SCTP endpoint that does not support the ECN-nonce may be denied preferential treatment or otherwise penalized by a peer that supports the ECN-nonce based on that peer's policy. 5. ECN-nonce Operation The following sub-sections describe in detail the ECN-nonce operation. This operation includes (i) the local SCTP state to be maintained at each endpoint, (ii) the sender procedures for transmitting nonces and checking of the nonce sum, (iii) intermediate router(s) behavior, and (iv) the receiver procedures for calculating the nonce sum from the received nonces, and returning the nonce sum to the sender. 5.1 State Information SCTP endpoints should maintain a single bit local state called "current nonce sum". The current nonce sum is a one bit cumulative addition of the nonces. In the beginning of a new SCTP association the current nonce sum SHOULD be initialised to one. SCTP senders should store a mapping from Transmission Sequence Numbers (TSNs) to nonce values associated with packets. The following sections describe in detail how these values are maintained and updated. 5.2 Sender Behavior (Transmit) The sender's transmit behavior follows Section 3 of RFC3540 [5] with the following changes to nonce handling. The one bit nonce is placed or encoded only for SCTP packets which carry one or more "new" DATA chunks. In other words, while all Ladha, et al. Expires March 17, 2005 [Page 6] Internet-Draft ECN-nonce for SCTP September 2004 packets may be ECN-capable (with either ECT(0) or ECT(1) codepoints set), nonces are placed only in SCTP packets containing one or more "new" DATA chunks. The sender maintains a mapping of the TSNs of transmitted DATA chunks with the nonce values placed in the respective packets. When multiple DATA chunks are bundled in the same packet, only one of the TSN's transmitted in that packet is mapped to the nonce placed in the packet. All other TSNs transmitted in the same packet are mapped to a nonce value of zero. (Implementation Note: An implementation may maintain the mapping of only the single TSN sent in each packet with the corresponding nonce. Said implementation will assume that all TSNs lying between two consecutive TSNs in the data structure are mapped to a nonce value of zero.) 5.3 Router Behavior For the ECN-nonce to function correctly, routers should behave as specified in RFC3168 [3]. 5.4 Receiver Behavior (Receive and Transmit) The receiver updates the value of its current nonce sum on receiving a packet carrying one or more new DATA chunks. Recall that the nonce sum is the cumulative one bit addition of the nonces received so far. Thus on receipt of a packet with one or more new DATA chunks a single bit addition of the current nonce sum and the received nonce is performed. The result is the new value of current nonce sum. In contrast to RFC3540 [5], the current nonce sum is also updated immediately when receiving out of order packets. SCTP is inherently a SACK based protocol, hence an SCTP sender can know exactly which packets had reached the receiver out of order. When a packet is marked with a Congestion Experienced (CE) signal, the original nonce is unknown to the receiver. The missing nonce value is ignored (or equivalently a value of zero is assumed) when calculating the current nonce sum. When the receiver sends a SACK chunk, the current nonce sum (the updated value as described above) is placed in the NS flag (defined in Section 3.2) of the SACK chunk. (Implementation Note: When sending an ECNE chunk and a SACK chunk in response to a CE marked packet that contained one or more DATA chunks, an SCTP endpoint should try to bundle the ECNE chunk and the Ladha, et al. Expires March 17, 2005 [Page 7] Internet-Draft ECN-nonce for SCTP September 2004 SACK chunk in the same packet.) 5.5 Sender Side (Receive) This section describes the sender's procedure for verifying the nonce sum returned by the receiver. The nonce sum is verified on the receipt of a SACK chunk which acknowledges new data, either via an advanced Cumulative TSN Ack field or by new Gap Ack Blocks. To verify the nonce sum, the sender SHOULD: o Calculate the expected nonce sum. This calculation is a single bit addition of the current nonce sum plus all the nonce values corresponding to the new data acknowledged. The nonce values are looked up from the local mapping of TSNs and nonce values maintained at the sender. o Set the current nonce sum to the value of expected nonce sum. o Compare the current nonce sum with the NS flag returned in the SACK chunk. The sender SHOULD disable checking of the nonce sum in the following three scenarios (checking of the nonce sum SHOULD be enabled after re-synchronization as described in Section 5.6) : o On detecting that a packet has been lost (i.e., after receiving four missing reports or after the expiration of the retransmission timer). Nonce checking is suspended because the receiver has admitted to missing packets and an ordinary congestion response is in effect. o On receiving an ECNE chunk from the receiver. Nonce checking is suspended because the receiver has admitted to a congestion experienced mark and an ordinary congestion response is in effect. o After sending a FORWARD TSN chunk defined in [7]. The FORWARD TSN chunk is used by SCTP senders that support the partially reliable extension to move the receiver's cumulative ack point forward. If nonce sum checking is enabled, and a SACK chunk is received with an incorrect nonce sum, then several scenarios are possible: (i) the ECNE and SACK chunks were sent in separate packets and the ECNE chunk was dropped by the network, (ii) the ECNE chunk was sent in a separate packet after the SACK chunk (i.e., the ECNE chunk is currently in the network), or (iii) the receiver is misbehaving and concealing Congestion Experienced (CE) signals. To detect unambiguously that a receiver is misbehaving, the sender waits until new data, sent after having received the incorrect nonce sum, is acknowledged. The sender also suspends checking of the nonce Ladha, et al. Expires March 17, 2005 [Page 8] Internet-Draft ECN-nonce for SCTP September 2004 sum during this period. If no ECNE chunk is received till the acknowledgement for the new data arrives, the sender can be certain that the receiver is concealing CE signals and thus misbehaving. 5.6 Re-synchronization of the Nonce Sum To enable proper checking of the nonce sums, re-synchronization of the sender and receiver current nonce sums is required in three situations. o Loss of one or more packets in a window of data: Re-synchronization of the sender and receiver current nonce sum occurs when new data sent after the congestion window was reduced is acknowledged via the Cumulative TSN Ack field. o After having received an ECNE chunk: Re-synchronization of the sender and receiver current nonce sum occurs when new data sent after the Congestion Window Reduced (CWR) chunk is acknowldeged via the Cumulative TSN Ack field. o After sending a FORWARD TSN chunk: Re-synchronization of the sender and receiver current nonce sum occurs when new data sent after the FORWARD TSN chunk is acknowledged via the Cumulative TSN Ack field. To re-synchronize, the sender simply sets its current nonce sum to the value of NS flag received in the SACK chunk. 6. Sender's Response The following discussion describes the response that SHOULD be applied (i) to a peer that does not support the ECN-nonce, or (ii) after having detected a misbehaving receiver. 6.1 Response to a peer that does not support the ECN-nonce o An SCTP endpoint that supports the ECN-nonce SHOULD disable ECN (i.e., stop setting the ECT codepoints for the association) if its peer does not support the ECN-nonce. o Optionally, an SCTP sender can further respond by rate limiting the association. Several such responses are possible; this document leaves them as a matter of policy that can be exercised by an endpoint. 6.2 Response to a misbehaving receiver o After having detected a misbehaving receiver, the SCTP sender SHOULD disable ECN for the rest of the association. o The minimum penalty to a receiver's misbehavior SHOULD be the equivalent of the response to an ECNE chunk. Ladha, et al. Expires March 17, 2005 [Page 9] Internet-Draft ECN-nonce for SCTP September 2004 o Optionally, an SCTP sender can further respond to a misbehaving receiver by setting the congestion window (cwnd) to one, thus re-probing the available bandwidth. This conservative action eliminates the incentive for a receiver to misbehave. Several such responses are possible; this document leaves them as a matter of policy that can be exercised by an endpoint. 7. Summary This document applies the ECN-nonce proposal RFC3540 [5] to SCTP. A single new parameter called the Nonce-Supported parameter and a single bit flag in the SACK chunk called the Nonce Sum (NS) have been described along with rules governing the sender and receiver side implementation. This document outlines the minimum response that a sender should apply to a receiver's misbehavior. 8. Security Considerations This document shares the same security concerns as RFC3540 [5]. 9. IANA Considerations A single bit flag in the SACK chunk called the Nonce Sum (NS) is used by this proposal, and must be allocated. One new parameter type code is defined by this document to be added to SCTP RFC2960 ('0x8001'). 10. Acknowledgements Paul Amer provided valuable feedback on an early version of this draft. 11 References [1] Blanton, E. and M. Allman, "Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions", draft-ietf-tsvwg-dsack-use-02.txt (work in progress), October 2003, . [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, Ladha, et al. Expires March 17, 2005 [Page 10] Internet-Draft ECN-nonce for SCTP September 2004 September 2001. [4] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, "TCP congestion control with a misbehaving receiver", SIGCOMM CCR, October 1999. [5] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [6] Stewart, R., Ong, L., Arias-Rodriguez, I., Poon, K., Conrad, P., Caro, A. and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Implementer's Guide", draft-ietf-tsvwg-sctpimpguide-08.txt (work in progress), February 2003, . [7] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M. and P. Conrad, "SCTP Partial Reliability Extension", draft-ietf-tsvwg-prsctp-01.txt (work in progress), August 2003, . [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. Authors' Addresses Sourabh Ladha Qualcomm 5775 Morehouse Drive San Diego, CA USA EMail: sladha@qualcomm.com Neil Spring University Of Maryland 4133 A.V. Williams Bldg College Park, MD 20742 USA EMail: nspring@cs.washington.edu Ladha, et al. Expires March 17, 2005 [Page 11] Internet-Draft ECN-nonce for SCTP September 2004 Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA EMail: rrs@cisco.com Ladha, et al. Expires March 17, 2005 [Page 12] Internet-Draft ECN-nonce for SCTP September 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ladha, et al. Expires March 17, 2005 [Page 13]