On Dec 19, 2012, at 6:21 AM, "Sriram, Kotikalapudi" 
<[email protected]> wrote:
>> On Dec 18, 2012, at 3:03 PM, "Sriram, Kotikalapudi" 
>> <[email protected]> wrote:
>>> Adding to Oliver's suggestion, it will be even more effective if, in the 
>>> "origin only" case,
>>> the mitigator announces a slightly more specific (e.g., two /17s  for a /16)
>>> if the maxlength of the victim's existing ROA permits it (of course, 
>>> victim’s AS is inserted
>>> as the origin AS as suggested).
>>> More specific wins, so the downside of one hop longer path length goes away.
>> 
>> Sound fine in theory, but will not work in practice.  *When* the original 
>> announcement is 
>> a (IPv4) /24 and all providers filter on announcements > /24 ... you're, 
>> umm, up a creek 
>> without a paddle if you don't have an ability to [immediately] originate the 
>> same /24 from a "proxy" AS.
>> 
>> Remember, there's a *lot* of "legitimate" more specifics out there already, 
>> primarily for the purposes of Traffic Engineering (TE).
> 
> The proposed solution would work fine in practice as well.

In who's world?  ;-)


> Whichever prefix (or more specific of it) that the mitigator and the victim 
> decide to 
> propagate (via the mitigator) for DDoS mitigation today in BGP, the same 
> prefix can also 
> be propagated with BGPSEC (and more securely). 

I thought we were just talking about _Origin_ Validation, not BGPSEC?


> If “all providers filter on announcements > /24” as you say, 
> then that is a constraint for the DDoS mitigation method under discussion 
> regardless of whether it is in BGP or BGPSEC.

Not true.  There are a variety of techniques available today, which will fail 
with Origin Validation.  By way of a couple of examples, here they are.  First, 
"Proxy AS" originates same /24 as "Victim AS".
1)  "Victim AS" then withdraws their /24 and falls back on an existing, 
covering aggregate, e.g.: /23, /20, etc. for delivery of the scrubbed traffic.
2)  "Victim AS" performs AS_PATH prepending of their /24 to make it less 
preferred compared to the new, shorter AS_PATH length "Proxy AS" origination.
3)  "Victim AS" uses their SP's BGP "Traffic Engineering" Communities to signal 
to their Service Provider(s) to lower LOCAL_PREF of the Victim's /24, inside 
their SP(s) AS, compared to the /24 being announced from "Proxy AS".

It's all about intent ...

-shane
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to