Re: [dhcwg] Alissa Cooper's Discuss on draft-ietf-dhc-dhcpv4-active-leasequery-06: (with DISCUSS and COMMENT)

[Kim Kinnear <[e-mail]>]

Alissa,

Thank you for reviewing our draft.  I have responded to your discuss
and comment below.

On Sep 29, 2015, at 6:46 PM, Alissa Cooper <[e-mail]> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-dhc-dhcpv4-active-leasequery-06: 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-dhcpv4-active-leasequery/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> What is the rationale for allowing the use of this protocol in insecure
> mode? I realize this is usually for backwards compatibility, but it seems
> like both clients and servers would need to be updated in order to
> implement this spec anyway.

	The basic reason for two modes of operation (insecure and
	secure mode) is because there are essentially two models of
	use for this protocol.  In one model, the requestor of an
	active leasequery is connected to the internet in an arbitrary
	location, and the information transmitted needs to be
	protected during transmission.  In addition, the identity of
	both requestor and server need to be verified.  For this model
	of use, the secure mode is appropriate.

	The other model of use is where the requestor of the active
	leasequery resides in a network element that is essentially
	"next to" the element containing the DHCP server, and both of
	these elements are inside a protected environment.  In this
	case, the insecure mode is sufficient since there are other,
	more global, protections in place to protect this information.

	Note that in discussions of the DHCPv6 Active Leasequery draft
	with Stephen Farrell, we have changed both this draft and the
	DHCPv6 version to require *two* explicit choices in
	configuration to use the insecure mode.  So nobody should be
	able to deploy a DHCP server and through ignorance or
	inattention allow someone to perform an insecure active
	leasequery.

	Kathleen Moriarty attached a comment to her ballot explaining
	why she didn't have an issue with this, and I agree
	wholeheartedly with her analysis!


> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In sections 7.2, 8.1, and 9, this is a bit of a strange layering of
> normative requirements:
> 
> The recommendations in [RFC7525] SHOULD be followed when negotiating
>   this connection.
> 
> If you were going to use normative language here I think this would more
> appropriately be a MUST, but I would actually recommend something along
> the lines of "The recommendations in [RFC7525] apply" since the
> recommendations contained therein vary in their normative strength.
> Perhaps the security ADs have a preferred formulation, I'm not sure.

	I will change the sentence you noted to be "The recommendations
	in [RFC7525] apply." in the next update of the draft.

	Thanks again for your review.

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