binding update procedure may depend on several factors (including
heuristics, cross layer information, and configuration options) and
is not specified by Mobile IPv6. Not initiating the binding update
procedure automatically may alleviate these attacks, but it will not,
in general, prevent them completely.
In a real attack the attacker would induce the mobile node to
initiate binding update protocols with a large number of
correspondent nodes at the same time. If the correspondent addresses
are real addresses of existing IP nodes, then most instances of the
binding update protocol might even complete successfully. The
entries created in the Binding Cache are correct but useless. In
this way, the attacker can induce the mobile to execute the binding
update protocol unnecessarily, which can drain the mobile’s
resources.
A correspondent node (i.e., any IP node) can also be attacked in a
similar way. The attacker sends spoofed IP packets to a large number
of mobiles, with the target node’s address as the source address.
These mobiles will initiate the binding update protocol with the
target node. Again, most of the binding update protocol executions
will complete successfully. By inducing a large number of
unnecessary binding updates, the attacker is able to consume the
target node’s resources.
This attack is possible against any binding update authentication
protocol. The more resources the binding update protocol consumes,
the more serious the attack. Therefore, strong cryptographic
authentication protocol is more vulnerable to the attack than a weak
one or unauthenticated binding updates. Ingress filtering helps a
little, since it makes it harder to forge the source address of the
spoofed packets, but it does not completely eliminate this threat.
A node should protect itself from the attack by setting a limit on
the amount of resources (i.e., processing time, memory, and
communications bandwidth) that it uses for processing binding
updates. When the limit is exceeded, the node can simply stop
attempting route optimization. Sometimes it is possible to process
some binding updates even when a node is under the attack. A mobile
node may have a local security policy listing a limited number of
addresses to which binding updates will be sent even when the mobile
node is under DoS attack. A correspondent node (i.e., any IP node)
may similarly have a local security policy listing a limited set of
addresses from which binding updates will be accepted even when the
correspondent is under a binding update DoS attack.
The node may also recognize addresses with it had meaningful
communication in the past and only send binding updates to, or accept
them from, those addresses. Since it may be impossible for the IP
layer to know about the protocol state in higher protocol layers, a
good measure of the meaningfulness of the past communication is
probably per-address packet counts. Alternatively, Neighbor
Discovery [2] (Section 5.1, Conceptual Data Structures) defines the
Destination Cache as a set of entries about destinations to which
traffic has been sent recently. Thus, implementors may wish to use
the information in the Destination Cache.
Section 11.7.2 ("Correspondent Registration") in [6] does not specify
when such a route optimization procedure should be initiated. It
does indicate when it may justifiable to do so, but these hints are
not enough. This remains an area where more work is needed.
Obviously, given that route optimization is optional, any node that
finds the processing load excessive or unjustified may simply turn it
off (either selectively or completely).
3.3.2. Forcing Non-Optimized Routing
As a variant of the previous attack, the attacker can prevent a
correspondent node from using route optimization by filling its
Binding Cache with unnecessary entries so that most entries for real
mobiles are dropped.
Any successful DoS attack against a mobile or correspondent node can
also prevent the processing of binding updates. We have previously
suggested that the target of a DoS attack may respond by stopping
route optimization for all or some communication. Obviously, an
attacker can exploit this fallback mechanism and force the target to
use the less efficient home agent-based routing. The attacker only
needs to mount a noticeable DoS attack against the mobile or
correspondent, and the target will default to non-optimized routing.
The target node can mitigate the effects of the attack by reserving
more space for the Binding Cache, by reverting to non-optimized
routing only when it cannot otherwise cope with the DoS attack, by
trying aggressively to return to optimized routing, or by favoring
mobiles with which it has an established relationship. This attack
is not as serious as the ones described earlier, but applications
that rely on Route Optimization could still be affected. For
instance, conversational multimedia sessions can suffer drastically
from the additional delays caused by triangle routing.
3.3.3. Reflection and Amplification
Attackers sometimes try to hide the source of a packet-flooding
attack by reflecting the traffic from other nodes [1]. That is,
instead of sending the flood of packets directly to the target, the
attacker sends data to other nodes, tricking them to send the same
number, or more, packets to the target. Such reflection can hide the
attacker’s address even when ingress filtering prevents source
address spoofing. Reflection is particularly dangerous if the
packets can be reflected multiple times, if they can be sent into a
looping path, or if the nodes can be tricked into sending many more
packets than they receive from the attacker, because such features
can be used to amplify the traffic by a significant factor. When
designing protocols, one should avoid creating services that can be
used for reflection and amplification.
Triangle routing would easily create opportunities for reflection: a
correspondent node receives packets (e.g., TCP SYN) from the mobile
node and replies to the home address given by the mobile node in the
Home Address Option (HAO). The mobile might not really be a mobile
and the home address could actually be the target address. The
target would only see the packets sent by the correspondent and could
not see the attacker’s address (even if ingress filtering prevents
the attacker from spoofing its source address).
+----------+ TCP SYN with HAO +-----------+
| Attacker |-------------------->| Reflector |
+----------+ +-----------+
|
| TCP SYN-ACK to HoA
V
+-----------+
| Flooding |
| target |
+-----------+
Figure 5. Reflection Attack
A badly designed binding update protocol could also be used for
reflection: the correspondent would respond to a data packet by
initiating the binding update authentication protocol, which usually
involves sending a packet to the home address. In that case, the
reflection attack can be discouraged by copying the mobile’s address
into the messages sent by the mobile to the correspondent. (The
mobile’s source address is usually the same as the care-of address,
but an Alternative Care-of Address sub-option can specify a different
care-of address.) Some of the early proposals for MIPv6 security
used this approach and were prone to reflection attacks.
In some of the proposals for binding update authentication protocols,
the correspondent node responded to an initial message from the
mobile with two packets (one to the home address, one to the care-of
address). It would have been possible to use this to amplify a
flooding attack by a factor of two. Furthermore, with public-key
authentication, the packets sent by the correspondent might have been
significantly larger than the one that triggers them.
These types of reflection and amplification can be avoided by
ensuring that the correspondent only responds to the same address
from which it received a packet, and only with a single packet of the
same size. These principles have been applied to MIPv6 security
design.
3.4. Classification of Attacks
Sect. Attack name Target Sev. Mitigation
---------------------------------------------------------------------
3.1.1 Basic address stealing MN Med. RR
3.1.2 Stealing addresses of stationary nodes Any High RR
3.1.3 Future address stealing MN Low RR, lifetime
3.1.4 Attacks against secrecy and integrity MN Low RR, IPsec
3.1.5 Basic denial-of-service attacks Any Med. RR
3.1.6 Replaying and blocking binding updates MN Low lifetime,
seq number,
MAC
3.2.1 Basic flooding Any High RR
3.2.2 Return-to-home flooding Any High RR
3.3.1 Inducing unnecessary binding updates MN, CN Med. heuristics
3.3.2 Forcing non-optimized routing MN Low heuristics
3.3.3 Reflection and amplification N/A Med. BU design
Figure 6. Summary of Discussed Attacks
Figure 6 gives a summary of the attacks discussed. As it stands at
the time of writing, the return-to-the-home flooding and the
induction of unnecessary binding updates look like the threats
against which we have the least amount of protection, compared to
their severity.
3.5. Problems with Infrastructure-Based Authorization
Early in the MIPv6 design process, it was assumed that plain IPsec
could be the default way to secure Binding Updates with arbitrary
correspondent nodes. However, this turned out to be impossible.
Plain IPsec relies on an infrastructure for key management, which, to
be usable with any arbitrary pair of nodes, would need to be global
in scope. Such a "global PKI" does not exist, nor is it expected to
come into existence any time soon.
More minor issues that also surfaced at the time were: (1)
insufficient filtering granularity for the state of IPsec at the
time, (2) cost to establish a security association (in terms of CPU
and round trip times), and (3) expressing the proper authorization
(as opposed to just authentication) for binding updates [13]. These
issues are solvable, and, in particular, (1) and (3) have been
addressed for IPsec usage with binding updates between the mobile
node and the home agent [7].
However, the lack of a global PKI remains unsolved.
One way to provide a global key infrastructure for mobile IP could be
DNSSEC. Such a scheme is not completely supported by the existing
specifications, as it constitutes a new application of the KEY RR,
something explicitly limited to DNSSEC [8] [9] [10]. Nevertheless,
if one were to define it, one could proceed along the following
lines: A secure reverse DNS that provided a public key for each IP
address could be used to verify that a binding update is indeed
signed by an authorized party. However, in order to be secure, each
link in such a system must be secure. That is, there must be a chain
of keys and signatures all the way down from the root (or at least
starting from a trust anchor common to the mobile node and the
correspondent node) to the given IP address. Furthermore, it is not
enough that each key be signed by the key above it in the chain. It
is also necessary that each signature explicitly authorize the lower
key to manage the corresponding address block below.
Even though it would be theoretically possible to build a secure
reverse DNS infrastructure along the lines shown above, the practical
problems would be daunting. Whereas the delegation and key signing
might work close to the root of the tree, it would probably break
down somewhere along the path to the individual nodes. Note that a
similar delegation tree is currently being proposed for Secure
Neighbor Discovery [15], although in this case only routers (not
necessarily every single potential mobile node) need to secure such a
certificate. Furthermore, checking all the signatures on the tree
would place a considerable burden on the correspondent nodes, making
route optimization prohibitive, or at least justifiable only in very
particular circumstances. Finally, it is not enough simply to check
whether the mobile node is authorized to send binding updates
containing a given home address, because to protect against flooding
attacks, the care-of address must also be verified.
Relying on this same secure DNS infrastructure to verify care-of
addresses would be even harder than verifying home addresses.
Instead, a different method would be required, e.g., a return
routability procedure. If so, the obvious question is whether the
gargantuan cost of deploying the global secure DNS infrastructure is
worth the additional protection it affords, as compared to simply
using return routability for both home address and care-of address
verification.
4. Solution Selected for Mobile IPv6
The current Mobile IPv6 route optimization security has been
carefully designed to prevent or mitigate the threats that were
discussed in Section 3. The goal has been to produce a design with a
level of security close to that of a static IPv4-based Internet, and
with an acceptable cost in terms of packets, delay, and processing.
The result is not what one would expect: it is definitely not a
traditional cryptographic protocol. Instead, the result relies
heavily on the assumption of an uncorrupted routing infrastructure
and builds upon the idea of checking that an alleged mobile node is
indeed reachable through both its home address and its care-of
address. Furthermore, the lifetime of the state created at the
corresponded nodes is deliberately restricted to a few minutes, in
order to limit the potential threat from time shifting.
This section describes the solution in reasonable detail (for further
details see the specification), starting from Return Routability
(Section 4.1), continuing with a discussion about state creation at
the correspondent node (Section 4.2), and completing the description
with a discussion about the lifetime of Binding Cache Entries
(Section 4.3).
4.1. Return Routability
Return Routability (RR) is the name of the basic mechanism deployed
by Mobile IPv6 route optimization security design. RR is based on
the idea that a node should be able to verify that there is a node
that is able to respond to packets sent to a given address. The
check yields false positives if the routing infrastructure is
compromised or if there is an attacker between the verifier and the
address to be verified. With these exceptions, it is assumed that a
successful reply indicates that there is indeed a node at the given
address, and that the node is willing to reply to the probes sent to
it.
The basic return routability mechanism consists of two checks, a Home
Address check (see Section 4.1.1) and a care-of-address check (see
Section 4.1.2). The packet flow is depicted in Figure 7. First, the
mobile node sends two packets to the correspondent node: a Home Test
Init (HoTI) packet is sent through the home agent, and a Care-of Test
Init (CoTI) directly. The correspondent node replies to both of
these independently by sending a Home Test (HoT) in response to the
Home Test Init and a Care-of Test (CoT) in response to the Care-of
Test Init. Finally, once the mobile node has received both the Home
Test and Care-of Test packets, it sends a Binding Update to the
correspondent node.
+------+ 1a) HoTI +------+
| |---------------------->| |
| MN | 2a) HoT | HA |
| |<----------------------| |
+------+ +------+
1b) CoTI | ^ | / ^
| |2b| CoT / /
| | | / /
| | | 3) BU / /
V | V / /
+------+ 1a) HoTI / /
| |<----------------/ /
| CN | 2a) HoT /
| |------------------/
+------+
Figure 7. Return Routability Packet Flow
It might appear that the actual design was somewhat convoluted. That
is, the real return routability checks are the message pairs < Home
Test, Binding Update > and < Care-of Test, Binding Update >. The
Home Test Init and Care-of Test Init packets are only needed to
trigger the test packets, and the Binding Update acts as a combined
routability response to both of the tests.
There are two main reasons behind this design:
o avoidance of reflection and amplification (see Section 3.3.3), and
o avoidance of state exhaustion DoS attacks (see Section 4.2).
The reason for sending two Init packets instead of one is to avoid
amplification. The correspondent node does not know anything about
the mobile node, and therefore it just receives an unsolicited IP
packet from some arbitrary IP address. In a way, this is similar to
a server receiving a TCP SYN from a previously unknown client. If
the correspondent node were to send two packets in response to an
initial trigger, that would provide the potential for a DoS
amplification effect, as discussed in Section 3.3.3.
This scheme also avoids providing for a potential reflection attack.
If the correspondent node were to reply to an address other than the
source address of the packet, that would create a reflection effect.
Thus, the only safe mechanism possible for a naive correspondent is
to reply to each received packet with just one packet, and to send
the reply to the source address of the received packet. Hence, two
initial triggers are needed instead of just one.
Let us now consider the two return routability tests separately. In
the following sections, the derivation of cryptographic material from
each of these is shown in a simplified manner. For the real formulas
and more detail, please refer to [6].
4.1.1. Home Address Check
The Home Address check consists of a Home Test (HoT) packet and a
subsequent Binding Update (BU). It is triggered by the arrival of a
Home Test Init (HoTI). A correspondent node replies to a Home Test
Init by sending a Home Test to the source address of the Home Test
Init. The source address is assumed to be the home address of a
mobile node, and therefore the Home Test is assumed to be tunneled by
the Home Agent to the mobile node. The Home Test contains a
cryptographically generated token, home keygen token, which is formed
by calculating a hash function over the concatenation of a secret
key, Kcn, known only by the correspondent node, the source address of
the Home Test Init packet, and a nonce.
home keygen token = hash(Kcn | home address | nonce | 0)
An index to the nonce is also included in the Home Test packet,
allowing the correspondent node to find the appropriate nonce more
easily.
The token allows the correspondent node to make sure that any binding
update received subsequently has been created by a node that has seen
the Home Test packet; see Section 4.2.
In most cases, the Home Test packet is forwarded over two different
segments of the Internet. It first traverses from the correspondent
node to the Home Agent. On this trip, it is not protected and any
eavesdropper on the path can learn its contents. The Home Agent then
forwards the packet to the mobile node. This path is taken inside an
IPsec ESP protected tunnel, making it impossible for the outsiders to
learn the contents of the packet.
At first, it may sound unnecessary to protect the packet between the
home agent and the mobile node, since it travelled unprotected
between the correspondent node and the mobile node. If all links in
the Internet were equally insecure, the additional protection would
be unnecessary. However, in most practical settings the network is
likely to be more secure near the home agent than near the mobile
node. For example, if the home agent hosts a virtual home link and
the mobile nodes are never actually at home, an eavesdropper should
be close to the correspondent node or on the path between the
correspondent node and the home agent, since it could not eavesdrop
at the home agent. If the correspondent node is a major server, all
the links on the path between it and the home agent are likely to be
fairly secure. On the other hand, the Mobile Node is probably using
wireless access technology, making it sometimes trivial to eavesdrop
on its access link. Thus, it is fairly easy to eavesdrop on packets
that arrive at the mobile node. Consequently, protecting the HA-MN
path is likely to provide real security benefits even when the CN-HA
path remains unprotected.
4.1.2. Care-of-Address Check
From the correspondent node’s point of view, the Care-of-Address
check is very similar to the home check. The only difference is that
now the source address of the received Care-of Test Init packet is
assumed to be the care-of address of the mobile node. Furthermore,
the token is created in a slightly different manner in order to make
it impossible to use home tokens for care-of tokens or vice versa.
care-of keygen token = hash(Kcn | care-of address | nonce | 1)
The Care-of Test traverses only one leg, directly from the
correspondent node to the mobile node. It remains unprotected all
along the way, making it vulnerable to eavesdroppers near the
correspondent node, on the path from the correspondent node to the
mobile node, or near the mobile node.
4.1.3. Forming the First Binding Update
When the mobile node has received both the Home Test and Care-of Test
messages, it creates a binding key, Kbm, by computing a hash function
over the concatenation of the tokens received.
This key is used to protect the first and the subsequent binding
updates, as long as the key remains valid.
Note that the key Kbm is available to anyone who is able to receive
both the Care-of Test and Home Test messages. However, they are