Note: This ballot was opened for revision 01 and is now closed.
(Jari Arkko) Yes
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
Comment (2007-06-05 for -)
Section 3.2., paragraph 0: > 3.2. Anticipatory Query Given that this is future work, I suggest to make this section an informational appendix, rather than having it be part of the body of a PS specification.
(Sam Hartman) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
(Cullen Jennings) No Objection
(Jon Peterson) No Objection
(Tim Polk) (was Discuss) No Objection
[The follow text is Julien Laganierâ€™s SecDir Review, in its entirety. Please consider these as Last Call comments. Note that some of Julien's issues were also highlighted in my DISCUSS.] I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other (late) last call comments. Summary: - I am really not a DHC expert, so some of my comments/questions might be bogus -- please apologize in advance. - I think the Protocol Overview Section could do a better job of explaining what this is about; IMHO someone who isn't familiar with this can only guess. - Bottom line is that Security Considerations should be more explicit about which attacks can be defended against and how, and which cannot (e.g. rogue DHCP relay with correct keying material for DHCP auth). In Section: 3. Protocol Overview One important motivating example is that the LEASEQUERY message allows access concentrators to query DHCP servers to obtain location information of broadband access network devices. I have some idea of what an "access concentrators" is, but I will find it helpful if it was defined in the Terminology Section, especially since it appears multiple times in the remainder of the document, including Security Considerations Section. Otherwise an architecture diagram could help too. Also, what is the "location information"? It could be an IP address, but I don't think so. Would be useful to define more precisely what's in it. The leasequery capability described in this document parallels the DHCPv4 leasequery capability documented in [RFC4388]. As such, it shares many of the basic motivations, design goals and constraints as the capability described in Section 4 of [RFC4388]. I understand that, but then reading the remainder of the Protocol Overview I find them vague and/or unclear. On the other hand, reading through RFC4388 I could easily understand motivations, goals, etc. Since this document "shares many of the basic motivations, design goals and constraints as the capability described in Section 4 of [RFC4388]", how about simply referring to those, and spelling out differences? The same could also be applied to the Security Considerations Section, although if there's too much differences between the v4 and v6 of the LEASEQUERY then it does't make much sense. In Section: 5. Security Considerations The senders of LEASEQUERY messages are expected to be within the same security domain as the DHCPv6 server. As such, the security threat to DHCPv6 leasequery is inherently an insider threat. It can't be "inherently an insider threat" if the document doesn't recommend filtering LEASEQUERY messages at the domain's boundary, which it doesn't: However, this document doesn't prohibit entities in external security domains from sending LEASEQUERY messages to DHCPv6 servers. Regardless of the network configuration, however, the potential attacks by insiders and outsiders are the same. Hence I'm missing the point that the paragraph above tries to convey. If the requestor is an access concentrator, DHCPv6 leasequery security SHOULD follow security between the relay agent and the DHCPv6 server as described in  Sections 21.1 and 22.11. What if the requestor is *not* an access concentrator, it doesn't need to secure the queries? [...] DHCPv6 servers SHOULD also provide for the ability to restrict the information that they make via leasequery, as described in Section 4.4.2. => [...] that they make available [...] ? DHCPv6 servers supporting LEASEQUERY SHOULD ensure that they cannot be successfully attacked By whom? by being flooded with large quantities of LEASEQUERY messages in a short time. How can they ensure? Rate limitation, DHCP authentication...? In some environments, it may be appropriate to configure a DHCPv6 server with the IPv6 source addresses of the relay agents for which it may respond to LEASEQUERY messages, thereby allowing it to respond only to requests from only a handful of relay agents. This does not provide any true security, but may be useful to thwart unsophisticated attacks of various sorts. I don't see how that would protect from flooding attacks. Who is going to flood the server? Legitimate relays, or unlegitimate ones. If authentication between requestor and server is in place, only legitimate host can flood. Are we trying to protect against them? If authentication isn't in place, then attackers can also spoof IP addresses of relays. Replayed messages can represent a DOS attack through exhaustion of processing resources, bogus leasequery requestors can send a lot of LEASEQUERY messages to overwhelm a DHCPv6 server, thus preventing the server from serving legitimate and regular DHCPv6 clients as well as legitimate DHCPv6 leasequery requestors, denying configurations to legitimate DHCPv6 clients as well lease information to legitimate DHCPv6 leasequery requestors. Maybe say here that authentication of DHCP messages with rekeying would protect against replay attacks? One attack specific to an access concentrator as a requestor is the establishment of a malicious server with the intent of providing incorrect lease or route information to the access concentrator, thwarting source IPv6 address verification and preventing correct routing. Again, maybe say that DHCP auth would block that too. Two editorial nits: 1. Introduction s/programitcally/programmatically/ 8. Security Considerations s/DOS/Denial-of-Service/ I hope the review helps. Best, --julien