nanog mailing list archives
Re: soBGP deployment
From: Edward Lewis <Ed.Lewis () neustar biz>
Date: Mon, 23 May 2005 12:18:08 -0400
At 11:27 -0400 5/23/05, Larry J. Blunk wrote:
I suspect this was due to the fact that template submissions were not fully automated at the time and required human review (disclaimer: I worked for the MichNet side of Merit back then and was not intimately familiar with PRDB operations).
It could have been the tools. (I can't argue, I wasn't there.)Here's another thought. Much like the comparison of SSH and DNSSEC in this reply of mine from last March:
http://www.merit.edu/mail.archives/nanog/2005-03/msg00694.htmlI.e., the "mythical core" needs work. This time it's the address organizations and routing elements.
Yet another thought. Skimming through this thread, and only being slightly aware of sBGP and soBGP in past years, some concepts remind me of work under DARPA's Active Nets research done in the late 90's. (http://www.darpa.mil/ato/programs/activenetworks/actnet.htm)
Some things I learned then:1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood).
2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.)
IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)?
Dijkstra's shortest path algorithms (an example IGP) work "in the plane" because it manages to mimic the ubiquitous view. You aren't afraid that someone is "not playing my the rules." When you are working with security (algorithms), you don't have that safety belt.
And a final thought...Security ought to not make the system being protected brittle. Like the example of routing changes being held up until the paperwork went through - maybe an improvement in tools will enable this. But think of the long term impact - who will be paying to keep the tools and system up to date?
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Current thread:
- Re: soBGP deployment, (continued)
- Re: soBGP deployment Steven M. Bellovin (May 23)
- Re: soBGP deployment Randy Bush (May 23)
- Re: soBGP deployment Randy Bush (May 23)
- Re: soBGP deployment Tony Li (May 23)
- Re: soBGP deployment Randy Bush (May 24)
- Re: soBGP deployment Russ White (May 24)
- Re: soBGP deployment Randy Bush (May 24)
- Re: soBGP deployment Michael . Dillon (May 23)
- Re: soBGP deployment Russ White (May 23)
- Re: soBGP deployment Russ White (May 23)
- Re: soBGP deployment Edward Lewis (May 23)
- Re: soBGP deployment Michael . Dillon (May 23)
- Re: soBGP deployment william(at)elan.net (May 23)
- Re: soBGP deployment bmanning (May 23)
- Re: soBGP deployment Daniel Golding (May 23)
- Re: soBGP deployment Jeroen Massar (May 23)
- Re: soBGP deployment bmanning (May 23)
- Re: soBGP deployment Edward Lewis (May 23)
- Re: soBGP deployment Daniel Golding (May 23)
- Re: soBGP deployment Valdis . Kletnieks (May 23)
- Re: soBGP deployment Brad Knowles (May 23)