Detail comments wrt. HIP on draft-irtf-nsrg-report-10.txt Last Call

[Pekka Nikander <[e-mail]>]

I have both more general comments on the draft, and a
number of detail comments with regard to the HIP section,
Section 2.3 in the draft.  This message contains only
the detail, HIP related comments.  I will raise my
more general comments separately.

Section 2.3 of the draft describes HIP.  While the description
is mostly accurate, it does not quite reflect the most recent
work on HIP.  To make the section more up to date with the
current work, I am providing a number of comments and making
some suggestions.  Please note that these comments or suggestions
do not present critisism against the draft; their sole purpose
is to update the HIP related parts of the draft up to date
with the more recent work.

Page 8, second last paragraph, last line:

   Current text:

     HIP attempts to address this [security threat] through
     the use of public key verification.

   Suggested new text:

     HIP attempts to address this through the use of public
     key verification and a Return Routability (RR) test, similar
     to the RR test used in Mobile IPv6 Route Optimization.

   A reference to the MIPv6 RO Security backgrounder,
   draft-nikander-mobileip-v6-ro-sec-01.txt, would probably
   be in place.  That draft explains the reasoning behind the
   MIPv6 RO RR test.

Page 8, last paragraph, last line, continuing to the next page:

   Current text:

     Because the value of a HIT is a hash in part, and only
     the administratively assigned value can be aggregated, ...

   Comment:

     The current HIP specifications contain detailed
     specifications only for HITs that are just the hash,
     and do not contain an administratively assigned part.
     In that respect the currently suggested HIT usage in
     HIP is closer to PBK than earlier.  However, the architecture
     still contains the provisioning for HITs that are different
     in structure, and may contain and administratively assigned
     part.

   Suggested new text:

     Because the value of a HIT may is a hash in part or in whole, the
     possibilities of controlling large numbers of HITs with a
     single administrative configuration entry may be reduced when
     compared to the curent situation with IP addresses.  On the
     other hand, since the HITs refer to public keys and since the
     signatures are sent in clear text in HIP control messages, future
     firewalls may verify the signatures and have more secure control
     over the traffic.

Page 9, second paragraph, starting with "On the other hand, there is..."

   Comment:

     It looks like there is something missing from the paragraph.
     As it currently stands, the paragraph does not make much sense.

Page 9, third paragraph:

   Comment:

     Even with a careful reading of the HIP architecture draft version
     -02 (the referred one) or -04 (the current one), I could not
     find explicit discussion of how to use domain names.  If this
     paragraph refers to Section 5.3 of the -02 version of the HIP
     archi draft, on Host Assigning Authority (HAA) field, then I
     would suggest a much more careful wording on the paragraph.
     Furthermore, the refernence to the old version of the draft has
     to be retained, since the current version of the HIP architecture
     draft does not explicitly discuss the HAA field any more.

     Unfortunately I do not fully understand the message that the
     paragraph is trying to convey, and therefore I cannot provide
     a suggestion for new text.  Maybe the paragraph should just be
     removed.

Page 9, fourth paragraph:

   Comment:

     The new version (-04) of the HIP architecture draft explicitly
     discusses the concept of a HIP rendezvous server.  The rendezvous
     provides a service similar to the Mobile IP home agent to fast
     moving HIP hosts.  HIP hosts that change their IP address only
     occasionally may not need the services from a rendezvous server,
     and use Dynamic DNS instead.

   Suggested new text:

     A key concern with HIP is whether or not it will work in a mobile
     world.  The HIP architecture proposes a new infrastructure
     component, called the HIP rendezvous service, which provides
     services similar to the Mobile IP home agent for fast moving HIP
     hosts.  Since the rendezvous server needs to pass only a few
     packets, until HIP peers can communicate directly, the expected
     load on a rendezvous server is verly light.

     Compared to Mobile IP, there is an important difference.  That is,
     even a fast moving HIP host is not dependent on the rendezvous
     server; a host can have several rendezvous servers at the
     same time, or change them in the fly.  The life of existing
     connections is in no way bound to the rendezvous servers.

Page 22, reference 21:

   Comment:

     The currentversion of the HIP architecture draft is -04.  There
     will be a -05 version before Minneapolis deadline.  It may also
     be appropriate to refer also to the actual protocol specification,
     which is currently draft-moskowitz-hip-07.txt.  A new version -08
     will be released before the Minneapolis deadline.

     Depending on the above comment about the HAA field, it may also
     be necessary to retain a reference to the old -02 version of the
     architecture draft.

--Pekka Nikander