mailing list archives
Re: do not filter your customers
From: Geoff Huston <gih () apnic net>
Date: Sat, 25 Feb 2012 09:08:54 +1100
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.
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
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?