[routing-wg] looking for online RPKI dashboard / looking glass?
Job Snijders job at ntt.net
Wed May 2 20:29:52 CEST 2018
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: > > > > https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen > > 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