Re: CloudFlare issues?

[Matt Corallo <nanog () as397444 net>]

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