idnits 2.17.1 draft-kurapati-dhc-leasequery-by-remote-id-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. 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 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 (June 14, 2008) is 5767 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) -- Looks like a reference, but probably isn't: 'RFC2131' on line 538 == Unused Reference: '7' is defined on line 666, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 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: December 16, 2008 B. Joshi 5 Infosys Technologies Ltd. 6 June 14, 2008 8 DHCPv4 Leasequery by relay agent remote ID 9 draft-kurapati-dhc-leasequery-by-remote-id-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 16, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Some Relay Agents extract lease information from the DHCP message 43 exchanged between the client and DHCP server. This lease information 44 is used by relay agents for various purposes like antispoofing, 45 prevention of flooding. RFC 4388 defines a mechanism for relay 46 agents to retrieve the lease information from the DHCP server as and 47 when this information is lost. Existing leasequery mechanism is data 48 driven which means that a relay agent can initiate the leasequery 49 only when it starts receiving data from/to the clients. In certain 50 scenarios, this model is not scalable. This document first looks at 51 issues in existing mechanism and then proposes a new query type, 52 query by remote ID, to address these issues. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.1. Information Acquisition before Data Starts . . . . . . . . 9 61 4.2. Lessen Negative Caching . . . . . . . . . . . . . . . . . 9 62 4.3. Antispoofing in 'Fast Path' . . . . . . . . . . . . . . . 9 63 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 64 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. Sending the DHCPLEASEQUERY Message . . . . . . . . . . . . 11 66 6.2. Receiving the DHCPLEASEQUERY Message . . . . . . . . . . . 12 67 6.3. Responding to the DHCPLEASEQUERY Message . . . . . . . . . 12 68 6.4. Determining the IP address to be used in response . . . . 12 69 6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or 70 DHCPLEASEACTIVE Messages . . . . . . . . . . . . . . . . . 13 71 6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 72 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 15 73 6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 74 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 15 75 6.8. Receiving No Response to the DHCPLEASEQUERY Message . . . 15 76 6.9. Lease Binding Data Storage Requirements . . . . . . . . . 16 77 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP 78 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 7. RFC 4388 Considerations . . . . . . . . . . . . . . . . . . . 17 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 21 85 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 86 Appendix 1. Why a New Leasequery is Required? . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 88 Intellectual Property and Copyright Statements . . . . . . . . . . 26 90 1. Introduction 92 DHCP relay agents snoop DHCP messages and append relay agent 93 information option before relaying it to the configured DHCP Servers. 94 In this process, some relay agents also glean the lease information 95 sent by the server and maintain this locally. This information is 96 used for prevention of spoofing attempts from the clients and also 97 sometimes used to install routing information. When relay agent 98 reboots, this information is lost. RFC 4388 [2] has defined a 99 mechanism to retrieve this lease information from the DHCP server. 100 The existing query types defined by RFC 4388 [2] are data driven. 101 When client initiates data, based on the source MAC/IP address, relay 102 agent can query the server about the lease information. These 103 mechanisms do not scale well when there are thousands of clients 104 connected to the relay agent. In data driven model, DHCP Leasequery 105 does not provide all the active Lease informations associated with a 106 given connection/circuit [consolidated information] which will result 107 into an inefficient anti-spoofing. It also has to contend with 108 considerable resources for negative caching specially under spoof 109 attacks. 111 We need a mechanism for relay agent to retrieve the consolidated 112 lease information for a given connection/circuit before traffic is 113 initiated by the clients. 115 +--------+ 116 | DHCP | +--------------+ 117 | Server |-...-| DSLAM | 118 | | | Relay Agent | 119 +--------+ +--------------+ 120 | | 121 +------+ +------+ 122 |Modem1| |Modem2| 123 +------+ +------+ 124 | | | 125 +-----+ +-----+ +-----+ 126 |Host1| |Host2| |Host3| 127 +-----+ +-----+ +-----+ 129 Figure 1 131 For example, when a DSLAM acting as a Relay Agent is rebooted, it 132 should query the server for the lease information for all the 133 connections/circuits. Also, as shown in the above figure, there 134 could be multiple clients on one DSL circuit. Relay agent should get 135 the lease information of all the clients connected to a DSL circuit. 136 This is possible by introducing a new query type based on the Remote 137 Id sub-option of Relay Agent Information option. This document talks 138 about the motivation for the new query type and the method to do the 139 same. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [1]. 147 This document uses the following terms: 149 o "access concentrator" 151 An access concentrator is a router or switch at the broadband access 152 provider's edge of a public broadband access network. This document 153 assumes that the access concentrator includes the DHCP relay agent 154 functionality. 156 o "DHCP client" 158 A DHCP client is an Internet host using DHCP to obtain configuration 159 parameters such as a network address. 161 o "DHCP relay agent" 163 A DHCP relay agent is a third-party agent that transfers Bootstrap 164 Protocol (BOOTP) and DHCP messages between clients and servers 165 residing on different subnets, per RFC951[5] and RFC1542[6]. 167 o "DHCP server" 169 A DHCP server is an Internet host that returns configuration 170 parameters to DHCP clients. 172 o "downstream" 174 Downstream is the direction from the access concentrator towards the 175 broadband subscriber. 177 o "fast path" 179 Data transfer which happens through Network Processor or an ASIC 180 which are programmed to forward the data at very high speeds. 182 o "gleaning" 184 Gleaning is the extraction of location information from DHCP 185 messages, as the messages are forwarded by the DHCP relay agent 186 function. 188 o "location information" 190 Location information is information needed by the access concentrator 191 to forward traffic to a broadband-accessible host. This information 192 includes knowledge of the host hardware address, the port or virtual 193 circuit that leads to the host, and/or the hardware address of the 194 intervening subscriber modem. 196 o "MAC address" 198 In the context of a DHCP packet, a MAC address consists of the 199 following fields: hardware type "htype", hardware length "hlen", and 200 client hardware address "chaddr". 202 o "slow path" 204 Data transfer which happens through the control plane. Typically 205 this has very limited buffers to store data and the speeds are very 206 low compared to fast path data transfer. 208 o "upstream" 210 Upstream is the direction from the broadband subscriber towards the 211 access concentrator. 213 3. Motivation 215 Consider a typical access concentrator (e.g., DSLAM) working also as 216 a DHCP relay agent. "Fast path" and "slow path" generally exist in 217 most networking boxes. Fast path processing is done in network 218 processor or an ASIC (Application Specific Integrated Circuit). Slow 219 path processing is done in a normal processor. As much as possible, 220 regular data handling code should be in fast path. Slow path 221 processing should be reduced as it may become a bottleneck. 223 For an access concentrator having multiple access ports, multiple IP 224 addresses may be assigned using DHCP to a single port and the number 225 of clients on a port may be unknown. The access concentrator may 226 also not know the network portions of the IP addresses that are 227 assigned to its DHCP clients. 229 The access concentrator gleans IP address or other information for 230 antispoofing and for other purposes from DHCP negotiations. The 231 antispoofing itself is done in fast path. Access concentrator keeps 232 track of only one list of IP addresses: list of IP addresses that are 233 assigned by DHCP server. Traffic for all other IP addresses is 234 dropped. If client starts its data transfer after its DHCP 235 negotiations are gleaned by access concentrator, no legitimate 236 packets will be dropped because of antispoofing. In other words, 237 antispoofing is effective (no legitimate packets are dropped and all 238 spoofed packets are dropped) and efficient (antispoofing is done in 239 fast path). The intention is to achieve similar effective and 240 efficient antispoofing in the lease query scenario also when an 241 access concentrator loses its gleaned information (for example, 242 because of reboot). 244 After a deep analysis, we found that the three existing query types 245 supported by RFC 4388[2] do not provide effective and efficient 246 antispoofing for the above scenario and a new mechanism is required. 248 The existing query types 250 o necessitate a data driven approach: the lease queries can only be 251 done when access concentrator receives data. That results in 252 increased outage time for clients. 254 o result in excessive negative caching consuming lot of resources 255 under a spoofing attack. 257 o result in antispoofing being done in slow path instead of fast 258 path. 260 The deeper analysis, which led to the above conclusions, itself 261 appears as an Appendix to this document. 263 4. Design Goals 265 The goal of this document is to provide a lightweight mechanism for 266 access concentrator to retrieve lease information available in the 267 DHCP server. The mechanism SHOULD also support an access 268 concentrator to retrieve consolidated lease information for a 269 connection/circuit. 271 4.1. Information Acquisition before Data Starts 273 Existing data driven approach by RFC 4388 [2] means that the lease 274 queries can only be done when access concentrator receives data. If 275 an approach exists to initiate lease queries even before the calls 276 come up, then it will be more effective. For antispoofing, packets 277 need to be dropped until it gets the lease information from DHCP 278 server. If access concentrator finishes the lease queries before it 279 start receiving data, then there is no need to drop legitimate 280 packets. So, effectively outage time may be reduced. The lease 281 queries should help in retrieving lease information even before the 282 data starts flowing and should be independent of data traffic. 284 4.2. Lessen Negative Caching 286 If lease queries result in negative caches, then that puts additional 287 overhead on access concentrator. The negative caches not only 288 consume precious resources they also need to be managed. Hence they 289 should be avoided as much as possible. The lease queries should 290 reduce the need for negative caching as far as possible. 292 4.3. Antispoofing in 'Fast Path' 294 If Antispoofing is not done in fast path, it will become a bottleneck 295 and may lead to denial of service of access concentrator. The lease 296 queries should make it possible to do antispoofing in fast path. 298 5. Protocol Overview 300 RFC 3046 [4] defines two sub-options for Relay Agent Information 301 option. Sub-option 1 corresponds to circuit ID which identifies the 302 local circuit of the access concentrator. This sub-option is unique 303 to the relay agent. Sub-option 2 corresponds to remote ID which 304 identifies the remote host end of the circuit. This is globally 305 unique in the network. 307 This document defines a new query type based on remote ID sub-option. 308 Suppose that the access concentrator (e.g., DSLAM) lost the lease 309 information when it was rebooted. When the access concentrator comes 310 up, it would initiate a DHCPLEASEQUERY message for each connection/ 311 circuit containing the Relay Agent Information option [4] with sub- 312 option remote ID. DHCP server must return an IP address in the 313 ciaddr if it has any record of the client described by the remote ID. 314 In the absence of specific configuration information to the contrary, 315 it SHOULD be the IP address with the latest client-last-transaction- 316 time associated with the client described by the remote ID. The DHCP 317 servers that implement this document always send a response 318 (DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN) to the 319 DHCPLEASEQUERY message. The reasons why a DHCPLEASEUNASSIGNED, 320 DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message might be generated are 321 explained in the specific query regimes below. Servers that do not 322 implement the DHCPLEASEQUERY based on remote ID message SHOULD simply 323 not respond. 325 The query regime is described below: 327 o Query by Agent Remote ID sub-option: 329 For this query, the requester supplies only a option 82 which will 330 include only an Agent Remote ID sub-option in the DHCPLEASEQUERY 331 message. The DHCP server will return any information that it has on 332 the IP address most recently accessed by a client with that Agent 333 Remote ID. In addition, it may supply additional IP addresses that 334 have been associated with Agent Remote ID in different subnets. 335 Information about these bindings can then be found using the Query by 336 IP Address, as described in RFC 4388[2]. 338 The DHCP server replies with a DHCPLEASEACTIVE message if the Agent 339 Remote ID in the DHCPLEASEQUERY message currently has an active lease 340 on an IP address in this DHCP server. Server replies with a 341 DHCPLEASEUNASSIGNED if it has information of the said remote ID but 342 no lease is assigned for the same. Server replies with a 343 DHCPLEASEUNKNOWN message if it has no information of the said remote 344 ID. 346 6. Protocol Details 348 In this section, DHCPLEASEQUERY message refers to DHCPLEASEQUERY 349 message with query by remote ID. 351 6.1. Sending the DHCPLEASEQUERY Message 353 The DHCPLEASEQUERY message is typically sent by an access 354 concentrator. The DHCPLEASEQUERY message uses the DHCP message 355 format as described in RFC2131[3], and uses message number 10 in the 356 DHCP Message Type option (option 53). The DHCPLEASEQUERY message has 357 the following pertinent message contents: 359 o The giaddr MUST be set to the IP address of the requester (i.e., 360 the access concentrator). The giaddr is the return address of the 361 DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message 362 from the DHCP server. Note that this use of the giaddr is 363 consistent with the definition of giaddr in RFC2131[3], where the 364 giaddr is always used as the return address of the DHCP response 365 message. In some (but not all) contexts in RFC 2131, the giaddr 366 is used as the "key" to access the appropriate address pool. 368 o The Parameter Request List option (option 55) SHOULD be set to the 369 options of interest to the requester. It MUST include the Relay 370 Agent Information option (option 82). The other interesting 371 options are likely to include the IP Address Lease Time option 372 (option 51), and possibly the Vendor class identifier option 373 (option 60). In the absence of a Parameter Request List option, 374 the server SHOULD return the same options it would return for a 375 DHCPREQUEST message that didn't contain a DHCPLEASEQUERY message, 376 which includes those mandated by Section 4.3.1 of [RFC2131] as 377 well as any options that the server was configured to always 378 return to a client. 380 Additional details concerning different query types are 382 o Query by Agent Remote ID sub-option: 384 * There MUST be a Relay Agent Information option (option 82) with 385 only Agent Remote ID sub-option (sub-option 2) in the 386 DHCPLEASEQUERY message. 388 * The "ciaddr" field MUST be set to zero. 390 * The values of htype, hlen, and chaddr MUST be set to zero. 392 * The Client-identifier option (option 61) MUST NOT appear in the 393 packet. 395 The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is 396 known to possess authoritative information concerning the remote ID. 397 The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, 398 and in the absence of information concerning which DHCP server might 399 possess authoritative information concerning the remote ID, it SHOULD 400 be sent to all DHCP servers configured for the associated relay agent 401 (if any are known). 403 6.2. Receiving the DHCPLEASEQUERY Message 405 A DHCPLEASEQUERY message MUST have a non-zero giaddr. The 406 DHCPLEASEQUERY message MUST have a zero ciaddr, a zero htype/hlen/ 407 chaddr, and no Client-identifier option. The DHCPLEASEQUERY message 408 MUST have a relay agent option 82 with only remote ID sub-option. 410 6.3. Responding to the DHCPLEASEQUERY Message 412 There are three possible responses to a DHCPLEASEQUERY message: 414 o DHCPLEASEUNASSIGNED 416 The server MUST respond with a DHCPLEASEUNASSIGNED message if this 417 server has information about the remote ID, but there is no 418 associated active lease. The DHCPLEASEUNASSIGNED indicates that the 419 server manages the IP address allocation for the given remote ID, but 420 there is no currently active lease. 422 o DHCPLEASEUNKNOWN 424 The DHCPLEASEUNKNOWN message indicates that the client specified in 425 the DHCPLEASEQUERY message is not managed by the server. 427 o DHCPLEASEACTIVE 429 The DHCPLEASEACTIVE message indicates that the server not only know 430 the client specified in the DHCPLEASEQUERY message, but also knows 431 that there is an active lease for that client. 433 6.4. Determining the IP address to be used in response 435 Since the response to a DHCPLEASEQUERY request can only contain full 436 information about one IP address -- the one that appears in the 437 "ciaddr" field -- determination of which IP address about which to 438 respond is a key issue. Of course, the values of additional IP 439 addresses for which a client has a lease must also be returned in the 440 associated-ip option (RFC 4388[2], Section 6.1, #3). This is the 441 only information returned not directly associated with the IP address 442 in the "ciaddr" field. 444 The client's identity is any client that has proffered an identical 445 Agent Remote ID (if the option 82 with Agent Remote ID sub-option 446 appears in DHCPLEASEQUERY message). This client matching approach 447 will, for the purposes of this section, be described as "remote ID". 449 The IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE 450 message MUST be the IP address with the latest client-last- 451 transaction-time associated with the client described by the remote 452 ID specified in the DHCPLEASEQUERY message. 454 If there is only a single IP address that fulfills this criteria, 455 then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE 456 message. 458 In the case where more than one IP address has been accessed by the 459 client specified by the Remote ID, then the DHCP server MUST return 460 the IP address returned to the client in the most recent transaction 461 with the client unless the DHCP server has been configured by the 462 server administrator to use some other preference mechanism. 464 6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or 465 DHCPLEASEACTIVE Messages 467 DHCPLEASEUNASSIGNED and DHCPLEASEUNKNOWN messages are created alike 468 except for message type. DHCP server MUST echo the received Option 469 82 available in DHCPLEASEQUERY in the response. No other options are 470 returned for these messages. With that the processing for a 471 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN message is complete. 473 For the DHCPLEASEACTIVE message, the rest of the processing largely 474 involves returning information about the IP address specified in the 475 "ciaddr" field. 477 The MAC address of the DHCPLEASEACTIVE message MUST be set to the 478 values that identify the client associated with the IP address in the 479 "ciaddr" field of the DHCPLEASEACTIVE message. 481 If the Client-identifier option (option 61) is specified in the 482 Parameter Request List option (option 55), then the Client-identifier 483 (if any) of the client associated with the IP address in the "ciaddr" 484 field SHOULD be returned in the DHCPLEASEACTIVE message. 486 In the case where more than one IP address has been involved in a 487 DHCP message exchange with the client specified by the Agent Remote 488 ID, then the list of all those IP addresses MUST be returned in the 489 associated-ip option, whether or not that option was requested as 490 part of the Parameter Request List option. 492 If the IP Address Lease Time option (option 51) is specified in the 493 Parameter Request List then the DHCP server MUST return this option 494 in the DHCPLEASEACTIVE message with its value equal to the time 495 remaining until lease expiration. 497 A request for the Renewal (T1) Time Value option or the Rebinding 498 (T2) Time Value option in the Parameter Request List of the 499 DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time 500 option is handled. DHCP server SHOULD return these options (when 501 requested) with the remaining time until renewal or rebinding, 502 respectively. 504 The information contained in the most recent Relay Agent Information 505 option received from the relay agent associated with this IP address 506 MUST be included in the DHCPLEASEACTIVE message. 508 The DHCPLEASEACTIVE message SHOULD include the values of all other 509 options not specifically discussed above that were requested in the 510 Parameter Request List of the DHCPLEASEQUERY message and that are 511 acceptable to return based on the list of "non-sensitive options", 512 discussed below. 514 DHCP servers SHOULD be configurable with a list of "non-sensitive 515 options" that can be returned to the access concentrator when 516 specified in the Parameter Request List of the DHCPLEASEQUERY 517 message. Any option not on this list SHOULD NOT be returned to an 518 access concentrator, even if requested by that access concentrator. 520 The DHCP server uses information from its lease binding database to 521 supply the DHCPLEASEACTIVE option values. The values of the options 522 that were returned to the DHCP client would generally be preferred, 523 but in the absence of those, options that were sent in DHCP client 524 requests would be acceptable. 526 In some cases, the Relay Agent Information option in an incoming 527 DHCPREQUEST packet is used to help determine the options returned to 528 the DHCP client that sent the DHCPREQUEST. When responding to a 529 DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay 530 Agent Information option just like it did when responding to the DHCP 531 client in order to determine the values of any options requested by 532 the DHCPLEASEQUERY message. The goal is to return the same option 533 values to the DHCPLEASEQUERY as those that were returned to the 534 DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise 535 specified, above). 537 In the event that two servers are cooperating to provide a high- 538 availability DHCP server, as supported by [RFC2131], they would have 539 to communicate some information about IP address bindings to each 540 other. In order to properly support the DHCPLEASEQUERY message, 541 these servers MUST ensure that they communicate the Relay Agent 542 Information option information to each other in addition to any other 543 IP address binding information. 545 6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 546 DHCPLEASEUNKNOWN Message 548 The server expects a giaddr in the DHCPLEASEQUERY message, and 549 unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 550 DHCPLEASEUNKNOWN message to the giaddr. 552 6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 553 DHCPLEASEUNKNOWN Message 555 When a DHCPLEASEACTIVE message is received in response to the 556 DHCPLEASEQUERY message, it means that there is a currently active 557 lease for this IP address in this DHCP server. The access 558 concentrator SHOULD use the information in the "htype", "hlen", and 559 "chaddr" fields of the DHCPLEASEACTIVE as well as Relay Agent 560 Information option information included in the packet to refresh its 561 location information for this IP address. An access concentrator is 562 likely to query by IP address for all the IP addresses specified in 563 the associated-ip option in the response, if any, at this point in 564 time. 566 When a DHCPLEASEUNASSIGNED message is received in response to the 567 DHCPLEASEQUERY message, it means that there is no currently active 568 lease associated with the client specified by remote ID in the DHCP 569 server, but that this server does in fact manage the IP address 570 allocation for the client specified by remote ID. In this case, the 571 access concentrator SHOULD cache this information for later use. 573 When a DHCPLEASEUNKNOWN message is received by an access concentrator 574 that has sent out a DHCPLEASEQUERY message, it means that the DHCP 575 server does not have definitive information concerning the DHCP 576 client specified in the Agent Remote ID sub-option of the 577 DHCPLEASEQUERY message. The access concentrator SHOULD cache this 578 information, but only for a relatively short lifetime, approximately 579 5 minutes. Having cached this information, the access concentrator 580 SHOULD only infrequently direct a DHCPLEASEQUERY message to a DHCP 581 server that responded to a DHCPLEASEQUERY message with a 582 DHCPLEASEUNKNOWN. 584 6.8. Receiving No Response to the DHCPLEASEQUERY Message 586 When an access concentrator receives no response to a DHCPLEASEQUERY 587 message, it should be handled in the same manner as suggested in RFC 588 4388 [2]. 590 6.9. Lease Binding Data Storage Requirements 592 The lease binding data storage requirements are same as those 593 specified in RFC 4388 [2]. 595 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers 597 This scenario should be handled in the same way it is done in RFC 598 4388 [2]. 600 7. RFC 4388 Considerations 602 This document is compatible with RFC 4388 [2] based implementations 603 which means that a client which supports this extension can work with 604 a server not supporting this document provided it uses RFC 4388 [2] 605 defined query types. Also, a server supporting this document can 606 work with a client not supporting this query type. However, there 607 are some changes that this document proposes with respect to RFC 4388 608 [2]. Implementors extending RFC 4388 [2] implementation to support 609 this document, should take note of the following points: 611 o RFC 4388 [2] suggests that a DHCPLEASEUNASSIGNED is returned only 612 in the case of 'query by IP address'. All other query types will 613 have a return message of either DHCPLEASEACTIVE or 614 DHCPLEASEUNKNOWN'. This document proposes that 615 DHCPLEASEUNASSIGNED can be returned for the query by remote ID. 617 o There may be cases where a query by IP address/MAC address/Client 618 Identifier has an option 82 containing remote ID. In that case, 619 the query will still be recognized as query by IP address/MAC 620 address/Client Identifier as specified by RFC 4388 [2]. 622 o Section 6.4 of RFC 4388 [2] suggests that a DHCPLEASEUNKNOWN MUST 623 NOT have any other option present. But for a query by remote ID, 624 option 82 MUST be present in the reply. 626 8. Security Considerations 628 This document does not introduce any new security concerns beyond 629 those specified in the original leasequery protocol RFC 4388 [2] 630 specifications. 632 9. IANA Considerations 634 This document does not introduce any new namespaces for the IANA to 635 manage. 637 10. Acknowledgments 639 Copious amounts of text in this document are derived from RFC 4388 640 [2]. 642 11. References 644 11.1. Normative Reference 646 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 647 Levels", BCP 14, RFC 2119, March 1997. 649 [2] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol 650 (DHCP) Leasequery", RFC 4388, February 2006. 652 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 653 March 1997. 655 [4] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 656 January 2001. 658 11.2. Informative Reference 660 [5] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 661 September 1985. 663 [6] Wimer, W., "Clarifications and Extensions for the Bootstrap 664 Protocol", RFC 1542, October 1993. 666 [7] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 667 Extensions", RFC 2132, March 1997. 669 1. Why a New Leasequery is Required? 671 The three existing query types supported by RFC 4388 do not provide 672 effective and efficient antispoofing for the above scenario. 674 o Query by Client Identifier 676 Query by Client Identifier is not possible because to use that access 677 concentrator need to glean client identifier also but the whole issue 678 is that we need leasequeries because the gleaned information was 679 lost. On the other hand, we can query by client identifier when 680 client sends a DHCP request, but then there may not be any need for 681 lease query as such -- regular gleaning may be enough. 683 o Query by IP Address 685 RFC 4388 suggests that it is preferable to use Query by IP Address 686 when getting downstream traffic. 688 Query by IP address is not very useful in downstream traffic because 689 downstream traffic may not exist for the clients on a access port. 690 (In most Internet applications, downstream traffic exists only when a 691 client sends upstream traffic). In other words, the client will be 692 denied service until it gets downstream traffic, which may never 693 come. 695 Query by IP address may be used for upstream traffic. Then whenever 696 an upstream packet comes whose IP address is unknown to the access 697 concentrator, a lease query may be initiated. A related question is 698 what to do with that upstream traffic itself until lease query 699 response comes? If the traffic is dropped, we may be dropping 700 legitimate traffic. If the traffic is forwarded, we may be 701 forwarding spoofed packets. Once the lease response comes, 702 subsequent traffic is handled depending on the response. If a 703 DHCPLEASEACTIVE response comes, access concentrator will accept the 704 traffic. If a DHCPLEASEUNASSIGNED response comes, access 705 concentrator will drop the traffic corresponding to the IP address. 706 If a DHCPLEASEUNKNOWN response comes, access concentrator may drop 707 the traffic corresponding to the IP address but will have to 708 periodically send the lease query for that IP address again 709 (additional overhead). The process is triggered whenever an unknown 710 IP address comes. 712 Note that access concentrator needs to keep track of 4 lists of IP 713 addresses: (1) List of IP addresses for which it got DHCPLEASEACTIVE 714 responses; (2) List of IP addresses for which it got 715 DHCPLEASEUNASSIGNED responses; (3) List of IP addresses for which it 716 got DHCPLEASEUNKNOWN responses; (4) All other IP addresses. 718 This approach may be acceptable if only legitimate traffic is 719 received. Consider the case when someone sends packets that uses 720 spoofed IP addresses. In that case, lease response will be 721 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. RFC 4388 suggests usage of 722 negative caching in this regard (which involves additional 723 resources). 725 In a spoofing type of attack, negative caching information may grow 726 considerably if attacker varies the source IP address. For each such 727 new source IP address, traffic will come to slow path, a new lease 728 query needs to be initiated, response will be processed, and negative 729 caching to be done. That will mean using many resources for negative 730 caching. 732 RFC 4388 suggests that if the access concentrator knows the network 733 portion of the IP addresses that are assigned to its clients, then 734 some amount of antispoofing can be done in fast path and some lease 735 queries may be avoided. But as indicated before, that information 736 may not always be available to access concentrators. 738 Effectively, antispoofing support involves considerable slow path 739 processing and considerable resources tied for negative caching. 741 RFC 4388 says that DHCP server should be protected from being flooded 742 with too many leasequery requests and access concentrator also should 743 not send too many lease query messages at a time. This would mean 744 that legitimate clients may be excessively delayed getting their 745 information in the face of antispoofing attacks. 747 It is concluded that antispoofing is neither effective nor efficient 748 with this query type. 750 o Query by MAC Address 752 Query by MAC address can also be used similar to query by IP address 753 described above. Indeed, query by MAC address may be better than 754 query by IP address in one sense because of the possible presence of 755 associated-ip option in lease responses (Note that associated-ip 756 option does not appear in responses for query by IP address). With 757 associated-ip option, access concentrator can get information not 758 only about the IP address/MAC address that triggered the lease query 759 but also about other IP addresses that are associated with the 760 original MAC address. That way, when traffic that uses the other IP 761 addresses comes along, access concentrator is already prepared to 762 deal with them. 764 Although, query by MAC address is better than query by IP address in 765 the above respect, it has a specific problem which is not shared by 766 query by IP address. For a query by MAC address, only two types of 767 responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE; 768 DHCPLEASEUNASSIGNED is not supported. This is particularly 769 troublesome when a DHCP server indeed has definitive information that 770 no IP addresses are associated with the specified MAC address in the 771 leasequery, but it is forced to respond with DHCPLEASEUNKNOWN instead 772 of DHCPLEASEUNASSIGNED. As we have seen above, unlike 773 DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying with 774 DHCP server, an additional overhead. 776 Moreover, query by MAC address also shares all other issues we 777 discussed above for query by IP address. 779 We conclude that existing lease query types are not appropriate to 780 achieve effective and efficient antispoofing. 782 Authors' Addresses 784 Pavan Kurapati 785 Infosys Technologies Ltd. 786 44 Electronics City, Hosur Road 787 Bangalore 560 100 788 India 790 Email: pavan_kurapati@infosys.com 791 URI: http://www.infosys.com/ 793 D.T.V Ramakrishna Rao 794 Infosys Technologies Ltd. 795 44 Electronics City, Hosur Road 796 Bangalore 560 100 797 India 799 Email: ramakrishnadtv@infosys.com 800 URI: http://www.infosys.com/ 802 Bharat Joshi 803 Infosys Technologies Ltd. 804 44 Electronics City, Hosur Road 805 Bangalore 560 100 806 India 808 Email: bharat_joshi@infosys.com 809 URI: http://www.infosys.com/ 811 Intellectual Property Statement 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the procedures with respect to rights in RFC documents can be 820 found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at 833 ietf-ipr@ietf.org. 835 Disclaimer of Validity 837 This document and the information contained herein are provided on an 838 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 839 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 840 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 841 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 842 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 843 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 845 Copyright Statement 847 Copyright (C) The IETF Trust (2008). This document is subject to the 848 rights, licenses and restrictions contained in BCP 78, and except as 849 set forth therein, the authors retain all their rights. 851 Acknowledgment 853 Funding for the RFC Editor function is currently provided by the 854 Internet Society.