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

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 31 May 2002 19:35:16 -0700 (PDT)

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).
   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.
   
   I wonder, why  are we allowing the binding to remain valid
   up to MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE sec, should not
   it be just MAX_RR_BINDING_LIFE sec, where
   MAX_RR_BINDING_LIFE = 300 sec
   MAX_COOKIE_LIFE = 240 sec

   Thanks,
   -Samita