Joe, 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 >> replies; >> 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@xxxxxxxx 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 operative: 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 complete." ------------------------------------------------- >>> >>> - 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@xxxxxxxx > 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 he accepted: 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 transit). 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 deployed. 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 Bulk Leasequery: >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. ----------------------------- Regards -- Kim _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf