Subject: [mobile-ip] More comments on Draft16 -CLARIFICATION

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 24 Apr 2002 15:28:10 -0700 (PDT)

After some internal discussions we think, the following items should be
clarified in the next revision of the MIPv6 draft.

BTW, there is one recommendation for adding one more BA status as well.

Here are the comments:

1.
In the draft, we must make sure to clearly specify that reverse tunnel
is mandatory now for mobile node and home agent. I am not sure, which
section this information should go to.

2.
Also, we have had email discussion that only HOT message is sent in
ESP tunnel mode. For symmetry, we should mandate ESP tunnel mode for
both HOT/HOTI messages between MN-HA.

Also, we need to clarify in the draft that ESP tunnel mode must(?) be used
over the MN-HA tunnel for binding update signalling HOTI/HOT traffic
only. The regular data traffic through the same MN-HA tunnel may not 
necessarily be protected by ESP.

3.
section 4.5.5

This section should clarify whether route optimazation through binding
update to a CN is a MUST or optional.
Also, for better understanding and clarification of crypto handling,
it would be very helpful if this section offers several subsections,
for example:

Cookie(Kcn) generation procedure
--------------------------------

Should talk about how Kcn should be generated. It should talk about
the size and data type of Kcn.

Cookie update
---------------

Whether Kcn should be updated periodically. What is the default or
recommended update mechanism ? 
When Kcn value is changed, then how long should one keep the old
Kcn around in order to accept a BU which is on flight while the
Kcn got changed.

Nonce generation procedure
-----------------------------

Nonce index is a 16 bit quantity. So what would be the default 
recommendation for sequence of index values for which the cookie
would be valid ? Should it correspond to COOKIE_MIN_LIFETIME ?

What is data type and size of Nj ?

I understand that Nj == j is acceptable, because Nj is  locally 
known to CN, do we need to document that ? 

A calculation or relationship between COOKIE LIFETIME and 
nonce-index and nonce generation method would be useful for
implementors to maintain interoperability.

Nonce update  
------------
How j values and Nj values should be stored and updated in the
system ?

RR signaling procedure
----------------------

The current 7 steps could be re-written in such a way which can
clearly specify the sequence and parallel steps and which of
them going via HA and which of them are not. BU messge does not
go via HA-right ? It should clarify that here. A diagram may be
useful.

Each HOTI/COTI/HOT/COT/BA/BU/BR messages should specify the source
and destination address of the packet. Whether it's tunneled or
not. If tunneled if there is any security protocol to be used.
It should also specify data type and size of K0, K1 and how they
should be formed in terms of implementation. Each item should
also refer to the Message Authentication section below.

Message Authentication
----------------------
This section  should specify the HMAC-SHA1 and how it could be
used. It should specify how the output value of HMAC-SHA1 be
considered for K0 or K1 (96bit value). What is the input value
size of HMAC_SHA1 function here ?

It's confusing whether MAC-Kcn is meant to use HMAC-SHA1 with key
Kcn, please clarify the notation.

Hash Function
---------------
Should talk about the recommended hash function to compute Kbu.

section 5.1.8  BA messages

I understand that Alt COA and Unique identifier parameters are
optional. Should not we have a BA status value when these parameters
are not supported ?
i,e

146

 Parameter type not supported

--------------------------------------------------------------------

Thanks,
-Samita