Subject: [netlmm] Review of Proxy Mobile IPv6 (draft-ietf-netlmm-proxymip6-05.txt)

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 21 Sep 2007 14:14:01 -0400

Technical Issues

4.2  Security Policy Database Entries

    mobile access gateway SPD-S:
        - IF local_address = mag_address_1 &
             remote_address = lma_address_1 &
             proto = MH & local_mh_type = BU & remote_mh_type = BA
          Then use SA ESP transport mode
          Initiate using IDi = mag_1 to address lma_1

Should that last line read "Initiate using IDi = mag_1 to address
lma_address_1"?

5.1  Extensions to Binding Cache Entry Data Structure

   o  A flag indicating whether or not this Binding Cache entry is
      created due to a proxy registration.  This flag is enabled for
      Binding Cache entries that are proxy registrations and is turned
      off for all other entries that are created due to the
      registrations directly sent by the mobile node.

This point seems to be related to the interaction of proxy MIP and
client MIP using the same home agent.  I think it would be best to
leave this sort of detail to a separate document describing such
interaction.  There are many issues that must be dealt with in that
case, such as how to put BUs in the right order.

   o  The identifier of the registered mobile node, MN-Identifier.  This
      identifier is obtained from the NAI Option [RFC-4283] present in
      the received Proxy Binding Update request.

Isn't it intended that the MN-Identfier can be something other than
NAI?  For example, an L2 address?

5.3.  Signaling Considerations

   o  The local mobility anchor MUST identify the mobile node from the
      identifier present in the NAI option [RFC-4283] of the Proxy
Here again the NAI is mandated.

Binding De-Registration:
...
   o  Upon accepting the request, the local mobility anchor MUST delete
      the mobile node's Binding Cache entry and remove the Routing state
      for the mobile node's home network prefix.
This bullet seems to contradict the first bulllet in this sub-section,
which states that the LMA must implement a hang timer.  Maybe just 
delete this bullet.

Constructing the Proxy Binding Acknowledgement Message:
...
   o  If the Status field is set to a value greater less than 128, i.e.
      if the binding request was rejected, 
Does this mean to say "a value different from 128"?

5.4.  Timestamp Option for Message Ordering

   and the node receiving the message checks
   that this timestamp is greater than all previously accepted
   timestamps.
Shouldn't there be a check that the timestamp is somewhere close
to the current time of day, to prevent a misconfigured MAG from
blocking all registrations for a period fo time,
by sending a message stamped sometime in the far future?
I think what is needed here is something like:
   and the node receiving the message checks
   that this timestamp is within some delta of the current time of day
   and is greater than all previously accepted timestamps.

I also share the concerns raised by Kilian Weniger in his e-mail
to the list today.  I hope you can address these as well.

5.5.2.  Forwarding Considerations

   o  When the local mobility anchor is serving a mobile node, it MUST
      be able to receive packets that are sent to the mobile node's home
      network.  In order for it to receive those packets, it MUST
      advertise a connected route in to the Routing Infrastructure for
      the mobile node's home network prefix or for an aggregated prefix
      with a larger scope.  This essentially enables IPv6 routers in
      that network to detect the local mobility anchor as the last-hop
      router for that prefix.
This is a change from the behavior in RFC 3775 that allowed for
proxy ND.  Will this create issues when co-locating an LMA with an HA?

6.10.2.  Tunneling & Encapsulation Modes

Should GRE be mentioned here?

11.  Security Considerations

   To eliminate the threats on the interface between the mobile access
   gateway and the mobile node, this specification requires an
   established trust between the mobile access gateway and the mobile
   node and to authenticate and authorize the mobile node before it is
   allowed to access the network.
I think you should talk here not only about trust but also about
a secure binding between the MN-Identifier and the traffic arriving
at the MAG.  This means that whatever scheme is used to authenticate
the MN must provide keys that will be used to protect traffic, indexed
by the MAC Address or MN-Identifier as appropriate.

Editorial Issues

Abstract: 

   in the case of network-based mobility management
   protocol 
Should be:
   in the case of a network-based mobility management
   protocol 

1.  Introduction

   IP mobility for nodes which have mobile IP client
   functionality in the IPv6 stack as well as those hosts which do not,
   would be supported by enabling Proxy Mobile IPv6 protocol
   functionality in the network. 
Get rid of the comma in the above sentence.

2.2  Terminology 

      management of a mobile node is handled using Proxy Mobile IPv6
protocol
Should be:
      management of a mobile node is handled using the Proxy Mobile IPv6
protocol

   Through out this document,
Should be:
   Throughout this document,

