Subject: [Hipsec] HIPv1 to HIPv2 transition issues

From: Xin Gu <[email-masked]>
Date: Thu, 10 May 2012 11:56:13 +0300

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). 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

---

From: Tobias Heer <[email-masked]>
Date: Thu, 10 May 2012 23:57:26 +0200

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.
> 
>                       1) V1 responder    2) V2 responder    3) Dual responder
>                          HITv1              HIT_OGA            HITv1 & HIT_OGA
> 
> 	• 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-masked]
> 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

---

From: Xin Gu <[email-masked]>
Date: Fri, 11 May 2012 10:24:18 +0300

Hi,

> Will this solve your problem?

A new prefix will be a great help. I was wondering why the new version 
of the ORCHID is still not available? In recent RFC5201-bis-08 there is 
no hints about a new prefix.

Best regards,
Xin Gu

---

From: Miika Komu <[email-masked]>
Date: Mon, 14 May 2012 08:59:35 +0300

Hi,

> Will this solve your problem?

perhaps the transition mechanism should be explicitly mentioned in the
bis draft. It's not only important for HIPv2 but also for HIPv3 if such
will ever come.