idnits 2.17.1 draft-ietf-savi-dhcp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC3315], [RFC2131], [I-D.ietf-savi-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Unrecognized Status in 'Intended status: Standard Tracks', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2011) is 4749 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) == Missing Reference: 'RFC3736' is mentioned on line 141, but not defined ** Obsolete undefined reference: RFC 3736 (Obsoleted by RFC 8415) == Unused Reference: 'RFC4861' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'RFC3307' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'RFC5227' is defined on line 861, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-savi-framework (ref. 'I-D.ietf-savi-framework') ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi, J. Wu, G. Yao 2 Internet Draft Tsinghua University 3 Intended status: Standard Tracks F. Baker 4 Expires: October 2011 Cisco Systems 5 April 26, 2011 7 SAVI Solution for DHCP 8 draft-ietf-savi-dhcp-08.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to publish it 15 as an RFC and to translate it into languages other than English. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 10, 19 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on October 26, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents carefully, 55 as they describe your rights and restrictions with respect to this 56 document. Code Components extracted from this document must include 57 Simplified BSD License text as described in Section 4.e of the Trust 58 Legal Provisions and are provided without warranty as described in 59 the Simplified BSD License. 61 Abstract 63 This document specifies the procedure for creating bindings between a 64 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a 65 binding anchor (refer to [I-D.ietf-savi-framework]) on SAVI (Source 66 Address Validation Improvements) device. The bindings can be used to 67 filter packets generated on the local link with forged source IP 68 address. 70 Table of Contents 72 Copyright Notice ............................................... 2 73 Abstract ....................................................... 2 74 1. Introduction ................................................ 3 75 2. Conventions used in this document ........................... 4 76 3. Terminology ................................................. 4 77 4. SAVI-DHCP Scenario .......................................... 4 78 5. Data Structures ............................................. 5 79 5.1. Control Plane Data Structure: Binding State Table (BST). 5 80 5.2. Data Plane Data Structure: Filtering Table (FT)......... 6 81 6. Binding Anchor Attributes.................................... 6 82 6.1. No Attribute ........................................... 7 83 6.2. SAVI-Validation Attribute............................... 7 84 6.3. SAVI-DHCP-Trust Attribute............................... 7 85 6.4. SAVI-SAVI Attribute..................................... 7 86 6.5. SAVI-BindRecovery Attribute............................. 7 87 7. Binding Set Up .............................................. 8 88 7.1. Rationale .............................................. 8 89 7.2. Binding States Description.............................. 8 90 7.3. Events ................................................. 8 91 7.3.1. Timer expiration event............................. 8 92 7.3.2. Control message arriving events ................... 8 93 7.4. Process of DHCP Packet Snooping ........................ 9 94 7.4.1. From NO_BIND to other states ...................... 9 95 7.4.1.1. Trigger Event................................. 9 96 7.4.1.2. Following Actions............................ 10 97 7.4.2. From INIT_BIND to other states ................... 11 98 7.4.2.1. Trigger Event................................ 11 99 7.4.2.2. Following Actions............................ 12 100 7.4.3. From BOUND to other states ....................... 12 101 7.4.3.1. Trigger Event................................ 12 102 7.4.3.2. Following Actions............................ 12 103 7.5. State Machine of DHCP Snooping ........................ 13 104 8. Supplemental Binding Process................................ 14 105 8.1. Binding Recovery Process............................... 14 106 9. Filtering Specification..................................... 15 107 9.1. Data Packet Filtering.................................. 16 108 9.2. Control Packet Filtering............................... 16 109 10. State Restoration ......................................... 16 110 11. Handle Binding Anchor Off-link Event ...................... 17 111 12. Constants ................................................. 17 112 13. Security Considerations.................................... 17 113 13.1. Binding Number Limitation............................. 17 114 13.2. Risk from Link Layer Routing Dynamic ................. 18 115 13.3. Duplicate Bindings of Same Address ................... 18 116 14. References ................................................ 19 117 14.1. Normative References.................................. 19 118 14.2. Informative References................................ 19 119 15. Acknowledgments ........................................... 20 121 1. Introduction 123 This document describes the procedure for creating bindings between 124 DHCP addresses and binding anchor on SAVI device (refer to [I-D.ietf- 125 savi-framework]). Other related details about this procedure are also 126 specified in this document. The definition and examples of binding 127 anchor are specified in [I-D.ietf-savi-framework]. 129 Bindings can be used to filter packets with forged IP address. 130 Section 9 suggests usage of these bindings for common practice. 132 The mechanism specified in this document is designed to provide a 133 binding anchor granularity validation, as a supplement to BCP38 134 [BCP38]. This mechanism is deployed on the access device (including 135 access switch, wireless access point/controller, etc), and performs 136 mainly DHCP snooping to set up bindings between IP addresses assigned 137 by DHCP and corresponding binding anchors. The binding process is 138 inspired by the work of IP Source Guard [IP Source Guard]. 140 This solution is designed for stateful DHCP scenario [RFC2131, 141 RFC3315]. In stateless DHCP scenarios [RFC3736], DHCP is used to 142 configure other parameters but rather IP address. The address of the 143 client SHOULD be bound based on other SAVI solutions, but rather this 144 solution. 146 This solution is primarily designed for a pure DHCP scenario in which 147 only DHCP address is legitimate global address. How to use this 148 mechanism in multiple address assignments scenario is discussed in 149 [draft-bi-savi-mixed]. 151 2. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 3. Terminology 159 Lease time: Lease time in IPv4 [RFC2131] and valid lifetime in 160 IPv6 [RFC3315] 162 4. SAVI-DHCP Scenario 164 Figure 1 shows the main elements in a DHCP network. At least one DHCP 165 server must be deployed in the network, and DHCP relay may be used to 166 relay message between client and server. Multiple SAVI devices and 167 non-SAVI devices can co-exist on link. A SAVI device can be attached 168 by client, DHCP relay (even DHCP server), SAVI device and non-SAVI 169 device. 171 Other address assignment mechanisms may be also used in such network. 172 However, this solution is primarily designed for a pure DHCP scenario, 173 in which only DHCP servers can assign valid global address. 175 Note that in IPv6 environment, DHCP procedure cannot be performed on 176 an interface without a link-local or global address pre-assigned. 177 Thus, to make this solution work, a SAVI solution for link-local 178 address MUST be enabled. 180 /------------\ 181 +--------+ | | 182 | DHCP |-----| Router | 183 | Server | | | 184 +--------+ \------------/ 185 | 186 --------------|-----------------. 187 | | | 188 | | | 189 | | | 190 | | | 191 | | | 192 +-----\----+ +----'-----+ +---\'-----+ 193 | SAVI | | SAVI | | Non SAVI| 194 | Device | | Device | | Device | 195 +/---.-----+ +-.------.-+ +-----.----+ 196 | | | | | 197 /----| | | | | 198 | | | | | 199 +-------/--++----/-----+ +----\-+ +\-----+ +--\---+ 200 | SAVI || Non SAVI| |DHCP | |Client| |Client| 201 | Device || Device | |Relay | | | | | 202 +----------++----------+ +------+ +------+ +------+ 203 Figure 1 DHCP Scenario 205 5. Data Structures 207 This section describes the data structures used in this mechanism. 209 Two main data structures are used to record bindings and their states 210 respectively. There is redundancy between the two structures, for the 211 consideration of separation of data plane and control plane. 213 5.1. Control Plane Data Structure: Binding State Table (BST) 215 This table contains the state of binding between source address and 216 binding anchor. Entries are keyed on the binding anchor and source IP 217 address. Each entry has a lifetime field recording the remaining 218 lifetime of the entry, a state field recording the state of the 219 binding and a field recording other information. The lifetime field 220 is used to help remove expired bindings. The state field is used to 221 identify state. The other field is used to keep temporary information, 222 e.g., the transaction ID (TID, Refer to Section 2 in [RFC2131] and 223 Section 4.2 in [RFC3315]) in DHCP request. Before a binding is 224 finished, the lease time of the address is also kept in this field 225 because it is improper to keep it in the lifetime field which keeps 226 the lifetime of the binding entry but not the address. 228 +---------+----------+-------+-----------+-------+ 229 | Anchor | Address | State | Lifetime |Other | 230 +---------+----------+-------+-----------+-------+ 231 | A | IP_1 | Bound | 65535 | | 232 +---------+----------+-------+-----------+-------+ 233 | A | IP_2 | Bound | 10000 | | 234 +---------+----------+-------+-----------+-------+ 235 | B | IP_3 |_Start | 1 | | 236 +---------+----------+-------+-----------+-------+ 237 Figure 2 Instance of BST 239 5.2. Data Plane Data Structure: Filtering Table (FT) 241 This table contains the bindings between binding anchor and address, 242 keyed on binding anchor and address. This table doesn't contain any 243 state of the binding. This table is only used to filter packets. An 244 Access Control List can be regarded as a practical instance of this 245 table. 247 +---------+----------+ 248 | Anchor |Address | 249 +---------+----------+ 250 |A |IP_1 | 251 +---------+----------+ 252 |A |IP_2 | 253 +---------+----------+ 254 Figure 3 Instance of FT 256 6. Binding Anchor Attributes 258 This section specifies the binding anchor attributes used in this 259 mechanism. 261 Attribute of each binding anchor is configurable. By default, binding 262 anchor has no attribute. A binding anchor MAY be configured to have 263 one or more compatible attributes. However, a binding anchor MAY 264 always have no attribute. 266 6.1. No Attribute 268 By default, a binding anchor has no attribute. Server type DHCP 269 message from binding anchor with no attribute MUST be dropped. 270 However, other packets SHOULD NOT be dropped. 272 6.2. SAVI-Validation Attribute 274 SAVI-Validation attribute is used on binding anchor on which the 275 source address is to be validated. The filtering process on binding 276 anchor with such attribute is described in section 9. 278 6.3. SAVI-DHCP-Trust Attribute 280 SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a 281 trustable DHCP server/relay. 283 DHCP server/relay message coming from binding anchor with this 284 attribute will be forwarded. 286 6.4. SAVI-SAVI Attribute 288 This attribute is used on binding anchor from which the data traffic 289 is not to be checked. Binding will not be set up on binding anchor 290 with this attribute. Except for message from DHCP server, all packets 291 will not be let pass directly. 293 Through configuring this attribute on binding anchor that joins two 294 or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes 295 implement the security perimeter concept in [savi-framework]. Since 296 no binding entry is needed on such binding anchor, the binding entry 297 resource requirement can be reduced greatly. 299 This attribute can also be set on other binding anchors if the 300 administrator decides not to validate the traffic from the binding 301 anchor. 303 This attribute is mutually exclusive with SAVI-Validation. 305 6.5. SAVI-BindRecovery Attribute 307 This attribute is used on binding anchor that requires data-triggered 308 binding recovery described in section 8.1. 310 This attribute is mutually exclusive with SAVI-SAVI. 312 7. Binding Set Up 314 This section specifies the procedure of setting up bindings based on 315 DHCP message snooping. The binding procedure specified here is 316 exclusively designed for binding anchor with SAVI-Validation 317 attribute. 319 7.1. Rationale 321 The rationale of this mechanism is that if a node attached to a 322 binding anchor is legitimate to use a DHCP address, the DHCP 323 procedure which assigns the address to the node must has been 324 performed on the same binding anchor. This basis stands when the link 325 layer routing is stable. However, layer-2 mobility and unstable link 326 layer routing may result in that data packet is received from a 327 different binding anchor. Infrequent link layer path change can be 328 handled (but not perfectly) by the mechanism described in section 8. 329 Section 13.2 discusses the situation that link layer routing is 330 naturedly unstable. To handle this situation is above the scope of 331 this document. 333 7.2. Binding States Description 335 This section describes the binding states of this mechanism. 337 NO_BIND The state before a binding has been set up. 339 INIT_BIND A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 340 Solicitation with Rapid Commit option) has been received from host, 341 and it may trigger a new binding. 343 BOUND The address is authorized to the client. 345 7.3. Events 347 7.3.1. Timer expiration event 349 EVE_ENTRY_EXPIRE: The lifetime of an entry expires 351 7.3.2. Control message arriving events 353 Only if a control message can pass the check in section 9.2, the 354 corresponding event is a valid event. 356 EVE_DHCP_REQUEST: A DHCP Request message is received from a binding 357 anchor with SAVI-Validation attribute, and the binding entry limit 358 (discussed in "Security Considerations") on the binding anchor has 359 not been reached. 361 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received from a binding 362 anchor with SAVI-Validation attribute, and the binding entry limit on 363 the binding anchor has not been reached. 365 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 366 option is received from a binding anchor with SAVI-Validation 367 attribute, and the binding entry limit on the binding anchor has not 368 been reached. 370 EVE_DHCP_REPLY: A DHCPv4 Acknowledgement or DHCPv6 Reply message is 371 received from a binding anchor with SAVI-DHCP-Trust attribute, and 372 the message should be forwarded to a binding anchor with SAVI- 373 Validation attribute. 375 EVE_DHCP_REPLY_NULL: A DHCPv4 Acknowledgement or DHCPv6 Reply message 376 is received from a binding anchor with SAVI-DHCP-Trust attribute. 378 EVE_DHCP_DECLINE: A DHCP Decline message is received from a binding 379 anchor with SAVI-Validation attribute. 381 EVE_DHCP_RELEASE: A DHCP Release message is received from a binding 382 anchor with SAVI-Validation attribute. 384 EVE_LEASEQUERY_REPLY: A successful DHCP LEASEQUERY_REPLY is received 385 from a binding anchor with SAVI-DHCP-Trust attribute. 387 7.4. Process of DHCP Packet Snooping 389 7.4.1. From NO_BIND to other states 391 7.4.1.1. Trigger Event 393 EVE_DHCP_REQUEST, EVE_DHCP_CONFIRM, EVE_DHCP_OPTION_RC, 394 EVE_DHCP_REPLY_NULL. 396 Note that vulnerability may be caused by DHCP Reply triggered 397 initialization. The binding of assigned address and binding anchor 398 may be threatened if the binding mechanism between binding anchor and 399 link layer address is not secure. If one of the following conditions 400 is satisfied, the security can be ensured. 402 1. DHCP Option 82 is used to keep binding anchor in DHCP Request and 403 Reply, or 405 2. Unspoofable MAC is used as binding anchor(802.11i,802.1ae/af), or 407 3. The mapping table from MAC to binding anchor is secure. 409 It is NOT RECOMMENDED to initialize a binding based on DHCP Reply, 410 until the associated mechanism is also implemented. 412 7.4.1.2. Following Actions 414 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC: 416 The SAVI device MUST forward the message. 418 The SAVI device MUST generate an entry for the binding anchor in 419 the Binding State Table (BST) and set the state field to INIT_BIND. 420 The lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME. 421 The TID field of the request packet MUST be recorded in the entry, 422 except that the mapping from link layer address to binding anchor 423 is secure as specified in section 7.2.1.1. 425 +---------+-------+---------+-----------------------+-------+ 426 | Anchor |Address| State | Lifetime |Other | 427 +---------+-------+---------+-----------------------+-------+ 428 | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 429 +---------+-------+---------+-----------------------+-------+ 430 Figure 4 Binding entry in BST on client triggered initialization 432 The TID is kept as a mediator of assigned address and the binding 433 anchor of requesting node, to assure that the assigned address can 434 be bound with binding anchor secure. 436 If the triggering event is EVE_DHCP_CONFIRM: 438 Other than forwarding the message and generating corresponding 439 entry, the address to be confirmed MUST be recorded in the entry. 440 Because no lease time will be contained in the REPLY from DHCP 441 server, the SAVI device MUST send a LEASEQUERY [RFC5007] message 442 querying by IP address to All_DHCP_Relay_Agents_and_Servers 443 multicast address [RFC3315] or a configured server address. 445 +---------+--------+---------+-----------------------+-------+ 446 | Anchor | Address| State | Lifetime |Other | 447 +---------+--------+---------+-----------------------+-------+ 448 | A | Addr |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 449 +---------+--------+---------+-----------------------+-------+ 450 Figure 5 Binding entry in BST on Confirm triggered initialization 452 If the triggering event is EVE_DHCP_REPLY_NULL: 454 The SAVI device MUST deliver the message to the destination. 456 The SAVI device MUST generate as many new entries in BST and FT as 457 the number of IADDR found in the message. The binding anchor in 458 entry is looked up based on the destination link layer address, 459 from mapping table from link layer address to binding anchor (e.g., 460 the MAC-Port mapping table in case that port is used as binding 461 anchor). The states of the corresponding entries are set to be 462 BOUND. The lifetime of the entries MUST be set to be the lease time. 464 The binding entry limit can be exceeded when setting up bindings 465 for all addresses in a REPLY message. If there is enough binding 466 entry resource, corresponding new entries MUST be generated even 467 the binding number limit is exceeded. In case that there is not 468 enough resource left, as many as possible entries SHOULD be set up. 470 +---------+----------+-------+------------------------+-------+ 471 | Anchor | Address | State | Lifetime |Other | 472 +---------+----------+-------+------------------------+-------+ 473 | A | Addr1 | BOUND | Lease time 1 | | 474 +---------+----------+-------+------------------------+-------+ 475 | A | Addr2 | BOUND | Lease time 2 | | 476 +---------+----------+-------+------------------------+-------+ 477 Binding entry in BST on Reply triggered initialization 479 +---------+----------+ 480 | Anchor |Address | 481 +---------+----------+ 482 |A |Addr1 | 483 +---------+----------+ 484 |A |Addr2 | 485 +---------+----------+ 487 Figure 6 Binding entry in FT on Reply triggered initialization 489 7.4.2. From INIT_BIND to other states 491 7.4.2.1. Trigger Event 493 EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE, EVE_LEASEQUERY_REPLY. 495 7.4.2.2. Following Actions 497 If the trigger event is EVE_DHCP_REPLY: 499 The SAVI device MUST deliver the message to the destination. 501 If the Address field is null, the lease time in Reply message MUST 502 be recorded in the entry with matched TID. The state of the entry 503 is changed to be BOUND. If more than one IADDR is found in the 504 message, if there is enough binding entry resource, corresponding 505 new entries MUST be generated even the binding number limit is 506 exceeded. In case that there is not enough resource left, as many 507 as possible entries SHOULD be set up. 509 If the Address field is not null, the Reply is in response to a 510 Confirm message. If the Reply message is of Status Code Success, 511 set the Lifetime of corresponding entry to be MAX_LEASEQUERY_DELAY. 512 The state of the entry is changed to be BOUND. 514 +---------+----------+-------+------------------------+-------+ 515 | Anchor | Address | State | Lifetime |Other | 516 +---------+----------+-------+------------------------+-------+ 517 | A | Addr | BOUND | Lease time | | 518 +---------+----------+-------+------------------------+-------+ 519 Figure 7 From INIT_BIND to BOUND 521 A corresponding entry MUST also be generated in FT. 523 If the trigger event is EVE_ENTRY_EXPIRE: 525 The entry MUST be deleted from BST. 527 If the trigger event is EVE_LEASEQUERY_REPLY: 529 The Lifetime field of entry with corresponding IP address MUST be 530 set to the lease time in the LEASEQUERY_REPLY. 532 7.4.3. From BOUND to other states 534 7.4.3.1. Trigger Event 536 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 537 EVE_DHCP_REPLY_RENEW. 539 7.4.3.2. Following Actions 541 If the trigger event is EVE_ENTRY_EXPIRE: 543 Remove the corresponding entry in BST and FT. 545 If the trigger event is EVE_DHCP_RELEASE or EVE_DHCP_DECLINE: 547 Remove the corresponding entry in BST and FT. The Release or 548 Decline message MUST be forwarded. 550 If the trigger event is EVE_DHCP_REPLY_RENEW: 552 Set the lifetime of the address to be the new lease time. 554 7.5. State Machine of DHCP Snooping 556 The main state transits are listed as follows. 558 State Event Action Next State 560 NO_BIND REQ/RC Generate entry INIT_BIND 562 NO_BIND CFM Generate entry and send Leasequery INIT_BIND 564 *NO_BIND RPL Generate entry with lease BOUND 566 INIT_BIND RPL Record lease time/set LQ_DLY BOUND 568 INIT_BIND Timeout Remove entry NO_BIND 570 BOUND LQR Record lease time BOUND 572 BOUND RLS/DCL Remove entry NO_BIND 574 BOUND Timeout Remove entry NO_BIND 576 BOUND RNW Set new lifetime BOUND 578 *: optional but NOT RECOMMENDED. 580 REQ: EVE_DHCP_REQUEST 582 CFM: EVE_DHCP_CONFIRM 584 RC: EVE_DHCP_OPTION_RC 586 RPL: EVE_DHCP REPLY 588 DCL: DHCP DECLINE 589 RLS: DHCP RELEASE 591 RNW: EVE_DHCP_RPL_RENEW 593 LQR: EVE_LEASEQUERY_REPLY 595 Timeout: EVE_ENTRY_EXPIRE 597 LQ_DLY: MAX_LEASEQUERY_DELAY 599 8. Supplemental Binding Process 601 Supplemental binding process is designed to cover conditions that 602 packet is sent by node without previous DHCP procedure sensed by the 603 SAVI device. A typical situation is that the link topology change 604 after the binding has been set up, and then the node will send packet 605 to a different port with the bound port. Another scenario is that a 606 node moves on the local link without re-configuration process. 608 Supplemental binding process is designed to avoid permanent 609 legitimate traffic blocking. It is not supposed to set up a binding 610 whenever a data packet with unbound source address is received. 611 Generally, longer time and more packets are needed to trigger 612 supplemental binding processes. 614 Binding Recovery Process is a conditional SHOULD. This function 615 SHOULD be implemented if the vendor has such ability, unless the 616 implementation is known to be directly attached to host. If the 617 mechanism is not implemented and managed nodes are not directly 618 attached, permanent legitimate traffic blocking can happen until the 619 node is reconfigured. 621 8.1. Binding Recovery Process 623 If a binding anchor is set to have SAVI-BindRecovery attribute, 624 packet without matched binding can trigger the SAVI device to check 625 if the source address can be used by corresponding node: 627 1. Check if the address has a local conflict through sending 2 DAD 628 NS/ARP on the address. If duplicate detection fails, the packet 629 MUST be discarded. Otherwise, go to the next step. 631 2. 633 IPv4 address: 635 Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all 636 DHCPv4 servers for IPv4 address or a configured server address. The 637 server addresses may be discovered through DHCPv4 Discovery. If no 638 DHCPLEASEACTIVE message is received, discard the packet; otherwise 639 generate a new binding entry for the address. 641 IPv6 address: 643 Send a LEASEQUERY [RFC5007] message querying by IP address to 644 All_DHCP_Relay_Agents_and_Servers multicast address or a configured 645 server address. If no successful LEASEQUERY-REPLY is received, 646 discard the packet; otherwise generate a new binding entry for the 647 address. The SAVI device may repeat this process if a LEASEQUERY- 648 REPLY with OPTION_CLIENT_LINK is received, in order to set up binding 649 entries for all the address of the client. 651 This process MUST be rate limited to avoid Denial of Services attack 652 against the SAVI device itself. A constant BIND_RECOVERY_INTERVAL is 653 used to control the frequency. Two data-triggered recovery processes 654 on one binding anchor MUST have a minimum interval time 655 BIND_RECOVERY_INTERVAL. This constant SHOULD be configured prudently 656 to avoid Denial of Service attacks. 658 This process is not strict secure. The node with SAVI-BindRecovery 659 binding anchor has the ability to use the address of an inactive node, 660 which doesn't reply to the detection probes. 662 In case that SAVI device is pure layer-2 device without IP address, 663 it is impossible to perform DHCP LEASEQUERY. It is SUGGESTED NOT to 664 perform this data-triggered process. If binding recovery is still 665 required, DHCP Confirm SHOULD be sent instead of DHCP LEASEQUERY. The 666 security degree will degrade for the address may not be assigned by 667 DHCP server. A default lifetime DEFAULT_LEASE SHOULD be set with the 668 entry. 670 This process may fail if any DHCP server doesn't support DHCP 671 LEASEQUERY. 673 9. Filtering Specification 675 This section specifies how to use bindings to filter packets. 677 Filtering policies are different for data packet and control packet. 678 DHCP and ND messages that may cause state transit are classified into 679 control packet. Neighbor Advertisement and ARP Response are also 680 included in control packet, because the Target Address of NA and ARP 681 Response should be checked to prevent spoofing. All other packets are 682 considered to be data packets. 684 9.1. Data Packet Filtering 686 Data packets with a binding anchor which has attribute SAVI- 687 Validation MUST be checked. 689 If the source of a packet associated with its binding anchor is in 690 the FT, this packet SHOULD be forwarded; or else the packet SHOULD be 691 discarded, or alternatively the SAVI SHOULD record this violation. 693 9.2. Control Packet Filtering 695 For binding anchors with SAVI-Validation attribute: 697 Discard/record DHCPv4 Discovery with non-all-zeros source IP address. 698 Discard/record DHCPv4 Request whose source IP address is neither all 699 zeros nor a bound address in FT. 701 Discard/record DHCPv6 Request whose source is not bound with the 702 corresponding binding anchor in FT. Discard/record DHCPv6 Confirm/ 703 Solicit whose source is not a link local address bound with the 704 corresponding binding anchor in FT. The link layer address may be 705 bound based on SAVI-SLAAC solution or other solutions. 707 Discard/record other types of DHCP messages whose source is not an 708 address bound with the corresponding binding anchor. 710 Discard/record IPv6 NS and IPv4 gratuitous ARP whose source is not an 711 address bound with the corresponding binding anchor. 713 Discard/record NA and ARP Replies messages whose target address and 714 source address are not bound with the corresponding binding anchor. 716 For other binding anchors: 718 Discard DHCP Reply/Ack messages not from binding anchor with the 719 SAVI-DHCP-Trust attribute or SAVI-SAVI attribute. 721 10. State Restoration 723 If a SAVI device reboots accidentally or designedly, the states kept 724 in volatile memory will get lost. This may cause hosts indirectly 725 attached to the SAVI device to be broken away from the network, 726 because they can't recover bindings on the SAVI device of themselves. 727 Purely using the Binding Recovery Process is of great cost and delay 728 to recover a large number of bindings. Thus, recovery from non- 729 volatile storage is designed. 731 Binding entries MUST be saved into non-volatile storage whenever a 732 new binding entry changes to BOUND state or a binding with state 733 BOUND is removed in condition that this function is supported by 734 hardware. Immediately after reboot, the SAVI device MUST restore 735 binding states from the non-volatile storage. The lifetime and the 736 system time of save process MUST be stored. Then the device MUST 737 check whether the saved entries are obsolete when rebooting. 739 11. Handle Binding Anchor Off-link Event 741 Port DOWN event MUST be handled if switch port is used as binding 742 anchor. In more general case, if a binding anchor turns off-link, 743 this event MUST be handled. 745 Whenever a binding anchor with attribute SAVI-Validation turns down, 746 set a timer with OFFLINK_DELAY. Until the timer becomes zero, the 747 bindings with the binding anchor SHOULD be kept. As an exception, to 748 handle movement, if receiving DAD Neighbor Solicitation/Gratuitous 749 ARP request targeting at the address during OFFLINK_DELAY, the entry 750 MAY be removed. 752 If the binding anchor turns on-link during OFFLINK_DELAY, turn off 753 the timer and keep corresponding bindings. 755 12. Constants 757 MAX_DHCP_RESPONSE_TIME 120s 759 BIND_RECOVERY_INTERVAL 60s and configurable 761 MAX_LEASEQUERY_DELAY 10s 763 DEFAULT_LEASE 2h 765 OFFLINK_DELAY 2s 767 13. Security Considerations 769 13.1. Binding Number Limitation 771 It is suggested to configure some mechanism in order to prevent a 772 single node from exhausting the binding table entries on the SAVI 773 device. Either of the following mechanism is sufficient to prevent 774 such attack. 776 1. Set the upper bound of binding number for each binding anchor with 777 SAVI-Validation. 779 2. Reserve a number of binding entries for each binding anchor with 780 SAVI-Validation attribute and all binding anchors share a pool of 781 the other binding entries. 783 3. Limit DHCP Request rate per binding anchor. 785 13.2. Risk from Link Layer Routing Dynamic 787 An implicit assumption of this solution is that data packet must 788 arrive at the same binding anchor with the binding anchor that the 789 control packets have arrived at. If this assumption is not valid, 790 this control packet based solution will fail or at least discard 791 legitimate packet. Unfortunately, the link layer routing between host 792 and SAVI device can be inconsistent from time to time. Time 793 consistency of link layer routing is not assured by link layer 794 routing protocol. For example, TRILL, a recent link layer routing 795 protocol, is flexible and multiple link layer paths are allowed. 797 To make the basic assumption stand, the best way is enforcing that 798 there should be only one topology path from downstream host to the 799 SAVI device. For example, SAVI device is directly attached by hosts. 801 If the assumption doesn't stand, a better solution is requiring 802 inter-operation between SAVI protocol and the link layer routing 803 protocol to make SAVI protocol sensitive to the link layer routing 804 change. This solution is above the scope of this document. 806 13.3. Duplicate Bindings of Same Address 808 The same address may be bound with multiple binding anchors, only if 809 the binding processes are finished on each binding anchor 810 successfully respectively. This mechanism is designed in 811 consideration that a node may move on the local ink, and a node may 812 have multiple binding anchors. However, the traceability of address 813 is reduced. 815 Note that the local link movement scenario is not handled perfectly. 816 The former binding may not be removed, unless the node is directly 817 attached to the SAVI device. The nodes sharing the same former 818 binding anchor of the moving node have the ability to use its address. 820 14. References 822 14.1. Normative References 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [I-D.ietf-savi-framework] 829 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 830 "Source Address Validation Improvement Protocol Framework", 831 draft-ietf-savi-framework-04 (work in progress), March 2011. 833 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 834 March 1997. 836 [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6 837 (DHCPv6)", RFC3315, July 2003. 839 [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration 840 Protocol (DHCP) Leasequery", RFC4388, February 2006. 842 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 843 "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, 844 September 2007. 846 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 847 Autoconfiguration", RFC4862, September, 2007. 849 [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6 850 Leasequery", RFC5007, September 2007. 852 14.2. Informative References 854 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 855 Defeating Denial of Service Attacks which employ IP Source 856 Address Spoofing", BCP 38, RFC 2827, May 2000. 858 [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast 859 Addresses", RFC3307, August 2002. 861 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 862 July 2008. 864 [IP Source Guard] 866 Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet 867 draft (work in progress), November 2007. 869 [draft-bi-savi-mixed] 871 Jun Bi, Guang Yao, J. Halpern and E. Levy-Abegnoli, "SAVI 872 for Mixed Address Assignment Methods Scenario", draft-bi- 873 savi-mixed-04 (work in progress), March 2011. 875 15. Acknowledgments 877 Special thanks to Christian Vogt, Joel M. Halpern, Eric Levy-Abegnoli 878 and Alberto Garcia for careful review and valuation comments on the 879 state machine and text. 880 Thanks to Marcelo Bagnulo Braun, Mark Williams, Erik Nordmark, Mikael 881 Abrahamsson, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia 882 Zhang, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 883 their valuable contributions. 885 Authors' Addresses 887 Jun Bi 888 Network Research Center, Tsinghua University 889 Beijing 100084 890 China 891 Email: junbi@cernet.edu.cn 893 Jianping Wu 894 Computer Science, Tsinghua University 895 Beijing 100084 896 China 897 Email: jianping@cernet.edu.cn 899 Guang Yao 900 Computer Science, Tsinghua University 901 Beijing 100084 902 China 903 Email: yaog@netarchlab.tsinghua.edu.cn 905 Fred Baker 906 Cisco Systems 907 Santa Barbara, California 93117 908 US 909 Email: fred@cisco.com