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

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 13 Aug 2002 14:57:05 -0400

Hi

I have some questions about Section 5 (Security) in
draft 18.

1.  Multiple subsections use the symbol '|' in the cookie
     and key calculations.  Does this symbol mean "concatinate"
     or "Logical OR"?  (my guess is "Concatinate").  If my guess
     is correct, in what order are the bits concatinated (i.e
     cookie | none == ((cookie << 64) | nonce)?

2.  Section 5.2.5 uses a function First64() in calculating home
     and care-of cookies.  Which bits are assumed to be the first
     64 bits?

3.  There doesn't appear to be a section on processing and validating
     Binding Updates.  Is it enought to make sure that authenticator
     matches, or should the entire HMAC match?  (My guess it the
     entire HMAC).

4.  Section 5.2.7 says the following:

     "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."

    I find this paragraph highly confusing from the point of view of a
    correspondent node.  This paragraph implies that the correspondent
    should timeout and therefore cache cookies, but the whole assumption
    behind RR is that correspondent doesn't keep state per mobile node until
    BU had happened.  So, in effect, the corresondent times out nonces every
    MAX_COOKIE_LIFE seconds.  Is my understanding correct?

Depending on the replies to the above, I might have more questions,
but I'll hold them for now.

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 13 Aug 2002 19:00:26 -0700 (PDT)

> However under Home Agent Operation for shake of clarity I would like to 
propose some lines of description how a static SA is used to validate the MN-HA 
BUs. Current text that describes in 10.2 "Primary Care-of Address Registration" 
starts with an assumption that the BU is valid. But says nothing how the 
validation is done. Later in  section 10.3 "Primary Care-of address 
De-Registration" the text finally refers to Section 9.4.1.
> 
> However section 9.4.1 has been written Return Routability in mind that doesn't 
apply as such with the home agent that has IPsec SA. 

Agreed.  Currently Section 10 (Home Agent Operation) is missing a
section on "Processing Binding Updates". A section seems to be necessary
to describe HA's processing of binding updates from MN.

-Samita

> -----Original Message-----
> From: ext Vladislav Yasevich [mailto:[email-masked]]
> Sent: 13 August, 2002 11:57 AM
> To: MobilIP
> Subject: [mobile-ip] Question about MIPv6 draft 18
> 
> 
> Hi
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 15 Aug 2002 15:27:58 -0700 (PDT)

> > 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).
> 
> 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...
> 

Oops. I did not see that the MAX_COOKIE_LIFE is now changed from 180 to 240.
It was 180 sec  before ( I think, draft 16). 

> > 
> > 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.
> 
> 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.
> 

True.

> >  
> >  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). 
> 
> 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.
> 

After thinking about it a bit, I realized that this situation would be 
rare and in those cases, MN should restart RR procedure.

> >  
> >  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. 
> 
> "Updating Node Keys, Nonces and Cookies"  ;)
> 

Yes, that was not correct. So we need to come up with a better sub-heading.

> 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.

Actually, I looked at the hardcopy of draft 16, the explanation on nonce
and Kcn updates using examples (Nj, N(j+1)) seems to have more information
than that in draft 18. Some text similar to that would be helpful (in 
section 5.2.7  of draft 18) for implementors.

Thanks,
-Samita