Subject: [Tsvwg] TCP ECN with nonces

From: [email-masked]
Date: Sat, 4 May 2002 20:57:03 +0300

Hi all!

	Just a quick comment that is on top of my head after reading the draft...

	The application of this draft is supposed to make life harder to cheating ECN-capable hosts... However, I'm not sure if the support of this nonce stuff is going to be compulsory in every ECN-capable host... Otherwise, a host can leave the NS always set to 0, and at the same time ignore the CE notifications, i.e., behaving as before (without nonces) and then continue masking the reception of CE notifications...

	I think that in these cases, when the NS bit is not set during connection set up, the data sender should in fact not use ECN at all... In other words, the actual initial negotiation should be:

	- The SYN sender sets the CWR and ECE bits in the IP header...
	- The SYN/ACK sender sets the NS and ECE bits...
	- The ACK sender sets the NS bit...

	Either you use nonces, or ECN should not be used... :-/

	That's all!

	BR Iván Arias Rodríguez

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

---

From: Neil Spring <[email-masked]>
Date: Sat, 4 May 2002 15:07:47 -0700

Hi Ivan,

Thanks for your comments.  Some of the issues you raise are
addressed in the draft, and the others are intentionally
left open as policy.

>	I think that in these cases, when the NS bit is
> not set during connection set up, the data sender should
> in fact not use ECN at all... In other words, the actual
> initial negotiation should be:

I think this is what we specify in the last paragraph of
section 5:

   The initial nonce sum is 1, and is included in the SYN/ACK and ACK of
   the three way TCP handshake.  This allows the other endpoint to infer
   nonce support, but is not a negotiation, in that the receiver of the
   SYN/ACK need not check if NS is set to decide whether to set NS in
   the subsequent ACK.

What a sender does when it knows the receiver doesn't
support the ECN-nonce is a matter of policy.  Some options
are in section 6.2:

   If the receiver has never sent a non-zero nonce sum, the sender can
   infer that the receiver does not understand the nonce, and rate limit
   the connection, place it in a lower-priority queue, or cease setting
   ECT in outgoing segments.

A sender could also decide to enable optional performance
optimizations based on advertised nonce support in the
initial exchange, perhaps using the larger initial window
or supporting Eifel only when the ECN-nonce provides an
assurance that the receiver is behaving properly.

> 	Either you use nonces, or ECN should not be used... :-/

Although receiver behavior is deliberately simple to
implement correctly, deliberate incompatibility with
rfc-3168-supporting hosts seems like a bad idea. Instead,
if receiver misbehavior were to become common, either
through faulty implementations or deliberate cheating,
the ECN-nonce provides an alternative to disabling ECN
entirely.

I hope this clarifies a little.  

thanks,
-neil

On Sat, May 04, 2002 at 08:57:03PM +0300, [email-masked] wrote:
> 	BR Iv?n Arias Rodr?guez