Oops, I mean with a script which removes such routes if there is an encompassing route which a different upstream takes, as obviously the more-specific would otherwise still win.
Matt On 7/6/19 5:44 PM, Matt Corallo wrote: > On my test net I take ROA_INVALIDs and convert them to unreachables with > a low preference (ie so that any upstreams taking only the shorter path > will be selected, but so that such packets will never be routed). > > Obviously this isn't a well-supported operation, but I'm curious what > people think of such an approach? If you really want to treat > ROA_INVALID as "this is probably a hijack", you don't really want to be > sending the hijacker traffic. > > Of course if upstreams are rejecting ROA_INVALID you can still have the > same problem one network away, but its an interesting result for > testing, especially since it rejects a bunch of crap in China where CT > has reassigned prefixes with covering ROAs to customers who re-announce > on their own ASN (which appears to be common). > > Matt > > On 7/6/19 4:05 PM, Brett Frankenberger wrote: >> On Thu, Jul 04, 2019 at 11:46:05AM +0200, Mark Tinka wrote: >>> I finally thought about this after I got off my beer high :-). >>> >>> Some of our customers complained about losing access to Cloudflare's >>> resources during the Verizon debacle. Since we are doing ROV and >>> dropping Invalids, this should not have happened, given most of >>> Cloudflare's IPv4 and IPv6 routes are ROA'd. >> >> These were more-specifics, though. So if you drop all the >> more-specifics as failing ROV, then you end up following the valid >> shorter prefix to the destination. Quite possibly that points at the >> upstream which sent you the more-specific which you rejected, at which >> point your packets end up same going to the same place they would have >> gone if you had accepted the invalid more-specific. >> >> Two potential issues here: First, if you don't have an upstream who >> is also rejecting the invalid routes, then anywhere you send the >> packets, they're going to follow the more-specific. Second, even if >> you do have an upstream that is rejecting the invalid routes, ROV won't >> cause you to prefer the less-specific from an upstream that is >> rejecting the invalid routes over a less-specific from an upstream that >> is accepting the invalid routes. >> >> For example: >> if upstream A sends you: >> 10.0.0.0./16 valid >> and upstream B sends you >> 10.0.0.0/16 valid >> 10.0.0.0/17 invalid >> 10.0.128.0/17 invalid >> you want send to send the packet to A. But ROV won't cause that, and if >> upstream B is selected by your BGP decision criteria (path length, >> etc.), you're packets will ultimately follow the more-specific. >> >> (Of course, the problem is can occur more than one network away. Even >> if you do send to upstream A, there's no guarantee that A's >> less-specifics aren't pointed at another network that does have the >> more-specifics. But at least you give them a fighting chance by >> sending them to A.) >> >> -- Brett >>
