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
- [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-… Ben Campbell
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Kim Kinnear
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Kim Kinnear
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Kim Kinnear
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Kathleen Moriarty
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Kim Kinnear
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-… Kathleen Moriarty