Discovering the Local Location Information Server (LIS)
draft-ietf-geopriv-lis-discovery-15

[Ballot comment]
Editorial suggestion for the details in sections 3.2 and 3.3: make the field names in the diagram and the textual explanation match; e.g., in section 3.2, use either "Code" or "option-code" in both the diagram and text.

[Ballot discuss]
Following up on Lars' DISCUSS, the current version of the spec has not, as far as I know, been reviewed by the dhc WG.  I've asked the WG chairs for their review and feedback.  The syntax of the options is modeled on and compatible with the syntax of other options that carry DNS names or FQDNs, so I anticipate that the syntax will be acceptable.

[Ballot comment]
I support Pasi's discuss, which addresses the same issue as my comment, but more concisely
and eloquently.  I have retained the text of my comment, since authors may want to read this
with Pasi's discuss.

The security considerations paragraph on "https:" URIs does a nice job of explaining the
rationale for the differences with RFC 3958 (compatibility with existing client software) but
fails to explain the security ramifications. 

Specifically, the authentication process authenticates the LIS against the output of the
U-NAPTR process, but does not verify that the discovery process identified an LIS that is
appropriate for the requested domain.  If the attacker has compromised stages 1 or 2, the
process provides an authenticated connection to the attacker's rogue LIS.  If the process
satisfied the requirements from 3958, the https connection would authenticate the LIS
against the domain name used as input to the U-NAPTR process.  An attacker would need to
compromise stage 1 (and provide a falsified domain name) to succeed and the
vulnerability of the DNS would not be an issue.

[Ballot discuss]
[I am picking up Pasi's discuss since I am already familiar with the
issues on this document.  No change to his discuss text or my comments
at this time.]

I have reviewed draft-ietf-geopriv-lis-discovery-13, and have one
concern that I'd like to discuss before recommending approval of the
document:

While relying on DHCP seems unavoidable here, normally HTTPS does not
rely on DNS to work securely. I'd like to see a better rationale for
ignoring important security advice from the NAPTR specifications (most
of Section 8 of RFC 3958). "More compatible with existing HTTP client
software" seems rather vague, especially considering we're talking
about new HELD client software, and not e.g. existing web browsers.

LoST (RFC 5222) did use this approach, too, but only after concluding
that the approach recommended in RFC 3958 would not have worked well
in that particular context (where large number of inputs map to a
very small number of LoST servers, and the LoST server is not even
aware of all the possible inputs). Here the situation seems quite
different: the location server needs to be aware of the access networks
that have delegated to it (in order to properly determine the location).

[Ballot comment]
2.  LIS Discovery Procedure

  A device MUST support discovery using the access network domain name
  DHCP option (Section 3) as input to U-NAPTR resolution (Section 4).
  If this option is not available, DHCPv4 option 15 [RFC2132] is used.

I would like to see more justification in the document of why the option 15 is not acceptable/sufficient for LIS discovery. An example would satisfy me.

  Other domain names MAY be used, as described in Section 3.4.

[Ballot discuss]
I have reviewed draft-ietf-geopriv-lis-discovery-13, and have one
concern that I'd like to discuss before recommending approval of the
document:

While relying on DHCP seems unavoidable here, normally HTTPS does not
rely on DNS to work securely. I'd like to see a better rationale for
ignoring important security advice from the NAPTR specifications (most
of Section 8 of RFC 3958). "More compatible with existing HTTP client
software" seems rather vague, especially considering we're talking
about new HELD client software, and not e.g. existing web browsers.

LoST (RFC 5222) did use this approach, too, but only after concluding
that the approach recommended in RFC 3958 would not have worked well
in that particular context (where large number of inputs map to a
very small number of LoST servers, and the LoST server is not even
aware of all the possible inputs). Here the situation seems quite
different: the location server needs to be aware of the access networks
that have delegated to it (in order to properly determine the location).

[Ballot comment]
I support the Lars/Ralph Discuss, and the way to resolve that is to get
the review the DHC WG. Our process for DHCP option development is to
host it in the "user" working group (such as GEOPRIV), but run
simultaneous WGLCs also in DHC WG. This ensures that both the use case
and DHCP encoding is done correctly.

[Ballot comment]
Section 2.2 begins

  A Device MUST avoid performing LIS discovery over a VPN network
  interface unless discovery on other interfaces is unsuccessful.  A
  LIS discovered in this way is unlikely to have the information
  necessary to determine an accurate location.

I find this use of RFC 2119 a little vague. In trying to parse it, I
think I concluded...

  A device MUST NOT attempt LIS discovery over a VPN network interface
  until it has attempted and failed to perform discovery on all other
  non-VPN interfaces. A device MAY perform discovery over a VPN network
  interface if it has first attempted discovery on non-VPN interfaces,
  but a LIS discovered in this way is unlikely to have the information
  necessary to determine an accurate location.

Note s/Device/device/

---


Nits:

Section 1

  for providing that location information to devices with an access
  network.  The LIS uses knowledge of the access network and its

This is hard to parse and it is only when we get to the definitions
later that we discover it means:

  for providing that location information to devices with attached
  access networks used to provide Internetr access.  The LIS uses
  knowledge of the access network and its


---

Section 1.1
  The bulk of DHCP information is largely static

That looks like a double vagueness :-)
Either
  The bulk of DHCP information is static
Or
  The DHCP information is largely static

[Ballot discuss]
A relatively small Discuss that I hope will cause you no trouble.

It might be valuable to note that there could be more than one LIS
for any access network and that the device makes the choice based on
local policy.

In particular, in step 2 of figure 1 the result may be more than one
URI. Or the "N" path from step 3 should return to step 2.

[Ballot comment]
I support Pasi's discuss, which addresses the same issue as my comment, but more concisely
and eloquently.  I have retained the text of my comment, since authors may want to read this
with Pasi's discuss.

The security considerations paragraph on "https:" URIs does a nice job of explaining the
rationale for the differences with RFC 3958 (compatibility with existing client software) but
fails to explain the security ramifications. 

Specifically, the authentication process authenticates the LIS against the output of the
U-NAPTR process, but does not verify that the discovery process identified an LIS that is
appropriate for the requested domain.  If the attacker has compromised stages 1 or 2, the
process provides an authenticated connection to the attacker's rogue LIS.  If the process
satisfied the requirements from 3958, the https connection would authenticate the LIS
against the domain name used as input to the U-NAPTR process.  An attacker would need to
compromise stage 1 (and provide a falsified domain name) to succeed and the
vulnerability of the DNS would not be an issue.

[Ballot discuss]
I have reviewed draft-ietf-geopriv-lis-discovery-13, and have one
concern that I'd like to discuss before recommending approval of the
document:

While relying on DHCP seems unavoidable here, normally HTTPS does not
rely on DNS to work securely. I'd like to see a better rationale for
ignoring important security advice from the NAPTR specifications (most
of Section 8 of RFC 3958). "More compatible with existing HTTP client
software" seems rather vague, especially considering we're talking
about new HELD client software, and not e.g. existing web browsers.

LoST (RFC 5222) did use this approach, too, but only after concluding
that the approach recommended in RFC 3958 would not have worked well
in that particular context (where large number of inputs map to a
very small number of LoST servers, and the LoST server is not even
aware of all the possible inputs). Here the situation seems quite
different: the location server needs to be aware of the access networks
that have delegated to it (in order to properly determine the location).

[Ballot discuss]
I have reviewed draft-ietf-geopriv-lis-discovery-13, and have one
concern that I'd like to discuss before recommending approval of the
document:

While relying on DHCP seems unavoidable here, normally HTTPS does not
rely on DNS to work securely. I'd like to see a better rationale for
ignoring important security advice from the NAPTR specifications (most
of Section 8 of RFC 3958). "More compatible with existing HTTP client
software" seems rather vague, especially considering we're talking
about new HELD client software, and not e.g. existing web browsers.

LoST (RFC 5222) did use this approach, too, but only after concluding
that the approach recommended in RFC 3958 would not have worked well
in that particular context (where large number of inputs map to a
very small number of LoST servers, and the LoST server is not even
aware of all the possible inputs). Here the situation seems quite different: the location server needs to be aware of the access networks
that have delegated to it (in order to properly determine the location).

[Ballot discuss]
Following up on Lars' DISCUSS, the current version of the spec has not, as far as I know, been reviewed by the dhc WG.  I've asked the WG chairs for their review and feedback.  The syntax of the options is modeled on and compatible with the syntax of other options that carry DNS names or FQDNs, so I anticipate that the syntax will be acceptable.

[Ballot comment]
[Note: I am entering this as a Comment to promote discussion before the telechat.  I have
not decided on a ballot position yet, and may upgrade this to a discuss.]

The security considerations paragraph on "https:" URIs does a nice job of explaining the
rationale for the differences with RFC 3958 (compatibility with existing client software) but
fails to explain the security ramifications. 

Specifically, the authentication process authenticates the LIS against the output of the
U-NAPTR process, but does not verify that the discovery process identified an LIS that is
appropriate for the requested domain.  If the attacker has compromised stages 1 or 2, the
process provides an authenticated connection to the attacker's rogue LIS.  If the process
satisfied the requirements from 3958, the https connection would authenticate the LIS
against the domain name used as input to the U-NAPTR process.  An attacker would need to
compromise stage 1 (and provide a falsified domain name) to succeed and the
vulnerability of the DNS would not be an issue.

[Ballot discuss]
I've been following this document closely, and support its publication. I've spotted two things in a final review that I think need attention.

1) The document currently places requirements on a LIS implementation (in section 2.2 paragraph 2). This is out of place in this document. I think this should point to the guidance in HELD instead. (Non-normative reinforcement of the guidance in HELD would make sense here).

2) I encourage adjusting the language at the beginning of section 2.1.
The group put effort into discussing this point, and the resulting changes in the document don't leave the first sentence standing well on its own. In particular, deployments with residential gateways that are doing the right things with DHCP option 15 won't run into the trouble the sentence originally was calling out. Here is some proposed alternate text for that first paragraph:

  The options available in residential gateways will affect the
  success of this algorithm in residential network scenarios.
  A fixed wireline scenario is described in more detail in Section 3.1 of
  [I-D.ietf-geopriv-l7-lcp-ps].  In this fixed wireline environment an
  intervening residential gateway exists between the device and the
  access network.  If the residential gateway does not provide the
  appropriate information to the devices it serves, those devices
  are unable to discover a LIS.

[Ballot comment]
Section 2., paragraph 1:
>    A device that has multiple network interfaces could potentially be
>    served by a different access network on each interface, each with a
>    different LIS.  The device SHOULD attempt to discover the LIS
>    applicable to each network interface, stopping when a LIS is
>    successfully discovered on any interface.

  What if I have multiple access interfaces connected to multiple
  operators, all of which operate LIS servers that satisfy the criteria
  for use? According to the outlined procedure, I'd only ever use one of
  them. Does it truly not matter which LIS I use? How does this
  procedure intersect with what the MIF WG is doing?


Section 5., paragraph 2:
>    methods are described here that can limit the probablity of, or

  Nit: s/probablity/probability/

[Ballot discuss]
Section 3.1., paragraph 0:
> 3.1.  Domain Name Encoding

  DISCUSS: This discuss can probably be cleared up quickly. I'm
  surprised to see a DHCPv4/6 option standardized out of GEOPRIV. Has
  the DHC WG reviewed this?

[Ballot comment]
1.  Introduction and Overview

  This document describes a process that a device can use to discover a
  LIS.  This process uses a DHCP option and the DNS.  The product of
  this discovery process is an http: or https: URI, which identifies a

URI schemes need references to the correponding RFCs.

  LIS.

[Ballot discuss]
This is a fine document, I only have one issue that I would like to discuss before recommending its approval:

2.  LIS Discovery Procedure

  A device MUST support discovery using the access network domain name
  DHCP option (Section 3) as input to U-NAPTR resolution (Section 4).
  If this option is not available, DHCPv4 option 15 [RFC2132] is used.

I would like to see more justification of why the option 15 is not acceptable/sufficient for LIS discovery.

  Other domain names MAY be used, as described in Section 3.4.

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "BOOTP Vendor Extensions and DHCP Options" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Tag Name Data Length Meaning Reference
--- ---- ----------- --------- ---------
TBD OPTION_V4_ACCESS_DOMAIN N Access Network Domain Name
[RFC-geopriv-lis-discovery-11]


Action 2:

Upon approval of this document, IANA will make the following
assignment in the "DHCP Option Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Value Description Reference
----- ----------- ---------
TBD OPTION_V6_ACCESS_DOMAIN [RFC-geopriv-lis-discovery-11]


Action 3:

Upon approval of this document, IANA will make the following
assignments in the "S-NAPTR Application Service Tags" registry at
http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xhtml

Tag Reference
--- ---------
LIS [RFC-geopriv-lis-discovery-11]
HELD [RFC-geopriv-lis-discovery-11]


We understand the above to be the only IANA Actions for this document.

(1.a) The document shepherd for this document is Alissa Cooper. The
document shepherd has personally reviewed the document and believes
that this document is fit for publication.

(1.b) This document has been thoroughly reviewed by the GEOPRIV
working group, as well as key members of the DNS and DHC communities.

(1.c) There are no specific areas within this document that require
additional external review.

(1.d) The shepherd has no specific technical concerns with this
document to which to call attention. No IPR disclosures have been
filed against this document.

(1.e) The GEOPRIV working group has discussed this document at length
and reached consensus about its content. There are no explicit
disagreements with the document.

(1.f) There have been no threatened appeals or expressions of extreme
discontent against this document.

(1.g) The shepherd has checked the document for ID nits. The document
has just one nit: a reference to a document that has been updated
since its publication. The authors have been informed of these nits.
Otherwise, the document meets the checklist criteria and has no need
for any additional reviews.

(1.h) The document's references are appropriately split into normative
and informative. There are two normative references to documents in
draft: http-location-delivery and dhc-container-opt. The former is
currently pending IESG evaluation. The latter is awaiting a revised ID
before IESG re-evaluation (but should it continue to be controversial,
the reference could be removed, as it is largely optional).

The document contains one downward reference to RFC 2818, which has
been called out during a previous last call for what is now RFC 4791.
The usage of a reference to RFC 2818 in lis-discovery is essentially a
subset of its usage in RFC 4791, and thus the downward reference need
not be called out again.

(1.i) The shepherd has verified that the document's IANA consideration
section exists and is consistent with the body of the document. The
document makes four requests of IANA: a DHCPv4 option code, a DHCPv6
option code, a NAPTR Application Service tag and a NAPTR Application
Protocol tag.

(1.j) There are no instances of formal language in this document.

(1.k) Announcement Writeup:

Technical Summary:

This document describes a method for the discovery of a Location
Information Server (LIS) in the access network serving a device.
Discovery of the correct LIS in the local access network is necessary
for devices that wish to acquire location information from the
network. The method described defines Dynamic Host Configuration
Protocol (DHCP) options for IP versions 4 and 6 that specify a domain
name. This domain name is then used as input to a URI-enabled NAPTR (U-
NAPTR) resolution process.

Working Group Summary:

This document represents the consensus of the GEOPRIV working group.
The original drafts of this document contained several different
methods of performing LIS discovery. Through the working group review
process, the DHCP/U-NAPTR method outlined in the current document was
selected as the most appropriate for standardization at the current
time.

Document Quality:

The key decision in drafting this document was to craft the LIS
discovery mechanism in a near-identical fashion to the server
discovery process outlined in RFCs 5222 and 5223, which had already
been thoroughly vetted.