intra-AS messaging for route leak prevention

Wed Jun 8 13:24:15 UTC 2016

On 8/Jun/16 14:48, Joe Provo wrote:

>  
> "There are more routing policies in heavan and earth, Sriram
>  Than are dreamt of in your draft."
>
> But in my experience, community tagging is by far the widest 
> deployment due to the broad support and extent of information 
> which can be carried.  It is useful to note that AS_PATH if 
> often also involved on egress decisions. 

Agree.

We use BGP communities extensively on all eBGP sessions to identify
upstreams, peers, customers, special partners, e.t.c., on the inbound
routing policy.

Outbound routing policies will depend on the type of neighbor, i.e.,
upstream, peer, customer, special partner, e.t.c. At any rate, we use
communities to determine what routes will be announced to what eBGP
neighbor. Those communities will need to match the intended source of
the route at some other point in the network.

The only time we look at prefix lists is to ensure we send (or accept)
nothing longer than a /24 (IPv4) or a /48 (IPv6) to (and from) an eBGP
neighbor of any kind. That said, further granularity in the outbound
routing policy toward upstreams will allow for transmission of
longest-match (/32 IPv4 and /128 IPv6) to support RTBH requirements.
This is a co-ordinated routing policy, so it is not harmful to us, our
upstreams or the wider Internet. We'd also accept these prefix lengths
from BGP customers as part of their standard RTBH capability they get
when they buy IP Transit from us; again, highly controlled and
co-ordinated to never cause any harm to us, the customer or the wider
Internet, while still being 100% functional for the customer.

Ultimately, once a routing policy is in place on a specific router, we
are never touching that router again as the edge moves around, i.e.,
customers, peers, special partners, e.t.c., come on-board, move around,
e.t.c. This creates natural safe guards against cock-ups, although the
goal is always to eliminate cock-ups from the get-go (automation of
repetitive provisioning tasks makes this goal easier to attain).

Coupled with our insistence on creating matching prefix and AS_PATH
filters for all customers (after being checked against the relevant RIR
WHOIS database to avoid hijack), we've been fortunate to never be in a
position where our network is leaking routes, unintentionally or
otherwise. Work continues to further harden this so that it never happens.

Mark.