Re: [re-ECN] Preferential Dropping

[Bob Briscoe <[e-mail]>]

Pete,

Still off the topic of chartering...

At 21:11 17/05/2010, McCann Peter-A001034 wrote:
>Hi, Bob,
>
>Thanks for the explanation.
>
>Bob Briscoe wrote:
> > The analysis I did on this showed that re-ECN can raise the bar
> > against DDoS so that the army has to be N times bigger to achieve the
> > same *sustained* attack force, where N=1/p and p is the 'normal'
> > level of congestion in the network. E.g. if normal congestion is
> > 0.001%, a sustained attack against a re-ECN internetwork has to be
> > 100,000 times bigger to cause the same damage as it could against a
> > network without re-ECN.
> >
> > Obviously, there are assumptions and details, but that was the
> > take-home message. If anyone wants more details, just ask.
>
>I'm curious about your definition of "damage".  Was it just "causing
>a given loss probability on a particular target link"?

Correct

>It seems like
>there are other costs in a DDoS attack on a re-ECN enabled network, such
>as causing well-behaving users to consume their black token allotment,

Correct. Or slowing their bit-rate to consume 
their token allotment more slowly.

>making them less able to respond to congestion for some time after the
>attack.

I think you mean "less able to contribute to congestion..."

>But then, I guess the philosophy of re-ECN is that if you
>experience
>congestion, you are also causing it, so those well-behaving users that
>marked near 100% should also be "held responsible" for the DoS attack...

Indeed.

I have pointed out before that attacking during a 
flash crowd is the most cost-effective strategy 
an attacker can adopt — then the infrastructure 
is most valuable to most genuine users, and it 
takes least extra malicious effort to tip it into 
overload. See <http://www.bobbriscoe.net/projects/refb/#refb_dplinc>

Imagine three types of users in such a situation:
1) a 'genuine' member of the flash crowd who slows in response to congestion
2) a 'genuine' member of the flash crowd who is unresponsive to congestion
3) an attacker who is unresponsive to congestion

IMHO it is not unreasonable for the system to 
throttle down 2 & 3 the same, at least by 
default. They may have different intent 
(selfishness as opposed to malice), but they have 
the same outward effect on everyone else.


>My assumption was that this dropping should happen at any congested
>link, not just the egress, for maximum effectiveness.  (Btw, is this
>different from the behavior you propose for an "egress dropper"?  That
>wasn't clear to me from the documentation.)

Sorry; I'll be clearer: This OPTIONAL 
preferential dropping could be at any IP-aware 
link vulnerable to DDoS. It's not needed at all 
for re-ECN to work. It's not proposed for initial 
chartering (this thread is for light techie 
relief). Nonetheless, if a network is using 
re-ECN already for other reasons, and a queue 
under attack has to drop stuff, re-ECN is 
designed so that a router can easily distinguish 
stuff not obeying the protocol and drop it first.

The 'egress dropper' proposed in 
draft-briscoe-re-ecn-tcp-motivation is very 
different. It uses drop to punish cheating (not 
because it's overloaded itself). This egress 
dropper (or something like it) is needed to 
asssure the integrity of re-ECN markings against 
cheaters. It's only needed at the egress of the 
internetwork, not at every link. A simplifed 
variant could be useful at an interior egress 
(border), but may not be necessary.


>How often do you think this technique would need 
>to be invoked on a core Internet router?

You might be able to protect core routers from 
DDoS by good network design (e.g. ECMP and 
over-provisioning). But if this still isn't 
enough, preferential drop based on re-ECN might 
be the lightest possible *self-protection* a core 
router could adopt against DDoS. It doesn't rely 
on the addresses in packets so we claim it is 
robust against SYN attacks and spoofed source 
addresses (unlike the scrubbing solutions used 
today, which rely on attacks not bothering to obfuscate themselves very well).

>Do you agree that an out-of-band per-flow signaling
>solution
>would have difficulty supporting this feature, if the core routers
>needed to implement it?

I can't imagine how an OOB solution would allow 
the data plane to discriminate attack traffic, but...

<RANT> <!--not against you-->
We cannot know whether an OOB per-flow signalling 
solution support any feature, because it's currently vapourware.

People have proposed systems of echo-reflectors 
to check the QoS performance of networks. None 
I've seen have been designed to be robust against 
even simple cheating strategies. Katarina 
Argyraki's Loss & Delay accountability idea is 
the only example I know designed to be robust 
(see my posting to Stewart Bryant on 17-May). But 
all these things only address the easy half of 
the ConEx problem: holding networks accountable 
for too little capacity, not also holding users 
accountable for too much traffic. Despite this, 
they are already highly complicated beasts.

It took literally years to solve the really hard 
problem of making inter-domain congestion 
exposure robust to self-interest and attacks, 
including DDoS. Then as people came up with some 
really perverse attacks against it, we spent a 
further year working out how to harden it (and 
simplified it in the process). I'm not saying 
it's perfect, but it's pretty damn solid.

Hey, I'm open to someone solving this problem a 
different way. But let's see it before we believe it.

Yes, I'm grateful to the guys from the IESG who 
have opened up with their concerns and engaged in 
debate. But, let's keep this in perspective...

Re-ECN has been accused of being research. I hope 
it's accepted that was a confusion - "an output 
of research" rather than "still needing more research"....

But now we're discussing an OOB solution, without 
even a vaguest whiff of where a design might 
start, let alone any research, evaluation, running code, yada yada.

</RANT>



>(I agree this is all out-of-scope of the charter discussion and that
>preferential dropping shouldn't be in the initial charter anyway.  I
>am just trying to understand whether this feature would be a motivation
>for per-packet as opposed to out-of-band signaling solutions).

Understood

Cheers



Bob


>-Pete

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design