idnits 2.17.1 draft-ietf-dhc-leasequery-by-remote-id-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2009) is 5574 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2132' is defined on line 680, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group P. Kurapati 3 Internet-Draft R. Desetti 4 Expires: July 17, 2009 B. Joshi 5 Infosys Technologies Ltd. 6 January 13, 2009 8 DHCPv4 Leasequery by relay agent remote ID 9 draft-ietf-dhc-leasequery-by-remote-id-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 17, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 Some Relay Agents extract lease information from the DHCP message 49 exchanged between the client and DHCP server. This lease information 50 is used by relay agents for various purposes like antispoofing, 51 prevention of flooding. RFC 4388 defines a mechanism for relay 52 agents to retrieve the lease information from the DHCP server as and 53 when this information is lost. Existing leasequery mechanism is data 54 driven which means that a relay agent can initiate the leasequery 55 only when it starts receiving data from/to the clients. In certain 56 scenarios, this model is not scalable. This document first looks at 57 issues in existing mechanism and then proposes a new query type, 58 query by remote ID, to address these issues. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.1. Information Acquisition before Data Starts . . . . . . . . 10 67 4.2. Lessen Negative Caching . . . . . . . . . . . . . . . . . 10 68 4.3. Antispoofing in 'Fast Path' . . . . . . . . . . . . . . . 10 69 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.1. Sending the DHCPLEASEQUERY Message . . . . . . . . . . . . 13 72 6.2. Receiving the DHCPLEASEQUERY Message . . . . . . . . . . . 14 73 6.3. Responding to the DHCPLEASEQUERY Message . . . . . . . . . 14 74 6.4. Determining the IP address to be used in response . . . . 14 75 6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or 76 DHCPLEASEACTIVE Messages . . . . . . . . . . . . . . . . . 15 77 6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 78 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 17 79 6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 80 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 17 81 6.8. Receiving No Response to the DHCPLEASEQUERY Message . . . 18 82 6.9. Lease Binding Data Storage Requirements . . . . . . . . . 18 83 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP 84 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 7. RFC 4388 Considerations . . . . . . . . . . . . . . . . . . . 19 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23 91 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 23 92 Appendix A. Why a New Leasequery is Required? . . . . . . . . . . 24 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 95 1. Introduction 97 DHCP relay agents snoop DHCP messages and append relay agent 98 information option before relaying it to the configured DHCP Servers. 99 In this process, some relay agents also glean the lease information 100 sent by the server and maintain this locally. This information is 101 used for prevention of spoofing attempts from the clients and also 102 sometimes used to install routing information. When relay agent 103 reboots, this information is lost. RFC 4388 [RFC4388] has defined a 104 mechanism to retrieve this lease information from the DHCP server. 105 The existing query types defined by RFC 4388 [RFC4388] are data 106 driven. When client initiates data, based on the source MAC/IP 107 address, relay agent can query the server about the lease 108 information. These mechanisms do not scale well when there are 109 thousands of clients connected to the relay agent. In data driven 110 model, DHCP Leasequery does not provide all the active Lease 111 informations associated with a given connection/circuit [consolidated 112 information] which will result into an inefficient anti-spoofing. It 113 also has to contend with considerable resources for negative caching 114 specially under spoof attacks. 116 We need a mechanism for relay agent to retrieve the consolidated 117 lease information for a given connection/circuit before traffic is 118 initiated by the clients. 120 +--------+ 121 | DHCP | +--------------+ 122 | Server |-...-| DSLAM | 123 | | | Relay Agent | 124 +--------+ +--------------+ 125 | | 126 +------+ +------+ 127 |Modem1| |Modem2| 128 +------+ +------+ 129 | | | 130 +-----+ +-----+ +-----+ 131 |Host1| |Host2| |Host3| 132 +-----+ +-----+ +-----+ 134 Figure 1 136 For example, when a DSLAM acting as a Relay Agent is rebooted, it 137 should query the server for the lease information for all the 138 connections/circuits. Also, as shown in the above figure, there 139 could be multiple clients on one DSL circuit. Relay agent should get 140 the lease information of all the clients connected to a DSL circuit. 141 This is possible by introducing a new query type based on the Remote 142 Id sub-option of Relay Agent Information option. This document talks 143 about the motivation for the new query type and the method to do the 144 same. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 This document uses the following terms: 154 o "access concentrator" 156 An access concentrator is a router or switch at the broadband access 157 provider's edge of a public broadband access network. This document 158 assumes that the access concentrator includes the DHCP relay agent 159 functionality. 161 o "DHCP client" 163 A DHCP client is an Internet host using DHCP to obtain configuration 164 parameters such as a network address. 166 o "DHCP relay agent" 168 A DHCP relay agent is a third-party agent that transfers Bootstrap 169 Protocol (BOOTP) and DHCP messages between clients and servers 170 residing on different subnets, per RFC951[RFC951] and 171 RFC1542[RFC1542]. 173 o "DHCP server" 175 A DHCP server is an Internet host that returns configuration 176 parameters to DHCP clients. 178 o "downstream" 180 Downstream is the direction from the access concentrator towards the 181 broadband subscriber. 183 o "fast path" 185 Data transfer which happens through Network Processor or an ASIC 186 which are programmed to forward the data at very high speeds. 188 o "gleaning" 190 Gleaning is the extraction of location information from DHCP 191 messages, as the messages are forwarded by the DHCP relay agent 192 function. 194 o "location information" 196 Location information is information needed by the access concentrator 197 to forward traffic to a broadband-accessible host. This information 198 includes knowledge of the host hardware address, the port or virtual 199 circuit that leads to the host, and/or the hardware address of the 200 intervening subscriber modem. 202 o "MAC address" 204 In the context of a DHCP packet, a MAC address consists of the 205 following fields: hardware type "htype", hardware length "hlen", and 206 client hardware address "chaddr". 208 o "slow path" 210 Data transfer which happens through the control plane. Typically 211 this has very limited buffers to store data and the speeds are very 212 low compared to fast path data transfer. 214 o "upstream" 216 Upstream is the direction from the broadband subscriber towards the 217 access concentrator. 219 3. Motivation 221 Consider a typical access concentrator (e.g., DSLAM) working also as 222 a DHCP relay agent. "Fast path" and "slow path" generally exist in 223 most networking boxes. Fast path processing is done in network 224 processor or an ASIC (Application Specific Integrated Circuit). Slow 225 path processing is done in a normal processor. As much as possible, 226 regular data handling code should be in fast path. Slow path 227 processing should be reduced as it may become a bottleneck. 229 For an access concentrator having multiple access ports, multiple IP 230 addresses may be assigned using DHCP to a single port and the number 231 of clients on a port may be unknown. The access concentrator may 232 also not know the network portions of the IP addresses that are 233 assigned to its DHCP clients. 235 The access concentrator gleans IP address or other information for 236 antispoofing and for other purposes from DHCP negotiations. The 237 antispoofing itself is done in fast path. Access concentrator keeps 238 track of only one list of IP addresses: list of IP addresses that are 239 assigned by DHCP server. Traffic for all other IP addresses is 240 dropped. If client starts its data transfer after its DHCP 241 negotiations are gleaned by access concentrator, no legitimate 242 packets will be dropped because of antispoofing. In other words, 243 antispoofing is effective (no legitimate packets are dropped and all 244 spoofed packets are dropped) and efficient (antispoofing is done in 245 fast path). The intention is to achieve similar effective and 246 efficient antispoofing in the lease query scenario also when an 247 access concentrator loses its gleaned information (for example, 248 because of reboot). 250 After a deep analysis, we found that the three existing query types 251 supported by RFC 4388[RFC4388] do not provide effective and efficient 252 antispoofing for the above scenario and a new mechanism is required. 254 The existing query types 256 o necessitate a data driven approach: the lease queries can only be 257 done when access concentrator receives data. That results in 258 increased outage time for clients. 260 o result in excessive negative caching consuming lot of resources 261 under a spoofing attack. 263 o result in antispoofing being done in slow path instead of fast 264 path. 266 The deeper analysis, which led to the above conclusions, itself 267 appears as an Appendix to this document. 269 4. Design Goals 271 The goal of this document is to provide a lightweight mechanism for 272 access concentrator to retrieve lease information available in the 273 DHCP server. The mechanism SHOULD also support an access 274 concentrator to retrieve consolidated lease information for a 275 connection/circuit. 277 4.1. Information Acquisition before Data Starts 279 Existing data driven approach by RFC 4388 [RFC4388] means that the 280 lease queries can only be done when access concentrator receives 281 data. If an approach exists to initiate lease queries even before 282 the calls come up, then it will be more effective. For antispoofing, 283 packets need to be dropped until it gets the lease information from 284 DHCP server. If access concentrator finishes the lease queries 285 before it start receiving data, then there is no need to drop 286 legitimate packets. So, effectively outage time may be reduced. The 287 lease queries should help in retrieving lease information even before 288 the data starts flowing and should be independent of data traffic. 290 4.2. Lessen Negative Caching 292 If lease queries result in negative caches, then that puts additional 293 overhead on access concentrator. The negative caches not only 294 consume precious resources they also need to be managed. Hence they 295 should be avoided as much as possible. The lease queries should 296 reduce the need for negative caching as far as possible. 298 4.3. Antispoofing in 'Fast Path' 300 If Antispoofing is not done in fast path, it will become a bottleneck 301 and may lead to denial of service of access concentrator. The lease 302 queries should make it possible to do antispoofing in fast path. 304 5. Protocol Overview 306 RFC 3046 [RFC3046] defines two sub-options for Relay Agent 307 Information option. Sub-option 1 corresponds to circuit ID which 308 identifies the local circuit of the access concentrator. This sub- 309 option is unique to the relay agent. Sub-option 2 corresponds to 310 remote ID which identifies the remote host end of the circuit. This 311 is globally unique in the network. 313 This document defines a new query type based on remote ID sub-option. 314 Suppose that the access concentrator (e.g., DSLAM) lost the lease 315 information when it was rebooted. When the access concentrator comes 316 up, it would initiate a DHCPLEASEQUERY message for each connection/ 317 circuit containing the Relay Agent Information option [RFC3046] with 318 sub-option remote ID. DHCP server must return an IP address in the 319 ciaddr if it has any record of the client described by the remote ID. 320 In the absence of specific configuration information to the contrary, 321 it SHOULD be the IP address with the latest client-last-transaction- 322 time associated with the client described by the remote ID. The DHCP 323 servers that implement this document always send a response 324 (DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN) to the 325 DHCPLEASEQUERY message. The reasons why a DHCPLEASEUNASSIGNED, 326 DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message might be generated are 327 explained in the specific query regimes below. Servers that do not 328 implement the DHCPLEASEQUERY based on remote ID message SHOULD simply 329 not respond. 331 The query regime is described below: 333 o Query by Agent Remote ID sub-option: 335 For this query, the requester supplies only a option 82 which will 336 include only an Agent Remote ID sub-option in the DHCPLEASEQUERY 337 message. The DHCP server will return any information that it has on 338 the IP address most recently accessed by a client with that Agent 339 Remote ID. In addition, it SHOULD supply any additional IP addresses 340 that have been associated with Agent Remote ID in different subnets. 341 Information about these bindings can then be found using the Query by 342 IP Address, as described in RFC 4388[RFC4388]. 344 The DHCP server MUST reply with a DHCPLEASEACTIVE message if the 345 Agent Remote ID in the DHCPLEASEQUERY message currently has an active 346 lease on an IP address in this DHCP server. The server MUST reply 347 with a DHCPLEASEUNASSIGNED if it has information of the said remote 348 ID but no lease is assigned for the same. The server MAY keep track 349 of the remote ID values for which it has currently active leases as 350 well as any which it has served in the past but for which it has no 351 currently active leases. The server MUST reply with a 352 DHCPLEASEUNKNOWN message if it has no information of the said remote 353 ID. 355 6. Protocol Details 357 In this section, DHCPLEASEQUERY message refers to DHCPLEASEQUERY 358 message with query by remote ID. 360 6.1. Sending the DHCPLEASEQUERY Message 362 The DHCPLEASEQUERY message is typically sent by an access 363 concentrator. The DHCPLEASEQUERY message uses the DHCP message 364 format as described in RFC2131[RFC2131], and uses message number 10 365 in the DHCP Message Type option (option 53). The DHCPLEASEQUERY 366 message has the following pertinent message contents: 368 o The giaddr MUST be set to the IP address of the requester (i.e., 369 the access concentrator). The giaddr is the return address of the 370 DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message 371 from the DHCP server. Note that this use of the giaddr is 372 consistent with the definition of giaddr in RFC2131[RFC2131], 373 where the giaddr is always used as the return address of the DHCP 374 response message. In some (but not all) contexts in RFC 2131, the 375 giaddr is used as the "key" to access the appropriate address 376 pool. 378 o The Parameter Request List option (option 55) SHOULD be set to the 379 options of interest to the requester. It MUST include the Relay 380 Agent Information option (option 82). The other interesting 381 options are likely to include the IP Address Lease Time option 382 (option 51), and possibly the Vendor class identifier option 383 (option 60). In the absence of a Parameter Request List option, 384 the server SHOULD return the same options it would return for a 385 DHCPREQUEST message that didn't contain a DHCPLEASEQUERY message, 386 which includes those mandated by Section 4.3.1 of [RFC2131] as 387 well as any options that the server was configured to always 388 return to a client. 390 Additional details concerning different query types are 392 o Query by Agent Remote ID sub-option: 394 * There MUST be a Relay Agent Information option (option 82) with 395 only Agent Remote ID sub-option (sub-option 2) in the 396 DHCPLEASEQUERY message. 398 * The "ciaddr" field MUST be set to zero. 400 * The values of htype, hlen, and chaddr MUST be set to zero. 402 * The Client-identifier option (option 61) MUST NOT appear in the 403 packet. 405 The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is 406 known to possess authoritative information concerning the remote ID. 407 The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, 408 and in the absence of information concerning which DHCP server might 409 possess authoritative information concerning the remote ID, it SHOULD 410 be sent to all DHCP servers configured for the associated relay agent 411 (if any are known). 413 6.2. Receiving the DHCPLEASEQUERY Message 415 A DHCPLEASEQUERY message MUST have a non-zero giaddr. The 416 DHCPLEASEQUERY message MUST have a zero ciaddr, a zero htype/hlen/ 417 chaddr, and no Client-identifier option. The DHCPLEASEQUERY message 418 MUST have a relay agent option 82 with only remote ID sub-option. 420 6.3. Responding to the DHCPLEASEQUERY Message 422 There are three possible responses to a DHCPLEASEQUERY message: 424 o DHCPLEASEUNASSIGNED 426 The server MUST respond with a DHCPLEASEUNASSIGNED message if this 427 server has information about the remote ID, but there is no 428 associated active lease. The DHCPLEASEUNASSIGNED indicates that the 429 server manages the IP address allocation for the given remote ID, but 430 there is no currently active lease. 432 o DHCPLEASEUNKNOWN 434 The DHCPLEASEUNKNOWN message indicates that the client specified in 435 the DHCPLEASEQUERY message is not managed by the server. 437 o DHCPLEASEACTIVE 439 The DHCPLEASEACTIVE message indicates that the server not only knows 440 the client specified in the DHCPLEASEQUERY message, but also knows 441 that there is an active lease for that client. 443 6.4. Determining the IP address to be used in response 445 Since the response to a DHCPLEASEQUERY request can only contain full 446 information about one IP address -- the one that appears in the 447 "ciaddr" field -- determination of which IP address about which to 448 respond is a key issue. Of course, the values of additional IP 449 addresses for which a client has a lease must also be returned in the 450 associated-ip option (RFC 4388[RFC4388], Section 6.1, #3). This is 451 the only information returned not directly associated with the IP 452 address in the "ciaddr" field. 454 The client's identity is any client that has proffered an identical 455 Agent Remote ID (if the option 82 with Agent Remote ID sub-option 456 appears in DHCPLEASEQUERY message). This client matching approach 457 will, for the purposes of this section, be described as "remote ID". 459 The IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE 460 message MUST be the IP address with the latest client-last- 461 transaction-time associated with the client described by the remote 462 ID specified in the DHCPLEASEQUERY message. 464 If there is only a single IP address that fulfills this criteria, 465 then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE 466 message. 468 In the case where more than one IP address has been accessed by the 469 client specified by the Remote ID, then the DHCP server MUST return 470 the IP address returned to the client in the most recent transaction 471 with the client unless the DHCP server has been configured by the 472 server administrator to use some other preference mechanism. 474 6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or 475 DHCPLEASEACTIVE Messages 477 DHCPLEASEUNASSIGNED and DHCPLEASEUNKNOWN messages are created alike 478 except for message type. DHCP server MUST echo the received Option 479 82 available in DHCPLEASEQUERY in the response. No other options are 480 returned for these messages. With that the processing for a 481 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN message is complete. 483 For the DHCPLEASEACTIVE message, the rest of the processing largely 484 involves returning information about the IP address specified in the 485 "ciaddr" field. 487 The MAC address of the DHCPLEASEACTIVE message MUST be set to the 488 values that identify the client associated with the IP address in the 489 "ciaddr" field of the DHCPLEASEACTIVE message. 491 If the Client-identifier option (option 61) is specified in the 492 Parameter Request List option (option 55), then the Client-identifier 493 (if any) of the client associated with the IP address in the "ciaddr" 494 field SHOULD be returned in the DHCPLEASEACTIVE message. 496 In the case where more than one IP address has been involved in a 497 DHCP message exchange with the client specified by the Agent Remote 498 ID, then the list of all those IP addresses MUST be returned in the 499 associated-ip option, whether or not that option was requested as 500 part of the Parameter Request List option. 502 If the IP Address Lease Time option (option 51) is specified in the 503 Parameter Request List then the DHCP server MUST return this option 504 in the DHCPLEASEACTIVE message with its value equal to the time 505 remaining until lease expiration. 507 A request for the Renewal (T1) Time Value option or the Rebinding 508 (T2) Time Value option in the Parameter Request List of the 509 DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time 510 option is handled. DHCP server SHOULD return these options (when 511 requested) with the remaining time until renewal or rebinding, 512 respectively. 514 The information contained in the most recent Relay Agent Information 515 option received from the relay agent associated with this IP address 516 MUST be included in the DHCPLEASEACTIVE message. 518 The DHCPLEASEACTIVE message SHOULD include the values of all other 519 options not specifically discussed above that were requested in the 520 Parameter Request List of the DHCPLEASEQUERY message and that are 521 acceptable to return based on the list of "non-sensitive options", 522 discussed below. 524 DHCP servers SHOULD be configurable with a list of "non-sensitive 525 options" that can be returned to the access concentrator when 526 specified in the Parameter Request List of the DHCPLEASEQUERY 527 message. Any option not on this list SHOULD NOT be returned to an 528 access concentrator, even if requested by that access concentrator. 530 The DHCP server uses information from its lease binding database to 531 supply the DHCPLEASEACTIVE option values. The values of the options 532 that were returned to the DHCP client would generally be preferred, 533 but in the absence of those, options that were sent in DHCP client 534 requests would be acceptable. 536 In some cases, the Relay Agent Information option in an incoming 537 DHCPREQUEST packet is used to help determine the options returned to 538 the DHCP client that sent the DHCPREQUEST. When responding to a 539 DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay 540 Agent Information option just like it did when responding to the DHCP 541 client in order to determine the values of any options requested by 542 the DHCPLEASEQUERY message. The goal is to return the same option 543 values to the DHCPLEASEQUERY as those that were returned to the 544 DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise 545 specified, above). 547 In the event that two servers are cooperating to provide a high- 548 availability DHCP server, as supported by [RFC2131], they would have 549 to communicate some information about IP address bindings to each 550 other. In order to properly support the DHCPLEASEQUERY message, 551 these servers MUST ensure that they communicate the Relay Agent 552 Information option information to each other in addition to any other 553 IP address binding information. 555 6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 556 DHCPLEASEUNKNOWN Message 558 The server expects a giaddr in the DHCPLEASEQUERY message, and 559 unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 560 DHCPLEASEUNKNOWN message to the giaddr. 562 6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 563 DHCPLEASEUNKNOWN Message 565 When a DHCPLEASEACTIVE message is received in response to the 566 DHCPLEASEQUERY message, it means that there is a currently active 567 lease for this IP address in this DHCP server. The access 568 concentrator SHOULD use the information in the "htype", "hlen", and 569 "chaddr" fields of the DHCPLEASEACTIVE as well as Relay Agent 570 Information option information included in the packet to refresh its 571 location information for this IP address. An access concentrator is 572 likely to query by IP address for all the IP addresses specified in 573 the associated-ip option in the response, if any, at this point in 574 time. 576 When a DHCPLEASEUNASSIGNED message is received in response to the 577 DHCPLEASEQUERY message, it means that there is no currently active 578 lease associated with the client specified by remote ID in the DHCP 579 server, but that this server does in fact manage the IP address 580 allocation for the client specified by remote ID. In this case, the 581 access concentrator SHOULD cache this information for later use. 583 When a DHCPLEASEUNKNOWN message is received by an access concentrator 584 that has sent out a DHCPLEASEQUERY message, it means that the DHCP 585 server does not have definitive information concerning the DHCP 586 client specified in the Agent Remote ID sub-option of the 587 DHCPLEASEQUERY message. The access concentrator SHOULD cache this 588 information, but only for a relatively short lifetime, approximately 589 5 minutes. Having cached this information, the access concentrator 590 SHOULD only infrequently direct a DHCPLEASEQUERY message to a DHCP 591 server that responded to a DHCPLEASEQUERY message with a 592 DHCPLEASEUNKNOWN. 594 6.8. Receiving No Response to the DHCPLEASEQUERY Message 596 When an access concentrator receives no response to a DHCPLEASEQUERY 597 message, it should be handled in the same manner as suggested in RFC 598 4388 [RFC4388]. 600 6.9. Lease Binding Data Storage Requirements 602 Implementation Note: 604 To generate replies for a lease query by remote-id effeciently, a 605 DHCP server should index the lease binding data structures using 606 remote-id. 608 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers 610 This scenario should be handled in the same way it is done in RFC 611 4388 [RFC4388]. 613 7. RFC 4388 Considerations 615 This document is compatible with RFC 4388 [RFC4388] based 616 implementations which means that a client which supports this 617 extension can work with a server not supporting this document 618 provided it uses RFC 4388 [RFC4388] defined query types. Also, a 619 server supporting this document can work with a client not supporting 620 this query type. However, there are some changes that this document 621 proposes with respect to RFC 4388 [RFC4388]. Implementors extending 622 RFC 4388 [RFC4388] implementation to support this document, should 623 take note of the following points: 625 o RFC 4388 [RFC4388] suggests that a DHCPLEASEUNASSIGNED is returned 626 only in the case of 'query by IP address'. All other query types 627 will have a return message of either DHCPLEASEACTIVE or 628 DHCPLEASEUNKNOWN'. This document proposes that 629 DHCPLEASEUNASSIGNED can be returned for the query by remote ID. 631 o There may be cases where a query by IP address/MAC address/Client 632 Identifier has an option 82 containing remote ID. In that case, 633 the query will still be recognized as query by IP address/MAC 634 address/Client Identifier as specified by RFC 4388 [RFC4388]. 636 o Section 6.4 of RFC 4388 [RFC4388] suggests that a DHCPLEASEUNKNOWN 637 MUST NOT have any other option present. But for a query by remote 638 ID, option 82 MUST be present in the reply. 640 8. Security Considerations 642 This document does not introduce any new security concerns beyond 643 those specified in the original leasequery protocol RFC 4388 644 [RFC4388] specifications. 646 9. IANA Considerations 648 This document does not introduce any new namespaces for the IANA to 649 manage. 651 10. Acknowledgments 653 Copious amounts of text in this document are derived from RFC 4388 654 [RFC4388]. Kim kinnear provided valuable feedback on this document. 656 11. References 658 11.1. Normative Reference 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 664 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 666 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 667 RFC 2131, March 1997. 669 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 670 RFC 3046, January 2001. 672 11.2. Informative Reference 674 [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", 675 RFC 951, September 1985. 677 [RFC1542] Wimer, W., "Clarifications and Extensions for the 678 Bootstrap Protocol", RFC 1542, October 1993. 680 [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 681 Extensions", RFC 2132, March 1997. 683 Appendix A. Why a New Leasequery is Required? 685 The three existing query types supported by RFC 4388 do not provide 686 effective and efficient antispoofing for the above scenario. 688 o Query by Client Identifier 690 Query by Client Identifier is not possible because to use that access 691 concentrator need to glean client identifier also but the whole issue 692 is that we need leasequeries because the gleaned information was 693 lost. On the other hand, we can query by client identifier when 694 client sends a DHCP request, but then there may not be any need for 695 lease query as such -- regular gleaning may be enough. 697 o Query by IP Address 699 RFC 4388 suggests that it is preferable to use Query by IP Address 700 when getting downstream traffic. 702 Query by IP address is not very useful in downstream traffic because 703 downstream traffic may not exist for the clients on a access port. 704 (In most Internet applications, downstream traffic exists only when a 705 client sends upstream traffic). In other words, the client will be 706 denied service until it gets downstream traffic, which may never 707 come. 709 Query by IP address may be used for upstream traffic. Then whenever 710 an upstream packet comes whose IP address is unknown to the access 711 concentrator, a lease query may be initiated. A related question is 712 what to do with that upstream traffic itself until lease query 713 response comes? If the traffic is dropped, we may be dropping 714 legitimate traffic. If the traffic is forwarded, we may be 715 forwarding spoofed packets. Once the lease response comes, 716 subsequent traffic is handled depending on the response. If a 717 DHCPLEASEACTIVE response comes, access concentrator will accept the 718 traffic. If a DHCPLEASEUNASSIGNED response comes, access 719 concentrator will drop the traffic corresponding to the IP address. 720 If a DHCPLEASEUNKNOWN response comes, access concentrator may drop 721 the traffic corresponding to the IP address but will have to 722 periodically send the lease query for that IP address again 723 (additional overhead). The process is triggered whenever an unknown 724 IP address comes. 726 Note that access concentrator needs to keep track of 4 lists of IP 727 addresses: (1) List of IP addresses for which it got DHCPLEASEACTIVE 728 responses; (2) List of IP addresses for which it got 729 DHCPLEASEUNASSIGNED responses; (3) List of IP addresses for which it 730 got DHCPLEASEUNKNOWN responses; (4) All other IP addresses. 732 This approach may be acceptable if only legitimate traffic is 733 received. Consider the case when someone sends packets that uses 734 spoofed IP addresses. In that case, lease response will be 735 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. RFC 4388 suggests usage of 736 negative caching in this regard (which involves additional 737 resources). 739 In a spoofing type of attack, negative caching information may grow 740 considerably if attacker varies the source IP address. For each such 741 new source IP address, traffic will come to slow path, a new lease 742 query needs to be initiated, response will be processed, and negative 743 caching to be done. That will mean using many resources for negative 744 caching. 746 RFC 4388 suggests that if the access concentrator knows the network 747 portion of the IP addresses that are assigned to its clients, then 748 some amount of antispoofing can be done in fast path and some lease 749 queries may be avoided. But as indicated before, that information 750 may not always be available to access concentrators. 752 Effectively, antispoofing support involves considerable slow path 753 processing and considerable resources tied for negative caching. 755 RFC 4388 says that DHCP server should be protected from being flooded 756 with too many leasequery requests and access concentrator also should 757 not send too many lease query messages at a time. This would mean 758 that legitimate clients may be excessively delayed getting their 759 information in the face of antispoofing attacks. 761 It is concluded that antispoofing is neither effective nor efficient 762 with this query type. 764 o Query by MAC Address 766 Query by MAC address can also be used similar to query by IP address 767 described above. Indeed, query by MAC address may be better than 768 query by IP address in one sense because of the possible presence of 769 associated-ip option in lease responses (Note that associated-ip 770 option does not appear in responses for query by IP address). With 771 associated-ip option, access concentrator can get information not 772 only about the IP address/MAC address that triggered the lease query 773 but also about other IP addresses that are associated with the 774 original MAC address. That way, when traffic that uses the other IP 775 addresses comes along, access concentrator is already prepared to 776 deal with them. 778 Although, query by MAC address is better than query by IP address in 779 the above respect, it has a specific problem which is not shared by 780 query by IP address. For a query by MAC address, only two types of 781 responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE; 782 DHCPLEASEUNASSIGNED is not supported. This is particularly 783 troublesome when a DHCP server indeed has definitive information that 784 no IP addresses are associated with the specified MAC address in the 785 leasequery, but it is forced to respond with DHCPLEASEUNKNOWN instead 786 of DHCPLEASEUNASSIGNED. As we have seen above, unlike 787 DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying with 788 DHCP server, an additional overhead. 790 Moreover, query by MAC address also shares all other issues we 791 discussed above for query by IP address. 793 We conclude that existing lease query types are not appropriate to 794 achieve effective and efficient antispoofing. 796 Authors' Addresses 798 Pavan Kurapati 799 Infosys Technologies Ltd. 800 44 Electronics City, Hosur Road 801 Bangalore 560 100 802 India 804 Email: pavan_kurapati@infosys.com 805 URI: http://www.infosys.com/ 807 D.T.V Ramakrishna Rao 808 Infosys Technologies Ltd. 809 44 Electronics City, Hosur Road 810 Bangalore 560 100 811 India 813 Email: ramakrishnadtv@infosys.com 814 URI: http://www.infosys.com/ 816 Bharat Joshi 817 Infosys Technologies Ltd. 818 44 Electronics City, Hosur Road 819 Bangalore 560 100 820 India 822 Email: bharat_joshi@infosys.com 823 URI: http://www.infosys.com/