Re: Last Call: draft-ietf-hip-applications (Using the Host Identity Protocol with Legacy Applications) to Experimental RFC

[Pekka Savola <pekkas at netcore.fi>]

On Mon, 14 May 2007, The IESG wrote:
> The IESG has received a request from the Host Identity Protocol WG (hip)
> to consider the following document:
>
> - 'Using the Host Identity Protocol with Legacy Applications '
>   <draft-ietf-hip-applications-01.txt> as an Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf at ietf.org mailing lists by 2007-05-28. Exceptionally,
> comments may be sent to iesg at ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.

Some slightly late comments below.

My main (meta-) issue with the draft is that it's not clear from how 
the draft is written what is the goal of the draft.  It seems it's 
providing an informative overview of different approaches for HIP 
experiments; it does not aim to provide any normative specification 
for HIP implementations or applications, even to make the experiments 
using different approaches to use more uniform methods.

Is this correct? If yes, maybe this could be made more explicit, e.g., 
by adding 'Overview on' at the start of the title and similar other 
modifications.  On the other hand, if this spec is intended to be used 
somehow by HIP or application implementations, I believe text would 
likely need significant rework; there is very little explicit guidance 
or explicit specification as it is and very little text that would 
help in creating interoperable implementations.

substantial
-----------

   While the text below concentrates on the use of the sockets connect
   system call, the same argument is also valid for other system calls
   using socket addresses.

==> I'm not sure if I will accept this assumption at its face value 
without a reference.  Are you sure all the socket-operating system 
calls are basically equivalent? Has this been studied somewhere 
(Miika/Mika's Master's thesis as one example?) more extensively?  For 
example, what does listen(LSI) or bind(LSI) mean?  Section 3.4 seems 
to discuss this a bit implying that all the socket system calls aren't 
necessarily similar.

   Using DNS to map IP addresses to HIs:

      If the responder has host identifiers registered in the forward
      DNS zone and has a PTR record in the reverse zone, the initiating
      system could perform a reverse+forward lookup to learn the HIT
      associated with the address. [...]

==> does this cause a recursion problem with DNS resolver IP addresses?  I.e., you try
to look up HIP records by reverse+forward of node X by doing queries to DNS
servers A and B, but end up querying DNS reverse+forward records of A and B
through DNS first.  I think this should work under normal circumstances
but I can see some potential reliability issues; at least if the DNS server
addresses are provisioned with HIP records but they don't support HIP,
you might end up hosing all your DNS lookups if the fallback from trying HIP
to no-HIP isn't reliable.

Is there already sufficient experience of these kind of potential bootstrap
problems?  Is a warning that such a bootstrap mechanism may want to avoid
looking up DNS server addresses warranted?

   DNS with security extensions (DNSSEC) [6], if trusted, may be able to
   provide some additional initial authentication, but at a cost of
   initial resolution latency.

==> maybe remove 'additional' as it appears opportunistic HIP has no initial
authentication at all as described in the previous sentence.

It might also be useful to quantify 'some' as I belive it's not 
clearly discussed anywhere though more generic and longer text can 
probably be found in DNSSEC documents; security considerations only 
mentions that 'if DNSSEC zones are considered trustworthy enough'. 
Basically as you describe using DNSSEC with reverse DNS, the 
delegation chain from the reverse IP root should be trusted (typical 
trust anchor issues) but this is not typically an issue; and that the 
DNS zone administrators in charge of the netblock should be trusted to 
put in the right information.

editorial
---------

   upgraded.  This informational document discusses implementation and
   API issues relating to using HIP in situations in which the system is

==> spell out 'API' (done in Introduction but not here apparently)

Fully deployed, the HIP
   architecture will permit applications to explicitly request the

==> feeling optimistic? :-)  Maybe 'would' would be slightly more neutral

  (Section 1.1.6 of [2]) in that the ESP association formed by HIP is

==> spell out ESP.

   [3]  Nikander, P., "An IPv6 Prefix for Overlay Routable Cryptographic
        Hash Identifiers  (ORCHID)", draft-laganier-ipv6-khi-07 (work in
        progress), February 2007.

==> RFC now.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf