CloudFlare issues?

Ca By cb.list6 at gmail.com
Tue Jun 25 14:21:34 UTC 2019


On Tue, Jun 25, 2019 at 7:06 AM Stephen Satchell <list at 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.





>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190625/ecdf5efa/attachment.html>


More information about the NANOG mailing list