Re: [rrg] Some concerns about ILNP

Xu Xiaohu <xuxh@huawei.com> Fri, 31 July 2009 08:37 UTC

Return-Path: <xuxh@huawei.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50913A6C2C for <rrg@core3.amsl.com>; Fri, 31 Jul 2009 01:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.769
X-Spam-Level:
X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLAtijS4TUEc for <rrg@core3.amsl.com>; Fri, 31 Jul 2009 01:37:33 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D44E43A6BC5 for <rrg@irtf.org>; Fri, 31 Jul 2009 01:37:32 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN008TE19RHI@szxga04-in.huawei.com> for rrg@irtf.org; Fri, 31 Jul 2009 16:37:03 +0800 (CST)
Received: from x41208a ([10.111.12.94]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNN00A4F19RXB@szxga04-in.huawei.com> for rrg@irtf.org; Fri, 31 Jul 2009 16:37:03 +0800 (CST)
Date: Fri, 31 Jul 2009 16:37:02 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <004201ca11b7$e8f30b10$5e0c6f0a@china.huawei.com>
To: rja@extremenetworks.com
Message-id: <004c01ca11ba$14274e70$5e0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Thread-index: AcoRt+iHrYYXRMbrTlaM9enzktGB3QAAUJvw
Cc: 'IRTF RRG' <rrg@irtf.org>
Subject: Re: [rrg] Some concerns about ILNP
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2009 08:37:33 -0000

Hi,

The following is some comment from Tom (HIPRG co-chair) with regard to the flat HIT vs hierarchial HIT. The corresponding discussion thread is https://listserv.cybertrust.com/pipermail/hipsec-rg/2008-July/000511.html

**********************************************************************************
Regarding flat HIT vs. hierarchical HIT, this by itself is IMO a good
topic for discussion for this research group, because a hierarchical HIT
offers some improved resolution properties.

I think it is challenging to squeeze hierarchy/administrative bits into
the existing 128-bit field, because if we are constrained to use an
ORCHID prefix, then to get on the order of 32 bits of hierarchy we will
be down to roughly 70 bits of hash which compromises the ability to
survive the second preimage attack.  To me, this is problematic because
one of the key attributes of HIP is that the security of the binding
update is not easily compromised.

Another problem is to decide who owns and gets to allocate the bits
corresponding to the administrative domains.  Presumably, there would
need to be some security architecture to authenticate ownership of
certain bit patterns in that field, and would introduce some kind of
third party gatekeeper of the bits. 

However, if the bit constraints were reduced by going to larger HITs
(such as 256 bits) then I think that having some bits to identify the
overlay where the HIT may be resolved becomes more attractive, and if
there are a lot of administrative bits available, then the political
problems of administering them are somewhat reduced since they are not
so scarce.

- Tom
********************************************************************************* 

BR,
Xiaohu

> -----邮件原件-----
> 发件人: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] 代表 Xu Xiaohu
> 发送时间: 2009年7月31日 16:22
> 收件人: rja@extremenetworks.com
> 抄送: 'IRTF RRG'
> 主题: [rrg] Some concerns about ILNP
> 
> Hi Ran,
> 
> If I understand your ILNP correctly, it is much silimar with 
> the GSE.  If so, I'm wondering whether the issues with the 
> GSE described in draft-ietf-ipngwg-esd-analysis  have been 
> successfully solved by the ILNP, e.g., identifier 
> authentication issue. It seems that  the answers to these 
> hard issues have not been mentioned in your slides.
> 
> I noticed the following statement in your slides, do you 
> believe that 62-bit field is long enough to prevent the 
> security of the binding of the 62-bit hash value and the 
> public key from being easily compromised once you use the 
> HIP/CGA like ideas to deal with the identifier authentication issue?
> 
> *********************************
> If scope bit is local, have 62 bits that can be anything:
> ‣ Cryptographically Generated Identifier (a la CGA proposals) 
> ‣ Hash of a public-key (a la HIP) ‣ Pseudo-randomly generated 
> (a la IPv6 Privacy AutoConf)
> **********************************
> 
> Best regard,
> 
> Xiaohu
> 
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
>