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

[Kim Kinnear <[e-mail]>]

Stephen,

Thanks for your review.  My comments are inline, below...

On Jul 8, 2015, at 7:42 AM, Stephen Farrell <[e-mail]> wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-active-leasequery-03: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> This might seem like a lot of discuss points, but it's really
> two main ones (privacy and use of TLS) broken out into what I
> think are separable questions that might help us get the
> discussion done quicker.
> 
> (1) I'm not sure I'm following the use-cases for this but
> clearly this protocol could be used as part of a pervasive
> monitoring toolkit, to track users or client-devices with very
> fine granularity.  So a) can you explain the main valid
> use-case(s) and b) did you consider RFC7258 in developing this
> protocol?  The answers here might well result in a few changes
> to my other discuss points below. I also had a quick peek at
> 5460, but note that pre-dates 7258 by quite a bit and I'm also
> not clear how or if this protocol has the same goal of restoring
> routes.  Note also that I am not claiming that there are no good
> uses for this protocol, I'm just asking what (some of) those are
> and how you considered the PM issue.

	The use cases for this protocol extension are centered around
	processing elements inside of a service provider that need to
	know the information that the DHCP server knows, in near real
	time.

	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.

	That is to say, this is not a speculative protocol.  Something
	that solves the same problem in a similar way is in wide use.

	We did not consider RFC 7258 as particularly relevant to this
	protocol since we expect that the requestors of this protocol
	will be processing elements that sit next to the DHCP server
	and would have direct access to the DHCP server's database (if
	the DHCP server allowed direct access to its database).

	This protocol allows some separation and standardization of
	how to get the information out of a DHCP server in order to
	build a database that is substantially the same as that in the
	DHCP server.  We expect that the processing elements that are
	building that database are controlled by the same people that
	control the DHCP server, and that the same protections and
	controls that are placed access to the DHCP server's data are
	also placed on the data garnered by the requestor of an active
	leasequery.

	We intended the use of TLS and the process of verifying the
	TLS certificates to be the mechanism that a server would use
	to ensure that the requestor of the active leasequery was
	allowed to access the data from the DHCP server.  We may have
	misunderstood some of how that works, and I'll discuss that
	later.

	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).

> 
> 
> (2) I also think you need to add (or reference) privacy
> considerations text here - the information accessible via this
> could have significant privacy impact. 

	Absolutely, we will do that.  I expect to say that the
	information obtainable from active leasequery is essentially
	everything that the DHCP server knows, and should be
	considered a threat to privacy in the same way the DHCP
	server's data is.
> 

> 
> (3) Along the lines of (1) - can you say why all of the various
> bits of data one could return are needed by the requestor here?

	Not really, as the service providers have a variety of use
	cases for this information inside of their ensemble of
	provisioning and support systems. 

> If not, then isn't there a good data-minimisation case to be
> made for profiling down the information returned to the
> requestor?  I think one can validly argue that the answers we
> arrived at in 2009 (for 5460) might not be those on which we'd
> reach consensus today, but this draft seems to (quite
> understandably) assume that 2009's answers are still good
> enough.  Did the WG consider that? 

	I could see adding some words to the draft that would
	say that the server SHOULD provide some way to configure
	which DHCP options will be allowed to be sent over an
	active leasequery channel, to allow the minimization of
	information to take place by the people who know what
	they really need.  Would that be sufficient to deal with
	your concern here?
> 
> (4) Having TLS is good. But I don't get why you've not reversed
> the TLS client/server roles to make the requester the TLS
> server, since it seems to me that authenticating and authorizing
> the requestor here is the main thing and not authenticating the
> DHCP server. So why not reverse the TLS roles? (I'll clear this
> quickly but wanted to check in case it'd not occurred to folks.) 

	We think that if you are using TLS, that the requestor
	has as much reason to ensure they are talking to right server
	as the server has to ensure that it is talking to a valid
	requestor.

	So, no, it hadn't occurred to us to switch roles.  We have
	been assuming that if the server verifies the certificates of
	the requestor and the requestor verifies the certificates of
	the server, that each would be able to ensure that it was
	talking to someone that it trusted to be the right ...
	someone.

	Have we missed something here?

> (5) The TLS mutual authentication requirement is underspecified.
> The sentence in 9.1 isn't really enough I think, you need to say
> that all TLS sessions MUST be mutually authenticated and then
> that has administrative consequences that might need more text.

	Ok, we know from Scott Bradner's review that we managed to
	leave out the words that said that we expected the
	verification of the certificates in both directions to be the
	mechanism that the requestor and server would both use to
	ensure that they were talking to the right partner.
	We will be putting words in to that effect.  Phrased better
	that I did here, of course.

> For example, the DHCP servers need to trust the set of CAs that
> requestors use - is it ok to be just silent on that?

	We expected that the server will verify the CA's from the
	requestor.  I didn't think of that as trusting them, but
	perhaps I'm missing something here.

> I also
> wonder about naming and other things - does there need to be
> some profile of how the DHCP server is named vs. a TLS
> certificate? 

	We were leaving the "given a certificate, how do you
	decide if this is someone you want to talk to" issue
	as something that was outside the scope of this draft.
	
	If you have any words that you would suggest or references
	to drafts that document this kind of thing, we'd love
	to hear them!
> 
> (6) Why not just make the use of TLS mandatory or RECOMMENDED
> here anyway - would that really hurt?

	The draft says TLS SHOULD be implemented, which seems to
	be the same as RECOMMENDED.  We could say RECOMMENDED if
	you would rather we did so. 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - I had a look at the DHCPv4 equivalent - is the plan that those
> be as close to one another as possible? If so, then the
> "DHCPTLS" vs. "STARTTLS" thing seems odd, as does the
> duplication of text in the two - would it not have been better
> to develop a separate spec for how to talk to a DHCP v4 or v6
> server using TLS? I think that'd be cleaner for all sorts of
> reasons, e.g. naming, the roles of the peers, TLS extensions
> needed etc.

	Yes, they are essentially equivalent.  The message names
	are based on the precedents in each protocol.  We always
	try to make the message names fit in to DHCPv4 or DHCPv6,
	as opposed to making them fit in across two drafts.

	We proposed one draft for both DHCPv4 and DHCPv6, and
	the WG, WG Chairs, and AD all *really* didn't like that,
	so we didn't do that.
> 
> - sections 8/9: Sending the DHCP REPLY with no status code as a
> way to indicate acceptance of TLS seems very hacky. Why is that
> a good plan? I don't think STARTTLS works that way in other
> protocols for example.

	I think so to, but that is the current precedent for the
	use of the status code in the DHCP protocols and it 
	is considered a bigger hack to break the precedent.  
> 
> - somewhere: I think it'd be a fine thing if you referred to
> RFC7525/BCP195 and said implementations need to follow that in
> how they use TLS.

	Great!  Will do.
> 
> - section 10: why is (the usually mythical:-) 3315 a MUST NOT
> here? I don't get that. I could see it being an EDONTCAR but I
> don't see the harm if one did go mad and try use 3315. And I
> could maybe, possibly, with a lot of a nose-holding, see a
> universe in which one might use TLS server auth for the DHCP
> server and 3315 to authenticate the requestor, so it seems odd
> to rule that out in this way.

	I'll do a little more research and get back to
	you on this one.  I don't want to hold up the
	discussions on the rest of these issues until
	I figure this one out.

	Thanks -- Kim

> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg