normally routed by different routes through the network, and the Home
Test is transmitted over an encrypted tunnel from the home agent to
the mobile node (see also Section 5.4).
4.2. Creating State Safely
The correspondent node may remain stateless until it receives the
first Binding Update. That is, it does not need to record receiving
and replying to the Home Test Init and Care-of Test Init messages.
The Home Test Init/Home Test and Care-of Test Init/Care-of Test
exchanges take place in parallel but independently of each other.
Thus, the correspondent can respond to each message immediately, and
it does not need to remember doing that. This helps in potential
denial-of-service situations: no memory needs to be reserved for
processing Home Test Init and Care-of Test Init messages.
Furthermore, Home Test Init and Care-of Test Init processing is
designed to be lightweight, and it can be rate limited if necessary.
When receiving a first binding update, the correspondent node goes
through a rather complicated procedure. The purpose of this
procedure is to ensure that there is indeed a mobile node that has
recently received a Home Test and a Care-of Test that were sent to
the claimed home and care-of addresses, respectively, and to make
sure that the correspondent node does not unnecessarily spend CPU or
other resources while performing this check.
Since the correspondent node does not have any state when the binding
update arrives, the binding update itself must contain enough
information so that relevant state can be created. To that end, the
binding update contains the following pieces of information:
Source address: The care-of address specified in the Binding Update
must be equal to the source address used in the Care-of Test Init
message. Notice that this applies to the effective Care-of
Address of the Binding Update. In particular, if the Binding
Update includes an Alternate Care-of Address (AltCoA) [6], the
effective CoA is, of course, this AltCoA. Thus, the Care-of Test
Init must have originated from the AltCoA.
Home address: The home address specified in the Binding Update must
be equal to the source address used in the Home Test Init message.
Two nonce indices: These are copied over from the Home Test and
Care-of Test messages, and together with the other information
they allow the correspondent node to re-create the tokens sent in
the Home Test and Care-of Test messages and used for creating Kbm.
Without them, the correspondent node might need to try the 2-3
latest nonces, leading to unnecessary resource consumption.
Message Authentication Code (MAC): The binding update is
authenticated by computing a MAC function over the care-of
address, the correspondent node’s address and the binding update
message itself. The MAC is keyed with the key Kbm.
Given the addresses, the nonce indices (and thereby the nonces) and
the key Kcn, the correspondent node can re-create the home and care-
of tokens at the cost of a few memory lookups and computation of one
MAC and one hash function.
Once the correspondent node has re-created the tokens, it hashes the
tokens together, giving the key Kbm. If the Binding Update is
authentic, Kbm is cached together with the binding. This key is then
used to verify the MAC that protects integrity and origin of the
actual Binding Update. Note that the same Kbm may be used for a
while, until the mobile node moves (and needs to get a new care-of-
address token), the care-of token expires, or the home token expires.
4.2.1. Retransmissions and State Machine
Note that since the correspondent node may remain stateless until it
receives a valid binding update, the mobile node is solely
responsible for retransmissions. That is, the mobile node should
keep sending the Home Test Init / Care-of Test Init messages until it
receives a Home Test / Care-of Test, respectively. Similarly, it may
need to send the binding update a few times in the case it is lost
while in transit.
4.3. Quick expiration of the Binding Cache Entries
A Binding Cache Entry, along with the key Kbm, represents the return
routability state of the network at the time when the Home Test and
Care-of Test messages were sent out. It is possible that a specific
attacker is able to eavesdrop a Home Test message at some point of
time, but not later. If the Home Test had an infinite or a long
lifetime, that would allow the attacker to perform a time shifting
attack (see Section 2.2). That is, in the current IPv4 architecture
an attacker on the path between the correspondent node and the home
agent is able to perform attacks only as long as the attacker is able
to eavesdrop (and possibly disrupt) communications on that particular
path. A long living Home Test, and consequently the ability to send
valid binding updates for a long time, would allow the attacker to
continue its attack even after the attacker is no longer able to
eavesdrop on the path.
To limit the seriousness of this and other similar time shifting
threats, the validity of the tokens is limited to a few minutes.
This effectively limits the validity of the key Kbm and the lifetime
of the resulting binding updates and binding cache entries.
Although short lifetimes are required by other aspects of the
security design and the goals, they are clearly detrimental for
efficiency and robustness. That is, a Home Test Init / Home Test
message pair must be exchanged through the home agent every few
minutes. These messages are unnecessary from a purely functional
point of view, thereby representing overhead. What is worse, though,
is that they make the home agent a single point of failure. That is,
if the Home Test Init / Home Test messages were not needed, the
existing connections from a mobile node to other nodes could continue
even when the home agent fails, but the current design forces the
bindings to expire after a few minutes.
This concludes our walk-through of the selected security design. The
cornerstones of the design were the employment of the return
routability idea in the Home Test, Care-of Test, and binding update
messages, the ability to remain stateless until a valid binding
update is received, and the limiting of the binding lifetimes to a
few minutes. Next we briefly discuss some of the remaining threats
and other problems inherent to the design.
5. Security Considerations
This section gives a brief analysis of the security design, mostly in
the light of what was known when the design was completed in Fall
2002. It should be noted that this section does not present a proper
security analysis of the protocol; it merely discusses a few issues
that were known at the time the design was completed.
It should be kept in mind that the MIPv6 RO security design was never
intended to be fully secure. Instead, as we stated earlier, the goal
was to be roughly as secure as non-mobile IPv4 was known to be at the
time of the design. As it turns out, the result is slightly less
secure than IPv4, but the difference is small and most likely
insignificant in real life.
The known residual threats as compared with IPv4 are discussed in
Section 5.1. Considerations related to the application of IPsec to
authorize route optimization are discussed in Section 5.2. Section
5.3 discusses an attack against neighboring nodes. Finally, Section
5.4 deals with the special case of two mobile nodes conversing and
performing the route optimization procedure with each other.
5.1. Residual Threats as Compared to IPv4
As we mentioned in Section 4.2, the lifetime of a binding represents
a potential time shift in an attack. That is, an attacker that is
able to create a false binding is able to reap the benefits of the
binding as long as the binding lasts. Alternatively, the attacker is
able to delay a return-to-home flooding attack (Section 3.2.2) until
the binding expires. This is different from IPv4, where an attacker
may continue an attack only as long as it is on the path between the
two hosts.
Since the binding lifetimes are severely restricted in the current
design, the ability to do a time shifting attack is equivalently
restricted.
Threats possible because of the introduction of route optimization
are, of course, not present in a baseline IPv4 internet (Section
3.3). In particular, inducing unnecessary binding updates could
potentially be a severe attack, but this would be most likely due to
faulty implementations. As an extreme measure, a correspondent node
can protect against these attacks by turning off route optimization.
If so, it becomes obvious that the only residual attack against which
there is no clear-cut prevention (other than its severe limitation as
currently specified) is the time shifting attack mentioned above.
5.2. Interaction with IPsec
A major motivation behind the current binding update design was
scalability, which implied the ability to run the protocol without
any existing security infrastructure. An alternative would have been
to rely on existing trust relationships, perhaps in the form of a
special-purpose Public Key Infrastructure in conjunction with IPsec.
That would have limited scalability, making route optimization
available only in environments where it is possible to create
appropriate IPsec security associations between the mobile nodes and
the corresponding nodes.
There clearly are situations where there exists an appropriate
relationship between a mobile node and the correspondent node. For
example, if the correspondent node is a server that has pre-
established keys with the mobile node, that would be the case.
However, entity authentication or an authenticated session key is not
necessarily sufficient for accepting Binding Updates.
Home Address Check: If one wants to replace the home address check
with cryptographic credentials, these must carry proper
authorization for the specific home address, and care must be
taken to make sure that the issuer of the certificate is entitled
to express such authorization. At the time of the design work,
the route optimization security design team was not aware of
standardized certificate formats to do this, although more recent
efforts within the IETF are addressing this issue. Note that
there is plenty of motivation to do so, as any pre-existing
relationship with a correspondent node would involve the mobile
node’s home address (instead of any of its possible care-of
addresses). Accordingly, the IKE exchange would most naturally
run between the correspondent node and the mobile node’s home
address. This still leaves open the issue of checking the mobile
node’s care-of address.
Care-of Address Check: As for the care-of-address check, in
practice, it seems highly unlikely that nodes could completely
replace the care-of-address check with credentials. Since the
care-of addresses are ephemeral, in general it is very difficult
for a mobile node to present credentials that taken at face value
(by an arbitrary correspondent node) guarantee no misuse for, say,
flooding attacks (Section 3.2). As discussed before, a
reachability check goes a long way to alleviate such attacks.
Notice that, as part of the normal protocol exchange, establishing
IPsec security associations via IKE includes one such reachability
test. However, as per the previous section, the natural IKE
protocol exchange runs between the correspondent node and the
mobile node’s home address. Hence, another reachability check is
needed to check the care-of address at which the node is currently
reachable. If this address changes, such a reachability test is
likewise necessary, and it is included in ongoing work aimed at
securely updating the node’s current address.
Nevertheless, the Mobile IPv6 base specification [6] does not specify
how to use IPsec together with the mobility procedures between the
mobile node and correspondent node. On the other hand, the
specification is carefully written to allow the creation of the
binding management key Kbm through some different means.
Accordingly, where an appropriate relationship exists between a
mobile node and a correspondent node, the use of IPsec is possible,
and is, in fact, being pursued in more recent work.
5.3. Pretending to Be One’s Neighbor
One possible attack against the security design is to pretend to be a
neighboring node. To launch this attack, the mobile node establishes
route optimization with some arbitrary correspondent node. While
performing the return routability tests and creating the binding
management key Kbm, the attacker uses its real home address but a
faked care-of address. Indeed, the care-of address would be the
address of the neighboring node on the local link. The attacker is
able to create the binding since it receives a valid Home Test
normally, and it is able to eavesdrop on the Care-of Test, as it
appears on the local link.
This attack would allow the mobile node to divert unwanted traffic
towards the neighboring node, resulting in an flooding attack.
However, this attack is not very serious in practice. First, it is
limited in the terms of location, since it is only possible against
neighbors. Second, the attack works also against the attacker, since
it shares the local link with the target. Third, a similar attack is
possible with Neighbor Discovery spoofing.
5.4. Two Mobile Nodes Talking to Each Other
When two mobile nodes want to establish route optimization with each
other, some care must be exercised in order not to reveal the reverse
tokens to an attacker. In this situation, both mobile nodes act
simultaneously in the mobile node and the correspondent node roles.
In the correspondent node role, the nodes are vulnerable to attackers
that are co-located at the same link. Such an attacker is able to
learn both the Home Test and Care-of Test sent by the mobile node,
and therefore it is able to spoof the location of the other mobile
host to the neighboring one. What is worse is that the attacker can
obtain a valid Care-of Test itself, combine it with the Home Test,
and then claim to the neighboring node that the other node has just
arrived at the same link.
There is an easy way to avoid this attack. In the correspondent node
role, the mobile node should tunnel the Home Test messages that it
sends through its home agent. This prevents the co-located attacker
from learning any valid Home Test messages.
6. Conclusions
This document discussed the security design rationale for the Mobile
IPv6 Route Optimization. We have tried to describe the dangers
created by Mobile IP Route Optimization, the security goals and
background of the design, and the actual mechanisms employed.
We started the discussion with a background tour to the IP routing
architecture the definition of the mobility problem. After that, we
covered the avenues of attack: the targets, the time shifting
abilities, and the possible locations of an attacker. We outlined a
number of identified threat scenarios, and discussed how they are
mitigated in the current design. Finally, in Section 4 we gave an
overview of the actual mechanisms employed, and the rational behind
them.
As far as we know today, the only significant difference between the
security of an IPv4 Internet and that of an Internet with Mobile IPv6
(and route optimization) concerns time shifting attacks.
Nevertheless, these are severely restricted in the current design.
We have also briefly covered some of the known subtleties and
shortcomings, but that discussion cannot be exhaustive. It is quite
probable that new subtle problems will be discovered with the design.
As a consequence, it is most likely that the design needs to be
revised in the light of experience and insight.
7. Acknowledgements
We are grateful for: Hesham Soliman for reminding us about the threat
explained in Section 5.3, Francis Dupont for first discussing the
case of two mobile nodes talking to each other (Section 5.4) and for
sundry other comments, Pekka Savola for his help in Section 1.1.1,
and Elwyn Davies for his thorough editorial review.
8. Informative References
[1] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location
Management", Proc. 18th Annual Computer Security Applications
Conference, pages 78-87, Las Vegas, NV, USA, IEEE Press,
December 2002.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines
and Philosophy", RFC 3439, December 2002.
[5] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[11] Chiappa, J., "Will The Real ’End-End Principle’ Please Stand
Up?", Private Communication, April 2002.
[12] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver", ACM Computer
Communication Review, 29:5, October 1999.
[13] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Security Protocols 9th
International Workshop, Cambridge, UK, April 25-27 2001, LNCS
2467, pages 12-26, Springer, 2002.
[14] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", Private
Communication, 1999.
[15] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Authors’ Addresses
Pekka Nikander
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Jari Arkko
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
EMail: jari.arkko@ericsson.com
Tuomas Aura
Microsoft Research Ltd.
Roger Needham Building
7 JJ Thomson Avenue
Cambridge CB3 0FB
United Kingdom
EMail: Tuomaura@microsoft.com
Gabriel Montenegro
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: gabriel_montenegro_2000@yahoo.com
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
EMail: erik.nordmark@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.