Mobility Extensions W. Haddad
Internet-Draft G. Tsirtsis
Intended status: Informational Qualcomm
Expires: January 15, 2009 B. Lim
Panasonic
S. Krishnan
Ericsson
F. Dupont
ISC
July 14, 2008
Mobile IPv6 Residual Threats
draft-haddad-mext-mip6-residual-threats-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Haddad, et al. Expires January 15, 2009 [Page 1]
Internet-Draft MIPv6 Residual Threats July 2008
Abstract
This memo aims to highlight specific "residual" threats in Mobile
IPv6 protocol. We call these threats "residual" simply because they
were rightfully deemed not urgent during the design of Mobile IPv6
protocol. However, these threats are somehow benefiting from new
mechanisms and/or extensions built on top of Mobile IPv6 protocol to
improve their effects and likelihood. Hence, our main goal is to
motivate designers to re-assess their potential taking into
consideration these new mechanisms.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Residual Threats Associated with a Malicious Mobile Node . . . 5
3.1. Violating Trust between the Mobile Node and its Home
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Violating Trust between a Multihomed Mobile Node and
its Home Agents . . . . . . . . . . . . . . . . . . . . . 6
3.3. Creating Routing Loops Among Home Agents . . . . . . . . . 8
4. Exploiting Multihoming to Defeat Ingress Filtering . . . . . . 10
5. Exploiting Neighbor Discovery in a MIPv6 Environment . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Haddad, et al. Expires January 15, 2009 [Page 2]
Internet-Draft MIPv6 Residual Threats July 2008
1. Introduction
Mobile IPv6 protocol design (described in [MIPv6]) involved extensive
security analysis in order to evaluate the potential of each threat
and suggest defensive measures when necessary or avoid adding
complexities in case a security weakness was deemed acceptable (i.e.,
does not make IPv6 Internet more secure than without IP mobility).
However, these weaknesses have been implicitly inherited in new
mobility mechanisms and/or extensions built on top of MIPv6 which may
in turn have increased their effects and thus, made them more
attractive.
This memo aims to describe these residual threats and to motivate
designers to re-assess their potential in the light of what has been
added so far to MIPv6 protocol.
Haddad, et al. Expires January 15, 2009 [Page 3]
Internet-Draft MIPv6 Residual Threats July 2008
2. Conventions used in this document
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 [TERM].
Haddad, et al. Expires January 15, 2009 [Page 4]
Internet-Draft MIPv6 Residual Threats July 2008
3. Residual Threats Associated with a Malicious Mobile Node
3.1. Violating Trust between the Mobile Node and its Home Agent
The trust model adopted in MIPv6 protocol assumes that the mobile
node (MN) will always refrain from misusing the relationship it
forges with its home agent (HA). In return, the HA should treat any
legitimate information sent by the MN as being trustable. For
example, the HA will accept any new care-of address (CoA) claimed by
the MN and sent in a valid binding update (BU) message(s).
In fact, there are two interrelated factors for expecting a well
behaving MN. First, the MN is expected to be fully aware about the
HA tracing capabilities coupled with a strong authentication.
Second, there is a high probability that the victim will complain to
the operator in which case, the MN is quickly identified and punitive
actions can be taken against it.
However, the situation changes when the first factor is no longer
valid. This is the case where a user gains access to the operator
network without strong identification (e.g., prepaid phone card). In
such scenario, a malicious behavior can go unpunished since the
operator is unable to trace the user. The malicious behavior can
consist of sending to the HA a valid BU message carrying a fake CoA,
which triggers traffic redirection towards the victim. While the
target can always complain to the attacker's operator, the latter can
do little or nothing about it (of course, the attack will eventually
stop when the credit on the prepaid card is entirely consumed or the
prepaid card itself expires). Note that while some countries have
imposed some restrictions on using prepaid card, e.g, by requiring
additional identification and denying roaming service, other
countries are still allowing them without control.
In fact, the lack of any reachability test between the MN and its HA,
prior to or after sending a BU message, enables a malicious MN to
launch a flooding attack against any potential target by simply
claiming a new CoA which seems to be topologically located within the
targeted network. Without testing the new CoA reachability, the HA
will simply re-route data packets to the new CoA, i.e., targeted
network, and the attacker can keep sending acknowledgment (ACK)
messages to all its CN(s) in order to maintain the attack as long as
needed.
Note that this type of attack is not new and has been analyzed in
[MROD]. In fact, when the route optimization (RO) mode is used, the
impact of such attack is mitigated by imposing a periodic return
routability procedure. Another way to protect against this attack is
to deploy ingress filtering (described in [INGRESS]).
Haddad, et al. Expires January 15, 2009 [Page 5]
Internet-Draft MIPv6 Residual Threats July 2008
Moreover, new added extensions to MIPv6 may enhance launching
flooding attack through the HA. This is due to the MN's ability to
register multiple CoAs with the HA. Such scenario is better
described in [Multih_Sec] and is analyzed in the next section.
3.2. Violating Trust between a Multihomed Mobile Node and its Home
Agents
Multiple Care-of Address registration (MCoA) protocol (described in
[MCoA]) extends the MIPv6 protocol to enable a multi-interface MN to
register multiple CoAs at its HA. The fundamental difference between
MIPv6 and MCoA is that for a given home address (HoA) in MIPv6, the
MN is only able to bind a primary 'fake' CoA. Hence, this implies
that once a malicious MN binds the 'fake' CoA at HA, that MN loses
its ability to use that HoA for communication. However, in MCoA,
with the ability to bind several CoAs to a single HoA, a malicious MN
could bind a mixture of 'real' and 'fake' CoAs. The MN can still use
the HoA for communication by directing control traffic towards its
'real' CoA.
Likewise in the trust model described in [MROD] between the MN and
its HA, it permits the HA to always acknowledge any binding that the
MN requests. This trust relationship is further strengthened when
one assume that ingress filtering is being used such that when the HA
receives a BU message from the MN stating its CoA as the source
address, the HA trusts that the incoming packets do indeed originate
from the specified source address. In addition, the HA also trusts
the routing infrastructure, i.e., that packets forwarded by the HA
would be sent to the intended destination. This assumption makes it
possible for the HA to somewhat trust the MN if the MN sends the
binding of each CoA individually (e.g., one BU message per CoA).
Even with ingress filtering deployed worldwide in all networks, the
problem of the flooding attack described above could still be
achieved in the Multiple Care-of Address registration (MCoA) protocol
where the MN is able to use multiple binding identifier options in a
single binding update message to the home agent for registration
purposes. With the care-of addresses embedded inside the BU message,
it is not possible for ingress filtering to be used to verify these
CoAs. Figure 1 shows an example on how MCoA could be used to
initiate the redirection attack.
Haddad, et al. Expires January 15, 2009 [Page 6]
Internet-Draft MIPv6 Residual Threats July 2008
[Start of packet header]
Source Address : CoA
Destination Address : HA's address
[Mobility Options]
Binding Unique Identifier: BID1
Binding Unique Identifier: BID2
Care-of Address : V1's address
Binding Unique Identifier: BID3
Care-of Address : V2's address
[End of packet header]
Figure 1: Binding update message for MCoA
CoA is a valid care-of address owned by MN. MN is attempting to bind
addresses of two victims, V1 and V2, at HA in order to launch an
attack towards the victims.
When HA receives this BU message, it will accept it based on the
following. First, the BU message is deemed authorized as the correct
IPSec SA is used for the message. Second, the trust relationship
that HA has with the routing infrastructure allows it to understand
that this BU message is sent from MN. Finally, after the first two
checks have succeeded, the trust relationship that HA has with the MN
permits it to trust the care-of addresses that are specified in this
BU message. Hence, the binding cache at HA will record three
bindings for MN tied to MN's home address (HoA) as shown in Figure 2
below.
Binding 1 [HoA, CoA , BID1]
Binding 2 [HoA, V1's address, BID2]
Binding 2 [HoA, V2's address, BID3]
Figure 2: Binding Cache at Home Agent
The lack of any reachability test between the mobile node and its HA,
prior to or after sending a BU message, enables a malicious MN to
launch a network flooding attack against any potential target by
Haddad, et al. Expires January 15, 2009 [Page 7]
Internet-Draft MIPv6 Residual Threats July 2008
simply claiming new care-of addresses.
3.3. Creating Routing Loops Among Home Agents
In MIPv6, it is possible for a malicious MN to create a routing loop
amongst HAs. This can be achieved when a MN binds one home address
located on a first HA to another home address on a second HA. This
type of binding will force HAs to route the same packet among each
other without knowledge that a routing loop has been created. Such
looping problem is limited to cases where a MN has multiple HAs. For
the single case, MIPv6 has a policy at the HA to prevent the binding
of one home address to another home address hosted by the same home
agent. Figure 3 below shows such threat of routing loop between home
agents.
+-----+
| |
| I | cccc +-----+ Binding cache
| N |------| HA1 | [HoA1, HoA2]
HoA1 | T | +-----+
+----+ | E |
| MN |------| R |
+----+ | N | cccc +-----+ Binding cache
HoA2 | E |------| HA2 | [HoA2, HoA1]
| T | +-----+
| |
+-----+
Figure 3: Packet flooding attack scenario
The mobile node (MN) sends a binding update (BU) message to its first
home agent (HA1) to bind its home address (HoA1) to a care-of address
(HoA2). Since HoA2 is not a home address on HA1, HA1 accepts this
binding thinking that HoA2 is indeed a CoA. Likewise, on HA2, MN
sends a BU to bind its home address (HoA2) to a care-of address
(HoA1). Such bindings created among the two HAs create a routing
loop between them. For example, when HA1 wants to forward a packet
(shown as 'c') from a CN to MN, HA1 searches the binding cache to
find the relevant MN's CoA. In this case, HA1 tunnels the packet to
MN via HoA2. This will cause HA2 to intercept the packet for MN.
Now, at HA2, it sees that the packet is addressed to HoA2. Searching
the respective binding entry in its binding cache, HA2 will tunnel
this packet to MN via HoA1. This will cause HA1 to intercept the
packet for MN. This repetition will continue until one of the HA
discover that it can no longer encapsulate the packet (i.e., due to
the tunnel encapsulation limit == 0 described in [GPT6]). In this
case, the packet would be dropped and a flood of error message will
Haddad, et al. Expires January 15, 2009 [Page 8]
Internet-Draft MIPv6 Residual Threats July 2008
be sent between both HAs to indicate that the packet has failed to
reach its intended destination (the MN). Thus, it can be seen that
such attacks consumes the resources of the home agent and if launched
in full scale (e.g., multiple sets of HoAs) could 'shut down' the HA.
Haddad, et al. Expires January 15, 2009 [Page 9]
Internet-Draft MIPv6 Residual Threats July 2008
4. Exploiting Multihoming to Defeat Ingress Filtering
A malicious multi-homed node can also use its multiple interfaces to
emulate a home network and defeat ingress filtering. This is the
case when an attacker with two interfaces (A) and (B) starts its
attack by establishing sessions with a set of correspondent nodes
(CNs) using (A)'s IPv6 address then at some point, attaches (B) to
the targeted network and triggers a return routability (RR) procedure
with the CN. As the RR procedure involves exchanging HoTI/HoT
messages, the MN will use (A)'s IPv6 address for that purpose and
receives a home keygen token. Then the MN exchanges a CoTI/CoT
messages using (B)'s IPv6 address as a CoA and obtain a care-of
keygen token. A BU message is then sent to the CN and the data
traffic is redirected to (B).
At some point, the MN detaches itself from the targeted network and
start sending legitimate ACK messages via a legitimate address to
each CN causing a flooding attack. Such scenario is mitigated by the
fact that the MN MUST periodically repeat the RR procedure which
means that it has to exchange CoTI/CoT messages with each CN.
However, if the MN manages to position itself on-path with at least
one CN without detaching (A) then it will be able to keep the attack
as long as needed. Note that this attack becomes easier if the MN
does not have to periodically repeat the RR procedure as a result of
establishing a long lifetime security association with the CN, e.g.,
when the enhanced RO mode ([ERO]) is used.
Haddad, et al. Expires January 15, 2009 [Page 10]
Internet-Draft MIPv6 Residual Threats July 2008
5. Exploiting Neighbor Discovery in a MIPv6 Environment
Note: It may be asserted that this attack is related to Neighbor
Discovery Protocol (described in [NDP]). However, our main goal is
to convey a description about its potential which may go well beyond
the local link when applied in a MIPv6 context.
This threat offers a malicious node two edges. It requires first
that the attacker be attached to the same foreign link as the MN, and
the discovery of the MN's home agent IP address as well as the MN's
IP home address (which may not pose a serious problem). After
learning these two information, the attacker advertises the MN's home
prefix on the link thus leading the MN to believe that it has
returned to its home network. Such information will prompt the MN to
send a BU message to its HA to request de-registration. However,
such early de-registration may not be possible as the foreign network
may have activated ingress filtering. But the main goal for the
attacker is to get a valid copy of the MN's BU message and such goal
is achieved. If the malicious node concludes that the MN is still
receiving data packets tunneled by the HA to its current CoA, then it
will get involved in the MN de-registeration procedure by forwarding
the BU message to the MN's HA on another interface where ingress
filtering is not activated (i.e., under the assumption that the
attacker is multihomed). Upon receiving the BU message, the HA will
de-register the MN and stops tunneling data packets to the MN's CoA.
In addition, the HA sends back a BA message which will never reach
the MN. From that moment, the data traffic sent by the CN(s) stops
at the MN's home network. However, the lack of ACK messages sent by
the MN will prompt the CN(s) at some point to halt sending data
traffic and eventually tear down the session(s).
However, the situation gets worse if the malicious node decides to
push further in his attack by sending fake ACK messages to the CN(s),
i.e., using the MN's home address. In such situation, the CN(s) will
keep sending data traffic to the MN's HA (where they eventually get
discarded) and thus, may cause severe disruption within the home
access network, possibly leading to a network flooding attack in some
specific topologies.
Note that as they may be more than one MN attached to the same
foreign link and using the same home prefix, such attack may lead to
collective de-registration.
Haddad, et al. Expires January 15, 2009 [Page 11]
Internet-Draft MIPv6 Residual Threats July 2008
6. Security Considerations
This document is about security analysis of some specific parts in
the MIPv6 protocol.
Haddad, et al. Expires January 15, 2009 [Page 12]
Internet-Draft MIPv6 Residual Threats July 2008
7. References
7.1. Normative References
[ERO] Vogt, C., Arkko, J., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, June 2006.
[GPT6] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6", RFC 2473, December 1998.
[INGRESS] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP
Source Address Spoofing", RFC 2827, May 2000.
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
for IPv6", RFC 3775, June 2004.
[MROD] Nikander, P., Arkko, J., Aura, T., and E. Nordmark,
"Mobile IPv6 version 6 Route Optimization Security Design
Background", RFC 4225, December 2005.
[NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
7.2. Informative References
[MCoA] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli,
"Multiple Care-of Addresses Registration", Internet
Draft, draft-ietf-monami6-multiplecoa-08.txt, May 2008.
[Multih_Sec]
Lim, B., Ng, C., and K. Aso, "Verification of Care-of
Addresses in Multiple Bindings Registration", Internet
Draft, draft-lim-mext-multiple-coa-verify-01.txt,
February 2008.
Haddad, et al. Expires January 15, 2009 [Page 13]
Internet-Draft MIPv6 Residual Threats July 2008
Authors' Addresses
Wassim Haddad
Qualcomm
500 Somerset Corporate Blvd
Bridgewater, New Jersey 08807
US
Phone: +908 938 5027
Email: whaddad@qualcomm.com
Georges Tsirtsis
Qualcomm
London
UK
Phone: +908 443 8174
Email: tsirtsis@qualcomm.com
Benjamin Lim
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: +65 65505478
Email: benjamin.limck@sg.panasonic.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900
Email: Suresh.Krishnan@ericsson.com
Francis Dupont
ISC
Rennes
France
Email: Francis.Dupont@fdupont.fr
Haddad, et al. Expires January 15, 2009 [Page 14]
Internet-Draft MIPv6 Residual Threats July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Haddad, et al. Expires January 15, 2009 [Page 15]