IP Routing for Wireless/Mobile Hosts (mobileip) WG Allison Mankin
INTERNET-DRAFT Basavaraj Patil
Date: 05 November 2001 Dan Harkins
Expires: May 2001 Erik Nordmark
Pekka Nikander
Phil Roberts
Thomas Narten
Threat Models introduced by Mobile IPv6 and Requirements for Security
in Mobile IPv6
<draft-ietf-mobileip-mipv6-scrty-reqts-02.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
The IESG returned the Mobile IPv6 (MIPv6) draft to the working group
due to concerns about the security and scalability of binding updates
(BUs) sent to correspondent nodes and the associated IPsec processing
that is specified in the draft. Since that time discussions have
continued to attempt to define what is really needed to make binding
updates secure while taking into consideration the aspect of
scalability as well as the fact that IPsec may not be the most
suitable security mechanism for securing BUs between MNs and CNs. In
Multi-Author [Page i]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
the course of discussing the requirements it became apparent that a
threat model is needed in order to adequately specify the security
requirements. Mobile IPv6 mandates that all binding updates be
authenticated. The current approach taken to securing these BUs is
via the use of IPsec. This approach for securing BUs has various
problems, one of which is scalability. The I-D from a specification
perspective does not have security vulnerabilities, but as specified,
has serious limitations in its capability to be deployed on an
Internet wide basis.
The purpose of this I-D is to identify the scenarios and threats that
Mobile IPv6 can possibly bring to the Internet. From these scenarios
and threats are derived a set of requirements that Mobile IPv6 needs
to address as part of the specification.
Multi-Author [Page ii]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
Table of Contents
Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 1
2. Terminology/Definitions . . . . . . . . . . . . . . . . . . . 2
3. Threats on a broad scope introduced by Mobile IPv6 . . . . . . 3
4. Classification of Threats . . . . . . . . . . . . . . . . . . 4
5. Classification of Attackers . . . . . . . . . . . . . . . . . 5
6. Detailed threat scenarios . . . . . . . . . . . . . . . . . . 6
6.1. Threats related to attackers located anywhere in the
internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1.1. Tampering with the CN binding cache . . . . . . . . 7
6.1.1.1. Scenario 1 - Attacker knows MNs home adress . . . 7
6.1.1.2. Scenario 2 - ICMP unreachable sent to CN . . . . . 8
6.1.2. Tampering with the MNs binding cache . . . . . . . . 9
6.1.2.1. Scenario 3 - Both end-points of a session as MNs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1.3. BU flooding . . . . . . . . . . . . . . . . . . . . 10
6.1.3.1. Scenario 4 - Flooding a CN with BUs . . . . . . . 10
6.2. Threats related to attacks originating from the same
subnet/link as the MN . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Scenario 5 - MITM via a spoofed BU . . . . . . . . . 10
6.2.2. Scenario 6 - Man-in-the-middle attack via the
default router . . . . . . . . . . . . . . . . . . . . . . 11
6.2.3. Scenario 7 - Moving to an untrusted access point . . 12
6.2.4. Scenario 8 - Passive monitoring of traffic . . . . . 13
6.3. Threats related to attacks originating from the same
subnet/link as the CN . . . . . . . . . . . . . . . . . . . . 13
6.4. Attacker located on the same subnet/link as the HA . . . 14
6.4.1. Scenario 9 - Spoofed BUs sent on behalf of an MN
which is at home . . . . . . . . . . . . . . . . . . . . . 14
6.4.2. Scenario 10 - Intercepting BUs sent to HA . . . . . 15
6.4.3. Scenario 11 - BU cancellation at HA by malicious
node . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Attacker on the path between the CN and HA . . . . . . . 16
6.5.1. Scenario 12 - Masquarade/DoS attack . . . . . . . . 16
6.5.2. Scenario 13 - CN challenge to a BU sent by the MN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Multi-Author [Page iii]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
6.6. Attacker on the path between the MN and CN . . . . . . . 17
6.6.1. Scenario 14 - Non MIPv6 Specific . . . . . . . . . . . . . 18
6.6.2. Scenario 15 . . . . . . . . . . . . . . . . . . . . . . . 18
6.7. Threat model for the case where the MN sends a binding
update to the previous router asking it to take on the role
of an HA temporarily . . . . . . . . . . . . . . . . . . . . . 18
6.7.1. Scenario 16 . . . . . . . . . . . . . . . . . . . . . . . 19
6.8. Other threats, including those that target the Home
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.8.1. Scenario 17 . . . . . . . . . . . . . . . . . . . . . . . 19
6.8.2. Scenario 18 - HA used as a Packet reflector . . . . . . . 20
6.8.3. Scenario 19 - CN as a packet reflector . . . . . . . . . . 21
6.8.4. Threat model specifically in wireless networks . . . 21
7. Requirements for MIPv6 Security . . . . . . . . . . . . . . . 21
7.1. General Requirements . . . . . . . . . . . . . . . . . . 22
7.2. Specific to Mobile IPv6 . . . . . . . . . . . . . . . . . 23
7.3. Requirements from Threats . . . . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Authors's Addresses . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 26
Appendix B: Question and Discussions . . . . . . . . . . . . . . 28
Multi-Author [Page iv]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
1. Introduction
The IESG returned the MIPv6 draft to the working group due to
concerns about the security and scalability of binding updates (BUs)
sent to correspondent nodes and the associated IPsec processing that
is specified in the draft. Since that time discussions have
continued to attempt to define what is really needed to make binding
updates secure while taking into consideration the aspect of
scalability as well as the fact that IPsec may not be the most
suitable security mechanism for securing BUs between MNs and CNs. In
the course of discussing the requirements it became apparent that a
threat model is needed in order to adequately specify the security
requirements.
The purpose of this I-D is to identify the scenarios and threats that
Mobile IPv6 can possibly bring to the Internet. From these scenarios
and threats are derived a set of requirements that Mobile IPv6 needs
to address as part of the specification.
The goal is to determine which of those threats are of concern and
should be defended against. While the basic goal is "no worse than
IPv4," the prevalence of wireless and the likely deployment of MIPv6
in that space means the basic goal should aim at being "no worse than
IPv4 with switched Ethernets", although the intent is not to try to
solve the security problems of shared/broadcast wireless mediums.
The threat model is used to generate a list of requirements to make
the MIPv6 protocol secure against likely threats. These requirements,
interspersed with the threats and also listed at the end of this
document are aimed at providing guidelines in developing a solution
for MIPv6 security.
For the readers that are new to computer and communications security,
we recommend consulting Appendix A, "Background", for some
introductory material.
1.1. Assumptions
The Mobile IPv6 specifies that basically any IPv6 node MAY function
as a Correspondent Node (CN), receiving Binding Updates and creating
Binding Cache Entries. However, any node MAY alternatively ignore,
either selectively or altogether, Binding Updates, and continue
sending packets to the Home Address. Additionally, a Corresponding
Node may itself be a Mobile Node. It should be noted that most
threats if not all arise from the BU that is sent by the MN to the
CN, and that too only when the CN processes the BU itself, thereby
creating a binding cache or, when it processes the home address
option in an IPv6 packet without authorization to do so.
Multi-Author [Page 1]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
Furthermore, the following assumptions are made in the threat
analysis below:
1 The mobile node and the HA have setup a pre-established
bidirectional security association before the mobile node begins
to roam and connects to the network from a location that is not
its home. This does not imply that the MN has to always boot up at
home before roaming onto other networks. The reason for a
bidirectional SA is to authenticate the BU as well as the BAck.
The nature of this security association is not elaborated in this
document. But it is anticipated that it is quite feasible to assign
keys or certificates between a MN and an HA. This assumption is due
to the likelihood that an MN and Home Agent belong to the same
administrative domain, or else are in a business relationship of some
sort. The unusual cases in which this is not true ("homeless" MN)
will have additional security issues, which will need to be
separately considered in the future.
This security association may be established by configuring the keys
or certificates etc. on the MN and the home network at the time of
subscription.
2 In most cases there are no existing, established security
associations or other security relationships between the mobile
node and the correspondent node. In addition no Certificate
authorities nor a PKI exist that would enable the establishment of
such SAs dynamically. The reason for requiring a SA between the MN
and a CN is because the BU sent by the MN to the CN needs to be
secured in order to avoid possible threats identified in this I-D.
2. Terminology/Definitions
1 Passive Attacks In a passive attack, the attacker reads packets
off the network but does not write them. Eg: For instance,
password sniffing attacks can be mounted by an attacker who can
only read arbitrary packets. This is generally referred to as a
PASSIVE ATTACK.
2 Active Attacks When an attack involves writing data to the
network, we refer to this as an ACTIVE ATTACK.
Multi-Author [Page 2]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
3. Threats on a broad scope introduced by Mobile IPv6
An intrinsic feature of any mobility scheme is, obviously, mobility.
Thus, node mobility accomplished via Mobile IPv6 raises a number of
security issues. The most damaging threat that MIPv6 introduces is
the ability to redirect packets from communicating IPv6 peers. A
redirect attack can be defined as an attack in which mobility
signaling causes the route that packets take between two
communicating peers to be altered such that the packets are routed to
a destination determined by the attacker. The ability to redirect
packets can allow an attacker to insert himself in the middle of a
session (MITM) quite easily. Redirect attacks can also be launched
from remote locations and attackers do not have to be on the same
link as the communicating peers.
Other mobility introduced threats are denial-of-service (DoS)
threats, basically meaning that a hostile node may be able to block
all traffic on an unprotected link, or a dishonest (wireless) link
operator may cause DoS or other harm to a mobile node.
Another class of threats is created by the Mobile IPv6 route
optimization mechanism. A Mobile Node (MN) has the capability to
send a Binding Update to a Correspondent Node (CN) in order to
achieve route optimization of the packet stream from the CN to the
MN. Normal packet routing without Binding Updates sent to CNs works
as follows:
Packet stream from MN to CN:
--------------------->
|--------|
[MN]----|Internet|----[CN]
|--------|
SRC Addr: MNs CoA
Dst Addr: CNs Global IPv6 address
Dest opt: MNs Home Address in Home Address option
Packet stream from CN to MN:
Multi-Author [Page 3]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
|--------|
[MN]----|Internet|----[CN]
^ |--------| /
| | /
\ | /
\------[HA]<----/
CN to HA:
SRC Addr: CNs Address
Dst Addr: MNs Global IPv6 home address
HA to MN:
Tunnelled
A Binding Update can be sent by the MN to a CN, which results in a
Binding Cache Entry for the MN being created in the CN (See Section
8.3 of [1]). However it should be noted that a CN will create the
entry in the Binding Cache iff the rules specified in Sec 8.2 of [1]
are satisfied. Subsequent packets from the CN to the MN will include
a routing header which contains the MNs home address and the
destination address in the IP header is the MNs CoA (thereby
achieving route optimization and bypassing the HA from the packet
stream).
4. Classification of Threats
In the absence of a security association between most MN-CN pairs,
there are multiple vulnerabilities that the MN, the CN, or the HA or
home network, become exposed to. Basically, the threats can be
classified as follows.
1 Tampering with the Binding Cache Entries
- creating an unauthorized Binding Cache Entry at a Home Agent
(Note that this threat is mostly covered by the assumption of having
a security association between the MN and the HA. However, we do
include some discussion in order to clarify some of the authorization
and security policy issues involved.)
Multi-Author [Page 4]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
- creating an unauthorized Binding Cache Entry at a Correspondent
Node
- creating an unauthorized Binding Cache Entry at the previous
access router, acting as a temporary packet forwarding Home Agent
2 Denial-of-Service
- preventing a MN from communicating with some or all nodes
- preventing a CN from communicating with some or all nodes
- preventing a HA from serving legitimite MNs
3 Disclosure of sensitive information
- Disclosure of nodes serving as home agents in a network
5. Classification of Attackers
The following classes of attackers, and threats caused by them, are
considered:
- an arbitrary node, anywhere in the Internet, launching an attack
gainst a MN, a CN, or a HA
- an attacker located on the same (wireless) link as the MN
- an attacker located on the same link as the CN
- an attacker located on the same link as the HA
- an attacker on the path between the CN and the HA
- an attacker on the path between the MN and the CN
Please note that we do not consider the case where an attacker is on
the path between the MN and HA, since we assume that their
communication is secured or can be secured via the existence of the
MN-HA security association. Note, however that the current Mobile
IPv6 specification (version -14 of [1]) makes no assumptions about
the MN-HA path traffic being secured.
Multi-Author [Page 5]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
Furthermore, we consider the following threats separately:
- using a previous router as a temporary HA
- DoS attacks against a CN
- DoS attacks against a MN
- DoS attacks against a HA
6. Detailed threat scenarios
In this section, we present a number of specific threat scenarios.
The scenarios are arranged by the capabilities of an attacker, using
the same order as the classification above. Some of the threats are
specific to Mobile IPv6 while other's are not. The inclusion of the
non-related threats serves as a background to evaluate the related
threats.
To make cross referencing easier, the scenarios can be classified as
follows:
Attack | Attacker location | Effect | Remarks
----------+-------------------+------------+------------------------------
A. 1 | Anywhere | MITM/DoS | Needs to know Home Address
2 | Anywhere | MITM/DoS | Needs to know Home Address
3 | Anywhere | DoS | No prior knowledge needed
----------+-------------------+------------+------------------------------
B. 1 | MN's link | MITM/DoS | Using only BUs
2 | MN's link | MITM/DoS | Using non-MIPv6 mechanisms
3 | Close to MN | MITM/DoS | Tamper with radio interface
4 | MN's link | MITM/DoS | Tampering Binding Acks
----------+-------------------+------------+------------------------------
C. 1 | CN's link | MITM/DoS | Using non-MIPv6 mechanisms
----------+-------------------+------------+------------------------------
D. 1 | HA's link | MITM/DoS |
2 | HA's link | Multiple | Acting as a Home Agent
----------+-------------------+------------+------------------------------
E. 1 | CN->HA link | Masq/DoS | Attack without BUs
2 | CN->HA link | MITM/DoS | Defeat Home Address check
----------+-------------------+------------+------------------------------
F. 1 | MN->CN link | DoS | Attack without BUs
2 | MN->CN link | MITM/DoS | Immune to ingress filtering
----------+-------------------+------------+------------------------------
G. 1 | MN's (past) link | MITM/DoS | Fool temporary HA
----------+-------------------+------------+------------------------------
H. 1 | Anywhere | Disclosure | Topology information exposed
Multi-Author [Page 6]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
2 | Anywhere | DDoS | Use HA as a reflector
3 | Anywhere | DDoS | Use CN as a reflector
6.1. Threats related to attackers located anywhere in the internet
6.1.1. Tampering with the CN binding cache
The following section describes scenarios, threats, effects and
requirements that deal with manipulating the binding cache in the CN.
6.1.1.1. Scenario 1 - Attacker knows MNs home adress
A MN and a CN have an ongoing session. A malicious node/attacker
knows the MNs home address.
6.1.1.1_Threat:
The attacker can send a binding update to the CN. The CN believes
that the MN has moved and hence has a new CoA. It updates the entry
for the MN in its binding cache.
6.1.1.1_Effect:
The packet stream for the ongoing session from the CN to the MN now
is diverted to the malicious node.
The MN in this case may be on its home network and not have any CoA
or it may be on another network and have a CoA. The attacker in this
case only needs to know about the MNs home address and possibly any
CNs that the user may communicate with. The attacker could be
anywhere on the Internet and does not have to be on the same link or
network as the MN.
6.1.1.1_Reaction:
In the above case the MN may realize that it is no longer receiving
any further packets from the CN and may take appropriate actions,
which may include sending another binding update to the CN.
The attacker has the ability to redirect the traffic to another
location via this attack. If not for any gains, this kind of an
attack can be classified as a DoS attack. Such an intruder could also
send a BU to the MN supposedly from the CN and insert himself as a
MITM for traffic between the two.
Multi-Author [Page 7]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
The attack described here is an active binding cache update attack.
The CNs binding cache has been changed by an entity that does not own
the home address sent in the BU. So the issue is, how does a CN
determine if the sender of the BU actually is authorized to create
cache entries for the home address carried in the BU, before updating
his binding cache.
A DoS attack or MITM attack on an IPv6 node can be mounted even if
the node never goes mobile. Since it is possible to create an entry
in the binding cache for an IPv6 node in another IPv6 node, it is not
required that a node be mobile or have mobile IP client software on
it to be able to do it. In the absence of verifiability of the
authority over the IPv6 home address of a node, another IPv6 node can
send a BU to any other IPv6 node on behalf of someone else and cause
disruptions in communications between legitimate IPv6 nodes.
6.1.1.1_Requirement:
A correspondent node MUST not update its binding cache on receiving a
binding update from any IPv6 node without verifying that the packet
was sent by a node authorized to create binding cache entries for the
home address carried in the home address option of the BU.
6.1.1.2. Scenario 2 - ICMP unreachable sent to CN
An ICMP unreachable message can be originated as a result of packets
from the CN not being able to be delivered to the MN at it's COA (or
its Home Address). The ICMP unreachable message would normally be
sent by the last hop router serving a MN if the MN has moved and is
no longer attached to the network via that router.
6.1.1.2_Threat:
An attacker could send an ICMP unreachable for an MNs COA to a CN
which has created a binding cache entry for that MN.
6.1.1.2_Effect:
The CN deletes the binding cache entry for that MN. The result is
that the traffic stream from the CN to the MN are now routed through
the HA. Route optimization fails, but the traffic stream between the
MN and CN is still maintained.
6.1.1.2_Requirement:
Multi-Author [Page 8]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
No Mobile IPv6 specific requirements can be generated from this
threat.
6.1.2. Tampering with the MNs binding cache
In the previous section we looked at changing the binding cache entry
for an IPv6 MN in the CN. However an MN can also be considered as a
CN from the perspective of being an end-point in a session that is
being terminated at the MN and originated from another MN. In such a
case the MN (now in the role of a CN) also has a binding cache entry
for the other MN. The same threats discussed above are now opened up
on the MN.
6.1.2.1. Scenario 3 - Both end-points of a session as MNs
If a MN originates a VoIP call to a CN which is also mobile, the MN
sends the CN a binding update to achieve route optimization. The CN
will also in this case send a BU to the MN (originator) and update
the binding cache. An attacker could possibly determine the end-
points of this session by various means. For example, it may learn
about the call/session by eavesdropping on the local link of either
party, or possibly by eavesdropping on the SIP signalling elsewhere
in the internet.
6.1.2.1_Threat:
An attacker can send a BU to either the MN or the CN or both and
disrupt the communication. So, a passive attacker could be just
sitting and learning about the VoIP call, and possibly launch the
malicious BU to the MN and the CN from another network.
6.1.2.1_Effect:
Cause packets to be routed to the incorrect destination, leading to
either denial-of-service or snooping (privacy violation) or worse
modifying the content of the traffic by MITM.
6.1.2.1_Requirement:
Same as Req 6.1.1.1_Requirement
<Comment1 in Appendix B>
Multi-Author [Page 9]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
6.1.3. BU flooding
This section deals with threats that are related to nodes involved in
mobility being flooded by BUs.
6.1.3.1. Scenario 4 - BU flooding
Malicious nodes could flood a CN with fake BUs affecting the binding
cache.
6.1.3.1_Threat:
A malicious node or virus could keep sending fake BUs to other IPv6
nodes at a very rapid rate and thereby create unnecessary state in an
IPv6 node. It could also possibly cause the binding cache memory to
become inundated with entries for nodes that have no real meaning and
thereby preventing a valid node's entry being created in the binding
cache.
6.1.3.1_Requirement:
a) An IPv6 node that receives binding updates SHOULD NOT create state
until it has verified the authenticity of the sender.
b) An IPv6 node SHOULD have the capability to reject binding updates.
6.2. Threats related to attacks originating from the same subnet/link
as the MN
There are multiple possibilities here depending on the type of access
medium. If the access medium is a shared multiple access network such
as a wireless network (802.11, wide-area cellular) or an Ethernet
LAN, the attacker could do passive monitoring of the packets. The
attacker could possibly not intercept the packets and forward them
unless he takes on the role of the default router and cause packets
from the MN to be delivered to him instead of the actual default
router. However this threat can be classified as a general threat and
one that is not specific to Mobile IPv6.
6.2.1. Scenario 5 - MITM via a spoofed BU
A man-in-the-middle attack can be mounted on an ongoing session by
sending a spoofed to the CN or the MN.
6.2.1_Threat:
Multi-Author [Page 10]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
By being able to passively monitor the traffic, the attacker could
learn about the CNs that the MN is communicating with and also
determine to which CNs the MN is sending BUs. The attacker could in
such a case send a spoofed BU packet to the same CN. Furthermore, it
can very easily send a spoofed BU to the MN, claiming that the CN is
currently on the same link as the MN (i.e. co-located with the
attacker).
6.2.1_Effect:
This will cause the traffic from the CN to the MN be routed
elsewhere. Changing the route of packets from CN to MN is a serious
threat. It can be classified as a DoS attack on the MN or the CN.
The latter case where the attacker also sends a BU to the MN results
in a MITM, where the attacker could possibly alter the contents of
the traffic.
6.2.1_Requirement:
Same as verifying if the sender is authorized to send BUs for the
home address contained in the BU.
6.2.2. Scenario 6 - Man-in-the-middle attack via the default router
A man-in-the-middle attack could be launched on hosts attached to a
link by having them change their default router
6.2.2_Threat:
If the attacker takes on a more active role, it can insert itself as
a MITM between the MN and the CN, by pretending to be the default
router to the MN and the MN to the CN.
6.2.2_Effect:
The attacker could possibly modify/change the contents of the
traffic. On a wired or wireless LAN or wireless network, the attacker
cannot prevent the router advertisements from the default router (DR)
reaching the MN. So it would probably be difficult for the attacker
to intercept packets to/from the MN by pretending to be the DR.
However the attacker who is on the link and monitoring the router
advertisements can in effect send a new router advt. (proclaiming
himself as the DR) immediately after the actual routers advt and
thereby overriding the true routers advt. from the MNs perspective.
If an attacker can take on the role of the default router there are
other more significant threats than the ones that Mobile IP
introduces and it goes for both v4 and v6.
Multi-Author [Page 11]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
6.2.2_Requirement:
This is not specific to Mobile IPv6 and hence no requirement is
generated as a result.
6.2.3. Scenario 7 - Moving to an untrusted access point
The MN could attach itself to an access point that has not been
authenticated.
6.2.3_Threat:
The attacker could easily have a WLAN access point and cause the MN
to switch to the new AP and a different network (maybe) on which the
attacker could be at the DR and thereby able to intercept and modify
packets on the uplink and downlink.
In this attack, the attacker uses the original base station as its
uplink, and pretends to be a single node to the original base
station.
6.2.3_Effect:
In this type of an active attack, the MN continues its session with
the CN, but in the case where the attacker uses the original base
station the binding cache entry for the MN in the CN is that of the
attacker's address. The attacker continues to forward doctored
packets (received from the CN) to the MN. The attacker essentially
changes the destination address from it's own (CoA) address to the
MNs CoA before forwarding the packets and the MN as such is unaware
of the MITM.
The CN is unaware that the packets to the MN are now being sent to
another node as there is no way that the CN could verify the
ownership of the home address in the BU.
In the case of a wide area wireless network (CDMA/TDMA) it is
possible to mount a passive attack on the traffic between the MN and
the CN on the air-interface. However it would be much more difficult
(cost-perspective) in having a MN change the AP/BTS that it is
currently using. The attacker can learn the details of the MN and
it's communicating partners and mount an attack from elsewhere.
The CN which continues to receive packets from the MN (with src
address, MNs CoA) has also received a BU from the attacker and has
changed the entry for the MN in it's binding cache. As a result the
CN's packet stream to the MN will flow to the attacker at the address
Multi-Author [Page 12]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
specified. The CN may tend to believe that the CoA sent in the BU is
an alternative CoA which MIPv6 allows.
6.2.3_Requirement:
The Mobile Node SHOULD be capable of ascertaining the identity of the
access point to which it is attaching and authenticate it.
6.2.4. Scenario 8 - Passive monitoring of traffic
An attacker who is able to passively monitor the traffic could send a
fake Binding Ack to the MN as a response to a BU sent by the MN.
6.2.4_Threat:
By being able to passively monitor the traffic, the attacker could
learn about the CNs or HA that the MN is communicating with and also
determine to which CNs or HA the MN is sending BUs. The attacker
could thus synchronize with the MN such that when MN sends a BU then
attacker replies to MN with a fake Binding Acknowledgment different
than the true Binding Acknowledgment (Status, Lifetime or Refresh
fields).
6.2.4_Effect:
This can lead to (1) MN sends unnecessary BU's (subject to rate
limiting of sending BU's) or (2) MN doesn't send a BU that is
necessary. As further effects of (2) unnecessary triangular routing
takes place or MN is not reachable at all.
6.2.4_Requirement:
Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node SHOULD ensure it trusts the sender of that Binding
Acknowledgment.
<Question1 in Appendix B>
6.3. Threats related to attacks originating from the same subnet/link
as the CN
The fact that the attacker can be on the same link as the CN has
other implications as well. When considering this possibility most of
the same issues already outlined apply. In many cases the CN may
also be an MN to a different CN and in that case all the attacks
listed above apply here as well.
Multi-Author [Page 13]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
6.3_Threat:
It should be pointed out that in the absence of MIPv6 today an
attacker on this link is able to accomplish quite a lot of mischief,
such as spoofing neighbor discovery or inserting itself as an MITM
using link level techniques.
It is also easier for the attacker to now insert himself as a MITM
and intercept and modify packets sent between the MN and the CN. So
an attacker on the CNs link can mount an active attack more
effectively than if he is on the MNs link.
6.4. Attacker located on the same subnet/link as the HA
If a mobile node is on its home network, it does not need to send any
binding updates to CNs and as such Mobile IP is not required.
6.4.1. Scenario 9 - Spoofed BUs sent on behalf of an MN which is at
home
An attacker on the same subnet as the MN (on its home subnet) could
send BUs to CNs that the node is communicating with and disrupt the
traffic.
6.4.1_Threat:
An attacker on the same subnet as the MN (on its home subnet) could
send BUs to CNs that the node is communicating with and disrupt the
traffic. Since the attacker is on the same subnet as the MN, i.e. at
home, it may be aware of the CNs that the MN is communicating with.
Therefore it can easily send a BU to these CNs and inform them that
the MN is now reachable at some COA.
6.4.1_Effect:
Traffic disruption by diverting the packets to an unwanted COA; DoS
attack agains the MN, or Man-in-the-Middle attack with some more
effort.
6.4.1_Requirement:
Same as verifying if the sender is authorized to send BUs for the
home address contained in the BU.
With some more effort, the attacker can insert himself between the MN
and the CN, even when the MN is at home. That is, the attacker sends
a BU on the behalf of the CN to the MN, telling that the CN is a
Multi-Author [Page 14]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
mobile node and currently co-located at the same network as the MN
is. Simultaneously, it sends a BU to the CN telling the CN that the
MN is currently at the attacker's address. Since the CN is not
assumed to check that the Home Address and the COA are at different
subnets, there is no reason why the latter wouldn't work either.
6.4.2. Scenario 10 - Intercepting BUs sent to HA
If the attacker is on the same subnet as the HA of an MN, the
attacker could possibly intercept the BU packet the MN sends to the
HA (while the MN is roaming). The attacker could spoof the HA and
send a Binding request to the MN even when it is not required.
6.4.2_Threat:
If the attacker is on the same subnet as the HA of an MN, the
attacker could possibly intercept the BU packet the MN sends to the
HA (while the MN is roaming). The attacker could spoof the HA and
send a Binding request to the MN even when it is not required.
Binding requests can also be sent by other malicious nodes to the MN
or in the worst case scenario, the MN could be flooded by binding
requests from an attacker with spoofed source IP addresses.
6.4.2_Effect:
1 DoS for the MN as the Binding update could be rejected.
2 The attacker himself pretends to be the HA and begins to intercept
traffic destined for the MN originating from the CNs.
3 The MN may not be sending BUs to CNs in order to maintain
location confidentiality. However Since the attacker is aware of
the COA of the MN at all times, the location privacy of the MN is
lost.
4 Flood the MN with a large number of binding requests.
6.4.2_Requirement:
The MN SHOULD be capable of authenticating binding requests. The MN
SHOULD/MAY only process binding requests which are originated by
nodes that are in the binding update list of the MN.
Multi-Author [Page 15]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
6.4.3. Scenario 11 - BU cancellation at HA by malicious node
A malicious node on the home subnet can send a binding update to the
HA for an MN with lifetime set to zero and thereby cause the binding
cache entry to be deleted.
6.4.3_Threat:
A malicious node on the home subnet can send a binding update to the
HA for an MN with lifetime set to zero and thereby cause the binding
cache entry to be deleted. The malicious node could cause the HA to
believe that the MN has returned to its home network and hence does
not need a binding to some COA.
6.4.3_Requirement:
The HA MUST authenticate any binding update received by it before
making any changes to the binding cache entries.
<Comment2 in Appendix B>
6.5. Attacker on the path between the CN and HA
If an attacker is able to insert himself on the path between the CN
and the HA, it may open up the following security gaps.
6.5.1. Scenario 12 - Masquarade/DoS attack
6.5.1_Threat:
If the MN and CN are communicating via Mobile IPv6 but the MN is not
sending Binding Updates to the CN, all packets originated by the CN
are first sent to the Home Address. The packets are then received by
the HA, and tunneled to the MN. Now, if the attacker is on the CN-HA
link, including CN's local link and the HA link, it is able to
eavesdrop on all traffic flowing from the CN to the MN. Thus, if the
MN is not on-line, the attacker can easily play the MN's part, and
masquerade as an MN. On the other hand, if the MN is on-line, the
attacker can easily disrupt communications e.g. by sending TCP RSTs.
6.5.1_Effect:
Masquarade when the MN is off-line, DoS otherwise.
6.5.1_Requirement:
Multi-Author [Page 16]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
Any requirements to address this threat is outside the scope of
Mobile IPv6 as the threat described above is a generic one. However
MIPv6 itself SHOULD not cause further grief in establishing end-to-
end security either using IPsec or other mechanisms.
6.5.2. Scenario 13 - CN challenge to a BU sent by the MN
6.5.2_Threat:
If the MN sends a binding update to the CN and the CN rather than
updating the cache decides to challenge the MN to verify if in fact
the MN was the one that originated the BU, it can send a
challenge/cookie/foobar to the MNs home address instead of the CoA.
If the routing infrastructure is intact, the home agent of the MN
will receive this packet containing the challenge and will
forward/tunnel the packet to the MN (maybe over a secure tunnel). The
MN on receiving the challenge/cookie may act on it and send it back
to the CN. The CN on receiving the challenge it sent out originally
to the MNs home address has reason to believe that the MN was indeed
the one that originated the BU and can go ahead and create an entry
in the binding cache.
However if the attacker is on the CN-HA path, including CN's local
link and the HA link, s/he can intercept this packet containing the
challenge and send a spoofed response to the CN and cause it to
create an invalid entry for the MN in it's binding cache. The
attacker on the CN-HA path and an attacker on the MNs link could be
co-conspirators and be able to insert themselves in the communication
path.
6.5.2_Effect:
Ability to insert onself as a MITM.
6.5.2_Requirement:
Same as verifying if the sender is authorized to send BUs for the
home address contained in the BU.
6.6. Attacker on the path between the MN and CN
If the MN is not at home, and the attacker is on the path between the
MN and the CN (including the MN's and CN's local link), it can
eavesdrop on packets sent by the MN to the CN. Therefore it can
easily learn the Home Address of the MN.
Multi-Author [Page 17]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
6.6.1. Scenario 14 - Non MIPv6 Specific
6.6.1_Threat:
Since the attacker can eavesdrop on the traffic flowing from the MN
to the CN, it can easily cause DoS e.g. by sending TCP RSTs.
6.6.1_Effect:
Selective DoS.
6.6.1_Requirement:
This threat is also non Mobile-IPv6 specific and hence no requirement
is generated.
6.6.2. Scenario 15
6.6.2_Threat:
Taking advantage of its topological location, the attacker can send
BUs to the CN, giving the MN's Home Address. This threat is
different from threat 6.6.1.1_Threat in the sense that this attack
works even in the presence of fully functioning ingress filtering and
even if Alternate CoAs were disallowed.
6.6.2_Effect:
MITM/DoS.
6.6.2_Requirement:
Same as verifying if the sender is authorized to send BUs for the
home address contained in the BU.
6.7. Threat model for the case where the MN sends a binding update to
the previous router asking it to take on the role of an HA temporarily
Section 10.9 of the Mobile IP specification allows a MN to send a
binding update to a router (that can act as a Home Agent) on the
previous subnet that the MN was attached to, and request it to
forward packets destined to the MNs previous COA to the new COA. The
specification also states : "As with any packet containing a Binding
Update (see section 5.1), the Binding Update packet to this home
agent MUST meet the IPsec requirements for Binding Updates, defined
in Section 4.4." However it is not clear how the MN could have
Multi-Author [Page 18]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
established a security association with that router on the previous
subnet.
6.7.1. Scenario 16
6.7.1_Threat:
An attacker who is aware of a MN being currently attached to a subnet
could send a binding update to a router on that subnet (which is
willing to act as an HA) with the H bit set.
6.7.1_Effect:
This binding update which is spoofed causes the HA router on that
subnet to create a binding entry for the legitimate MN to some other
COA. It will start intercepting the packets destined to the MN (which
is still on the same subnet) and forward(tunnel) it to the COA
specified in the binding update. Traffic destined to a MN is now
redirected elsewhere causing a DoS attack.
6.7.1_Requirement:
A router on a subnet willing to take on the role of an HA for a MN
(even on a temporary basis) MUST establish a security association
before the router will accept BUs for a MN with the H bit set.
<Comment 3 in Appendix B>
6.8. Other threats, including those that target the Home Agent
6.8.1. Scenario 17 - Home Agent discovery via the ICMP anycast Home
Agent discovery message
Section 9.2 of the specification [Ref1]: "As described in Section
10.7, a mobile node attempts dynamic home agent address discovery
by sending an ICMP Home Agent Address Discovery Request message to
the "Mobile IPv6 Home-Agents" anycast address [10] for its home IP
subnet prefix, using its care-of address as the Source Address of
the packet. A home agent receiving such a Home Agent Address
Discovery Request message that is serving this subnet (the home
agent is configured with this anycast address on one of its
network interfaces) SHOULD return an ICMP Home Agent Address
Discovery Reply message to the mobile node (at its care-of address
that was used as the Source Address of the Request message), with
the Source Address of the Reply packet set to one of the global
unicast addresses of the home agent."
Multi-Author [Page 19]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
The reply message MAY contain a list of all possible home agents
on that subnet.
6.8.1_Threat:
An attacker who knows the home address of a MN can possibly send a
home-agent discovery message to the MN's home subnet and receive a
list of all home agent routers on that subnet.
6.8.1_Effect:
This would expose the structure of the operator's network (to some
extent) which is not desirable. It would also allow an atacker to
determine the routers acting as home agents and mount DoS attacks
or other types of attacks on these routers and thereby cause these
routers to be unable to forward packets to MNs that they are
intended to serve.
6.8.1_Result:
One of the things that operators might do is to make sure their
firewalls do not allow any ICMP home agent discovery messages to
be let in. This would defeat the whole purpose of having the
ability to do home agent discovery. 2 Use the Home Agent as a
packet reflector
6.8.1_Requirement:
An HA which responds to an ICMP home agent discovery message
SHOULD only do so after authenticating the MN's identity.
6.8.2. Scenario 18 - HA used as a Packet reflector
6.8.2_Threat:
If an attacker can make a Home Agent to believe that a Mobile Node
is at a given CoA, the attacker can then use the Home Agent as a
packet reflector when launching a distributed DoS attack against
the node at the CoA. That is, by simply sending packets to the
Home Address, the Home Agent will tunnel them and send them to the
DDoS target. An HA will create a binding entry for an MN if the
authentication in the BU is valid. Using the HA as a packet
reflector makes it easier for the DDoS attacker to hide itself,
making it harder to succesfully shut down the DDoS attack.
6.8.2_Requirement:
Multi-Author [Page 20]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
The MN and HA MUST have a strong security association and the HA
MUST verify the BUs sent by any IPv6 node requesting the HA to
intercept packets destined for it and tunnel them to it's COA.
6.8.3. Scenario 19 - CN as a packet reflector
According to the Mobile IPv6 spec: "A node receiving a packet that
includes a Home Address option MAY
implement the processing of this option by physically exchanging
the
Home Address option field with the source IPv6 address in the
IPv6
header."
An attacker can simply spoof the home address option in packets
sent to a CN causing the CN to swap the source address with the
address contained in the home address option. This causes the CN
to become a packet reflector in attacks on nodes whose addresses
may be known. Using the CN as a packet reflector may make it
easier for the DDoS attacker to hide itself, making it harder to
successfully shut down the DDoS attack.
6.8.3_Requirement:
CNs SHOULD NOT/MAY NOT process any packet (BU or not) containing a
Home Address option unless they have verified that that the node
sending the packets is authorized to use the home address in the
destination option.
6.8.4. Threat model specifically in wireless networks
Wireless network technology typically enables security features
through its own technology specific techniques. To a greater
(GSM) or lesser (802.11) degree these techniques offer some level
of security. The network provider must in any case enable these
features and it is sometimes the case that this is not done.
There are well-known deficiencies in the security schemes of some
of the technologies. In general the wireless link may easily
become the weakest link in terms of system and network security.
7. Requirements for MIPv6 Security
Multi-Author [Page 21]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
7.1. General Requirements
A Should be no worse than IPv4 as it is today.
B Should be as secure as if the mobile node was on the home link
without using Mobile IP.
C Identity verification MUST not rely on the existence of a
gloabl PKI.
D Any solution that is developed for securing the binding updates
(MN-HA and MN-CN) should be able to use whatever security
associations may already exist to minimize the threats created
by on-axis attackers. In particular:
D.1
It is assumed that in all schemes there will be some form of
pre-established security association between a mobile node and
its home agent. Such a security association should be used to
minimize the threats. In this context it makes sense exploring
the complexity of handling mobile-to-mobile communication
differently than mobile-to-nonmobile communication. As an
example, if two MNs are communicating while visiting fairly
untrusted visited links, it may make sense to take advantage of
the fact that each mobile has a security association with its
home agent when exchanging the messages needed to establish the
binding. Thus these messages might travel MN1->HA1->HA2->MN2
(and in the reverse direction) so that the risks for a MITM
attack are limited to the HA1<->HA2 path.
D.2
In some deployments a PKI may exist (encompassing for e.g some
home "domain" which includes a set of MNs, their HAs and some
CNs). In that case it should be possible to use the local PKI
to prevent MITM attacks when the CN is covered by that PKI.
(For instance, if both MN and CN share a trust chain in the PKI
sense it should be possible to take advantage of that.)
D.3
If a method to validate public keys (without the existence of
CAs and PKI) is created or exists, then it should be possible
to take advantage of that mechanism for improved security of
the BUs.
Multi-Author [Page 22]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
7.2. Specific to Mobile IPv6:
0 Security for binding updates is MANDATORY. This is already the
case for MIPv6 and as such is not a new requirement. However
the mechanism used for securing binding updates MUST be one
that is scalable and does not rely on existence of PKIs.
1 It SHOULD be extremely difficult for an attacker "off-axis"
i.e. an attacker that cannot snoop packets on either of the
three legs of the paths, to divert traffic. This difficulty
should be on the order of correctly guessing a very large
random number.
2 It SHOULD be possible to leverage the only security association
that can be preconfigured (the MN-HA SA) to secure BUs to CNs.
3 It MUST be possible for a mobile node to be anonymous while
still taking advantage of route optimization. Thus if a Mobile
Node is using RFC 3041 temporary addresses for its home and/or
COA it must be able to use a different visible identity when it
uses a different temporary address.
4 It SHOULD be possible to negotiate alternative cypher
suites/algorithms. It SHOULD be possible to negotiate
alternative mechanisms. All implementations MUST implement one
designated mechanism and algorithm for interoperability
reasons.
5 If IPsec is used as part of the solution it SHOULD not place
additional requirements on the set of IPsec SPD selectors
beyond what is in common implementations. (Note: This is
however debatable. A soon to be published I-D will identify the
issues of using IPsec in conjunction with Mobile IPv6.)
6 Router Advertisements sent by the HA to the MN MUST be secured.
7 Scalability of mechanisms using symmetric or asymmetric keys
MUST be considered in any solution.
8 SHOULD optimize the number of message exchanges and bytes sent
between the participating entities (MN, CN, HA). This is an
important consideration for some MNs which may operate over
bandwidth constrained wireless links.
9 A CN SHOULD be capable of rejecting BUs sent by a MN. If a CN
rejects a BU, the MN SHOULD refrain from sending further BUs to
that CN (for a period of time).
Multi-Author [Page 23]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
10 Any approach MUST consider the scalability issues and
computational capabilities of the entities in a mobile
environment, especially MNs and CNs. The expense associated
with generating keys or public key operations or Diffie Hellman
computations SHOULD be accounted for.
7.3. Requirements from Threats
6.1.1.1_Requirement
A correspondent node MUST not update its binding cache on
receiving a binding update from any IPv6 node without verifying
that the packet was sent by a node authorized to create binding
cache entries for the home address carried in the home address
option of the BU.
6.1.1.2_Requirement
No Mobile IPv6 specific requirements can be generated from this
threat.
6.1.1.4_Requirement
a) An IPv6 node that receives binding updates SHOULD NOT create
state
until it has verified the authenticity of the sender.
b) An IPv6 node SHOULD have the capability to reject binding
updates.
6.2.3_Requirement
The Mobile Node SHOULD be capable of ascertaining the identity
of the access point to which is is attaching and authenticate
it.
6.2.4_Requirement
Upon receiving a packet carrying a Binding Acknowledgement, a
mobile node SHOULD ensure it trusts the sender of that Binding
Acknowledgment.
6.4.2_Requirement
The MN SHOULD be capable of authenticating binding requests.
The MN SHOULD/MAY only process binding requests which are
originated by nodes that are in the binding update list of the
MN.
6.4.3_Requirement
The HA MUST authenticate any binding update received by it
before making any changes to the binding cache entries.
Multi-Author [Page 24]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
6.5.1_Requirement
Any requirements to address this threat is outside the scope of
Mobile IPv6 as the threat described above is a generic one.
However MIPv6 itself SHOULD not cause further grief in
establishing end-to-end security either using IPsec or other
mechanisms.
6.7.1_Requirement
A router on a subnet willing to take on the role of an HA for a
MN (even on a temporary basis) MUST establish a security
association before the router will accept BUs for a MN with the
H bit set.
6.8.1_Requirement
An HA which responds to an ICMP home agent discovery message
MUST only do so after authenticating the MN's identity.
6.8.2_Requirement
The MN and HA MUST have a strong security association and the
HA MUST verify the BUs sent by any IPv6 node requesting the HA
to intercept packets destined for it and tunnel them to it's
COA.
6.8.3_Requirement
CNs SHOULD NOT/MAY NOT process any packet (BU or not)
containing a Home Address option unless they have verified that
that the node sending the packets is authorized to use the home
address in the destination option.
8. Acknowledgments
We would like to thank feedback from many WG members especially
Claude Castellucia, Alexandru Petrescu, Gabriel Montenegro and
Francis Dupont for their comments and suggestions to make this
document better.
9. References
[Ref1] draft-ietf-mobileip-ipv6-13.txt - Work in progress
[Ref2] draft-nikander-ipng-address-ownership-00.txt - Work in
progress
Multi-Author [Page 25]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
10. Authors's Addresses
Pekka Nikander
Pekka.Nikander@nomadiclab.com
Dan Harkins
dharkins@lounge.org
Basavaraj Patil
Basavaraj.Patil@nokia.com
Phil Roberts
Proberts@megisto.com
Allison Mankin
mankin@isi.edu
Erik Nordmark
Erik.Nordmark@eng.sun.com
Thomas Narten
narten@raleigh.ibm.com
Appendix A. Background
There are two basic ways of securing communications and data. One
is to use cryptography. The second one is to protect the
communications or data using physical and programmatic means,
basically making it infeasible to tamper with the data without the
required privileges. In the case of communication, the latter
approach means that the actual networking equipment must be
physically protected, e.g., through pressurising the cables.
When new functionality is added to a networking architecture, the
functionality usually means opening up new possibilities for
tampering with some (management) data or communications. That is,
some of the physical and/or progammatic means of protection are
lowered, thereby creating new security vulnerabilities. In the
case of Mobile IPv6, there are two new major issues: the Binding
Cache, and node mobility. Basically, in order for Mobile IPv6 to
be as secure as the system would be without it, there must be
means to protect the Binding Cache against unauthorized
Multi-Author [Page 26]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
modification, and to provide reasonable protection for the Mobile
Nodes against malicious networks and for the networks against
malicious Mobile Nodes.
Furthermore, the use of wireless link layers creates new threats.
For example, unless care is taken at the link layer, it may be
hard for a Mobile Node to make sure that it is actually
communicating with the very access router that it thinks it is
communicating with. However, these threats are mostly independent
of Mobile IPv6, and it is not expected that Mobile IPv6 security
would necessarily bring any remedy to them.
When cryptography is used to secure communications, there must be
a way of creating a session key. The session key may then be used
to protect (some of) the communicated data against eavesdropping
and/or unauthorized modification. However, if the communicating
parties do not have any direct nor indirect security relationship
between them, there are no known methods for creating such session
keys in a manner that would be secure against all attackers. (One
example of an indirect security relationship is one created with
the help of a trusted third party.)
In the case of Mobile IPv6, the main threat we want to protect
against is unauthorized creation or alteration of Binding Cache
Entries. One way to define who is authorized in this case is to
define that whoever "owns" the Home Address is authorized to
create Binding Cache Entries for it [Ref2].
Unless the IPv6 addresses are themselves used as some kind of pre-
established security relationships, the only other way of
providing security relationships between an arbitrary pair of a
Mobile Node (MN) and a Corresponding Node (CN) is to create a
global trusted third party based security infrastructure.
Experience has shown that building such an infrastructure is
extremely hard, and not likely to succeed any time in the near
term future.
Thus, it seems like it is, in practice, impossible to build a
deployable Mobile IPv6 security solution that is secure against
all possible classes of attackers. Thus, this document goes into
some length and detail in describing threats caused by various
classes of attackers, keeping in mind the goal of "no worse than
IP v4 with switched Ethernets."
Generic attack descriptions
Multi-Author [Page 27]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
Here we give a brief overview of the possible attacks.
- In a Masquarade attack a node plays the role of another node
towards a third node. That is, if Mallory is able to convince
Bob that he is Alice, he is masquarading as Alice. Basically,
even in the current IPv4 internet, if Alice is switched off or
off-line, it is fairly easy to masquarade as Alice if Mallory
are able to eavesdrop or anticipate the traffic flowing back
from Bob to Alice.
- In a Man-in-the-Middle (MITM) attack a node plays a double
masquarede. That is, Mallory plays Bob to Alice and Alice to
Bob. In the current IPv4 internet, if the attacker is on the
path between two nodes, or at the same physical link with
either of them, there are a number of mechanisms that can be
emploeyd to launch MITM attacks. The mechanisms include, for
example, tampering with the routing tables and ARP spoofing.
- In a Denial-of-Service (DoS) attack, an attacker prevents a
node from communicating with one or more other nodes. For
example, Mallory may be able prevent Alice from communicating
with Bob, even though they could communicate without the
presense and acts of Mallory. A Denial-of-Service attack can
either be selective, e.g. disrupting communications between
Alice and Bob, generic, e.g. disrupting all communications of
Alice, or random, e.g. disrupting some communications of Alice.
In the current IPv4 internet, it is fairly easy to launch a large
number of different kinds of Denial-of-Service attacks. Thus, the
aim of this draft is to point out some new DoS threats so that
they can be potentially addressed.
Appendix B: Question and Discussions
- Comment1:
<Note> If the MN is moving in a rapid manner and changing it's CoA
quite frequently as a result, it makes it difficult for the
attacker to stay as a MITM. The MN on changing it's CoA will send
a new BU to the CN and update the binding cache. Unless the
attacker is aware of the MN's movement and changes to CoA, it will
be hard to continue to be a MITM (but I guess it depends on what
point in the network structure the attacker sits). On the other
hand, at least in theory an attacker could just send a continuous
stream of Binding Updates, and unless the CN had checks for this
Multi-Author [Page 28]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
specific condition, most packets would still flow through the
attacker. </Note>
- Question1:
Does the fact that a BU can contain alternative CoAs open up
further security problems?
</Question> <Comment AUTHOR="Pekka Nikander"> IMHO, no. It is
foolish to rely on the source address not being spoofed.
Personally, I don't believe that it will be ever possible to
mandate ingress PRF filtering everywhere. Thus, from the security
point of view, the source address and the Alt CoA should be
considered equally trustworthy: both can be spoofed. </Comment>
<Comment AUTHOR="BP"> I agree. We should just capture the ability
of the MN to send an alternative COA to be used in the creation of
the binding entry in the cache of the CN, but note that the same
issues that exist for the source address exist for the alternate
COA. </Comment>
- Question2:
(Question: What does an IPv6 node do when it has all these entries
in its binding cache that have some lifetime associated with them
and it is not possible to add further entries in this cache
without eliminating some. I guess it would be upto the
implementation to figure out ways to delete entries that are not
being used or FIFO type of mechanisms).
- Comment 2:
<Comment Author="BP"> An attacker on the same subnet as the HA can
do a lot of harm. However it is expected that the home subnet is
protected quite effectively and such attacks as described above
can only be launched by an insider. </Comment>
<Comment Author="BP"> In the case of wireless (Cellular) networks
it is expected that the HA is on a virtual subnet and a mobile
node as such is never really on it's home subnet ever. A Mobile
node performs deregistration when it is back on it's home subnet,
but in a cellular network that home subnet as such does not really
exist. A MN may be in it's home administrative domain network but
not on it's home subnet. Hence there is always a binding for the
MN to some COA. Such HAs will be well protected and an attacker
being on the same subnet as the HA would be quite difficult.
Multi-Author [Page 29]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
</Comment>
- Comment 3:
<Note BP> It is not necessary that the default router that the MN
is using be the router that acts as the temporary home agent to
forward the packets. The attacker could be on the same subnet as
the MN and listen to the router advertisements ad determine the
one that has the capability to act as an HA for that subnet. The
attack could be launched from the same subnet or from elsewhere.
</Note>
Multi-Author [Page 30]
INTERNET-DRAFT Security for MIPv6 05 Nov. 2001
