intra-AS messaging for route leak prevention

Fri Jun 10 18:38:22 UTC 2016

On 10/Jun/16 19:34, Leo Bicknell wrote:

> 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.

I've found communities to be robust at filtering very effectively.

I have heard of software issues that may cause filters to stop working,
but I have not yet encountered any such issues myself that had nothing
to do with a mis-configuration or lack of understanding about how
policies are evaluated by the router.

>
> 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.

That does not scale, and was probably one of the primary reasons
communities were developed.

>
> 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".

We've been operating purely community-based filtering on border and
peering routers for years. I've never ran into an issue with the
software that broke that.

The folk I know who have suffered this either mis-configured their
policies, did not understand BGP and did not get a good handle on how
their router OS implements filtering and filter evaluation.

Mark.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160610/ccaaeff8/attachment.sig>