Subject: [Tsvwg] feedback on draft-briscoe-tsvwg-re-ecn-tcp-02.txt

From: Sally Floyd <[email-masked]>
Date: Wed, 2 Aug 2006 13:14:14 -0700

Bob -

I haven't finished reading this draft yet - other things keep coming to  
the
top of the todo list - but here is feedback on what I have read so far.

The basic feedback is on the status of the ECN Nonce, and on whether the
ECN Nonce should be abandoned in favor of re-ecn.  Not surprisingly,
I think that the current ECN Nonce is well worth defending.

------------------------------------------------------------------------ 
------------------------------
The current status of the ECN Nonce:
draft-briscoe-tsvwg-re-ecn-tcp-02.txt says the following:
"the most immediate priority for the authors is to delay any move of  
the ECN nonce to Proposed Standard status."

However, even though RFC 3540, "Robust ECN Signaling with Nonces",
is still experimental, the ECN Nonce also appears in other documents
that are Proposed Standard.  This should be reported in any revised
version of draft-briscoe-tsvwg-re-ecn-tcp-02.txt.

 From RFC 3168:
The definition of the four codepoints in the ECN field is in RFC 3168,  
which has
been Proposed Standard since September 2001:  (See Figure 1 in the RFC.)

"The use of two ECT codepoints essentially gives a one-bit ECN nonce
in packet headers, and routers necessarily "erase" the nonce when
they set the CE codepoint [SCWA99]."

 From RFC 4340:
"Each DCCP sender SHOULD set ECN Nonces on its packets and remember
which packets had nonces."

 From RFC 4341:
"The sender will use the ECN Nonce for data packets, and the receiver
will echo those nonces in its Ack Vectors."

 From RFC 4342:
"The sender can use Loss Intervals options' ECN Nonce Echoes (and
possibly any Ack Vectors' ECN Nonce Echoes) to probabilistically
verify that the receiver is correctly reporting all dropped or marked
packets."

------------------------------------------------------------------------ 
------------------------------
The usefulness of the ECN Nonce:

"draft-briscoe-tsvwg-re-ecn-tcp-02.txt" says the following:
"Although the nonce is a neat idea, its applicability seems too
limited to warrant space in the IP header;"

I would argue that the nonce is indeed sufficiently useful to warrant  
space
(one codepoint in the ECN field in the IP header) in the IP header.

* The ECN Nonce is quite useful for DCCP, with or without ECN-Capable
routers along the path.  For unreliable transport protocols, the  
receiver
might have a particular incentive to lie about whether a packet was
dropped in the network, and the ECN Nonce gives the sender
protection against this, without the sender having to trust that there
are appropriate re-ecn policers along the path.

* The ECN Nonce is useful for the sender to police feedback from the
receiver in environments that include the following:
   -  short flows, or
   - paths in a *local* network where there are no re-ecn policers along  
the
         path (because there might be no "ingress" or "egress" routers  
along the
         path), or
   -  environments where for some reason paired re-ecn policers are not
         deployed, or
   - paths where the congested link is the access link rather than
         between the re-ecn policers, or
   - perhaps in other cases that have not yet come to mind.

So, while I think that re-ecn is very interesting, and I see that it  
could be quite
useful for ISPs, I don't think it serves as a replacement for the ECN  
Nonce,
and I don't think it should prevent RFC 3540 from progressing to
Proposed Standard.

- Sally
http://www.icir.org/floyd/

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 09 Aug 2006 19:10:35 +0100

Sally,

You are perfectly correct that the DCCP RFCs also refer to the ECN nonce so 
I will certainly refer to them in future. And I'm sure other RFCs in the 
pipeline might be starting to reference the ECN nonce.

The ECN nonce is nice, but it only fixes a small subset of possible 
attacks. My general response is that it is well known that defenders are 
always at a disadvantage against attackers and against misbehaving traffic 
generally. An attacker only has to find one vulnerability that hasn't been 
fixed. If there are n possible vulnerabilities, and the defenders identify 
and patch 90% of n /everywhere/ (which would be extremely hard anyway), the 
probability that each vulnerability found by an attacker is /not/ defended 
against is 10%.

If we keep fixing every different class of attack that we can dream up with 
a piecemeal solution, we will always fail to defend against the next 
attack. And in the process we will require a few hundred different patches 
to *every* implementation of everything going, requiring loads of little 
patches to each protocol standard.

Re-ECN is intended to protect network layer resources. It is indended to fix
* SYN flooding,
* SMURF,
* UDP flooding,
* reflection DoS,
* DNS flooding,
* ACK flooding,
* frag attacks,
* etc etc
* as well as the misbehaving receiver attacks{note 1} that the nonce fixes,
* /and/ selfish unresponsive streaming, etc, etc.
(these are bold claims that we are trying to substantiate, but we have 
limited resources, which is why we need to build a community to test them)

