Re: "The IETF has difficulty solving complex problems" or alternatively

On 15-sep-2005, at 9:57, Pekka Nikander wrote:

> > > So, as I state in my little web page, I think we really should  
> > > work hard to create a new waist for the architecture.   I, of  
> > > course, have my own theory where the new waist should be and how  
> > > it should be implemented,
> > Well, don't be shy: where can we absorb these insights?
> Unfortunately I don't have any concise summary of my "theory", but  
> wading through my academic papers (available through my home page)  
> should give a fairly good view.
[HIP]

> But, as I wrote, I am trying to take distance from these and trying  
> to understand alternative approaches, like "virtualising IP" or  
> "domain-based internetworking" that some people are thinking  
> about.  It is now mostly other people that are continuing the HIP- 
> based work, for example, at the CEC funded Ambient Networks project  
> and at the IRTF HIP Research Group.
I think HIP is on the right track in some areas, but I don't like the  
protocol as such because the overhead is too large, and I think even  
though it's fairly radical in some ways, it doesn't go far enough.
For instance, the first sentence of any new internet architecture  
would have to be: one size does NOT fit all. The assumption that it  
does has allowed a lot of great work in the past. For instance, for  
some time, TCP was able to accommodate the slowest possible links and  
the fastest. But that's no longer true, so now we have to choose  
between enabling RFC 1323 high performance options to allow high  
speed downloads across the globe, or disable them and allow for  
header compression to optimize for low speed links. Unfortunately  
most operating systems enable the options, killing header  
compression, while applications fail to use buffers that are big  
enough so long distance high speed downloads aren't possible either.
That kind of stuff is very common in today's internet.

We also need to address the need of intermediate systems to influence  
the communication between two endpoints in various ways, without  
killing the end-to-end principle wholesale.
Routing, naming, addressing and layering is a big mess in the current  
"architecture". (I'm using quotes because all of this evolved over  
time without noticeable architectural oversight.) CIDR was a step in  
the right direction, but now it's time for the next step: make  
addresses variable length. (One size doesn't fit all.) Port numbers  
should be part of the address to allow for easier filtering. Having  
DNS names is great, but applications shouldn't have to deal with name  
to address mappings: we need a new API that hides addresses from  
applications that don't have any need to look at them. HIP does get  
the locator/identifier idea right. In addition to that, we need to  
abandon the notion of one single network with a fixed root. By  
allowing each point in the network to be the root, and map all other  
parts of the network to arbitrary parts of the hierarchy as seen from  
a given root, we can impose the constraints required by many  
organizations. Interdomain routing needs more link state like  
mechanisms in order to get rid of BGP's version of the count to  
infinity problem. It also needs to work when the view of the network  
is incomplete, while at the same time taking advantage of additional  
topological information when available. (This includes taking  
advantage of geography in routing.) And interdomain routing shouldn't  
be subvertable like it is today.
Coming back to IPsec: we need more of this. TLS is broken because it  
doesn't protect the underlying TCP session. We need an API that  
allows applications to do an IPsec version of "STARTTLS". (It would  
be nice if we could do authentication first and then encryption,  
unlike it's done today, to get rid of at least SOME of the huge IPsec  
overhead: the auth data can then be the encryption IV.)
In other words: we now need to do everything that we didn't do until  
now because it was too hard.
Ok, that's my rant for today.  :-)

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf