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

[Kim Kinnear <[e-mail]>]

Stephen,

In an attempt to narrow down the discussion, I've selected a few sections
to respond to here, but I'm actually trying to respond to your entire 
concern w.r.t. privacy.

On Jul 11, 2015, at 9:11 AM, Stephen Farrell <[e-mail]> wrote:

> Sure, I don't doubt there's utility here. But the actual utility
> is still vague for me. I also don't doubt that it's not vague for
> you or those deploying but it's not really possible (for me) to try
> analyse the privacy properties without some more detailed knowledge
> of the purpose(s) to which this data will be put.

I do not believe that we going to be able to give you the information
as to which data elements are "necessary" and how they will be used.
We simply don't know, and in many cases our customers won't (or even
can't) tell us.  I think for the purposes of analysis here, that we
should assume that people using Active Leasequery are going to use all
of the data that the DHCP server has available to it about each client
and that it can send out in an Active Leasequery response.  I don't
doubt that vendor independent extensions will be used as well to
enhance the information with specific items in different
implementations.

Essentially, our customers are building a parallel database which
contains essentially everything they can get from an Active Leasequery
response (or a Bulk Leasequery response).  Trying to limit the data
that they can acquire from an Active Leasequery by limiting it in this
document will only, in my view, take us back to where they will find
other approaches to acquire the missing information.  Which is exactly
the reason that we developed an Active Leasequery-like capability in
the first place -- to remove the need to develop one-off solutions for
each customer.

That said, it would certainly serve the goal of privacy if there were
no standardized way to acquire this information.  We have no
particular incentive to standardize this Active Leasequery other than
it seemed like a "good thing to do".  Clearly from a privacy standpoint
it isn't.  Seems like from a user's standpoint, though, there is some
value in having this standardized.  Thus, we have added TLS support at
the request of the former AD.

>> 
>> 	Ultimately, we expect that the people in charge of the data on
>> 	the DHCP server are the same people in charge of the data that
>> 	a processing element can discover from the DHCP server through
>> 	the use of the active leasequery protocol.  These same people
>> 	have control of the data in both elements (as well as the
>> 	network on which the raw DHCP data flows).  Of course all of
>> 	this information can be garnered from a tcpdump of the wire on
>> 	which the DHCP server sits (and we have customers doing that
>> 	too, to meet their needs for a near-real time database of
>> 	client<->IP address binding information).
> 
> Sure a local tcpdump is what it is, but if someone deploys this
> without implementing and turning on TLS and screws up their f/w config
> then the entire world could find this data. And with zmap that's no
> longer unrealistic if the DHCP server has an IPv4 address. And we do
> know that people do screw up f/w configs. So the thing to analyse I
> think is the balance between the probability and downsides of
> publishing this information to the world, vs. the costs of making
> the spec more restrictive/protective. I'm not sure we've got that
> balance quite right, but then as I said I don't yet understand the
> beneficial uses of this.

You have put this well -- what is the probability and downsides of
making the information the DHCP server knows easily available vs the
cost of make this spec more restrictive.

I want to emphasize as well that we expect that the people who control
the information on the DHCP server are the same people who will
control the configuration of the DHCP server (regarding Active
Leasequery) as well as the database constructed by the requestor of
the Active and Bulk Leasequery information.

Yes, someone could mistakenly leave their firewall unconfigured
regarding DHCP and thus let anyone see what the DHCP server knows.

Of course this can already be done with DHCPv6 Bulk Leasequery (RFC
5460) as well as DHCPv6 Leasequery (RFC 5007).  I recognize, however,
that just because some existing protocols don't protect some data is
no justification for allowing a new protocol to not protect some data.
So I'm not using that as a justification for anything, yet I did want
to point it out.

I believe that anyone who allows TCP connections to port 67 on their
DHCP server is at risk of losing data to Bulk Leasequery already, and
so one would normally prevent TCP connections to port 67.  And that
would also cover Active Leasequery.

But mistakes certainly do happen when configuring networks, and I deal
with supporting customers who make such mistakes frequently.  So
perhaps simply telling people to "prevent access by unauthorized
requestors" isn't enough (which is essentially what we have done 
so far).

It would be straightforward to alter the draft to say that you MUST
NOT make Active Leasequery access available by default, and that it
MUST require explicit configuration in order to allow the DHCP server
to respond to any Active Leasequery request.  Then someone would have
to take an action to create a privacy problem.

Further we could say that it MUST take explicit configuration to allow
Active Leasequery without TLS even if TLS wasn't implemented.  So you
would have two explicit hurdles to overcome to do something dumb
regarding privacy.  This would largely prevent people who knew nothing
about Active Leasequery from having it enabled it on their servers,
as well as encouraging others to use it in a protected way.

> I'm asking wouldn't it be better if the spec said that "Mutually
> authenticated TLS MUST be supported and SHOULD be used and SHOULD
> be the default."
> 
> Right now, it says TLS SHOULD be implemented, which is consistent
> with overall IETF BCPs. I'm asking if, for this protocol, with
> the potential privacy exposure, we ought go further that those (now
> somewhat old) BCPs and say to just turn on TLS, since it ought not
> be that hard and really ought be the default.

Our answer is no, we don't believe that we should go further and
require TLS, in that we don't see this protocol as creating a privacy
exposure of sufficiently unusual magnitude to warrant taking that
extra step.  Possibly because we don't view the information available
as unusually ... useful to someone intent on violating privacy
concerns.  Useful, certainly, but not extraordinarily useful, and so
not requiring extraordinary measures to protect.

Thanks -- Kim