Subject: [mobile-ip] An attempt to classify attacks against Mobile IPv6

From: Pekka Nikander <[email-masked]>
Date: Wed, 21 Mar 2001 19:20:10 +0200

Now that the discussion about Mobile IPv6 security has been opened,
I think it is very important to explicitly specify the level of 
protection that we want to provide for Mobile IPv6. 

Thus, here is my first attempt to classify various possible attacks
against Mobile IPv6, to compare the attacks with the current situation
of running IPv4 between two stationary hosts, and my understanding of
the level of protection that we should aim for when designing a 
solution to protect Mobile IPv6. 

I've basically written this yesterday, and more work is definitely
needed.  Thus, comments and volunteers are solicited.

--Pekka

1. Introduction

As a general statement about protection requirements, the mechanism
MUST protect against completely new risks caused by mobility, SHOULD
protect against existing risks that become more propable, and MAY
protect against existing risks whose probablity is not changed.  In
praticular, if mobility makes a it slightly more likely that an
attacker is able to eavesdrop or modify traffic, the mechanism SHOULD
protect against such an eavesdropper.  On the other hand, if mobility
makes it highly more likely that an attacker is able to eavesdrop or
modify traffic, or creates likely new scenarios where the attacker has
these capabilities, the mechanism MUST provide protection.  What comes
to the circumstances under which an attack may occur, new
circumstances created by mobility REQUIRE modification, while
modification requirement is RECOMMENDED or OPTIONAL in other
scenarios.

2. Attacker capabilities

The may be attackers with various levels of capabilities.  In general,
we assume that all attackers are able to send forged IP packets.  That
is, we assume that the attacker can construct IP level packets and
sent them so that they contain any IP address as their source
address.  

2.1. Attacker cannot eavesdrop any traffic

The attacker is a completely outside node.  It is able to send forged
traffic to the MN, CA and HA, but it is not able to eavesdrop any
traffic between the MN, CA or HA.  The mechanism MUST be able to
protect against attacks launched by these kinds of attackers.
These kinds of attackers are denoted with the capability "NO".

2.2. Attacker can eavesdrop traffic

The attacker is able to eavesdrop some traffic.  It may have this
ability because it is able to eavesdrop a specific link that happens
to be used between the active parties, or because the attacker is on
the same local link as one of the parties, and is therefore able to
eavesdrop to all traffic on that local link.  In general, the
mechanism SHOULD be able to protect against attacks launched by these
kinds of attackers, but there are specific cases where the mechanism
MUST be able to provide protection, and one case where the attacker is
so powerful that it seems sufficient to loose the protection
requirement to OPTIONAL.  This capability is further divided in
subcases as follows.

2.2.1. Eavesdrop traffic between CN and HA only

The attacker is able to eavesdrop flowing between the CN and HA, but
no other relevant traffic.  The mechanism SHOULD be able to protect
against this kind of attackers.  These kinds of attackers are denoted
with the capability "CN<>HA".

2.2.2. Eavesdrop traffic between CN and MN only

The attacker is able to eavesdrop flowing between the CN and MN, but
no other relevant traffic.  The mechanism SHOULD be able to protect
against this kind of attackers.  These kinds of attackers are denoted
with the capability "CN<>MN". 

2.2.3. Eavesdrop traffic between MN and HA only

The attacker is able to eavesdrop flowing between the MN and HA, but
no other relevant traffic.  The mechanism SHOULD be able to protect
against this kind of attackers.  These kinds of attackers are denoted
with the capability "MN<>HA". 

2.2.4. Eavesdrop all traffic sent and received by CN

The attacker is able to eavesdrop all traffic send and received by
CN. For example, the CN might be a mobile host itself, and the
attacker is able to contact the same local link that the CN is
currently using.  The mechanism SHOULD be able to protect against this
kind of attackers.  These kinds of attackers are denoted with the
capability ">CN>". 

2.2.5. Eavesdrop all traffic sent and received by MN

The attacker is able to eavesdrop all traffic send and received by
MN. A typical case of this is the MN and the attacker on the same
wireless link.  The mechanism MUST be able to protect against this
kind of attackers.  These kinds of attackers are denoted with the
capability ">MN>". 

2.2.6. Eavesdrop all traffic sent and received by HA

The attacker is able to eavesdrop all traffic send and received by HA.
For example, the HA is a foreign HA, the MN has moved away from the
link but it is still receiving packets through its previous CoA, and
the attacker is able to contact the link afterwards.  Another case is
the less likely one where the attacker is attached to the same local
link as a long-term permanent HA.  The mechanism SHOULD be able to
protect against this kind of attackers.  These kinds of attackers are
denoted with the capability ">HA>". 

2.2.7. Eavesdrop all traffic sent and received by MN and HA

The attacker is able to eavesdrop all traffic sent and received by MN
or HA.  A typical scenario is the special case where the HA is a
foreign HA, and the MN, HA and attacker are all at the same local
link.  In general, the mechanism SHOULD be able to protect against
this kind of attackers, but it MUST be able to protect against certain
connection hijacking scenarios. These kinds of attackers are denoted
with the capability ">MN,HA>".

[TBD.  This case seems to require additional considerations.]

2.2.8. Eavesdrop all traffic sent or received by CN, MN or HA

The attacker is able to eavesdrop all relevant traffic.  Typically,
this requires co-ordinated attacks.  The mechanism MAY be able to
protect against this kind of attackers.  These kinds of attackers are
denoted with the capability "ALL". 

2.2.9. Eavesdrop traffic on a link where MN is likely to come

This is a case easily overlooked but very relevant.  In mobile
communications, a dedicated attacker can often easily figure out the
usual daily whereabouts of its target.  By acting preactively, it may
be able to connect to a local link where the MN is likely to come
soon, and pre-establish the situation so that it will be able to
launch its attack as soon as the MN arrives.  The mechanism MUST be
able to protect against attackers with this capability.  These kinds
of attackers are denoted with the capability "FUTURE".

2.3. Attacker can eavesdrop and modify traffic

A more capable attacker is not only able to send forged traffic and
eavesdrop some traffic, it is also able to block and thereby modify
some packets.  In general, we do not require that the mechanism
protects against these kinds of attackers, and therefore the
protection is OPTIONAL.  

2.3.1. Eavesdrop/modify traffic send and received by CN

TBD

2.3.2. Eavesdrop/modify traffic send and received by MN

TBD

2.3.3. Eavesdrop/modify traffic send and received by HA

TBD

2.3.4. Eavesdrop/modify all traffic

TBD

2.3.5. Eavesdrop/modify traffic on a link where MN is likely
       to come

TBD

2.4. Attacker capability summary

All attackers are able to send forged packets.  Some attackers are
able to eavesdrop some traffic, and others even block and therefore
modify some traffic.

  Attacker |                    |                  | Protection
  type     | Eavesdropping 	| Modification     | requirement
  ---------+--------------------+------------------+-------------
  NO       | None               | None             | MUST
  CN<>HA   | Between CN and HA  | None             | SHOULD
  CN<>MN   | Between CN and MN  | None             | SHOULD
  MN<>HA   | Between MN and HA  | None             | SHOULD
  >CN>     | CN                 | None             | SHOULD
  >MN>     | MN                 | None             | MUST
  >HA>     | HA                 | None             | SHOULD
  >MN,HA>  | MN and HA          | None             | SHOULD/MUST 1)
  ALL      | MN, CN, HA         | None             | MAY
  FUTURE   | Future MN          | None             | MUST
  ---------+--------------------+------------------+-------------
  MOD-CN   | CN                 | CN               | MAY
  MOD-MN   | MN                 | MN               | MAY/MUST 2)
  MOD-HA   | HA                 | HA               | MAY
  MOD-ALL  | MN, CN, HA         | MN, CN, HA       | MAY
  MOD-FUT  | Future MN          | Future MN        | SHOULD/MAY 3)

  1) MUST protect against TBD
  2) MUST protect against TBD.
  3) SHOULD protect against TBD.

3. CN properties

3.1. CN is a stationary host

3.2. CN is a multi-homed stationary host

3.3. CN is a mobile host

3.4. CN is a multi-home mobile host 

4. HA properties

4.1. Existing security association between MN and HA

Long-term HA.  "MN=HA"

4.2. No existing security associations between MN and HA

Temporary HA, used to forward packets sent to the old CoA.
"MN!HA".

5. Attack skenarios

The number of possible attacks is almost unlimited.  Thus, we do not
try to enumerate all possible attacks, but instead outline a number of
possible attack scenarious, pointing out the probable outcome of an
attack and (some of) the conditions under which the attack could
occur.  We also try to point potential vulnerabilities that could lead
to the realization of real attacks.  Finally, we classify the
scenarious based on their protection needs.

Currently the scenarios are limited to traffic hijacking and
denial-of-servidce only.  Other attacks are probably possible too, and
need to be added to later revisions of this document.

5.1. Hijacking existing Bindings

Traffic hijacking is the primary threat that there is a need to be
protected from.  That is, because mobility signalling effectively
creates local exceptions to the generic routing information, it is a
very potential tool for diverting traffic to an unauthorized
destination.  This, in turn, may lead to other attacks such as
denial-of-service (also covered separately), impersonation, and/or
man-in-the-middle attacks.

5.1.1. Hijacking existing Binding while MN is online and stationary

If an attacker is able to make a CN to believe that a MN has moved to
a new location, even if it has not, the attacker may be able to hijack
all traffic sent by the CN to the MN.  Furthermore, since the attacker
is assumed to be able to forge packets, it can forward all the
hijacked traffic to the MN, potentially leading to an attack where all
traffic passes through the attacker unnoticed.  Clearly, this is a new
threat compared to the non-mobile situation, and in principle the
mechanism MUST provide protection against attacks belonging to this
scenario.  On the other hand, it is already now possible to hijack TCP
connections if an attacker is able to modify traffic flowing between
two stationary hosts, and therefore protection against an attacker
that is able to modify packets flowing between the CN and the MN is
OPTIONAL.  This attack scenario is called "H-STAT".

5.1.2. Hijacking existing Binding while MN is changing it

If an attacker is able to make a CN to believe that a MN has moved to
location A while it is actually moving to location B, the attack may
be able to hijack traffic sent by the CN to the MN.  As a special
case, if an attacker is able to make the CN believe that a MN has NOT
moved while it has, the attacker may be able to hijack traffic sent by
the CN to the MN, depending on its ability to eavesdrop.  Clearly,
these are new threats compared to the non-mobile situation, and
the mechanism MUST provide protection.  This attack scenario is called
"H-MOVE". 

5.1.3. Hijacking existing Binding while MN is temporarily off-line

Another attack scenario applies when the MN is temporarily off-line
due to e.g. being temporarily outside radio coverage.  We take this as
an different scenario beause the situation may be easier for the
attacker.  That is, since the MN is off-line it is not able to receive
any messages sent to it, nor to reply to them.  Therefore the attacker
may have easier time in trying to make the CN to believe that the MN
has moved or that it is still on-line at its previous location.
Clearly, the mechanism MUST protect against the attack where the CN
thinks that the MN has moved to a new location.  What comes to the
case where the attacker continues to communicate with the CN using the
MNs previous location, the mechanism SHOULD provide protection.  This
attack scenario is called "H-OFFL".

5.2. Hijacking a Binding during its first establishment

It may be possible to attack while the MN is first contacting the CN.
Since we do not expect the existence of any global authentication
infrastructure, it may be hard to protect against man-in-the-middle
attacks during connection establishment.  That is, since the CN does
not necessarily have any information that might help it authenticate
the MN, it may be hard to provide protection, especially in the case
where the MN is away from home while first contacting the CN.
However, we strongly feel that the mechanism SHOULD provide protection
if possible at all.  Thus, this RECOMMENDATION should be considered as
an almost REQUIREMENT.  This attack scenario is called "H-INIT".

5.3. Hijacking a Binding before its first establishment

A capable attacker may be able to plan its attack well beforehand, and
try to anticipate the movements of its target.  Doing so, it may
launch an attack before the target has become on-line at all.  For
example, it may move to a local link where it expects the target to
first become on-line.  Since the target MN is off-line, and most
probably the HA does not have a binding for it, the attacker may be
able to play a number of tricks.  In the worst case scenario, there
may be two co-acting attackers, one at the link where the target MN is
likely to become on-line, and one at the same local link with the CN,
which itself may be a mobile node.  Under such circumstances, it may
be quite hard to provide protection.  However, the mechanism SHOULD
provide protection, if possible.  This attack scenari is called
"H-FUT". 

5.4. Blocking traffic (Denial-of-Service)

A threat possibly not as severe as traffic hijacking but worth
separate coverage is denial-of-service (DoS).  Currently, it is fairly
simple to launch various denial-of-service attacks against traffic
flowing between two stationary nodes.  Thus, in general, there are no
hard REQUIREMENTS to protect against DoS.  However, if one mechanism
clearly protects better against various DoS scenarious than another,
and is not otherwise inferior, the one providing better DoS protection
should clearly be preferred.  In order to be able to evaluate between
different DoS protection models, the DoS scenarios are classified as
those where the protection is RECOMMENDED and where it is OPTIONAL.
Furthermore, we discuss the potential severity of the DoS scenarious,
giving us some guidance when evaluating the protection properties.

5.4.1. Blocking traffic while MN is online and stationary

Currently, it is fairly easy to break existing TCP connections between
any two stationary hosts, e.g., by sending TCP RST to the parties.
However, such an attack does not necessarily prevent the parties from
re-establishing the TCP connection immediately and thereby continuing
communications.  On the other hand, combining connection termination
with resource exhausting DoS (such as SYN flooding) may effectively
prevent communication.  Now, from this point of view we may classify
the DoS attacks to two subclasses: those that only cause a temporary
disruption of communication, and those that prevent future
communication.  With regard to the first subclass, protection is
considered OPTIONAL, while protection against the second subclass
is considered RECOMMENDED.  This attack scenario is called "B-STAT".

5.4.2. Blocking traffic while MN is moving and changing its Binding

More severe DoS attacks may be available while the MN is changing its
binding.  For example, if the attacker is able to make the CN to
believe that the MN has not moved, it will continue to send packets to
the old CoA, either degrading or temporarily terminating the service.
(The service is degraded if the MN has registered with a temporary HA
at its old link, and the HA keeps tunneling the packets to the MN.  On
the other hand, if no such forwarding service has been established,
service is termporarily terminated.)  Depending on its capabilities,
the CN may notice that the MN does not seem to get the packets any
more, and expire the binding.  On the other hand, service degradion is
likely to go unnoticed for a while.  Protection against this class of
DoS attacks is RECOMMENDED.  This attack scenario is called "B-MOVE".

5.4.3. Blocking traffic while MN is temporarily off-line

While the MN is temporarily off-line, e.g., due to being outside radio
coverage, an attacker may have more possibilities to block future
traffic.  For example, the attacker may try to make the CN believe
that the CN has moved to an address which does not exist, or that the
CN has altogether terminated communication with the CN may lead to
DoS.  In the latter case, for example, the CN may flush any security
associations that it currently has with the MN, thereby forcing the MN
to re-create them once it becomes back on-line.  Typically, that would
lengthen the period of unablity to communicate by several seconds.  
Currently, protection against these kinds of attacks is considered
OPTIONAL.  This attack scenario is called "B-OFFL".

5.4.4. Blocking traffic while MN is trying to contact CN

The initial contact between the MN and the CN seems like a very
lucrative point to attack.  The MN and the CN don't even really know
yet whether the other party exists, and if the attacker can make the
MN believe that the CN is currently unavailable, or the CN believe
that the MN can't get reply packets sent to it, the attempt to
communicate may fail altogether.  However, such attacks are already
now fairly easy to execute.  Therefore, we consider protection against
this class of attacks as OPTIONAL.  This attack scenario is called
"B-INIT". 

5.4.5. Blocking traffic before MN tries to contact CN

As we discussed in Section 5.3, mobility signalling opens up a
possibility for a class of attacks that are performed before there is
any contact between the MN and the CN.  For example, the attacker may
lead the CN to believe that the MN-to-come is currently at a
non-existing address.  When the MN the contacts the CN, the CN will
send the reply packets to this non-existing address, leading the MN to
believe that the CN is currently unavailable.  

Another possibility may be to make the CN to persistently believe thet
the MN is dishonest and should not be allowed to communicate at all.
For example, the attacker may launch a resource exhausting
denial-of-service attack against the CN, making the CN to believe that
the launcher of the attack is the MN-to-come.  Now, if the CN, based
on its countermeasures, decided to (temporarily) ignore all traffic
originated by the MN, the MN will not get any replies from the CN once
it eventually tries to contact.

These attack possibilities seem to be new, and therefore it is
RECOMMENDED that the mechanism provides some protection against them.
This attack scenario is called "B-FUT".

5.5. Sumary of the attack scenarios

In the table below, "Scenario type" is the name of the attack
scenario, as named in sections above.  The "Attack possible currently"
tries to indicate if there are currently known ways of attacking
communication between two static IPv4 hosts.  "No" means that the
authors are unaware of such an attack, "Yes" that the authors are
aware of such attacks, and "Limited" means that a limited form of an
attack is known, typically depending on the capabilities of the
attacker.  "Protection requirement" gives indication how important it
is for the Mobile IPv6 protection mechanism to provide protection
against attacks belonging to the scenario.

           | Attack    |
  Scenario | possible  | Protection
  type	   | currently | requirement
  ---------+-----------+--------------
  H-STAT   | Limited   | MUST/MAY
  H-MOVE   | No        | MUST
  H-OFFL   | Limited   | MUST/SHOULD
  H-INIT   | Yes       | SHOULD
  H-FUT	   | ??        | SHOULD
  ---------+-----------+--------------
  B-STAT   | Yes       | SHOULD/MAY
  B-MOVE   | No        | SHOULD
  B-OFFL   | Yes       | MAY
  B-INIT   | Yes       | MAY
  B-FUT	   | No        | SHOULD

6. Protection requirement matrix

The following tables summarize the protection requirements
by classifying the attacks along the attack scenarios and attacker
capabilities.  Where deemed illuminating, also other properties such
as the existense of a pre-established security association between the
MN and the HA are considered.  In the table, the following
abbreviations are used.

 Abbr   | Explanation
 -------+---------------------------------------------------------
 MUST   | Protection is REQUIRED.  The mechanism MUST provide
        | protection against this class of attackers and attacks.
 -------+---------------------------------------------------------
 SHOULD | Protection is RECOMMENDED.  The mechanism SHOULD provide
        | protection if possible.
 -------+---------------------------------------------------------
 MAY    | Protection is OPTIONAL (but desired).  If the mechanism
        | does provide protection, it is a definite plus

6.1. Hijacking attacks

  Attacker | 
  type     | H-STAT | H-MOVE | H-OFFL | H-INIT | H-FUT  |
  ---------+--------+--------+--------+--------+--------+
  NO       | MUST   | MUST   | MUST   | MUST   | MUST   |
  CN<>HA   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  CN<>MN   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  MN<>HA   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  >CN>     | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  >MN>     | MUST   | MUST   | MUST   | MUST   | MUST   |
  >HA>     | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  >MN,HA>  | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  ALL      | SHOULD | SHOULD | SHOULD | MAY    | MAY    |
  FUTURE   | MUST   | MUST   | MUST   | SHOULD | SHOULD |
  ---------+--------+--------+--------+--------+--------+
  MOD-CN   | SHOULD | SHOULD | MAY    | MAY    | SHOULD |
  MOD-MN   | SHOULD | SHOULD | MAY    | MAY    | SHOULD |
  MOD-HA   | SHOULD | SHOULD | MAY    | KAY    | SHOULD |
  MOD-ALL  | MAY    | SHOULD | MAY    | MAY    | SHOULD |
  MOD-FUT  | SHOULD | SHOULD | MAY    | MAY    | SHOULD |

6.2. Denial-of-service attacks

  Attacker | 
  type     | B-STAT | B-MOVE | B-OFFL | B-INIT | B-FUT  |
  ---------+--------+--------+--------+--------+--------+
  NO       | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD |
  CN<>HA   | SHOULD | SHOULD | SHOULD | MAY    | SHOULD |
  CN<>MN   | SHOULD | SHOULD | SHOULD | MAY    | SHOULD |
  MN<>HA   | SHOULD | SHOULD | SHOULD | MAY    | SHOULD |
  >CN>     | SHOULD | SHOULD | SHOULD | MAY    | MAY    |
  >MN>     | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD |
  >HA>     | SHOULD | SHOULD | MAY    | MAY    | MAY    |
  >MN,HA>  | SHOULD | SHOULD | MAY    | MAY    | MAY    |
  ALL      | MAY    | MAY    | MAY    | MAY    | MAY    |
  FUTURE   | SHOULD | SHOULD | MAY    | MAY    | MAY    |
  ---------+--------+--------+--------+--------+--------+
  MOD-CN   | MAY    | MAY    | MAY    | MAY    | MAY    |
  MOD-MN   | MAY    | MAY    | MAY    | MAY    | MAY    |
  MOD-HA   | MAY    | MAY    | MAY    | KAY    | MAY    |
  MOD-ALL  | MAY    | MAY    | MAY    | MAY    | MAY    |
  MOD-FUT  | MAY    | MAY    | MAY    | MAY    | MAY    |