Subject: Re: [mobile-ip] Question about MIPv6 draft 18

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 14 Aug 2002 20:31:21 -0700 (PDT)

Hi Vlad,

> >>Yes, but the time window on the nonce only slides when the cookie
> >>for a CoT or a HoT are computed, not everytime.
> >>
> > 
> > 
> > I am not sure what you mean by this, could you please explain ?
> 
> 
> I'll try...
> 
> A nonce is valid for MAX_COOKIE_LIFE after the cookie is generated
> to make the cookie valid.  So, for every (new) cookie that's generated from
> a nonce, the time that the nonce and the cookie are valid stides out to 
> MAX_COOKIE_LIFE.  But, conceptually, cookies are originally generated for
> HoT and CoT messages only. They just will need to be recomputed to figure
> out Kbu.  So, my assumption (and this is just my assumption) is that the
> timeout on the nonce is reset only when the cookies are computed for HoT and
> CoT messages.  Otherwise nonces, and thus cookies, might be kept for much
> longer then intended.
> 
> Does that make sense?
> 

Let me see if my understanding is correct...

For example, if nonces are generated in every 10 sec, then there will be
about 20 (18 + 2 extra) nonces will be valid for MAX_COOKIE_LIFE (180sec).

So for a 10 sec period at a given time, there might be 5 HOTI/COTI messages
from 5 MNs; they all will use same Ni, Nj even though their cookies are
different and so is the expiry time for each cookie, depending on when they
are generated. So, if one HOTI or COTI message is received at t+9 sec, when
t= Nonce Nj generation time, then this Nj cannot expire until after
 10+MAX_COOKIE_LIFE sec. Are you saying that the nonce timeout value should
 be updated everytime a cookie is created ?  That may be possible, or simply
 setting to the max value (nonce generation value + COOKIE_LIFE_TIME + delta)
  may save some CPU cycles.
 
 But, I think the draft should specify the "delta" value. "delta" value is
 the extra time a old nonce to be around to make sure that nonce does not
 disappear between sending HOT/COT and receiving BU. 
 This value should depend on the RTT of max (COT path , HOT path). 
 
 Also, I agree with you that the draft is unclear about managing nonce
 and nonce-indices and their generation frequency.
 
 Section 5.2.7 ( Updating Node Keys and Nonces) needs to specify the 
 nonce timeout logic more clearly than it is now. The second and third 
 paragraph of this section mostly talks about the cookie lifetime which
 is confusing in the context of Nonces. 
 
 Perhaps the heading needs to change to say " Updating Node Keys and Nonces and
 Cookies" and add one more paragraph on Nonce timeout procedure. 
 
 Copying to Jari Arkko for his comments.
 
 -Samita

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 15 Aug 2002 09:20:20 -0400

> about 20 (18 + 2 extra) nonces will be valid for MAX_COOKIE_LIFE (180sec).

I thought MAX_COOKIE_LIFE was 240?   This brings up another possible
problem.  The MAX_COOKIE_LIFE duration at a mobile node SHOULD not be
smaller that at the correspondent node (assumig MAX_COOKIE_LIFE is
configurable).    Otherwise, the situations where RR will succeed, but BU
fail due to nonce timeout will become very likely.  This might be something
that needs to be in the draft...

>   may save some CPU cycles.

I was saing that that nonce timeout value needs to be updated every time a
"new" cookie is generated from a given nonce.  The "new" cookie is a cookie
that is generated for the first time, usually during processing of HoTI and
CoTI messages.  This means that any cookie generation as part of the BU
processing does NOT effect the current timeout value of a nonce.

Also, using your example,  I would actually say that the Nj can not
expire until after t+9+MAX_COOKIE_LIFE, but that's a more conservative
estimate.

>  This value should depend on the RTT of max (COT path , HOT path). 

This would be extremely rare as the mobile node would have to delay
MAX_COOKIE_LIFE-RRT(mn-cn path) to send a BU after RR is complete.
The recovery mechanims is in place and the mobile will succeed eventually.

>  Cookies" and add one more paragraph on Nonce timeout procedure. 

"Updating Node Keys, Nonces and Cookies"  ;)

Section 5.2.2 states the following:
"  ...                                      Expected validity times for
    the nonces values and the procedures for updating them are discussed
    later in Section 5.2.7. "

As we see now, 5.2.7 does not talk about nonces.

>  Copying to Jari Arkko for his comments.

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