Internet Draft A. Petrescu
Document: draft-petrescu-nemo-threats-00.txt A. Olivereau
Expires: May 2004 C. Janneteau
H.-Y. Lach
Motorola
November 2003
Threats for Basic Network Mobility Support (NEMO threats)
<draft-petrescu-nemo-threats-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes security threats related to the network
mobility base protocol (NEMO). It does not present threats of
Mobile IPv6. The communication between MR and HA, as well as the
forwarding information at HA and nested mobility configurations are
considered to be the main sensitive points of the protocol.
Existing tools of Mobile IPv6 protection between MN and HA (IPsec),
dynamic routing protocol authentication, NEMO prefix table and
ingress filtering checks at HA are presented as potential help
defending against threats.
Petrescu et al. Expires May 2004 [Page i]
INTERNET-DRAFT Mobile Networks Threats November 2003
Table of Contents
Status of this Memo................................................i
Abstract...........................................................i
Conventions Used in this Document..................................1
1. Introduction and Overview.......................................1
2. Interactions between MR and HA..................................2
3. Interactions between several MR's of same HA....................4
4. Forwarding Information Updates at HA............................4
5. Nested Mobility.................................................5
6. Other Threats...................................................5
Acknowledgements...................................................5
References.........................................................5
Changes............................................................6
Copyright Notice...................................................7
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 RFC-2119 [2].
1. Introduction and Overview
The Network Mobility base protocol [4] describes means for a Mobile
Router using Mobile IPv6 [5] to offer continuous connectivity for a
set of hosts and routers inside a moving network, to the Internet.
A moving network has a relatively stable internal IP structure and
will usually not transit traffic.
Documents desribing protocols are supposed to contain a Security
Section [9][11]. Section 8 of the NEMO base protocol is such a
section. It contains briefly outlined guidelines on the methods to
use to offer a relatively high level of security (IPsec, HA ingress
filtering and some routing protocol verifications indications).
This document tries to illustrate some of the thoughts that were
used as initial threat model for the respective Security
Considerations section.
A Mobile Router implements most functionalities of a Mobile IPv6
Mobile Host with the notable additions of the BU R-bit management
and NEMO-specific modes (implicit, explicit network , explicit
prefix len). A NEMO Home Agent implements most functionalities of
a Mobile IPv6 HA with the notable additions of BU R-bit management,
the three previously mentioned modes and, additionally,
interactions with its forwarding information (routing table)
management.
A new mobility behaviour introduced by NEMO with respect to Mobile
IPv6 mobility is the "nested" configuration, in which two moving
networks served by different Mobile Routers (each with its own Home
Agent) attach one under the other. A simpler case of nested
Petrescu et al. Expires May 2004 [Page 1]
INTERNET-DRAFT Mobile Networks Threats November 2003
mobility appears when one Mobile Host visits a moving network (MH
and MR having different Home Agents).
While Route Optimization is currently an integral part of the
Mobile IPv6 specification for Mobile Hosts, it is not a part of the
behaviour of a Mobile Router or of that of a NEMO Home Agent.
Thus, this document describes security threats that pertain to: (1)
interactions between MR and its HA, (2) interactions between
several MR's served by same HA, (3) threats relating to forwarding
information updates at HA and, finally and (4) threats related to
nested mobility. For the described threats, suggestions are given
for possible tools.
This document does not describe threats relating to Route
Optimization for moving networks, nor threats relating to Mobile
IPv6 for hosts, nor other mobility-related threats whose solutions
are described by PANA, AAA and SEND Working Groups. For threats
relating to Mobile IPv6 for Mobile Hosts, reader is kindly referred
to [7], [1]. For threats relating to access granting and control,
or threats of IPv6 behaviour on same-link, please see the above
mentioned Working Groups documents. For threats on the routing
protocol (eventually used between MR and HA) see [3].
A similar document attempting to describe threats in the NEMO
context is [6].
The current network mobility base specification specifies that all
signaling messages between the Mobile Router and the Home Agent
MUST be authenticated by IPsec. The use of IPsec to protect Mobile
IPv6 signaling messages is described in detail in the HA-MN IPsec
specification [1]. Using AH and/or ESP between MR and HA is of
paramount importance in order to protect against a wide range of
threats. However, other means of protecting communication between
MR and HA might be useful in certain cases. A good overview of
authentication mechanisms in the Internet can be found in [10].
2. Interactions between MR and HA
T.1 Confidentiality threat: the payload of all IPv6 packets between
LFN and CN is encapsulated inside the bidirectional tunnel between
MR and HA. An attacker placed in the path between LFN and CN might
have visibility over all this traffic. But, if the encapsulating
tunnel uses ESP tunnel mode, payload is encrypted, thus hidden.
T.2 Authentication threat: the same attacker might modify the
payload of data between LFN and CN. But if AH is used, payload is
authenticated, thus impossible to modify without LFN and CN
noticing it.
Both the above mentioned threats are particular exemplifications
with a NEMO terminology, but they are, of course, highly generic
threats to computer communications; the purpose of translating into
a NEMO terminology is to illustrate just that, and stress that
IPsec is a useful protection tool.
Petrescu et al. Expires May 2004 [Page 2]
INTERNET-DRAFT Mobile Networks Threats November 2003
T.3 Threat on switching between modes: MR sends BU in implicit mode
to HA, HA replies back positively, using MNP from external means
(not from BU). During this time, the attacker gained knowledge of
the MR's Home Address, sends BU to HA in explicit mode for the same
Home Address but a MNP specified in the BU, different than what HA
already has. HA replies back positively to MR and switches to
explicit mode and a different MNP. Threat is DoS: tunneling data
between MR and HA stops, MR is in implicit mode while HA in
explicit mode. IPsec helps protecting against this behaviour in
that HA will drop the attacker's BU because it does not positively
authenticate the attacker (if ESP + auth is used).
The description of this threat started with MR using implicit mode
and attacker trying explicit mode. The description applies equally
well if the initial step was in explicit mode and second step used
explicit mode.
T.4 Masquerading for Denial-of-Service: when attacker needs to send
an unreasonably large amount of IP packets to a target without risk
of his current address being identified, it could do so by two
means. First, it would set the src address of the packets to
another address, at random (thus "spoofing" a legitimate address,
or "masquerading" as that address). However, the first-hop router
might forbid forwarding packets whose source address are not
topologically correct at that particular router (ingress
filtering). Second, if ingress filtering at the access router is
in place, the MH might first encapsulate towards HA, thus tricking
the access router; HA decapsulates and "bombs" the actual target by
using MH's Home Address as source address. However, the ingress
filtering technique is used at the HA as well; Mobile IPv6 requires
HA of MH to only forward those packets from MH if the src address
of the outer header to match a Care-of Address entry in the BC and
the src address in the inner header to match the home address field
of the same entry. The NEMO base specification offers further help
by requiring the Home Address to match a Mobile Network Prefix
owned by the Mobile Router. If is obvious that this threat applies
to Mobile IPv6 for Mobile Hosts and, where Mobile IPv6 for Mobile
Hosts offers protection, it automatically offers protection for
Mobile Routers as well.
T.5 Threat on location privacy: it is not immediately clear to
authors whether location privacy can be qualified as a NEMO
security threat per se or as a particular aspect of open
communications in mobile environments.
Location privacy is the desire of a Mobile Host to not reveal, or
hide, its current association Care-of Address (its location) - Home
Address (its permanent identifier) from an attacker listening on
the path between MH and HA. It is not a desire to hide only one
address, but the association. It might constitute a problem in
that attacker may have visibility over the Home Address and the
Care-of Address of a Binding Update or Binding Acknowledgement
between MR and HA even if ESP is used (ESP does not cover the first
40 bytes of the IPv6 header of the BU whose src field contains the
CoA, nor the DO0 or RT headers that might contain the Home
Address).
Petrescu et al. Expires May 2004 [Page 3]
INTERNET-DRAFT Mobile Networks Threats November 2003
In the context of NEMO, if MR and HA do not use ESP protection, it
is possible for an attacker to discover information about the LFN's
Home Address, MR's Care-of Address and MR's Home Address. With
this information, attacker has a triplet giving information about
localization of MR and, implicitely, LFN. However, if MR and HA
use ESP, then all traffic to/from LFN is invisible to attacker who
can not find out the Home Address of LFN. Thus, even if location
privacy might be considered as a security threat, it is mostly a
problem of Mobile IPv6 for Mobile Hosts.
3. Interactions between several MR's of same HA
T.6 DoS threat on peer MR by attacker spoofing a legitimate MR's
Home Address: This particular threat applies equally well to Mobile
IPv6 for hosts: an attacker MH may demand the HA (with which it
holds an SA) to insert a BC entry of its CoA towards the Home
Address of a legitimate MH, even if both MH's have respective SA's
with that HA. If this threat is solved by Mobile IPv6 for hosts,
the method specified by Mobile IPv6 could possibly be reused by
NEMO base support too.[should be checked]
This threat applies in the NEMO context as follows: consider a
legitimate MR with prefix MNP and an attacker MR with a different
prefix, both served by the same HA. Each MR shares a set of keys
with HA, and SA's linking the respective Home Addresses and the HA
address. The attacker MR could instruct the HA to add MNP in the
binding cache, relating it to its own Home Address (instead of to
the legitimate MR's Home Address), thus effectively denying service
to the legitimate MR and redirecting the entire traffic to MNP
towards the attacker MR. Even if HA uses IPsec, it could not
protect against attacker MR's claiming the legitimate MR's MNP.
However, the prefix table specified by NEMO base protocol
associates a MR's Home Address to the MNP that it owns, thus
constituting a means for MR to check against attacker MR claiming a
prefix it does not actually own.
4. Forwarding Information Updates at HA
How current routing protocols routers authentify each other, how
they lack a concept of "prefix ownership" (see the "address
ownership problem" [8]). How the prefix table might help with
this. How routing protocols authentication could be interpreted to
solve the potential "prefix ownership" problem. The use of the
prefix table to help authorizing the injection of route updates is
different than the use of the same prefix table in explicit mode in
order to authorize insertion of bindings (in NEMO explicit mode),
as presented in threat T.6.
The current base NEMO specification contains:
When the Mobile Router is running a dynamic routing protocol as
described in section 7, it injects routing update messages into
the Home Link. The Home Agent MUST verify that the Mobile
Router is allowed to send routing updates before processing the
messages and propagating the routing information.
Petrescu et al. Expires May 2004 [Page 4]
INTERNET-DRAFT Mobile Networks Threats November 2003
5. Nested Mobility
T.8 DoS threat on TLMR due to too many levels of nested networks:
several moving networks may attach one under the other forming a
nested aggregation of moving networks ("levels" can be pictured as
follows: first MR attached under TLMR makes it for a one-level
aggregation of moving networks; a second MR attached under TLMR is
still a one-level aggregation; were the second MR attached under
the first MR, it would have been a two-level aggregation).
Naturally, the top-level MR will forward traffic of all moving
networks attached under it. When the number of levels is large,
this may become an overload on the initial expectations of the
capabilities of this Mobile Router (overload in the form of more
cycles dedicated to IPv6 Fragmentation and Reassembly, as well as
Path MTU calculations), thus becoming a DoS attack.
It is thus possible for MR to need to limit the number of levels of
moving networks nesting under it; it could use the Tunnel
Encapsulation option by setting a limit on the number of levels of
mobile networks below it.
Nested mobility configurations appear also when Mobile Hosts visit
mobile networks. However, all Mobile Hosts will always attach to a
same level; given a mobile network, it is not possible to build a
more than one-level nested aggregation only by adding Mobile Hosts
(MH's don't attach one under the other). Thus, the above mentioned
threat of nested configurations is pertinent to nested moving
networks exclusively.
6. Other Threats
Other threats might exist.
Acknowledgements
Threats related to network mobility have been discussed on the NEMO
list, whose members are acknowledged here.
References
[1] Arkko, J., Devarapalli, V. and Dupont, F., "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents" (work in progress). Internet Draft, IETF.
draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. June 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Barbir, A., Murphy, S. and Yang, Y., "Generic Threats to Routing
Protocols". Internet Draft, IETF.
draft-ietf-rpsec-routing-threats-02. August 2003.
Petrescu et al. Expires May 2004 [Page 5]
INTERNET-DRAFT Mobile Networks Threats November 2003
[4] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P.,
"Nemo Basic Support Protocol" (work in progress). Internet
Draft, IETF. draft-ietf-nemo-basic-support-01.txt. September
2003.
[5] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in
IPv6" (work in progress). Internet Draft,
IETF. draft-ietf-mobileip-ipv6-24.txt. June 2003.
[6] Jung, S., Zhao, F., Wu, F., Kim, H. and Sohn, S., "Threat
Analysis for NEMO" (work in progress). Internet Draft, IETF.
draft-jung-nemo-threat-analysis-01.txt. October 2003.
[7] Nikander, P., Harkins, D., Patil, B., Roberts, P., Nordmark,
E. and Makin, A., "Threat Models introduced by Mobile IPv6 and
Requirements for Security in Mobile IPv6" (work in progress).
Internet Draft, IETF.
draft-team-mobileip-mipv6-sec-reqts-00.txt. December 2001.
[8] Nikander, P., "An Address Ownership Problem in IPv6" (work in
progress). Internet Draft, IETF.
draft-nikander-ipng-address-ownership-00.txt. February 2001.
[9] Postel, J. and Reynolds, J., "Instructions to RFC Authors", RFC
2223, October 1997.
[10] Rescorla, E., "A Survey of Authentication Mechanisms" (work in
progress). Internet Draft, IETF.
draft-rescorla-auth-mech-02.txt. October 2003.
[11] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text
on Security Considerations", BCP 72, RFC 3552, July 2003.
[12] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000.
Changes
November 2003: revision 00 submitted.
Authors' Addresses
Alexandru Petrescu Christophe Janneteau
Motorola Labs Motorola Labs
Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin
Gif-sur-Yvette 91193 Gif-sur-Yvette 91193
France France
Phone: +33 1 69354827 Phone: +33 1 69352548
Alexandru.Petrescu@motorola.com Christophe.Janneteau@motorola.com
Alexis Olivereau Hong-Yon Lach
Motorola Labs Motorola Labs
Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin
Gif-sur-Yvette 91193 Gif-sur-Yvette 91193
France France
Phone: +33 1 69352516 Phone: +33 1 69352536
Alexis@motorola.com Hong-Yon.Lach@motorola.com
Petrescu et al. Expires May 2004 [Page 6]
INTERNET-DRAFT Mobile Networks Threats November 2003
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Funding for the RFC editor function is currently provided by the
Internet Society.
Petrescu et al. Expires May 2004 [Page 7]