Hi, Am 10.05.2012 um 10:56 schrieb Xin Gu:
> Hi everyone, > > I am a developer from HIPL project and working on HIPv2 related > functionalities under Miika's instruction. We have found some gaps in the > transition process from HIPv1 to HIPv2. My question is: do we expect a smooth > transition from HIPv1 to HIPv2 or we simply want to wipe out HIPv1? > > No matter what the answer it will be, we think it is still worthwhile to > describe those gaps we met, because we might face similar transition problems > again when HIPv3 comes out. Below is the description: > > In order to provide a smooth transition from HIPv1 to HIPv2, we start to > prototype a dual version support HIPL, which aims to handle HIPv1 and HIPv2 > association at the same time. If the version of the inbound I1 is one, the > HIPL host continues a HIPv1 BEX; If the version of the inbound I1 is two, the > host goes with a HIPv2 BEX. > > However the new OGA bits in HIPv2 adds new gaps to this approach. The > introduction of OGA bits changes the presentation of a key in HIPv1 HIT and > HIPv2 HIT and a host cannot tell a HIT contains OGA bits or not solely > (although there is a very low possibility that v1 HIT and v2 HIT for a same > key are identical). As far as I remember, we discussed a new prefix for the new version of the ORCHID. This would make the distinction trivial. Will this solve your problem? Tobias > Therefore a dual-version host is clueless on which HIP version it should use > when a peer HIT is presented. For a dual-version responder, it also needs to > check two kinds of new invalid requests: 1) a HIPv1 initiation to a HIT with > OGA. 2) a HIPv2 initiation to a HIT without OGA. > > The interoperability table below shows all possible conditions: > > V1 initiator: a host only capable of triggering HIPv1 BEX > V1 responder: a host only capable of handling HIPv1 messages > V2 initiator: a host only capable of triggering HIPv2 BEX > V2 responder: a host only capable of handling HIPv2 messages > Dual initiator: a host capable of triggering both HIPv1 and HIPv2 BEX > Dual responder: a host capable of handling both HIPv1 and HIPv2 messages > HITv1: a HIT without OGA bits owned by the host > HIT_OGA: a HIT with OGA bits owned by the host > > ------------------------------------------------------------------------------- > 1) V1 responder 2) V2 responder 3) Dual responder > HITv1 HIT_OGA HITv1 & HIT_OGA > > a) V1 initiator v1 no v1* > HITv1 > > b) V2 initiator no v2 v2* > HIT_OGA > > c) Dual initiator v1* v2* v1/v2* > HITv1 & HIT_OGA > ------------------------------------------------------------------------------- > Interoperability table > > All gap cases are marked by an asterisk in the cell: > • Cell c2, A dual-version initiator and a HIPv2-only responder: the > initiator gets a HIT with OGA bits since the responder only support HIPv2. > But the initiator gets stuck here because it doesn't know if it should choose > HIPv1 BEX or HIPv2 BEX. > • Cell c1, similar to Cell c2. > • Cell b3, A HIPv2-only initiator and a dual-version responder: the > initiator knows 2 HITs (with and without OGA bits) of the peer. The initiator > can only start a HIPv2 BEX, but it doesn't know which HIT contains OGA. > • Cell a3, similar to Cell b3. > • Cell c3, A dual-version initiator and a dual-version responder: the > initiator has 2 HITs (with and without OGA bits) of the peer and it can start > both HIPv1 and HIPv2 BEX, but either one requires to find a corresponding HIT. > To facilitate the transition process, a dual-version host needs a mechanism > to detect the presence of OGA bits in a HIT, which seems to be impossible to > achieve now. Perhaps changing the current HIT prefix (2001:0010::0/28) to > another one can be a solution? > > In addition to the issue above, the HIP DNS extension faces similar > challenges since it doesn't distinguish the types of HIT (with or without > OGA) in its record, while IPv4 and IPv6 does ( A record and AAAA record). > > Miika also proposes a potential security vulnerability on the communication > of two dual-version host with DNS. If DNS supports returning both kinds of > HIT to a dual-version host, an attacker can remove the record containing OGA > bits, which forces two dual-version hosts establish a HIPv1 association and > use weaker ciphers. > > > Miika and I have been actively discussing on these issues. Hope we can also > get advice from all experts here. Thanks a lot. > > Best regards, > Xin Gu > > _______________________________________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec -- Dr. Tobias Heer, Postdoctoral Researcher Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 214 17 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ pgp id: AEECA5BF _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
