Subject: [netlmm] pmip6-07 review

From: "Alper Yegin" <[email-masked]>
Date: Mon, 3 Dec 2007 03:10:52 +0200

Thank you editors for the hard work!

Here are my comments on pmip6-07 I-D.

   Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to
   an access link, the mobile access gateway on that access link, after
   identifying the mobile node and acquiring its identity, will
   determine if the mobile node is authorized for the network-based
   mobility management service.

How? I presume this is one of those "out of scope" components. We shall
state that.

Do we have to bundle the IPsec-based security mechanism with the base spec?
Can't we document it separately, like we did for MIP6?

   o  The access technology through which the mobile node is currently
      connected.  This is obtained from the Access Technology Type
      option, present in the Proxy Binding Update message.

If there are more than one interfaces of the same type this fails to serve
any identification purpose. Multiple interfaces of same type is not
unrealistic for CPEs.

   Typically, the MN-Identifier is the key for locating a Binding Cache
   entry.  

I had challenged this before the WG last call and there was no response. Why
can't we rely on out-of band HNP assignment, such that HNP is present in all
PBUs and that's the key for locating the BCE? 

Given that the MAG has to know the LMA that is assigned for a MN and the
policy of whether PMIP6 is enabled for the MN and HI flag value etc.,
additionally knowing the HNP is not an added complexity. If we do that, the
complexity around MN-Id and MN-IfId goes away. What do we lose?

   o  If the requesting prefix in the Home Network Prefix option is a
      non 0::/0 value and is different from what is present in the
      currently active Binding Cache entry for that mobile node, the
      local mobility anchor MUST reject the request and send a Proxy
      Binding Acknowledgement message with Status field set to 129
      (Administratively Prohibited).

Why so? By doing that the spec is prohibiting use of multiple HNPs by the
MN.

   o  If the received Proxy Binding Update request with the lifetime
      value of zero, has a Source Address in the IPv6 header different
      from what is present in the Proxy-CoA address field in the Binding
      Cache entry existing for that mobile node, the local mobility
      anchor MUST ignore the request.

Why so? I cannot think of a direct side effect, but unless we really need it
why create such constraints -- it may bite us down the road.

   o  The message MUST be protected by using IPsec, using the security
      association existing between the local mobility anchor and the
      mobile access gateway.

SHOULD be protected.

   o  If there exists a Binding Cache entry and if the Handoff Indicator
      flag in the Access Technology Type option present in the received
      Proxy Binding Update message is set to value 4 (Handoff state
      unknown), the local mobility anchor SHOULD wait till the existing
      Binding Cache entry is de-registered by the previously serving
      mobile access gateway, before it assigns the same home network
      prefix or updates the existing Binding Cache entry.  However, if
      there is no de-registration message that is received within a
      given amount of time, the local mobility anchor upon accepting the
      request MUST assign a new home network prefix and create a new
      Binding Cache entry.  The local mobility anchor MAY also choose to
      assign a new home network prefix and without waiting for a de-
      registration message.

What would be that "given amount of time"? This can significantly delay the
network entry and even cause disruption.

   o  If there does not exist a Binding Cache entry and if the Handoff
      Indicator flag in the Access Technology Type option present in the
      received Proxy Binding Update message is set to value 2 (Handoff
      between interfaces), the local mobility anchor MUST verify if
      there exists one and only one Binding Cache entry for the mobile
      node, identified by the MN-Identifier and with any interface
      identifier value.  If there exists such an entry, the local
      mobility anchor upon accepting the request MUST update the
      existing Binding Cache entry and assign the home network prefix
      present in the Binding Cache entry.

Is there an assumption that either all interfaces are using the same HNP, or
they are all using different HNPs. For example, you cannot have two sharing
the same HNP, and the 3rd one is using a different HNP.

   o  The IPv6 home network prefix of the attached mobile node.  The
      home network prefix of the mobile node is acquired from the mobile
      node's local mobility anchor through the received Proxy Binding
      Acknowledgement messages.  The IPv6 home network prefix also
      includes the corresponding prefix length.

This is just one of the options as presented in this I-D. The other option
is to acquire HNP out-of band.

   Alternatively, one of the workarounds for this issue is to set the
   DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that
   will force the mobile node to redo DAD operation on the global and
   link-local addresses every time the interface detects a handover,
   even when DNAv6 does not detect a link change.

