Document: draft-ietf-geopriv-http-location-delivery-14 Reviewer: Ben Campbell Review Date: 2009-06-04 IETF LC End Date: 2009-06-09 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I have a few editorial and clarity comments that might could slightly improve the draft, but can safely be ignored. Additionally, I have one comment highlighting a "feature" that is not necessarily a problem, but is architecturally important enough that I want to make sure the IESG thinks about it. Major issues: None. Minor issues: -- There is one feature of HELD that the ADs should explicitly think about: The HTTP binding forbids LIS reliance on HTTP digest or basic authentication. If I understand correctly, this means effectively that the _only_ method for client authentication is the built in reverse routeability test. I am agnostic as to whether this is sufficient. Nits/editorial comments: -- section 4, paragraph 1: Please expand (and reference) PIDF-LO on first mention. -- Section 6.2, value list: -- In my previous review, I was confused as to the relationship between the geodetic/civic and LoBV/LoBR choices. I think it's worth some clarification in this section that geodetic and civic imply LoBV. -- section 9.3, 5th paragraph: "A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in another Device's location." It might be worth clarifying that (if I understand correctly) that this is more than a spoofing attack, in that the attacker must not only spoof its source address, but must be able to receive packets sent to the spoofed address? -- same paragraph: "... re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location." It seems like this problem is pretty unlikely to occur by _accident_ when HELD is used over TCP (the only binding right now), right? And certain not to happen over TLS? Might be worth a "mitigating" mention. ============================================================ Document: draft-ietf-geopriv-http-location-delivery-09 Reviewer: Ben Campbell Review Date: 2008-09-11 IETF LC End Date: 2008-05-07 IESG Telechat date: (if known) Summary: Ready ========================================================== Document: draft-ietf-geopriv-http-location-delivery-07 Reviewer: Ben Campbell Review Date: 2008-05-06 IETF LC End Date: 2008-05-07 IESG Telechat date: (if known) Summary: This document is almost ready for publication as a proposed standard. I have a few questions and comments that should be considered prior to publication. Comments: -- Substantive comments: -- I am a little bit confused by the scope of applicability of this draft. Section 3, paragraph 1 says "This document assumes that the LIS is present within the same administrative domain as the Device (e.g., the access network)." However, section A.3. claims compliance to a requirement to the effect of "The design of the L7 LCP MUST NOT assume a business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider." (It is possibly I am misunderstanding what ASP means in this context?) Furthermore, certain aspects of HELD seem to require fairly tight coupling between the LIS and the access network. For example, the NIS needs to know about any range of addresses for which it is likely to have erroneous location info due to VPNs and NATs. The security considerations indicate that the network needs to be properly configured to avoid ip spoofing attacks, which would seem to indicate at least an administrative coupling between the access network provider. It goes on to make a normative statement that network configuration SHOULD be considered. A paragraph or two describing the expected network architecture might clear this up. Maybe this is covered sufficiently in some of the referenced documents? -- I would like to see a little more analysis on the safety of using the source IP address as the device identifier. My instinct says that reverse routeability may keep this from being a problem--but the security considerations do indicate source address spoofing could cause LI to be compromised, and add a list of approaches, "one or more" of which is recommended to limit the exposure. If there are in fact risks of compromise, I think the draft needs some more exhaustive and explicit statements of what I must do to avoid such attacks. -- The lbyr requirements draft includes a SHOULD level requirement that a client should be able to cancel location references. HELD does not seem to allow for that capability. I know it was only a SHOULD, but was there a particular reason to leave it out? -- Section 4.2: I understand that the authz mechanisms for dereferencing location URLs constitute a bit of an "elephant in the room". But do we really think it is useful to punt entirely on that? The referenced doc does not seem all that helpful on the matter. Even an example of a potentially useful approach might be helpful. (I realize this is not a HELD problem per se, but without some mechanism for it, I question the usefulness of location by reference in HELD.) (If we can point to a location dereference protocol and claim that spec solves this, then no problem.) Section 4.3.1: Should there be normative advice in this section? Section 6.2 and 6.2.1: I don't see an obvious way to say I only want to get location by value. Is that intentional? Section 6.3, error code unsupportedMessage: Wasn't there a normative statement ealier that the LIS MUST ignore anything in a request that it does not understand? If so, when would this get used? 6.5.2: Can you give any guidance about useful value ranges for "expires"? I assume very short expirations would not be useful. 6.6, last paragraph: "Note that the presence parameter is not explicitly shown in the XML schema Section 7 for a location response message due to XML schema constraints." Is that not a problem, since section 7 is the formal definition of the protocol syntax? Section 8: I'm a little confused by the fact that a HELD URI can show up both in a HELD response, and in LIS discovery. Does this use of a HELD URI imply the use of the HELD protocol? If so, how would a HELD URI in a locationReponse message be used? Since HELD uses the source IP address for the identifier, it is not useful to transmit the URI to another device, right? -- Nits and Editorial Comments: S1: Expand LIS on first use. (You do so later in paragraph.) Section 4: Paragraph 1 I realized at this point I had not yet seen an expansion of "HELD", nor a statement that HELD is the protocol being defined in this document outside of the document title. Maybe an official "naming" sentence in the last paragraph of the intro would help. Also, this paragraph could use explicit references for pidf-lo and location URIs. Section 4.3, paragraph 3: Please expand VPN on first use. Table 1: Can you add a legend for o and m? I know it seems obvious, but better to be explicit. Also, listing locationUriSet and presence both as optional for responses does not quite capture the normative statement that one or the other MUST exist. Section 5.2: Should there be normative language around the inclusion of locationType? (There is for the other parameters) Section 6.2. "any" value: The normative statement that the LIS SHOULD return all available forms seems to mildly conflict with some of the further normative statements in the paragraph. Section 12.5: URI Scheme Syntax says "See section" with no section number.