Network Working Group S. Ladha Internet-Draft PEL/U. of Delaware Expires: July 29, 2004 N. Spring U. of Washington R. Stewart Cisco Systems, Inc. January 29, 2004 ECN Nonces for Stream Control Transmission Protocol (SCTP) draft-ladha-sctp-nonce-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/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 July 29, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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 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/ Ladha, et al. Expires July 29, 2004 [Page 1] Internet-Draft ECN-nonce for SCTP January 2004 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) . . . . . . . . . . . . . . . . . . . . 7 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 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Ladha, et al. Expires July 29, 2004 [Page 2] Internet-Draft ECN-nonce for SCTP January 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 uses 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 July 29, 2004 [Page 3] Internet-Draft ECN-nonce for SCTP January 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 July 29, 2004 [Page 4] Internet-Draft ECN-nonce for SCTP January 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 ECN-nonce support to the peer. Ladha, et al. Expires July 29, 2004 [Page 5] Internet-Draft ECN-nonce for SCTP January 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. For clarity, the operation has been described with unidirectional traffic, i.e. one SCTP endpoint as the sender and the other SCTP endpoint as the receiver. 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. Ladha, et al. Expires July 29, 2004 [Page 6] Internet-Draft ECN-nonce for SCTP January 2004 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 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. 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 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 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, an SCTP endpoint should try to bundle the ECNE chunk and the SACK chunk in the same packet.) 5.5 Sender Side (Receive) This section describes the sender's procedure for verifying the nonce Ladha, et al. Expires July 29, 2004 [Page 7] Internet-Draft ECN-nonce for SCTP January 2004 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 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. Ladha, et al. Expires July 29, 2004 [Page 8] Internet-Draft ECN-nonce for SCTP January 2004 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. 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 Ladha, et al. Expires July 29, 2004 [Page 9] Internet-Draft ECN-nonce for SCTP January 2004 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. 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, September 2001. [4] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, "TCP congestion control with a misbehaving receiver", SIGCOMM CCR, October 1999. Ladha, et al. Expires July 29, 2004 [Page 10] Internet-Draft ECN-nonce for SCTP January 2004 [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-10.txt (work in progress), November 2003, . [7] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M. and P. Conrad, "SCTP Partial Reliability Extension", draft-ietf-tsvwg-prsctp-03.txt (work in progress), January 2004, . [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 PEL/U. of Delaware Protocol Engineering Lab EMail: ladha@cis.udel.edu Neil Spring U. of Washington EMail: nspring@cs.washington.edu Randall R. Stewart Cisco Systems, Inc. 8725 West Higgins Road Suite 300 Chicago, IL 60631 USA EMail: rrs@cisco.com Ladha, et al. Expires July 29, 2004 [Page 11] Internet-Draft ECN-nonce for SCTP January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Ladha, et al. Expires July 29, 2004 [Page 12] Internet-Draft ECN-nonce for SCTP January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ladha, et al. Expires July 29, 2004 [Page 13]