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

From: [email-masked]
Date: Tue, 13 Aug 2002 17:41:33 -0700

Vlad

About your question 3 there is a section describing BU processing and validation in 9.4.1 "Receiving Binding Updates". So this should be covered.

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. 

Regards 
Hannu

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

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: Vladislav Yasevich <[email-masked]>
Date: Thu, 15 Aug 2002 16:34:07 -0400

Hi

I have a comment about authorization of BAcks in draft 18.

They way I interpret the spec, if the BU has the Authorization
Data option, BAck must contains this option as well.  I get this
out sections 5.2.6 and and 9.4.4.

However, section 6.2.7 "Binding Authorization Data" says:
"  ...                  This specification gives the rules only for
    the return routability procedure.  For this procedure, this option
    can only appear in a Binding Update message and rules for calculating
    the Authenticator value are described in Section 6.1.7."

This seems to restrict Bindgin Authorisation Data only to BUs.
Also, going and reading 6.1.7, I can't find the rules for calculating
the Authenticator value.  I think the reference needs to be fixed as well.

-vlad

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Aug 2002 13:12:34 +0300

> This seems to restrict Bindgin Authorisation Data only to BUs.

Yes, this is a left-over from the time that we only had BU authorization.
This needs to be fixed. Suggested new text:

      For this procedure, this option
      can only appear in the Binding Update and Binding Acknowledgement messages
      and rules for calculating the Authenticator value are described in
      Section 5.2.6.

> the Authenticator value.  I think the reference needs to be fixed as well.

Fixed above.

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 21 Aug 2002 09:19:17 -0400

Jari

>      and rules for calculating the Authenticator value are described in

Thanks, that works...

-vlad