Subject: [netlmm] Review of draft-sgundave-mip6-proxymip6-01

From: Christian Vogt <[email-masked]>
Date: Tue, 23 Jan 2007 22:23:03 +0100

Hi authors and NETLMM folks,

Vidya and Phil asked me for a review of the two Proxy Mobile
IPv6 proposals that are currently being discussed in the
NETLMM working group.  Here is one for draft-sgundave-mip6-
proxymip6-01.  (I will send a the review for draft-singh-
netlmm-protocol-00 in a separate email.)

The proposal in draft-sgundave-mip6-proxymip6-01 defines an
extension to RFC 3775 for localized mobility management (MM)
support.  It enables the home agent to serve as both an RFC
3775 home agent and a PMIPv6 home agent at the same time.  A
new network entity, the Proxy Mobile Agent (PMA), registers
a mobile node's current point of attachment with the home
agent on behalf of the mobile node.  The PMA gives the
mobile node the illusion of being on its home link while
actually being away from home.  The draft adapts major RFC
3775 concepts to also support localized MM, including home
agent operation, binding cache entry components,
bidirectional-tunnel management, message ordering, DHAAD,
and MPD.  RFC 3775 terminology is reused in the context of
localized MM.

While the draft does a good job in addressing the changes
required to RFC 3775 concepts when adopted to localized MM,
the close integration of localized and global MM necessarily
has two conceptual disadvantages:

    - The security and trust relationships in PMIPv6 are
    inherently different from those in RFC 3775.  RFC 3775
    calls for the home agent to authenticate the mobile node
    during the binding update procedure and to authorize the
    mobile node for using its particular home address.  In
    PMIPv6, both of these tasks are the responsiblity of the
    PMA, and the home agent trusts the proxy mobile agent.
    From this perspective, it seems to be cleaner to separate
    localized and global MM.

    - Combining global and localized MM requires expensive
    security associations between the home agent and each
    access router in the localized MM domain if the home
    agent is from a different administrative domain than the
    domain that the mobile node currently visits.  IMO global
    and localized MM are orthogonal, and global MM should
    remain mobile-initiated.  The mobile node could then
    perform a binding update with its home agent in domain A
    while roaming within a PMIPv6 domain B.

    Decoupling global and localized MM requires different
    home addresses, home links, and home agents for PMIPv6
    and RFC 3775 because the mobile node would otherwise
    think it is on its (global) home link and it would never
    inititate any global mobility signaling.  The "local"
    (PMIPv6) home address would then rather be used as a
    care-of address in the binding with the "global" (RFC
    3775) home address.

    In this context, it should be noted that a PMIPv6 home
    agent must not drop return routability signaling as
    currently stipulated in section 5.7 of the draft.

It is important to note that the above concerns are likely
to be an editorial matter only rather than a technical
shortfall.  E.g., it might already help to give the PMIPv6-
specific home agent a different name, say, "local home
agent".  This would decouple localized MM from global MM,
while keeping the concept of the protocol described in the
draft.  It would also make it easier for the reader to
understand that localized and global MM are in fact
orthogonal and take place on different levels.

There are also some technical issues involved when global and 
localized MM are combined.  Here are three that I came across:

    - The draft says that timestamps rather than sequence
    numbers should be used to order the MH messages exchanged
    between a PMA and a home agent.  If the PMIPv6 home agent
    is combined with an RFC 3775 home agent, this home agent
    may receive MH messages from both a mobile node and from
    a PMA proxying that mobile node.  The mobile node's
    messages would have sequence numbers, while the PMAs'
    would include timestamps.  This complicates the matter of
    ordering messages when the home agent supports both
    global and localized MM.  (In practice, this problem may
    not be dramatic as it should only occur when the mobile
    node enters or leaves a PMIPv6 domain from or to a
    visited link.  The home agent would then likely get a
    deregistration from the mobile node and a registration
    from the PMA, or vice versa, respectively.)

    - When the mobile node moves to its real physical home
    link (i.e., the one where the home agent is located)
    after roaming through a PMIPv6 domain, there might be
    some interference with the home agent intercepting the
    mobile node's packets and performing proxy Neighbor
    Discovery for the mobile node.  According to standard
    Mobile IPv6, the mobile node would send a Binding Update
    message to the home agent for deregistration as well as
    an unsolicited Neighbor Advertisement message to update
    the neighbor caches of other nodes on the (physical) home
    link.  However, if the mobile node comes from a different
    link within the PMIPv6 domain, it thinks that it has been
    on the home link all along.  So it neither deregisters
    with the home agent nor does it send an unsolicited
    Neighbor Advertisement message.

    Lack of the deregistration Binding Update message is not
    necessarily an issue because the home agent could rely on
    the deregistration of the mobile node's previous PMA.
    The absence of the unsolicited Neighbor Advertisement
    message, however, may cause some neighboring nodes that
    communicate with the mobile node to continue sending
    their packets to the home agent's link layer address.
    This seems to be an issue especially when localized and
    global mobility managment are combined as they are in the
    current version of the draft.  Using the per-mobile-node
    prefix model avoids the issue.

    - One would need to think about network renumbering on
    the (physical) home link.  How would any changes in the
    home link prefix be communicated to the mobile node's
    serving PMA, to the mobile node, and to the profile
    database?

