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

[Kim Kinnear <[e-mail]>]

Kathleen,

Ben dropped his DISCUSS based on the response of the security AD's.

Ben said (on Oct 1, 2015 4:37pm EDT)

> Hi, thanks for the response-response :-)
> 
> Based on your responses, and on discussion among the IESG on today's telechat, I will clear the discuss. Further comments inline. I've removed sections that don't seem to need further discussion. Unless I missed something, I think you've covered all my concerns.
> 
> Thanks!
> 
> Ben.

In the same email...

Ben said:

>>> 
>>> To clarify, when I talk about MTI, I mean something to the effect of saying implementations "MUST implement the secure mode, and SHOULD [or MAY] implement the insecure mode"

Kim said:

>> 
>> 	Thanks for the clarification.  I was not clear -- the
>> 	reasoning for allowing insecure mode is the same as for not
>> 	requiring implementation of secure mode.  I expect that some
>> 	implementations will not wish to implement secure mode at all,
>> 	since all of their deployments will be targeted toward
>> 	environments which are protected by more global protections.
>> 
>> 	One use of Active leasequery is an alternative to providing a
>> 	direct connection to the DHCP server's lease state database.
>> 	We want to standardize Active Leasequery in such a way as to
>> 	facilitate that sort of implementation (which makes insecure
>> 	mode appropriate) as well implementations of the more
>> 	distributed sort which require secure mode.

Ben said:

> 
> Thanks for the explanation. We discussed this on the telechat today, and the security ADs are okay without the secure mode being MTI. So I guess I am, as well.
> 

Regards -- Kim


On Oct 6, 2015, at 1:56 PM, Kathleen Moriarty <[e-mail]> wrote:

> I'm chiming in a little late, but I agree with Ben on his mTI comment.
> I had noticed that as well when reading the draft, but was mostly okay
> with the language.  The draft didn't spell out MTI, but seemed to talk
> more about MTU.  MTI for secure mode would be good.  I see the
> security considerations section has an MTU focus.  Where is the
> statement in the list of changes that resulted from Ben's discuss?
> I'm not able to pick it out easily (might just be me).
> 
> Thanks,
> Kathleen
> 
> I'm not sure the SHOULD statement is enough, but if he's okay to clear...
> 
> On Tue, Oct 6, 2015 at 1:39 PM, Kim Kinnear <[e-mail]> wrote:
>> 
>> Ben, et. al.
>> 
>> I've submitted a new version of draft-ietf-dhc-dhcpv4-active-leasequery,
>> with all of the changes to which I agreed during the review process.
>> I've replied to Ben's email since he had the most comments, but I
>> believe that I've covered them all.
>> 
>> I've included an rfc diff with this email, and below you will find a
>> list of the changes that I have made along with whose review prompted
>> that change.
>> 
>> Thank you all for your reviews.
>> 
>> Regards -- Kim
>> 
>> -------------------------
>> 
>> 1. Changed "recommendations in [RFC7525] SHOULD be followed" to
>> "recommendation in [RFC7525] apply".  Alissa Cooper
>> 
>> 2. Added "Retries SHOULD NOT be more frequent than one every
>> ACTIVE_LQ_IDLE_TIMEOUT.  See Section 5.3." to the two places where
>> we say "... the Requestor MAY retry."  Ben Campbell, Spencer Dawkins
>> 
>> 3. Added to Section 8.1:
>> 
>> "If a connection is to be rejected because of a limitation of the
>> number of open connections, the TCP connection itself should be
>> rejected, or the subsequent ACTIVELEASEQUERY message should be
>> rejected.  Capacity related rejections SHOULD NOT affect the response
>> to the DHCPTLS message." Spencer Dawkins
>> 
>> 4. Moved the following paragraph to appear after a paragraph explaining
>> how the server needs to ensure that a constant (albeit light) stream
>> of messages flows from server to requestor:
>> 
>> "If the stream of replies becomes blocked with no messages being
>> received, the Requestor SHOULD terminate the connection after
>> ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
>> to do so."  Spencer Dawkins
>> 
>> 5.  Added the following paragraph to section 7.1, General Processing:
>> 
>> "Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection
>> at a time.  Parallel DHCPACTIVELEASEQUERY requests on the same TCP
>> are no allowed."  Spencer Dawkins
>> 
>> 6. Added the following paragraph to section 9, Security Considerations:
>> 
>> "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."  Ben Campbell
>> 
>> 7. In section 7.2, Initiating a Connection, changed:
>> 
>> "When operating in insecure mode, the requestor SHOULD proceed to send
>> a DHCPACTIVELEASEQUERY request after the establishment of a TCP
>> connection."
>> 
>> to
>> 
>> "When operating in insecure mode, the requestor sends a
>> DHCPACTIVELEASEQUERY request after the establishment of a TCP
>> connection."  Ben Campbell
>> 
>> 8. In section 7.2, Initiating a Connection, changed:
>> 
>> "... the requestor SHOULD initiate the exchange ..."
>> 
>> to
>> 
>> "... the requestor initiates the exchange ..." Ben Campbell
>> 
>> 9. In section 7.3, Forming an Active Leasequery, changed:
>> 
>> "... the requestor SHOULD place this highest base-time value into
>> a query-start-time option in the ..."
>> 
>> to
>> 
>> "... the requestor should place this highest base-time value into
>> a query-start-time option in the ..." Ben Campbell
>> 
>> 10. In section 7.3, Forming an Active Leasequery, changed:
>> 
>> "Note that a DHCPACTIVELEASEQUERY request specifically requests the
>> DHCPv4 server to create a long-lived connection which may not have
>> data transferring continuously during its lifetime."
>> 
>> 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." Ben Campbell
>> 
>> 11. In section 7.4, Processing Active Replies, changed:
>> 
>> "This SHOULD be the last message on that connection, and once the
>> message has been transmitted, the server SHOULD close the connection."
>> 
>> to
>> 
>> "This MUST be the last message on that connection, and once the
>> message has been transmitted, the server MUST close the connection."
>> Ben Campbell
>> 
>> 12. In section 8.1, Accepting Connections, added the following:
>> 
>> After:
>> 
>> "Any options appearing in a DHCPTLS message received by a DHCPv4
>> server SHOULD be ignored."
>> 
>> added:
>> 
>> "Any options appearing in a DHCPTLS message received by a DHCPv4
>> server SHOULD be ignored.  This is a SHOULD instead of a MUST
>> in order to allow use of the DHCPTLS message in later documents,
>> possibly with the use of options, without requiring those documents
>> to update this document." Ben Campbell
>> 
>> 13.  In section 8.1, changed the following:
>> 
>> "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."
>> 
>> to
>> 
>> "If for some reason the DHCPv4 server cannot or has been configured
>> to not support a TLS connection, then it sends a DHCPTLS
>> message with a dhcp-status-code of TLSConnectionRefused back to
>> the requestor."  Ben Campbell
>> 
>> 14. In section 8.1.1, changed the following:
>> 
>> "In an update to the DHCPv4 Bulk Leasequery protocol <xref
>> target="RFC6926"/> (which didn't discuss this situation explicitly),
>> if the DHCPv4 server receives a DHCPv4 message containing a
>> dhcp-message-type option with a value that is not supported over
>> a TCP connection, it SHOULD close the TCP connection."
>> 
>> to
>> 
>> "In an update to the DHCPv4 Bulk Leasequery protocol <xref
>> target="RFC6926"/> (which didn't discuss this situation explicitly),
>> if the DHCPv4 server receives a DHCPv4 message containing a
>> dhcp-message-type option with a value that is not supported over
>> a TCP connection, it MUST close the TCP connection."  Ben Campbell
>> 
>> 15. In section 8.4, changed the following:
>> 
>> "The sever MAY close its end of the TCP connection after sending its
>> last message, a DHCPLEASEQUERYSTATUS message in response to a query."
>> 
>> to
>> 
>> "The sever MAY may end communication by sending a DHCPLEASEQUERYSTATUS
>> message and then immediately closing the TCP connection." Ben Campbell
>> 
>> 16. In section 7.3, moved the paragraph starting with:
>> 
>> "Note that until all of the recent data (catch-up data) has been ..."
>> 
>> after the subsquent paragraph. Ben Campbell
>> 
>> 17. In section 8.2, replaced the paragraph beginning as follows:
>> 
>> "Note that until all of the recent data (catch-up data) has been ..."
>> 
>> with
>> 
>> "The DHCPv4 server SHOULD keep track of previous binding
>> activity.  It SHOULD limit the amount of previous binding activity it
>> keeps track of."  Ben Campbell
>> 
>> 18. Addd this explanation to section 9, Security Considerations:
>> 
>> "Two modes of operation exist for this protocol, insecure mode and
>> secure mode.  These two modes exists 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.  For this model, the insecure mode
>> is sufficient since there are other, more global, protections in
>> place to protect this information."
>> 
>> and placed references to it in section 7.2, Initiating a Connection
>> and section 8.1, Accepting Connections.
>> 
>> Alissa Cooper
>> 
>> 19. Three situations where statements with normative language were used
>> which echoed other similar statements also using normative language were
>> changed to not use normative language.  References to the section of the
>> document where the normative language remains were added.  These
>> changes were made in sections 3, 7.1, and 7.4.1.  Ben Campbell
>> 
>> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen