Re: [re-ECN] Preferential Dropping

["McCann Peter-A001034" <[e-mail]>]

Hi, Bob,

Bob Briscoe wrote:
> Pete,
> 
> Still off the topic of chartering...

Indeed.  Thanks for the discussion, it is helping me wrap my brain
around this problem space.
 
> 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

Based on the statement above and reading the paper you point to below,
it seems you are making an assumption about the token bucket parameters
of the ingress policing and their relationship to the access network
link speed and the link speed of the congested, target link.  If you
take the 'normal' level of congestion as a setpoint for the ingress
policer, your example above seems to imply that the token bucket rate
would be .001% of line rate for a given customer.  As for the depth
of the token bucket, I have no intuition about how to pick a good value.

If we consider operating regions where the token bucket is fast and
deep, the access link speed is high, and the target congested link
is very bandwidth constrained, we could have a situation where the
link remains near 100% congestion for a long period of time or even
in steady state, when senders are marking exactly at their token
bucket rate, even when N isn't inordinately large.  Even with
preferential
drop we might be forced to start discarding packets with positive worth.

Perhaps this is an example of a link that was poorly dimensioned for
the expected load, but that kind of argument seems to be a variant
of the "just overprovision all the links" point of view.

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

Yes, thanks.  I guess the effectiveness of this attack depends on the
relative depth of the token buckets.
 
> 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.   

Regardless of intent, I wonder if a better outcome could be achieved
if the owner of the congested resource made a per-flow admission control
policy decision instead of lumping all the flows together in one
statistical
drop bucket.  Especially for inelastic flows, it would be better to
time-shift in units of whole flows rather than start dropping a fraction

of the traffic across all flows.

The use of Re-ECN marking to resolve contention for a congested link
is kind of like a game of chicken.  If N is sufficiently large, and
all parties are willing and able to mark up to 100% of their flows,
then no one gets out of the way and the system collapses in overload.
Undoubtedly, Re-ECN would make this situation (possibly much) less
likely due to the damping effect of the ingress policers.  However,
it still wouldn't be entirely safe to put a mission critical resource
behind a low-bandwidth link (e.g., a 56kbps modem) exposed to the 
Internet.  That situation still seems to require some sort of security
gateway in front of the link to discard unauthorized traffic, and a
signaling protocol to establish state in that gateway.

> 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. 

Agreed; I am just trying to figure out whether Re-ECN completely
eliminates the need for protocols like RSVP or NSIS (or even non-e2e
IKE, to the extent that IPSec gateways are used to prevent DoS) or 
whether a signaling protocol would still be needed to establish 
per-flow state in middleboxes for the purpose of DoS prevention and
congestion control in general.  The case of a link that is a few
orders of magnitude slower than the average access link still seems
to require this.  Perhaps such a protocol could be tweaked to work
in concert with Re-ECN; for example, you could directly carry the
path congestion metric p in the signaling, maybe eliminating the need
to fight over the evil bit.  This would allow for policing on ingress
as well as auditing on egress.  On the other hand, you would lose the
ability to do inter-domain settlement and preferential dropping without
keeping per-flow state.  You would also have to invent some way to tie
the signaling to the bearer flow (robust against spoofed headers).  It 
might be desirable in some circumstances to interact with your first-hop

policer; e.g., to request a token bucket upgrade in the event of an 
emergency.  If the congestion is near the receiver, then it might be
good to give that receiver some input into which flows get admitted.

Do you see co-existence between Re-ECN and NSIS?  Or is the signaling
just a big can of worms that isn't justified given the lower
effectiveness
of DoS in a Re-ECN enabled network?

-Pete