|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Shane Amante <shane@castlepoint.net> In-Reply-To: <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu> Date: Fri, 24 Feb 2012 13:04:20 -0700 To: Steven Bellovin <smb@cs.columbia.edu> Cc: North American Network Operators' Group <nanog@nanog.org> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org Steve, On Feb 24, 2012, at 11:10 AM, Steven Bellovin wrote: > On Feb 24, 2012, at 7:46 40AM, Danny McPherson wrote: >> On Feb 23, 2012, at 10:42 PM, Randy Bush wrote: >>> the problem is that you have yet to rigorously define it and how to >>> unambiguously and rigorously detect it. lack of that will prevent >>> anyone from helping you prevent it. >>=20 >> You referred to this incident as a "leak" in your message: >>=20 >> "a customer leaked a full table" >>=20 >> I was simply agreeing with you -- i.e., looked like a "leak", smelled=20= >> like a "leak" - let's call it a leak. >>=20 >> I'm optimistic that all the good folks focusing on this in their day >> jobs, and expressly funded and resourced to do so, will eventually >> recognize what I'm calling "leaks" is part of the routing security=20 >> problem. >>=20 > Sure; I don't disagree, and I don't think that Randy does. But just > because we can't solve the whole problem, does that mean we shouldn't > solve any of it? Solving for route leaks is /the/ "killer app" for BGPSEC. I can't = understand why people keep ignoring this. As has been discussed in the SIDR WG, BGPSEC will _increase_ state in = BGP, (more DRAM needed in PE's and RR's, crypto processors to verify = sigs, more UPDATE traffic for beaconing). And, at the end of the day, = ISP's are going to go to their customers and say to them: - BGP convergence may be slower than in the past, because we're shipping = sigs around in BGP now - we can prevent a malicious attack from a random third-party (in the = right part of the topology); - *but* I can't protect you from a 20+ year old problem of a transit = customer accidentally -or- maliciously stealing/dropping your traffic if = they leak routes from one provider to another provider? > As Randy said, we can't even try for a strong technical solution > until we have a definition that's better than "I know it when I see = it". The first step is admitting that we have a problem, then discussing it = collectively to try to determine a way to prevent said problem from = happening. -shane=
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |