Re: CGA-based HoA generation for MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)

Lakshminath Dondeti <ldondeti@qualcomm.com> Tue, 15 August 2006 19:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4IU-0006dC-4A; Tue, 15 Aug 2006 15:09:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4IS-0006bq-6N for mipshop@ietf.org; Tue, 15 Aug 2006 15:09:52 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD4IQ-0008PT-Qp for mipshop@ietf.org; Tue, 15 Aug 2006 15:09:52 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7FJ9luN007733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Aug 2006 12:09:48 -0700
Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7FJ9j7L013043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Aug 2006 12:09:46 -0700 (PDT)
Message-Id: <7.0.1.0.2.20060815120030.03da9910@qualcomm.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 15 Aug 2006 12:09:52 -0700
To: Christian Vogt <chvogt@tm.uka.de>
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
Subject: Re: CGA-based HoA generation for MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)
In-Reply-To: <44E2195B.9070900@tm.uka.de>
References: <C24CB51D5AA800449982D9BCB903251311A60A@NAEX13.na.qualcomm.com> <44E1AB09.2070904@tm.uka.de> <44E1C024.8020103@piuha.net> <7.0.1.0.2.20060815094403.05b12f28@qualcomm.com> <44E2195B.9070900@tm.uka.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: mipshop@ietf.org, Jari Arkko <jari.arkko@piuha.net>
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Errors-To: mipshop-bounces@ietf.org

At 11:58 AM 8/15/2006, Christian Vogt wrote:
>Hi Lakshminath,
>
>we do HoA authorization in any case.  The question is how:
>
>(a)  According to RFC 3775, the HA binds the MN's HoA to the IPsec SA
>during bootstrapping and re-verifies the HoA whenever it receives a BU
>from the MN.

Here's my take on it.  If at bootstrapping, the HA makes the leap (no 
way to always verify the HoA claim if the MN picks the HoA, but 
doesn't provide CGA assertion), yeah, you are right.  Although, I am 
still puzzled by your use of the word authorization in case of (a).

I am trying to make sure that the separation between actual address 
authorization (this is case b) and re-verification based on initial 
acceptance of an unverifiable claim (case a) is clear.  If all MNs 
use CGAs, the burden on a misbehaving MN is substantially high, in 
that it needs to find a collision to claim someone else's address.




>(b)  An alternative to this would be to have the HA verify the MN's HoA
>based on a CGA property.  This is what Vidya brought in.
>
>Given that approach (a) already exists for HoA verification (it's the
>default), there is actually no strong need for an additional approach
>(b), although it may be handy in some deployments.

In your view, what is the upside of CGAs in this scenario.

regards,
Lakshminath


>Best,
>- Christian
>
>--
>Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
>www.tm.uka.de/~chvogt/pubkey/
>
>
>
>Lakshminath Dondeti wrote:
> > At 05:37 AM 8/15/2006, Jari Arkko wrote:
> >> Christian Vogt wrote:
> >>
> >>> From a security perspective, I don't currently see a requirement
> >>> for the HA to know that the HoA is CGA-based, given that all
> >>> MN-HA security is IPsec-based:
> >>
> >> Agreed.
> >
> > I am confused by this and trying to understand the statement.
> > Doesn't this really depend on the security requirements?  CGAs and
> > secure channels (IPsec SA) provide very different things.  We might
> > say that there are no current requirements for HoA authorization and
> > I can buy that, but saying that the presence of an IPsec-based secure
> > channel obviates the need for CGAs confuses me.  What am I missing?
> >
> > regards, Lakshminath


_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop