DHCPv6 Leasequery
draft-ietf-dhc-dhcpv6-leasequery-01

[Note]: 'Document Shepherd is Ralph Droms <rdroms@cisco.com>
NOTE: Tools server has a weird copy of this draft. Use the ietf.org server.' added by Jari Arkko

[Ballot comment]
From the Gen-ART by Pasi Eronen ...

  Some editorial suggestions: RFC editor nowadays recommends using
  symbolic references (e.g. [RFC3911] instead of [5]); and abbreviations
  should be expanded on first use (e.g. KPLM, UA, UAC, UAS, and GRUU).

[Ballot discuss]
What happened with LC comments from Ian Elz?  I think a response was
  deserved, but I cannot find one.  Did I miss it?

[Ballot discuss]
As a matter of process the secdir review has not received a response
Tim has pulled the specific blocking comments into a discuss, but I
also think we should block until the authors actually respond to the
last call comments raised.  Tim, if you want to pick this up, that
would be fine with me.

[Ballot comment]
[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

[Ballot discuss]
Access concentrator needs to be defined in Section 2.  This section references RFC 3315 for
terminology, but this term is not used in 3315. I presume you are using the definition from
RFC 4388:

          An access concentrator is a router or switch at the broadband
          access provider's edge of a public broadband access network.
          This document assumes that the access concentrator includes
          the DHCP relay agent functionality.

If this is the correct definition, it would be very helpful to include it in the  spec!

Similarly, a definition for location information would be helpful as well.  Are the peer
address in the Relay Data option and the link-address in the client link option both
examples of location information, or only data in the client link option?

This Security Considerations section seems to assume that the query originates with an
access concentrator.  (Paragraphs two and three address the access concentrator
scenario directly; no other scenario is considered.)  Are there any legitimate scenarios
where the query comes from a component that isn’t an access concentrator?  Are there
security considerations specific to such requesters?

Paragraph 1 in Security Considerations implies that networks should generally be
configured so that LEASEQUERY messages are limited to systems in the same
security domain.  This idea seems to merit a more explicit statement!

In RFC 4388, the Security Consdierations include the following text:

  Access concentrators SHOULD minimize potential denial of service
  attacks on the DHCP servers by minimizing the generation of
  DHCPLEASEQUERY messages.  In particular, the access concentrator
  SHOULD employ negative caching (i.e., cache DHCPLEASEUNASSIGNED,
  DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
  messages) and ciaddr restriction (i.e., don't send a DHCPLEASEQUERY
  message with a ciaddr outside of the range of the attached broadband
  access networks).  Together, these mechanisms limit the access
  concentrator to transmitting one DHCPLEASEQUERY message (excluding
  message retries) per legitimate broadband access network IP address
  after a reboot event.

Is there analagous guidance that should be provided to access concentrators
that implement this specification?

[Ballot comment]
[The follow text is Julien Laganier’s SecDir Review, in its entirety.  Please
consider these as Last Call comments. Note that some issues
were also addressed 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

[Ballot discuss]
Access concentrator needs to be defined in Section 2.  This section references RFC 3315 for
terminology, but this term is not used in 3315. I presume you are using the definition from
RFC 4388:

          An access concentrator is a router or switch at the broadband
          access provider's edge of a public broadband access network.
          This document assumes that the access concentrator includes
          the DHCP relay agent functionality.

If this is the correct definition, it would be very helpful to include it in the  spec!

Similarly, a definition for location information would be helpful as well.  Are the peer
address in the Relay Data option and the link-address in the client link option both
examples of location information, or only data in the client link option?

This Security Considerations section seems to assume that the query originates with an
access concentrator.  (Paragraphs two and three address the access concentrator
scenario directly; no other scenario is considered.)  Are there any legitimate scenarios
where the query comes from a component that isn’t an access concentrator?  Are there
security considerations specific to such requesters?

Paragraph 1 in Security Considerations implies that networks should generally be
configured so that LEASEQUERY messages are limited to systems in the same
security domain.  This idea seems to merit a more explicit statement!

[Ballot comment]
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.

IANA Last Call Comments:

**** IANA has Questions about this document ***

Action #1:
Upon approval of this document, the IANA will make the
following assignments in the "DHCPv6 and DHCPv6 options -
per [RFC3315]" registry located at

http://www.iana.org/assignments/dhcpv6-parameters

sub-registry "DHCP Message types"

TDB1 LEASEQUERY [RFC-dhc-dhcpv6-leasequery-00]
TDB2 LEASEQUERY-REPLY [RFC-dhc-dhcpv6-leasequery-00]
(TDB2+1) - ??? Available for assignment

Action #2:
Upon approval of this document, the IANA will make the
following assignments in the "DHCPv6 and DHCPv6 options -
per [RFC3315]" registry located at

http://www.iana.org/assignments/dhcpv6-parameters

sub-registry "DHCP Option Codes"

TDB3 OPTION_LQ_QUERY [RFC-dhc-dhcpv6-leasequery-00]
TEB4 OPTION_CLIENT_DATA [RFC-dhc-dhcpv6-leasequery-00]
TDB5 OPTION_CLT_TIME [RFC-dhc-dhcpv6-leasequery-00]
TDB6 OPTION_LQ_RELAY_DATA [RFC-dhc-dhcpv6-leasequery-00]
TDB7 OPTION_LQ_CLIENT_LINK [RFC-dhc-dhcpv6-leasequery-00]
(TDB7+1) - ??? Available for assignment


Action #3:
Upon approval of this document, the IANA will make the
following assignments in the "DHCPv6 and DHCPv6 options -
per [RFC3315]" registry located at

http://www.iana.org/assignments/dhcpv6-parameters

sub-registry "DHCP Status Codes"

TDB8 UnknownQueryType [RFC-dhc-dhcpv6-leasequery-00]
TDB9 MalformedQuery [RFC-dhc-dhcpv6-leasequery-00]
TDB10 NotConfigured [RFC-dhc-dhcpv6-leasequery-00]
TDB11 NotAllowed [RFC-dhc-dhcpv6-leasequery-00]
(TDB11+1) - ??? Available for assignment


Action #4:
Upon approval of this document, the IANA will create the
following sub-registry named "LQ_QUERY options"
in the "DHCPv6 and DHCPv6 options - per [RFC3315]" registry
located at http://www.iana.org/assignments/dhcpv6-parameters

Initial contents of this registry will be:

1 QUERY_BY_ADDRESS [RFC-dhc-dhcpv6-leasequery-00]
2 QUERY_BY_CLIENTID [RFC-dhc-dhcpv6-leasequery-00]
3 - ??? Available for assignment


Allocation policy is missing.

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Ralph Droms, dhc WG co-chair
I have reviewed the document and I believe it is ready for
publication.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

The document was carefully reviewed and extensively discussed on the
dhc WG mailing list.  As a result of the discussion, the design of the
leasequery mechanism was significantly simplified and clarified.
During WG last call on the document, the participants in the earlier
WG mailing list discussion said they thought the document is now ready
for publication.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No.  This document describes an internal infrastructure mechanism for
DHCP, similar to the DHCPv4 leasequery mechanism in RFC 4388.  It uses
no other technologies that might require review.

(1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it.  In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here.  Has an IPR disclosure related to this document
      been filed?  If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

I have no specific concerns about this document.  The primary area of
technical discussion about this document was in the inclusion of
extensions like different query methods and bulk transfers.  The
consensus of the WG was to leave those extensions out of the
specification and the text for the extensions has been removed from
the document.

To the best of my knowledge, there are no IPR disclosures on file with
the IETF related to this document.

(1.e)  How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

There was significant WG involvement in the development of the final
version of this document.  There was strong consensus from a few
individuals, with no dissenting opinions, in response to the WG last
call.  Although only a few individuals responded to the WG last call,
I believe the WG as a whole understands and agrees with the document.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No.

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

I have verified that the document meets the requirements of
ID-Checklist.html.  There are no formal reviews required.

(1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

The references are split into normative and informative.  There are no
problematic normative references.

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggest a
      reasonable name for the new registry?  See [RFC2434].  If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists.  It specifies reservations
that are appropriate for the clearly identified existing registries.
The document requests the creation of a new registry, but does not
suggest a name.  This issue can be dealt with during IESG review.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

N/A

(1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Write-Up?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

      Technical Summary
  Relevant content can frequently be found in the abstract
  and/or introduction of the document.  If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

  "DHCPv6 Leasequery"
  specifies a mechanism, "leasequery", for the Dynamic Host
  Configuration Protocol for IPv6 (DHCPv6) through which lease
  information about DHCPv6 clients can be obtained from a DHCPv6
  server.  This document specifies the scope of data that can be
  retrieved as well as both DHCPv6 leasequery requestor and server
  behavior.  This document extends DHCPv6.

      Working Group Summary
  Was there anything in WG process that is worth noting?  For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Nothing to note beyond what is described above.

      Document Quality
  Are there existing implementations of the protocol?  Have a
  significant number of vendors indicated their plan to
  implement the specification?  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?  If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)?  In the case of a Media Type
  review, on what date was the request posted?

There are no known implementations of the protocol.  Comcast
contributed to the document, so it is expected that there will be
implementations to meet Comcast and other DOCSIS 3.0 deployment
requirements.  No special reviews were performed or required.

The mechanism in this document is related to and based in
implementation and deployment experience with a similar leasequery
mechanism for DHCPv4, RFC 4388.

      Personnel
  Who is the Document Shepherd for this document?  Who is the
  Responsible Area Director? Is an IANA expert needed?

Shepherd: Ralph Droms
AD:      Jari Arkko
IANA:    N/A