Subject: Re: [mobile-ip] Relationship between RR_BINDING and COOKIE_LIFE

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Jun 2002 23:47:15 +0300

Samita Chakrabarti wrote:

> It may have been discussed before, sorry if I missed the discussion.
> 
> I am a bit unclear on the actual binding lifetime as section 14.3
> of draft-17 states:
>    However,
>    one difference is that in basic IPv6 an on-path attacker must be
>    constantly present on the link or the path (e.g., in order to perform
>    a man-in-the-middle attack), whereas with Mobile IPv6 an attacker
>    can leave an existing binding behind, even after it is no longer on
>    the link or on the path [23].  For this reason, this specification
>    limits the validity of bindings authorized by return routability to
>    a maximum of MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE seconds after the
>    last routability check has been performed.
> 
> 
> Again in section 5.5.7 states:
> 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.
> 
> 
>    So, if RR has been performed at time t and then I expect that
>    the refresh should be performed before t+MAX_COOKIE_LIFE in order
>    to use the same cookie(s).

I think the intention of the "reusable" cookies is that you can change
your position quickly and reuse a cookie from an old position. With
the way they are currently defined, you might actually use them also
for refreshing the same binding. This wasn't the intention however.

>    However, if we keep the binding valid beyond t+MAX_COOKIE_LIFE
>    period, then anyway MN needs to do RR check again after cookie
>    lifetime expires. So, my point is what is the purpose of having
>    extended max binding life that is:
>    MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE ?
>    
>    Does it mean that frequency of RR check could be
>     MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE in the worst case.
>     
>    That means a BU can be as infrequent as 300 +240 = 9 min.

Yes. Section 14 seems a bit vague on this point. But the intention
was that the lifetime of any CN binding, when you create it, would
be limited to MAX_RR_BINDING_LIFE s. Now, you can still create this
binding with cookies that are MAX_COOKIE_LIFE s old.

Therefore, BUs must always be sent at least every MAX_RR_BINDING_LIFE
seconds.

Note that it would be possible to have the CNs inform the MNs about
the remaining cookie lifetime, or have the CN calculate real lifetimes
based on how old the cookies are. I'm not sure the complexity buys
enough. It's easier implementation-wise to keep the cookie and binding
lifetimes separate.

Jari