3.  Proxy Mobile IPv6 Protocol Overview

   The core functional entities in the NETLMM infrastructure are the
   Local Mobility Anchor and the Mobile Access Gateway.  The local
   mobility is responsible for maintaining the mobile node's
   reachability state and is the topological anchor point for the mobile
   node's home network prefix.  While the mobile access gateway is the
   entity that performs the mobility management on behalf of a mobile
   node and it resides on the access link where the mobile node is
   anchored.  The mobile access gateway is responsible for detecting the
   mobile node's movements on its access link and for sending binding
   registrations to the mobile node's local mobility anchor.
Should be:
   The core functional entities in the NETLMM infrastructure are the
   Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG).  The
LMA
   is responsible for maintaining the mobile node's
   reachability state and is the topological anchor point for the mobile
   node's home network prefix.  The MAG is the
   entity that performs the mobility management on behalf of a mobile
   node and it resides on the access link where the mobile node is
   anchored.  The MAG is responsible for detecting the
   mobile node's movements on its access link and for sending binding
   registrations to the mobile node's LMA.  The architecture of
   a Proxy Mobile IPv6 domain is shown in Figure 1.

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

   valid address from its home network prefix, at the current point of
Should be:
   valid address from its home network prefix at the current point of

   by any corresponding node to the mobile node.
Should be:
   by any correspondent node to the mobile node.

   Any packet that the mobile node sends to any
   corresponding node will be received by the mobile access gateway and
Should be:
   Any packet that the mobile node sends to any
   correspondent node will be received by the mobile access gateway and

   The local mobility anchor on the other end of the tunnel,
   after receiving the packet removes the outer header and routes the
   packet to the destination.
Should be:
   The local mobility anchor on the other end of the tunnel,
   after receiving the packet, removes the outer header and routes the
   packet to the destination.

   mobile access gateway on the new access link, will signal the local
Should be:
   mobile access gateway on the new access link will signal the local

   making it believe its still on
   the same link 
Should be:
   making it believe it's still on
   the same link 

4.  Proxy Mobile IPv6 Protocol Security

   The signaling messages, Proxy Binding Update and Proxy Binding
   Acknowledgement, exchanged between the mobile access gateway and the
   local mobility anchor MUST be protected using end-to-end security
Should be:
   The signaling messages Proxy Binding Update and Proxy Binding
   Acknowledgement, exchanged between the mobile access gateway and the
   local mobility anchor, MUST be protected using end-to-end security

   Mobile IPv6 specification [RFC-3775] requires the home agent to
Should be:
   The Mobile IPv6 specification [RFC-3775] requires the home agent to

5.  Local Mobility Anchor Operation

   The section describes the operational details of the local mobility
   anchor.
Should be:
   This section describes the operational details of the local mobility
   anchor.

5.3.  Signaling Considerations

   the local mobility MUST consider this request as
   an initial binding registration request.
Should be:
   the local mobility anchor MUST consider this request as
   an initial binding registration request.

   However, the local mobile anchor MUST send the Proxy
Should be:
   However, the local mobility anchor MUST send the Proxy

   o  The Type 2 Routing header, MUST NOT be present in the IPv6 header
      of the packet.
Should be:
   o  The Type 2 Routing header MUST NOT be present in the IPv6 header
      of the packet.

5.4.  Timestamp Option for Message Ordering

   Hence, the sequence
   number scheme as specified in [RFC-3775], will be insufficient for
   Proxy Mobile IPv6.
Should be:
   Hence, the sequence
   number scheme, as specified in [RFC-3775], will be insufficient for
   Proxy Mobile IPv6.

   it may potentially
   process an older message sent by a mobile access gateway, where the
   mobile node was previously anchored, resulting in an incorrect
   Binding Cache entry.
Should be:
   it may potentially
   process an older message sent by the mobile access gateway where the
   mobile node was previously anchored, resulting in an incorrect
   Binding Cache entry.

   For solving this problem, this specification adopts two alternative
   solutions, one is based on timestamps and the other based on sequence
   numbers, as defined in [RFC-3775].
Should be:
   For solving this problem, this specification adopts two alternative
   solutions.  One is based on timestamps and the other based on
sequence
   numbers, as defined in [RFC-3775].

   o  All the mobility entities in a Proxy Mobile IPv6 domain,
      exchanging binding registration messages using Timestamp option
      must have adequately synchronized time-of-day clocks.
Should be:
   o  All the mobility entities in a Proxy Mobile IPv6 domain that are
      exchanging binding registration messages using the Timestamp
option
      must have adequately synchronized time-of-day clocks.

5.5.1.  Bi-Directional Tunnel Management

   will be updated after
   each periodic registrations for extending the lifetime.
Should be:
   will be updated after
   each periodic re-registration for extending the lifetime.

5.5.2.  Forwarding Considerations

   o  On receiving a packet from a corresponding node with the
Should be:
   o  On receiving a packet from a correspondent node with the

5.7.  Mobile Prefix Discovery Considerations

   In Proxy Mobile IPv6, the mobile node's home network prefix is hosted
   on the access link connected to the mobile access gateway. but it is
Should be:
   In Proxy Mobile IPv6, the mobile node's home network prefix is hosted
   on the access link connected to the mobile access gateway, but it is

   Since, there is
Should be:
   Since there is

5.8.  Route Optimizations Considerations

   The Route Optimization in Mobile IPv6, as defined in [RFC-3775],
   enables a mobile node to communicate with a corresponding node
Should be:
   The Route Optimization in Mobile IPv6, as defined in [RFC-3775],
   enables a mobile node to communicate with a correspondent node

6.  Mobile Access Gateway Operation

   The Proxy Mobile IPv6 protocol described in this document, introduces
   a new functional entity, the Mobile Access Gateway (MAG). 
Should be:
   The Proxy Mobile IPv6 protocol described in this document introduces
   a new functional entity, the Mobile Access Gateway (MAG).

   The specifics on how
   that is achieved or the signaling interactions between those
   functional entities is beyond the scope of this document.
Should be:
   The specifics on how
   that is achieved or the signaling interactions between those
   functional entities are beyond the scope of this document. 

6.2.  Mobile Node's Policy Profile

   A mobile node's policy profile contains the essential operational
   parameters that are required by the network entities for managing the
   mobile node's mobility service.  These policy profiles are stored in
   a local or a remote policy store, the mobile access gateway and the
   local mobility anchor MUST be able to obtain a mobile node's policy
   profile.
Should be:
   A mobile node's policy profile contains the essential operational
   parameters that are required by the network entities for managing the
   mobile node's mobility service.  These policy profiles are stored in
   a local or a remote policy store.  The mobile access gateway and the
   local mobility anchor MUST be able to obtain a mobile node's policy
   profile.

6.4.  Supported Address Configuration Models

   The Router Advertisement
   messages sent on the access link, specify the address configuration
   methods permitted on that access link for that mobile node. 
Should be:
   The Router Advertisement
   messages sent on the access link specify the address configuration
   methods permitted on that access link for that mobile node. 

6.8.  Link-Local and Global Address Uniqueness

   A mobile node in the Proxy Mobile IPv6 domain, as it moves from one
   mobile access gateway to the other, it will continue to detect its
Should be:
   A mobile node in the Proxy Mobile IPv6 domain, as it moves from one
   mobile access gateway to the other, will continue to detect its

   Every time the mobile node attaches to a new link, the event related
   to the interface state change, will trigger the mobile node to
   perform DAD operation on the link-local and global addresses.
Should be:
   Every time the mobile node attaches to a new link, the event related
   to the interface state change will trigger the mobile node to
   perform DAD operation on the link-local and global addresses.

   However, this issues will not impact point-to-point links based on
   PPP session.
Should be:
   However, this issues will not impact point-to-point links based on
   a PPP session.

   and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered.
Should be:
   and the IPv6 Control Protocol, IPV6CP [RFC-2472] gets triggered.

   If the PPP session state is moved to the new mobile access gateway,
   as part of context transfer procedures that are in place, there will
Should be:
   If the PPP session state is moved to the new mobile access gateway
   as part of context transfer procedures that are in place, there will

   Since, there is a unique home network prefix for each mobile node,
Should be:
   Since there is a unique home network prefix for each mobile node,

6.9.1.  Binding Registrations

      management service needs to offered to the mobile node, it MUST
Should be:
      management service needs to be offered to the mobile node, it MUST

   o  The mobile access gateway MUST apply the considerations specified
      in Section 5.4, for processing the Sequence Number field and the
      Timestamp option, in the message.
Should be:
   o  The mobile access gateway MUST apply the considerations specified
      in Section 5.4 for processing the Sequence Number field and the
      Timestamp option, in the message.

      the mobile access gateway SHOULD try to register again only after
      it synchronized its clock to a common time source that is used by
Should be:
      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

      mobile access gateway MUST create Binding Update List entry for
Should be:
      mobile access gateway MUST create a Binding Update List entry for

   o  For extending the lifetime of a currently existing binding at the
      local mobility, the mobile access gateway MUST send a Proxy
