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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
