Subject: [mobile-ip] Design team note: bidding down attacks

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Feb 2002 00:56:55 +0200

Here's a note relating to the RR vs. stronger mechanism selection.
On the list we have previously discussed bidding down attacks
against this selection, and the purpose of this note is to describe
those attacks. This may help the discussion of methods for mechanism
selection.

A second note relating to bidding down attacks will soon be posted
as well. That note deals with the methods of protecting the selection.

1. INTRODUCTION

The Mobile IP Working Group has been discussing if it could
allow a single, mandatory Binding Update (BU) authorization
scheme to be complemented with an optional scheme with a
higher strength. If several schemes are allowed in this
manner, it becomes necessary to select a scheme in some
manner. The question is whether such selection methods are
secure, since if the optional scheme can be turned off by
attackers the resulting security will be that of the mandatory
mechanism.

An earlier Design Team note [1] briefly described the above
issue but didn't go to the details of the possible attacks. In
view of the recent active discussions on possible secure
scheme selection protocols this was inadequate.

The purpose of this note is to describe the so called Bidding
Down problem in the selection method. Our purpose is to show a
few concrete examples on how the attacker can downgrade the
security to the lowest (mandatory) level even if communicating
peers supported a stronger method.

2. BASIC ATTACK

Figure 1 shows the network scenario for the most basic form of
a bidding down attack. The starting point of any attack must
be that RR can be defeated, otherwise there would be no
benefit to the attacker. In order to defeat RR, the attacker
must find himself on the path between the CN and the HA, or
perhaps in one of the LANs where these nodes are located.

      (MN) <----> HA <----> Attacker <----> CN

             Figure 1. Network scenario.

For the basic attack, it does not matter at all where the MN
is. For the attack to be interesting, we have to assume the MN
wishes to use something else than RR as its BU authorization
method. For the purposes of this example, we can assume this
method is a yet to be discovered new signaling scheme.

The attack starts in Step 1 by the attacker sending a fake
request to the CN, indicating in the desire to use RR in the
request.  The CN, not having any knowledge of the true desires
of the MN accepts this.

Step 1. Attacker sends first message(s) of BU authorization to
         CN, indicating that RR is desired. In the case of
         currently planned RR protocol [2] this would mean
         sending the 1a and 1b messages. In this network
         scenario both messages can be sent from the attacker's
         location towards the CN. This is because the attacker
         can choose the CoA so the attacker is on the path
	between the CN and the CoA. This can be done easily
	e.g. by selecting an address from the network where
	the attacker is.

Step 2. CN inspects the messages and continues the RR
         protocol, by responding to the message(s). According
	to the current understanding these would be 2a
	and 2b.

Step 3. Attacker receives the responses and proceeds to
         continue with the RR protocol. In the current
         protocol, this would be message 3, the actual BU.
         Typically, the attacker is also able to prevent the
         responses from reaching the MN (see section 3).

As a result, the attacker has established a BCE with the CN,
using RR and regardless of the desire of the MN to engage in
any Route Optimization or RR-based authorization.

3. DISCUSSION

Note that the bidding down attack does not have to take place
between CNs and MNs that are communicating at that moment. In
fact, it's easier for the attacker to just pretend to be the
MN that requests Route Optimization, than try to hijack a real
request for Route Optimization.

Unless CNs store information regarding previous security
preferences of MNs, the existence of previous or current BCEs
does not matter for the attacker either, as the attack looks
like the MN had moved.

The described bidding down attack depends heavily on the
infrastructureless approach selected for the BU authorization
protocols. Because of this approach, there isn't necessarily
any knowledge of the peers or their security preferences prior
the first BU authorization requests coming in.

Section 2 assumed that the attacker has the capability to
receive and inject IP packets somewhere on the path. We did
not assume the attacker would be able to block the flow of the
response packets to the HA/MN. Let's study the effects such
packets may have:

- If the MN happens to be a stationary and not a mobile node,
   it may not implement the processing of the MN messages, and
   hence may not be aware of any messages being sent to it.

- If the attacker blocks the CN's packets from reaching the
   MN, the MN becomes unaware of any attack being in progress.
   Can the attacker block the packets? It seems possible given
   that most attacks on the links or on the path would be based
   on spoofing Neighbour or Router Discovery. It has also been
   reported that TCP sequence number attacks have succesfully
   used temporary flooding of the nodes and links in order to
   hide the hijack attempt.

- In any case, given the position of the attacker, it is
   likely that he will see the responses of the CN sooner, and
   is also able to respond to the CN earlier. Therefore the CN
   accepts the attacker's BCE first.

- Also, if the MN would respond to a message in the middle of
   the RR protocol without having initiated the protocol by
   itself, there may be possibilities for the MN to warn the CN
   of a possible security breach, or to try re-establish a
   correct BCE at the CN.  However, the DoS aspects of this
   change to the RR protocols should be analyzed carefully.

4. CONCLUSIONS

RR leaves one residual threat open (the future attack [1])
when compared to the baseline case i.e. IPv6 without
mobility. Sites that do not host any HAs should be able to
protect themslves by disallowing RR on the addresses used by
these sites. Therefore, it seems desirable to set up a
mechanism that allows the CNs easily check whether a given MN
is willing to use RR or not.

In infrastructureless BU authorization methods, the CNs and
MNs do not have more information available to them about the
preferences of their peers than what can be deduced from the
BU signaling, i.e. the relevant addresses, the contents of the
BUs and the authorization messages, the properties ensured
through return routability tests, and possibly previous
knowledge of the peers' preferences if they have contacted
each other previously. It does not appear that we can trust
the real MN to react messages relating to the attack under
most circumstances.

There are two specific cases where bidding down attacks are
troublesome in particular. The first case is that of a
stationary node, which may not wish to be involved in mobility
at all, and which would benefit from the ability to say 'no
thanks' in a secure manner. The second case is that there have
recently been discussions on improving IPv6 control signaling
security. While any improvements are currently only
speculation, it is conceivable that Neighbour Discovery
security could be improved. Currently, RR does not make
current (quite low) on-link security much worse. However, this
could change as a result of improvements in ND security, and
as a result RR might be left as the weaker link. In order to
be able to handle this in future, there'd have to be a way
start moving towards more secure BU authorization mechanisms
at the same time as ND is improved. However, this is very hard
if attackers can claim that the nodes in question are older
and only support RR.

It is necessary to study the possible remedies to bidding down
attacks further. The discussion subject should include at
least:

- Allocation of bits in interface identifiers to signify
   security preferences.

- Ability to choose multiple stronger methods, and not have
   the selection mechanism tied to a particular strong method.

- Possibility of making RR nodes 'prove' their right to do RR
   in some manner, and therefore protecting stationary nodes.

- Whether security preferences from previous BCE establishment
   can be used in guarding against attacks. It is necessary to
   convince ourselves that there are no additional DoS
   concerns, however, in these schemes. As an example, an
   attacker with a DSL connection could fill an embedded device
   memory of 100KB in 10 s, assuming 1 KB messaging per BU and
   16 B per address. A CNN web server with 16 GB disk dedicated
   for this would fill up in 12 days. There must also be ways
   to avoid problems when the same address (e.g. in dial-up) is
   reused for other devices after a particular connection is
   finished. It should also be studied what the effect of this
   mechanism is when MNs do not always immediately run RO with
   their CNs. Thus, there appears to be many concerns around
   this approach.

- Whether we can make use of the ability of MNs to "notice" an
   attack is going on through a message leaked from the
   attacker to the HA/MN. (This may not matter, however, as it
   can be argued that attackers that can spoof RR can also
   typically prevent leaked packets.)

5. REFERENCES

[1] http://www.piuha.net/~jarkko/publications/mipv6/Residual_threats.txt
[2] http://www.piuha.net/~jarkko/publications/mipv6/RRCGA_Mail.txt