Pekka, Thanks for your review of this draft. I'm cc'ing ietf@xxxxxxxx to avoid cross-posting, and will summarize later to hipwg list. Responses inline below. > -----Original Message----- > From: Pekka Savola [mailto:pekkas@xxxxxxxxxx] > Sent: Wednesday, May 30, 2007 12:25 AM > To: ietf@xxxxxxxx > Cc: hipsec@xxxxxxxx > 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@xxxxxxxx mailing lists by 2007-05-28. Exceptionally, > > comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf