Re: [Geopriv] Requiring DNSSEC in draft-ietf-geopriv-lis-discovery-04

From: Peter Koch ^lt;pk@DENIC.DE>
Date: Tue Nov 11 2008 - 12:46:34 EST


On Tue, Nov 04, 2008 at 03:50:05PM -0700, Cullen Jennings wrote:
> My read of the draft is that it requires implementation (but not
> deployment) of DNSSEC on end user devices. WIth my Cisco/Linksys hat
> on, I would like to say that is is extremely unlikely that vendors of
> small phone devices are going to do this any time soon. I would highly
> encourage the WG to not make this required.

I'm also not sure that DNSSEC can provide what's asked for here.
While at it, please find below a review of the draft through my DNS glasses:

> GEOPRIV M. Thomson
> Internet-Draft J. Winterbottom
> Intended status: Standards Track Andrew
> Expires: May 3, 2009 October 30, 2008
> Discovering the Local Location Information Server (LIS)
> draft-ietf-geopriv-lis-discovery-04

> 4. Determining the Access Network Domain Name

The basic criticism is that the document suggests there is an equivalent of
"network" and "domain" or "domain name". This doesn't hold in practice and in
fact both are orthogonal concepts. That said, both S-NAPTR and U-NAPTR are
prone to abuse in a service discovery context (as opposed to service location),
where one tries to publish information _for_ a certain target audience instead
of _about_ a domain (name).
Even with this set aside for a moment, I'd like to comment on some of the
specific approaches.

> The U-NAPTR discovery method described in Section 3 requires that the
> domain name applicable to the access network is known. An
> unconfigured host might not have this information, therefore it must
> determine this value before the U-NAPTR method can be attempted.
> This section describes several methods for discovering a domain name
> for the local access network. Each method is attempted where
> applicable until a domain name is derived. If a domain name is
> successfully derived but that domain name does not produce any
> U-NAPTR records, alternative methods can be attempted to determine
> additional domain names. Reattempting with different methods is
> particularly applicable when NAT is used, as is shown in
> Section 4.2.1.

> 4.1. DHCP Domain Name Option
> For IP version 4, Dynamic Host Configuration Protocol (DHCP) option
> 15 [RFC2131] includes the domain name suffix for the host. If DHCP
> and option 15 are available, this value should be used as input the
> U-NAPTR procedure.
> Alternatively, a fully qualified domain name (FQDN) for the host
> might be provided by the server ([RFC4702] for DHCPv4, [RFC4704] for
> DHCPv6). The domain part of the FQDN can be used as input to the
> U-NAPTR resolution and is obtained by removing the first label. If

While that's a common case, the "domain part" may also be equal to the
FQDN or differ by more than one label.

> 4.2. Reverse DNS
> DNS "PTR" records in the "" domain can be used to
> determine the domain name of a host, and therefore, the name of the
> domain for that host. The use of the "" domain is
> described in [RFC1034] and results in the domain name of the host.
> Likewise, IPv6 hosts use the "" domain. In the majority of
> cases, the domain part of this name (everything excluding the first
> label) is also the domain name for the access network. Assuming that
> this is true, this domain name can be used as input to the U-NAPTR
> process.

This is a brave assumption that actually tries to overlay semantics
on the target of PTR RRs. Also, it tacitly assumes that the host did
not provide a name of his own choosing for the DNS reverse mapping.
While this may work, it appears like a "hack" and should not be accepted
as an architectural principle.

> For example, for an address of "", if the "PTR" record at
> "" refers to "", this
> results in a U-NAPTR search for ""
> The DNS hierarchy does not necessarily directly map onto a network
> topology (see [RFC4367]); therefore, this method MUST only be used
> for the domain name determined by removing the first label only.
> This method assumes that the access network provider also provides
> the reverse DNS record and they control the domain that is indicated
> in the "PTR" record.
> Furthermore, this method might not apply where a host is given a
> domain name that is different from the domain name of the access
> network. This might occur in some hosting configurations, such as
> where a number of web server hosts, with widely varying domain names,
> are co-located. From the above example, the access network provider
> allocated "" to the host; therefore, they also need to
> control the DNS domain "" and the associated NAPTR
> records. DNS Security Extensions (DNSSEC) [RFC4033] provides a
> cryptographic means of validating this association, through data
> origin authentication.

While these paragraphs already list the weaknesses, albeit without
conclusion, the proposed use of DNSSEC seems to demand a service that
DNSSEC cannot deliver. First, DNSSEC is only about data origin authentication,
not control. There is simply no information available who "controls" the
name space. Second, and more importantly, the signing entities are the
zones themselves, i.e., each and every zone will have a key pair generated,
so there is no way that one could conclude "same key == same management".

> 5. Overall Discovery Procedure
> To claim compliance with this document, a host MUST support both DHCP
> discovery and U-NAPTR discovery. Further, the host MUST support
> retrieval of domain name from DHCP and reverse DNS, using a local
> interface address and the reflexive transport address provided by
> STUN. Additional methods for determining the IP address of the host
> in different network segments are optional.
> These individual components of discovery are combined into a single
> discovery procedure. Some networks maintain a topology analogous to
> an onion and are comprised of layers, or segments, separating hosts
> from the Internet through intermediate networks. Applying the
> individual discovery methods in the following order provides a higher
> probability that a host discovers the LIS physically closest to it:
> 1. DHCP LIS URI Option
> 2. DNS U-NAPTR Discovery, using the domain name from:
> A. DHCP Domain Name Option
> B. Reverse DNS, using the IP address from:
> 1. the local network interface and immediate network segment
> 2. the public reflexive transport address, as revealed by
> 3. Alternative methods, including static configuration
> A host that has multiple network interfaces could potentially be
> served by a different access network on each interface, each with a
> different LIS. The host SHOULD attempt to discover the LIS
> applicable to each network interface, stopping when a LIS is
> successfully discovered on any interface.
> A host that discovers a LIS URI MUST attempt to verify that the LIS
> is able to provide location information. For the HELD protocol, the
> host MUST make a location request to the LIS. If the LIS responds to
> this request with the "notLocatable" error code (see Section 4.3.2 of
> [I-D.ietf-geopriv-http-location-delivery]), the host MUST continue
> the discovery process and not make further requests to that LIS on
> that network interface.
> DHCP discovery MUST be attempted before DNS discovery. This allows
> the network access provider a direct and explicit means of
> configuring a LIS address. DNS discovery is used as a failsafe,
> Thomson & Winterbottom Expires May 3, 2009 [Page 12]

> Internet-Draft LIS Discovery October 2008
> providing a means to discover a LIS where the DHCP infrastructure
> does not support the LIS URI option.
> LIS discovery through DNS requires the host to determine the domain
> name of the local access network. Where DHCP is available, the DHCP
> domain name option (Section 4.1) can be used to provide this
> information. If the domain name cannot be determined from DHCP, or
> the resulting domain name fails to yield a valid LIS address then
> reverse DNS is used. Alternative methods for determining the domain
> name MAY be used, providing they consider the guidance in
> Section 4.2.2.
> Static host configuration MAY be used to provide a LIS address if
> both DHCP and DNS methods fail. Note however, that if a host has
> moved from its customary location, static configuration might
> indicate a LIS that is unable to provide a location.
> If the discovery process fails, user interaction is NOT RECOMMENDED.
> The discovery process is not easily diagnosed by a user.
> The product of the LIS discovery process is an http: or https: URI.
> Nothing distinguishes this URI from other URIs with the same scheme,
> aside from the fact that it is the product of this process. Only
> URIs produced by the discovery process can be used for location
> configuration using HELD. URIs that are not a product of LIS
> discovery MUST NOT be used for location configuration.

> 7. Security Considerations


> Reverse DNS is subject to the maintenance of the "" or
> "" domain and the integrity of the results that it provides.
> DNSSEC [RFC4033] provides some measures that can improve the
> reliability of DNS results. In particular, DNSSEC SHOULD be applied
> to ensure that the reverse DNS record and the resulting domain are
> provided by the same entity before this method is used. Without this
> assurance, the host cannot be certain that the access network
> provider has provided the NAPTR record for the domain name that is
> provided.

See my earlier remark. DNSSEC cannot help here. All you could apply here is
a cross-check between the reverse mapping and forward resolution, which
would give you hints about data consistency. This is often considered
a questionable practice and DNSSEC would only change little.

Remarks regarding the availability of DNSSEC, including validators on the
client or a trust relationship with a validating resolver, have already
been made.

Best regards,
Geopriv mailing list
Received on Tue, 11 Nov 2008 18:46:34 +0100

This archive was generated by hypermail 2.1.8 : Tue Nov 11 2008 - 12:46:53 EST