Re: HIPv1 to HIPv2 transition issues

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
> Hipsec <at> ietf.org
> 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