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

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 3 May 2002 17:13:42 -0700 (PDT)

Hi Jari,

Thanks much for taking the comments into consideration.
My response is in-line.

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

IMHO, SHOULD is quite weak statement. The whole point of
doing route optimization is to save round-trip time.
Now that we are solving the security issues, I think
route optimization is the feature that a CN (a CN could be
a MN) must implement. But obviously there SHOULD be a knob
on  MN side to turn it off and on.

Without RO, the roundtrip time now is even longer through the
reverse tunnel. Route optimization should be "MUST" for CN, IMHO.

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

Ok.

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

Ok, thanks. But the nonce indices would have to be valid (in system)
during the cookie-lifetime period.

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

Yes, it documents that Nj is only local value. 

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

Actually I am wondering as well how to clarify.
May be an example would be:
if cookie_lifetime  is  n sec, then how long does the Nj need to be
valid ? And during the n sec period, how many j or Nj should be
around in the sliding window so that we consider loss of BUs
or arrival of bogus BUs during MAX_COOKIE_LIFETIME.

Also, I am not quite clear on how we handle MIN_COOKIE_LIFETIME and
MAX_COOKIE_LIFETIME. Why exactly do we need MIN_COOKIE_LIFETIME ?
Is it more for implementors not to set cookie lifetime lower than
MIN_COOKIE_LIFETIME ?  So, if cookie Ko is set to MIN_COOKIE_LIFETIME,
does that mean the BU beyond MIN_COOKIE_LIFETIME, will not be accepted ?
Or should it still be accepted till MAX_COOKIE_LIFETIME, although it's
set to MIN_COOKIE_LIFETIME ? So, anyway we need to keep the cookie,
nonce, nonce-index around up to MAX_COOKIE_LIFETIME, so why do we need
a MIN value ? I mean to say whether just one value, COOKIE_LIFETIME 
is enough ?

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

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 ?

-Samita

---

From: Jari Arkko <[email-masked]>
Date: Sun, 05 May 2002 11:08:54 +0300

> reverse tunnel. Route optimization should be "MUST" for CN, IMHO.

This is a good argument. Why don't we create a separate issue for
this... I'll do that.

> valid ?

Cookies are valid exactly as long as both the nonces and Kcn used for
creating them are valid. I'll try to clarify this.

> And during the n sec period, how many j or Nj should be

I've been wondering about this myself. I'll file a separate issue on
this.

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

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.

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.

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

Jari