nanog mailing list archives

Re: CloudFlare issues?


From: Ca By <cb.list6 () gmail com>
Date: Tue, 25 Jun 2019 07:21:34 -0700

On Tue, Jun 25, 2019 at 7:06 AM Stephen Satchell <list () satchell net> wrote:

On 6/25/19 2:25 AM, Katie Holly wrote:
Disclaimer: As much as I dislike Cloudflare (I used to complain about
them a lot on Twitter), this is something I am absolutely agreeing with
them. Verizon failed to do the most basic of network security, and it
will happen again, and again, and again...

I used to be a quality control engineer in my career, so I have a
question to ask from the perspective of a QC guy:  what is the Best
Practice for minimizing, if not totally preventing, this sort of
problem?  Is there a "cookbook" answer to this?

(I only run edge networks now, and don't have BGP to worry about.  If my
current $dayjob goes away -- they all do -- I might have to get back
into the BGP game, so this is not an idle query.)

Somehow "just be careful and clueful" isn't the right answer.


1. Know what to expect — create policy to enforce routes and paths that you
expect, knowing sometimes this may be very broad

2. Enforce what you expect — drop routes and session that do not conform

3.  Use all the internal tools in series as layers of defense —
as-path-list with regex, ip prefix lists, max-routes — they work in series
and all must match. Shoving everything into a route-map is not best,
because what happens when that policy breaks?  Good to have layers.

4. Use irr, rpki, and alarming as external ecosystem tools.

5. Dont run noction or ios, unsafe defaults.

6. When on the phone with your peer, verbally check to make sure they
double check their policy.  Dont assume.







Current thread: