Re: do not filter your customers

[Geoff Huston <gih () apnic net>]

On 25/02/2012, at 7:54 AM, Christopher Morrow wrote:

> On Fri, Feb 24, 2012 at 3:04 PM, Shane Amante <shane () castlepoint net> wrote:
>
> > Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't understand why people keep ignoring this.
>
> I don't think anyone's ignoring the problem... I think lots of people
> have said an equivalent of:
> 1) "How do I know that this path: A - B - C - D
>  is a 'leak'?"

If you are receiving  a path of the form (A B C D), and the origination of the prefix at D is good, then the only way 
you can figure out this is a leak as compare to the intentional operation of BGP is not by looking at the operation of 
protocol per se, but by looking at the routing policy intentions of A, B, C and D and working out if what you are 
seeing is intentional within the scope of the routing policies of these entities. RPSL is one such approach of 
describing such policy in a manner that one could perform some basic computation over the data.

It exposes a broader issue here about the difference between routing intent and protocol correctness. From the 
perspective of protocol correctness, regardless of whether the information was intended to be propagated, a protocol 
correctness tool should be able to tell you that the information has been faithfully propagated, but cannot tell you 
whether such propagation was intentional or not.


> Followed by:
> 2) "Tell me how to answer this programatically given the data we have
> today in the routing system" (bgp data on the wire, IRR data, RIR
> data)

I wish.

> so far ... both of the above questions haven't been answered (well 1
> was answered with: "I will know it when i see it" which isn't helpful
> at all in finding a solution)


Some longstanding problems are longstanding because we have not quite managed to apply the appropriate analytical 
approach to the problem. Others are longstanding problems because they are damn difficult and this makes me wonder if 
we really understand the nature of the space we are working in. For example, if you think about routing not as a 
topology and reachability tool, but an distributed algorithm to solve a set of simultaneous equations (policies) would 
that provide a different insight as to the way in which routing policies and routing protocols interact? 

Geoff