idnits 2.17.1 draft-ietf-dhc-leasequery-by-remote-id-02.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 13, 2009) is 5398 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 682, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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: January 14, 2010 B. Joshi 5 Infosys Technologies Ltd. 6 July 13, 2009 8 DHCPv4 Leasequery by relay agent remote ID 9 draft-ietf-dhc-leasequery-by-remote-id-02.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 January 14, 2010. 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Some Relay Agents extract lease information from the DHCP message 48 exchanged between the client and DHCP server. This lease information 49 is used by relay agents for various purposes like antispoofing, 50 prevention of flooding. RFC 4388 defines a mechanism for relay 51 agents to retrieve the lease information from the DHCP server as and 52 when this information is lost. Existing leasequery mechanism is data 53 driven which means that a relay agent can initiate the leasequery 54 only when it starts receiving data from/to the clients. In certain 55 scenarios, this model is not scalable. This document first looks at 56 issues in existing mechanism and then proposes a new query type, 57 query by remote ID, to address these issues. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Information Acquisition before Data Starts . . . . . . . . 10 66 4.2. Lessen Negative Caching . . . . . . . . . . . . . . . . . 10 67 4.3. Antispoofing in 'Fast Path' . . . . . . . . . . . . . . . 10 68 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13 70 6.1. Sending the DHCPLEASEQUERY Message . . . . . . . . . . . . 13 71 6.2. Receiving the DHCPLEASEQUERY Message . . . . . . . . . . . 14 72 6.3. Responding to the DHCPLEASEQUERY Message . . . . . . . . . 14 73 6.4. Determining the IP address to be used in response . . . . 14 74 6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or 75 DHCPLEASEACTIVE Messages . . . . . . . . . . . . . . . . . 15 76 6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 77 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 17 78 6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 79 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 17 80 6.8. Receiving No Response to the DHCPLEASEQUERY Message . . . 18 81 6.9. Lease Binding Data Storage Requirements . . . . . . . . . 18 82 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP 83 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7. RFC 4388 Considerations . . . . . . . . . . . . . . . . . . . 19 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23 90 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 23 91 Appendix A. Why a New Leasequery is Required? . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 DHCP relay agents snoop DHCP messages and append relay agent 97 information option before relaying it to the configured DHCP Servers. 98 In this process, some relay agents also glean the lease information 99 sent by the server and maintain this locally. This information is 100 used for prevention of spoofing attempts from the clients and also 101 sometimes used to install routing information. When relay agent 102 reboots, this information is lost. RFC 4388 [RFC4388] has defined a 103 mechanism to retrieve this lease information from the DHCP server. 104 The existing query types defined by RFC 4388 [RFC4388] are data 105 driven. When client initiates data, based on the source MAC/IP 106 address, relay agent can query the server about the lease 107 information. These mechanisms do not scale well when there are 108 thousands of clients connected to the relay agent. In data driven 109 model, DHCP Leasequery does not provide all the active Lease 110 informations associated with a given connection/circuit [consolidated 111 information] which will result into an inefficient anti-spoofing. It 112 also has to contend with considerable resources for negative caching 113 specially under spoof attacks. 115 We need a mechanism for relay agent to retrieve the consolidated 116 lease information for a given connection/circuit before traffic is 117 initiated by the clients. 119 +--------+ 120 | DHCP | +--------------+ 121 | Server |-...-| DSLAM | 122 | | | Relay Agent | 123 +--------+ +--------------+ 124 | | 125 +------+ +------+ 126 |Modem1| |Modem2| 127 +------+ +------+ 128 | | | 129 +-----+ +-----+ +-----+ 130 |Host1| |Host2| |Host3| 131 +-----+ +-----+ +-----+ 133 Figure 1 135 For example, when a DSLAM acting as a Relay Agent is rebooted, it 136 should query the server for the lease information for all the 137 connections/circuits. Also, as shown in the above figure, there 138 could be multiple clients on one DSL circuit. Relay agent should get 139 the lease information of all the clients connected to a DSL circuit. 140 This is possible by introducing a new query type based on the Remote 141 Id sub-option of Relay Agent Information option. This document talks 142 about the motivation for the new query type and the method to do the 143 same. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 This document uses the following terms: 153 o "access concentrator" 155 An access concentrator is a router or switch at the broadband access 156 provider's edge of a public broadband access network. This document 157 assumes that the access concentrator includes the DHCP relay agent 158 functionality. 160 o "DHCP client" 162 A DHCP client is an Internet host using DHCP to obtain configuration 163 parameters such as a network address. 165 o "DHCP relay agent" 167 A DHCP relay agent is a third-party agent that transfers Bootstrap 168 Protocol (BOOTP) and DHCP messages between clients and servers 169 residing on different subnets, per RFC951[RFC951] and 170 RFC1542[RFC1542]. 172 o "DHCP server" 174 A DHCP server is an Internet host that returns configuration 175 parameters to DHCP clients. 177 o "downstream" 179 Downstream is the direction from the access concentrator towards the 180 broadband subscriber. 182 o "fast path" 184 Data transfer which happens through Network Processor or an ASIC 185 which are programmed to forward the data at very high speeds. 187 o "gleaning" 189 Gleaning is the extraction of location information from DHCP 190 messages, as the messages are forwarded by the DHCP relay agent 191 function. 193 o "location information" 195 Location information is information needed by the access concentrator 196 to forward traffic to a broadband-accessible host. This information 197 includes knowledge of the host hardware address, the port or virtual 198 circuit that leads to the host, and/or the hardware address of the 199 intervening subscriber modem. 201 o "MAC address" 203 In the context of a DHCP packet, a MAC address consists of the 204 following fields: hardware type "htype", hardware length "hlen", and 205 client hardware address "chaddr". 207 o "slow path" 209 Data transfer which happens through the control plane. Typically 210 this has very limited buffers to store data and the speeds are very 211 low compared to fast path data transfer. 213 o "upstream" 215 Upstream is the direction from the broadband subscriber towards the 216 access concentrator. 218 3. Motivation 220 Consider a typical access concentrator (e.g., DSLAM) working also as 221 a DHCP relay agent. "Fast path" and "slow path" generally exist in 222 most networking boxes. Fast path processing is done in network 223 processor or an ASIC (Application Specific Integrated Circuit). Slow 224 path processing is done in a normal processor. As much as possible, 225 regular data handling code should be in fast path. Slow path 226 processing should be reduced as it may become a bottleneck. 228 For an access concentrator having multiple access ports, multiple IP 229 addresses may be assigned using DHCP to a single port and the number 230 of clients on a port may be unknown. The access concentrator may 231 also not know the network portions of the IP addresses that are 232 assigned to its DHCP clients. 234 The access concentrator gleans IP address or other information for 235 antispoofing and for other purposes from DHCP negotiations. The 236 antispoofing itself is done in fast path. Access concentrator keeps 237 track of only one list of IP addresses: list of IP addresses that are 238 assigned by DHCP server. Traffic for all other IP addresses is 239 dropped. If client starts its data transfer after its DHCP 240 negotiations are gleaned by access concentrator, no legitimate 241 packets will be dropped because of antispoofing. In other words, 242 antispoofing is effective (no legitimate packets are dropped and all 243 spoofed packets are dropped) and efficient (antispoofing is done in 244 fast path). The intention is to achieve similar effective and 245 efficient antispoofing in the lease query scenario also when an 246 access concentrator loses its gleaned information (for example, 247 because of reboot). 249 After a deep analysis, we found that the three existing query types 250 supported by RFC 4388[RFC4388] do not provide effective and efficient 251 antispoofing for the above scenario and a new mechanism is required. 253 The existing query types 255 o necessitate a data driven approach: the lease queries can only be 256 done when access concentrator receives data. That results in 257 increased outage time for clients. 259 o result in excessive negative caching consuming lot of resources 260 under a spoofing attack. 262 o result in antispoofing being done in slow path instead of fast 263 path. 265 The deeper analysis, which led to the above conclusions, itself 266 appears as an Appendix to this document. 268 4. Design Goals 270 The goal of this document is to provide a lightweight mechanism for 271 access concentrator to retrieve lease information available in the 272 DHCP server. The mechanism SHOULD also support an access 273 concentrator to retrieve consolidated lease information for a 274 connection/circuit. 276 4.1. Information Acquisition before Data Starts 278 Existing data driven approach by RFC 4388 [RFC4388] means that the 279 lease queries can only be done when access concentrator receives 280 data. If an approach exists to initiate lease queries even before 281 the calls come up, then it will be more effective. For antispoofing, 282 packets need to be dropped until it gets the lease information from 283 DHCP server. If access concentrator finishes the lease queries 284 before it start receiving data, then there is no need to drop 285 legitimate packets. So, effectively outage time may be reduced. The 286 lease queries should help in retrieving lease information even before 287 the data starts flowing and should be independent of data traffic. 289 4.2. Lessen Negative Caching 291 If lease queries result in negative caches, then that puts additional 292 overhead on access concentrator. The negative caches not only 293 consume precious resources they also need to be managed. Hence they 294 should be avoided as much as possible. The lease queries should 295 reduce the need for negative caching as far as possible. 297 4.3. Antispoofing in 'Fast Path' 299 If Antispoofing is not done in fast path, it will become a bottleneck 300 and may lead to denial of service of access concentrator. The lease 301 queries should make it possible to do antispoofing in fast path. 303 5. Protocol Overview 305 RFC 3046 [RFC3046] defines two sub-options for Relay Agent 306 Information option. Sub-option 1 corresponds to circuit ID which 307 identifies the local circuit of the access concentrator. This sub- 308 option is unique to the relay agent. Sub-option 2 corresponds to 309 remote ID which identifies the remote host end of the circuit. This 310 is globally unique in the network. 312 This document defines a new query type based on remote ID sub-option. 313 Suppose that the access concentrator (e.g., DSLAM) lost the lease 314 information when it was rebooted. When the access concentrator comes 315 up, it would initiate a DHCPLEASEQUERY message for each connection/ 316 circuit containing the Relay Agent Information option [RFC3046] with 317 sub-option remote ID. DHCP server must return an IP address in the 318 ciaddr if it has any record of the client described by the remote ID. 319 In the absence of specific configuration information to the contrary, 320 it SHOULD be the IP address with the latest client-last-transaction- 321 time associated with the client described by the remote ID. The DHCP 322 servers that implement this document always send a response 323 (DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN) to the 324 DHCPLEASEQUERY message. The reasons why a DHCPLEASEUNASSIGNED, 325 DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message might be generated are 326 explained in the specific query regimes below. Servers that do not 327 implement the DHCPLEASEQUERY based on remote ID message SHOULD simply 328 not respond. 330 The query regime is described below: 332 o Query by Agent Remote ID sub-option: 334 For this query, the requester supplies only a option 82 which will 335 include only an Agent Remote ID sub-option in the DHCPLEASEQUERY 336 message. The DHCP server will return any information that it has on 337 the IP address most recently accessed by a client with that Agent 338 Remote ID. In addition, it SHOULD supply any additional IP addresses 339 that have been associated with Agent Remote ID in different subnets. 340 Information about these bindings can then be found using the Query by 341 IP Address, as described in RFC 4388[RFC4388]. 343 The DHCP server MUST reply with a DHCPLEASEACTIVE message if the 344 Agent Remote ID in the DHCPLEASEQUERY message currently has an active 345 lease on an IP address in this DHCP server. The server MUST reply 346 with a DHCPLEASEUNASSIGNED if it has information of the said remote 347 ID but no lease is assigned for the same. The server MAY keep track 348 of the remote ID values for which it has currently active leases as 349 well as any which it has served in the past but for which it has no 350 currently active leases. The server MUST reply with a 351 DHCPLEASEUNKNOWN message if it has no information of the said remote 352 ID. 354 6. Protocol Details 356 In this section, DHCPLEASEQUERY message refers to DHCPLEASEQUERY 357 message with query by remote ID. 359 6.1. Sending the DHCPLEASEQUERY Message 361 The DHCPLEASEQUERY message is typically sent by an access 362 concentrator. The DHCPLEASEQUERY message uses the DHCP message 363 format as described in RFC2131[RFC2131], and uses message number 10 364 in the DHCP Message Type option (option 53). The DHCPLEASEQUERY 365 message has the following pertinent message contents: 367 o The giaddr MUST be set to the IP address of the requester (i.e., 368 the access concentrator). The giaddr is the return address of the 369 DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message 370 from the DHCP server. Note that this use of the giaddr is 371 consistent with the definition of giaddr in RFC2131[RFC2131], 372 where the giaddr is always used as the return address of the DHCP 373 response message. In some (but not all) contexts in RFC 2131, the 374 giaddr is used as the "key" to access the appropriate address 375 pool. 377 o The Parameter Request List option (option 55) SHOULD be set to the 378 options of interest to the requester. It MUST include the Relay 379 Agent Information option (option 82). The other interesting 380 options are likely to include the IP Address Lease Time option 381 (option 51), and possibly the Vendor class identifier option 382 (option 60). In the absence of a Parameter Request List option, 383 the server SHOULD return the same options it would return for a 384 DHCPREQUEST message that didn't contain a DHCPLEASEQUERY message, 385 which includes those mandated by Section 4.3.1 of [RFC2131] as 386 well as any options that the server was configured to always 387 return to a client. 389 Additional details concerning different query types are 391 o Query by Agent Remote ID sub-option: 393 * There MUST be a Relay Agent Information option (option 82) with 394 only Agent Remote ID sub-option (sub-option 2) in the 395 DHCPLEASEQUERY message. 397 * The "ciaddr" field MUST be set to zero. 399 * The values of htype, hlen, and chaddr MUST be set to zero. 401 * The Client-identifier option (option 61) MUST NOT appear in the 402 packet. 404 The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is 405 known to possess authoritative information concerning the remote ID. 406 The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, 407 and in the absence of information concerning which DHCP server might 408 possess authoritative information concerning the remote ID, it SHOULD 409 be sent to all DHCP servers configured for the associated relay agent 410 (if any are known). 412 6.2. Receiving the DHCPLEASEQUERY Message 414 A DHCPLEASEQUERY message MUST have a non-zero giaddr. The 415 DHCPLEASEQUERY message MUST have a zero ciaddr, a zero htype/hlen/ 416 chaddr, and no Client-identifier option. The DHCPLEASEQUERY message 417 MUST have a relay agent option 82 with only remote ID sub-option. 419 6.3. Responding to the DHCPLEASEQUERY Message 421 There are three possible responses to a DHCPLEASEQUERY message: 423 o DHCPLEASEUNASSIGNED 425 The server MUST respond with a DHCPLEASEUNASSIGNED message if this 426 server has information about the remote ID, but there is no 427 associated active lease. The DHCPLEASEUNASSIGNED indicates that the 428 server manages the IP address allocation for the given remote ID, but 429 there is no currently active lease. 431 o DHCPLEASEUNKNOWN 433 The DHCPLEASEUNKNOWN message indicates that the client specified in 434 the DHCPLEASEQUERY message is not managed by the server. 436 o DHCPLEASEACTIVE 438 The DHCPLEASEACTIVE message indicates that the server not only knows 439 the client specified in the DHCPLEASEQUERY message, but also knows 440 that there is an active lease for that client. 442 6.4. Determining the IP address to be used in response 444 Since the response to a DHCPLEASEQUERY request can only contain full 445 information about one IP address -- the one that appears in the 446 "ciaddr" field -- determination of which IP address about which to 447 respond is a key issue. Of course, the values of additional IP 448 addresses for which a client has a lease must also be returned in the 449 associated-ip option (RFC 4388[RFC4388], Section 6.1, #3). This is 450 the only information returned not directly associated with the IP 451 address in the "ciaddr" field. 453 The client's identity is any client that has proffered an identical 454 Agent Remote ID (if the option 82 with Agent Remote ID sub-option 455 appears in DHCPLEASEQUERY message). This client matching approach 456 will, for the purposes of this section, be described as "remote ID". 458 The IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE 459 message MUST be the IP address with the latest client-last- 460 transaction-time associated with the client described by the remote 461 ID specified in the DHCPLEASEQUERY message. 463 If there is only a single IP address that fulfills this criteria, 464 then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE 465 message. 467 In the case where more than one IP address has been accessed by the 468 client specified by the Remote ID, then the DHCP server MUST return 469 the IP address returned to the client in the most recent transaction 470 with the client unless the DHCP server has been configured by the 471 server administrator to use some other preference mechanism. 473 6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or 474 DHCPLEASEACTIVE Messages 476 DHCPLEASEUNASSIGNED and DHCPLEASEUNKNOWN messages are created alike 477 except for message type. DHCP server MUST echo the received Option 478 82 available in DHCPLEASEQUERY in the response. No other options are 479 returned for these messages. With that the processing for a 480 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN message is complete. 482 For the DHCPLEASEACTIVE message, the rest of the processing largely 483 involves returning information about the IP address specified in the 484 "ciaddr" field. 486 The MAC address of the DHCPLEASEACTIVE message MUST be set to the 487 values that identify the client associated with the IP address in the 488 "ciaddr" field of the DHCPLEASEACTIVE message. 490 If the Client-identifier option (option 61) is specified in the 491 Parameter Request List option (option 55), then the Client-identifier 492 (if any) of the client associated with the IP address in the "ciaddr" 493 field SHOULD be returned in the DHCPLEASEACTIVE message. 495 In the case where more than one IP address has been involved in a 496 DHCP message exchange with the client specified by the Agent Remote 497 ID, then the list of all those IP addresses MUST be returned in the 498 associated-ip option, whether or not that option was requested as 499 part of the Parameter Request List option. 501 If the IP Address Lease Time option (option 51) is specified in the 502 Parameter Request List then the DHCP server MUST return this option 503 in the DHCPLEASEACTIVE message with its value equal to the time 504 remaining until lease expiration. 506 A request for the Renewal (T1) Time Value option or the Rebinding 507 (T2) Time Value option in the Parameter Request List of the 508 DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time 509 option is handled. DHCP server SHOULD return these options (when 510 requested) with the remaining time until renewal or rebinding, 511 respectively. 513 The information contained in the most recent Relay Agent Information 514 option received from the relay agent associated with this IP address 515 MUST be included in the DHCPLEASEACTIVE message. 517 The DHCPLEASEACTIVE message SHOULD include the values of all other 518 options not specifically discussed above that were requested in the 519 Parameter Request List of the DHCPLEASEQUERY message and that are 520 acceptable to return based on the list of "non-sensitive options", 521 discussed below. 523 DHCP servers SHOULD be configurable with a list of "non-sensitive 524 options" that can be returned to the access concentrator when 525 specified in the Parameter Request List of the DHCPLEASEQUERY 526 message. Any option not on this list SHOULD NOT be returned to an 527 access concentrator, even if requested by that access concentrator. 529 The DHCP server uses information from its lease binding database to 530 supply the DHCPLEASEACTIVE option values. The values of the options 531 that were returned to the DHCP client would generally be preferred, 532 but in the absence of those, options that were sent in DHCP client 533 requests would be acceptable. 535 In some cases, the Relay Agent Information option in an incoming 536 DHCPREQUEST packet is used to help determine the options returned to 537 the DHCP client that sent the DHCPREQUEST. When responding to a 538 DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay 539 Agent Information option just like it did when responding to the DHCP 540 client in order to determine the values of any options requested by 541 the DHCPLEASEQUERY message. The goal is to return the same option 542 values to the DHCPLEASEQUERY as those that were returned to the 543 DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise 544 specified, above). 546 In the event that two servers are cooperating to provide a high- 547 availability DHCP server, as supported by [RFC2131], they would have 548 to communicate some information about IP address bindings to each 549 other. In order to properly support the DHCPLEASEQUERY message, 550 these servers MUST ensure that they communicate the Relay Agent 551 Information option information to each other in addition to any other 552 IP address binding information. 554 6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 555 DHCPLEASEUNKNOWN Message 557 The server expects a giaddr in the DHCPLEASEQUERY message, and 558 unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 559 DHCPLEASEUNKNOWN message to the giaddr. 561 6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 562 DHCPLEASEUNKNOWN Message 564 When a DHCPLEASEACTIVE message is received in response to the 565 DHCPLEASEQUERY message, it means that there is a currently active 566 lease for this IP address in this DHCP server. The access 567 concentrator SHOULD use the information in the "htype", "hlen", and 568 "chaddr" fields of the DHCPLEASEACTIVE as well as Relay Agent 569 Information option information included in the packet to refresh its 570 location information for this IP address. An access concentrator is 571 likely to query by IP address for all the IP addresses specified in 572 the associated-ip option in the response, if any, at this point in 573 time. 575 When a DHCPLEASEUNASSIGNED message is received in response to the 576 DHCPLEASEQUERY message, it means that there is currently no active 577 lease associated with the client specified by remote ID in the DHCP 578 server, but that this server does in fact manage the IP address 579 allocation for the client specified by remote ID. Access 580 Concentrator MAY store this information for future use. 582 When a DHCPLEASEUNKNOWN message is received by an access concentrator 583 that has sent out a DHCPLEASEQUERY message, it means that the DHCP 584 server does not have definitive information concerning the DHCP 585 client specified in the Agent Remote ID sub-option of the 586 DHCPLEASEQUERY message. The Access Concentrator MAY store this 587 information for future use. However, a DHCPLEASEQUERY SHOULD NOT be 588 attempted with the same Remote ID sub-option. 590 In both the cases above, the impact of negative caching is greatly 591 reduced as the leasequery by remote-id leads to "definitive" and 592 complete information on all the hosts connected through a connection. 593 Note that in the case of RFC 4388 [RFC4388], a host spoofing several 594 IP addresses can lead to negative caching of greater magnitude. 596 6.8. Receiving No Response to the DHCPLEASEQUERY Message 598 When an access concentrator receives no response to a DHCPLEASEQUERY 599 message, it should be handled in the same manner as suggested in RFC 600 4388 [RFC4388]. 602 6.9. Lease Binding Data Storage Requirements 604 IMPLEMENTATION: 606 To generate replies for a lease query by remote-id effeciently, a 607 DHCP server should index the lease binding data structures using 608 remote-id. 610 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers 612 This scenario should be handled in the same way it is done in RFC 613 4388 [RFC4388]. 615 7. RFC 4388 Considerations 617 This document is compatible with RFC 4388 [RFC4388] based 618 implementations which means that a client which supports this 619 extension can work with a server not supporting this document 620 provided it uses RFC 4388 [RFC4388] defined query types. Also, a 621 server supporting this document can work with a client not supporting 622 this query type. However, there are some changes that this document 623 proposes with respect to RFC 4388 [RFC4388]. Implementors extending 624 RFC 4388 [RFC4388] implementation to support this document, should 625 take note of the following points: 627 o RFC 4388 [RFC4388] suggests that a DHCPLEASEUNASSIGNED is returned 628 only in the case of 'query by IP address'. All other query types 629 will have a return message of either DHCPLEASEACTIVE or 630 DHCPLEASEUNKNOWN'. This document proposes that 631 DHCPLEASEUNASSIGNED can be returned for the query by remote ID. 633 o There may be cases where a query by IP address/MAC address/Client 634 Identifier has an option 82 containing remote ID. In that case, 635 the query will still be recognized as query by IP address/MAC 636 address/Client Identifier as specified by RFC 4388 [RFC4388]. 638 o Section 6.4 of RFC 4388 [RFC4388] suggests that a DHCPLEASEUNKNOWN 639 MUST NOT have any other option present. But for a query by remote 640 ID, option 82 MUST be present in the reply. 642 8. Security Considerations 644 This document does not introduce any new security concerns beyond 645 those specified in the original leasequery protocol RFC 4388 646 [RFC4388] specifications. 648 9. IANA Considerations 650 This document does not introduce any new namespaces for the IANA to 651 manage. 653 10. Acknowledgments 655 Copious amounts of text in this document are derived from RFC 4388 656 [RFC4388]. Kim kinnear provided valuable feedback on this document. 658 11. References 660 11.1. Normative Reference 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 666 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 668 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 669 RFC 2131, March 1997. 671 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 672 RFC 3046, January 2001. 674 11.2. Informative Reference 676 [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", 677 RFC 951, September 1985. 679 [RFC1542] Wimer, W., "Clarifications and Extensions for the 680 Bootstrap Protocol", RFC 1542, October 1993. 682 [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 683 Extensions", RFC 2132, March 1997. 685 Appendix A. Why a New Leasequery is Required? 687 The three existing query types supported by RFC 4388 do not provide 688 effective and efficient antispoofing for the above scenario. 690 o Query by Client Identifier 692 Query by Client Identifier is not possible because to use that access 693 concentrator need to glean client identifier also but the whole issue 694 is that we need leasequeries because the gleaned information was 695 lost. On the other hand, we can query by client identifier when 696 client sends a DHCP request, but then there may not be any need for 697 lease query as such -- regular gleaning may be enough. 699 o Query by IP Address 701 RFC 4388 suggests that it is preferable to use Query by IP Address 702 when getting downstream traffic. 704 Query by IP address is not very useful in downstream traffic because 705 downstream traffic may not exist for the clients on a access port. 706 (In most Internet applications, downstream traffic exists only when a 707 client sends upstream traffic). In other words, the client will be 708 denied service until it gets downstream traffic, which may never 709 come. 711 Query by IP address may be used for upstream traffic. Then whenever 712 an upstream packet comes whose IP address is unknown to the access 713 concentrator, a lease query may be initiated. A related question is 714 what to do with that upstream traffic itself until lease query 715 response comes? If the traffic is dropped, we may be dropping 716 legitimate traffic. If the traffic is forwarded, we may be 717 forwarding spoofed packets. Once the lease response comes, 718 subsequent traffic is handled depending on the response. If a 719 DHCPLEASEACTIVE response comes, access concentrator will accept the 720 traffic. If a DHCPLEASEUNASSIGNED response comes, access 721 concentrator will drop the traffic corresponding to the IP address. 722 If a DHCPLEASEUNKNOWN response comes, access concentrator may drop 723 the traffic corresponding to the IP address but will have to 724 periodically send the lease query for that IP address again 725 (additional overhead). The process is triggered whenever an unknown 726 IP address comes. 728 Note that access concentrator needs to keep track of 4 lists of IP 729 addresses: (1) List of IP addresses for which it got DHCPLEASEACTIVE 730 responses; (2) List of IP addresses for which it got 731 DHCPLEASEUNASSIGNED responses; (3) List of IP addresses for which it 732 got DHCPLEASEUNKNOWN responses; (4) All other IP addresses. 734 This approach may be acceptable if only legitimate traffic is 735 received. Consider the case when someone sends packets that uses 736 spoofed IP addresses. In that case, lease response will be 737 DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. RFC 4388 suggests usage of 738 negative caching in this regard (which involves additional 739 resources). 741 In a spoofing type of attack, negative caching information may grow 742 considerably if attacker varies the source IP address. For each such 743 new source IP address, traffic will come to slow path, a new lease 744 query needs to be initiated, response will be processed, and negative 745 caching to be done. That will mean using many resources for negative 746 caching. 748 RFC 4388 suggests that if the access concentrator knows the network 749 portion of the IP addresses that are assigned to its clients, then 750 some amount of antispoofing can be done in fast path and some lease 751 queries may be avoided. But as indicated before, that information 752 may not always be available to access concentrators. 754 Effectively, antispoofing support involves considerable slow path 755 processing and considerable resources tied for negative caching. 757 RFC 4388 says that DHCP server should be protected from being flooded 758 with too many leasequery requests and access concentrator also should 759 not send too many lease query messages at a time. This would mean 760 that legitimate clients may be excessively delayed getting their 761 information in the face of antispoofing attacks. 763 It is concluded that antispoofing is neither effective nor efficient 764 with this query type. 766 o Query by MAC Address 768 Query by MAC address can also be used similar to query by IP address 769 described above. Indeed, query by MAC address may be better than 770 query by IP address in one sense because of the possible presence of 771 associated-ip option in lease responses (Note that associated-ip 772 option does not appear in responses for query by IP address). With 773 associated-ip option, access concentrator can get information not 774 only about the IP address/MAC address that triggered the lease query 775 but also about other IP addresses that are associated with the 776 original MAC address. That way, when traffic that uses the other IP 777 addresses comes along, access concentrator is already prepared to 778 deal with them. 780 Although, query by MAC address is better than query by IP address in 781 the above respect, it has a specific problem which is not shared by 782 query by IP address. For a query by MAC address, only two types of 783 responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE; 784 DHCPLEASEUNASSIGNED is not supported. This is particularly 785 troublesome when a DHCP server indeed has definitive information that 786 no IP addresses are associated with the specified MAC address in the 787 leasequery, but it is forced to respond with DHCPLEASEUNKNOWN instead 788 of DHCPLEASEUNASSIGNED. As we have seen above, unlike 789 DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying with 790 DHCP server, an additional overhead. 792 Moreover, query by MAC address also shares all other issues we 793 discussed above for query by IP address. 795 We conclude that existing lease query types are not appropriate to 796 achieve effective and efficient antispoofing. 798 Authors' Addresses 800 Pavan Kurapati 801 Infosys Technologies Ltd. 802 44 Electronics City, Hosur Road 803 Bangalore 560 100 804 India 806 Email: pavan_kurapati@infosys.com 807 URI: http://www.infosys.com/ 809 D.T.V Ramakrishna Rao 810 Infosys Technologies Ltd. 811 44 Electronics City, Hosur Road 812 Bangalore 560 100 813 India 815 Email: ramakrishnadtv@infosys.com 816 URI: http://www.infosys.com/ 818 Bharat Joshi 819 Infosys Technologies Ltd. 820 44 Electronics City, Hosur Road 821 Bangalore 560 100 822 India 824 Email: bharat_joshi@infosys.com 825 URI: http://www.infosys.com/