{Note 1: I've been very careful to say re-ECN protects network layer 
resources, I'm not claiming it protects the sender's resources, because I 
believe the sender can protect itself without needing to use network layer 
bits, as I make clear in the detailed responses below.}

In fixing one small class of attacks, the nonce uses up 1/2 a bit in the IP 
header. The Internet architecture is very clear: only put things in a lower 
layer that are generic to all higher layer uses of it. The nonce is 
elegant, but it breaks that principle - big time. I don't think the nonce 
will ever be allowed to progress from experimental because it breaks that 
rule.

But I'm sure more RFCs will try to refer to it, because people have to say 
something in the security considerations section to get through IETF process...

...I think Tim Shepard said in the last tsvwg meeting that the IETF process 
tends to get in the way of architectural change (or some paraphrasing of 
that sentiment).

Detailed responses also inline ...

>I think that the current ECN Nonce is well worth defending.

We should certainly have a nonce in the /transport/ header, for the sending 
transport to protect /itself/. So the sender can know if a receiver sends 
an ack for a packet it didn't get.

But, we need to think clearly. If a router is marking packets with ECN, it 
is the router that is congested, not the sender. If the receiver doesn't 
tell the sender about those ECN marks, the router suffers. If the sender 
also gets congested, it can determine for itself how it shares out its 
workload between all its receivers. It doesn't have to share out the 
attention it gives each receiver soley by what it is told about network 
congestion. It should have its own view on its own /rate control/ before it 
also takes into account network /congestion control/. Admittedly it won't 
help if the information it is getting about the network layer is dishonest, 
but it still doesn't ahve to starve all the other receivers if it chooses 
not to.

If a nonce in the network layer protected the network layer, it would be 
worth doing. But the ECN nonce only protects the sender. That would be 
worth doing if it didn't use header space or we weren't tight on space. But 
it does, and we are.

The situation is serious. We mustn't fiddle around with piecemeal fixes at 
the expense of strategic steps.

>receiver in environments that include the following:

In this discussion, I am focusing on protecting the network (for everyone 
who is using it). You are focusing on protecting a sender. In actual fact, 
of course, we are both concerned about both. So I think this debate is 
really about whether network layer bits should be used to protect the stack 
resources of sending hosts. If we had the bits, I would agree we might as 
well protect the sender. But we are arguing over the best use of available 
bits.

All the examples you give are where the sender is protecting itself. I 
maintain that ought to be done at the transport layer, and only use the 
network layer as well if absolutely necessary.

>   -  short flows, or

Re-ECN is designed to protect the network (and the receiver or firewalls 
etc,) against floods of one packet flows. You can't get shorter flows than 
that. I don't understand why the sender needs protecting against short 
flows, when it is doing the sending.

>         path (because there might be no "ingress" or "egress" routers

A transport-layer nonce can do that.

>   -  environments where for some reason paired re-ecn policers are not

The ECN nonce doesn't protect the network in this case (or in any case). It 
protects the sender: we're arguing at cross purposes.

Paired re-ecn policers protect the network between them. And if that 
network doesn't deploy them, it doesn't get the protection. Re-ECN policers 
are not designed to protect the sender which I believe can protect itself 
using transport layer mechanisms.

>         between the re-ecn policers, or

I assume you mean an access link with one host on it. In this case, again, 
this is solely the concern of the sender.

>useful for ISPs, I don't think it serves as a replacement for the ECN

I'm not arguing that re-ecn is a replacement for the ECN nonce. I'm saying 
they aim to do different things. But the ECN nonce uses network layer bits 
to protect the sender, which I believe can perfectly well protect itself 
without using bits at the network layer.

>and I don't think it should prevent RFC 3540 from progressing to

Clearly, I differ.

However, I must make the very big caveat that nearly everything I've said 
about re-ECN is unproven, because we are trying to tackle a very large 
problem space, which isn't easy to give simple proofs about.

Also I've had to rush this reply, as it is between jsut finishing a paper 
for a deadline and going off on holiday for a few days. Hope it helps.

Cheers

Bob

>http://www.icir.org/floyd/

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Sally Floyd <[email-masked]>
Date: Thu, 10 Aug 2006 08:20:05 -0700

Bob -

> In fixing one small class of attacks, the nonce uses up 1/2 a bit in 
> the IP header. The Internet architecture is very clear: only put 
> things in a lower layer that are generic to all higher layer uses of 
> it. The nonce is elegant, but it breaks that principle - big time. I 
> don't think the nonce will ever be allowed to progress from 
> experimental because it breaks that rule.

I will respond to the rest of your email later, but I wanted to
respond to this paragraph now.  If you mean that things in the lower
layer should have generic semantics regardless of the higher layers,
I would agree, and that is true for the ECT(1) codepoint in the ECN
field in the IP header.  Its semantics are defined in RFC 3168,
a Proposed Standard document.

If, in contrast, you are implying that things only go in the lower
layer if they are equally of use to all higher layers, I don't think
that is true of the ECT(1) codepoint, in the same way that it is
not true of the diffserv codepoint in the IP header.  My assumption
is that the ECT(1) codepoint will be of use to almost all TCP and
SCTP traffic, in the same way that it is now standardized for use
by all DCCP traffic.  However, my assumption is that the ECT(1)
codepoint will be used by some but not by all UDP traffic, and that
it might not be used by any multicast traffic.  (Maybe it would be
used by multicast traffic, but I certainly haven't thought about
it.)  In my view, this doesn't mean that the ECT(1) codepoint breaks
any key principles of the Internet architecture.

- Sally

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Aug 2006 12:05:38 +0100

Sally

At 16:20 10/08/2006, Sally Floyd wrote:
>Bob -
>
>>In fixing one small class of attacks, the nonce uses up 1/2 a bit in the 
>>IP header. The Internet architecture is very clear: only put things in a 
>>lower layer that are generic to all higher layer uses of it. The nonce is 
>>will ever be allowed to progress from experimental because it breaks that rule.
>
>I would agree,

I didn't actually mean this. It's a useful design guideline tho.

>and that is true for the ECT(1) codepoint in the ECN
>layer if they are equally of use to all higher layers,

Yes, this is what I meant. Tho "equally" is too strong. Indeed, I would 
even say it is acceptable for a lower layer function to not be useful at 
all to a small minority of higher layer functions.

For instance, the source address isn't always useful in the network layer 
(and could be in the transport layer for those transports that don't 
process error msgs from the network).

>I don't think
>not true of the diffserv codepoint in the IP header.

DS is a bad example, because few single applications requires a choice of 
DSCP, but as long as different apps require different choices, the DS field 
is generically useful to /every/ app, even if many of them choose BE.

The fragment ID field is perhaps a better example.

>My assumption
>by all DCCP traffic.

My concern is not that some types of transport will and some won't use the 
nonce. My concern is that the nonce is only essential (as opposed to 
useful) for a rather esoteric subset of the uses each transport might be 
put to.

The only trust scenario where the nonce makes sense is where a router 
trusts a sender to defend the router's interests. I believe I have 
successfully argued away the other cases you gave in your e-mail (you said 
you would reply later about them).

Back in the mid 1990s, a similar argument raged in the OO software security 
community about 'object self-defence'. The issue was between:
- should each software object include its own self-defence
- or would it be more generic to define a separately encapsulated security 
object

The point at issue was that there were trust scenarios where one object 
would trust another to do its security for it (e.g. proxy authentication), 
but if a separate security object was defined for these special trust 
scenarios, it had very different structure from that required when an 
object defended itself.

The argument was unresolvable, as it seemed you needed both cases - there 
wasn't a more generic case that encapsulated the other.

The outcome is the same in the case of the ECN nonce:
a) If a sender wants to defend a congested router from potentially 
malicious receivers, the ECN nonce is a useful tool.
b) If a sender wants to rely on network congestion information to optimally 
share out its /own/ resources, the nonce is also a useful tool.
c) But if the network doesn't trust senders generally to defend its 
congested routers, the ECN nonce isn't useful at all and a different 
mechanism is needed.

That's why I say the nonce isn't generic. In an Internet environment, every 
router is exposed to every sender in the whole internetwork. Even if a 
router trusts some senders to respond correctly to its congestion signals, 
it generally doesn't trust /every/ sender throughout the Internet.

In an ideal world, the right answer would be to standardise both 
mechanisms, treating the ECN nonce as a useful optimisation for the 
relevant trust scenarios. I would really like to do that.

The problem here is that we don't have an ideal world. We have pressure on 
header space. In this case, a) and b) above are luxuries compared to c) 
which is sufficient protection for all circumstances, even tho the sender 
can't be as efficient in case b).

>However, my assumption is that the ECT(1)

I hope I've explained why it does, in my view.

It would be useful if someone else came in on this discussion, because 
otherwise we are in danger of descending into "Is." "Isn't." "Is." "Isn't." 
"Is." "Isn't."

It is possible (tho v unlikely) that, if we were allowed to move the ECN 
nonce to some other coding while preserving its function, we might be able 
to find a way to get re-ECN to co-exist completely independently of the ECN 
nonce. I am willing to invest some effort in this, but would it be worth 
the effort?

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.    +44 1473 645196