Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dhcpv6-active-leasequery-03: (with DISCUSS and COMMENT)

[Christian Huitema <[e-mail]>]

> 	Service providers often need to know the client-id/MAC to IP
> 	binding information as part of their online provisioning
> 	capability and their client troubleshooting capabilities.
> 
> 	They have historically been scraping log files to glean this
> 	information, or creating extensions to our servers to
> 	broadcast this information to the elements in their
> 	provisioning ensemble that need to know this information.  We
> 	have actually implemented a capability similar to what is
> 	documented in this draft and it is in use by a number of large
> 	service providers -- and we implemented it in no small part
> 	because we got tired of trying to help people debug their
> 	extensions to our DHCP server, since implementing this is a
> 	hard problem.

To add my two cents there: I believe that the Security Section should be updated to point out the "information disclosure" risk. Information disclosure happens when unauthorized clients connect to the server and manage to extract sensitive information, such as leases, time of connection, or delegation of prefixes to specific customers. The main mitigation proposed in RFC 5460 is to reject connections from unauthorized customers, and that mitigation shall be explicitly mentioned in the security section. 

Here are the details of the reasoning:

1) Privacy analyses already assume that the DHCP server knows the relation between MAC Address and IP address, and that network management systems can obtain this information from the DHCP server.

2) Privacy analyses also assume that any "on-link" party can find the relation between MAC Address and IP Address, using ARP or network discovery.

3) Privacy analyses assume that the mapping of prefix delegation to ISP customer identity is only known by the ISP, and is only disclosed on a case by case basis using some formal channels.

The proposed extensions allow for real time monitoring of DHCP leases, including in particular prefix delegations. This clearly changes some of our privacy assumptions. With this protocol, the lease information can be accessed in real time by any party that manages to establish a connection to the DHCP server -- not just parties on the same link as the target, and not just devices managed directly by the ISP.

The draft does specify some access control mechanism to protect the information. Namely, section 9.1. Accepting connection states that:

   DHCPv6 servers that implement DHCPv6 Active Leasequery listen for
   incoming TCP connections.  Approach used in accepting the requestor
   connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460].

The corresponding text in section 7.1. of RFC 5460 states that:

   Servers MAY restrict Bulk Leasequery connections and LEASEQUERY
   messages to certain clients.  Connections that are not from permitted
   clients SHOULD BE closed immediately, to avoid server connection
   resource exhaustion.  Servers MAY restrict some clients to certain
   query types.  Servers MAY reply to queries that are not permitted
   with the NotAllowed status code [RFC5007], and/or close the
   connection.

That's pretty weak, because there is no good detail here of how the "certain clients" are identified. The STARTTLS option does not appear to infer Client Authentication. I assume that when the access control is implemented, it is done via IP address, but that seems weak.

-- Christian Huitema