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

From: Jari Arkko <[email-masked]>
Date: Fri, 03 May 2002 01:33:06 +0300

Thanks a lot for your commens Samita! I have taken them in account now.
Some further discussion below.

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

Yes.

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

Yes. This is especially important given the mobile-side cookies for
weak CoT/HoT authentication (prevention of random nodes from the
internet spoofing these).

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

Yes.

> 3.
> section 4.5.5
> 
> This section should clarify whether route optimazation through binding
> update to a CN is a MUST or optional.

Yes. There will be a new section under chapter 7,

Requirements for All IPv6 Hosts and Routers that

describes this. It currently reads SHOULD be able to
participate in a return routability procedure etc.

> Also, for better understanding and clarification of crypto handling,
> it would be very helpful if this section offers several subsections,
> for example:

Yes.

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

Yes. 20 bytes.

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

Yes.

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

There is no default recommendation. The index values can't be
used to infer anything. The mobile should expect to get a cookie
that is valid at least COOKIE_MIN_LIFETIME seconds. I'll try
to clarify this.

> What is data type and size of Nj ?

Yes. 16 bytes.

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

I believe this was already described in the explanation for the
CoT message in the flow of 4.5.5.

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

Can you clarify what you would like to see?

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

Yes, will be clarified.

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

Yes.

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

Yes. Will do...

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

Yes it is. Will be clarified.

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

Now it does.

> 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

I believe their use is optional, not support?

Jari

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 8 May 2002 17:15:39 -0700 (PDT)

Sorry, I am a bit behind the mails in the alias.

> > Yes, their use is optional. So, if a CN receives a message with 
> > alt COA (for example) and if it does not know how to process it,
> > should not it send BA with status that this parameter type is
> > not supported ? If we don't have such a status, what should CN
> > send to MN in this case ?
> 
> I suppose there are four different possible cases:
> 
> 1) A mandatory-to-support parameter in a legal position in some message. E.g.
>     Alt-CoA in a BU. I don't think the CN should be allowed to complain about 
this.

Do you mean to say  Alt-CoA in BU (ie. parameter type =3) could be 
mandatory to support ?

> 2) A mandatory-to-support parameter in a bad position, e.g. Alt-CoA in a BA
>     when the BU didn't contain any Alt-CoA. I'm not quite sure what we should 
do
>     about this.

Drop the packet  or optionally send "reason unspecified" ? But that is not
very clear message. 

> 3) A parameter that isn't defined in the base standard but whose support is
>     mandatory. I'm not sure we want to have these.
> 

Agree.

> 4) A parameter that isn't defined in the base standard and which is optional.
>     No problem here.
>

So  what do we do in this case ? This is the case I am concerned about.
Shouldn't CN send a BA with a status error if acknowledgement is requested ?
What that error should be ? Or do we send MH error header back in this case?

One way is to drop the packet (if ACK is not requested), otherwise send BA with 
a
"parameter type not supported" status error with the BA if ACK is requested.

Thanks,
-Samita