Subject: [Tsvwg] comments on draft-ietf-tsvwg-tcp-nonce-00

From: Neil Spring <[email-masked]>
Date: Fri, 6 Apr 2001 17:45:10 -0700

Issues discussed at the IETF meeting regarding
draft-ietf-tsvwg-tcp-nonce-00.txt

Viewgraphs from the presentation are available at:
http://www.cs.washington.edu/homes/nspring/talks/ietf-ecn.ps.gz
http://www.cs.washington.edu/homes/nspring/talks/ietf-ecn.pdf
Please let me know if you have trouble viewing or printing them.

Fragmentation
-------------

The ECN nonce does not protect fragments: if a fragment is
marked, the receiver can reconstruct the nonce.  Consensus
was to recommend setting the DF bit when using the nonce.
This may mirror language in the ECN specification relating
to the DF bit.

Negotiation
-----------

Negotiating the use of the nonce was deemed to be a
non-issue.

Nonces over Bytes or Packets
----------------------------

Disabling ECN for retransmissions allows nonces to apply
on a per-packet basis instead of on a per-byte-range
basis as was described in the draft.  This simplifies
implementation.

SACKs
-----

The nonce does not enforce /timely/ delivery of CE signals
from out of order packets that are SACK'd.  I asserted
that this did not leave any openings to misbehavior,
since SACK's are only an optimization for retransmission
and do not encourage the sender to send more quickly.
The cumulative nature of the nonce sum protects against
using SACK to conceal a congestion mark indefinitely.

SCTP
----

Discussion about how to apply the ECN nonce to SCTP
started.  Comments would be welcome.  SCTP appears able to
support such an extension without much difficulty.  We plan
to discuss ECN-nonce functionality with SCTP implementors
to create a separate document defining its behavior, and
are also looking for other transport protocols that would
benefit from the nonce.

Randomness
----------

David Black noted in off-line comments that whatever
pseudo-random number generator used to select nonces
will have inherent limitations and does not make any
security-related guarantees.  This will be added to a
security considerations section.

What to do at the sender when the nonce sum is incorrect
--------------------------------------------------------

Discussion on this issue would be very helpful.  This is
a policy question that can be made on a server by server
basis, though reasonable recommendations should probably
be made in a standards document.

There are two occasions when the nonce sum returned to
the sender can be wrong.
 1) the receiver attempts to conceal a congestion signal.  
 2) the receiver doesn't know about the nonce.
 
An attempt to conceal a congestion signal should probably
be punished; we suggest reducing cwnd and ssthresh to 1.

Lack of nonce support can be checked by observing the nonce
sum bit to see if it reacts to varied ECT code points.
Nonce support can be encouraged either by 1) disabling
ECN for nonce-less receivers, or 2) (Sally's suggestion)
providing higher priority service to nonce-supporting
receivers.  This choice may depend on deployment issues.

comments welcome.
-neil

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg