Internet Draft A. Petrescu
Document: draft-petrescu-nemo-threats-xx.txt A. Olivereau
Expires: July 2004 C. Janneteau
H.-Y. Lach
Motorola
January 2004
Threats for Basic Network Mobility Support (NEMO threats)
<draft-petrescu-nemo-threats-01.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). Threats of Mobile IPv6 for Mobile
Hosts are only briefly touched when in need of support of related
NEMO threats. The NEMO signalling 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 MH and HA (IPsec),
dynamic routing protocol authentication, NEMO prefix table, ingress
filtering checks at HA and tunnel encapsulation limiting are
presented as protocol features affording protection against
threats. NEMO threats for which there are no protections are
briefly mentioned.
Petrescu et al. Expires July 2004 [Page i]
INTERNET-DRAFT Mobile Networks Threats January 2004
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..................................4
3. Interactions between several MR's of same HA....................7
4. Forwarding Information Updates at HA............................7
5. Nested Mobility.................................................8
6. Other Threats...................................................8
Acknowledgements...................................................8
A. IPsec Architecture for Nested Mobility..........................8
B. IPsec Protection of Binding Updates and Acknowledgements.......10
C. IPsec non-Protection of Home Agent Discovery Messaging.........18
References........................................................19
Changes...........................................................21
Copyright Notice..................................................22
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].
In addition to the NEMO terminology [5], four additional terms were
useful for descriptions within this document.
Binding Update: an IPv6 datagram that contains a Mobility Header
whose MH Type field is 0x5; it is sent by a Mobile
Node to its Home Agent.
Binding Acknowledgement: an IPv6 datagram that contains a Mobility
Header whose MH Type field is 0x6; it is
sent by a Home Agent in response to a
Binding Update received from a Mobile
Node.
Mobile Security Gateway: an entity acting simultaneously as a NEMO
Mobile Router and as an IPsec Security
Gateway.
Home Security Gateway: an entity acting simultaneously as a NEMO
Home Agent and as an IPsec Security Gateway.
1. Introduction and Overview
The Network Mobility base protocol [4] describes means for a Mobile
Router using Mobile IPv6 [8] to offer continuous connectivity for a
set of hosts and routers within a moving network, to the Internet.
A moving network has a relatively stable internal IP structure and
will usually not transit traffic. The Mobile Router is part of the
moving network and moves together with all nodes of it.
Petrescu et al. Expires July 2004 [Page 1]
INTERNET-DRAFT Mobile Networks Threats January 2004
Documents desribing protocols should contain a Security Section
[18][20]. 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 routing protocol verifications indications).
This document presents the characteristics of the initial threat
model that was used as basis for developping the respective
Security Considerations section.
A Mobile Router implements most functionalities of a Mobile IPv6
Mobile Host [8]. Notable additions include the R-bit management
and NEMO-specific modes (implicit and explicit). A NEMO Home Agent
implements most functionalities of a Mobile IPv6 HA with the the
additions of R-bit management, the two modes and, additionally,
interactions with its forwarding information (routing table)
management. There are no new messages introduced by the base NEMO
document [4] when compared to Mobile IPv6 [8]. The modified
messages are: Binding Update, Binding Acknowledgement, Home Agent
Discovery Request and Home Agent Discovery Reply. New R-bit fields
have been included in the Binding Update and the Home Agent
Discovery Request and Reply; a new MNP field has been introduced in
the Binding Update; the Status field of a Binding Acknowledgement
contains new values.
A new mobility configuration 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 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.
Another document attempting to describe threats in the NEMO context
is [9].
This document avoids description of threats relating to Route
Optimization for moving networks, to Mobile IPv6 for Mobile Hosts,
to multihoming for moving networks; other generic mobility threats
exist whose solutions are proposed by PANA, AAA and SEND Working
Groups. For threats relating to Mobile IPv6 for Mobile Hosts,
reader is referred to section 15.1 of [8], to [1] and [16]. For
threats relating to access granting and control, or threats of IPv6
behaviour on same link, please see the above mentioned Working
Group documents. For threats on the routing protocol (eventually
used between MR and HA) see [3].
Petrescu et al. Expires July 2004 [Page 2]
INTERNET-DRAFT Mobile Networks Threats January 2004
The current network mobility base specification [4] requires 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
attacks.
The Internet IPsec architecture can be particularized for Mobile
Routers by distinguishing two cases: (1) IPsec protection in
transport mode for NEMO signalling and (2) IPsec protection in
tunnel mode for NEMO traffic between LFN and CN.
AH/ESP used in transport mode for NEMO signalling protects Binding
Updates, Binding Acknowledgements (but does not protect Home Agent
Address Discovery Requests and Home Agent Address Discovery
Replies). They are exchanged between the Mobile Router (Mobile
Security Gateway) and Home Agent (Home Security Gateway):
+--------+ +--------+
| Mobile | AH/ESP transport mode | Home |
| Sec GW |========================| Sec GW |
| (MR) | | (HA) |
+--------+ +--------+
AH/ESP used in tunnel mode for NEMO traffic protects all fields of
all IP datagrams exchanged between LFN and CN, including
application-level data:
+--------+ AH/ESP tunnel mode +--------+
+-----+ | Mobile |________________________| Home | +----+
| LFN |.....| Sec GW |........................| Sec GW |.....| CN |
+-----+ | (MR) |------------------------| (HA) | +----+
+--------+ +--------+
This IPsec architecture for moving networks can be extended to
nested network mobility configurations, by means of encapsulating
tunneling. See section A for illustrations of IPsec for nested
mobility.
Other means of protecting communication between MR and HA are
needed in certain cases; they include the use of the NEMO Prefix
Table, the prefix-extended ingress filtering technique [6] used by
the NEMO Home Agent and the tunnel encapsulation limiting. If
further additional tools are needed, a good overview of
authentication mechanisms in the Internet can be found in [19].
Last but not least, even if IPsec, ingress filtering, Prefix Table
and tunnel encapsulation limiting are used, we acknowledge the
existence of other security risks with the NEMO base protocol.
They stem mainly from the lack of certain security features of the
underlying Mobile IPv6 protoocol. For example: attacks on the R
bit within the Home Agent Discovery messaging, and location privacy
risks.
Petrescu et al. Expires July 2004 [Page 3]
INTERNET-DRAFT Mobile Networks Threats January 2004
2. Interactions between MR and HA
T.1 Threat on the MNP field (redirection threat): the simplest and
most important (but avoidable) threat of the NEMO basic support
protocol is the redirection of traffic of all addresses within a
Mobile Network Prefix. An attacker sending an un-protected NEMO
Binding Update to a Home Agent for a certain MNP is actually
instructing that Home Agent to forward all traffic for MNP towards
the address of the attacker. The gravity of the risk is more
important than in the case of Mobile Hosts; an attacker Mobile Host
could re-direct only one legitimate Home Address, while with NEMO
an attacker MR could re-direct all the addresses within an MNP.
Moreover, the risk is all the more important since attacker MR can
be positioned anywhere in the Internet, NEMO is not restrained to a
closed system. In order to avoid this risk actually realizing, it
is important to protect all signalling messages between MR and HA
by IPsec (this is also required by [1] and [8]). In general, if HA
uses AH/ESP transport mode for all NEMO signalling with the
legitimate MR then attacker MR is not able to realize such a
re-direction attack, because AH/ESP in transport mode covers the
MNP field of the BU.
T.2 Threat on the R bit of BU: An attacker Mobile Host asks its
Home Agent to forward all traffic addressed to addresses within MNP
to its current Care-of Address. Normally, Mobile Hosts do not send
the R-bit in the Binding Update. An attacker Mobile Host can
specify the R-bit and thus receiving traffic addressed to other
addresses than simply to its Home Address. However, if IPsec is
used, the R-bit in the BU is covered both by AH and ESP in
transport mode, so if HA and MH have a trust relationship it is
assumed that MH will not specify the R bit.
T.3 Threat on the Status field of BAck: an attacker entity on the
path between legitimate MR and HA modifies the Status field of the
Binding Acknowledgement sent by the HA to MR. It is assumed that
MR has previously sent a BU to HA with the R-bit set and that HA
replied with Status 140 (Mobile Router Operation not Permitted).
The attacker entity substitutes 141 (Invalid Prefix) for 140 and
thus leads MR into re-sending Binding Updates to Home Agent
(instead of stopping sending Binding Updates). However, the AH/ESP
headers cover the Status field of the BAck and thus attacker can
not tamper with the Status field, invalidating this threat.
T.4 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 two-fold: on one hand
HA would stop forwarding packets of the legitimate MNP towards the
legitimate MR; on the other hand HA would start forwarding packets
of a false MNP towards the legitimate MR.
Petrescu et al. Expires July 2004 [Page 4]
INTERNET-DRAFT Mobile Networks Threats January 2004
IPsec can not help protecting against attacker MR obtaining the
Home Address of the legitimate MR (it is not covered by ESP when
legitimate MR sends BU or receives BAck). However, IPsec can
protect against the attacker MR specifying an illegitimate MNP
within a BU; the MNP field in the BU is covered by ESP in transport
mode.
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
implicit mode.
T.5 Threat on the R bit of Home Agent Discovery Request: an
attacker on the path between legitimate MR and HA transforms the R
bit from 1 to 0. The Home Agents thus receive a request for
non-NEMO Home Agents and will not set the R bit in the Reply
message. Thus the MR is led into believing there is no HA on the
home link supporting Mobile Routers. IPsec does not protect
against this threat since the Home Agent Address Discovery Request
is not protected neither by AH nor by ESP headers.
T.6 Threat on the R bit of Home Agent Discovery Reply: an attacker
entity on the path between legitimate MR and HA transforms the R
bit from 1 to 0. It is assumed that, initially, the MR has sent a
Home Agent Address Discovery message to the home network with the
R-bit set, thus requesting responses from HA's that support Mobile
Routers; it is also assumed that the HA replied a legitimate Reply
containing the R bit set. The effect of this threat is that MR is
falsely led into believing that no HA on the home network can
support Mobile Routers. IPsec does not protect against this threat
since the Home Agent Address Discovery Reply is not protected
neither by AH nor by ESP headers.
T.7 Threat of address spoofing: 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
[6]). 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.
Petrescu et al. Expires July 2004 [Page 5]
INTERNET-DRAFT Mobile Networks Threats January 2004
T.8 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 risk of open
communications in mobile environments.]
In the context of Mobile Hosts (not Mobile Routers), location
privacy represents 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 is sufficient for an attacker
wishing to find the current location of a victim Mobile Host to
snoop traffic between the victim and its Home Agent. When the
Mobile Host changes its location and updates the Home Agent, a pair
of Binding Update/Acknowledgement messages is communicated. An
attacker on the path can find the association Home Address -
Care-of Address of the Mobile Host, even if AH and/or ESP headers
are used to protect the two packets. Both AH and ESP for Binding
Updates and Acknowledgements are used in transport mode (not tunnel
mode), thus the base header (containing the Care-of Address and the
Home Agent address), the Destination Options header and the Routing
Header Type 2 (containing the Home Address) are transmitted in
clear (but message integrity, and implicitely integrity of the Home
Address and the Care-of Address, is afforded by AH), see section
B.6.
In the context of NEMO, the location privacy can be described as
the desire of a Local Fixed Node within a moving network to not
reveal, or hide, the location triplet LFN Home Address - MR Care-of
Address - MR Home Address. An attacker outside the moving network
and on the path between the Mobile Router and its Home Agent could
snoop packets. If the bidirectional tunnel between the Mobile
Router and its Home Agent is not protected by ESP, then attacker
can find the LFN Home Address in the src field of the inner packet
sent by MR to HA and the MR Care-of Address in the src field of the
outer base header. The MR Home Address could have been obtained
from the Binding Update or the Binding Acknowledgement, as
described in the previous paragraph. In this way, attacker can
gain knowledge of the triplet LFN Home Address - MR Home Address -
MR Care-of Address. However, if MR uses ESP tunnel mode protection
for the bidirectional tunnel, then attacker has no means to gain
visibility of the LFN Home Address.
Thus, even if location privacy might be considered as a security
threat, it is mostly a risk for Mobile Hosts, and can not be
qualified as a NEMO risk; the association Home Address - Care-of
Address of a Mobile Host might be revealing location information
but the location triplet can not be revealed if ESP is used for
non-signaling traffic between MR and HA.
T.9 Threat on the Routing Header Type 2: attacker modifies the type
of the routing header type 2 of a Binding Acknowledgement sent by
HA to MR and substitues 0 for 2. In addition attacker may specify
a number of addresses within this fake type 0 routing header. The
risk is that attacker provokes bombing attacks and stays hidden
Petrescu et al. Expires July 2004 [Page 6]
INTERNET-DRAFT Mobile Networks Threats January 2004
(its address does not appear in the packet); it is the Home Agent's
and the Mobile Router's addresses that appear in the attack. The
risk is typically a Mobile IPv6 for hosts risk, but it is more
important in the case of Mobile Routers because Mobile Hosts are
not expected to implement routing header software, or are expected
to implement type 2 routing headers exclusively (for Mobile Hosts).
However, all routers (Mobile Routers included) are expected to
implement routing headers type 0, thus they are more at risk with
this threat. Protection against this risk is again offered by AH
which covers all fields of the Routing Header Type 2.
3. Interactions between several MR's of same HA
T.10 DoS threat on peer MR by attacker spoofing a legitimate MR's
Care-of Address. A similar threat exists in the case of Mobile
IPv6 for Mobile Hosts, but is less important than in the case of
NEMO.
In the context of Mobile IPv6 for Mobile Hosts, consider two Mobile
Hosts belonging to the same Home Agent; each MH is trusted by the
Home Agent (with IPsec). The victim MH and the attacker MH are
both visiting the same foreign network. The attacker MH reads the
Care-of Address of the victim from the Binding Update or
Acknowledgement that victim exchanges with HA. The attacker MH
sends Binding Update for the victim's CoA and its own Home Address.
Thus the HA will forward all traffic intended to attacker's Home
Address towards victim's Care-of Address, even though IPsec is
correctly being used.
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. 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" [17]). 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.x.
Petrescu et al. Expires July 2004 [Page 7]
INTERNET-DRAFT Mobile Networks Threats January 2004
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.
5. Nested Mobility
T.11 DoS threat on TLMR due to too many levels of nested networks:
several moving networks may attach one under the other thus 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 original 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 exist.
Acknowledgements
Threats related to network mobility have been discussed on the IETF
NEMO WG list, whose members are acknowledged here.
Seongho Cho provided significant feedback about several threats.
A. IPsec Architecture for Nested Mobility
The IPsec architecture can be particularized for nested mobility
cases by using nested encapsulation. In the figure below we
picture the protection of NEMO signalling between MR1 and its HA
(HA_MR1), when the moving network of MR1 is nesting within the
Petrescu et al. Expires July 2004 [Page 8]
INTERNET-DRAFT Mobile Networks Threats January 2004
moving network of MR2 (it is assumed that the MR2 has already
performed NEMO signalling with its own HA - HA_MR2). The first
level of IPsec protection is offered by the AH/ESP transport mode
between MR1 and HA_MR1 (1). The second level is offered by AH/ESP
tunnel mode between MR2 and HA_MR2 (2).
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
| Mobile | | Mobile |__2__| Home |___| Home |
| Sec GW |=1=| Sec GW |=====| Sec GW |===| Sec GW |
| (MR1) | | (MR2) |-----|(HA_MR2)|---|(HA_MR1)|
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
The IPsec protection of application-level traffic between LFN and
CN, when LFN belongs to a nested moving network is pictured below.
The first level of protection is offered by the AH/ESP tunnel mode
between MR1 and HA_MR1 while the second is offered by the AH/ESP
tunnel mode between MR2 and HA_MR2.
+--------+ +--------+ +--------+ +--------+
| | | |__2__| | | |
+-----+ | Mobile |_1_| Mobile |_____| Home |___| Home | +----+
| LFN |..| Sec GW |...| Sec GW |.....| Sec GW |...| Sec GW |..| CN |
+-----+ | (MR1) |---| (MR2) |-----|(HA_MR2)|---|(HA_MR1)| +----+
| | | |-----| | | |
+--------+ +--------+ +--------+ +--------+
A parcticular case of nested mobility configuration is the visit of
of a MH within a moving network. The signalling protection is
offered by AH/ESP in transport mode between MH and HA_MH (1) and by
AH/ESP offered by AH/ESP in tunnel mode between MR and HA_MR (2).
+--------+ +--------+ +-------+
+--+ | Mobile |___________2____________| Home | | |
|MH|===1====| Sec GW |========================| Sec GW |==| HA_MH |
+--+ | (MR) |------------------------| (HA_MR)| | |
+--------+ +--------+ +-------+
Still in the case of nested mobility of a MH within a moving
network, the application-level traffic between MH and CN is offered
a first level of protection by the AH/ESP tunnel mode between MH
and HA_MN (1) and a second level by the AH/ESP tunnell mode between
MR and HA_MR (2).
+--------+ +--------+ +-------+
+---+ | |_________2________| | | |
| |_1__| Mobile |__________________| Home |___| | +----+
|MH |....| Sec GW |..................| Sec GW |...| HA_MH |....| CN |
| |----| (MR) |------------------| (HA_MR)|---| | +----+
+---+ | |------------------| | | |
+--------+ +--------+ +-------+
Petrescu et al. Expires July 2004 [Page 9]
INTERNET-DRAFT Mobile Networks Threats January 2004
B. IPsec Protection of Binding Updates and Acknowledgements
In this section, we used the following NEMO messages for threat
analysis: Binding Update, Binding Acknowldegement. The following
fields have been considered as relevant for NEMO threat analysis:
-src and dst addresses in the base header.
-the Home Address in the Destination Options 0 header of the
Binding Update.
-the R bit in the AHLKR field of the Binding Update.
-the Prefix Len and Mobile Network Prefix fields in a Binding
Update sent in explicit mode.
-the Routing Type, Segments Left and Home Address fields in the
Routing Header Type 2 of the Binding Acknowledgement.
-the Status field of the Binding Acknowledgement.
In building the packet formats below, the following notation was
used:
*: NEMO field, or bit or value introduced by NEMO base protocol, or
containing helpful information for realization of the
NEMO-related risks described in this document.
x: authenticated field, as covered by AH ICV.
y: encrypted field, as part of ESP payload data.
z: authenticated field, as part of ESP authentication data.
For example, fields that are marked (*xyz) are helping realizing
threats, but are protected by AH and ESP non-NULL authentication,
thus rendering most NEMO threats impossible; fields that are only
marked (*) are not protected, thus might constitute security risks.
In the following sections, pairs consisting of a Binding Update and
the corresponging Binding Acknowledgement are illustrated. Each
section describes two pairs: the pair when MR is in a foreign
network followed by the pair when MR is returning to the home
network. Section B.1 presents unprotected pairs while section B.6
presents pairs protected both by AH and ESP in transport mode (ESP
with non-NULL authentication algorithm). Intermediary sections use
transport mode AH exclusively or transport mode ESP exclusively (ESP
with or without authentication algorithm).
Petrescu et al. Expires July 2004 [Page 10]
INTERNET-DRAFT Mobile Networks Threats January 2004
B.1 Unprotected BU and BAck when MR in foreign network
Base Header Base Header
src: CoA (*) src: Home Agent address (*)
dst: Home Agent address (*) dst: CoA (*)
Destination Options Routing Header
Home Address: Home Address (*) Routing Type: 2 (*)
Mobility Header Segments Left: 1 (*)
Header Len Home Address: Home Address (*)
MH Type: Mobility Header
Reserved: Header Len:
Checksum: MH Type:
Message Data Reserved:
Seq # Checksum:
AHLKR (*) Message Data
Lifetime: Status (*)
Mobility Options K:
Alternate CoA: CoA Reserved
Mobile Net Prefix Option Seq #:
Prefix Len: (*) Lifetime:
Mobile Net Prefix: (*) Mobility Options
Binding Refresh Advice
Refresh Interval:
Unprotected BU and BAck when MR returns home
Base Header Base Header
src: Home Address (*) src: Home Agent address (*)
dst: Home Agent address (*) dst: Home Address (*)
Mobility Header Mobility Header
Header Len Header Len:
MH Type: MH Type:
Reserved: Reserved:
Checksum: Checksum:
Message Data Message Data
Seq # Status (*)
AHLKR (*) K:
Lifetime: Reserved
Mobility Options Seq #:
Mobile Net Prefix Option Lifetime:
Prefix Len: (*) Mobility Options
Mobile Net Prefix: (*) Binding Refresh Advice
Refresh Interval:
Petrescu et al. Expires July 2004 [Page 11]
INTERNET-DRAFT Mobile Networks Threats January 2004
B.2 AH protected BU and BAck when MR in foreign network
Base Header Base Header
src: CoA (*x) src: Home Agent address (*x)
dst: Home Agent address (*x) dst: CoA (*x)
Destination Options Routing Header
Home Address: Home Address (*x) Routing Type: 2 (*x)
Authentication Header Segments Left: 1 (*x)
SPI: Home Address: Home Address(*x)
Seq No: Authentication Header
ICV: SPI:
Mobility Header Seq No:
Header Len ICV:
MH Type: Mobility Header
Reserved: Header Len:
Checksum: MH Type:
Message Data Reserved:
Seq # Checksum:
AHLKR (*x) Message Data
Lifetime: Status (*x)
Mobility Options K:
Alternate CoA: CoA Reserved
Mobile Net Prefix Option Seq #:
Prefix Len: (*x) Lifetime:
Mobile Net Prefix: (*x) Mobility Options
Binding Refresh Advice
Refresh Interval:
AH protected BU and BAck when MR returns home
Base Header Base Header
src: Home Address (*x) src: Home Agent address (*x)
dst: Home Agent address (*x) dst: Home Address (*x)
Authentication Header Authentication Header
SPI: SPI:
Seq No: Seq No:
ICV: ICV:
Mobility Header Mobility Header
Header Len Header Len:
MH Type: MH Type:
Reserved: Reserved:
Checksum: Checksum:
Message Data Message Data
Seq # Status (*x)
AHLKR (*x) K:
Lifetime: Reserved
Mobility Options Seq #:
Mobile Net Prefix Option Lifetime:
Prefix Len: (*x) Mobility Options
Mobile Net Prefix: (*x) Binding Refresh Advice
Refresh Interval:
Petrescu et al. Expires July 2004 [Page 12]
INTERNET-DRAFT Mobile Networks Threats January 2004
B.3 ESP NULL auth algo for BU and BAck when MR in foreign network
Base Header Base Header
src: CoA (*) src: Home Agent address (*)
dst: Home Agent address (*) dst: CoA (*)
Destination Options Routing Header
Home Address: Home Address (*) Routing Type: 2 (*)
ESP Header Segments Left: 1 (*)
SPI: Home Address: Home Address (*)
Seq No: ESP Header
Mobility Header SPI:
Header Len Seq No:
MH Type: Mobility Header
Reserved: Header Len:
Checksum: MH Type:
Message Data Reserved:
Seq # Checksum:
AHLKR (*y) Message Data
Lifetime: Status (*y)
Mobility Options K:
Alternate CoA: CoA Reserved
Mobile Net Prefix Option Seq #:
Prefix Len: (*y) Lifetime:
Mobile Net Prefix: (*y) Mobility Options
ESP Trailer Binding Refresh Advice
Refresh Interval:
ESP Trailer
ESP NULL auth algo for BU and BAck when MR returns home
Base Header Base Header
src: Home Address (*) src: Home Agent address (*)
dst: Home Agent address (*) dst: Home Address (*)
ESP Header ESP Header
SPI: SPI:
Seq No: Seq No:
Mobility Header Mobility Header
Header Len Header Len:
MH Type: MH Type:
Reserved: Reserved:
Checksum: Checksum:
Message Data Message Data
Seq # Status (*y)
AHLKR (*y) K:
Lifetime: Reserved
Mobility Options Seq #:
Mobile Net Prefix Option Lifetime:
Prefix Len: (*y) Mobility Options
Mobile Net Prefix: (*y) Binding Refresh Advice
ESP Trailer Refresh Interval:
ESP Trailer
Petrescu et al. Expires July 2004 [Page 13]
INTERNET-DRAFT Mobile Networks Threats January 2004
B.4 ESP non-NULL auth algo for BU and BAck when MR in foreign network
Base Header Base Header
src: CoA (*) src: Home Agent address (*)
dst: Home Agent address (*) dst: CoA (*)
Destination Options Routing Header
Home Address: Home Address (*) Routing Type: 2 (*)
ESP Header Segments Left: 1 (*)
SPI: Home Address: Home Address (*)
Seq No: ESP Header
Mobility Header SPI:
Header Len Seq No:
MH Type: Mobility Header
Reserved: Header Len:
Checksum: MH Type:
Message Data Reserved:
Seq # Checksum:
AHLKR (*yz) Message Data
Lifetime: Status (*yz)
Mobility Options K:
Alternate CoA: CoA Reserved
Mobile Net Prefix Option Seq #:
Prefix Len: (*yz) Lifetime:
Mobile Net Prefix: (*yz) Mobility Options
ESP Trailer Binding Refresh Advice
ESP Auth Refresh Interval:
ESP Trailer
ESP Auth
ESP non-NULL auth algo for BU and BAck when MR returns home
Base Header Base Header
src: Home Address (*) src: Home Agent address (*)
dst: Home Agent address (*) dst: Home Address (*)
ESP Header ESP Header
SPI: SPI:
Seq No: Seq No:
Mobility Header Mobility Header
Header Len Header Len:
MH Type: MH Type:
Reserved: Reserved:
Checksum: Checksum:
Message Data Message Data
Seq # Status (*yz)
AHLKR (*yz) K:
Lifetime: Reserved
Mobility Options Seq #:
Mobile Net Prefix Option Lifetime:
Prefix Len: (*yz) Mobility Options
Mobile Net Prefix: (*yz) Binding Refresh Advice
ESP Trailer Refresh Interval:
ESP Auth ESP Trailer
ESP Auth
Petrescu et al. Expires July 2004 [Page 14]
INTERNET-DRAFT Mobile Networks Threats January 2004
B.5 AH and ESP NULL for BU and BAck when MR in foreign network
Base Header Base Header
src: CoA (*x) src: Home Agent address (*x)
dst: Home Agent address (*x) dst: CoA (*x)
Destination Options Routing Header
Home Address: Home Address (*x) Routing Type: 2 (*x)
Authentication Header Segments Left: 1 (*x)
SPI: Home Address: Home Address(*x)
Seq No: Authentication Header
ICV: SPI:
ESP Header Seq No:
SPI: ICV:
Seq No: ESP Header
Mobility Header SPI:
Header Len Seq No:
MH Type: Mobility Header
Reserved: Header Len:
Checksum: MH Type:
Message Data Reserved:
Seq # Checksum:
AHLKR (*xy) Message Data
Lifetime: Status (*xy)
Mobility Options K:
Alternate CoA: CoA Reserved
Mobile Net Prefix Option Seq #:
Prefix Len: (*xy) Lifetime:
Mobile Net Prefix: (*xy) Mobility Options
ESP Trailer Binding Refresh Advice
Refresh Interval:
ESP Trailer
Petrescu et al. Expires July 2004 [Page 15]
INTERNET-DRAFT Mobile Networks Threats January 2004
AH and ESP NULL for BU and BAck when MR returns home
Base Header Base Header
src: Home Address (*x) src: Home Agent address (*x)
dst: Home Agent address (*x) dst: Home Address (*x)
Authentication Header Authentication Header
SPI: SPI:
Seq No: Seq No:
ICV: ICV:
ESP Header ESP Header
SPI: SPI:
Seq No: Seq No:
Mobility Header Mobility Header
Header Len Header Len:
MH Type: MH Type:
Reserved: Reserved:
Checksum: Checksum:
Message Data Message Data
Seq # Status (*xy)
AHLKR (*xy) K:
Lifetime: Reserved
Mobility Options Seq #:
Mobile Net Prefix Option Lifetime:
Prefix Len: (*xy) Mobility Options
Mobile Net Prefix: (*xy) Binding Refresh Advice
ESP Trailer Refresh Interval:
ESP Trailer
Petrescu et al. Expires July 2004 [Page 16]
INTERNET-DRAFT Mobile Networks Threats January 2004
B.6 AH and ESP non-NULL for BU and BAck when MR in foreign network
Base Header Base Header
src: CoA (*x) src: Home Agent address (*x)
dst: Home Agent address (*x) dst: CoA (*x)
Destination Options Routing Header
Home Address: Home Address (*x) Routing Type: 2 (*x)
Authentication Header Segments Left: 1 (*x)
SPI: Home Address: Home Address(*x)
Seq No: Authentication Header
ICV: SPI:
ESP Header Seq No:
SPI: ICV:
Seq No: ESP Header
Mobility Header SPI:
Header Len Seq No:
MH Type: Mobility Header
Reserved: Header Len:
Checksum: MH Type:
Message Data Reserved:
Seq # Checksum:
AHLKR (*xyz) Message Data
Lifetime: Status (*xyz)
Mobility Options K:
Alternate CoA: CoA Reserved
Mobile Net Prefix Option Seq #:
Prefix Len: (*xyz) Lifetime:
Mobile Net Prefix: (*xyz) Mobility Options
ESP Trailer Binding Refresh Advice
ESP Auth Refresh Interval:
ESP Trailer
ESP Auth
Petrescu et al. Expires July 2004 [Page 17]
INTERNET-DRAFT Mobile Networks Threats January 2004
AH and ESP non-NULL for BU and BAck when MR returns home
Base Header Base Header
src: Home Address (*x) src: Home Agent address (*x)
dst: Home Agent address (*x) dst: Home Address (*x)
Authentication Header Authentication Header
SPI: SPI:
Seq No: Seq No:
ICV: ICV:
ESP Header ESP Header
SPI: SPI:
Seq No: Seq No:
Mobility Header Mobility Header
Header Len Header Len:
MH Type: MH Type:
Reserved: Reserved:
Checksum: Checksum:
Message Data Message Data
Seq # Status (*xyz)
AHLKR (*xyz) K:
Lifetime: Reserved
Mobility Options Seq #:
Mobile Net Prefix Option Lifetime:
Prefix Len: (*xyz) Mobility Options
Mobile Net Prefix: (*xyz) Binding Refresh Advice
ESP Trailer Refresh Interval:
ESP Auth ESP Trailer
ESP Auth
C. IPsec non-Protection of Home Agent Discovery Messaging
In this section, we used the following NEMO messages for threat
analysis: Home Agent Address Discovery and Home Agent Address Reply.
The following fields have been considered as relevant for NEMO
threat analysis:
-src and dst addresses in the base header.
-the R bit in the ICMPv6 discovery and reply messages.
-the R bit in the Home Agent Information Option of the Reply
message.
In building the packet formats below, the following notation was
used:
*: NEMO field, or bit or value introduced by NEMO base protocol, or
containing helpful information for realization of the
NEMO-related risks described in this document.
x: authenticated field, as covered by AH ICV.
y: encrypted field, as part of ESP payload data.
z: authenticated field, as part of ESP authentication data.
For example, fields that are marked (*xyz) are helping realizing
threats, but are protected by AH and ESP non-NULL authentication,
thus rendering most NEMO threats impossible; fields that are only
marked (*) are not protected, thus might constitute security risks.
Petrescu et al. Expires July 2004 [Page 18]
INTERNET-DRAFT Mobile Networks Threats January 2004
C.1 Unprotected Home Agent Address Discovery and Reply
Base Header Base Header
src: CoA (*) src: Home Agent address (*)
dst: Home Agents anycast (*) dst: CoA (*)
ICMPv6 message ICMPv6 message
Type Type
Code Code
Checksum Checksum
Identifier Identifier
R (*) R (*)
Home Agent Information Option
Type
Length
R (*)
Remark the the Agent Discovery messages are not protected at all by
IPsec and may lead to important security threats. NEMO threat
analysis is concerned solely by the use of the R bit of these
messages, and by the risks involved on tampering with the integrity
or the confidentiality of this bit exclusively.
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.txt. August 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-02.txt. December
2003.
[5] Ernst, T. and Lach, H.-Y, "Network Mobility Support
Terminology", Internet Draft,
IETF. draft-ietf-nemo-terminology-00.txt. May 2003.
[6] Ferguson, P. and Senie, D., "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[7] Gupta, M. and Melam, N., "Authentication/Confidentiality for
OSPFv3" (work in progress). Internet Draft, IETF.
draft-ietf-ospf-ospfv3-auth-04.txt. December 2003.
Petrescu et al. Expires July 2004 [Page 19]
INTERNET-DRAFT Mobile Networks Threats January 2004
[8] 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.
[9] 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.
[10] Kent, S. and Seo, K., "Security Architecture for the Internet
Protocol" (work in progress). Internet Draft,
IETF. draft-ietf-ipsec-rfc2401bis-02.txt. January 2004.
[11] Kent, S., "IP Authentication Header" (work in progress).
Internet Draft, IETF. draft-ietf-ipsec-rfc2402bis-05.txt.
September 2003.
[12] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[13] Madson, C., "The Use of HMAC-MD5-96 within ESP and AH", RFC
2403, November 1998.
[14] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
Algorithm with Explicit IV", RFC 2405, November 1998.
[15] Madson, C. and Glenn, R., "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998.
[16] 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.
[17] Nikander, P., "An Address Ownership Problem in IPv6" (work in
progress). Internet Draft, IETF.
draft-nikander-ipng-address-ownership-00.txt. February 2001.
[18] Postel, J. and Reynolds, J., "Instructions to RFC Authors",
RFC 2223, October 1997.
[19] Rescorla, E., "A Survey of Authentication Mechanisms" (work in
progress). Internet Draft, IETF.
draft-rescorla-auth-mech-02.txt. October 2003.
[20] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text
on Security Considerations", BCP 72, RFC 3552, July 2003.
[21] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000.
Petrescu et al. Expires July 2004 [Page 20]
INTERNET-DRAFT Mobile Networks Threats January 2004
Changes
November 2003: revision 00 submitted.
January 2004: revision 01 submitted.
-added appendices with detailed packet formats.
-added the threat on Home Agent Discovery messaging.
-added detailed explanations on existing threats and how IPsec
headers protect.
-eliminated the highly generic threats on Confidentiality and
Integrity to better focus on NEMO specific threats.
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
Copyright (C) The Internet Society (2004). 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 July 2004 [Page 21]