Subject: [mobile-ip] Unresolved issue #6: Reuse of nonces

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Apr 2002 21:15:43 +0300

Again an item which has consensus, but now there's some proposed
text to go with it:

Background: The RR method makes a routing test and expects the
resulting authorization to apply for a certain amount of time. It has
been asked whether a fast moving mobile node needs to apply all tests
on all movements or not, and whether the results of [HC]oT{,I} could
be reused. On the other hand we want to ensure that the correspondent
nodes don't have to be stateful, so creating SAs based on [HC]oTI
messages would be inappropriate? Also, deletion of BCEs at the CN
side may in some implementations require that nonces used to create
them be invalidated at the same time, so short-lived BCEs may cause
it to be impossible to reuse a particular nonce.

Question: Is the reuse functionality useful? How to provide it?

Proposal: Require that CNs should (if possible) keep nonces 'alive'
for a certain amount of time. During this time, the MN can reuse
either HoA or CoA cookies as appropriate. This can be useful for fast
movement (HoA cookie reuse) or multihomed host movement to a single
interface (CoA cookie reuse).

Text: Under 4.5.5:

    Before sending a Binding Update in Step 3, the mobile node has to wait
    for both the Home and Care-of Cookies to arrive. Due to resource
    limitations, rapid deletion of bindings, or reboots it can not be
    guaranteed that the cookies are still fresh and acceptable when the
    correspondent node uses them in the processing of the Binding Update.
    If the cookies have become too old, the correspondent replies with an
    an error code in the Binding Acknowledgement. The mobile node can then
    retry the Return Routability procedure. However, it is recommended
    that correspondent nodes try to keep these cookies acceptable at least
    MIN_COOKIE_LIFE seconds and SHOULD NOT allow them to be accepted
    beyond MAX_COOKIE_LIFE seconds.

    Given that the cookies are normally expected to be fresh for at least
    MIN_COOKIE_LIFE seconds, the mobile node MAY use them beyond a single
    run of the Return Routability procedure. A fast moving mobile node may
    reuse a recent Home Cookie from a correspondent node when moving to a
    new location, and just acquire a new Care-of Cookie to show
    routability in the new location. While this does not save roundtrips
    due to the parallel nature of the home and care-of return routability
    tests, the roundtrip through the home agent may be longer, and
    consequently this optimization is often useful. A mobile node that has
    multiple home addresses, may also use the same Care-of Cookie for
    Binding Updates concerning all of these addresses.

And then under 8.4:

    In order to prevent replayed binding updates after a binding cache
    entry has been deleted the CN needs to make sure that the nonce
    indicies used to create the binding are no longer valid.  This
    applies whether the binding is deleted due to it timing out
    (lifetime expiry) or being deleted explicitly by the MN.

    If a binding cache entry is logically deleted and either the home
    nonce index or the care-of nonce index used to create (or last
    update) the binding are still valid, the CN must behave as if it
    retains the state about the binding (including the sequence number)
    until at least one of the cookies has become too old.

    A possible way to implement this is to mark the binding cache entry
    so that it does not effect sending and receiving of packets, but so
    that it is found when a binding update is received. Another way is
    to mark the used nonces immediately too old. However, this method
    may cause some unnecessary failures and retries with ongoing Return
    Routability procedures with other mobile nodes. Furthermore, unless
    the mobile node has requested a Binding Acknowledgement, it is
    possible that this method may even cause an error in the RR
    procedure to go unnoticed, and data packets to be dropped through
    the use of the Home Address Option without an existing binding. The
    effect is similar to packet loss during the RR procedure, but may
    in certain circumstances significantly increase the problems.

And finally under 11:

    MAX_COOKIE_LIFE          180 seconds
    MIN_COOKIE_LIFE          60 seconds
    MAX_RR_BINDING_LIFE      300 seconds

------------
Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Apr 2002 21:35:07 +0300

Background: Draft 16 has an SPI field in the Authentication Data
parameter. This field has existed in the draft since draft 14.
However, in draft 16 it must be set to zero and the message is dropped
if on receipt it contains something else. Even the potential semantics
of the field are somewhat unclear. Is it going to be an algorithm
identifier, or an IPsec-like dynamic entity? On the other hand, there
is a need to signal other potential security schemes beyond RR in BUs,
and how can we do this?

Question: Should the SPI field be kept?

Proposal: This SPI field doesn't seem very useful, remove
it. For ability to provide other security mechanisms, the
following building blocks can be used:
- Flags in the RR or BU messages
- New parameters in the RR or BU messages

------------

---

From: Michael Thomas <[email-masked]>
Date: Tue, 9 Apr 2002 12:56:17 -0700 (PDT)

Jari Arkko writes:
 > it.

   Agree.

		Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Apr 2002 13:17:09 -0700

Please leave it in there. 

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Apr 2002 13:33:47 -0700

Agree with most of the text, except for section 11.

The actual window of vulnerability is only 
MAX_RR_BINDING_LIFE (300 seconds). The MAX_COOKIE_LIFE 
does not add anything to the window of vulnerability. So 
why not make the MAX_COOKIE_LIFE also 300 seconds. 

lets assume an MN has initiated an RR test. An on-path
attacker (CN-HA path) could get hold of K0. For him to 
launch to attack, he must generate a new K1 with his 
CoA and send a BU as soon as the CN has sent a BAck to 
the actual MN. If he does not do it immediately, the 
packets from the CN will keep going to the right MN. 
No harm done, till the attacker tries to use K0. And 
when the attacker does this, he is able to hijack 
connection for MAX_RR_BINDING_LIFE. Whatever the case,
the MN would be vulnerable only for MAX_RR_BINDING_LIFE.

So I suggest

      MAX_COOKIE_LIFE          300 seconds
      MIN_COOKIE_LIFE          60 seconds
      MAX_RR_BINDING_LIFE      300 seconds

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 09 Apr 2002 13:41:29 -0700

Hello Jari,

The SPI field has to be available, to allow for selection of
the appropriate Binding Security Association to be used for
calculations involving the authentication data.

I think the potential semantics of the field are pretty
clear.  No one has, to my knowledge, suggested that the
field be used as an algorithm identifier.  It has always
been just an index (as the name suggests).  Alternatively,
the SPI could be a field in the Binding Update and the
Binding Acknowledgement messages.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Apr 2002 10:15:24 +0200

Proposal: This SPI field doesn't seem very useful, remove it.

=> if nobody proposes a real use of it: agree.

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Apr 2002 10:22:38 +0200

=> I believe we have to exhibit a scenario where multiple BSAs
are useful before applying this argument. In IPsec the source address
is not used in the SA lookup for incoming packets so a SPI is needed
but the case of BSAs is a bit different.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Apr 2002 17:22:51 +0300

This issue was brought up earlier (21/3) by Vijay on the mailing
list.

Background: Section 9.6 of draft 16 requires that the home
agents MUST use IPsec ESP to protect RR packets between
itself and the mobile node. Encryption of the RR packets
provides protection against attackers along this path, e.g.
those on the mobile node's current LAN.

Question: There are multiple questions:
- Must it be a MUST, should it be a SHOULD or
   may it even be a MAY?
- Is this a MUST implement or a MUST use?
- If it does not have to be used all the time,
   how is the will to use this signaled, and does
   it need to be signaled?

Proposal: The keyword should apply to implementation, not use. In
particular situations users may want to turn this off. For
interoperability reasons, a MUST implement would be desireable. This
does not appear to cause much additional implementation effort since
ESP (or AH) is already necessary for home registration protection.
Finally, IPsec SPD controls the use of IPsec so this should be a
sufficient mechanism for controlling this feature. Adding a MIPv6
specific flag in the BUs, for instance, to signal the desires of the
MN to the HA in this matter might complicate the implementation by
requiring additional co-operation between IPsec and MIPv6 stack parts.

Text: New contents of 9.6

The Return Routability procedure described in Section X.X.X assumes
that the confidentiality of the HoTI and HoT messages is protected as
it is tunneled from the home agent to the mobile node. Therefore, the
home agent MUST support IPsec ESP for the protection of RR
packets. Support for a non-null encryption transform MUST be
available. It isn't necessary (or even possible) to distinguish
between different kinds of RR packets in this case.

The use of ESP for RR protection is optional and controlled by
configuration of the IPsec Security Policy Database both at the mobile
node and at the home agent.

As described earlier, the Binding Update and Binding Acknowledgement
messages already need protection even if they are not tunneled. As
these messages employ the Mobility Header in a similar manner to the
RR messages, one way to set up the Security Policy Database is to
protect all traffic to the mobile node and back with IPsec ESP if the
protocol in the packet is Mobility Header.

---

From: Parijat Mishra <[email-masked]>
Date: Wed, 10 Apr 2002 23:54:42 +0800

> calculations involving the authentication data.

I think what Jari meant was if the SPI is to be used for selecting 
BSAs then why is the only legal value defined as 0, and why must 
implementations discard messages containing other values?  I mean, 
how would one select one of many BSA's if the only BSA one can 
specify is BSA 0.

-- 
Parijat

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Apr 2002 09:52:13 -0700

The text needs to change to say that the SPI field is ignored.

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 10 Apr 2002 09:58:54 -0700

Hello Vijay,

I agree with this, except that it should say that
the SPI field SHOULD be ignored.  The intention is that
all implementations should ignore it unless they have
a very specific reason not to do so -- as I understand
to be the semantics of "SHOULD".

The specific reason to do so would be if a correspondent
node had alternative Binding Security Associations,
established by any means sufficient to authenticate
data supplied with the particular binding cache management
message to be authenticated.

The specific means could be by way of proprietary or
military-oriented key establishment protocols.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Apr 2002 10:21:37 -0700

