From eric.nevup@gmail.com Thu May 10 01:56:21 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F7A21F85C2 for ; Thu, 10 May 2012 01:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL6ozBLPRyzk for ; Thu, 10 May 2012 01:56:19 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3F21F8505 for ; Thu, 10 May 2012 01:56:17 -0700 (PDT) Received: by lagj5 with SMTP id j5so1025778lag.31 for ; Thu, 10 May 2012 01:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=O436hz/zaCcLyo+gJ++0T9veR7ieOeSuPki8yCPHquQ=; b=LcGqZus+IcZ2ck09sRx8ogzb0bsjukgEgC4W7UpEEvIx9fcNVkzUqBxkA7tob+mZB2 xeRcpADDzdybG9NBu/B2MBJrRhVeggOmG/hj4MY9FJXnKOaqY2UffkZWfAQ1JzsTLJ5H 2l6ejlY0C0H3MQV7m3qpYdMPf57Ba0Pxd3vGPH+4io0DCSgo2L6y5sTFi0+fH52dUsgd lwyBSGFEh0osLjWgOU1cezqEtCS7FS4OtqgkXucDD146NBpD4ppXeINCJZMiKu3B0zZ+ 5Z2qVlRbpHcpkv3/EQWACGTkNpSO04N+MaeqZUcygI+OtnmmhI//Lt+otwbelJyzEg15 bHOg== Received: by 10.152.145.1 with SMTP id sq1mr3337412lab.22.1336640176322; Thu, 10 May 2012 01:56:16 -0700 (PDT) Received: from [130.233.48.170] (tt-dhcp-70.tt.hut.fi. [130.233.48.170]) by mx.google.com with ESMTPS id tt8sm6722623lbb.16.2012.05.10.01.56.14 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 01:56:15 -0700 (PDT) Message-ID: <4FAB82AD.60604@gmail.com> Date: Thu, 10 May 2012 11:56:13 +0300 From: Xin Gu User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: multipart/alternative; boundary="------------030807040402060508090002" Subject: [Hipsec] HIPv1 to HIPv2 transition issues X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 08:56:21 -0000 This is a multi-part message in MIME format. --------------030807040402060508090002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------030807040402060508090002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------030807040402060508090002-- From heer@informatik.rwth-aachen.de Thu May 10 14:57:30 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9290521F84A0 for ; Thu, 10 May 2012 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SobzaObz85Os for ; Thu, 10 May 2012 14:57:29 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id E867B21F8498 for ; Thu, 10 May 2012 14:57:28 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0M3T00C7IUBQX640@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 10 May 2012 23:57:26 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.75,567,1330902000"; d="scan'208";a="88504828" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-2.rz.rwth-aachen.de with ESMTP; Thu, 10 May 2012 23:57:26 +0200 Received: from tobias-heers-macbook-air.fritz.box ([unknown] [91.179.152.202]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0M3T008KLUBQDF40@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 10 May 2012 23:57:26 +0200 (CEST) From: Tobias Heer In-reply-to: <4FAB82AD.60604@gmail.com> Date: Thu, 10 May 2012 23:57:26 +0200 Content-transfer-encoding: quoted-printable Message-id: <54B2ABB4-ABD9-4AFC-8602-72AFDD7F5C4E@cs.rwth-aachen.de> References: <4FAB82AD.60604@gmail.com> To: Xin Gu X-Mailer: Apple Mail (2.1084) Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIPv1 to HIPv2 transition issues X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 21:57:30 -0000 Hi, Am 10.05.2012 um 10:56 schrieb Xin Gu: > Hi everyone, >=20 > 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? >=20 > 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: >=20 > 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.=20 >=20 > 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. >=20 > The interoperability table below shows all possible conditions: > =20 > 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 >=20 > = --------------------------------------------------------------------------= ----- > 1) V1 responder 2) V2 responder 3) Dual = responder > HITv1 HIT_OGA HITv1 & = HIT_OGA >=20 > a) V1 initiator v1 no v1* > HITv1 >=20 > b) V2 initiator no v2 v2* > HIT_OGA >=20 > c) Dual initiator v1* v2* v1/v2* > HITv1 & HIT_OGA > = --------------------------------------------------------------------------= ----- > Interoperability table >=20 > All gap cases are marked by an asterisk in the cell: > =95 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. > =95 Cell c1, similar to Cell c2. > =95 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. > =95 Cell a3, similar to Cell b3. > =95 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? >=20 > 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). >=20 > 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. >=20 >=20 > Miika and I have been actively discussing on these issues. Hope we can = also get advice from all experts here. Thanks a lot. >=20 > Best regards, > Xin Gu >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --=20 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=20 From eric.nevup@gmail.com Fri May 11 00:24:22 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64FD21F85D2 for ; Fri, 11 May 2012 00:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMeYtRKysXOQ for ; Fri, 11 May 2012 00:24:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8ADC21F85CF for ; Fri, 11 May 2012 00:24:21 -0700 (PDT) Received: by lagv3 with SMTP id v3so494862lag.31 for ; Fri, 11 May 2012 00:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DWCReN6F2QvaPQWL9+1IzV5ddOP/jI/u2PBDEUbL2Js=; b=LQ7IYQ9evpqJvUMQvXzcmO8iRtCyPZ3y6KEliwYtW+ju6HOx/Mctl2vdD/HsydxQmG YPwyUBQqbKlAEFfDD/ydL8f+cdv2UFLJ5/hXPrXwOyQVlSxZGwyP6zYEzF83y8dOf4sJ 610QgYrqNLFhqwFbodxktewdpblxOBtP9EFmIoVrHPa4F4sPb/srEAO4qY/TO1SePXic uG/MsMB9aWBmSvtpyrt9Uck92y/6VevxWprVQqMkqa6TXGkCR6vk/ONHk9d4hZHRpWRu Sv+tV8ZDO/iTpnbEIE006KQ8+vwc9VN+9G86hZVs5iEDejL6Mvz3Ij8op2Fo1yw/jmDc 0ANg== Received: by 10.152.131.74 with SMTP id ok10mr7342055lab.17.1336721060844; Fri, 11 May 2012 00:24:20 -0700 (PDT) Received: from [130.233.48.170] (tt-dhcp-70.tt.hut.fi. [130.233.48.170]) by mx.google.com with ESMTPS id j5sm10706600lbg.1.2012.05.11.00.24.18 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 00:24:19 -0700 (PDT) Message-ID: <4FACBEA2.8080707@gmail.com> Date: Fri, 11 May 2012 10:24:18 +0300 From: Xin Gu User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tobias Heer References: <4FAB82AD.60604@gmail.com> <54B2ABB4-ABD9-4AFC-8602-72AFDD7F5C4E@cs.rwth-aachen.de> In-Reply-To: <54B2ABB4-ABD9-4AFC-8602-72AFDD7F5C4E@cs.rwth-aachen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIPv1 to HIPv2 transition issues X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 07:24:22 -0000 Hi, On 11/05/12 00:57, Tobias Heer wrote: > 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? > > 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 g.c.prasad@gmail.com Sun May 13 22:38:41 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF821F8595 for ; Sun, 13 May 2012 22:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftTMhzhL27oQ for ; Sun, 13 May 2012 22:38:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3F21F8471 for ; Sun, 13 May 2012 22:38:40 -0700 (PDT) Received: by bkty8 with SMTP id y8so4034930bkt.31 for ; Sun, 13 May 2012 22:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Lx0bT0VmnDTh+WtNHjL52TzqDWudM9RhfGeD8Chl4aU=; b=hndr3GjTaNaHWOdo+w/dUW118m3QjM+ItrPzLvAPLn6YwVyPfsvguQRMpTlaRJIihZ mrAIgjeyUodFFcza4YoV1ZHeDd/BXBgVRSU+fwdA0C5U7rFWekNfQUd6+CrgFWVM5+kB gbQuLbfCu5So2zzBaELhP/pG4l9pXzTurWeBEyBRF3haQNuwNswvswFHwZEeMCRWhRc0 sgMVI3JT/zAAbP79eGGaYLgdwfB6zcMXP4eLJW/A61+Sp3U3ruA9f4VkctYA8JPENJQG g5rPDlswSsMLMXKxylpHAkYz+goUFGyg9Tre50fmOTLZ8LJJKXK1zSBq/fkivVd/4trU xfeQ== Received: by 10.205.133.193 with SMTP id hz1mr2605015bkc.31.1336973919685; Sun, 13 May 2012 22:38:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.40.132 with HTTP; Sun, 13 May 2012 22:38:19 -0700 (PDT) From: Ganesh and Sashi Prasad Date: Mon, 14 May 2012 15:38:19 +1000 Message-ID: To: hipsec@ietf.org Content-Type: multipart/alternative; boundary=0015174769768e8c4c04bff87f3c Subject: [Hipsec] Feedback on RFC 4423 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 05:40:24 -0000 --0015174769768e8c4c04bff87f3c Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm writing to express my appreciation for the wonderful work you have done in explaining the need for a conceptual layer (HIP) to decouple the issues of host identity and host location. I'm also writing to warn of another potential source of coupling in the RFC 4423 proposal. >From my own experience implementing Identity and Access Management systems ( http://bit.ly/FR6REH), I have come to realise that identifiers and identity credentials are two different concepts, and that conflating the two can lead to problems. To be fair, you too have recognised that the two are different, but you are still proposing that verifiable credentials be used in place of plain identifiers for reasons of security. "In theory, any name that can claim to be 'statistically globally unique' may serve as a Host Identifier. However, in the authors' opinion, a public key of a 'public key pair' makes the best Host Identifier. As will be specified in the Host Identity Protocol specification, a public-key-based HI can authenticate the HIP packets and protect them from man-in-the-middle attacks." While I agree that a secure implementation of HIP is non-negotiable, we need to conceptually separate the host identifier from the mechanisms we use to reliably assert it. I would argue that a public key is only one of potentially several mechanisms that could be used, and we should not enshrine one such mechanism in the HIP protocol to the exclusion of others. Signed SAML2 assertions may be another valid way to assert identity in an untrusted environment. Within a trusted environment, the raw and meaning-free identifier may be used by itself without impact. I am a big fan of random UUIDs as meaning-free identifiers in a wide variety of contexts, and I would be happy to see a bit more design into this crucial aspect of your excellent proposal. Thanks and regards, Ganesh --0015174769768e8c4c04bff87f3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm writing to ex= press my appreciation for the wonderful work you have done in explaining th= e need for a conceptual layer (HIP) to decouple the issues of host identity= and host location. I'm also writing to warn of another potential sourc= e of coupling in the RFC 4423 proposal.

From my own experience implementing Identity and Acce= ss Management systems (http://bit.ly/FR6REH), I have come to realise t= hat identifiers and identity credentials are two different concepts, and th= at conflating the two can lead to problems. To be fair, you too have recogn= ised that the two are different, but you are still proposing that verifiabl= e credentials be used in place of plain identifiers for reasons of security= .

"In theory, any name that can claim to be 's= tatistically globally unique' may serve as a Host Identifier. However, = in the authors' opinion, a public key of a 'public key pair' ma= kes the best Host Identifier. As will be specified in the Host Identity Pro= tocol specification, a public-key-based HI can authenticate the HIP packets= and protect them from man-in-the-middle attacks."

While I agree that a secure implementation of HIP is = non-negotiable, we need to conceptually separate the host identifier from t= he mechanisms we use to reliably assert it. I would argue that a public key= is only one of potentially several mechanisms that could be used, and we s= hould not enshrine one such mechanism in the HIP protocol to the exclusion = of others. Signed SAML2 assertions may be another valid way to assert ident= ity in an untrusted environment. Within a trusted environment, the raw and = meaning-free identifier may be used by itself without impact. I am a big fa= n of random UUIDs as meaning-free identifiers in a wide variety of contexts= , and I would be happy to see a bit more design into this crucial aspect of= your excellent proposal.

Thanks and regards,
Ganes= h --0015174769768e8c4c04bff87f3c-- From mkomu@cs.hut.fi Sun May 13 22:59:40 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A7D21F84D9 for ; Sun, 13 May 2012 22:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDqvLK7ZH7iE for ; Sun, 13 May 2012 22:59:40 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 372A821F847C for ; Sun, 13 May 2012 22:59:40 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1SToJm-0005Dy-Og for hipsec@ietf.org; Mon, 14 May 2012 08:59:38 +0300 Message-ID: <4FB09F47.5080401@cs.hut.fi> Date: Mon, 14 May 2012 08:59:35 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: hip WG References: <4FAB82AD.60604@gmail.com> <54B2ABB4-ABD9-4AFC-8602-72AFDD7F5C4E@cs.rwth-aachen.de> In-Reply-To: <54B2ABB4-ABD9-4AFC-8602-72AFDD7F5C4E@cs.rwth-aachen.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIPv1 to HIPv2 transition issues X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 05:59:41 -0000 Hi, On 11/05/12 00:57, Tobias Heer wrote: > 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? 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.