Should be:
   o  For extending the lifetime of a currently existing binding at the
      local mobility anchor, the mobile access gateway MUST send a Proxy

   o  At any point, the mobile access gateway detects that the mobile
      node has moved away from its access link, it MUST send a Proxy
Should be:
   o  At any point, if the mobile access gateway detects that the mobile
      node has moved away from its access link, it MUST send a Proxy

Bottom of page 34 and top of page 35: the message format is split
across the two pages.  It is confusing and looks like there is a
dangling "Proxy Binding Update message format".  Please try to
keep the message on a single page.

6.10.1.  Transport Network

   The transport network between the local mobility anchor and the
   mobile access can be either an IPv6 or IPv4 network. 
Should be:
   The transport network between the local mobility anchor and the
   mobile access gateway can be either an IPv6 or IPv4 network. 

   negotiating IPv4 transport and the corresponding encapsulation mode,
   for supporting this protocol operation.
Should be:
   negotiating IPv4 transport and the corresponding encapsulation mode
   for supporting this protocol operation.

6.10.2.  Tunneling & Encapsulation Modes

   IPv6 datagrams to be encapsulated as a payload of another IPv6 packet
   and be routed between the local mobility anchor and the mobile access
Should be:
   IPv6 datagrams to be encapsulated as a payload of another IPv6 packet
   and to be routed between the local mobility anchor and the mobile
access

   Any
   packet that is routed over this interface, get encapsulated with the
Should be:
   Any
   packet that is routed over this interface gets encapsulated with the

6.10.4.  Local Routing

   If there is data traffic between a visiting mobile node and a
   corresponding node that is locally attached to an access link
Should be:
   If there is data traffic between a visiting mobile node and a
   correspondent node that is locally attached to an access link

   This decision of path optimization SHOULD be based on the configured
   policy configured on the mobile access gateway, but enforced by the
Should be:
   This decision of path optimization SHOULD be based on the
   policy configured on the mobile access gateway, but enforced by the

   The specific details on how
   this is achieved is beyond of the scope of this document.
Should be:
   The specific details on how
   this is achieved are beyond of the scope of this document.

6.10.5.  Tunnel Management

   All the considerations mentioned in Section 5.5.1, for the tunnel
   management on the local mobility anchor apply for the mobile access
   gateway as well.
Should be:
   All the considerations mentioned in Section 5.5.1 for the tunnel
   management on the local mobility anchor apply for the mobile access
   gateway as well.

6.10.6.  Forwarding Rules

   For reporting an error in such
      scenario, 
Should be:
   For reporting an error in such a
      scenario, 

   in the form of ICMP control message,
Should be:
   in the form of an ICMP control message,

   o  On receiving a packet from a corresponding node that is locally
      connected, to the mobile node that is on the access link, the
Should be:
   o  On receiving a packet from a correspondent node that is locally
      connected and which is destined to a mobile node that is on 
      another locally connected access link, the

6.12.  Home Network Prefix Renumbering

   However, the specific details on how the local mobility anchor
   notifies the mobile access gateway about the mobile node's home
   network prefix renumbering is outside the scope of this document.
Should be:
   However, the specific details on how the local mobility anchor
   notifies the mobile access gateway about the mobile node's home
   network prefix renumbering are outside the scope of this document.

6.14.  Allowing network access to other IPv6 nodes

   This essentially ensures, the mobile access gateway
Should be:
   This essentially ensures that the mobile access gateway

9.  Protocol Configuration Variables

      allowed to enable local routing of the traffic exchanged between a
      visiting mobile node and a corresponding node that is locally
Should be:
      allowed to enable local routing of the traffic exchanged between a
      visiting mobile node and a correspondent node that is locally

11.  Security Considerations

   to hijack a mobile node's session or may do a denial-of-service
   attacks. 
Should be:
   to hijack a mobile node's session or may carry out a
denial-of-service
   attack. 

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 01:03:15 -0700

Hi Pete,

Thanks for the review. I've updated the draft based on your
inputs. Please see inline.

> -----Original Message-----
> From: McCann Peter-A001034 [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 11:14 AM
> To: [email-masked]
> Subject: [netlmm] Review of Proxy Mobile 
> IPv6(draft-ietf-netlmm-proxymip6-05.txt)
> 
> Technical Issues
> 
>         - IF local_address = mag_addreFrom [email-masked] Mon Sep 24 04:03:38 2007
From: "Sri Gundavelli" <[email-masked]>
To: "'McCann Peter-A001034'" <[email-masked]>, <[email-masked]>
Subject: RE: [netlmm] Review of Proxy Mobile
	IPv6(draft-ietf-netlmm-proxymip6-05.txt)
Date: Mon, 24 Sep 2007 01:03:15 -0700
Cc: 

Hi Pete,

Thanks for the review. I've updated the draft based on your
inputs. Please see inline.

> -----Original Message-----
> From: McCann Peter-A001034 [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 11:14 AM
> To: [email-masked]
> Subject: [netlmm] Review of Proxy Mobile 
> IPv6(draft-ietf-netlmm-proxymip6-05.txt)
> 
> Technical Issues
> 

Ok.
 
> case, such as how to put BUs in the right order.

We are only marking that this is a PMIP BCE, with out discussing
the details of CMIP and PMIP integration. Since, we are extending
the 3775 BCE structure that is defined for CMIP, we have added
extra fields that are relevant to PMIP6 and also flagged the BCE
entry. 

> NAI?  For example, an L2 address?

The identifier is exchanged using the NAI Option (4282). The identifier
that is allowed in 4283 is based on the 4282 definition. We are bound
to that definition. 

In a proxy model, when a third entity is sending binding request,
the identifier of the MN needs to be present and that is the only
stable field. The HNP is allocated dynamically.

> which states that the LMA must implement a hang timer.  Maybe just 

Ok. Will fix it.

> Does this mean to say "a value different from 128"?

Typo. Fixed it.

> to the list today.  I hope you can address these as well.

I will take care of this.

>       the mobile node's home network prefix or for an 
>ss_1 &

Ok.
 
> case, such as how to put BUs in the right order.

We are only marking that this is a PMIP BCE, with out discussing
the details of CMIP and PMIP integration. Since, we are extending
the 3775 BCE structure that is defined for CMIP, we have added
extra fields that are relevant to PMIP6 and also flagged the BCE
entry. 

> NAI?  For example, an L2 address?

The identifier is exchanged using the NAI Option (4282). The identifier
that is allowed in 4283 is based on the 4282 definition. We are bound
to that definition. 

In a proxy model, when a third entity is sending binding request,
the identifier of the MN needs to be present and that is the only
stable field. The HNP is allocated dynamically.

> which states that the LMA must implement a hang timer.  Maybe just 

Ok. Will fix it.

> Does this mean to say "a value different from 128"?

Typo. Fixed it.

> to the list today.  I hope you can address these as well.

I will take care of this.

> proxy ND.  Will this create issues when co-locating an LMA with an HA?

No, its just stating that the LMA should be able to receive traffic that
is sent to the mobile node's home network. Also, 3775 does not prevent
the configuration MN's home network on a virtual interface and there is
no Proxy ND there. Proxy ND is required if the HA has to defend the 
address on a physical interface.

> Should GRE be mentioned here?

Thought about this. But, I've a draft on GRE for PMIP6 and I dont
want to show any references to that from this draft. 

> by the MAC Address or MN-Identifier as appropriate.

I have addes some text around this. 

> Editorial Issues

I've fixed all the below editorial issues. Thanks a lot for pointing them
to me.

Regards
Sri

>    an access n aggregated prefix

No, its just stating that the LMA should be able to receive traffic that
is sent to the mobile node's home network. Also, 3775 does not prevent
the configuration MN's home network on a virtual interface and there is
no Proxy ND there. Proxy ND is required if the HA has to defend the 
address on a physical interface.

> Should GRE be mentioned here?

Thought about this. But, I've a draft on GRE for PMIP6 and I dont
want to show any references to that from this draft. 

> by the MAC Address or MN-Identifier as appropriate.

I have addes some text around this. 

> Editorial Issues

I've fixed all the below editorial issues. Thanks a lot for pointing them
to me.

Regards
Sri

>    solutions, one is based on etwork, the mobile access gateway on that access network
>    A mobile node in the Proxy Mobile IPv6 domain, as it timestamps and the other based 
> on sequence
> Shouldmoves from one
> configured

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Sep 2007 17:20:58 -0700

Hi Pete,

> case, such as how to put BUs in the right order.

The 'P' flag is essential since we are re-using much of the Mobile IPv6 
home agent functionality for the description of the LMA functionality. 
The LMA needs to be able to distinguish that it is a proxy binding 
update. And the 'P' flag is the only way to do this.

> proxy ND.  Will this create issues when co-locating an LMA with an HA?

In RFC 3963 (NEMO) we already extended the home agent functionality to 
advertise reachability to a aggregated network prefix in addition to the 
  home address of the mobile router. This would be similar to that 
functionality. I don't see any issues when co-locating an LMA with a HA.

> by the MAC Address or MN-Identifier as appropriate.

This should be link-specific. More ever it would be better to capture 
this in the MN-AR interface document.

Vijay