Active DHCPv4 Lease Query
draft-ietf-dhc-dhcpv4-active-leasequery-07

[Ballot comment]
I think it would help to explain the rationale for having both secure and insecure modes supported.

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.

[Ballot comment]
Thank you for including a lot of TCP-awareness in this specification.

I had a few questions, but nothing at Discuss level. If you have questions about my questions, please ask, of course.

In this text,

  A requestor attempts to establish a TCP connection to a DHCPv4 Server
  in order to initiate a Leasequery exchange.  If the attempt fails,
  the Requestor MAY retry.
 
you might want to give some guidance about reasonable intervals to wait before retrying, randomizing retry intervals, and/or backing off retry intervals to some conservative maximum value. This isn't a general-purpose client-server protocol, and you understand the use case better than I do (and I wouldn't try to offer defaults), so please just consider whether this would be helpful.

In this text,

  In any of the first three possibilities, the DHCPv4 server can be
  assumed to not support TLS.  In this case, the requestor MUST close
  the connection.
 
is the assumption that all three possibilities would happen again if you retried the attempt with the same server? I wondered especially about the second possibility (server side TCP connection close, as a possible load-shedding strategy to reject a connection request that might work at another time).

In this text,

  The Requestor attempts to read a DHCPv4 leasequery reply message from
  the TCP connection.  If the stream of replies becomes blocked, the
  Requestor SHOULD terminate the connection after
  ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured
  to do so.
 
I'm not sure what "becomes blocked" means from the Requestor's perspective. I'm guessing the following paragraph, describing interaction with DHCPLEASEQUERYSTATUS, is the clue I'm missing, but if so, reversing the order of the paragraphs, and tying that more tightly ("becomes blocked, with no DHCPLEASEQUERYSTATUS messaging", or whatever the clue I'm missing is), would likely be clearer.

I have pretty much the same question about the corresponding text for the server side in 8.1,

  If the TCP connection becomes blocked while the server is accepting a
  connection or reading a query, it SHOULD terminate the connection
  after a BULK_LQ_DATA_TIMEOUT.  We make this recommendation to allow
  servers to control the period of time they are willing to wait before
  abandoning an inactive connection, independent of the TCP
  implementations they may be using.
 
and in 8.2,

  If the connection becomes blocked while the server is attempting to
  send reply messages, the server SHOULD terminate the TCP connection
  after ACTIVE_LQ_SEND_TIMEOUT.  This timeout governs how long the
  DHCPv4 server is prepared to wait for the requestor to read and
  process enough information to unblock the TCP connection.  The
  default is two minutes, which means that if more than two minutes
  goes by without the requestor reading enough information to unblock
  the TCP connection, the DHCPv4 server SHOULD close the TCP
  connection.
 
This text

8.3.  Multiple or Parallel Queries

  Every Active Leasequery request MUST be made on a single TCP
  connection where there is no other request active at the time the
  request is made.  Note that this is different than what was allowed
  in [RFC6926] section 7.7 for Bulk Leasequery requests.
 
and the following two paragraphs are good, but I didn't see any corresponding description of whether parallel queries were allowed on a single TCP connection in Section 7, for Requestor behavior, and the Requestor would be the entity that does this wrong, wouldn't it? Or did I miss it?

I've seen some use cases described in IESG evaluation e-mail that sounds like the Requestor and DHCPv4 server are close enough for a human to touch both at the same time, but Kathleen commented that some ISPs provide DHCP service to customer edge routers. Is it worth saying anything about firewalls and NATs treating TCP differently? Or would even those cases be part of a trusted network path, so no firewalls or NATs?

[Ballot comment]
I previously had no comments after reading the draft and think it may help to explain why, even though I did see the option for an insecure mode.

DHCP is *typically* used on local networks.  Admins have other controls they can use and I hope they aren't too worried about
their LANs physical security... they can use switches to separate out traffic - no one uses hubs anymore and they should control the equipment and wires.  Additionally, I was thinking that this was IPv4 and was long decided, as well as the discussions that already took place with Stephen for similar text in the IPv6 equivalent.  Since there was an option for a secure mode it could be used in other circumstances like an ISP's DHCP service to customers edge routers or any circumstance where a secure mode is warranted (and that's already stated in the Security Considerations). Security involves risk management decisions for operators and organizations and that has to be okay sometimes.  Since there is an option to use a secure mode (with details on how to do that) when needed, my feeling was the current text is enough given other security controls and the option that could be dependent on the environment.

[Ballot comment]

I think I recognise almost all of the security/privacy text we
ended up with for the dhcpv6 equivalent - thanks for getting all
that right!

For Alissa and Ben - I'd be happier too if only secure mode
existed here, but there was an argument (which I've forgotten)
as to why we needed the insecure one - I think it boiled down to
doing it on the same machine or that they'd do it no matter what
the RFC says. (But I may be mis-remembering.) So while I agree
with your points on that, I'm not sure we're (i.e. we as IESG)
right to fight the battle again over this one when they're
making this the same as the dhcpv6 one we already approved.
Anyway, if you do fight the battle over and win, we should
probably ensure any resulting edits also get done to the dhcpv6
equivalent spec which is with the RFC editor still.

[Ballot discuss]
Do you really want to discourage implementations that only support secure mode? Is there a reason not to make secure mode MTI?

Do I understand correctly that insecure mode makes no attempt to authorize requestors? 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.)

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.

[Ballot 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?

  "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)?

-- 7.1: "If the attempt fails,
  the Requestor MAY retry."

How many times? How often?

-- 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?

  "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?

  "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")

  "the requestor SHOULD initiate the
  exchange of the messages involved in a TLS handshake "

Why not MUST? When might it not do so?

  "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?

-- 7.3: "The DHCPv4 request MUST have an
  xid (transaction-id) unique on the connection on which it is sent."

Redundant with previous statement.

  "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)

-- 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.

  "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?

-- 7.4.1: "The requester MUST NOT assume that every individual state change..."

Redundant with previous statement.

-- 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?

  "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?

-- 8.1.1:

Why not 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."

-- 9:

The section seems to have a lot of redundant 2119 keywords.


*** 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.

-- 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..."

[Ballot 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.

[Ballot 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dhc-dhcpv4-active-leasequery-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the DHCP Message Type 53 Values subregistry of the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry located at:

http://www.iana.org/assignments/bootp-dhcp-parameters/

three new message types are to be registered as follows:

Value: [ TBD-at-Registration ]
Message Type: DHCPACTIVELEASEQUERY
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Message Type: DHCPLEASEQUERYSTATUS
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Message Type: DHCPTLS
Reference: [ RFC-to-be ]

Second, in the DHCP Status Code Type 151 Values also in the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry located at:

http://www.iana.org/assignments/bootp-dhcp-parameters/

four new status codes are to be registered as follows:

Status-Code: [ TBD-at-Registration ]
Name: DataMissing
Reference: [ RFC-to-be ]

Status-Code: [ TBD-at-Registration ]
Name: ConnectionActive
Reference: [ RFC-to-be ]

Status-Code: [ TBD-at-Registration ]
Name: CatchUpComplete
Reference: [ RFC-to-be ]

Status-Code: [ TBD-at-Registration ]
Name: TLSConnectionRefused
Reference: [ RFC-to-be ]

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Active DHCPv4 Lease Query) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Active DHCPv4 Lease Query'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
  extended with a Leasequery capability that allows a requestor to
  request information about DHCPv4 bindings.  That mechanism is limited
  to queries for individual bindings.  In some situations individual
  binding queries may not be efficient, or even possible.  In addition,
  continuous update of an external requestor with Leasequery data is
  sometimes desired.  This document expands on the DHCPv4 Leasequery
  protocol, and allows for active transfer of near real-time DHCPv4
  binding information data via TCP.  This document updates RFC6926,
  DHCPv4 Bulk Leasequery.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1278/

Document Writeup, template from IESG area on ietf.org, dated 24 February
2012.

draft-ietf-dhc-dhcpv4-active-leasequery-04

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

  Standards track. This I-D defines an extension to the DHCPv4 and
  also updates existing standards track RFC, so it is a valid type.
  The indended type is clearly indicated in the header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
  extended with a Leasequery capability that allows a client to request
  information about DHCPv4 bindings.  That mechanism is limited to
  queries for individual bindings.  In some situations individual
  binding queries may not be efficient, or even possible.  In addition,
  continuous update of an external client with Leasequery data is
  sometimes desired.  This document expands on the DHCPv4 Leasequery
  protocol, and allows for active transfer of near real-time DHCPv4
  address binding information data via TCP.

Working Group Summary:

  Active leasequery for DHCPv4 was initially proposed in 2010, but
  after 2 revisions it was abandoned due to lack of interest in the
  WG.  In 2013 active leasequery was proposed for DHCPv6 and received
  strong support in the WG. v6 version was presented in Vancouver
  (IETF88, Nov 2013) and one of the questions was whether WG is
  interested in its v4 equivalent. The strong consensus in the room
  (later confirmed on ML) was to have active leasequery for both
  DHCPv4 and DHCPv6 and thus the v4 draft was revived. As the
  principles are the same, this ended up in a somewhat unusually fast
  path. Cisco seems to have working implementation of this protocol,
  which is reflected in high maturity of the draft. 00 WG item
  passed WGLC in March 2014. The -01 (June 2014) addresses all raised
  comments (all were minor). This work was somewhat stalled as its
  v6 equivalent required several updates. The latest v6 draft was
  approved in June 2015 and all the changes required to address IESG
  comments were applied to v4 (in version -04).

Document Quality:

  This document is of high quality. Personally, I think this is the
  result of several factors: the imlementation primary author is
  involved in has this mechanism implemented with actual deployments
  for serveral years, significant experience of its primary author
  and also the similarity to its DHCPv6 counter-part, which was
  recently approved by IESG. Author made extra care to apply all
  changes to both v4 and v6 drafts. I have reviewed -04 and
  think it is ready for publication. It is idnits clean.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Tomek Mrugalski is the document shepherd. Brian Haberman is the
  responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  I did read this document thoroughly and posted my comments to the
  ML: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15380.html
  All my comments were addressed adequately. I also checked that all
  comments raised during v6 active leasequery review in IESG were
  also addressed in this v4 draft.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. There was sufficient number of comments received, from both the
  usual participants and also several people who typically do not
  participate in DHC discussions.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No. There are no such sections needed. This draft is purely DHCP
  extension, so DHC is the appropriate and sufficient WG to do the
  review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  I do not have any concerns. One objection raised during the
  discussion of the v6 version of this draft was that this mechanism
  can be misused for pervasive monitoring. While technically it is
  true, once the DHCP server cooperates (willingly or otherwise), he
  may provide access to the DHCP server database and extract that
  information anyway. Also, from my business experience I can see
  valid use cases where an ISP could use active leasequery to notify
  its inventory database about devices going up or down.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  Yes. Each author confirmed in writing that they are not aware of any
  outstading IPR disclousures.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes. There is one filed: http://datatracker.ietf.org/ipr/1278/
  It was filed very promptly, couple days after the individual draft
  was submitted. As the draft was individual at that time, the
  announcement was not sent to the ML. This has been brought up to
  the WG attention (http://www.ietf.org/mail-archive/web/dhcwg/current/
  msg15452.html), but it didn't cause any reaction. That is
  understandable, as the IPR disclousure is quite benign. Disclaimer:
  I'm not a laywer and often find legal terms confusing.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is strong consensus for this work. There was never any
  opposition, although the interest was minor couple years ago.
  Since the DHCPv6 equivalent is moving forward, WG decided to proceed
  with DHCPv4 as well. That support was demonstrated during adoption
  call (Dec 2013) and WGLC (Feb/March 2014).

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  There are none. The I-D is idnits clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such additional reviews are required.

(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No. All normative references are to published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

  Yes. It updates DHCPv4 Bulk Leasequery (RFC6926). That information
  is clearly stated on the front page in the header and further
  repeated in Abstract and later explained in the Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA considerations section is written correctly. It requests
  IANA to assign 3 new DHCPv4 message types and 4 new status codes. All
  registers and values are clearly identified, including direct links
  to said registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such reviews were necessary.