Subject: [mobile-ip] Mipv6 issue #103: unclear cookie lifetimes

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Oct 2002 01:37:54 +0300

I'm working on closing this issue. There are in fact multiple
related problems:

1) The current text in 5.2.7 indicates that the cookies are
    kept by the correspondent node, which is incorrect.
    Proposed resolution: the text should be changed to
    talk about nonces instead (see below).

2) The text doesn't adequately describe how to implement
    cookie lifetimes, and nonce lifetimes of "few minutes"
    (as indicated) would make it hard to provide accurate
    cookie lifetimes. Proposed resolution: an easy way
    to implement this is to have a shorter nonce lifetime.
    The current draft is misleading on this.

3) We should clarify that nonce lifetimes only need to
    be computed when RR signaling occurs; unused nonces
    don't get old. Proposed resolution: clarify this
    in the text.

4) We need to specify allowed delta for cookie lifetimes, to avoid
    updating nonce lifetime for every answered HoTI/CoTI
    message. Proposed resolution: This is already partially taken care
    of, as the cookies SHOULD be kept as long as possible, but MUST NOT
    be kept more than MAX_COOKIE_LIFE. We still need to ensure that MNs
    don't use cookies during the period that an implementation which
    uses nonce again produces. In order to do this, we introduce a new
    constant MAX_NONCE_LIFE which is slightly higher than
    MAX_COOKIE_LIFE. MNs are expected to use MAX_COOKIE_LIFE, while CNs
    use MAX_NONCE_LIFE.

5) MAX_COOKIE_LIFE, if configurable, should not be higher in the MN
    than in the CN. Proposed resolution: Given that there can be no
    pre-configuration for the MN-CN relationship, MAX_COOKIE_LIFE
    should stay as a constant.

Proposed text changes are as follows. In Section 12, introduce
the constants:

      "MAX_NONCE_LIFE           240 seconds
       MAX_COOKIE_LIFE          210 seconds"

and then refer to the correct constant in the relevant sections of the
specification. In Section 5.2.2, change

     "Each correspondent node also generates nonces at regular intervals,
     for example every few minutes."

=>

     "Each correspondent node also generates nonces at regular intervals."

In Section 5.2.7, change

     "An update of Kcn can be done at the same time as an update of a
     nonce, so that the nonce index identifies both the nonce and the
     key.  Old Kcn values have to be therefore remembered as long as
     old nonce values.

     Before sending a Binding Update, 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
     node 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 as long as possible and SHOULD NOT accept
     them beyond MAX_COOKIE_LIFE seconds.

     Given that the cookies are normally expected to be usable for some
     time, 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."

=>

     "Correspondent nodes generate nonces at regular intervals. It is
     recommended to keep each nonce acceptable for at least
     MAX_COOKIE_LIFE seconds after it has been first used in
     constructing a return routability message response. However, the
     correspondent node MUST NOT accept nonces beyond MAX_NONCE_LIFE
     seconds after the first use. As the difference between these two
     constants is 30 seconds, a convenient way to enforce the above
     lifetimes is to generate a new nonce every 30 seconds. The node can
     then continue to accept cookies that have been based on the last 12
     (MAX_NONCE_LIFE / 30) nonces. This results in cookies being
     acceptable MAX_COOKIE_LIFE to MAX_NONCE_LIFE seconds after they
     have been sent to the mobile node, depending on whether the cookie
     was sent at the beginning or end of the first 30 second period.
     Note that the correspondent node may also attempt to generate new
     nonces on demand, or only if the old nonces have been used. This
     is possible, as long as the correspondent node keeps track of
     which how old the nonces are, and does not generate new
     nonces on every return routability request.

     Due to resource limitations, rapid deletion of bindings, or
     reboots the correspondent node may not in all cases recognize the
     nonces that the cookies were based on. If a nonce index is
     unrecognized, the correspondent node replies with an an error code
     in the Binding Acknowledgement. The mobile node can then retry the
     return routability procedure.

     An update of Kcn SHOULD be done at the same time as an update of
     a nonce, so that the nonce index identifies both the nonce and the
     key. Old Kcn values have to be therefore remembered as long as old
     nonce values.

     Given that the cookies are normally expected to be usable for
     MAX_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."

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 07 Oct 2002 11:30:31 -0400

