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
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