The text looks good. But I still think a flag in the BU is
good. This is to let the MN dynamically turn on/off ESP
protection for tunneled RR messages.

for Example

if (link == public WLAN)
	turn on ESP for tunneled RR messages
if (link == cellular link)
	turn off ESP for tunneled RR messages

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Apr 2002 19:28:56 +0300

> protection for tunneled RR messages.

I'm not sure it's worth the complexity it brings. A flag is
a small thing, but implies complexity at the other end, and
on turning on/off things. Ideally, we shouldn't have to integrate
the MIPv6 and IPSec code too much.

Furthermore, it isn't clear to me that turning of the protection
saves so much that it would force us to think about ways to make
the turning on/off easier. It's symmetric crypto for a very short
message. It's probably faster than some of the MAC operations for
RR...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Apr 2002 20:01:09 +0300

> Agree with most of the text, except for section 11.

Excellent.

> why not make the MAX_COOKIE_LIFE also 300 seconds. 

MAX_COOKIE_LIFE determines the window between the time
you had to be able to send/receive the RR messages and the
sending of the BU. For most attacks that I can think of, the
time the BU is sent is the start of the attack. The BU might even
be sent from somewhere else than the claimed location of the MN.
The attack lasts upto MAX_RR_BINDING_LIFE seconds. In some attacks,
such as the bombing attack, the effects of the attack concentrate
on the beginning of the binding's lifetime.

There's also another aspect that is related to the cookie
lifetimes. The CNs are expected to at least try keeping the
cookies alive for MAX_COOKIE_LIFE seconds. Increasing the
value might make it harder to deal with deleted BCE entries
on a busy server (if you delete an entry, you have to either
invalidate the cookie at the same time or remember the entry for
some additional time).

But, let's face it that none of us knows exactly the right
times for RR.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Apr 2002 12:13:56 -0700

> the MIPv6 and IPSec code too much.

This integration is a simple call from MIPv6 code to the IPSec
code to instantiate a manually created ESP SA (in tunnel mode).
And MIPv6 code removes this SA when ESP tunnel protection is
to be turned off. I dont think it is too complicated.

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Apr 2002 14:05:40 -0700

Jari Arkko wrote:
> time the BU is sent is the start of the attack. 

The above is an important point. An attacker sending the BU
is the start of the attack.

> The BU might even
> The attack lasts upto MAX_RR_BINDING_LIFE seconds. 

And only upto to MAX_RR_BINDING_LIFE seconds.

> In some attacks,

Either way the MAX_COOKIE_LIFE does not increase the duration
of attack. So thats why I said MAX_COOKIE_LIFE does not add
to the vulnerability.

> invalidate the cookie at the same time or remember the entry for

This is true. But at the same time, see from the MN's side. 
A cookie lifetime of 300 seconds is very different from
a cookie lifetime of 180 seconds. If a mobile node (on an
average) moves every 200 seconds, it cant reuse the cookie
(just an example :-). It has to run RR everytime it moves.

> But, let's face it that none of us knows exactly the right

So lets go with 300 seconds. It atleast improves the handoff
performance for a longer duration without causing any 
additional harm.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Apr 2002 14:48:48 -0700 (PDT)

We don't need to allocate bits for people to make
non-standard protocols. There are a million other
ways they can achieve that.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Apr 2002 15:07:51 -0700 (PDT)

Jari,

I'm really confused. This seems rather complicated
on the face of it, but is there a possibility that
this could be expressed in the SDP instead? Ie,
select only MIP/HA traffic for the SA but allow
other traffic through untouched? That seems to do
the same thing from what I can tell.

	 Mike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Apr 2002 06:39:43 +0300

> the same thing from what I can tell.

Yes, that was my proposal. See second text paragraph at
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue14.txt

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Apr 2002 10:23:58 +0300

If the SPI field is ignored, how does one signal to the other end that
you are using some special, perhaps even proprietary, scheme to authorize
BUs? It seems to me that you would have been forced to include a
a flag or an extra option/parameter anyway, or?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Apr 2002 10:46:52 +0300

> of attack. So thats why I said MAX_COOKIE_LIFE does not add

Yes, but perhaps the duration of the attack is not the only
consideration. Presumably you could drive around the city and
collect cookies from vulnerable WLAN networks. If MAX_COOKIE_LIFE
is long, you can do this longer, or drive slower ;-)

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Apr 2002 09:53:27 -0700

> a flag or an extra option/parameter anyway, or?

Could be done in many ways. Maybe a flag in the BU is enough. 
Or local configuration in a bunch of nodes.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Apr 2002 09:55:23 -0700

> is long, you can do this longer, or drive slower ;-)

I still dont see it. yes, the attacker can go around, collecting
the cookies for a longer time. But no harm is done, till the 
attacker sends a BU to the CN. And after that happens, its
the MAX_RR_BINDING_LIFE which comes into picture. What am I 
missing?

Vijay