Mobility Extensions W. Haddad
Internet-Draft ...
Intended status: Informational G. Tsirtsis
Expires: August 21, 2008 Qualcomm
B. Lim
Panasonic
S. Krishnan
Ericsson Research
February 18, 2008
Mobile IPv6 Residual Threats
draft-haddad-mext-mip6-residual-threats-00
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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Haddad, et al. Expires August 21, 2008 [Page 1]
Internet-Draft MIPv6 Residual Threats February 2008
Abstract
This memo aims to highlight specific residual threats in the Mobile
IPv6 design. These threats are inherited in the design of new
mechanisms built on top of the mobility protocol, and are raising
concerns regarding the amplitude of their potential impacts.
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 . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Haddad, et al. Expires August 21, 2008 [Page 2]
Internet-Draft MIPv6 Residual Threats February 2008
1. Introduction
The design of Mobile IPv6 protocol (described in [MIPv6]) did not
address a set of specific threats for various reasons. In fact,
these residual threats were (rightly or not) not considered of equal
importance than others which required immediate action. However, as
these threats are implicitely inherited in the design of new
mechanisms built on top of MIPv6, their potential impact is raising
some concerns.
This memo aims to describe these residual threats and to motivate
designers to take a fresh look at the reasoning behind leaving them
in an unconvincing state and to address them in case it is needed.
Haddad, et al. Expires August 21, 2008 [Page 3]
Internet-Draft MIPv6 Residual Threats February 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 August 21, 2008 [Page 4]
Internet-Draft MIPv6 Residual Threats February 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 that guided MIPv6 protocol design was based on two
main assumptions. The first one considers that the mobile node (MN)
will always refrain from misusing the relationship with its home
agent (HA). It follows that the HA can always blindly accept any
information sent by the MN. Thus, the second assumption requests the
HA to accept any new care-of address(es) (CoA(s)) claimed by the MN
and sent in a valid binding update (BU) message(s).
The justification behind the first assumption is the tracing ability
that the HA is supposed to always acquire over the MN. In other
words, the MN is always supposed to fear being traced -as the target
is also supposed to complain- thus, refrain from misusing a mutual
trust which can appear now as being "imposed" on both nodes. We
argue that such assumption is too naive when applied in the real
world as it is simply impossible to back it with a solid proof that
confirm the existence of enough anxiety to deter all potential
attackers from launching malicious act in such particular context.
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 network flooding attack against any potential target by
simply claiming a new CoA which is topologically located within the
targeted network. This is especially possible when only the
bidirectional tunneling (BT) mode is used and/or when the enhanced
route optimization mode (described in [ERO]) is in use. Without
testing the new CoA reachability, the HA will simply re-route data
packets to the new CoA, i.e., targeted network, and the MN can keep
sending acknowledgment 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 as it has been well analyzed in [MROD] and its effects on the
targeted network are mitigated by imposing a periodic return
routability procedure.
Moreover, as MIPv6 is acquiring many extensions, such attack on the
HA side may get amplified with the MN's ability to register multiple
CoAs with the HA. Such scenario is better described in [Multih_Sec].
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
Haddad, et al. Expires August 21, 2008 [Page 5]
Internet-Draft MIPv6 Residual Threats February 2008
MN is only able to bind a single '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 'blindly' accept any binding that the MN
makes. 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 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).
However, such a trust is no longer valid when the MN utilizes a
single BU message to register its multiple CoAs at its HA. This
technique is explained in [MCoA] with the aim of introducing some
optimization when registering multiple CoAs for a MN. Such
optimization technique is useful in scenarios when resources (e.g.
bandwidth) are scarce on some of the MN's interfaces, since it allows
the MN to send a BU message containing multiple CoAs to its HA from
an interface that does not have such resource constraint. Moreover,
in MIPv6, the use of the alternate CoA option permits the MN to
achieve the same effect of registering a CoA for another interface
via a specific interface. This introduces the risk of having 'fake'
CoAs registered at the HA and compromise the security of the network.
If these 'fake' CoAs are IP addresses of other MNs, it is possible
for the malicious MN to instruct the HA to re-direct traffic towards
these 'fake' CoAs, thereby flooding these MNs with useless traffic.
With such a threat towards the network, some mechanism might be need
in order for the HA to verify the CoA for the MN prior to binding or
using them for packet routing.
Haddad, et al. Expires August 21, 2008 [Page 6]
Internet-Draft MIPv6 Residual Threats February 2008
4. Security Considerations
This document is about security threats on Mobile IPv6 protocol.
Haddad, et al. Expires August 21, 2008 [Page 7]
Internet-Draft MIPv6 Residual Threats February 2008
5. References
5.1. Normative References
[ERO] Vogt, C., Arkko, J., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, June 2006.
[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.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
5.2. Informative References
[MCoA] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli,
"Multiple Care-of Addresses Registration", Internet
Draft, draft-ietf-monami6-multiplecoa-05.txt,
January 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-00.txt,
November 2007.
Haddad, et al. Expires August 21, 2008 [Page 8]
Internet-Draft MIPv6 Residual Threats February 2008
Authors' Addresses
Wassim Haddad
...
Email: wmhaddad@gmail.com
Georges Tsirtsis
Qualcomm
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 Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900
Email: Suresh.Krishnan@ericsson.com
Haddad, et al. Expires August 21, 2008 [Page 9]
Internet-Draft MIPv6 Residual Threats February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Haddad, et al. Expires August 21, 2008 [Page 10]