soBGP deployment

Mon May 23 19:24:20 UTC 2005

One correction: I shouldn't have said: "The RIRs are iffy". It should have
been "The IRRs are iffy". A world of difference.

I understand the limitations. However, no one is rushing to implement most
of the things that folks in this thread are obsessing over: DNSSec, IPV6,
sBGP, soBGP. 

A bizarre assertion was made that only a "few" are implementing SPF, which
is demonstrably untrue. Its getting implemented because its easy, not
because its complete. This obsession with perfection will (as usual) result
in exactly no progress. Folks need to be willing to get 70% of the benefit
for 10% of the effort.

- Dan

On 5/23/05 2:33 PM, "Edward Lewis" <Ed.Lewis at neustar.biz> wrote:

> At 14:00 -0400 5/23/05, Daniel Golding wrote:
> 
> My reply is mostly tongue-in-cheek.  I think it's always healthy to
> explore alternatives.
> 
>> Why not do something simple? The in-addr.arpa reverse delegation tree is
>> pretty accurate. We use it for lots of different things. Why not just give
>> IP address blocks a new RR (or use a TXT record) to identify ASN? This
>> solves the biggest problem we have right now, which is stealing of address
>> blocks. It requires little processor overhead, and only a few additional DNS
>> lookups. Its reasonably foolproof.
> 
> I'll ignore that you said "(or use a TXT record)". ;)
> 
> Without DNSSEC, what does this buy?  "Secure" information on a
> non-secure channel.
> 
> If, by "stealing addresses" you mean that the RIR records are
> changed, then changing the name servers is trivial - changing to
> servers that have the hijacker's preferred data (or none!).
> 
>> Why create reliance on more databases? The RIRs are iffy. We rely on DNS
>> right now. Why not keep relying on it? This solution doesn't solve all of
>> our problems, but it does help, its easy, and people will implement it.
> 
> Who populates the DNS (well, the .arpa domain)?  The RIRs do.
> 
>> Ok, please start flaming now :)
> 
> Brave to make such a request on a Monday afternoon.