Subject: [Gen-art] review (full) of draft-ietf-hip-mm-05.txt

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Apr 2007 23:34:43 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-hip-mm-05.txt
Reviewer: Francis Dupont
Review Date: 03 April 2007
IESG Telechat date: 05 April 2007

Summary: Not Ready

Comments:
 - as I wrote in the summary message, IMHO the abstract needs a
  full rewrite

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

 - I believe the reference [3] (Rendez vous) should be made not
   normative. Perhaps the introduction wording needs to be adapted
   (I don't believe so but you should check with your AD)

(minor points)

 - abstract page 2, intro page 4, 3.2.3 page 14, 3.2.5 page 15,
   3.3.4 page 21: I prefer a space before -- (as it is the rule
   in French, the language the construct is from :-)

 - intro page 4: double (and too close) usage of the word "possible"

 - 2 page 6: perhaps the right place to introduce the status keywords
   and locator types

 - 3.1 page 9: the "for fault tolerante" is too restrictive, I propose
   to add "for instance"

 - 3.1.2 page 10: other transport modes -> formats?

 - 3.2.1 page 12: first use of the status keywords (UNVERIFIED,
   DEPRECATED and ACTIVE)

 - 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

 - 3.2.3 page 13: in "However, it is recommended that implementations
   attempt to support peers that prefer to use non-paired SAs" why not
   RECOMMENDED? (BTW to avoid this kind of question the best is to
   use a synonym in the place of a lower case keyword)

 - 3.2.3 page 14: first use of locator types (and without any hint
   about what there are for a new reader)

 - 3.2.7 page 16: some type of mechanism -> mechanisms?

 - 3.3.3 page 20: draft -> document/text/... (but not draft! :-)

 - 3.3.4 page 21: "unless the ESP anti-replay window is loose"???
                                                        ^^^^^
   I suggest "is large enough"

 - 3.3.4 page 22: I don't (want to) understand what you mean by
   "at least reset its ESP anti-replay window"
             ^^^^^

 - 4 page 24: the P (preferred) flag is underdefined. It seems
   according to 5.5 -3 it is in fact a hint. So it can be an
   answer to my question: is it possible to set zero or more than
   one P flag to one?

 - 4.2 page 25: th locator type must be introduced before!

 - 5.1 page 26: the status must be introduced before!

 - 5.2 page 27 and 5.3 page 30: the IPv6 undefined address should
   be added to the illegal addresses (i.e., with broadcast and
   multicast)?

 - 5.5 -3 page 33: I really don't like the idea to pick randomly
   an address. Why not using the RFC 3484 rules?

 - 5.6 page 33: to stay polite and because my own opinion is already
   well known, I shan't say what I think about the CBA mechanism...

 - 7 page 42: the Section 5.3 doesn't "define this parameter with
   a Value of 46" (easy but mandatory to fix as the IANA consideration
   will stay)

 - appendix A page 44: the usage is to specify the appendix will be
   removed by the RFC editor

Regards

[email-masked]

PS: IMHO the document provides readdressing which is a limited form
of mobility (as explained inside the document, so the issue is in the
wording) and a limited form of multihoming too. Perhaps the source of
the problem is the mixed between the mechanism and its usage?

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 9 Apr 2007 10:21:11 -0700

Francis,
Thank you for the extensive review.  I will respond inline to each of
your points.  At the end of the message, I will discuss possible next
steps and open issues.

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 2:35 PM
> To: [email-masked]
> Cc: Henderson, Thomas R; [email-masked]
> Subject: review (full) of draft-ietf-hip-mm-05.txt
> 

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.

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.

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.

Question for the chairs/AD-- what do you think about changing the
document title at this date in the review?

>    to not specify how to choose a new SPI value (out of the reserved

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 don't believe so but you should check with your AD)

I agree to shifting this to informative, because it is just there for
informational purposes.

>    in French, the language the construct is from :-)

changed

>  - intro page 4: double (and too close) usage of the word "possible"

changed

>  - 2 page 6: perhaps the right place to introduce the status keywords

I have introduced these earlier, as you suggested.

>  - 3.1 page 9: the "for fault tolerante" is too restrictive, I propose

changed

>  - 3.1.2 page 10: other transport modes -> formats?

changed
>  - 3.2.1 page 12: first use of the status keywords (UNVERIFIED,

changed (noted above)

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

>    use a synonym in the place of a lower case keyword)

changed to RECOMMENDED

(I think this is the only case in the document where
s/recommended/RECOMMENDED is needed)

>    about what there are for a new reader)
changed (noted above)

>  - 3.2.7 page 16: some type of mechanism -> mechanisms?
changed

>  - 3.3.3 page 20: draft -> document/text/... (but not draft! :-)

changed to document

>    I suggest "is large enough"

changed

>    "at least reset its ESP anti-replay window"

I deleted this clause.

>    answer to my question: is it possible to set zero or more than

Section 4.1 attempted to define this, but I will make this a bit more
explicit
in section 4.1:

   The "P" (preferred) bit, when set, has scope over the corresponding
   Traffic Type.  That is, when a "P" bit is set for Traffic Type "2",
   for example, it means that the locator is preferred for data packets.
   If there is a conflict (for example, if P bit is set for an address
   of Type "0" and a different address of Type "2"), the more specific
   Traffic Type rule applies (in this case, "2").  By default, the IP
   addresses used in the base exchange are Preferred locators for both
   signaling and user data, unless a new Preferred locator supersedes
   them.

   The Preferred bit is a hint that identifies the locator(s) on which
   the receiver prefers to receive traffic.  The sender of the LOCATOR
   MAY explicitly select one or more locator for each traffic type as a
   preferred locator.  The corresponding host sending data packets MAY
   select any active, in-scope locator for a given Traffic Type, but it
   is RECOMMENDED that Preferred locators be used when all other
   considerations are equal.  If there are more than one Preferred
   locators to choose from, the sender may select from among them
   according to [4] or local policy.  If no Preferred locators are
   identified or usable, then the sender may again select from the
   active locators according to [4] or local policy.

where [4] is RFC3484.

>  - 4.2 page 25: th locator type must be introduced before!

changed (noted above)

>  - 5.1 page 26: the status must be introduced before!

changed (noted above)

>    be added to the illegal addresses (i.e., with broadcast and

added

>    an address. Why not using the RFC 3484 rules?

I agree that it would be better to cite RFC 3484, so I've changed it to
say that the host picks according to RFC3484 or local policy.

>    well known, I shan't say what I think about the CBA mechanism...

no change.

However, there is an outstanding open issue here which is that the
citations have expired.

>    a Value of 46" (easy but mandatory to fix as the IANA consideration

I changed this text as follows below:

   This document defines a LOCATOR parameter for the Host Identity
   Protocol [2].  The LOCATOR Parameter Type value is specified in
   Section 4.

   This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message
   Type for the NOTIFICATION parameter defined in the Host Identity
   Protocol specification [2].  The value for the Notify Message Type of
   LOCATOR_TYPE_UNSUPPORTED is specified in Section 5.3.

>    removed by the RFC editor
I added a note to this effect, as is customarily done.

----------

I have posted a candidate -06 version at the following URL, and will
wait for either feedback or guidance from the chair as to how to
proceed.  
http://www.openhip.org/ietf/drafts/draft-ietf-hip-mm-06-pre.txt

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?

Regards,
Tom

---

From: Francis Dupont <[email-masked]>
Date: Tue, 10 Apr 2007 20:08:44 +0200

In your previous mail you wrote:

=> note that the only issue here is the (old) abstract doesn't reflect
the content of the document.

=> I have no problem with the title itself as soon as the abstract is clear.

   OLD:

   NEW:

=> this new abstract is far better!

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

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

=> fine with me.

Thanks