Re: intra-AS messaging for route leak prevention

[Leo Bicknell <bicknell () ufp org>]

In a message written on Fri, Jun 10, 2016 at 10:50:17AM +0200, Job Snijders wrote:
> You say 'often', but I don't recognise that design pattern from my own
> experience. A weakness with the egress point (in context of route leak
> prevention) is that if you are filtering there, its already too late. If
> you are trying to prevent route leaks on egress, you have already
> accepted the leaked routes somewhere, and those leaked routes are best
> path somewhere in your network, which means you've lost.

It does mean the provider creating the leak has already lost, but
that doesn't mean it still isn't vital to protecting the larger
internet.  A good example of this is fire code.  Most fire codes
do not do much to prevent you from starting a fire in your own
house/condo/apartment, but rather prevent it from spreading to your
neighbors.

For instance, if you filter Customer A to A's Prefix list on ingress,
B to B's, C to C's, it may also be prudent to filter outbound to
your peers based on A+B+C's prefix list.  When the ingress filter
to A fails (typo, bug, bad engineer), your own network is hosed by
whatever junk A ingested, but at least you won't pass it on to peers
and spoil the rest of the Internet.

Basically both ingress and egress filtering have weaknesses, and
in some cases doing both can provide some mitigation.  It's the old
adage "belt and suspenders".

-- 
Leo Bicknell - bicknell () ufp org
PGP keys at http://www.ufp.org/~bicknell/

Attachment: _bin
Description: