>> 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?
Well, we were talking about both. But we can talk one at a time. It is well known that origin_only_validation has limitations in general (e.g., spoofed origin, subprefix hijack with spoofed origin, etc.). In fact, the DDoS mitigation being discussed here is taking advantage of those limitations in the origin_only_validation case. BGPSEC overcomes the limitations of origin_only_validation, and works quite cleanly (IMHO) in this DDoS mitigation scenario for the benefit of the victim and the mitigator. > >> 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 ... I read what you described above quite carefully twice. But it is not clear to me how origin_only_validation fails or interferes in any of the methods you outlined above. I am sure you recognize by now that with origin_only_validation in place, in the proposed solution, the mitigator needs to spoof the victim’s origin in order to pass ROA validation. (Again, if we advance to path validation, then the proposed solution in BGPSEC does not require the origin spoofing etc. ... we have already gone over that.) Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
