There were two things that I referenced in response to your initial
review that you hadn't seen. More details on those below:
On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
>> INTERLEAVING- sec 7.7 says that the server MUST interleave
>> there doesn't seem a valid reason for this requirement. clearly the
>> receiver MUST tolerate interleaved replies. having the server interleave
>> replies is relevant only if each request/reply has its own timeout --
>> which should be overridden if there is another response in progress
>> anyway. This issue should be more clearly explained and motivated.
> Robert Sparks offered clarification, which I like
> a lot and have already agreed to use:
I didn't see that; can you send that to tsv-dir@... and me?
>> Is the requirement you are really trying to capture "MUST
>> NOT block sending replies on new queries until all
>> replies for the existing query are complete."?
I wasn't clear here -- the entire result of our
discussion was captured in the text above.
Note that a server does not *have* to support multiple
queries on the same connection. If, however, a server
chooses to do so, then the following discussion is
Based on my discussion with Robert Sparks, the sentence:
"A server that is processing multiple queries
simultaneously MUST interleave replies to the multiple
queries within the stream of reply messages it sends."
will be replaced by the sentence:
"The server MUST NOT block sending replies on new
queries until all replies for the existing query are
>>> - The protocol supports bulk transfer that is not data driven.
>>> This could represent a security vulnerability by exposing
>>> information that may not be on the data path (and thus already
>>> accessible) to a relay agent. This should be discussed in the
>>> security considerations section.
>> All data that is exposed has already been
>> exposed using UDP to regular DHCP port. But please see
>> my response to Stephen Farrell (which is too long to include
>> here) to see if it covers the issues about which you
>> have concerns.
> Again, I didn't see it; please send a copy to tsv-dir@... >
There are two related posts that I will include here
in order to keep this discussion in some kind of order.
Here are the words that I proposed to Stephen which
There are two specific issues regarding Bulk Leasequery
security that deserve explicit mention. The first is
preventing information that Bulk Leasequery can provide from
reaching clients who are not authorized to receive such
information. The second is ensuring that authorized clients of
the Bulk Leasequery capability receive accurate information
from the Server (and that this information is not disrupted in
To prevent information leakage to unauthorized clients Servers
SHOULD restrict Bulk Leasequery connections and
DHCPBULKLEASEQUERY messages to certain requestors, either
through explicit configuration of the Server itself or by
employing external network elements to provide such
restrictions. In particular, the typical DHCPv4 client SHOULD
NOT be allowed to receive a response to a Bulk Leasequery
request, and some technique MUST exist to allow prevention of
such access in any environment where Bulk Leasequery is
Connections not from permitted requestors SHOULD be closed
immediately, to avoid server connection resource exhaustion or
alternatively, simply not be allowed to reach the server at
all. Servers SHOULD have the capability to restrict certain
requestors to certain query types. Servers MAY reply to
queries that are not permitted with the DHCPLEASEQUERYDONE
message with a status-code option status of NotAllowed, or MAY
simply close the connection.
To prevent disruption and malicious corruption of Bulk
Leasequery data flows between the server and authorized clients
these data flows SHOULD transit only secured networks. These
data flows are typically infrastructure oriented, and there is
usually no reason to have them flowing over networks where such
attacks are likely. In the rare cases where these data flows
might need to be sent through unsecured networks, they MUST
sent over connections secured through means external to the
DHCPv4/DHCPv6 server and its client(s) (e.g., through VPN's).
Here is Ted Lemon's reply to Stephen's suggestion about
using SSH/TLS to secure the data flows of DHCPv4
From Ted Lemon, Feb 22 2012, 10:37:12 EST:
The main reason why TLS wasn't included is that there is zero
chance of anyone using it. In practice this protocol is useful
only in a very specific sort of application: communications
between the core of an ISP network and the edge of the ISP
network. Encrypting everything would be quite expensive; the
value of the data that would be acquired in an attack is low; the
risk that there could be an attacker that would do this is low,
since it would require physical access. Furthermore, if someone
does break in, they can just collect this data with a sniffer.
Given these considerations, the additional verbiage and testing
required for TLS support seemed unnecessary and potentially
damaging, since untested code is vulnerable code. The working
group did actually consider requesting that the authors add TLS
to the document, but concluded that it was not worthwhile.