Again, I think that none of the above-mentioned issues is a
blocker for this protocol proposal.  Most of them rather
concern the way the idea is presented rather than any
technical difficulties.

Regarding security, the interesting part of the PMIPv6
protocol is specific to the access technology and as such
unspecified by the draft.  Data origin authentication and
integrity protection on the interface between the PMA and
the home agent is provided through IPsec, and this should do
away with most threats.  One issue that remains is, of
course, that an attacker from the Internet may send bogus
packets to the PMIPv6 domain and, provided the IP
destination addresses of the packets match one in the home
agent's binding cache, cause increased workload at the home
agent and the involved PMAs for encapsulating and
decapsulating these packets, respectively.  At the same
time, the load on the paths from the home agent to the PMAs
increases.  The flooding comes with some amplification due
to the additional header that the home agent adds.  In any
case, the home agent won't forward any flooding packets if
the IP destination address is not found in the binding
cache.

Note that the threat of flooding is not specific to the
proposal in draft-sgundave-mip6-proxymip6-01; a similar
threat even exists in standard Mobile IPv6.

Best regards,
- Christian

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

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

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 23 Jan 2007 17:00:01 -0800 (PST)

Hi Christian,

Thanks for the review and all the comments. Please see
our response below:

1. Global/Local mobility and the terminology

It is our view that local mobility and global mobility
can be implmented in many ways and we did not want to
tie this specification to a specific deployment model.
It is possible the home address of a mobile in the PMIP
domain, can be a home address or a care-of address in
the global mobility sense, it is upto the proposed
architecture that is based on this specification. However,
we are willing to change the terminology to remove *any*
ambiguous terms. As suggested by some in this mailing
list, terminology with a proxy prefix is probably ok for
us and for certain terms. Ex: PCOA - Proxy Care-Of Address.

It is possible, a home agent can be acting as a home
agent for that local proxy domain and may still be acting
as a global home agent for some other nodes. There are
clear sementics in the state at the home agent, Ex: fields
in the BCE, protocol messaging between the home agent and
the proxy mobile agent, that enables the entities to clearly
have a seperation on how the local mobility or global mobility
is offered or how the respective messages are authenticated
or authorised.

2. Time stamps and Sequence Numbers

As we explained in the draft, sequence numbers are suited
for two end points to establish messaging order, when
multiple end points are involved, we need a different
global scale and the time stamp is possibly suits the
model better.

There is one race condition as you have pointed out and
we are aware of this. However, the occurance of that
situation is indeed a special case, where the mobile keeps
oscillating between PMIP and CMIP domains or links and
the home agent keeps receiving BU's and PBU's in out of
order. This one scenario, we can certainly document and
provide guidance to the operator.

3. Going Home

As discussed in one of the threads with Genadi,

We recommend the configuration of PMIP nodes to be on a
virtual link. It is a very common practise and all most
all operators configure the mobile's on a virtual link.
Out of the two models, in the per-MN-prefix model, there
is no physical home link. The prefix follows the mobile
and is hosted on the MN-AR link and thus there is proxy
ND operation required on the home link. Now, in the
shared link model, we recommend the configuration of the
mobile's to be on a virtual link. This will remove any
proxy ND operation issues.

4. Network Renumbering

Can be certainly done. We did have the text on this and
later removed it, as we did not see the use for it for
the target PMIP deployments. However, its just about
the home agent sending the MPA message to the proxy and
proxy enforcing the change by the means of RA.

-
When this message is sent by a home agent to a proxy mobile agent, it
MUST NOT include the Type 2 Routing header containing the mobile's
home address.  The final consumer of this message is the proxy mobile
agent and thus Routing header should not be present.

The ICMP Mobile Prefix Solicitation message, described in Section 6.7
and Section 11.4.2 of [RFC-3775], allows a mobile node to trigger the
home agent to obtain the latest home prefix information.
When this message is sent by a Proxy Mobile Agent, the home address
option MUST be present as an option to the Mobile Prefix Solicitation
message.  The home address option MUST NOT be present in the
Destination Options header.
-

