Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



IMHO, this thread of this discussion belongs to the HIP WG list. I am replying there.

--Pekka Nikander

On Sep 17, 2005, at 15:48, Iljitsch van Beijnum wrote:

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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]