Subject: Re: [netlmm] AD review of draft-ietf-netlmm-mip-interactions

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Apr 2010 11:17:18 +0300

Any updates on this?

Jari

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 30 Apr 2010 15:29:02 -0700

Hi Jari,

Sorry for the long delay on this. I revised the document based on your comments and Christian's ones. Please see inline for comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jari Arkko
> Sent: Wednesday, December 09, 2009 3:42 AM
> To: [email-masked]; [email-masked]
> Subject: [netlmm] AD review of draft-ietf-netlmm-mip-interactions
> 
> I have finally made my AD review of this document. Apologies for the
> delay. Overall, the document was easy to read and I had no major
> problems. I do want you to revise the document for the following
> issues,
> however:
> 
> The document should state that the list of scenarios is not exhaustive.
> (Or convince the reader that the given scenarios are the only possible
> ones.)
> 

In the introduction I changed the following text:

OLD TEXT

      <t>This document provides a taxonomy of all scenarios that require
      direct interaction between MIPv6 and PMIPv6. Moreover, this document
      presents and identifies all issues pertained to these scenarios and
      discusses possible means and mechanisms that are recommended to enable
      them.</t>

NEW TEXT

      <t>This document provides a taxonomy of the most common scenarios that require
      direct interaction between MIPv6 and PMIPv6. The list is not meant to be 
      exhaustive. Moreover, this document presents and identifies all issues 
      pertained to these scenarios and discusses possible means and mechanisms 
      that are recommended to enable them.</t>

> Section 3.2 should talk about how you can identify nodes that get PMIP
> service and those that don't. This does not seem like a trivial
> exercise. You can make a policy lookup, but then you rely on the
> operator knowing what software your device has. I realize that you rule
> this out of scope later, and I do not ask you to explain the specific
> mechanisms. I am asking you to outline the implications of having a
> mechanism.
> 
> I would also like the authors to respond to Christian Vogt's review
> (posted October 1st). I did not see a response, but maybe I missed it.
> 

Done

> What about Basavaraj Patil's question in the mailing list on October
> 21st? Is there a need to add something to the document about his
> scenario?
> 

I think at that time I discussed with Raj there was no need. Raj can jump in if needed.

> >    The solution for this scenario may depend on the access network
> being
> >    able to determine that a particular mobile node wants to use
> Mobile
> >    IPv6.
> Only a "may depend"? How would it otherwise work? I would suggest
> /s/may
> depend/depend/
> 

Done

> > As described in
> > [RFC4877 <http://tools.ietf.org/html/rfc4877>], the identifier of the
> MN is known by the Home Agent
> > after the IKEv2 exchange, but this is not used in the MIPv6
> > signaling, nor as a lookup key for the binding cache.
> 
> Maybe you should bring that if authentication is performed at the MIP
> layer (authentication option) then this information is available. In
> other words, authentication mechanisms differ with respect to the ease
> that the identifier will be available.
> 

I am not sure we want to take the authentication option into consideration here. The lookup keys in the binding cache will be anyway different and so the issue will still be there. 

> > Since all these steps must be performed by the mobile node before
> > sending the Binding Update, they have an impact on the handover
> > latency experienced by the MN.  For this reason it is recommended
> > that the mobile node establishes the IPsec security association (and
> > consequently is provided by the HA/LMA with a MIPv6-HoA) when it is
> > still attached to the PMIPv6 domain.
> 
> But the steps are configuration tasks, and there is no need to perform
> them on a per-movement basis. A far better recommendation would be to
> move the steps to mobile node initialization time or to a periodic
> process.
> 

I think that was what we meant. I rephrased as follows:

OLD TEXT

          Since all these steps must be performed by the mobile node before
          sending the Binding Update, they have an impact on the handover
          latency experienced by the MN. For this reason it is recommended
          that the mobile node establishes the IPsec security association (and
          consequently is provided by the HA/LMA with a MIPv6-HoA) when it is
          still attached to the PMIPv6 domain. This implies that the mobile
          node has Mobile IPv6 stack active while in the PMIPv6 domain, but as
          long as it is attached to the same Proxy Mobile IPv6 domain, it will
          appear to the mobile node as if it is attached to the home link.

NEW TEXT

          Since all these steps must be performed by the mobile node before
          sending the Binding Update, they have an impact on the handover
          latency experienced by the MN. For this reason it is recommended
          that the mobile node establishes the IPsec security association (and
          consequently is provided by the HA/LMA with a MIPv6-HoA) when it is
          initialized. This implies that the mobile
          node has Mobile IPv6 stack active while in the PMIPv6 domain, but as
          long as it is attached to the same Proxy Mobile IPv6 domain, it will
          appear to the mobile node as if it is attached to the home link.

> > The MAG needs to discover the
> > HA/LMA; however the current version of [RFC5213
> <http://tools.ietf.org/html/rfc5213>] assumes that the LMA
> > is assigned to the MAG or discovered by the MAG when the mobile node
> > attaches to the MAG. the exact mechanism is not specified in
> > [RFC5213 <http://tools.ietf.org/html/rfc5213>].
> 
> I think it would be fair to state somewhere that in configurations
> where
> there is just one of these nodes, the discovery is not an issue.
> 

I removed the text based on comments from Christian

> > This document requires that the a home agent that also implements the
> > PMIPv6 LMA functionality should allow both the mobile node and the
> > authorized MAGs to modify the binding cache entries for the mobile
> > node.  Note that the compromised MAG threat described in [RFC4832
> <http://tools.ietf.org/html/rfc4832>]
> > applies also here.
> >
> 
> I would like to see a discussion of what the security policy database
> entries need to look like in this situation. For instance, is it
> possible to have such a configuration?
> 

This is possible as the SPD is keyed on the HoA in one case and on the MAG address in the other case. SPD for one direction would look like:

MIP
>From HoA to HA proto MIP6 protect

PMIP
>From MAG to HA proto MIP6 protect 

> > The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6
> > (MIPv6) protocols are both deployed in a network require some
> > analysis and considerations.  This document describes all identified
> > possible scenarios, which require an interaction between PMIPv6 and
> > MIPv6 and discusses all issues related to these scenarios.  Solutions
> > and recommendations to enable these scenarios are also described.
> 
> Clumsy language. Maybe "The use of Proxy Mobile IPv6 (PMIPv6) and
> Mobile
> IPv6 (MIPv6) in the same network requires some care. This document
> discusses scenarios where such mixed usage is appropriate and points
> out
> the need for interaction between the two mechanisms. Solutions ..."
> 

Done

> 
> >    Some SDOs are also investigating more complex scenarios where the
> Expand the term SDO or use some other phrase.
> 

Done

> > However, in case there are nodes that implement Mobile IPv6 and want
> > to use this protocol, the network must offer MIPv6 service to them.
> >
> 
> There is no "MIPv6 service" in this case. It would be better to say,
> e.g., "must offer plain IP connectivity service without proxy
> mobility".
> 

Done 

> >    advertising the HNP, the MAG should advertise the topologically
> 
> The term HNP has not appeared before (at least not outside "MN-HNP"
> which is presumably another term).
> 

Fixed

> > This section highlights some considerations that are applicable to
> > scenario C where the LMA and HA are logically collocated and need to
> > be evaluated when selecting the technical approach to be chosen.
> >
> 
> Complex sentence that seems to be repeating the same thing.
> 

NEW TEXT

This section highlights some considerations that are applicable to scenario A.2

> > based on the base specification [RFC3775
> <http://tools.ietf.org/html/rfc3775>]
> 
> I'm sure there's a better way to write this...
> 

Fixed

> >           ordered by a timestamp option. .
> 
> Garbage at the end.
> 

Fixed all the rest.

Thanks
Gerardo

> > If a different LMA is
> > assigned to the MAG, the mobile node will not be on the home
> > link but will still have an active MIPv6 binding cache entry
> > and this may be not desirable in some deployments..
> >
> 
> Garbage at the end. Please also explain why this is not desirable.
> 
> >    LMA hss changed, and therefore the mobile node sends a MIPv6
> Binding
> 
> s/hss/has/
> 
> >    o  The downlink packets in the case where both the MIPv6 binding
> >       cache entry and PMIPv6 binding cache entry exist are processed
> as
> >       follows:
> >
> >    o
> >
> >       1.  The MIPv6 binding cache entry is processed first.  If the
> >
> 
> Odd indentation & bullet style.
> 
> Jari
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm