On May 2, 2018, at 2:29 PM, Job Snijders <job@ntt.net> wrote:
If your DDoS mitigator depends on BGP hijacking to deliver their scrubbing services to you ... indeed you'll have challenges. I have no good answer, this is an architectural flaw where one has to make a trade-off between wanting to protect against hijacks and having the ability to insert more-specifics for legitimate purposes.
The DDoS mitigator might try announcing the affected prefix’s more specific, faking the legitimate origin’s AS as the origin. If BGPSec is not around to protect the path, it would work/help. (I think this is what Matthias was saying, also, which makes this a +1.) Also - current best practice to protect origination is to use route filters based on some IRR or the other. In the current world, the DDoS mitigator has the same problem - to authoritatively originate the affected more specific prefix, the mitigator has to wait for propagation from the IRR. I’ve been told one strategy is to have a large collection of peers who understand that they should be forgiving of the announcements from the mitigator. [And the bad-guys know this as well. Lots of cases where the mis-origination is registered in some IRR or the other. And in some cases, the explanation from the embarrassed upstream of the mis-originator was that they were told the mis-originator was a DDoS mitigator.] That same large-number-of-very-understanding-peers strategy works for DDoS mitigation in an RPKI OV world. I’m not advocating that strategy, by the way. —Sandy
Some providers can siphon off the victim IP addresses to scrubber devices within the confines of the autonomous system - and the outside world (the DFZ) never sees these more-specifics.