intra-AS messaging for route leak prevention

Fri Jun 10 08:50:17 UTC 2016

Hi All,

On Wed, Jun 08, 2016 at 08:48:11AM -0400, Joe Provo wrote:
> On Wed, Jun 08, 2016 at 11:48:36AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> > Thanks for the inputs about the inter-AS messaging and route-leak
> > prevention techniques between neighboring ASes. Certainly helpful
> > information and also useful for the draft
> > (draft-ietf-idr-route-leak-detection-mitigation).
> > 
> > However, my question was focused on "intra-AS" messaging.  About
> > conveying from ingress to egress router (within your AS), the info
> > regarding the type of peer from which the route was received at
> > ingress.  This info is used at the egress router to avoid leaking a
> > route.
> > 
> > Question: Is the "common practice" described in the original message
> > http://mailman.nanog.org/pipermail/nanog/2016-June/086242.html  (see
> > the stuff in quotes) sufficient or are there other ways in common
> > use in which network operators convey the said information from
> > ingress to egress router?
>  
> 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.

I second this. One of NTT's design principles is to be very strict in
what we accept (e.g. "postel was wrong") at the ingress point. At the
ingress point the route announcement is weighted, judged, categorized &
tagged. This decides 99% of what happens next: the egress points are
merely executing what was "decided" at ingress (but exceptions are
possible).

> It is useful to note that AS_PATH if often also involved on egress
> decisions. 

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.

Having said that: as a conscious effort to mitigate (known) fragility in
one's 'ingress policy deployment' an egress AS_PATH filter might be a
good second layer of defense. It doesn't protect your own network but it
helps block further spreading of garbage.

Kind regards,

Job