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

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 Jan 2007 14:34:56 -0800 (PST)

Hello Christian,
  I am glad you have been contacted, it was my idea but I forgot to patent it :)

So you are clearing both drafts from the netlmm threats document?

Regards,

--behcet

----- Original Message ----
From: Christian Vogt <[email-masked]>
To: [email-masked]; [email-masked]; Vijay Devarapalli <[email-masked]>; [email-masked]; Netlmm <[email-masked]>
Cc: James Kempf <[email-masked]>; [email-masked]; Phil Roberts <[email-masked]>
Sent: Tuesday, January 23, 2007 3:23:03 PM
Subject: [netlmm] Review of draft-sgundave-mip6-proxymip6-01

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

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

---

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

Hi Behcet,

thanks for the recommendation!

At this stage, I'd say that draft-sgundave-mip6-proxymip6-01
presents a viable solution with respect to NETLMM threats.  The same
holds for the interface between the PMIP client and the LMA in
draft-singh-netlmm-protocol-00, but here one needs to attend to the
security on the interface between the access router and the PMIP
client IMO, as explained in my previous email.

Note that the interface between the mobile node and the access router,
and hence the security related to this, is out of scope of either of
the two proposals.

Regards,
- Christian