[Tsvwg] comments on draft-ietf-tsvwg-tcp-nonce-00
Neil Spring <nspring@cs.washington.edu> Sat, 07 April 2001 00:49 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23875 for <tsvwg-archive@odin.ietf.org>; Fri, 6 Apr 2001 20:49:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21545; Fri, 6 Apr 2001 20:45:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21515 for <tsvwg@ns.ietf.org>; Fri, 6 Apr 2001 20:45:09 -0400 (EDT)
Received: from poplar.cs.washington.edu ([128.95.2.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23825 for <tsvwg@ietf.org>; Fri, 6 Apr 2001 20:45:09 -0400 (EDT)
Received: from nspring by poplar.cs.washington.edu with local (Exim 3.12 #1 (Debian)) id 14lgqk-0003rE-00; Fri, 06 Apr 2001 17:45:10 -0700
Date: Fri, 06 Apr 2001 17:45:10 -0700
To: tsvwg@ietf.org
Cc: ely@cs.washington.edu, djw@cs.washington.edu
Message-ID: <20010406174510.A14796@cs.washington.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
From: Neil Spring <nspring@cs.washington.edu>
Subject: [Tsvwg] comments on draft-ietf-tsvwg-tcp-nonce-00
Sender: tsvwg-admin@ietf.org
Errors-To: tsvwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
X-BeenThere: tsvwg@ietf.org
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 tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg