DHCPv6 Leasequery
RFC 5007

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 -)
No email
send info
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

Comment (2007-06-05)
No email
send info
[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
[2] 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

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection