[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dhcwg] Revised DHCPv6 Leasequery Draft
Hello:
The IESG review and IETF last-call process uncovered a bunch of issues
with regards to the draft-ietf-dhc-dhcpv6-leasequery-00 draft and I've
just submitted a revised version to address those nits and more
significant issues.
For those that want to review the revised draft now, you can do so at
ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-dhcpv6-leasequery-01.txt.
Attached is also the differences between the two drafts.
The highlight of the changes (from the change log in the draft) are:
The changes between draft-ietf-dhc-dhcpv6-leaesquery-00 and this
version were as a result of the IETF last-call and IESG review:
o Several spelling, typographical, and grammatical corrections were
made.
o The Terminology section was expanded to define more of the terms
used, using the definitions from RFC 4388 [3].
o The Introduction and Protocol Overview sections were revised to
explicitly reference material in RFC 4388 [3] and also indicate
some of the key differences.
o The Security Considerations section was reworked.
o The IANA Considerations section now specifies how new query-type
codes are assigned - through Standards Action.
o Additional references were added as a result of the above changes.
Thanks to those that pointed out the above issues during the last-
call process, including Jari Arkko, Lars Eggert, Sam Hartman, Alfred
Hoenes, Tim Polk, and the folks at IANA.
The IESG status of this draft and issues can be viewed at
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&;
ballot_id=2449&filename=draft-ietf-dhc-dhcpv6-leasequery.
I did circulate a preliminary version to those that had pointed out
issues (minor or major) and have received comments back from most that
this version addresses their concerns, including Tim Polk.
- Bernie
Abstract
- This document specifies a leasequery exchange for the Dynamic Host
- Configuration Protocol for IPv6 (DHCPv6) which can be used to obtain
+ This document specifies leasequery for the Dynamic Host Configuration
+ Protocol for IPv6 (DHCPv6) which can be used as a means to obtain
lease information about DHCPv6 clients 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.
1. Introduction
The DHCPv6 [2] protocol specifies a mechanism for the assignment of
---
assigned using DHCPv6 [2] [4]. Specific examples where this
information has illustrated value are in broadband networks to
facilitate access control by edge devices. This capability to
- programmatically extract lease data from the DHCPv6 server is called
+ programitcally extract lease data from the DHCPv6 server is called
leasequery.
- The leasequery capability described in this document parallels the
- DHCPv4 leasequery capability documented in [3]. As such, it shares
- the basic motivations, background, design goals and constraints as
- described in [3]. Differences are due to the differences between
- IPv4 and IPv6 and by extension, DHCPv4 and DHCPv6. For example,
- Neighbor Discovery [7] is used in IPv6 instead of ARP [8] (section
- 4.1 of [3]) and DOCSIS 3.0 [11] defines IPv6 support for cable modem
- environments.
+ Existing specifications, such as [3] are leveraged as a basis for
+ extending the DHCPv6 protocol to support leasequery. The motivations
+ and justifications identified in [3] also generally apply to this
+ specification. Furthermore, advancements in DHCPv6 [2] are expanded
+ upon to specify additional means by which IPv6 address and delegated
+ prefix lease data can be retrieved through DHCPv6 leasequery.
2. Terminology
---
DHCPv6 terminology is defined in [2]. Terminology specific to DHCPv6
leasequery can be found below:
- access concentrator
- 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 DHCPv6 relay agent functionality.
-
client(s) The nodes that have one or more bindings
with a DHCPv6 server. This does not refer to
the node issuing the LEASEQUERY unless it
itself has one or more bindings with a DHCPv6
server.
- gleaning Gleaning is the extraction of location
- information from DHCPv6 messages, as the
- messages are forwarded by the DHCP relay agent
- function.
-
- location information
- Location information is information needed by
- the access concentrator to forward traffic to
- a broadband-accessible host. This information
- includes knowledge of the host hardware
- address, the port or virtual circuit that
- leads to the host, and/or the hardware address
- of the intervening subscriber modem.
-
requestor The node that sends LEASEQUERY messages to one
or more servers to retrieve information on the
bindings for a client.
-
3. Protocol Overview
The focus of this document is to extend the DHCPv6 protocol to allow
---
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. This is described
- in section 1 of [3] for IPv4.
+ information of broadband access network devices.
+
+ The leasequery capability described in this document parallels the
+ DHCPv4 leasequery capability documented in [3]. As such, it shares
+ many of the basic motivations, design goals and constraints as the
+ capability described in Section 4 of [3].
3.1. On-Demand Query
---
3.3. Query Types
- Leasequery provides for the following queries:
+ Leasquery provides for the following queries:
Query by IPv6 address - This query allows a requestor to request
from a server the bindings for a client that either is bound to
---
4.1.2. Options
+
4.1.2.1. Query Option
- The Query option is used only in a LEASEQUERY message and identifies
- the query being performed. The option includes the query type, link-
- address (or 0::0), and option(s) to provide data needed for the
- query.
+ The Leasequery Query option is used only in a LEASEQUERY message and
+ identifies the query being performed. The option includes the query
+ type, link-address (or 0::0), and option(s) to provide data needed
+ for the query.
The format of the Query option is shown below:
---
provides the relay agent information used when the client last
communicated with the server.
- The format of the Relay Data option is shown below:
+ The format of the Client Links option is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
---
This option is used by the server to return full relay agent
information for a client. It MUST NOT be returned if the server does
- not have such information, either because the client communicated
- directly (without relay agent) with the server or if the server did
- not retain such information.
+ not have such information, either because the client last
+ communicated directly (without relay agent) with the server or if the
+ server does not retained such information.
If returned, the DHCP-relay-message MUST contain a valid (perhaps
multi-hop) RELAY-FORW message as most recently received by the server
---
This option SHOULD only be returned if requested by the OPTION_ORO of
the OPTION_LQ_QUERY.
+
4.1.2.5. Client Link Option
The Client Link option is used only in a LEASEQUERY-REPLY message and
---
requestor.
o Send to multiple servers by multicasting to the All_DHCP_Servers
address.
- o Terminate the request.
+ o Terminate the leasequery.
4.3.3. Receipt of LEASEQUERY-REPLY
A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE
option (or an OPTION_STATUS_CODE option with a success code). There
- are three variants:
- 1. If the server had bindings for the requested client, the message
+ are three varients:
+ 1. If the server has bindings for the requested client, the message
includes an OPTION_CLIENT_DATA option and the requestor extracts
- the client data from the LEASEQUERY-REPLY and updates its binding
+ the client data for the LEASEQUERY-REPLY and updates its binding
information database. If the OPTION_CLIENT_DATA contains no
OPTION_CLT_TIME, the requestor SHOULD silently discard the
OPTION_CLIENT_DATA option.
---
the message includes an OPTION_CLIENT_LINK option. The requestor
will need to reissue LEASEQUERY messages using each of the
returned link-addresses to obtain the client's bindings.
- 3. If the server had no bindings for the client, neither the
+ 3. If the server has no bindings for the client, neither the
OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present.
An unsuccessful LEASEQUERY-REPLY is one that has an
---
4.4.2. Constructing the Client's OPTION_CLIENT_DATA
An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST
- minimally contain the following options:
+ minimally contain the following data.
1. OPTION_CLIENTID
- 2. OPTION_IAADDR and/or OPTION_IAPREFIX
- 3. OPTION_CLT_TIME
+ 2. OPTION_IAADDR
+ 3. OPTION_IAPREFIX
+ 4. OPTION_CLT_TIME
Depending on the bindings the client has on a link, either
OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be
---
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. 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.
+
+ 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.
+ Requestors are essentially a DHCPv6 client for the purposes of the
+ LEASEQUERY message. Thus, DHCPv6 authentication [2] is also an
+ appropriate mechanism for securing LEASEQUERY and LEASEQUERY-REPLY
+ messages.
+
Access concentrators are expected to be common leasequery requestors.
- Access concentrators that use DHCPv6 gleaning (i.e., [10]), refreshed
+ Access concentrators that use DHCPv6 gleaning (i.e., [6]), refreshed
with LEASEQUERY messages, will maintain accurate client/binding
information. This ensures that the access concentrator can forward
data traffic to the intended destination in the broadband access
network, can perform IPv6 source address verification of datagrams
from the access network, and can encrypt traffic that can only be
- decrypted by the intended access modem (e.g., [12] and [13]). Thus,
- the leasequery capability allows an access concentrator to provide
- considerably enhanced security.
-
- The "Security Considerations" section of [2] details the general
- threats to DHCPv6, and thus to LEASEQUERY messages. The
- "Authentication of DHCP Messages" section of [2] describes securing
- communication between relay agents and servers, as well as clients
- and servers. If the requestor is an access concentrator, the IPsec
- [9] based security as described in [2] section 21.1 SHOULD be used.
- Other types of requestors are essentially DHCPv6 clients. Thus,
- DHCPv6 authentication, section 21 of [2], is an appropriate mechanism
- for securing LEASEQUERY and LEASEQUERY-REPLY messages. As the number
- of leasequery requestors and servers in an administrative domain is
- relatively small, any shared key distribution issues are minimized.
-
- After implementing the above approaches, the DHCPv6 server should
- only be communicating with trusted LEASEQUERY requestors, and so
- security needs should be met.
-
- However, not all traffic originates directly from these trusted
- requestors. For example, trusted relay agents can relay LEASEQUERY
- messages from untrusted requestors or elsewhere in the network. This
- SHOULD be prevented at least at the perimeter relay agents (or on all
- relay agents unless relayed LEASEQUERY messages are required for some
- requestors). DHCPv6 servers MAY be configured to discard relayed
- LEASEQUERY messages or restrict relay chaining.
+ decrypted by the intended access modem (e.g., [7] and [8]). Thus,
+ the LEASEQUERY message allows an access concentrator to provide
+ considerably enhanced security. DHCPv6 servers SHOULD prevent
+ exposure of their information (particularly the mapping of hardware
+ address to IPv6 address, which can be an invasion of broadband
+ subscriber privacy) by employing the techniques detailed in [2],
+ Section 21, "Authentication of DHCP Messages".
DHCPv6 servers SHOULD also provide for the ability to restrict the
- information returned for a client in a LEASEQUERY-REPLY even to a
- trusted LEASEQUERY requestor, as described in Section 4.4.2.
+ information that they make via leasequery, as described in
+ Section 4.4.2.
- Since even trusted access concentrators may generate LEASEQUERY
- requests as a result of activity external to the access concentrator,
- access concentrators SHOULD minimize potential denial of service
- attacks on the DHCPv6 servers by minimizing the generation of
- LEASEQUERY messages. In particular, the access concentrator SHOULD
- employ negative caching (i.e., cache the fact that a particular
- recent query failed to return client data) and address restrictions
- where possible (i.e., don't send a LEASEQUERY message for addresses
- outside of the range of the attached broadband access networks).
- Together, these mechanisms limit the access concentrator to
- transmitting one LEASEQUERY message (excluding message retries) per
- legitimate broadband access network address after a reboot event.
-
- Packet flooding denial of service attacks can result in the
- exhaustion of processing resources, 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. While these attacks are unlikely when only
- communicating with trusted LEASEQUERY requestors, the possibility
- always exists that the trust is misplaced, security techniques are
- compromised, or even trusted requestors can have bugs in them.
- Therefore techniques for defending against packet flooding denial of
- service are always a good idea, and they include good perimeter
- security as mentioned earlier and rate limiting DHCPv6 traffic by
- relay agents, other network elements, or the server itself.
-
- One way to attack an access concentrator (as opposed to a DHCPv6
- server) as a LEASEQUERY 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. This type of attack can
- be minimized by using IPsec as described in section 21.1 of [2].
+ DHCPv6 servers supporting LEASEQUERY SHOULD ensure that they cannot
+ be successfully attacked by being flooded with large quantities of
+ LEASEQUERY messages in a short time. 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.
+
+ 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.
+
+ 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.
6. IANA Considerations
---
QUERY_BY_ADDRESS 1
QUERY_BY_CLIENTID 2
- New OPTION_LQ_QUERY option query-type codes are assigned through
- Standards Action, as defined in [6].
-
7. Acknowledgements
---
OPTION_LQ_RELAY_DATA option.
o And, other minor changes to accommodate the above.
- The changes between draft-ietf-dhc-dhcvp6-leasequery-01 and
- draft-ietf-dhcpv6-leasequery-00 (the corrected document name) were:
+ The changes between draft-ietf-dhc-dhcvp6-leasequery-01 and this
+ version with the corrected document name were:
o Fixed draft name (had dhcvp6 instead of dhcpv6).
o Removed reference to SRSN I-D and associated text. SRSN is only
needed if and when RAAN moves forward (in or close to its current
form).
- o Added [12] and [13] references that were missing (referenced in
+ o Added [7] and [8] references that were missing (referenced in
Security Considerations section).
o Updated RAAN I-D reference to current version.
o Updated boilerplate and copyright year.
- The changes between draft-ietf-dhc-dhcpv6-leaesquery-00 and this
- version were as a result of the IETF last-call and IESG review:
- o Several spelling, typographical, and grammatical corrections were
- made.
- o The Terminology section was expanded to define more of the terms
- used, using the definitions from RFC 4388 [3].
- o The Introduction and Protocol Overview sections were revised to
- explicitly reference material in RFC 4388 [3] and also indicate
- some of the key differences.
- o The Security Considerations section was reworked.
- o The IANA Considerations section now specifies how new query-type
- codes are assigned - through Standards Action.
- o Additional references were added as a result of the above changes.
-
- Thanks to those that pointed out the above issues during the last-
- call process, including Jari Arkko, Lars Eggert, Sam Hartman, Alfred
- Hoenes, Tim Polk, and the folks at IANA.
-
9. References
9.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
- [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
- (DHCP) Leasequery", RFC 4388, February 2006.
-
- [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
- Configuration Protocol (DHCP) version 6", RFC 3633,
- December 2003.
+ [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+ Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+ RFC 3315, July 2003.
+
+ [3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
+ (DHCP) Leasequery", RFC 4388, February 2006.
+
+ [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+ Configuration Protocol (DHCP) version 6", RFC 3633,
+ December 2003.
9.2. Informative References
- [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
- [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
- for IP Version 6 (IPv6)", RFC 2461, December 1998.
-
- [8] Plummer, D., "Ethernet Address Resolution Protocol: Or
- converting network protocol addresses to 48.bit Ethernet
- address for transmission on Ethernet hardware", STD 37,
- RFC 826, November 1982.
-
- [9] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [10] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN)
- Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 (work in
- progress), November 2006.
-
- [11] CableLabs, "Data-Over-Cable Service Interface Specifications:
- DOCSIS 3.0, MAC and Upper Layer Protocols Interface
- Specification, CM-SP-MULPIv3.0-I04-070518", May 2007, available
- at http://www.cablemodem.com/.
-
- [12] SCTE Data Standards Subcommittee, "Data-Over-Cable Service
- Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface
- Specification SCTE 22-2 2002", 2002, available at
- http://www.scte.org/standards/.
-
- [13] CableLabs, "Data-Over-Cable Service Interface Specifications:
- Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-
- 050812", August 2005, available at http://www.cablemodem.com/.
-
-
+ [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+ [6] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN)
+ Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 (work in
+ progress), November 2006.
+
+ [7] SCTE Data Standards Subcommittee, "Data-Over-Cable Service
+ Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface
+ Specification SCTE 22-2 2002", 2002, available at
+ http://www.scte.org/standards/.
+
+ [8] CableLab, "Data-Over-Cable Service Interface Specifications:
+ Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-
+ 050812", August 2005, available at http://www.cablemodem.com/.
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg