|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Geoff Huston <gih@apnic.net> In-Reply-To: <CAL9jLab+5QHfpWm0gkJJzECwa-498UPzJzNGTzB8c4-if9cdkw@mail.gmail.com> Date: Sat, 25 Feb 2012 09:08:54 +1100 To: Christopher Morrow <morrowc.lists@gmail.com> Cc: Shane Amante <shane@castlepoint.net>, North American Network Operators' Group <nanog@nanog.org> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org 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: >=20 >> Solving for route leaks is /the/ "killer app" for BGPSEC. I can't = understand why people keep ignoring this. >=20 > 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'?" >=20 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. =46rom 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) >=20 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?=20 Geoff
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |