>> 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. >
With the proposed solution (in BGPSEC), it is possible to announce (for the DDoS mitigation) any /17 or /22 or /24 that the mitigator needs to announce. The victim has to have set the maxlength long enough in anticipation of this (for coordination with the mitigator). Shane pointed out perhaps “all providers filter on announcements > /24”. That is a constraint for the DDoS mitigation method under discussion regardless of whether it is in BGP or BGPSEC. > > 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. > I am curious, if the mitigator announces a more specific (longer length) prefix, then how do they leave a path open to deliver the scrubbed traffic back to the victim’s server residing in that more specific prefix? All the ASes around the mitigator would be directing any traffic for the victim’s server towards the mitigator and not towards the victim. Well, may be the victim has an alternate server in the address space not impacted by the announcement of the more specific? Or, there is a back channel (like a VPN) to deliver the scrubbed data back to the victim? >> More specific wins, so the downside of one hop longer path length goes away. > > More specifics override longer prefixes? Not sure what you mean. More specific and longer prefix mean the same thing. > >> 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. > -- snip -- > 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. > If you mean the DoS attacker is also leaking the more specific route announced by the mitigaor, then he (the DoS attacker) would be quite a fool, isn’t it? It would seem he is then conducting DoS on his own router (in the data plane). Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
