IETF Logo Mail Archive

Re: [MEXT] [dmm] Draft related to DMM

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Wed, 09 March 2011 16:59 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068503A6A64; Wed, 9 Mar 2011 08:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.575
X-Spam-Level:
X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uT4VRZvkD-W; Wed, 9 Mar 2011 08:59:44 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7B66D3A6A5F; Wed, 9 Mar 2011 08:59:44 -0800 (PST)
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 8E343BF349F; Wed, 9 Mar 2011 18:00:55 +0100 (CET)
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Pete McCann <mccap@petoni.org>
In-Reply-To: <AANLkTimxj_bM4vP_chT7gXy6HFow1u6R1_AV5ErCHRxU@mail.gmail.com>
References: <1299522914.4239.38.camel@acorde.it.uc3m.es> <AANLkTimxj_bM4vP_chT7gXy6HFow1u6R1_AV5ErCHRxU@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+h0RyKP4lIjeArYOCbB6"
Organization: Universidad Carlos III de Madrid
Date: Wed, 09 Mar 2011 18:02:26 +0100
Message-ID: <1299690146.2781.37.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18002.000
Cc: Antonio de la Oliva Delgado <aoliva@it.uc3m.es>, dmm@ietf.org, mext@ietf.org
Subject: Re: [MEXT] [dmm] Draft related to DMM
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2011 16:59:46 -0000

Hi Pete,

Thanks for the feedback

On Mon, 2011-03-07 at 16:31 -0600, Pete McCann wrote:
> Hi, Carlos,
> 
> 2011/3/7 Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>es>:
> >
> > We have just submitted a draft related to DMM. The draft describes a
> > possible way of achieving a distributed mobility behavior with Client
> > Mobile IP, based on Mobile IPv6 and the use of Cryptographic Generated
> > Addresses.
> >
> > The draft is already on the I-D repository:
> >
> > http://www.ietf.org/id/draft-bernardos-mext-dmm-cmip-00.txt
> 
> I read through your draft, and I have a couple of questions.
> 
> First, it seems that you require a BU sent to the DAR right after
> SLAAC.  Is this the case?  Why do we need such a BU?

The BU is only sent if the MN wants to keep the reachability and session
continuity of an IPv6 address that was configured (and therefore is
anchored) at a previous DAR. In this case, the BU is sent to that
previous DAR, using as CoA the IPv6 address that has just configured
from the current DAR.

> 
> Second, how is the PHKT protected when it transits from the
> DAR to the MN?  Did you consider doing a simple Diffie-Hellman
> exchange to derive a PHKT for later use by the MN?  That would
> neatly avoid having to send the PHKT in the clear or to protect
> it with some sort of encryption wrapper.

We rely on the mechanisms described in
draft-laganier-mext-cga-01/RFC4866 for that (I don't remember the
details). I guess using D-H could also be a good option to derive the
token.

> 
> Third, how do you expect the CGA configuration to interact with
> the access network authentication that will be performed before
> the MN is allowed to attach to the first DAR?  Do you see any
> opportunities for synergy here, if say, EAP was used to authenticate
> and derive an MSK?

We haven't gone to that level of detail yet, to be honest. Interactions
with access network authentication and BU authorization issues are
definitely things that need to be further analyzed.

Thanks!

Carlos

> 
> -Pete

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

v2.8.7 | Report a Bug | By Email