RE: [netlmm] RE: Review of draft-singh-netlmm-protocol-00

Hi Ajoy,

I agree that separation of CP/BP with a Standalone PMIP client (PMA) is a key point. Of course the price to pay is a new "AR-PMIP client" interface that is not yet clearly specified. Despite this, the concept is interesting because it goes in the direction of some SDOs and is aligned with architectures relying on a standalone mobility manager (e.g. 3GPP SAE). 

Regards,
Pierrick

-----Message d'origine-----
De : Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] 
Envoyé : jeudi 25 janvier 2007 20:33
À : Christian Vogt
Cc : Netlmm
Objet : [netlmm] RE: Review of draft-singh-netlmm-protocol-00

Hi,  Christian, 

Please find inline responses. 

Regards,
Ajoy 

-----Original Message-----
From: Christian Vogt [mailto:chvogt@tm.uka.de] 
Sent: Thursday, January 25, 2007 12:20 PM
To: Singh Ajoy-ASINGH1
Cc: Bedekar Anand-ABEDEKA1; Kalyanasundaram Suresh-CSK090; Netlmm
Subject: Re: Review of draft-singh-netlmm-protocol-00

Hi Ajoy -

I agree with the removed comments.  Further comments in-line...

> Another concept of the protocol proposal is that, for a given mobile 
> node, the security association through which the mobile node ends up 
> being proxied to the LMA is unique.
> The consequence of this is that there either is only a single PMIP 
> client in the PMIP domain, and all signaling for all MNs goes through 
> the single SA between that PMIP client and the LMA.  Or the security 
> associations between a PMIP client and the LMA cannot be 
> preestablished, but rather needs to be set up on a per-mobile-node 
> basis.  The rationale behind this idea is to adopt the RFC 3775/3776 
> concept of having one SA per mobile node.  Yet I think the price to be

> paid for this concept is too high, due to the following reasons:
> 
>     - An inherent property of localized MM is that one can
>     assume that it is used in a single administrative domain.
>     (Inter-domain handovers can be considered separately.)
>     This means that entities within the PMIP domain know each
>     other and, once mutually authenticated, can trust each
>     other.  (Access points and other equipment which an
>     attacker could easily get his hands on are an exception
>     as they are at an increased risk to subversion.)  The
>     per-MN SAs in RFC 3775 are necessary because no entities
>     from within the access network are involved in a home
>     registration.  But in a localized MM domain, per-MN SAs
>     are not required IMO.
> 
>     - Using per-MN SAs for PMIPv6 increases the number of SAs
>     significantly.  This might be a scalability issue.
>     Moreover, since each SA needs to be set up through IKE,
>     and each such set-up requires a-priori interaction with
>     the AAA infrastructure, signaling overhead and latency
>     increases as well.
> 
> Ajoy-> Ok, agree. Ideally it will be better to have single SA between
> PMA and LMA. But please note that
> per-MN SA increases reuse of existing protocol, and this is a 
> desirable outcome per the requirements draft.
> Note that a standard MIPv6 HA handles per-MN security associations 
> already, so if the LMA has to handle per-MN security associations, it 
> won't be any worse off than a standard MIPv6 HA. However, we are open 
> to make this change if there is such interest in WG, but we do believe

> there is merit in making LMA as close to MIPv6 HA as possible.

In RFC 3775 MIPv6, there is a need for per-MN SAs because the protocol
runs between the MN and the HA.  But in the case of PMIP6, the protocol
runs between the PMIP client and the HA, so one SA for multiple MN
should be fine.  As you say, it's a trade-off between reusability and
efficiency.  But in this case I would personally opt for efficiency.

Ajoy-> Okay. We would like to hear from other folks as well. Note that
there is a clear business reason for re-using MIPv6 HA for both local
and global mobility. The re-use of MIPv6 HA for local and global
mobility will reduce overall production cost of MIPv6 HA and thereby
increase the deployment of MIPv6 based solution. 

> In summary, I would recommend three changes to the protocol
> proposal:
> 
>     - Use a single, possibly pre-configured SA between each
>     PMIP client and an LMA.  The LMA trusts all signaling
>     that is protected through this SA, even though it may
>     pertain to different MNs, and even though different
>     registrations for the same MN may arrive through
>     different such SAs.
> 
> Ajoy-> See above. 
> 
>     - Allow the serving PMIP client to change while the MN
>     roams across the PMIP domain.  E.g., the PMIP client
>     might always be colocated with the currently serving
>     access router.
> 
> Ajoy-> OK, this can be considered as an enhancement to our proposal. 
> Ajoy-> Do
> you see any need to consider
> this in base draft, or dealt with as an add-on? 

What I originally had in mind when writing this was that you might
actually merge the PMIP client functionality into the access router so
as to avoid a separate entity.  The serving PMIP client would then move
with the MN as the MN hands over from AR to AR.  In this case, you would
not have to worry about the security between the access router and the
PMIP client as the two would always be within one box. 
  Of course, it would require the use of one single SA between each PMIP
client and the LMA.

But if you want to leave the PMIP client as a separate entity so as to
separate the control plane from the data plane more cleanly, then, yes,
I agree that PMIP client migration can be left as future work.

Ajoy-> I would prefer to keep the separation of BP/CP. IMHO, this is a
good thing and simplifies the netlmm protocol. Separation of BP/CP will
also enhance the scalability of access network. 

>     - Address the security for signaling between the access
>     router and the PMIP client.  It may be sufficient if you
>     assume the two entities are colocated and leave the
>     protocol between the access router and an external PMIP
>     client as future work.
> 
> Ajoy-> Please see my comment above regarding the SA between PMIP 
> Ajoy-> client
> and AR. 
> 
> Finally, I would like to emphasize the clean separation of localized 
> MM and global MM in this draft.  According to section 4.4., it is the 
> MN's responsibility to initiate RFC
> 3775 signaling with its (global) home agent when moving from one LMA 
> to a different LMA in a possibly different PMIP domain.
> 
> Ajoy-> Thanks very much for the detailed review, Christian.
> In passing I'd also like to emphasize is that the draft allows a clean

> separation of bearer plane and control plane, which is aligned with 
> the architectural view of various SDOs including 3GPP / 3GPP2 / WIMAX
etc.

Alright.

Best regards,
- Christian

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

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

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