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

Kim Kinnear <kkinnear@cisco.com> Wed, 30 September 2015 21:00 UTC

Return-Path: <kkinnear@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70621A8AFA; Wed, 30 Sep 2015 14:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGvkP_LHgr0G; Wed, 30 Sep 2015 14:00:24 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C7E1A8AF9; Wed, 30 Sep 2015 14:00:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15477; q=dns/txt; s=iport; t=1443646824; x=1444856424; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=59lNak1K18NXcSgYV8LKF7Pv8u9qGfBRGf6AaNbCk+Y=; b=ITMmA2jkRhDl1/W8ac0/JetUQBk17uFw32BYW1l6Xbdvet26vjqMSYiR 1lcfgVbxu1FmMmfg9HCgBbQOuh3HPrP8H7HPmCVSIKtxWpo8ZGWew840l 3MhhIDu02pWFsK+z079BNmIGoi/yCpxtW5JOfis693/VE6sSySQJwC4l2 s=;
X-IronPort-AV: E=Sophos;i="5.17,614,1437436800"; d="scan'208";a="605460097"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2015 21:00:22 +0000
Received: from dhcp-10-131-65-126.cisco.com (dhcp-10-131-65-126.cisco.com [10.131.65.126]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8UL0J6N015574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Sep 2015 21:00:20 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Kim Kinnear <kkinnear@cisco.com>
In-Reply-To: <20150930035228.20755.429.idtracker@ietfa.amsl.com>
Date: Wed, 30 Sep 2015 17:00:18 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <19846C62-DF4F-402B-A7A6-9D2CE69BD9B3@cisco.com>
References: <20150930035228.20755.429.idtracker@ietfa.amsl.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1878.6)
X-Authenticated-User: kkinnear
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/8EASfGUp6un7WKtVNHuIu6B0WAs>
Cc: dhcwg@ietf.org, The IESG <iesg@ietf.org>, Kim Kinnear <kkinnear@cisco.com>
Subject: Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv4-active-leasequery-06: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 21:00:27 -0000

Ben,

Thank you for your review.  I will respond to the specific issues
you raise below.

On Sep 29, 2015, at 11:52 PM, Ben Campbell <ben@nostrum.com> wrote:

> Ben Campbell 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:
> ----------------------------------------------------------------------
> 
> Do you really want to discourage implementations that only support secure
> mode?

	There are installations who would prefer to operate in
	insecure mode for operational reasons.  That said, we do allow
	implementation of secure only mode. 

	I don't think that "SHOULD be able to operate in either
	insecure or secure mode" is all that discouraging to an
	implementor who feels that secure mode is the only thing that
	their users want (or should want).

> Is there a reason not to make secure mode MTI?

	As I just said in response to Alissa Cooper:

	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.	

> 
> Do I understand correctly that insecure mode makes no attempt to
> authorize requestors?

	Correct.

> If so, that should probably be mentioned in the
> security considerations. (I note that 6926 had some words about access
> control in the security considerations, but if this draft has the
> equivalent, I missed it.)

	I will add this sentence to the Security Considerations
	section:

	"Operating in insecure mode (see Section 8.1) does not
	provide any way to validate the authorization of requestors
	of a DHCPV4 Active Leasequery request."

> 
> The fact that insecure mode at the server does not allow a requester to
> upgrade to secure mode seems brittle.  That is, it's easy to configure
> things where the server and requester simply cannot talk.

	I don't disagree, and initially I had a negotiation approach
	written into the protocol.  In the Int-dir review of the
	DHCPv6 Active Leasequery draft (which is essentially identical
	in all respects to this draft) which was done in May 2015, Ted
	Lemon had me remove all of that and make it so that
	configuration on the server governed, period.  The theory was
	that, if the server could be contacted from insecure places
	(or if the data on the server was considered sufficiently
	confidential), that it would require secure access.  End of
	story.  The server knows what sort of data it has and
	(presumably, though less clearly) knows who can contact it.

	I will say that the current approach is *much* clearer than
	what went before, and while you can certainly configure things
	to not be able to talk, in practice I don't see that as a
	major problem.

	Bottom line:  I think we need to leave this one the way it is.



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I agree with Alissa's discuss questioning why this allows the insecure
> mode at all.
> 
> The draft could use a general pass to clean up the use of 2119 keywords.
> There are a lot of redundant normative statements between sections, and
> within sections. There are  2119 keywords in places that really don't
> need them--you don't need a MUST or a SHOULD to just describe the basic
> workings of a protocol. They should be saved for places where an
> implementer has a decision to make, or is likely to do the wrong thing.
> I've captured some examples, but I know I didn't get them all.
> 
> -- 3: "server SHOULD provide a mechanism to control which data is
> allowed"
> 
> Why not MUST?

	Two reasons:

	1. I generally try to not create requirements as to how the
	administrative interface for a protocol works.  I think that
	my responsibility is to what is on the wire, and I try to give
	guidance on administrative controls but not requirements.  In
	some cases, (e.g. the configuration of insecure mode), I have
	made requirements in the draft, but for anything less
	important, I resist the temptation to tell people how to build
	their admin interfaces.

	2. There are legitimate differences as to how important
	controlling the information in an Active Leasequery response
	is.  We could discuss this at length (and we can if you
	desire), but for now I would just say that some people think
	this is really important, and some people see it as less
	important.
> 
>  "with the exception that
>   a server responding to an Active Leasequery request SHOULD be able to
>   be configured to prevent specific data items from being included in
>   the response to the requestor even if they were requested by
>   inclusion in the dhcp-parameter-request-list option."
> 
> Redundant with previous. (Also, why not MUST)?

	Both of these statements come after a reference to RFC 6926,
	and are explaining why you don't do it *exactly* like RFC
	6926.  As such, I don't see them as redundant.  In addition,
	they were put in due to Stephen Farrell's review of the DHCPv6
	Active Leasequery draft, and I wanted to make sure that I
	handled his issue in a way that nobody could miss it.

	I have explained why not a MUST in the item #1 of the
	previous section.
> 
> -- 7.1: "If the attempt fails,
>   the Requestor MAY retry."
> 
> How many times? How often? 


	In some protocols, the details of retry times and counts are 
	specified in depth.  I don't see this protocol as one of those
	that requires an in-depth specification of these values.  I expect
	that someone implementing a requestor will do something reasonable
	here.  If they don't, it won't work as well as if they did.

	I can take out this entire sentence if you think it would be better.

> 
> -- 7.2:  "A requestor SHOULD be able to operate in either insecure or
> secure
>   mode.  This MAY be a feature that is administratively controlled."
> 
> Why only MAY?

	Same answer as above -- I try to not make requirements on 
	administrative interfaces when I don't have to.
> 
>  "When operating in insecure mode, the requestor SHOULD proceed to send
>   a DHCPACTIVELEASEQUERY request after the establishment of a TCP
>   connection."
> 
> Why not MUST? Or more to the point, why does this need a 2119
> keyword--it's simply how the protocol works?

	Good point.  I'll change this to "... the requestor sends a
	DHCPACTIVELEASEQUERY request ...".
> 
>  "The recommendations in [RFC7525] SHOULD be followed when negotiating
>   this connection."
> 
> Why not MUST? (Or as Alissa commented, why not "The recommendations in
> [RFC7525] apply")

	Yes, I agreed with Alissa to make this "The recommendations in
	[RFC7525] apply."
> 
>  "the requestor SHOULD initiate the
>   exchange of the messages involved in a TLS handshake "
> 
> Why not MUST? When might it not do so?

	Good point, MUST makes more sense, I'll change it to MUST.
> 
>  "If the handshake exchange does not yield a functioning TLS
>   connection, then the requester MUST close the TCP connection."
> 
> Is the requester allows to attempt a new connection in insecure mode?

	The requestor can initiate a new connection in any mode
	it wants to.  
> 
> -- 7.3: "The DHCPv4 request MUST have an
>   xid (transaction-id) unique on the connection on which it is sent."
> 
> Redundant with previous statement.

	I'm sorry, I don't understand.  There is no previous statement
	in this section that discusses the transaction-id, so ...
> 
>  "the requester SHOULD place this
>   highest base-time value into a query-start-time option"
> 
> Why does this need to be a 2119 keyword? It seems like the requester can
> do this if it cares about catch-up data, otherwise skip it. (as indicated
> by the next paragraph)

	Good point, I'll remove the 2119 keyword.
> 
> -- 7.4: "
>  "Note that a DHCPACTIVELEASEQUERY request specifically requests the
>   DHCPv4 server to create a long-lived connection "
> 
> I thought the Requester created the connections.

	Yes, you are correct.  This sentence is really designed to 
	tell people that the connection could be staying up for a good
	long time.  I'll change it to:

	"Note that the connection resulting from accepting a
	DHCPACTIVELEASEQUERY request may be long-lived, and may
	not have data transferring continuously during its lifetime."
> 
>  "This SHOULD
>   be the last message on that connection, and once the message has been
>   transmitted, the server SHOULD close the connection."
> 
> Why are the SHOULDs not MUSTs? When might one send additional messages,
> or not close the connection?

	I'll change them to MUSTS.
> 
> -- 7.4.1: "The requester MUST NOT assume that every individual state
> change..."
> 
> Redundant with previous statement.

	I don't see this as redundant.  There is a similar statement
	in Section 6, but I think both are important to communicate 
	this rather critical piece of information.  But the implication
	of your statement is that this is redundant with something just
	immediately previous, and I don't see that, so I must be missing
	something.
> 
> -- 8.1:
> 
>   "Any options appearing in a DHCPTLS message received by a DHCPv4
>   server SHOULD be ignored."
> 
> Why not MUST? When might a server chose not to ignore them?

	An interesting question.  I put this in due to a review on the
	DHCPv6 Active Leasequery draft, and the SHOULD instead of the
	MUST is just to allow someone to include some options someday
	in a DHCPTLS message (perhaps in support of some other protocol),
	and not have to "update" this draft where the DHCPTLS message
	is defined.

	If you feel strongly that this must be a MUST, I will change it.
> 
>  "If for some reason the DHCPv4 server cannot or has been configured to
>   not support a TLS connection, then it SHOULD send a DHCPTLS message
>   with a dhcp-status-code of TLSConnectionRefused back to the
>   requestor."
> 
> Why not MUST? When might it do something different?

	Good point, I'll change it to a MUST.
> 
> -- 8.1.1:
> 
> Why not MUST?
	
	I'll change it to a MUST.
> 
> -- 8.4:
> 
>  "The server MAY close its end of the TCP connection after sending its
>   last message, a DHCPLEASEQUERYSTATUS message in response to a query."
> 
> This seems to contradict previous normative statements. But I suspect you
> mean something to the effect of "The server MAY end communication by
> sending a DHCPLEASEQUERYSTATUS and them immediately closing the TCP
> connection."

	Yes, thanks, that is exactly what I mean.  I'll change it
	to your sentence, which is much clearer.
> 
> -- 9:
> 
> The section seems to have a lot of redundant 2119 keywords.

	Well, lets get specific.  Here is the part of Section 9
	with 2119 keywords, and my response to each:


>    When operating in secure mode, TLS [RFC5246] is used to secure the
>    connection.  The recommendations in [RFC7525] SHOULD be followed when
>    negotiating a TLS connection.

	We've already agreed that this will get redone as per Alissa
	Cooper's comment.
> 
>    Servers SHOULD offer configuration parameters to limit the sources of
>    incoming connections through validation and use of the digital
>    certificates presented to create a TLS connection.  They SHOULD also
>    limit the number of accepted connections, and limit the period of
>    time during which an idle connection will be left open.

	The first sentence is offering a suggestion as to how to create
	an administrative interface.  We have already discussed how to
	do the actual connections, but not that you should be able to 
	configure anything about them.  So I think this is still valid.
> 
>    The data acquired by using an Active Leasequery is subject to the
>    same potential abuse as the data held by the DHCPv4 server from which
>    it was acquired, and SHOULD be secured by mechanisms as strong as
>    those used for the data held by that DHCPv4 server.  The data
>    acquired by using an Active Leasequery SHOULD be deleted as soon as
>    possible after the use for which it was acquired has passed.

	This is the first time we have said this, and I think the
	SHOULD's are useful here.  In actuality, there isn't much more
	strength in a MUST here, as we are really only trying to wake
	people up to the fact that this stuff is valuable data.

> 
>    Servers which implement the Bulk Leasequery protocol [RFC6926] but do
>    not implement the Active Leasequery protocol SHOULD implement the
>    update to [RFC6926] discussed in Section 8.1.1.

	Yes, we said this before.  Is this really a problem?  I could 
	take it out, I suppose.  

> 
> 
> *** Editorial: 
> 
> -- 7.3:, paragraph starting with "Note that until all the recent
> data..."
> 
> This paragraph would make more sense after the explanation of base-time
> in the following paragraph.

	Excellent!  I'll swap the paragraphs.
> 
> -- 8.2:
> 
>  "The DHCPv4 server SHOULD, but is not required to, keep track of a
>   limited amount of previous binding activity"
> 
> I suggest " ... limit the amount of previous binding activity it keeps
> track of..."

	Okay.  I'll change it to:

	"The DHCPv4 server SHOULD keep track of previous binding activity.
	It SHOULD limit the amount of previous binding activity it keeps
	track of."

	Thanks -- Kim




> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg