|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
On Mon, May 23, 2005 at 08:15:15PM +0200, Jeroen Massar wrote: > On Mon, 2005-05-23 at 14:00 -0400, Daniel Golding wrote: > > > > I suspect the right thing to do is to ask why soBGP and sBGP have failed? > > > > And yes, they've failed. Just like DNSSec, we aren't seeing even limited > > adoption. Why? Too complex, too many moving parts, too much reliance on iffy > > third parties and requires mass adoption. > > > > I suggest that the community finds something that gives us most of what we > > want, is simple to understand, and can be implemented in a piece-wise > > fashion. Look at SPF - not perfect, but certainly useful. It is simple, easy > > to implement, and IS being implemented. > > <sidetrack> > > SPF gets implemented by a few. I won't implement it simply because it > will break my mailsetup because the mechanism format does not allow > optional mechanisms to be defined eg, if I would use in DNS: > "v=spf1 ip6:2001:db8::/48 -all" > Any host which implements SPF checks but does not know how to do ip6 > checks, even though the message went 100% through an IPv6 only path will > drop the mail in the trashcan, even though the mail is 100% legit. > But this is a non-issue of course as everybody uses IPv6 only... just > like nobody uses DNSSec and other cool toys. > > </sidetrack> > > <SNIP> > > 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. > > <sarcastic smiling comment> But you are the fool here </sa....> > > So your router boots and receives a prefix and then you are going to > check using the just received prefix if it is legit to be sent from that > ASN, remember that it was just faked :) Or do it before you get it and > thus don't have a route... > > L3 on L3 dependencies don't work unfortunately. > > I am really glad the IETF has a lot of people who catch above things > quite easily because of expertise and experience. > > Btw "pretty accurate" is not good enough unfortunately... > > Greets, > Jeroen > ah... but my old hack did -NOT- have the circular dependency you point out (and not for the last time either...) and yes, thanks to the IETF for being on top of this. --bill
|