On Wed, 2 May 2018, Job Snijders wrote:
*scratch head*
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.
RPKI origin validation does not protect against path manipulation.
Even if you announcing the /24, someone else could hijack with a faked origin A. It just gets more difficult because there are competing announcements.
For path validation there are other tricks!
yeah ... my point was that the previous discussion was a bit misleading. If you want that ROAs comply only with the current BGP annoucements, you have to deal with a (ROA) delay when you change the origins. If you want that ROAs comply with potential BGP annoucements, you should create the /24. It's not such a head scratching decision.
It is a bit of a poor man's solution, but so much better than nothing. It only protects a subset of all ASNs, but combined with RPKI Origin Validation this would be extremely effective.
https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pd... https://www.youtube.com/watch?v=CSLpWBrHy10
Thanks for the pointers. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl