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

[Alissa Cooper <[e-mail]>]

> On Sep 30, 2015, at 12:33 PM, Kim Kinnear <[e-mail]> wrote:
> 
> 
> 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] <mailto:[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.

Ok, apparently I had the same question on the v6 version but put it in a comment in support of Stephen’s DISCUSS. I think it would help to have some version of the above rationale in the draft, but will clear my DISCUSS.

Thanks,
Alissa

> 
> 	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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>