Not sure if this makes sense. First of all, this is a config on MNs, which
we had declared untouchable, off-the-shelf entities. Even if we could do
that, that'd simply disable the whole DNA optimization on the MN just in
case it encounters a PMIP6 network. Can anyone use DNA now?

   o  The Handoff Indicator flag in the Access Technology Type option
      MUST be set to value 2 (Handoff between interfaces), if the mobile
      access gateway definitively knows the mobile node's current
      attachment is due to a handoff of the mobility session between two
      interfaces of the mobile node.

How does the MAG know that? State this is out-of scope (AAA, context
transfer, etc..). 

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp),
      the mobile access gateway SHOULD try to register again only after
      it has synchronized its clock to a common time source that is used
      by all the mobility entities in that domain for their clock
      synchronization.  The mobile access gateway SHOULD NOT synchronize
      its clock to the local mobility anchor's system clock, based on
      the timestamp present in the received message.

I think it makes sense for the MAG to identify the delta between its clock
and each LMA it communicates with. Using this delta, it can generate
sufficiently fresh PBUs without synchronizing its clock with each and every
LMA. Note that there may be a mesh of LMAs and MAGs, belonging to different
administrative domains.

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
      (Not authorized for that prefix), the mobile access gateway SHOULD
      try to request for that prefix in the binding registration
      request, only after it learned the validity of that prefix.

How does the MAG learn the validity of the prefix? Can we get an example in
e-mail even if this is an out-of scope component?

   o  The message MUST be protected by using IPsec, using the security
      association existing between the local mobility anchor and the
      mobile access gateway.

SHOULD be....

   o  The DHCPv6 relay agent [RFC-3315] service needs to be enabled on
      each of the access links in the Proxy Mobile IPv6 domain.

Alternatively DHCP server may be on the MAG.

   However, the mobile node will always detect a new default-router on
   each connected link, but still advertising the mobile node's home
   network prefix as the on-link prefix and with the other configuration
   parameters consistent with its home link properties.

In case each MAG has a different link-layer address, can we always assume
the MN will discover it upon attachment? If not, then the MN may assume the
previous MAG's link-layer address is still usable. It may take a full NUD to
detect the problem, which effects the handover performance.

   The mobile node must
   update its default-router list with the new default router entry and
   must age out the previously learnt default router entry from its
   cache, just as specified in Section 6.3.5 [RFC-4861].  

We cannot be really mandating this on the MN.
Also, if we eagerly switch default routers, this prevents use of multiple
MAGs on the same link. MN will ignore MAG1 as soon as it hears from MAG2. OK
maybe this is not something we need, but let's make sure to consider this
side effect.

     Interface Identifier

         A variable length field containing the mobile node's interface
         identifier.

If we don't add an "interface type" field, we may cause collisions among two
different types of interfaces in case they map to the same bits.

   To address the threat related to a compromised mobile access gateway,
   the local mobility anchor, before accepting a Proxy Binding Update
   message for a given mobile node, may ensure that the mobile node is
   definitively attached to the mobile access gateway that sent the
   proxy binding registration request.  

Is that "may" sufficient?

Regards,

Alper 

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 11 Dec 2007 19:43:35 -0800

Hi Alper,

Please see inline.

Regards
Sri 

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Sunday, December 02, 2007 5:11 PM
> To: [email-masked]
> Subject: [netlmm] pmip6-07 review
> 

[Sri] The above is the introduction text. This is specified in
the section 6.5. "Access Authentication & Mobile Node Identification",

   "The exact specifics on how this is achieved or the
   interactions between the mobile access gateway and the access
   security service is outside the scope of this document."

Let me know, if you are not ok with this.

> Can't we document it separately, like we did for MIP6?

[Sri] 3775 requires lot more interaction and specification because
of the MN's HoA and for using CoA for IKE messages. In case of
PMIP6, this is a simple IPSec setup between two network nodes and
so there is not much we need to specify here and so dont see a need
for a separate document.

> any identification purpose. Multiple interfaces of same type is not

[Sri] We have the interface identifier for uniquely identifying
the mobile node's interface (same or different type). The multi-homing
text adopted as concluded in the ML discussion.

> PBUs and that's the key for locating the BCE? 

[Sri] I know you want the HNP as the MN-Identifier as supposed to a
MN-Id requirement in all messages. To restate our position on this ..
I know, you wont agree nothing other than MN-Id removal :)

