Mobile IPv6 Home Link Detection Mechanism Security considerationsEADS Innovation Works12, rue Pasteur - BP76Suresnes92152France+33 1 46 97 30 28arnaud.ebalard@eads.net
Internet
Mobile IPv6IPsecIKEHome Link DetectionNeighbor DiscoverySEND MIPv6 defines the concept of Home Network for a MN, in
opposition to the foreign network where this entity may find
itself. A ``Home Link Detection'' mechanism is also specified
to allow the MN to detect when it is at home. MIPv6 specification mandates the use of IPsec for protecting
main signaling traffic and also defines how IPsec can be used to
protect data traffic between the MN and its HA. Even if
optional, it is expected that many deployments of MIPv6 will
use it by default for MN which may roam outside a trusted
infrastructure (e.g. outside a mobile operator network). When a MN detects it is at home, it is expected to stop IPsec
protection for data traffic exchanged with its Home Agent. That
event is the result of the Home Return procedure, triggered by
the Home Link Detection mechanism.This document discusses the possible threats and security
impacts associated with the use of this insecure NDP-based
mechanism as a trigger to drop IPsec protection of data
traffic for the MN. It also provides some results on the
implementation of the attacks against an existing MIPv6
module. Possible solutions are suggested. 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 . MIPv6 entities (MN and HA) perform Neighbor Discovery
Protocol exchanges, for various needs:the HA: acting as a ND proxy for registered MN which
are currently in a foreign network, the HA defends the
MN's HoA on the MN's Home Link when it is away,
intercepts packets destined to the HoA and tunnels them
to the associated MN at its CoA. Its operations as a ND
Proxy for MN's HoA are basically subject to the same ND
threats as the ones existing for common neighbors of the
link. Those are not covered in the
document.
In practice, additional hypothesis can be made about the
Home Network; Being part of a controlled infrastructure,
those threats can be reduced, mitigated or
avoided.
As discussed in next item dedicated to the MN, those
hypothesis can usually not be made about the foreign
networks where the MN operates. the MN: upon movement, the MN performs link layer
interactions with the new foreign network it finds
itself in. By default, from a security standpoint, those
foreign networks must be considered as hostile
environments (i.e. with possible attackers). This
hypothesis may be relaxed in specific deployments where
the MN is expected to roam only between trusted networks
(e.g. mobile operator networks). We do not consider these
relaxed/specific hypothesis in the
document.
The interactions of the MN on foreign networks can be
summarized the following way: it sends RS messages in
order to get some RA from the router(s) of the link. The
RA gathered during the router discovery steps are used
by the MN to configure a CoA and most importantly to
detect if the current link is the home link or a foreign
link.
For that reason, the MN in this potentially hostile
environment is subject to ND protocol threats, already
described in .
But because the Home Link detection mechanism is based
on information gathered using NDP and may be the trigger
for some additional critical security steps, it may be a
vector for additional MIPv6 threats.
Specifically, this document focuses on the MIPv6-specific
link layer security issues associated with home link
detection (and Home Return procedure). It discusses the
possible security issues associated with current definition
of those mechanisms, lack of security considerations on
those mechanisms and inacurracies in reference documents. For the reasons introduced in , one
important hypothesis made in the document is that tunneled
traffic (data and possibly some specific signaling messages)
is protected using IPsec in tunnel mode, even if not
mandated by the reference documents. Some arguments justify
this decision: The Home Agent and the Mobile Node belong to a common
trust domain, and are already expected to support IPsec
and share common credentials for protecting signaling
with IPsec in transport mode. In that context,
supporting tunnel mode is expected to be inexpensive
from a deployment standpoint. The main remaining point
in this discussion is the possible performance cost of
handling IPsec protected data traffic in the home
network.
As specified in and
, ``Tunnel mode IPsec ESP MUST
be supported and SHOULD be used for the protection of
packets belonging to the return routability
procedure''.
Protection of IPsec payload traffic is documented for
both static and dynamic keying with IKEv1
and IKEv2
. Various implementations are
known to support it.
Except for specific devices which will operate on some
trusted operator or internal networks, Mobile Nodes are
expected to find themselves in untrusted/hostile foreign
networks. In that context, corporate deployments will
require the use of IPsec for tunneled data. Public
deployments will also probably follow that path.
In the end, as discussed later in this section, IPsec
tunneling and common (IPv6-in-IPv6) tunneling of data are
basically handled in the same way with regard to home
return.The rest of the document discusses the possible issues
associated with current Home Link Detection mechanism and
``Returning Home'' procedure as specified in the main MIPv6
reference documents (,
, ,
, and
).As described previously, this is done under the hypothesis
that IPsec is used to protect the traffic exchanged between
the Mobile Node and its Home Agent. To keep current section a reasonable size, the detailed analysis
of reference documents including normative excerpts of those
specifications is maintained in ,
at the end of the document. If you are interested by more
details on the topic, you should definitely read that
appendix.Here, we provide an overview of: The Home Link Detection mechanism performed by the MN The events associated with the ``Returning Home'' procedure
on both the MN and the HA.It is based on the detailed analysis available in the appendix. The MIPv6 specification provides a simple (one would say
primitive) Home Link detection mechanism for the MN: simply
put, when a Prefix Information Option found in a RA message
received by the MN includes its Home Subnet prefix, the MN
considers it is on its Home Link.The reaction of the MN to previous event (detection of home
network) is defined, but in a loose fashion: It is expected to send a deregistration BU: the content of
the BU is provided by (the set of
flags in MH header) but the specific format of the packet
is just suggested (no HAO and no AltCoA option). In
practice, the document does not prevent an implementation
to include an AltCoA option or a Destination Option Header
carrying a Home Address Option (HAO). precisely describes the steps
that should then occur at ND level, in order for the MN to
be able to use its HoA, which was previously defended by
the HA. We do not cover those steps here. expects the tunnel with the HA
to be torn down. also follows
that direction by expecting the IPsec tunnel with the HA
to be torn down. In practice, this is what existing
implementations do. The specific order in which things are expected to
happen is unclear, and more or less left as an
implementation decision despite its importance: the MN may
not wait for the BA to come back from the HA in order to
tear its IPsec tunnel down; just like it may not wait (for
obvious latency reasons) for a BA to come back to update
its IPsec tunnel SP/SA when performing a handover to
another foreign network. The security aspects of the Home Link Detection mechanism
and ``Returning Home'' procedure are not covered in any of
the MIPv6 reference documents. Those are basically not
considered as possible threat vectors. One possible reason
for that may be the fact that protection of data traffic
(authentication, privacy, ...) is not considered in the
documents (support and use of IPsec for that purpose is
optional). MIPv6 reference documents focus on the protection
of the infrastructure (address ownership considerations,
...) but not on security of user traffic. Here, we discuss the possible threats associated with the
loose expectations of reference documents and the reliance
on untrusted information to trigger changes in tunneling and
IPsec security policies.The only document which considers the topic is
,
which has an interesting Section 5 entitled ``Exploiting
Neighbor Discovery in a MIPv6 Environment''. That section
being quite short, it is provided (text is extracted from
current version, i.e. version 2) here for completeness and
commented below as an initial introduction to the possible
threats:As discussed in the draft and predicted by the summary
provided previously, it is expected to be quite easy for an
attacker on a foreign link to have a MN think that it is at
home and have it send a de-registration BU. For that
purpose, as noted in the draft, the attacker only needs to
acquire the Home Agent address, its Home Prefix and have the
ability to forge packets. The addresses are public
information available from the traffic of the MN.
The draft introduces the possibility that ingress filtering
implemented in the foreign network could lead to the BU
being dropped before hitting the HA.
In fact, for a common HAO-free deregistration BU packet
sent by a MN to its HA while believing it is at home, the
source address of the packet is the HoA. With that
hypothesis, the packet is both topologically invalid from
the foreign network's perspective (it should be dropped if
some filtering mechanism has been put in place by the ISP of
the foreign site or even the administrator of the site),
but it is also invalid from the destination site's
perspective (it should definitely be dropped at the MN's
network site boundaries). But those expectations do not
provide any real security guarantees.
The solution proposed in the draft for the attacker is to
relay its packets via another connection mean which does not
undergo ingress filtering. It is interesting to note that it
will still not work if the Home Network implements ingress
filtering too, and the attacker (and the MN) will never get
a Binding Ack in response. The only way for an attacker
would be to have a simultaneous access to the MN's foreign
network and to its home network.
Let's be wild and consider for a moment that an
implementation does not have restrictions (both from the MN
packet build perspective and the HA processing perspective)
on the expected format of the BU. This could be the case
because of code reuse. In that context, there are some
paths the attacker may explore. For instance, if the
attacker manages to get access to the ESP protected
deregistration BU sent by the MN in its expected common
format (while believing it is at home):
It could simply modify the packet in the following way to
add a destination option header with an HAO to make it look
that way:The packet is still perfectly valid at all
levels: The part protected by ESP has not been modified during
the addition so it should still be gracefully processed
by the HA IPsec stack. It is expected that the
processing of the HAO be performed before the IPsec
processing, hence replacing the attacker address
(Attacker_Address) by the HoA.Mobility Header checksum is computed based on MH
content (which has not been modified) and using the
usual L4 pseudo header which is also the same after the
changes: the final addresses are still the HoA and the
Home Agent address, the next header field is still
MH. The last element of the pseudo header, the length of
the upper layer is not bound to the modified payload
length field of the IPv6 header but to the unchanged
length field of the MH header.In the end, the mangled packet now has a more interesting
layout: it has a topologically valid source address which will
allow it to be routed to the HA. For previous reasons, it
should be processed successfully by the IPsec stack of the HA
and delivered to its MIPv6 module. Then, whether it will be
considered valid by the HA is a matter of implementation and
interpretation of the reference documents. Among the
remaining questions/points, we can list the following:
There is no AltCoA in the packet: in our example, there
is none. But, here again, reference documents are not
clear on the topic. AltCoA is usually expected in BU to
benefit from the IPsec protection. But there are specific
non normative notes in and
for deregistration BU sent from
Home: usual ones do not include the AltCoA option. This
point is mainly left as an implementation issue. For
instance, the Mobile IPv6 implementation for Linux
(UMIP) always includes the AltCoA option, even for
deregistration BU sent when back home.
Under the assumption that the HA processes the BU, can
we expect it to send the BA in the same fashion, using a
RH2? This is clearly implementation dependent. From a
specification point of view, the BA is expected to be
always sent to the source address of initial packet. In
our example, Attacker_Address.
Will the attacker be able to mangle received BA and have
it be processed by the MN? For the same reasons as the
ones given above, this may be possible.
As a temporary summary, the specific implementation of the
MIPv6 module running on the MN and the HA, the kind of
filtering implemented in the foreign and home networks will
impact the difficulty and requirements of setting up a full
BU/BA exchange leading to a complete deregistration on both
sides.
It is interesting to note that the final goal of the
attacker may not be to mount a full deregistration attack,
but to have the MN drop its IPsec tunnel protection. In that
context, a full attack would obviously do the job but some
less difficult solutions may exist. For instance, the reference documents leave quite some
latitude with respect to the order of events. For obvious
performance reasons, it is common for a MIPv6 modules not to
wait for the BA from its HA to start using its new
address. In the context of the deregistration when coming
back home, the MN may drop its IPsec tunnel protection
early, just after sending its BU and before receiving the
BA. Mobile IPv6 for Linux implementation (UMIP) can be
configured to do that. As a conclusion, the Home Link Detection mechanism rely on
untrusted and spoofable ND information. It is used as a
trigger for a significant security event when IPsec is used
for protecting data between the MN and its HA: the removal of
this IPsec tunnel protection on a foreign network. Moreover, various parts of the reference documents leave quite
some room for the build and processing of packets and the order
of events associated with deregistration and Home Return. It may
lead to interoperability issues and may also simplify the
work of an attacker which intend to exploit previous flaws. From our standpoint, when IPsec is used to protect data
traffic, even if an attacker manages to access the Home Subnet
of a MN, this should not provide her the ability to have one
such MN drop its IPsec protection on a foreign network. At the
moment, current MIPv6 reference documents may allow that to
happen. This section documents the implementation of the attacks
described in previous section against an existing
implementation. The targeted implementation is UMIP, the
freely available Linux implementation. The tool used to implement the attack in order to create or
mangle MIPv6 packets is Scapy. In this section, a Linux MN running UMIP is considered,
configured in order for signaling and data traffic to be
IPsec-protected. The former undergoing transport mode
protection and the latter tunnel mode protection. One configuration parameter of interest in the following
discussions is OptimisticHandoff option. It has the following
description in the software man page: Even if the option is disabled by default it is useful
to limit the effect of the RTT between the MN and its HA
when performing a handover. For that reason, chances are
high client will enable it. It should be noted that the effect of the option is
(unintentionally?) different whether the MN performs a
movement to a foreign network or to the home network. In former case, when the option is enabled, directly
after sending its BU, the MN migrates the tunnel endpoint
of its tunnel mode IPsec SP/SA (and warns the IKE daemon
of the change of CoA) as usual but also removes a blocking
rule for traffic which would normally be kept until the BA
is received. From the user perspective, the switch has
already happened, even if the HA has not yet acknowledged
it with a BA. In latter case, when the option is enabled, all the
changes required for the direct unprotected communication
of the MN on its Home Link are done directly after the
emission of the BU. Nonetheless, a rule which prevents
packets sent from the HoA to flow remains until the
protected BA is received from the HA. In the end, while
waiting for the BA, the MN does process unprotected
traffic sent to its HoA but is unable to reply (i.e. sent
traffic back from its HoA). Previous behavior when the OptimisticHandoff option is
enabled deserves some comments:
Considering the latency argument (RTT of the BU/BA
exchange) does not hold when the MN comes back home, the
fact that UMIP also performs a optimistic handoff in this
situation looks like a bug or at least a bad idea. The rule preventing traffic from the HoA until the
reception of the BA seems inconsistent with the rest of
the code (it may be here by luck). This subsection documents the effect on a UMIP-based
(IPsec-protected) MN of an attacker injecting fake RA,
advertising the Home Network Prefix (and the Home Agent
address). As introduced in previous subsection, the behavior of an
UMIP MN vary based on the value of the OptimisticHandoff
configuration parameter. If it is disabled (the default), the
MN is unable to communicate before the IPsec protected BA is
received from the HA. In that case, the attack results in a
DoS, but does not allow the attacker to directly send traffic
to node or access traffic sent by the node. When the OptimisticHandoff option is enabled, reception of
the RA advertising the Home Network prefix of the MN
directly leaves the MN without IPsec protection on the
attacker's link. As covered in previous subsection, a
residual blackhole route which is only dropped after the
reception of the BA by the MN prevents it to leak data
packets. Nonetheless, even if it is unable to reply, the MN
will happily process packets sent to its HoA (to listening
UDP services for instance).
As described in previous subsection, an attacker only
advertising the Home Network Prefix to an UMIP MN may be able,
depending on the specific configuration of the peer, to have
it drop the IPsec tunnel protecting data traffic. At most, in the best software configuration for the
attacker (OptimisticHandoff enabled on the MN), this may allow
it to have traffic sent to the peer on its HoA. The inability
for the MN to send traffic back from the HoA (blackhole rule
installed until the reception of the BA) will prevent TCP
connection to happen. Now, as explained in the first part of the document, the
attacker can improve the attack by mangling ESP-protected
deregistration BU sent by the peer (to the attacker, which
the MN believes to be its HA) and then resend it to the
HA. The setup is depicted on the following picture: The attacker now has two interfaces (it may be possible
to mount the attack with one interface but this is not
presented for clarity reasons), one on which it interacts
with the MN and the other which it uses to send/receive
packets to/from the HA. On that second interface, its
address (used in following descriptions) is
2001:db8::4:207:40ff:fe53:e1e4. The HA is available at 2001:db8::2:21e:bff:fe4e:3b2, the
Home Subnet of the MN being 2001:db8:0:2::/64. The MN's HoA
is 2001:db8::2:20d:93ff:fe55:8f79. Extending the code developed for previous attack
basically involves mangling the packet in the following way
(Scapy/Python code):For clarity, the ESP-protected BU received by the
attacker from the MN after having sent the RA and announced
itself as the MN's HA has the following layout: The address of the MN is
2001:db8::2:20d:93ff:fe55:8f79. The address of the HA is
2001:db8::2:21e:bff:fe4e:3b2. The packet sent to the HA at the end of the mangling
process associated with previous code has the following
layout: Its source address is now the address of the attacker
(2001:db8::4:207:40ff:fe53:e1e4) which provides it
connectivity to the internet in order to reach the HA (the
unmodified destination address found in the IPv6 header of
the packet, i.e. 2001:db8::2:21e:bff:fe4e:3b2). The address
of the MN (2001:db8::2:20d:93ff:fe55:8f79) is now found in
the inserted Home Address Option. The ESP Extension Header
has not been modified in the process. It should be noted
that the payload length field of the IPv6 header has been
recomputed by Scapy: its value differs from the one in the
initial packet due to the addition of the Destination
Option Header. Having implemented the mangling of the BU, the attacker
expects the HA to reply (if the BU is accepted) with a
BA. This BA, sent to the address of the attacker, will
include a Type 2 Routing Header (RH2). Unlike previous
mangling which required the insertion of an extension header
in the packet (the Destination Option Header), the attacker
now needs to remove the RH2 from the BA and set the MN's
HoA as destination address in the IPv6 header before sending
it to the peer. Improving the PoC to do that can be done in the
following way: For clarity, the ESP-protected BA received by the
attacker as a response from the HA has the following
layout: The packet obtained at the end of the mangling
process associated with previous code has the
following layout: As for previous mangling operation, the value of the
payload length field in the packet has been automatically
recomputed by Scapy to reflect the removal of the RH2. Implementing a PoC to test the effects of all theoretical
attacks against UMIP was easily done by developing a small
Automaton under Scapy (few lines of Python code). With such a tool, an attacker simply advertising the Home
Subnet prefix of a MN is able to make it believe it is at
home. Depending on the configuration of the MN, this may
allow the attacker to directly target the
MN: If OptimisticHandoff configuration option is disabled
(the default) this result in a simple DoS, the MN
waiting for a BA before it is able to communicate. If OptimisticHandoff configuration option is enabled,
the MN can then be joined on its HoA but cannot sent
traffic from that address (i.e. reply for instance) until
the reception of the BA. When the attacker also activates the relaying of BU from
the MN to the HA and the relaying of the associated BA from
the HA to the MN, the attack gets effective: the MN is fully
deregistered and does no more use IPsec protection for data
traffic, believing it is on its home network. The attack works against UMIP implementation because
the values found in the source address of the IPv6 packet,
the Home Address Option and the AltCoA are not invalid from
a specification standpoint, for a de-registration BU. Another reason is that the addition (respectively removal)
of the Destination Option Header (respectively RH2) in the
the BU (respectively BA) does not interfere with the
protection provided by ESP on the signaling traffic.In this subsection, we discuss the additional checks that
UMIP should implement in order to prevent previous
attacks. Note that those checks should only be seen as
workarounds/improvements of current situation, but not as a
complete solution to the Home Link Detection mechanism. UMIP should not enforce an optimistic behavior when
coming back home, i.e. it should not drop its IPsec tunnel
protection before the BA is received from the HA. This
does not make much sense from a performance point of view
and has security impacts, leading to the ability for an
attacker to have the MN handle incoming traffic (even
though the MN is unable to reply until it receives the
protected BA from the HA). UMIP should be modified in order for the HA to perform
stricter checks on incoming BU and only allow the
following layouts for de-registration
BU: Case 1 (Home De-registration): Lifetime is set to 0,
the packet does not contain an AltCoA option, does not
contain a Destination Option Header carrying a HAO and
has HoA as IPv6 source address. Case 2 (Remote De-registration): Lifetime is set to
0, the packet IPv6 source address is current registered
CoA, the packet contains a Destination Option Header
carrying a HAO (which contains the HoA), the packet
contains an AltCoA option carrying current registered
CoA (i.e. matching IPv6 source address of the
packet). Not that those proposed checks are stricter than the one
expected from a RFC3775-compliant implementation which may
result in interoperability issues. Ironically enough, if
such strict layouts had been initially specified in the
reference documents, this would have helped, both from
interoperability and security standpoints. As detailed in the appendix, the rules for MN and HA
for the creation and processing of BU are more than
fuzzy in reference documents. Those are spread over at
least 4 sections of :
6.1.7, 9.5.1, 10.3.2, 11.7.1. Rules for the sender (MN)
and the receiver (HA) do not match on some aspects, for
no specific reasons.
In this subsection, we discuss some possible leads for solving
the issue presented in the document. Without considering here the security impacts of current
Home Link Detection mechanism (discussed in following
subsections), current MIPv6 specification (and also
) would need some
work in order to define BU/BA processing/handling in a more
precise and consistent way. For instance, the allowed format of de-registration BU
(AltCoA option, HAO in Destination Option Header, IPv6
source address, ...) should be precisely described for both
cases (home and remote de-registration) instead of relying
on information from different sections. This would both help
in the development and security review. The first idea that comes to mind is to try and work on the root
of the issues, the Home Link Detection mechanism. By removing an
attacker the ability to spoof RA on a foreign network with crafted
ones including PIO with Home Subnet Prefix, the issue could
possibly be prevented. For that purpose, from a theoretical standpoint, SEND could
directly be used, simply by creating a Secure Home Link Detection
mechanism in which it would be required that RA advertising the
Home Subnet Prefix be signed. That way, an attacker on a
foreign link would not be able to trigger a deregistration
and this would prevent the IPsec tunnel protection to be
dropped.It should be noted that this possible solution comes with the
following drawbacks:It requires SEND to be implement on the Home Network.It requires SEND to be supported by the MIPv6 module.It does not protect the MNs on a foreign link against an
attacker that has simultaneous access to both the MN's Home
Subnet and the MN's foreign subnet. Even if this is a
strong hypothesis. MIPv6 specification does not mandate the removal of the
tunneling between the MN and the
HA. and ,
even if they expect the IPsec tunnel to be torn down when
back home, do not mandate it either.
It is possible to solve the issue by having MN warning
their HA that they are not willing to drop their IPsec
tunnel when back home. This simple solution (indicating that
willingness to keep IPsec tunnel protection up and running
on the home subnet is just a matter of a single flag in a
BU) would provide an efficient workaround to the issue. It would also be possible not to advertise anything in the
BU (not consume a flag) and let that as a local
configuration issue between the MN and the HA (requiring
configuration to be in sync on both sides). One would argue that this solution (maintaining IPsec
tunneling on the Home Network) could have negative drawbacks
on performance.The last obvious and most simple solution to the issue is
basically another a variant of previous proposal (``Never drop
IPsec tunnel protection''), but this time by removing the
ability for the MN to come back home (i.e. remove the
concept of Home Network for a MN) and consider the home
network is virtual. This section is purposely kept empty. The whole document discusses security considerations on the
Home Link Detection mechanisms defined in
. It covers the implication of its use
when IPsec is used to protect data traffic (as
allowed/expected by reference documents). Expected format and handling of BU/BA by HA/MN are discussed
from a security perspective.Key Words for Use in RFCs to Indicate
Requirement LevelsMobility Support in IPv6 Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents Mobile IPv6 Operation with IKEv2 and the Revised
IPsec Architecture Mobile IPv6 Bootstrapping in Split Scenario IPv6 Neighbor Discovery (ND) Trust Models and Threats Mobile IPv6 Residual Threats Mobility Support in IPv6 MIPv6 Home Link Detection To keep the core of the document readable but still have the
details available, this appendix provides a comprehensive analysis
of MIPv6 main reference documents for what is related to Home Link
detection and the ``Returning Home'' events. The Mobile IPv6 Home Link detection mechanism is quite
simple. In fact, it is specified in by a simple
sentence, in section 11.5.4 (``Returning Home''):
At the time of writing, MIPv6 specification is being revised
and that part of the document has been enhanced, to support
interactions with IKEv2 for Home Prefix Assignment
. Current version (02) of the draft
now includes a new specific
subsection providing a simple detection algorithm (based
on ) . The relevant part of the
algorithm is provided below:
It basically goes in the same direction as :
Mobile Node considers itself on its home link if it detects a
match between an advertised prefix and its home subnet prefix.
In the end, the expected Home Link detection mechanism has not
been modified compared to the one specified in the original
MIPv6 specification: simply put, if the MN finds itself on
a link where its Home Subnet Prefix is advertised, it considers
itself at home.
This excerpt from section 11.5.4 (``Returning Home'') of
(In current revision 02 of the document
, the section has not been
modified, but now has number 11.5.5) describes the emission of the
deregistration BU to the HA, just after it has detected it is at
home (using previous mechanism):
As for all Binding Update messages sent to the Home Agent as
part of Home Registration, IPsec protection is
expected. Usually, in order for the CoA information to be IPsec
protected (ESP does not provide protection for packet
source address), the Alternate CoA Option must be present in the
BU. This is explicitly stated in Section 11.7.1 (``Sending
Binding Updates to the Home Agent'') of :
Nonetheless, this expected behavior is somewhat different when
the Mobile Node is at home and needs to send its Binding
Update. This is described at the end of the following excerpt
from Section 4.3 (``IPsec Protocol Processing'') of
:
More specifically, as described in section 11.5.4 of
, the HoA must be set as source address of the
Binding Update message:
Still in (Section 3.1,``Binding Updates and
Acknowledgements''), specific examples of expected packet
layouts are given for registration when the node comes back
home:
This layout is associated with ``MUST support'' statements and is
expected to be used. Note that , the revised version
of , provides the same description and expects the same
behavior.
It is interesting to note that MIPv6 specification splits the
emission and validation steps: previous discussion were
associated with the emission of the deregistration BU by the
MN. Processing rules for validation and parsing of BU by the HA
when receiving it are covered in different sections of the
document and discussed later in next subsection.The reference documents require that Home Agent supports
previous Layout for deregistration Binding
Update. Even if this is probably the expected layout, this is
not the only possible solution. Additional information are
given in Section 9.5.1 of , for validating
Binding Update messages in general.Section 10.3.2 of covers in details ``Primary
Care-of Address De-Registration''. Here, the validation of
deregistration BU format by the HA leaves room for
different layouts:
The non-normative ``may not include the Home Address
destination option'' is ambiguous and error-prone: section
11.5.4 has a ``MUST use its home address as the source address
in the Binding Update''. If the Home Agent allows
deregistration BUs with Home Address destination option, this
leaves room for those to be sent from a foreign network,
probably to support the case where ``the mobile node knows
that it will not have any care-of addresses in the visited
network''.
Because of the rules for determining care-of address and
home address, provided in section 9.5.1The following various deregistration BU sent by a Mobile Node
should probably be considered valid (even if the specific
layout may not be supported on a specific implementation):
The last example is the common layout expected by the HA when
the MN is on a foreign network.The point here is that the expected layout for deregistration
BU sent by the MN should be strictly checked by the HA when
receiving the BU. It seems that the receiving rules for the HA
are not that strict, possibly to support the case where
``mobile node knows that it will not have any care-of
addresses in the visited network''. In this subsection, we just make the hypothesis that the HA has
received a deregistration BU which it has considered valid and
that it has determined the care-of address and the home-address
as described in section 9.5.1 of , quoted in
previous subsection.
The expected behavior by the HA is to remove the binding
(local modification of MIPv6 related structures). It is also
expected (even if not mandatory) that the tunnel with the Mobile
Node be removed, now that it is back home. This is described at
the end of section 11.5.4 of :
When IPsec is used for protecting tunneled traffic, the same
behavior is expected. Section 4.2 of specifies
that:
This SHOULD in was a MUST in . The
protection of BU/BA traffic using ESP in transport mode is
unmodified by the deregistration. After those changes, the HA sends back a BA to the MN. This is
required because the A bit is set in the BU sent by the MN for
de-registration, a BA is always sent by the HA, as described in
section 9.5.4 of :
This means that following the emission of a deregistration BU,
a MN should expect to receive a BA. With regard to the address the BA is sent, section 9.5.4 of
contains the following:
This basically implies that a deregistration BU with a HAO will
possibly trigger a BA with a RH2 sent to whatever address was in
the IPv6 header source address field in the BU. Simply put, the
BA is expect to be sent to the real address from which the BU
was sent.In section 3.1 of , the common cases for the
deregistration BA sent from the home network is covered:
Once it has sent the deregistration BU, the MN is expected to
perform some modification of its ND behavior, as discussed in
section 11.5.5 (``Returning home'') of
. Some final changes are
performed after receiving the BA from the HA:
The specification focuses on link layer interactions but does
not provide information on the timing associated with the
removal of the tunnel and/or IPsec Security Policies for
tunnel traffic. For performance reasons it usually happens
when the BU is sent (UMIP, the linux implementation,
does just that) to avoid sending packets with a possibly
invalid source address (the old CoA) while waiting for the BA
to come back.
If the same timing is kept when returning home, the MN will
drop its IPsec protection as soon as it has sent the
deregistration Binding Update. The author acknowledges the comments and corrections provided
by Jean-Michel Combes, Tony Cheneau, Nicolas Bareil and Romain
Kuntz on an initial version of the document. The work on this document was done in the context of
MobiSEND project, partially funded by the french "National
Research Agency (ANR)". This document was generated by xml2rfc.