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

From: Pekka Savola <[email-masked]>
Date: Wed, 30 May 2007 10:25:28 +0300 (EEST)

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
> [email-masked] mailing lists by 2007-05-28. Exceptionally,
> comments may be sent to [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 31 May 2007 12:22:37 -0700

Pekka,
Thanks for your review of this draft.  I'm cc'ing [email-masked] to avoid
cross-posting, and will summarize later to hipwg list.  Responses inline
below.

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Wednesday, May 30, 2007 12:25 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Hipsec] Re: Last Call: draft-ietf-hip-applications 
> (Using the HostIdentity Protocol with Legacy Applications) to 
> Experimental RFC 
> 
> Is this correct? 

Yes.

> If yes, maybe this could be made more 
> explicit, e.g., 

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

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.

> 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.

> 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."

>          progress), February 2007.

All these editorial suggestions are acceptable to me.

Thanks,
Tom