5. Return Routability messages

We can certainly ommit the line on mandating the dropping of RO
messages. But, in the absence of context transfer procedures,
it is not possible for the new PMA to move the established
binding management key between the PMA and the CN. But, we can
relax the text on this.

6. Our comments:

Also, there are other things in the draft that are worth
mentioning, as such, lot of efforts went into those details.
The draft's coverage of the following and the presentation
of the details on:

- Addressing mechanisms of the mobile
- Interface with the DHCP relay agent and PMA
- IPSec Guidance, PAD, SPD and other details
- Mobile Node perspective view
- IPv4 Addressing
- Tunnel Management
- Conceptual Data Structures and other details

Again, Appreciate your time and review. Thanks !!!!

Regards
Sri

On Tue, 23 Jan 2007, Christian Vogt wrote:

> There are also some technical issues involved when global and localized MM 
> are combined.  Here are three that I came across:
>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 24 Jan 2007 23:25:54 +0100

Hi Sri,

I agree with you that the protocol you are proposing can actually be
used in a way in which global and localized MM are decoupled.  Global
MM can then be supported through RFC 3775 Mobile IPv6.  I recognized
this when reading the draft, and maybe I did not state this clear enough 
in my review.

However, I think that reusing RFC 3775 terminology for PMIP purposes
can make some readers believe that PMIP is just an extension to RFC
3775 and can't be used separately.  The reuse somehow conceals the
orthogonality between global MM and localized MM, which this draft
actually supports.  I hence agree with those in the working group who
think the terminology in this draft should be separate from RFC 3775
terminology.

Certainly, the ability to integrate global and localized MM---in which
case the local home address equals the global home address---is an
interesting feature of this protocol proposal.  And I agree that this
ability should be described by, say, a separate section in the draft. 
But given goal #9 of the NETLMM Requirements document, which calls for 
maximum reuse of existing IETF protocols, my suggestion is to default to 
separate global and localized MM---in which case the local home address 
equals the global care-of address---, and to emphasize this by using 
terminology which is separate from that in RFC 3775.

Referring to your comments on return routability signaling:

> messages. But, in the absence of context transfer procedures, it is
>  not possible for the new PMA to move the established binding 
> management key between the PMA and the CN. But, we can relax the 
> text on this.

I was thinking about the mobile node itself doing RR signaling for 
global MM according to RFC 3775.  If the mobile node considers its local 
home address a global care-of address, it might wish to do global route
optimization with a correspondent node.  In this case, the HoTI/HoT
and CoTI/CoT exchanges would both go via the local (PMIP) home agent.
  So the local home agent must not drop these messages.

Finally, I agree with your comments on the use of timestamps vs.
sequence numbers and on the network renumbering mechanism.

Kind regards
- Christian

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 24 Jan 2007 17:38:04 -0600

Hi Christian,

Just one minor comment:

On 1/24/07 4:25 PM, "ext Christian Vogt" <[email-masked]> wrote:

> 3775 and can't be used separately.

Why would you not consider PMIP as being an extension of MIP6 (RFC3775) with
the caveat that PMIP is a special case for host mobility wherein the host is
not involved in the mobility management?
Additionally, my understanding is that the intent is to use the same HA and
signaling as specified in 3775. So IMO the extensions being proposed for
PMIP are incremental and based on 3775. So reusing the terminology makes
sense except for the new things that are introduced with PMIP.

-Raj

> The reuse somehow conceals the

---

From: Christian Vogt <[email-masked]>
Date: Thu, 25 Jan 2007 09:35:26 +0100

Hi Raj,

it's not a technical reason that makes me believe separate terminology
would be better.  It's more the conceptual differences like the trust
between the HA and an entity in the visited network, or the move towards
a virtual home link.

Also, if you apply the use case where the MN runs RFC 3775 MIPv6 on top
of PMIPv6, you end up with some ambiguity if the terminology of RFC 3775
and that of PMIPv6 is the same.

Best,
- Christian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jan 2007 14:41:42 +0100

> sense except for the new things that are introduced with PMIP.

Raj, what is the opinion on the security comment on AR-HA relationship 
not being same as MN-HA relationship?

It's impossible to have PMIPv6 as an extension to RFC3775 and moreover 
consider RFC3775 as a particular case.

One needs to strip off lots of things from RFC3775 (security, proxy ND, 
home link, MPD and DHAAD, RO) before starting a PMIPv6 solution.

Alex