Active DHCPv4 Lease Query
RFC 7724
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Alvaro Retana No Objection
(Brian Haberman; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) (was Discuss) No Objection
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.
(Barry Leiba; former steering group member) No Objection
Ben has anything I might say nailed quite well; thanks.
(Ben Campbell; former steering group member) (was Discuss) No Objection
Thanks for addressing my DISCUSS points and comments!
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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.
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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?
(Stephen Farrell; former steering group member) No Objection
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.
(Terry Manderson; former steering group member) No Objection