> > 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. 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). 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. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
