CloudFlare issues?

Thu Jul 4 17:10:11 UTC 2019

On 4/Jul/19 17:22, Francois Lecavalier wrote:

>  
>
> Following that Verizon debacle I got onboard with ROV, after a couple
> research I stopped my choice on the ….drum roll…. CloudFlare GoRTR
> (https://github.com/cloudflare/gortr).  If you trust them enough they
> provide an updated JSON every 15 minutes of the global RIR aggregate. 
> I’ll see down the road if we’ll fetch them ourselves but at least it
> got us up and running in less than an hour.  It was also easy for us
> to deploy as the routers and the servers are on the same PoP directly
> connected, so we don’t need the whole encryption recipe they provide
> for mass distribution.
>

Funny you should mention this... I was speaking with Tom today during an
RPKI talk he gave at MyNOG, about whether we'd be willing to trust their
RTR streams.

But, I'm glad you found a quick solution to get you up and running.
Welcome to the club.

>  
>
> But I also have a question for all the ROA folks out there.  So far we
> are not taking any action other than lowering the local-pref – we want
> to make sure this is stable before we start denying prefixes.  So the
> question, is it safe as of this date to : 1.Accept valid, 2. Accept
> unknown, 3. Reject invalid?  Have any large network who implemented it
> dealt with unreachable destinations?  I’m wondering as I haven’t found
> any blog mentioning anything in this regard and ClouFlare docs only
> shows example for valid and invalid, but nothing for unknown.
>
>  
>
> My assumption is that 1.Accept valid, 2. Accept unknown, 3. Reject
> invalid shouldn’t break anything.
>

Well, a Valid and NotFound state implicitly mean that the routes can be
used for routing/forwarding. In that case, the only policy we create and
apply is against Invalid routes, which is to DROP them.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190704/66755f90/attachment.html>