Subject: [rrg] Some concerns about ILNP

From: Xu Xiaohu <[email-masked]>
Date: Fri, 31 Jul 2009 16:21:31 +0800

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

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 31 Jul 2009 16:37:02 +0800

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

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Xu Xiaohu
> 发送时间: 2009年7月31日 16:22
> 收件人: [email-masked]
> 抄送: '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?
> 
> ‣ Hash of a public-key (a la HIP) ‣ Pseudo-randomly generated 
> (a la IPv6 Privacy AutoConf)
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 31 Jul 2009 09:04:59 -0400

On  31 Jul 2009, at 04:21, Xu Xiaohu wrote:
> 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.

1) GSE != ILNP.
    There are a range of differences between the specifications.
    The I-D you cite does NOT apply to ILNP.  Please do not confuse
    the two different protocol specifications.  There are similarities,
    and I believe in full credit for earlier related work, which is
    perhaps a bit odd for the modern IETF, but GSE and ILNP are  
different
    protocols in a variety of ways.

2) There are no open authentication issues with ILNP.
    Nearly all of the work on IGP authentication was done by me (that's
    why I'm mentioned in the OSPFv2 spec, for example).  I also did the
    original work on AH/ESP, for example see RFC-1825 through RFC-1827.
    So I've done a fair bit of authentication work within IETF standards
    over the past decades.  There aren't ANY open security issues with  
ILNP.
    ILNP provides security properties entirely equivalent to what IPv6  
has.

3) Separately, the "security issues" in the draft that you cite are  
widely
    agreed within the IETF Security community to be the result of an  
invalid
    analysis.  These errors were pointed out in detail (e.g. by Steve  
Bellovin
    and others) about a decade ago to the authors, the IESG, and the  
IAB.
    The authors' choice not to correct known errors in the security  
analysis
    is a large part of why that particular I-D was never published as  
an RFC.

I find it quite curious that ILNP, which fully addresses security in
an open and documented way, would have these questions arise from you,
yet I haven't seen you ask similar questions of the subset of RRG
proposals that don't address security in any meaningful way at all.
(NB: Clearly there are RRG proposals other than ILNP that do address
security issues, but not all RRG proposals do so.)

> 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?
>

I gather you aren't familiar with the CGA specification in RFC-3972.

A CGA uses what amounts to a 62-bit hash, because it sets the scope bit
("u") and multicast bit ("g") of the EUI-64 both to zero, precisely as
ILNP does.  See, for example, paragraphs numbered 6 & 7 on page 7 of
RFC-3972.  The IETF CGA community believes the resulting 62-bits of hash
are sufficient, evidence RFC-3972, so ILNP meets their stated  
requirements.

Your (separate) quote from Tom Henderson about how HITs are used in HIP,
is very interesting but doesn't apply.  The ILNP slides did not talk  
about
HITs anywhere.  A full specification of how HIP and ILNP might  
interact is
well beyond the presentation given, and probably deserves an I-D of  
its own.
I do think that ILNP and HIP can be combined/used together in a very
synergistic way, but again that is a topic well beyond today's talk.

ILNP is very careful to use the EUI-64 construct in a manner identical
to how existing IPv6 uses the EUI-64 construct, precisely so that  
various
methods used today for forming IPv6 IIDs could be used going forwards to
form ILNP Node IDs.

Yours,

Ran