nanog mailing list archives
Re: intra-AS messaging for route leak prevention
From: Job Snijders <job () instituut net>
Date: Fri, 10 Jun 2016 10:50:17 +0200
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
Current thread:
- intra-AS messaging for route leak prevention Sriram, Kotikalapudi (Fed) (Jun 06)
- Re: intra-AS messaging for route leak prevention Job Snijders (Jun 06)
- Re: intra-AS messaging for route leak prevention Joe Provo (Jun 06)
- Re: intra-AS messaging for route leak prevention Mark Tinka (Jun 06)
- Re: intra-AS messaging for route leak prevention Sriram, Kotikalapudi (Fed) (Jun 08)
- Re: intra-AS messaging for route leak prevention Joe Provo (Jun 08)
- Re: intra-AS messaging for route leak prevention Mark Tinka (Jun 08)
- Re: intra-AS messaging for route leak prevention Sriram, Kotikalapudi (Fed) (Jun 09)
- Re: intra-AS messaging for route leak prevention Job Snijders (Jun 10)
- Re: intra-AS messaging for route leak prevention Mark Tinka (Jun 10)
- Re: intra-AS messaging for route leak prevention Leo Bicknell (Jun 10)
- Re: intra-AS messaging for route leak prevention Mark Tinka (Jun 10)
- Re: intra-AS messaging for route leak prevention Joe Provo (Jun 11)
- Re: intra-AS messaging for route leak prevention Job Snijders (Jun 06)
- Re: intra-AS messaging for route leak prevention Christopher Morrow (Jun 10)
- Re: intra-AS messaging for route leak prevention Mark Tinka (Jun 10)
- Re: intra-AS messaging for route leak prevention Christopher Morrow (Jun 10)
- Re: intra-AS messaging for route leak prevention Mark Tinka (Jun 10)
- Re: intra-AS messaging for route leak prevention Christopher Morrow (Jun 10)
- Re: intra-AS messaging for route leak prevention Hugo Slabbert (Jun 10)