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