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(_dot_)org mailing lists by 2007-05-28. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf