Re: CloudFlare issues?

[Ben Maddison via NANOG <nanog () nanog org>]

Welcome to the club!

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Francois Lecavalier <Francois.Lecavalier () mindgeek com>
Sent: Thursday, July 4, 2019 8:46:46 PM
To: Ben Maddison; job () ntt net
Cc: nanog () nanog org
Subject: RE: CloudFlare issues?

> > At this point in time I think the ideal deployment model is to perform
> > the validation within your administrative domain and run your own
> > validators.

> +1

We'll definitely look into this shortly.  I definitely don't want to leave a security measure in the end of a third 
party but with my team being so busy it was a quick temp fix.

> The larger challenge has been related to vendor implementation choices and bugs, particularly on ios-xe. Happy to go 
> into more detail if anyone is interested.

We are on Juniper MX204's at the edge and they have been solid for the last 60 weeks - we ran into a long list of bugs 
on other platforms but not on these.

So I had about 4200 routes marked as invalid.  After looking at a sample of them it looks like most of them have a 
valid ROA with an improper mask length - so there is ultimately a route to these prefixes and at worse would result in 
"suboptimal" routing - or should I say: the remote network can't control its route propagation anymore.  In most case 
they are a stub networks with a single /24 reassigned from the upstream provider.  I have no traffic going directly to 
these networks and I don't expect any to go there anytime soon.

It's been close to 3 hours now since I dropped them - radio silence.

Whoever fears implementing RPKI/ROA/ROV, simply don't.  It's very easy to implement, validate and troubleshoot.

-----Original Message-----
From: Ben Maddison <benm@workonline.africa>
Sent: Thursday, July 4, 2019 11:51 AM
To: job () ntt net; Francois Lecavalier <Francois.Lecavalier () mindgeek com>
Cc: nanog () nanog org
Subject: [External] Re: CloudFlare issues?

Hi Francois,

On Thu, 2019-07-04 at 17:33 +0200, Job Snijders wrote:
> Dear Francois,
>
> On Thu, Jul 04, 2019 at 03:22:23PM +0000, Francois Lecavalier wrote:
> >
> At this point in time I think the ideal deployment model is to perform
> the validation within your administrative domain and run your own
> validators.

+1

> > 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.
We have been dropping Invalids since April, and have had only a
(single-digit) handful of support requests related to those becoming unreachable.

The larger challenge has been related to vendor implementation choices and bugs, particularly on ios-xe. Happy to go 
into more detail if anyone is interested.

I would recommend *not* taking any policy action that distinguishes Valid from Unknown. If you find that you have 
routes for the same prefix/len with both statuses, then that is a bug and/or misconfiguration which you could turn into 
a loop by taking policy action on that difference.

Cheers,

Ben
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. 
Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is 
unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce 
courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y 
rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne 
autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, 
veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.