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

Christian Vogt <chvogt@tm.uka.de> Tue, 15 August 2006 19:35 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4hD-0005gm-1o; Tue, 15 Aug 2006 15:35:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4hC-0005ge-AJ for mipshop@ietf.org; Tue, 15 Aug 2006 15:35:26 -0400
Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD4hB-00028t-OO for mipshop@ietf.org; Tue, 15 Aug 2006 15:35:26 -0400
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1GD4gr-0004I5-RS; Tue, 15 Aug 2006 21:35:13 +0200
Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8B7A2BF96; Tue, 15 Aug 2006 21:35:05 +0200 (CEST)
Message-ID: <44E221E9.1000304@tm.uka.de>
Date: Tue, 15 Aug 2006 21:35:05 +0200
From: Christian Vogt <chvogt@tm.uka.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.5) Gecko/20060725 SUSE/1.5.0.5-0.1 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: "Narayanan, Vidya" <vidyan@qualcomm.com>
Subject: Re: CGA-based HoA generation for MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)
References: <C24CB51D5AA800449982D9BCB903251311A6D3@NAEX13.na.qualcomm.com>
In-Reply-To: <C24CB51D5AA800449982D9BCB903251311A6D3@NAEX13.na.qualcomm.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.5 (----)
X-Spam-Status: No
X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.1 AWL AWL: From: address is in the auto white-list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: Wassim Haddad <whaddad@tcs.hut.fi>, 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

Narayanan, Vidya 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 don't know that this is true. As we know, what we get from IPsec 
> and CGAs are quite orthogonal benefits. In the case where the HA 
> assigns the HoA via IKEv2, HoA authorization at the HA is not needed,
>  since the HA knows that the IPsec SA is tied to the owner of the 
> corresponding HoA. Now, systems that allow stateless 
> autoconfiguration of HoAs may or may not want to ensure that those IP
>  addresses are authorized and verified. If a system employs CGAs in 
> the network, it is actually an indication that the system deployment 
> cares about IP address ownership verification. In this case, it 
> actually seems to me that the HA being able to verify the CGA would 
> be very valuable and needed.

You are raising an interesting point:  Whether the HA should verify that
the MN is authorized to /pick/ a particular /new/ HoA from the home prefix.

This is actually a different aspect of "HoA authorization" than ensuring
that a MN is live at a /given/ HoA -- and that it is therefore save to
redirect packets from this HoA to a CoA of the same MN.

I'd argue that, while the 2nd aspect is fundamental for mobility
security, the 1st aspect calls for proxy SEND, which could then combined
with Mobile IPv6 as you say.  And while the 2nd aspect is crucial for
the CGA-CBA protocol, I don't think there is a requirement for the 1st
aspect in the protocol.

Does this sound reasonable?

>>> From a practical standpoint, there may be a benefit for the HA to
>>> know that the MN's HoA is CGA-based.
>> 
>> Its possible to design mechanisms that employ the same tools also 
>> for the home agent registrations, or use the help of the home agent
>>  in the RO process. Such mechanisms would likely have some 
>> advantages.
> 
> Yes, I agree with the above. For this purpose, I think we should 
> analyze this further to see how best RO can be actually optimized. 
> Actually, considering all of this is why I suggested that if we want 
> to get an RFC on the cga-cba work now, it should preferably be 
> experimental, so that, we can move it to PS after we fully analyze 
> the space and are convinced this is optimized in the best possible 
> way.
> 
>> OTOH, there is also some value in keeping the two RO and HA 
>> registration mechanisms separate. E.g., you don't have to sync HA 
>> and MN code updates. IKEv2, auth option, and RFC 3776 all can 
>> support CGAs, though some with extra config effort.
> 
> Given that MIP6 hasn't seen much deployment yet and that RO is not 
> even considered in the pipeline yet in most planned MIP6 deployments 
> even, I am not so concerned about code updates. I think we should 
> work towards getting a fully optimized solution, so that RO in 
> general starts looking more attractive than it currently is.

Hmm, at this point I'm pretty much convinced that, if the HA would
verify the CGA property of the MN's HoA, that would actually not give
any benefit to RO.  It would certainly have its own uses.  But it would
be an orthogonal mechanism with orthogonal objectives (see above).

Having said that, IMO we should keep the two things separate as Jari
suggested.  All the more because the HoA verification at the HA seems to
 involve a proxy SEND mechanism which may not be so well understood at
this time as the pieces we need for the current CGA-CBA protocol.

Ciao,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/



Narayanan, Vidya wrote:
> 
> 
>> -----Original Message----- From: Jari Arkko 
>> [mailto:jari.arkko@piuha.net]
>> 
>> 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 don't know that this is true. As we know, what we get from IPsec 
> and CGAs are quite orthogonal benefits. In the case where the HA 
> assigns the HoA via IKEv2, HoA authorization at the HA is not needed,
>  since the HA knows that the IPsec SA is tied to the owner of the 
> corresponding HoA. Now, systems that allow stateless 
> autoconfiguration of HoAs may or may not want to ensure that those IP
>  addresses are authorized and verified. If a system employs CGAs in 
> the network, it is actually an indication that the system deployment 
> cares about IP address ownership verification. In this case, it 
> actually seems to me that the HA being able to verify the CGA would 
> be very valuable and needed.
> 
> 
>>> From a practical standpoint, there may be a benefit for the
>> HA to know
>>> that the MN's HoA is CGA-based.
>>> 
>>> 
>> Its possible to design mechanisms that employ the same tools also 
>> for the home agent registrations, or use the help of the home agent
>>  in the RO process. Such mechanisms would likely have some 
>> advantages.
> 
> Yes, I agree with the above. For this purpose, I think we should 
> analyze this further to see how best RO can be actually optimized. 
> Actually, considering all of this is why I suggested that if we want 
> to get an RFC on the cga-cba work now, it should preferably be 
> experimental, so that, we can move it to PS after we fully analyze 
> the space and are convinced this is optimized in the best possible 
> way.
> 
>> OTOH, there is also some value in keeping the two RO and HA 
>> registration mechanisms separate. E.g., you don't have to sync HA 
>> and MN code updates. IKEv2, auth option, and RFC 3776 all can 
>> support CGAs, though some with extra config effort.
>> 
> 
> Given that MIP6 hasn't seen much deployment yet and that RO is not 
> even considered in the pipeline yet in most planned MIP6 deployments 
> even, I am not so concerned about code updates. I think we should 
> work towards getting a fully optimized solution, so that RO in 
> general starts looking more attractive than it currently is.
> 
> Vidya


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