soBGP deployment

Mon May 23 16:18:08 UTC 2005

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.html

I.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.