ECN Nonces for Stream Control Transmission Protocol (SCTP)ResearcherChapiSC29036USArandall@lakerest.netInternet-DraftQualcomm5775 Morehouse DriveSan DiegoCAUSAUniversity Of Maryland4133 A.V. Williams BldgCollege ParkMD20742USAnspring@cs.washington.eduThis document describes the addition of the ECN-nonce
RFC 3540 to the Stream Control Transmission Protocol
(SCTP) RFC 2960 . 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/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.Like TCP, SCTP RFC 2960 supports Explicit Congestion
Notification (ECN) RFC 3168 , and therefore is exposed to misbehaving receivers
that conceal congestion signals. The misbehavior includes the concealment of ECN Echo (ECNE) signals
which may cause an SCTP sender to be agressive and unfair to compliant flows. The ECN-nonce
RFC 3540 adds robustness to ECN signaling for TCP. This document
analogously applies the ECN-nonce to SCTP. The ECN-nonce can be used to protect against other misbehaviors as well,
such as optimistic acknowledgements , and false Duplicate
TSN notifications for more information discussions in RFC 3708 may
be helpful. The reader should be familiar with the ECN-Nonce as described in
RFC 3540 . This document describes only the SCTP-specific
aspects of the ECN-nonce.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 needed 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.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 RFC 2119 .Endpoints supporting ECN-nonce SHOULD use the following OPTIONAL parameter to
indicate that the ECN-nonce extension is supported.Type: 16 bit u_int0x8001, Indicating the Nonce-Supported parameter.Length: 16 bit u_int4, Indicating the size of the parameter.A single bit flag (NS) in the SACK chunk is defined as follows: 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.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.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:MAY include the Nonce-Supported parameter in the INIT-ACK chunk.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.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. 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.The sender's transmit behavior follows Section 3 of
RFC 3540 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. Only SCTP packets containing
one or more "new" DATA chunks can be marked as ECN-capable (with
either ECT(0) or ECT(1) codepoints set), so only these packets can
use the one-bit nonce. This is because control chunks are not
subject to congestion control, and thus a router's ECN-marking
of control chunks would not illicit a congestion response.
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 TSNs 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.)x
For the ECN-nonce to function correctly, routers should behave as
specified in RFC 3168 .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 RFC 3540 , 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 SACK chunk in the same packet.) 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: 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. Set the current nonce sum to the value of expected nonce sum. 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) : 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. 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. After sending a FORWARD TSN chunk defined in RFC 3758.
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. To enable proper checking of the nonce sums, re-synchronization of the sender
and receiver current nonce sums is required in three situations. 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. 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. 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. 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.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.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.After having detected a misbehaving receiver,
the SCTP sender SHOULD disable ECN for the rest of the association.The minimum penalty to a receiver's misbehavior
SHOULD be the equivalent of the response to an ECNE chunk.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.This document applies the ECN-nonce proposal RFC 3540 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.This document shares the same security concerns as RFC 3540 .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 RFC 2960 ('0x8001').Paul Amer provided valuable feedback on an early version of this draft.TCP congestion control with a misbehaving receiver