One document matched: draft-arkko-mext-rfc3775-altcoa-check-00.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="full3978" docName="draft-arkko-mext-rfc3775-altcoa-check-00" category="std" updates="3775">
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<front>

<title abbrev="Alt-CoA Check">Verifying Correctness of Alternate Care-of Address Option</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

<date month="February" year="2008" />

<keyword>Mobile IPv6</keyword>

<abstract>

<t>This document revises the RFC 3775 rules on how Alternate Care-of
Address option is processed.  Alternate Care-of Address option is used
to carry the current care-of address inside a Mobility Header message.
This is used in addition to the source address in the packet in order
to ensure that the care-of address is protected by IPsec ESP, the
security mechanism that protects Mobility Header messages. Unfortunately,
RFC 3775 did not require verification that the source address and care-of
address are the same. This document adds that requirement.
</t>

</abstract>

</front>
<middle>

<section anchor="intro" title="Introduction">

<t>This document revises the RFC 3775 rules on how Alternate Care-of
Address option is processed <xref target="RFC3775"/> by home agents
and correspondent nodes.  Alternate Care-of Address option is used to
carry the current care-of address inside a Mobility Header message.
This is used in addition to the source address in the packet in order
to ensure that the care-of address is protected by IPsec ESP. IPsec
ESP is the security mechanism that protects Mobility Header messages
for the signaling between the mobile node and home agent <xref
target="RFC3776"/>.</t>

<t>Unfortunately, RFC 3775 did not require verification that the
source address and care-of address are the same. This document adds
that requirement. The rationale for this is to ensure that a mobile
node does not spoof its care-of address and cause a flooding attack to
a victim residing in the given care-of address <xref
target="RFC4225"/>. In Mobile IPv6, the home agent trusts the mobile
node to not lie about its care-of address, because they have a
security association and the administrator of the home agent could
disconnect the service to a misbehaving mobile node. This is in
contrast to route optimization that is performed with any node in the
Internet. There it is required that the correspondent node actually
verifies the validity of the claimed care-of address with a return
routability test. However, these two cases represent extremes. In the
former case, absolutely no checking is done. In the latter case an
explicit test is done.  Neither case relies on the correctness of the
source address. This assumption is valid because, in general, we cannot
assume that ingress filtering in the Internet is always done.</t>

<t>But the downside is that the specification does not benefit from
possible ingress filtering that may be applied in some networks. For
instance, the aviation community is planning to employ Mobile IPv6 in
some of its safety critical networks that are not reachable from the
global Internet. These networks will apply ingress filtering, and it
would be useful to be able to benefit from this within such a network.
Currently, this is not possible as there is no requirement that
Alternate Care-of Address option contains a valid source address. As a
result, this document adds this requirement.</t>

<t>At the same time, this change deprecates the ability of the mobile
node to provide a different care-of address to the home agent than it
is using as a source address. One potential use of this would be to
use a temporary source address <xref target="RFC4941"/> for privacy
reasons.  However, given the existence of an IPsec SPI, sequence
number, and potential link layer identifiers, it is unlikely that this
approach will be able provide actual protection for privacy.</t>

<t>Another potential use of a different care-of address relates to
handovers and being able to instruct the home agent to send traffic to
a new care-of address before actually being on the link. However, this
is something that cannot be done unless the mobile node either
actually attaches to the link or uses mechanisms capable of creating a
presence on the other link before attaching to it, such as FMIP <xref
target="RFC4068"/>. In the former case it becomes possible to send a
Binding Update from the right link. In the latter case, FMIP is
capable of tunneling packets sent to the old link to the new location,
so the Mobile IPv6 handover does not have to be done under so strict
timeliness requirements. Note that FMIP itself employs a mandatory
Alternate Care-of Address option, using an address that is not
topologically correct. Current specification does not say anything
about how this address is verified. However, as FMIP routers are aware of
the assignment of addresses on the other router, it seems in theory
possible to construct such an FMIP-specific test.</t>

<t>Finally, at the time of writing this, extensions are being written
to Mobile IPv6 to allow the registration of multiple care-of
addresses. The specific mechanisms that these extensions use for
ensuring the correctness of care-of address is still being
discussed. However, it is assumed that the same principles can apply
there as well: the active care-of address is the one that should also
appear in the source address, and when a switch to another care-of
address is being made some verification of the address happens as a
part of the path testing, policy update, or other processes.</t>

<t>As a result, the author believes that benefits of adding this check
outweight the potential benefits of being able to use a different
source address.</t>

</section>

<section anchor="reqs" title='Requirements language'>

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

</section>

<section anchor="newrules" title="Processing Alternate Care-of Address Option">

<t>When an Alternate Care-of Address option is present in a Binding
Update message, perform the following additional test:</t>

<t>If the address in the Alternate Care-of
Address option is not the same as either the home address or
the Source Address field in the IPv6 header of the Binding
Update packet, then by default the receiving node MUST send back a
Binding Acknowledgement with status code TBD-BY-IANA (mismatching
source address).  The Binding Cache entry targeted by the Binding
Update, if any, MUST NOT be changed.</t>

<t>This check is performed by default. Explicit configuration from the
network administrator can turn this behaviour off.</t>

<t>This check affects the processing of Binding Updates as specified
in RFC 3775 Section 9.5.1, and applies both to correspondent nodes and
home agents.</t>

</section>

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

<t>This document is about a change in the security policy related to
the processing of an option in the Mobile IPv6 protocol. The security
implications are discussed in <xref target="intro"/>.</t>

<t>While the additional check can be useful in networks that employ
Mobile IPv6 and ingress filtering, there is no assumption that ingress
filtering is always applied, applied correctly, or that security of
Mobile IPv6 is somehow based on a correctly operating ingress filterin
underneath. Indeed, ingress filtering is frequently not enabled or
enabled to perform only partial checks. For these reasons -- as
documented in RFC 3775 <xref target="RFC3775"/> -- Mobile IPv6
requires strong authentication of the mobile node to its home agent,
and that the home agent can trust mobile nodes or at least that the
administrators can disconnect a misbehaving mobile node.</t>

</section>

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

<t>A new Status Code in the Mobile IPv6 Parameters registry needs to
be allocated to "mismatching source address" (<xref
target="newrules"/>).</t>

</section>

</middle>
<back>

<references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.3775.xml"?>
      <?rfc include="reference.RFC.3963.xml"?>
</references>

<references title="Normative References">
      <?rfc include="reference.RFC.3776.xml"?>
      <?rfc include="reference.RFC.4068.xml"?>
      <?rfc include="reference.RFC.4225.xml"?>
      <?rfc include="reference.RFC.4941.xml"?>
</references>

<section anchor="changes" title="Changes from RFC 3775">

<t>RFC 3775 has been changed with regards to the Alternate Care-of
Address option process rules, outlined in <xref
target="newrules"/>. Note that this also affects indirectly network
mobility as specified in <xref target="RFC3963"/>.</t>

</section>

<section anchor="ack" title="Acknowledgements">

<t>The author would like to thank the February 2008 MEXT WG interim
meeting participants, in particular Ryuji Wakikawa, Jean-Michel
Combes, Julien Laganier, and Marcelo Bagnulo Braun for bringing this
issue into attention.</t>

</section>

</back>
</rfc>