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

Pekka Nikander <pekka.nikander@nomadiclab.com> Thu, 15 September 2005 13:45 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFu3T-0002lU-2l; Thu, 15 Sep 2005 09:45:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFu3R-0002lO-4F for ietf@megatron.ietf.org; Thu, 15 Sep 2005 09:45:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10981 for <ietf@ietf.org>; Thu, 15 Sep 2005 09:45:30 -0400 (EDT)
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFu8D-0001Hs-HA for ietf@ietf.org; Thu, 15 Sep 2005 09:50:32 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0DFCC212C46; Thu, 15 Sep 2005 16:45:21 +0300 (EEST)
In-Reply-To: <6.2.3.4.2.20050915124120.0421ce00@mail.jefsey.com>
References: <20050804050502.GB6084@sbrim-wxp01> <42F89F9F.5070008@zurich.ibm.com> <C5A01F62-A076-46C7-8C67-6568E752A1E7@nomadiclab.com> <4321D5E9.9010609@shockey.us> <151701c5b570$052a25a0$0500a8c0@china.huawei.com> <C0DE65F6343F8BD987425795@B50854F0A9192E8EC6CDA126> <43249A80.3020303@piuha.net> <4324A849.4060509@cs.columbia.edu> <BB8C050D-B298-4A8A-9325-45B149FC04AD@nomadiclab.com> <4A763861-D4E9-44DD-A193-8E73EC4E03A7@muada.com> <4A09791C-AF36-4C86-923A-D38343C2E037@nomadiclab.com> <6.2.3.4.2.20050915124120.0421ce00@mail.jefsey.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <1E180221-A952-481A-8B0A-47304297CD91@nomadiclab.com>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Date: Thu, 15 Sep 2005 15:45:18 +0200
To: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion <ietf@ietf.org>
Subject: Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> ... But if I see identification, authentication and routing matters  
> being addressed, I see proposed changes enough to suspect that this  
> will affect the level above (DNS) and below (IP addressing).

I don't see any *necessary* changes to IP addressing; OTOH wide  
spread use of HIP would certainly open new possibilities, like easier  
network renumbering and easier interworking between IPv4 and IPv6.

DNS, changes or at least extensions, definitely.  That is an area of  
active research.  The Hi3 paper covered that from one point of view  
briefly, but there are other proposals around.

> I would suggest you try to think of simple, robust, scalable global  
> Internet architecture which would include your proposition and  
> permit a transparent transition.

I don't know what you mean with "transparent transition".

> How would you support "ISP rotation": your Elm Street person has  
> several addresses and wants to rotate them with a defined pattern  
> within the same relation, for example for security purposes? (you  
> might call this a directed multi-homing?)

I don't understand why you call that "ISP rotation", but yes, based  
on your functional description, that should be fairly trivial.  With  
IPv6 and RFC3014(bis) addresses you might even get some level of  
privacy, but see also our "BLIND" paper, on my publications page.

> I note that you could also associate HI to predetermined paths as  
> well (anti-tapping protection)?

Maybe, but I don't see any easy way to do that.  One of the points in  
HIP is to loosen the currently tight binding between routing and  
transport.

--Pekka


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf