Subject: Re: [Geopriv] DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 15 Feb 2010 08:55:16 +0800

Hi Alexey,

Thanks for pointing out the omission on the URI schemes.  I'll add normative references to 2616 and 2818.

Use of DHCP option 15 has been the subject of much discussion [1].  I've proposed a small addition below that attempts to capture the essence of that discussion in the document.

On face value, it would seem that the new domain name option is redundant (in DHCPv4).  The very frequent misconfiguration of option 15 is scant justification for a new option.

A new option was created to avoid any potential mismatch between the existing uses the option is being put to, and this new use.  

Option 15 is commonly used to identify a domain search suffix for local users.  In small enterprise, this might be used to identify the small handful of computers in the office - user PCs and maybe a web server.  It is envisaged that a LIS is not necessarily within the same scope; a LIS is more likely provided by an ISP or the owner of the physical network infrastructure.

Section 3.4 might be the best place to insert text.

Section 3.4, OLD:
   DHCPv4 option 15 [RFC2132] provides an indication of the domain name
   that a host uses when resolving hostnames in DNS.  This option is
   used when the DHCPv4 access domain name is not available.
NEW:
   DHCPv4 option 15 [RFC2132] provides an indication of the domain name
   that a host uses when resolving hostnames in DNS.  The value of
   option 15 might have been set without considering its potential use
   in discovering a LIS.  Option 15 is only used when the DHCPv4 access
   domain name is not available.

Cheers,
Martin

[1] <http://www.ietf.org/mail-archive/web/geopriv/current/msg06491.html>

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Sunday, 14 February 2010 6:43 AM
> To: [email-masked]
> Cc: [email-masked]; draft-ietf-geopriv-lis-
> [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
> 
> 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.
> 
> 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.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 17 Feb 2010 07:07:39 +0800

Hi Lars,

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

The -05 draft was discussed extensively with DHC; -06 and -07 were the product of that discussion.  It's changed a little since then, and we haven't gone back (an oversight on my part).

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

If the goal is to get location information, then it is considered that any information is enough.  The source does matter, but not enough to have us describe more complicated procedures.  The text purposefully avoids "MUST" to allow implementations to use other logic if that suits.  If you believe that the "SHOULD" needs further clarification, I can add:

   This approach ensures that the device obtains location information as fast as possible.  An implementation MAY use other algorithms if it has other goals or if it has better information about the different access networks it uses.

(...reads MIF charter and PS...)  This is certainly pertinent to the work in MIF.  The problems that they discuss are the reason that this text is in here.

>   Nit: s/probablity/probability/

Fixed.

Thanks,
Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 19 Feb 2010 07:57:12 +0800

I remember having this exact discussion with someone in the past, but I can't find reference to it in the WG archives or meeting minutes, so it may have been a hallway conversation.

3958 uses the _input_ to DDDS to validate the authenticated identity of the server, even if the server is at a different domain.

LoST specifically states that the name in the _output_ of DDDS is used to validate server identity.  This makes a lot of sense for LoST because an N-to-1 deployment arrangement is expected.  But there's a problem with 3958 that isn't clear.

The vagueness in Sec8 should be fixed, but the problem is thus - I can build a discovery element, then take the output of that and feed it to an HTTP stack.  Normally, the only input the HTTP client takes is a URL.  The server is authenticated against the domain name in the URL.  While it is possible in some implementations to provide your own server authentication logic, very many implementations do not allow this.  Given the current implementations of HELD clients, I am aware of maybe only one (a Java-based client) that could possibly authenticate based on a different name than what was in the URL.

The 3958 choice was also going to place some cumbersome restrictions on those deploying a LIS into an ISP.  Small businesses and home customers are expected to rely on ISP-provided location infrastructure.  For the ISP, this could mean that adding new customers requires that they add new names to the subjectAltName of their LIS certificate.  The alternative is that the customers report the name of the ISP in their DHCP options, which is probably easier, but less friendly to those people; in most cases depends on access to the new option.

If the IESG believes that the 3958 approach is best, then I'm happy to accept that conclusion.  I would prefer to retain the existing mechanism.  It is my view that - while the choice made for 3958 is the "most secure" - it's the least practical.

--Martin

> From: Pasi Eronen [mailto:[email-masked]]
> Sent: Thursday, 18 February 2010 9:46 PM
> To: [email-masked]
> 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).
> 
> Comment:
> The regexp in Section 4 is wrong; "*." should be ".*"