Hi Ran, > 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.
Could you please tell me briefly what's the major differences between those two proposals? > 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. Yes, I knew your experience in security fields. So I especially want to know your opinions and reasons on that point. > 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. Thanks for your valuable information about this history. > 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.) That's because your draft seems more attractive to me so that I paid more attention to it :) > > 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. Maybe, but it doesn't prevent me borrowing the CGA idea to generate crypotographic and hierarchical host identifiers in my RANGI proposal (http://www.ietf.org/id/draft-xu-rangi-01.txt). > 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. What do you want to prove by saying this? > The IETF CGA community > believes the resulting 62-bits of hash are sufficient, > evidence RFC-3972, so ILNP meets their stated requirements. Thanks for providing such information. I had even made a presentation about my RANGI proposal in HIP RG session. At that time, one of the major concerns about the usage of the hierarchical and crypotographic host identifier is borrowing some bits from the hash value part will damage the security of the binding badly. Hence the boundary between the Administrative Domain ID and the hash part has not be determined yet. The information you provided here gives me more confidence on the usage of the hierarhical crypotographic host identifier. > 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. Good news, I'm in expectation of this I-D. Best regards, Xiaohu > 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
