On Dec 18, 2012, at 5:03 PM, Sriram, Kotikalapudi 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).
While I appreciate your consideration, this won't work. There are lots of practical reasons why, e.g., diverting a /17 worth of traffic through a DDoS mitigation service is a bad idea when only a subset (e.g., a /32 or /24) is under attack. Being as surgical as possible is important, for lots of operational and financial reasons. FWIW, I can do "origin validation" with access/filter lists and IRRs today, I don't need other parties to control how my prefixes are routed everywhere on the Internet, like folks appear to be aiming to "help me with" here. And Randy, longer prefixes from "mitigator" with victim withdrawing (i.e., what I think you were trying to convey with "Forget a out kink with longer prefixes etc. victim withdraws.") would leave you with no place to deliver the legitimate "scrubbed" traffic, and that might well be a problem, unless you were intending to effectively complete the attack. > More specific wins, so the downside of one hop longer path length goes away. More specifics override longer prefixes? Spoofed origins circumvent "origin validation"? Meh. We knew this already, and I suspect we're not the only ones... > And in the full path validation case, the victim forward signs a more > specific > (if permissible by existing ROA) to the mitigator. The victim also sets > pCount = 0 for this update. Assuming they're capable of "forward signing" and distributing an update to the "mitigator"'s BGP speakers -- something I definitely wouldn't count on with the scale and virulence of attacks today. YMMV... That said, in an RPKI-enabled BGPSEC world I suppose the mitigator could "leak" the route with some degree of impact, as you point out. As could attackers, of course, thereby allowing the leak itself to trigger the DoS on the target, but we've been there as well already. Additionally, as Chris keeps pointing out, it'd be trivial these days for an attacker to drop 10 or 20 or 100G of packet love on an RIR and just break the targets routing via RPKI DDoS - that's an attack vector I don't have to worry about today (beyond the SIDR work). Or with a fully functional RPKI-enabled BGPSEC simply "leak" their route and blackhole the traffic, molest selectively, or "other"), but again, we know this... I guess the point here is that I really don't need you to solve this problem for me Sriram, I just don't want you to add a bunch of baggage that introduces more vulnerabilities and fragility, breaks my agility, and yet solves very little of any problem I actually care about as an operator. BTW: Is there's some actual bound on the number of use cases (i.e., actual operational engineering objectives and techniques employed today) such as this where changes to "policy" in the RPKI may need to occur and be propagated to all RPs in less than hrmm... many hours[?]. Perhaps we should hit up the NOG lists and ask folks about their requirements for making changes, or learn from systems impacted from just this in the past (e.g., IRRs). Of course, I suspect it's largely futile given Randy's comments about horses and barns et al.., and he really was serious about "running code and running away!". Problem is, people have to deal with the residue; Randy is usually on the unhappy side of this equation... -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
