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

Pekka Nikander <> Sun, 18 September 2005 06:58 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EGt8Y-0008UZ-CC; Sun, 18 Sep 2005 02:58:54 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EGt8V-0008UJ-L1 for; Sun, 18 Sep 2005 02:58:51 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id CAA08712 for <>; Sun, 18 Sep 2005 02:58:49 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1EGtDr-0002ge-Lt for; Sun, 18 Sep 2005 03:04:24 -0400
Received: from [] (localhost []) by (Postfix) with ESMTP id B81A9212C46; Sun, 18 Sep 2005 09:58:20 +0300 (EEST)
In-Reply-To: <>
References: <20050804050502.GB6084@sbrim-wxp01> <> <> <> <151701c5b570$052a25a0$> <C0DE65F6343F8BD987425795@B50854F0A9192E8EC6CDA126> <> <> <> <> <> <>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <>
Date: Sun, 18 Sep 2005 08:58:18 +0200
To: Iljitsch van Beijnum <>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion <>
Subject: Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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 mailing list