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

Wassim Haddad <whaddad@tcs.hut.fi> Tue, 15 August 2006 18:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD41u-0001LC-Sr; Tue, 15 Aug 2006 14:52:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD41t-0001L6-Fv for mipshop@ietf.org; Tue, 15 Aug 2006 14:52:45 -0400
Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD41q-0006pL-0g for mipshop@ietf.org; Tue, 15 Aug 2006 14:52:45 -0400
Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 84F6F800604; Tue, 15 Aug 2006 21:52:40 +0300 (EEST)
Date: Tue, 15 Aug 2006 21:52:40 +0300
From: Wassim Haddad <whaddad@tcs.hut.fi>
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)
In-Reply-To: <C24CB51D5AA800449982D9BCB903251311A6D3@NAEX13.na.qualcomm.com>
Message-ID: <Pine.LNX.4.58.0608152115450.21981@rhea.tcs.hut.fi>
References: <C24CB51D5AA800449982D9BCB903251311A6D3@NAEX13.na.qualcomm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: Christian Vogt <chvogt@tm.uka.de>, 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

On Tue, 15 Aug 2006, Narayanan, Vidya wrote:

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

=> Perhaps "very" is a strong word. Can you please clarify why?
I still fail to understand why if the MN (wanting to use RO mode with the
CN) decides to use CGA with the CN then enabling the HA to verify the CGA
is very valuable? Do you have any particular threat in mind? If not, can
you please point to the advantage?

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

=> This sounds very general to me (especially that OMIPv6_CGA_CBA is
about the RO mode only). The goals that OMIPv6 aims to achieve are
clearly stated in the draft and the draft also explains why and how these
goals have been achieved. I'd be very interested if you can please clarify
what exactly you see as a problem in the RO mode (only) and would like to
see optimized?

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

=> Again this sems very general. Please clarify more.
Note that other *additional* optimization (which are directly or
indirectly connected to the mobility) are already "ongoing" work.


Wassim H.

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