Pekka,
Thanks for your review of this draft. I'm cc'ing ietf(_at_)ietf(_dot_)org to
avoid
cross-posting, and will summarize later to hipwg list. Responses inline
below.
-----Original Message-----
From: Pekka Savola [mailto:pekkas(_at_)netcore(_dot_)fi]
Sent: Wednesday, May 30, 2007 12:25 AM
To: ietf(_at_)ietf(_dot_)org
Cc: hipsec(_at_)ietf(_dot_)org
Subject: [Hipsec] Re: Last Call: draft-ietf-hip-applications
(Using the HostIdentity Protocol with Legacy Applications) to
Experimental RFC
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?
Yes.
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.
I would not have a problem with renaming to something like "Overview of
Approaches to Using the Host Identity Protocol with Legacy
Applications". Do you think such a title would be better?
The purpose of this document is to provide an overview of the various
ways that HIP can be used without changing the applications, and the
possible issues with the different approaches. It was not our goal to
create specification for interoperable implementations, since the
implementation issues are localized, and we have experience that
different implementations choosing different solutions from these
options can interoperate. Instead, we are trying to document some
implementation experience to cover implementation issues not discussed
in the other HIP drafts.
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.
I am not sure that anyone has done an extensive review of all possible
socket calls, but I think that this claim is valid in typical cases
because, in practice, applications seem to work correctly.
However, based on your comment, I propose to remove this sentence
altogether because it should be clear from the later text that the
discussion of connect() is intended as a typical example (e.g., section
3.1) and later in section 3.4 we discuss some caveats regarding wildcard
values.
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?
We are not suggesting that the DNS lookups use HIP. But even if they
try to use HIP, I am not seeing the potential problem if there is a
fallback to a no-HIP query, so perhaps you could sketch out a particular
scenario or warning that you think would be appropriate.
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.
the wording "some additional initial authentication" was intended to
suggest that the initial authentication was merely "I am talking to
someone who responds to packets addressed to IP address 'ip'", but as
you point out, this might be more accurately considered to be "no
authentication."
If you agree, I propose to change the sentence starting with "DNS with
security extensions..." to read:
"DNS with security extensions (DNSSEC) [6] could be used to authenticate
the bindings between IP address and host identifier, if the necessary
DNSSEC records were available and trusted."
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.
All these editorial suggestions are acceptable to me.
Thanks,
Tom
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf