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