On Wed, May 02, 2018 at 08:20:22PM +0200, Gert Doering wrote:
On Wed, May 02, 2018 at 06:11:23PM +0000, Job Snijders wrote:
On Wed, May 02, 2018 at 08:07:16PM +0200, Gert Doering wrote:
The information I was looking for is nicely visible, though... and what I was afraid I'd see... too much "N". The only "I" is something I was aware but had forgotten about ;-) - a sink-a-more-specific-/24 test that nicely exposes the problem of "strict /22" ROAs.
"problem" - just create a separate additional ROA for the /24!
I should have worded this as "the issue you run into if you create a single ROA with a fixed length *and* then decide to announce something else" - and indeed, since MaxLength opens room for spoofed-source-with-more-specific hijacks, this is why we set up our ROAs strictly.
I recommend to make separate ROAs for everything you announce in BGP. The use of MaxLength is easily abused. See this Internet-Draft for more considerations:
How would you recommend handling the case
"normally I only announce a /16, but in case one of our customers i DDoSed, I want to announce the affected IP address as part of their /24 out of upstream-that-does-regional-blackholing"?
If I create the /24 ROAs up front, I'm back in square one ("while I am not announcing the /24, someone else could hijack with a faked origin AS").
If I do not create the /24 ROAs up front, I have propagation delays (and might not be able to reach the RIPE RPKI tool at all while the DDoS goes on).
*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. 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. Kind regards, Job