<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [

<!--
    <!ENTITY rfc2119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
-->
    <!ENTITY rfc5213 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
    <!ENTITY rfc3775 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
    <!ENTITY I-D.chan-distributed-mobility-ps PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chan-distributed-mobility-ps.xml'>
    <!ENTITY rfc4877 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
    <!ENTITY rfc3972 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml'>
    <!ENTITY I-D.draft-laganier-mext-cga-01 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-laganier-mext-cga-01.xml'>

]>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="info" docName="draft-bernardos-mext-dmm-cmip-00"
     ipr="trust200902">
  <front>
      <title abbrev="A DMM solution for CMIP">
       A IPv6 Distributed Client Mobility Management
       approach using existing mechanisms
      </title>

    <!-- AUTHORS -->
    <author fullname="Carlos J. Bernardos"
            initials="CJ."
            surname="Bernardos">
      <organization abbrev="UC3M">
        Universidad Carlos III de Madrid
      </organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
          <city>Leganes, Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>

    <author fullname="Antonio de la Oliva"
            initials="A."
            surname="de la Oliva">
      <organization abbrev="UC3M">
        Universidad Carlos III de Madrid
      </organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
          <city>Leganes, Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 8803</phone>
        <email>aoliva@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/aoliva/</uri>
      </address>
    </author>

    <author fullname="Fabio Giust"
            initials="F."
            surname="Giust">
      <organization abbrev="IMDEA Networks and UC3M">
        Institute IMDEA Networks and Universidad Carlos III de Madrid
      </organization>
      <address>
        <postal>
          <street>Av. del Mar Mediterraneo, 22</street>
          <city>Leganes, Madrid</city>
          <code>28918</code>
          <country>Spain</country>
        </postal>
        <email>fabio.giust@imdea.org</email>
      </address>
    </author>

    <date month="March" year="2011" />

    <area>Internet</area>

    <workgroup>MEXT Working Group</workgroup>

    <abstract>
      <t>
The use of centralized mobility management approaches -- such as
Mobile IPv6 -- poses some difficulties to operators of current and
future networks, due to the expected large number of mobile users and
their exigent demands. All this has triggered the need for distributed
mobility management alternatives, that alleviate operators' concerns
allowing for cheaper and more efficient network deployments.
      </t>

      <t>
This draft describes a possible way of achieving a distributed mobility
behavior with Client Mobile IP, based on Mobile IPv6 and the use of
Cryptographic Generated Addresses.
      </t>

    </abstract>

<!--    
    <note title="Requirements Language">

      <t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.
      </t> 

    </note>
-->

  </front>

  <middle>

    <section anchor="sec:introduction" title="Introduction">

      <t>
Most of the currently standardized IP mobility solutions, like
Mobile IPv6 <xref target="RFC3775" />, or Proxy Mobile IPv6
<xref target="RFC5213" /> rely to a certain extent on a
centralized mobility anchor entity. This centralized network node
is in charge of both the control of the network entities involved
in the mobility management (i.e., it is a central point for the
control signalling), and the user data forwarding (i.e., it is
also a central point for the user plane). This makes centralized
mobility solutions prone to several problems and limitations, as
identified in <xref target="I-D.chan-distributed-mobility-ps" />:
longer (sub-optimal) routing paths, scalability problems, signaling
overhead (and most likely a longer associated handover latency), more
complex network deployment, higher vulnerability due to the existence
of a potential single point of failure, and lack of granularity on the
mobility management service (i.e., mobility is offered on a per-node
basis, not being possible to define finer granularity policies, as for
example per-application).
      </t>

      <t>
There are basically two main approaches that are being researched now:
one aimed at making Mobile IPv6 work in a distributed way, and another
one doing the same exercise for Proxy Mobile IPv6. In this draft we
describe a solution to achieve a DMM behavior with a CMIP (MIPv6)
solution. This document is based on a research paper of the same
authors, called "Flat Access and Mobility Architecture: an IPv6
Distributed Client Mobility Management solution" <xref target="GOB+11" />.
      </t>

    </section>

    <section anchor="sec:terminology" title="Terminology">

<!--
      <t> 
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
      this document are to be interpreted as described in
      <xref target='RFC2119'>RFC2119</xref>.
      </t>
-->

      <t>The following terms used in this document are defined in the
      Mobile IPv6 specification <xref target="RFC3775" />:

        <list style="empty">
          <t>Home Agent (HA)</t>
          <t>Home Link</t>
          <t>Home Address (HoA)</t>
          <t>Care-of Address (CoA)</t>
          <t>Binding Update (BU)</t>
          <t>Binding Acknowledgement (BA)</t>
        </list>

      </t>

      <t>
      The following terms are defined and used in this document:

        <list style="hanging">

	  <t hangText="DAR (Distributed Anchor Router)."> First hop
          routers where the mobile nodes attach to. They also play the
          role of mobility managers for the IPv6 addresses they
          anchor.</t>

	  <t hangText="HDAR (Home Distributed Anchor Router)."> DAR
          which plays the role of Home Agent for a particular IPv6
          address (i.e., DAR where that IPv6 address is anchored).</t>

        </list>

      </t>

    </section>


    <section anchor="sec:description" title="Description of the solution">

      <t>
Distributed Mobility Management approaches try to overcome the
limitations of the traditional centralized mobility management, i.e.,
Mobile IP, by bringing the mobility anchor closer to the MN. Following
this idea, in our approach -- that we call Flat Access and Mobility
Architecture (FAMA) -- the MIPv6 centralized home agent is moved to the
edge of the network, being deployed in the default gateway of the
mobile node. That is, the first elements that provide IP connectivity
to a set of MNs are also the mobility managers for those MNs. In the
following we will call these access routers Distributed Anchor Routers
(DARs).
      </t>

      <t>
Every time a mobile node attaches to a distributed anchor router, it
gets an IPv6 address which is topologically anchored at the DAR. That
means that while attached to this DAR, the mobile can send and receive
traffic using that address without using any tunneling nor special
packet handling. Every time the mobile node moves to a different DAR,
it gets a new IPv6 address from the new access router. In case the MN
wants to keep the reachability of the IPv6 address(es) it obtained
from the previous DAR (note that this decision is dynamic and it is out
of scope of this document, it can be
done on an application basis for example), the mobile has to involve
its MIPv6 stack, by sending a Binding Update to the DAR where the
IPv6 address is anchored, using the address obtained from the current
DAR as care-of address. In this way, the IPv6 address that the node
wants to maintain plays the role of home address, and the DAR from
where that address was configured plays the role of Home Agent (for that
particular address). Note that the FAMA approach basically enables a
mobile node to simultaneously handle several IPv6 addresses -- each of
them anchored at a different DAR -- ensuring their continuous
reachability by using Mobile IPv6 in a distributed fashion (i.e., each
access router is a potential home agent for the address it delegates,
if required). This distributed address anchoring is enabled on demand
and on a per-address granularity, which means that depending on the
user needs, it might be the case that all, some or none of the IPv6
addresses that a mobile node configures while moving within a FAMA
domain, are kept reachable and used by the mobile.
      </t>

      <t>
In traditional Mobile IPv6, the communication between the MN and the
HA is secured through IPsec <xref target="RFC4877" />. Following a similar
approach in FAMA is difficult due to the large number of security
associations that would be required, since any gateway of the access
network can play the role of home agent for any mobile node. In order
to overcome this problem and provide authentication between the DAR
and the MNs, we propose the use of Cryptographically Generated
Addresses <xref target="RFC3972" /> (CGAs), as introduced in
<xref target="I-D.laganier-mext-cga" />. CGAs are a powerful mechanism
allowing authentication of the packets and requires no public-key
infrastructure, hence it is well-suited for this application.
      </t>

      <t>
Following the ideas presented above, every time an MN attaches to a
DAR, it configures a CGA from a prefix anchored at the DAR (e.g., by
using stateless address auto-configuration mechanisms). This address
can then be used by the MN to establish a communication with a remote
Correspondent Node (CN) while attached to that particular DAR. If the
mobile then moves to a new DAR (nDAR), the following two cases are
possible: i) there is no need for the address that was configured at
the previous DAR (pDAR) to survive the movement: in this case there
is no further action required; ii) the mobile wants to keep the
reachability of the address configured at pDAR: in this case Mobile
IPv6 is triggered, and the MN sends a Binding Update (BU) message to
the pDAR, using the address configured at the previous DAR as home
address, and the address configured at the new DAR as care-of
address. This BU includes the CGA parameters and signature
<xref target="I-D.laganier-mext-cga" />, which are
used by the receiving DAR to identify the MN as the legitimate owner
of the address. Although the use of CGAs does not impose a heavy
burden in terms of performance, depending on the number of MNs handled
at the DAR, the processing of the CGAs can be problematic. To reduce
the complexity of the proposed protocol, we suggest an alternative
mechanism to authenticate any subsequent signaling packets exchanged
between the MN and the DAR (in case the mobile performs a new
attachment to a different DAR). This alternative method relies on the
use of a Permanent Home Keygen Token (PHKT), which will be used to
generate the Authorization option that the MN has to include in all
next Binding Update messages. This token is forwarded to the MN in the
Binding Acknowledgment message, sent on reply to the BU. The procedure
is depicted in <xref target="fig:FAMA_sig" />. Once the signaling
procedure is completed, a bi-directional tunnel is established between
the mobile node and the DAR where the IPv6 address is anchored
(the "home" DAR -- HDAR -- for that particular address), so the mobile
can continue using the IPv6 address.
      </t>

       <figure anchor="fig:FAMA_sig" title="Signaling between the
        MN and the DAR">
        <artwork><![CDATA[
        ------                               -------
        | MN |                               | DAR |
        ------                               -------
          |                                     |
     CGA  |                                     |
   config |-- BU + CGA param + signature ------>|
          |                                     |  MN
    PHKT  |<----------------------- BA + PHKT --| auth
  caching |                                     |
          |                                     |
                     (first handoff)

   PHKT   |                                     |
  refresh,|                                     |
   next   |-- BU(PHKT auth) ------------------->|
 handoffs,|                                     |  MN
   de-reg |<------------------------------ BA --| auth
          |                                     |
          |                                     |
                  (subsequent signaling)
]]></artwork>
       </figure>

      <t>
In case the MN performs any subsequent movements and it requires to
maintain the reachability of an address for which it has already sent
a BU, the following BU messages can be secured using the PHKT
exchanged before, reducing the computational load at the receiving DAR.
      </t>

      <t>
Note that on every attachment of a node to a DAR, the terminal also
obtains a new IPv6 address which is topologically anchored at that
DAR, and that this address can be used for new communications
(avoiding in this way the tunneling required when using an address
anchored at a different DAR). A mobile can keep multiple IPv6
addresses active and reachable at a given time, and that requires to
send -- every time the MN moves -- a BU message to all the previous
DARs that are anchoring the IP flows that the MN wish to maintain.
      </t>

    </section>


    <section anchor="IANA" title="IANA Considerations">

      <t>
      TBD.
      </t>

    </section>

    <section anchor="Security" title="Security Considerations">

      <t>
Although the approach documented in this document is attractive for
the reduced signaling overhead caused by the mobility support, it
can be misused in some particular scenarios by malicious nodes that
wish to export an incorrect CoA in the BU message, since it does
provide proof of the MN's reachability at the visited network.
Indeed, the CGA approach assures that the BU message has been sent
by the legitimate HoA's owner but it does not make sure that same
MN to be reachable at the CoA indicated. This requires further
analysis.
      </t>

      <t>
A possible approach to provide a more secure solution is the
following: a Return Routability procedure similar to the one defined
in MIPv6 Route Optimization can be used to mitigate the
aforementioned security issue. The Return Routability procedure
starts after the handoff. Instead of sending the BU message, the MN
sends a Care-of Test Init message (CoTI). This message is replied
by the DAR with a Care-Of Test message containing a CoA Keygen
Token. The MN can now send a BU using both Home and CoA Keygen
tokens to proof its reachability at both the HoA and the CoA. The
message and the knowledge of both tokens is a proof that the MN is
the legitimate node who has sent the BU and also is reachable at the
CoA indicated. As all security improvements, the one proposed incurs
in a performance penalty, in this case an increase in the handover
delay. Specifically this enhanced security approach requires four
messages to be exchanged between the MN and the DAR instead of the
two messages of the original solution. In terms of handover delay,
it increases it by a factor of two, as the new solution requires to
two Round Trip Times (RTTs) to conclude, instead of one.
      </t>

    </section>


    <section anchor="Acknowledgments" title="Acknowledgments">

      <t>
The research leading to these results has received funding
from the European Community's Seventh Framework Programme
(FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL
project). The work of Carlos J. Bernardos has also been partially
supported by the Ministry of Science and Innovation of Spain under
the QUARTET project (TIN2009-13992-C02-01).
      </t>

    </section>

  </middle>

  <back>
    <references title="Normative References">
      <!--include="reference.RFC.2119"-->

      <!--&rfc2119;-->
      &rfc3775;
      &rfc5213;
      &rfc4877;
      &rfc3972;

    </references>

    <references title="Informative References">
      <!---->
      &I-D.chan-distributed-mobility-ps;
      &I-D.draft-laganier-mext-cga-01;

      <reference anchor="GOB+11">
        <front>
          <title>Flat Access and Mobility Architecture: an IPv6
           Distributed Client Mobility Management solution</title>
          <author initials="F." surname="Giust" fullname="Fabio Giust">
            <organization></organization>
          </author>
          <author initials="A." surname="de la Oliva" fullname="Antonio de la Oliva">
            <organization></organization>
          </author>
          <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardos">
            <organization></organization>
          </author>
          <date year="2011"/>
        </front>
        <seriesInfo name="3rd IEEE International Workshop on Mobility
         Management in the Networks of the Future World (MobiWorld 2011),
         colocated with IEEE INFOCOM 2011" value=""/>
      </reference>

    </references>

    <!---->
  </back>
</rfc>
