Subject: [mobile-ip] Issue 51: cookie lengths

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Jun 2002 22:13:58 +0300

Here's a new issue that was originally brought up by Charlie, and
then Tuomas Aura and myself studied it.

Background: Current specification has 32 bit mobile cookies,
128 bit home and care-of cookies, and 96 bit authenticators.

Question: Charlie Perkins asks: Can the cookie lengths for mobile,
home, and care-of cookies be smaller? Is it necessary to have 32 and
128 bits?

Proposal: From Tuomas Aura and Jari Arkko: After some analysis, we
think it would be safe to have the home and care-of cookies as 64
bits. On the other hand, it seems that mobile cookies are too short if
we set them at 16 bits, so they have to be at least 32 bits.  Taking
in account alignment / padding requirements, if we have more than 16
bits we might as well make them 64 bits without wasting any more
bandwidth.

As a result, this proposal does not change the size of the HOTI/COTI
messages, but reduces the size of the HOT/COT messages by 8 bytes.
Size of all mobile cookies will be 64 bits, and home and care-of
cookies will also be 64 bits.

Some fragments of analysis follows.

HOME COOKIE:

Guessing a home cookie would allow the attacker to defeat the
return routability procedure, even outside the HA-CN path.
At the worst case, it would allow the attacker to get access
to traffic destined somewhere else.

Here's an attack scenario:

1. Victim V is a stationary node (for instance).
2. Attacker A is anywhere on the Internet.
3. The goal is to steal traffic some CN, C, sends to V.
4. Send a HOT to C to figure out its current nonce index. The
    home address used does not matter, it can be the attacker's
    address A.
5. Send a COT from A to C, to get a valid cookie and care-of nonce index.
6. Send 231 packets from A to C, with the valid care-of cookie,
    guessed home cookie, and a nonce index retrieved earlier (or something
    slightly higher)
7. C will install a BCE for V, point to coa=A for the first packet that
    happens to have a matching cookie.

Is this feasible? Assuming each packet in step 6 is about 100 bytes,
we need about 231 * 100 * 8 bits of bandwidth to do this attack,
i.e. about 4.7 hours at 100 mbit/s -- and the BCE would last for 5
minute. So while not quite practical at the moment, it seems feasible
that at some future time network bandwidths are big enough to make this
attack possible in some cases.

But repeating 2^64 packets is not feasible, so this length is recommended.

CARE-OF COOKIE:

The primary purpose of the care-of cookie in CoT is to verify that the
mobile is at the CoA. Otherwise, the attacker could be redirect data to
that address. I think 32 bits should be enough for this cookie. It means
that the attacker needs to send in the order of 232 false BUs to the
correspondent in order to trick it into accepting one.

However, perhaps it doesn't make sense to keep very different lengths
for similar cookies in the protocol, so 64 bits is recommended for this
as well.

MOBILE COOKIES:

The primary purpose of Mobile Cookies 1 and 2 is to prevent the attacker
blindly sending a flood of CoT and HoT messages, so that the mobile
always picks a false CoT or HoT instead of an authentic one. The result
is that the correspondent rejects all BUs and route optimization fails
(but see below for a more serious attack). This is not so serious. So it
would seem that 16 bits is enough (but see below). It means that the
blind attacker has to send in the order of 216 false CoT or HoT
messages / authentic CoTI-HoTI pair.

But all the cookies serve a secondary purpose: BA authentication. If
the attacker is able to send false BAs, it can make believe that the
BU has been accepted even if it has not. The result is that he mobile
will send data directly to the correspondent, which will reject
it. Thus, the nodes will be unable to communicate.  The BA
authentication work like this: The correspondent must be able to
receive both mobile cookies, one sent from CoA directly and the other
via HoA. The correct values of the mobile cookies in CoT and HoT
convince the mobile that these messages likely came from the authentic
correspondent. Thus, the mobile can also believe that the care-of
cookie and the home cookie were sent by the authentic correspondent.
This means that if the attacker spoofs CoT and HoT, it not only
prevents route optimization but can also spoof BA and, thus, prevent
the mobile and correspondent from communicating! This attack is just
as serious as having a false BU accepted.

A typical implementation of the mobile would probably reject any CoT
or HoT with the wrong mobile cookie value, and wait until it has
received at least one CoT and at least one HoT with the correct
cookie. This means that if the mobile cookies are 16 bits each, the
attacker has to send around 216+216 = 217 messages / authentic CoT-HoT
pair in order to spoof both of these messages. After that, the
correspondent will reject the mobile's BU message as unauthentic and
the attacker can send a false BA (because it knows K_bu).  What makes
things slightly worse is that if the attacker can eavesdrop mobile
cookie 2 in CoTI, it suffices to guess the other mobile cookie on
HoTI. Thus, the attacker on the MN-CN path only needs to send 216
false CoT messages / authentic CoT-HoT pair.

(Skip this paragraph if you agree with the above. -- A different
implementation could reject the CoT or HoT (which have correct mobile
cookie values) if it receives any false CoT or HoT messages (which
have wrong mobile cookie values) between the correct ones. This would
increase the cost of the above attack to 216*216 = 232 for the nodes
that cannot eavesdrop CoTI. But it would also make it very easy for
the attacker to prevent route optimization by sending a few false CoT
messages.)

The sequence number in BA helps against attackers who are not on the
MN-CN route. I'm not sure how many bits it is going to be and how much
entropy there is. Obviously, a real cookie in BU/BA would be better.
Nevertheless, 16 bits + the sequence number is probably enough to
prevent attackers who are not on the MN-CM route from creating false
BUs. Both the sequence number and the BU/BA cookie suffer from the
fact that an attacker on the BA/CN route can hear them. This leads me
to think that mobile cookie 1 on HoT needs to be longer than mobile
cookie 2 in CoT.

My conclusion is that mobile cookie 1 in HoTI/HoT should be as long as
the home cookie in HoT/BU. 32 bits should be enough. Mobile cookie 2
can be shorter, perhaps 16 bits is enough. That way, the cost of a DoS
attack that prevents communication between the mobile and the
correspondent is approximately equal regardless of whether the
attacker uses false BUs or false BAs for the attack.

So, setting mobile cookie 1 to 64 bits makes it as longs as the
home cookie. But perhaps it doesn't make sense to have the other
mobile cookies as different lengths, so we recommend them to be
64 bits as well.