Jari

The text you proposed is much better.  Thanks.

A few editorials comments

>     then continue to accept cookies that have been based on the last 12

MAX_NONCE_LIFE/30 = 8 :)

>     nonces on every return routability request.

The last sentence has an extra "which".

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 10 Oct 2002 11:01:23 -0700

Hi,

I would like some clarification. Sorry if these have
been discussed earlier..

-Rajeev

> Why not keep MAX_COOKIE_LIFE at 240 s ?

>      correspondent node MUST NOT accept nonces beyond MAX_NONCE_LIFE

When you say CN must not accept nonces, isn't the MN only providing the
nonce indices ? _Should_ the MN even worry about how the CN
manages its nonces ?

>      (MAX_NONCE_LIFE / 30) nonces. This results in cookies being

So, a CN has to verify a cookie against 8 possible nonces ?
Isn't this more work ?

>      key. Old Kcn values have to be therefore remembered as long as old

Is it Home Nonce index or Care of Address nonce index ?

>      agent may be longer, and consequently this optimization is often

Even if the RTT is shorter, this is useful in terms of the number of
messages sent.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Oct 2002 23:25:23 +0300

>>Why not keep MAX_COOKIE_LIFE at 240 s ?

Well, MAX_NONCE_LIFE is the vulnerability. In some cases
we see as long as 240 s lifetimes. Note that we don't actually
say the MN shouldn't be using them beyond 240 s... just that
it gets more unlikely that they are still valid.

>>     correspondent node MUST NOT accept nonces beyond MAX_NONCE_LIF
> 

You are right about the nonce indices. Perhaps we should add
".. keep each nonce (identified by a nonce index) acceptable ..."

>>     (MAX_NONCE_LIFE / 30) nonces. This results in cookies bein
> 

No, we still have nonce indices. The number of valid nonces can be
as large as you want (within the range provided by nonce indices) and
the amount of work will still be the same.

>>     nonce values

Either one. Maybe it should have read "... nonce indices can identify ..."

> Even if the RTT is shorter, this is useful in terms of the number of

Right.

Jari

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 15 Oct 2002 11:15:35 -0700

Hello Jari,

sorry for the delay in responding..

> it gets more unlikely that they are still valid.

Well, the text should clearly indicate that the MN only
keeps account of COOKIE_LIFETIME. I am still not
sure how you would like the MN to deal with NONCE_LIFETIME..
From the text above, it seems like the MN _should_ keep an eye on
NONCE_LIFETIME, else be prepared to receive an error. I would
rather have such text avoided.

> > Even if the RTT is shorter, this is useful in terms of the number of

Would it be possible to add a sentence to this effect ?

Thanks,

-Rajeev

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 15 Oct 2002 15:06:14 -0400

> rather have such text avoided.

Right.  The MN should not care what NONCE_LIFETIME is.  That's
only need by the CN.  The MN, on the other hand has to track COOKIE_LIFETIME
and SHOULD NOT use a cookie after the lifetime has expired.

-vlad
--

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Oct 2002 23:31:21 +0300

Rajeev Koodli wrote:

>>it gets more unlikely that they are still vali
> 

What text? Perhaps my e-mail above was unclear, but the text
proposal talked only about MAX_COOKIE_LIFE for MNs:

     Given that the cookies are normally expected to be usable for
     MAX_COOKIE_LIFE seconds, the mobile node MAY use them beyond a
     single run of the return routability procedure.

Ok?

>>Right

And the text proposal is:

     While this does
     not save roundtrips due to the parallel nature of the home and
     care-of return routability tests, there are less messages and the
     roundtrip through the home agent may be longer. Consequently this
     optimization is often useful.

Complete text at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue103.txt

Jari

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 15 Oct 2002 14:41:46 -0700

> What text? Perhaps my e-mail above was unclear, but the text

The text in your original reply.

>      single run of the return routability procedure.

How about

"The MN may re-use a cookie until MAX_COOKIE_LIFETIME
expires." ?

>      optimization is often useful.

Minor suggested changes: "While this does not save the number of round-trips due
to the simultaneous processing of home and care-of return routability
tests, there are fewer messages being exchanged, and a potentially
long round-trip through the home agent is avoided. Consequently, this
optmization is often useful. "

-Rajeev