1.) LMA is the anchor point for the prefix and from routing sense,
it owns that prefix. It is logical that we allow LMA to manage the
address management function. 

2.) We do allow MAG to learn the HNP thru out-of-band mechanisms 
and request the same from the LMA. Again, its upto the LMA to honor
that request or not. But, it may be possible the MAG in the access
network may not always know the mobile's HNP. 

3.) The MAG may or may not always know the mobile node's HNP. This
can be a statically assigned value for each MN or dynamically
allocated and deallocated. The spec supports both the schemes.

4.) HNP is not a stable identifier that the protocol entities can
rely on for identifying the mobile node. There will be error scenarios
such as LMA/MAG rebooting and the entities incorrectly identifying the
mobile, as the prefix may have been allocated to a new mobile. The
doc requires MN-Id to be a stable identifier, that they can be
exchanged in signaling messages.

5.) Supporting ONLY out of band mechanism for address allocation is
too restrictive. We should allow other modes.

> Why so? By doing that the spec is prohibiting use of multiple 

[Sri] The mobile can always get different prefixes on different
interfaces. For a given interface, we assign one prefix. We did not
specify the other feature of multiple prefixes on the same interface.
This can be done as an extension, if there is a usecase.

> why create such constraints -- it may bite us down the road.

[Sri] If the dereg message from the prev-MAG that created the mobility
session arrives at the LMA after the new-MAG completed the signaling,
the LMA will not be able to match the message to any BCE. So, we need
to say, what the LMA should do. But, I see your point that this is
bad constraint. Will change the "MUST" to "SHOULD", if others have no
issue.

>       association existing between the local mobility anchor and the

[Sri] Ok. We can say:
"If IPsec is used for protecting the messages, the message MUST be protected
....". So, we mandate this only when the security mechanism is IPsec and
not when using other mechanisms such as 4285.

> network entry and even cause disruption.

[Sri] Will specify a new protocol variable for controlling this. The 
text is provided in the thread with Gerardo.

> the same HNP, and the 3rd one is using a different HNP.

[Sri] We allow inter technology handoffs. This is for handling that case.

> is to acquire HNP out-of band.

[Sri] The prefix needs to be authorized by the LMA and so tied it to
the signaling. MAG may learn the prefix out of band, but the LMA is
still required to authorize that prefix and setup the route. If LMA
does not accept, the MAG cant really project this prefix on the MN-AR
link.

> case it encounters a PMIP6 network. Can anyone use DNA now?

[Sri] I agree. Long discussions on this DNA stuff in the past.
We had to state this. This consideration is relevant only if
DNAv6 is enabled on the mobile.

> How does the MAG know that? State this is out-of scope (AAA, context

[Sri] Sure. Will add, "The specific details on how the mobile access
gateway learns about the handoff details is out side the scope of
this document."

> LMA. Note that there may be a mesh of LMAs and MAGs, 

[Sri] Implementations can certainly do that. We had quite a long
discussions on this timestamp thing in the ML. What is documented is
the consensus. 

> e-mail even if this is an out-of scope component?

[Sri] The MAG needs to be certain, the prefix is authorized for 
use. On receiving that error code, some text on how the MAG can
handle that error case. If two MAG's suggest the same prefix for
different MN's, in band or out of band, there is a issue that the
LMA needs to deal with, it cannot accept both the requests. It needs
to reject the request. So, either way, we do in-band or out of band
address allocation schemes, the MAG still needs to be certain the
prefix is truely allocated for that mobile node, if it request for
a specific prefix.

>       association existing between the local mobility anchor and the

[Sri] Ok

> Alternatively DHCP server may be on the MAG.

[Sri] Ok

> detect the problem, which effects the handover performance.

[Sri] The MAG sends the RA and that should update the mapping.
 
> maybe this is not something we need, but let's make sure to 

[Sri] The entire MN section is non-normative, that is specified. Some
general considerations. But, nothing is specified for the MN behaviour. 

> different types of interfaces in case they map to the same bits.

[Sri] Access Tech type is required. The Interface ID is a MUST
if available for the MAG. Clearly, the combination or just the
HNP is sufficient for the LMA to identify the binding.

> Is that "may" sufficient?

[Sri] Better, we dont apply too many constraints. This text was proposed
and discussed in the ML.

Thanks for your comments.

Regards
Sri