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