In your previous mail you wrote:
I discussed briefly with the authors. Your comment is consistent with
some other recent comments that the draft does not fully specify a
mobility and multihoming solution but only the readdressing mechanisms.
=> note that the only issue here is the (old) abstract doesn't reflect
the content of the document.
After thinking about your suggestion, I would be inclined to even
retitle the document to something like:
"Readdressing Extensions for HIP Mobility and Multihoming" to clarify
that there are other aspects of mobility and multihoming that are not
addressed. I would be inclined to keep "Mobility and Multihoming" terms
in the title, though, because it is part of the HIP charter to produce
such a document.
=> I have no problem with the title itself as soon as the abstract is clear.
Would you agree with the following abstract? If not, can you suggest
specific changes?
OLD:
This document defines mobility and multihoming extensions to the Host
Identity Protocol (HIP). Specifically, this document defines a
general "LOCATOR" parameter for HIP messages that allows for a HIP
host to notify peers about alternate addresses at which it may be
reached. This document also defines elements of procedure for
mobility of a HIP host-- the process by which a host dynamically
changes the primary locator that it uses to receive packets. While
the same LOCATOR parameter can also be used to support end-host
multihoming, detailed procedures are left for further study.
NEW:
This document defines readdressing extensions to the Host Identity
Protocol (HIP) to facilitate host mobility and multihoming.
Specifically, this document defines and specifies basic elements of
procedure for a general "LOCATOR" parameter for HIP messages. The
LOCATOR parameter allows a HIP host to notify peers about alternate
addresses at which it may be reached, and further allows it to
express policy preferences as to which address to use in different
situations when there exists more than one choice for a destination
address. Procedures for requiring a host to test the reachability of
alternate addresses are also specified. Using this basic
readdressing mechanism, limited forms of host mobility and
multihoming may be performed, but detailed procedures for a full
solution for mobility and multihoming are left for further study.
=> this new abstract is far better!
Question for the chairs/AD-- what do you think about changing the
document title at this date in the review?
> - in 5.4 page 31, I have a real concern with "the new SPI value
>SHOULD be random" because IPsec people took a real care to
>*never* put such a constraint on SPI values. I simply propose
>to not specify how to choose a new SPI value (out of the reserved
>range of course)
AFAIK, this comes from even the very first drafts on HIP by Bob
Moskowitz in 1999. The SPI is being used as an endpoint selector. I do
not know the security assumptions that led Bob to recommend the "SHOULD"
but I will ask.
=> I asked in the IPsec list whether SPIs should be random and the answer
was a loud *no*. IMHO there is not good reason to have such a constraint.
I believe we should simply ask the security ADs.
> - 3.2.3 page 13: question: what happens for addresses which are not
>in a locator? This is a generic issue, if we want to avoid
> this case
>the address selection rules (RFC 3484) should be prepended with a
>rule limiting the candidate set to locators
I think the question is whether a host may use an address that was not
learned during the base exchange or through the LOCATOR parameter. I
would suggest that such addresses, if learned out-of-band from the
mechanisms specified herein, be treated as UNVERIFIED addresses.
=> this is only a half solution as the interaction between the LOCATOR
notion (including the status) and the RFC 3484 has to be specified
(note this is an issue of RFC 3484: as soon as something new is introduced
the rule sets, which are in a standard track document, have to be amended
by another document at a similar level...). I can see you understand
the problem in the new P flag text.
If my proposed changes above are acceptable, the current open issues
are:
1) whether the title should be changed
2) the "SHOULD" for setting the SPI value randomly
3) the CBA draft references need to be replaced with a permanent
citation
4) should addresses learned out-of-band be treated as UNVERIFIED, and
words to that effect be put in the draft?
=> fine with me.
Thanks
[EMAIL PROTECTED]
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/ge
