Subject: [dmm] Draft related to DMM

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 07 Mar 2011 19:35:14 +0100

Hi folks,

(apologies for the cross-posting)

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

Comments, as usual, are welcome!

Carlos

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

---

From: Pete McCann <[email-masked]>
Date: Mon, 7 Mar 2011 16:31:44 -0600

Hi, Carlos,

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

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.

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?

-Pete

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 09 Mar 2011 18:02:26 +0100

Hi Pete,

Thanks for the feedback

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

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

> opportunities for synergy here, if say, EAP was used to authenticate

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