Re: [Tsvwg] ECN nonce snag in TCP ESTATS MIB

[Bob Briscoe <[e-mail]>]

Matt, Sally,

At 04:50 29/01/2007, Sally Floyd wrote:
>Matt -
>
>>The document draft-ietf-tsvwg-tcp-mib-extension has been stalled due to a
>>"DOWNREF",  a normative reference from a standards track document to
>>to a less mature document.  In this case to an Experimental Protocol, 
>>RFC3540,
>>Robust ECN Signaling with Nonces.
>...
>>There are two obvious approaches to fix this:
>>1) Pursue the downref procedure in RFC 3967.  This entails writing a
>>justification for the downward reference and re-issuing the IETF last call.
>>2) Deleting the object entirely.  Since this is a substantial technical 
>>change
>>to the document, it requires re-issuing the TSVWG LC and possibly the 
>>IETF LC.
>>
>>I am willing to pursue either approach, however I think it would be best to
>>match the likely ultimate trajectory for RFC 3540.

Reasonable approach, but difficult to judge...

>>My questions:
>>Are there any known implementations of RFC3540 in the field?
>>
>>Can somebody provide some pointers to either dependent or alternative
>>nonce mechanisms?

back in Nov '06 I promised an alternative at the transport layer. It's 
nearly complete (but internally we also still have to get clearance to 
publish).

As I said when I promised it, it deals with the problems of receivers 
suppressing losses (including optimistic acks and split acks), but not ECN 
(which we claim re-ECN would cover).


>>Given that RFC 3540 conflicts with RE-ECN, what is (your opinion of) the
>>likely trajectory for RFC 3540?
>
>My apologies for the long delay in getting to this.  If this is still an 
>open question,
>my preference would be for (1), writing a justification for the downward 
>reference,
>and keeping the ECN nonce item in the TCP MIB.

I have no preference. All I'll try to do is advise on the likely course of 
RFC3540 and re-ECN, so the TCP ESTATS MIB authors can judge what is best.

1/ Our considered opinion of the worth of the ECN nonce is given in 
Appendix I of <draft-briscoe-tsvwg-re-ecn-tcp-03.txt>.

In summary: "Delaying the ECN nonce is justified because the applicability 
of the ECN nonce seems too limited for it to consume a two-bit codepoint in 
the IP header. "

By 'too limited', we mean it is no longer sufficient to consider that 
senders will protect the network against abuse. When the nonce was first 
proposed, that seemed reasonable, given most big senders were managed 
servers. Now nearly everyone's a big sender.
See the diag in slide 6 that I showed at IETF-67:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0611ietf/0611briscoe-tsvwg-re-ecn.pdf>

Another argument (new since in Appendix I): A sender cannot use the ECN 
nonce to detect a cheating receiver if the receiver claims not to support 
the ECN nonce. All it can do is throttle all receivers that don't support 
the ECN nonce (currently it would have to throttle everyone except Neil). 
There's no alternative deployment incentive to get round this deployment 
bootstrap killer.

2/ On the other hand, re-ECN is still a long way from general acceptance - 
I think in most people's minds it is at the stage of "sounds interesting, 
but it has major implications so we need to understand these better".

I'm second-guessing voter's reasoning, but I suspect that was why the straw 
poll at IETF-67 preferred RFC3540 to be held back at experimental for 
longer, in case the ECT(1) codepoint in the IPv4 header could indeed be 
better used for re-ECN (given it polices senders as well as receivers).

I'm acutely aware that what re-ECN claims to do is fix a very hard problem. 
Doing this in the minimal available space left in the IPv4 header was never 
going to be easy. Originally our target was for IPv6 or a 'future Internet 
architecture'. Then we came up with a way it could just be squeaked into 
IPv4 as well.

I live in fear of an attack on re-ECN being published that no-one can fix 
within the available space. Then we'd have to return to the original target 
of something like re-ECN in IPv6 and 'future architectures'. But all 
security solutions are in this constant state of uncertainty (HMAC & SHA 
hash algorithms being current cases in point).

---
Either way, Neil Spring's right that we have the ECN nonce innoculation 
sitting on the shelf if we need it.

I know Neil didn't like the conclusion "too limited for IP header." But I'd 
like to hear Neil's thoughts on each of the critiques of the ECN nonce that 
we wrote into Appendix I of <draft-briscoe-tsvwg-re-ecn-tcp-03.txt>. 
Despite appearances, I'm willing to shut up if the carefully thought 
through points I make are successfully argued down.


>I don't know of any implementations
>of RFC 3540.  However, my own prediction would be that RFC 3540 would
>eventually become Proposed Standard, regardless of the fact that RE-ECN
>conflicts with the ECN Nonce.  For a first draft of mine on why RFC 3540
>should go to Proposed Standard (not yet submitted as an internet-draft), 
>you could see
>the following:
>   "http://www.icir.org/floyd/papers/draft-floyd-tsvwg-ecn-nonce-00a.txt"

Sally, I understand this is not a complete draft, but I think it needs to 
address each critique we made of the ECN nonce in Appendix I mentioned 
above. Currently it just says the nonce is good without rebutting anything 
that's been said against it.

I'm not saying re-ECN's perfect, but I don't think the criticism you've 
chosen is valid. You seem to be saying re-ECN doesn't protect parts of the 
network that haven't deployed it. That's like saying Yale locks are crap 
because burglars can break in to your porch if you only install a Yale lock 
on the inner door of your porch.

Perhaps you meant it might be hard to deploy at the very edge?


Bob


____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]