Re: [rrg] Some concerns about ILNP

[RJ Atkinson <[e-mail]>]

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

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