draft-ietf-dhc-leasequery-by-remote-id-08.txt   draft-ietf-dhc-leasequery-by-remote-id-09.txt 
DHC Working Group P. Kurapati DHC Working Group P. Kurapati
Internet-Draft Juniper Networks Ltd. Internet-Draft Juniper Networks.
Updates: 4388 (if approved) R. Desetti Updates: 4388 (if approved) R. Desetti
Intended status: Standards Track B. Joshi Intended status: Standards Track B. Joshi
Expires: May 20, 2011 Infosys Technologies Ltd. Expires: June 6, 2011 Infosys Technologies Ltd.
November 16, 2010 December 3, 2010
DHCPv4 lease query by Relay Agent Remote ID DHCPv4 lease query by Relay Agent Remote ID
draft-ietf-dhc-leasequery-by-remote-id-08.txt draft-ietf-dhc-leasequery-by-remote-id-09.txt
Abstract Abstract
Some Relay Agents extract lease information from the DHCP messages Some Relay Agents extract lease information from the DHCP messages
exchanged between the client and DHCP server. This lease information exchanged between the client and DHCP server. This lease information
is used by relay agents for various purposes like antispoofing and is used by relay agents for various purposes like antispoofing and
prevention of flooding. RFC 4388 defines a mechanism for relay prevention of flooding. RFC 4388 defines a mechanism for relay
agents to retrieve the lease information from the DHCP server as and agents to retrieve the lease information from the DHCP server when
when this information is lost. The existing lease query mechanism is this information is lost. The existing lease query mechanism is data
data driven, which means that a relay agent can initiate the lease driven, which means that a relay agent can initiate the lease query
query only when it starts receiving data from/to the clients. In only when it starts receiving data from/to the clients. In certain
certain scenarios, this model is not scalable. This document first scenarios, this model is not scalable. This document first looks at
looks at issues in existing mechanism and then proposes a new query issues in existing mechanism and then proposes a new query type,
type, query by Remote ID, to address these issues. query by Remote ID, to address these issues.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2011. This Internet-Draft will expire on June 6, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 21 skipping to change at page 4, line 21
information is used to prevent spoofing attempts from clients and information is used to prevent spoofing attempts from clients and
also sometimes to install routing information. When a relay agent also sometimes to install routing information. When a relay agent
reboots, this information is lost. RFC 4388 [RFC4388] has defined a reboots, this information is lost. RFC 4388 [RFC4388] has defined a
mechanism to retrieve this lease information from the DHCP server. mechanism to retrieve this lease information from the DHCP server.
The existing query types defined by RFC 4388 [RFC4388] are data- The existing query types defined by RFC 4388 [RFC4388] are data-
driven. When a client sends data upstream, the relay agent can query driven. When a client sends data upstream, the relay agent can query
the server about the related lease information, based on the source the server about the related lease information, based on the source
MAC/IP address. These mechanisms do not scale well when there are MAC/IP address. These mechanisms do not scale well when there are
thousands of clients connected to the relay agent. In the data thousands of clients connected to the relay agent. In the data
driven model, lease query does not provide the full and consolidated driven model, lease query does not provide the full and consolidated
active lease informations associated with a given connection/circuit, active lease information associated with a given connection/circuit,
which will result in inefficient anti-spoofing. The relay agent also which will result in inefficient anti-spoofing. The relay agent also
has to contend with considerable resources for negative caching has to contend with considerable resources for negative caching
specially under spoofing attacks. specially under spoofing attacks.
We need a mechanism for a relay agent to retrieve the consolidated We need a mechanism for a relay agent to retrieve the consolidated
lease information for a given connection/circuit before upstream lease information for a given connection/circuit before upstream
traffic is sent by the clients. traffic is sent by the clients.
+--------+ +--------+
| DHCP | +--------------+ | DHCP | +--------------+
skipping to change at page 4, line 46 skipping to change at page 4, line 46
+------+ +------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Node1| |Node2| |Node3| |Node1| |Node2| |Node3|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 1 Figure 1
For example, when a DSLAM acting as a Relay Agent is rebooted, it For example, when a DSLAM (Digital Subscriber Line Access
should query the server for the lease information for all the Multiplexer) acting as a Relay Agent is rebooted, it should query the
connections/circuits. Also, as shown in the above figure, there server for the lease information for all the connections/circuits.
could be multiple clients on one DSL circuit. The relay agent should Also, as shown in the above figure, there could be multiple clients
get the lease information of all the clients connected to a DSL on one DSL circuit. The relay agent should get the lease information
circuit. This is possible by introducing a new query type based on of all the clients connected to a DSL circuit. This is possible by
the Remote ID sub-option of the Relay Agent Information option. This introducing a new query type based on the Remote ID sub-option of the
document talks about the motivation for the new query type and the Relay Agent Information option. This document talks about the
method to perform it. motivation for the new query type and the method to perform it.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
o "Access Concentrator" o "Access Concentrator"
skipping to change at page 7, line 15 skipping to change at page 7, line 15
of the intervening subscriber modem. of the intervening subscriber modem.
o "MAC address" o "MAC address"
In the context of a DHCP packet, a MAC address consists of the In the context of a DHCP packet, a MAC address consists of the
following fields: hardware type "htype", hardware length "hlen", and following fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr". client hardware address "chaddr".
o "Slow path" o "Slow path"
Data transfer that happens through the control plane. Typically this Data transfer that happens through the control plane. This has very
has very limited buffers to store data and the speeds are very low limited buffers to store data and the speeds are very low compared to
compared to the fast path data transfer. the fast path data transfer.
o "Upstream" o "Upstream"
Upstream is the direction from the broadband subscriber towards the Upstream is the direction from the broadband subscriber towards the
access concentrator. access concentrator.
3. Motivation 3. Motivation
Consider a typical access concentrator (e.g., DSLAM) working also as Consider an access concentrator (e.g., DSLAM) working also as a DHCP
a DHCP relay agent. A "Fast path" and a "slow path" generally exist relay agent. A "Fast path" and a "slow path" generally exist in most
in most networking boxes. Fast path processing is done in a network networking boxes. Fast path processing is done in a network
processor or an ASIC (Application Specific Integrated Circuit). Slow processor or an ASIC (Application Specific Integrated Circuit). Slow
path processing is done in a normal processor. As much as possible, path processing is done in a normal processor. As much as possible,
regular data forwarding should be done in the fast path. Slow path regular data forwarding should be done in the fast path. Slow path
processing should be reduced as it may become a bottleneck. processing should be reduced as it may become a bottleneck.
For an access concentrator having multiple access ports, multiple IP For an access concentrator having multiple access ports, multiple IP
addresses may be assigned using DHCP to a single port and the number addresses may be assigned using DHCP to a single port and the number
of clients on a port may be unknown. The access concentrator may of clients on a port may be unknown. The access concentrator may
also not know the network portions of the IP addresses that are also not know the network portions of the IP addresses that are
assigned to its DHCP clients. assigned to its DHCP clients.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
reboot. reboot.
The DHCP server MUST reply with a DHCPLEASEACTIVE message if there is The DHCP server MUST reply with a DHCPLEASEACTIVE message if there is
an active lease corresponding to the Remote ID that is present in the an active lease corresponding to the Remote ID that is present in the
DHCPLEASEQUERY message. Otherwise, the server MUST reply with a DHCPLEASEQUERY message. Otherwise, the server MUST reply with a
DHCPLEASEUNKNOWN message. Servers that do not implement DHCP lease DHCPLEASEUNKNOWN message. Servers that do not implement DHCP lease
query based on Remote ID SHOULD simply not respond. query based on Remote ID SHOULD simply not respond.
4.1. Sending the DHCPLEASEQUERY Message 4.1. Sending the DHCPLEASEQUERY Message
The DHCPLEASEQUERY message is typically sent by an access The lease query defined in this document will mostly be used by
concentrator. The DHCPLEASEQUERY message uses the DHCP message access concentrators, but it may also be used by other authorized
format as described in RFC 2131 [RFC2131], and uses message number 10 elements in the network. The DHCPLEASEQUERY message uses the DHCP
in the DHCP Message Type option (option 53). The DHCPLEASEQUERY message format as described in RFC 2131 [RFC2131], and uses message
message has the following pertinent message contents: number 10 in the DHCP Message Type option (option 53). The
DHCPLEASEQUERY message has the following pertinent message contents:
o There MUST be a Relay Agent Information option (option 82) with o There MUST be a Relay Agent Information option (option 82) with
only a Remote ID sub-option (sub-option 2) in the DHCPLEASEQUERY only a Remote ID sub-option (sub-option 2) in the DHCPLEASEQUERY
message. message.
o The Parameter Request List option [RFC2132] MUST be populated by o The Parameter Request List option [RFC2132] MUST be populated by
the access concentrator with the Associated-IP option code. The the access concentrator with the Associated-IP option code. The
giaddr field and other option codes listed in Parameter Request giaddr field and other option codes listed in Parameter Request
List option are set as explained in section 6.2 of RFC 4388 List option are set as explained in section 6.2 of RFC 4388
[RFC4388]. [RFC4388].
skipping to change at page 12, line 22 skipping to change at page 12, line 22
addresses can lead to negative caching of greater magnitude. Another addresses can lead to negative caching of greater magnitude. Another
important change that this draft brings is the removal of periodic important change that this draft brings is the removal of periodic
lease queries generated from negative caching caused by lease queries generated from negative caching caused by
DHCPLEASEUNKNOWN. Since the information obtained through query by DHCPLEASEUNKNOWN. Since the information obtained through query by
Remote ID is complete, there is no need of attempting lease query Remote ID is complete, there is no need of attempting lease query
again for the same connection. again for the same connection.
4.7. Receiving No Response to the DHCPLEASEQUERY Message 4.7. Receiving No Response to the DHCPLEASEQUERY Message
The condition of an access concentrator receiving no response to a The condition of an access concentrator receiving no response to a
DHCPLEASEQUERY message should be handled in the same manner as DHCPLEASEQUERY message is handled in the same manner as suggested in
suggested in RFC 4388 [RFC4388]. RFC 4388 [RFC4388].
4.8. Lease Binding Data Storage Requirements 4.8. Lease Binding Data Storage Requirements
Implementation Note: Implementation Note:
To generate replies for a lease query by Remote ID effeciently, a To generate replies for a lease query by Remote ID efficiently, a
DHCP server should index the lease binding data structures using DHCP server should index the lease binding data structures using
Remote ID. Remote ID.
4.9. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers 4.9. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers
This scenario should be handled in the same way it is done in RFC This scenario is handled in the same way it is done in RFC 4388
4388 [RFC4388]. [RFC4388].
5. RFC 4388 Considerations 5. RFC 4388 Considerations
This document is compatible with RFC 4388 [RFC4388] based This document is compatible with RFC 4388 [RFC4388] based
implementations, which means that a client that supports this implementations, which means that a client that supports this
extension can work with a server not supporting this document, extension can work with a server not supporting this document,
provided it uses RFC 4388 [RFC4388] defined query types. Also, a provided it uses RFC 4388 [RFC4388] defined query types. Also, a
server supporting this document can work with a client not supporting server supporting this document can work with a client not supporting
this query type. However, there are some changes that this document this query type. However, there are some changes that this document
proposes with respect to RFC 4388 [RFC4388]. Implementers extending proposes with respect to RFC 4388 [RFC4388]. Implementers extending
skipping to change at page 14, line 7 skipping to change at page 14, line 7
Identifier has an option 82 containing Remote ID. In that case, Identifier has an option 82 containing Remote ID. In that case,
the query will still be recognized as query by IP address/MAC the query will still be recognized as query by IP address/MAC
address/Client Identifier as specified by RFC 4388 [RFC4388]. address/Client Identifier as specified by RFC 4388 [RFC4388].
o Section 6.4 of RFC 4388 [RFC4388] suggests that a DHCPLEASEUNKNOWN o Section 6.4 of RFC 4388 [RFC4388] suggests that a DHCPLEASEUNKNOWN
MUST NOT have any other option present. But for a query by Remote MUST NOT have any other option present. But for a query by Remote
ID, option 82 MUST be present in the reply. ID, option 82 MUST be present in the reply.
6. Security Considerations 6. Security Considerations
This document does not introduce any new security concerns beyond This document inherits the security concerns present in the original
those specified in the original lease query protocol RFC 4388 lease query protocol RFC 4388 [RFC4388] specifications.
[RFC4388] specifications.
This specification introduces one additional issue, beyond those
described in RFC 4388 [RFC4388]. A query by remote-id will result in
the server replying with a consolidated lease binding information.
Such a query, if done from an unauthorized source may lead to leak of
lease binding information. It is critical to deploy authentication
techniques mentioned in RFC 3118 [RFC3118] to prevent such
unauthorized lease queries.
7. IANA Considerations 7. IANA Considerations
This document does not introduce any new namespaces for the IANA to This document does not introduce any new namespaces for the IANA to
manage. manage.
8. Acknowledgments 8. Acknowledgments
Copious amounts of text in this document are derived from RFC 4388 Copious amounts of text in this document are derived from RFC 4388
[RFC4388]. Kim Kinnear, Damien Neil, Stephen Jacob, Ted Lemon, Ralph [RFC4388]. Kim Kinnear, Damien Neil, Stephen Jacob, Ted Lemon, Ralph
skipping to change at page 17, line 24 skipping to change at page 17, line 24
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001. RFC 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
9.2. Informative Reference 9.2. Informative Reference
[RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)",
RFC 951, September 1985. RFC 951, September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the [RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
Authors' Addresses Authors' Addresses
Pavan Kurapati Pavan Kurapati
Juniper Networks Ltd. Juniper Networks.
Embassy Prime Buildings, C.V.Raman Nagar Embassy Prime Buildings, C.V.Raman Nagar
Bangalore 560 093 Bangalore 560 093
India India
Email: kurapati@juniper.net Email: kurapati@juniper.net
URI: http://www.juniper.net/ URI: http://www.juniper.net/
D.T.V Ramakrishna Rao D.T.V Ramakrishna Rao
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
 End of changes. 16 change blocks. 
42 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/