idnits 2.17.1 draft-ietf-savi-dhcp-04.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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC3315], [RFC2131], [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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: MUST not be delivered to the host which the SAVI device is performing DAD on behavior of. == 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 (July 5, 2010) is 5044 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: 'SAVI-framework' is mentioned on line 66, but not defined == Missing Reference: 'RFC3736' is mentioned on line 157, but not defined ** Obsolete undefined reference: RFC 3736 (Obsoleted by RFC 8415) == Missing Reference: 'BCP38' is mentioned on line 172, but not defined == Missing Reference: 'RFC5460' is mentioned on line 979, but not defined == Unused Reference: 'RFC4862' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC5227' is defined on line 1089, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi, J. Wu 2 Internet Draft CERNET 3 Intended status: Standard Tracks G. Yao 4 Expires: January 2011 Tsinghua Univ. 5 F. Baker 6 Cisco 7 July 5, 2010 9 SAVI Solution for DHCP 10 draft-ietf-savi-dhcp-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may not be modified, 16 and derivative works of it may not be created, except to publish it 17 as an RFC and to translate it into languages other than English. 19 This document may contain material from IETF Documents or IETF 20 Contributions published or made publicly available before November 10, 21 2008. The person(s) controlling the copyright in some of this 22 material may not have granted the IETF Trust the right to allow 23 modifications of such material outside the IETF Standards Process. 24 Without obtaining an adequate license from the person(s) controlling 25 the copyright in such materials, this document may not be modified 26 outside the IETF Standards Process, and derivative works of it may 27 not be created outside the IETF Standards Process, except to format 28 it for publication as an RFC or to translate it into languages other 29 than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on December 5, 2010. 47 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents carefully, 56 as they describe your rights and restrictions with respect to this 57 document. Code Components extracted from this document must include 58 Simplified BSD License text as described in Section 4.e of the Trust 59 Legal Provisions and are provided without warranty as described in 60 the Simplified BSD License. 62 Abstract 64 This document specifies the procedure for creating bindings between a 65 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a 66 binding anchor (refer to [SAVI-framework]) on SAVI (Source Address 67 Validation Improvements) device. The bindings can be used to filter 68 packets generated on the local link with forged source IP address. 70 Table of Contents 72 Copyright Notice ............................................... 2 73 Abstract ....................................................... 2 74 1. Introduction ................................................ 4 75 2. Conventions used in this document............................ 4 76 3. Mechanism Overview .......................................... 4 77 4. Terminology ................................................. 4 78 5. Conceptual 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).......... 5 81 6. Binding States Description................................... 6 82 7. DHCP Scenario ............................................... 6 83 8. Binding Anchor Attributes.................................... 7 84 8.1. No Attribute ........................................... 7 85 8.2. SAVI-Validation Attribute............................... 7 86 8.3. SAVI-DHCP-Trust Attribute............................... 7 87 8.4. SAVI-SAVI Attribute..................................... 8 88 8.5. SAVI-BindRecovery Attribute............................. 8 89 8.6. SAVI-ExtSnooping Attribute.............................. 8 90 9. Binding Set Up .............................................. 8 91 9.1. Rationale .............................................. 8 92 9.2. Process of Control Packet Snooping...................... 9 93 9.2.1. Initialization..................................... 9 94 9.2.1.1. Trigger Event................................. 9 95 9.2.1.2. Event Validation............................. 10 96 9.2.1.3. Following Actions............................ 10 97 9.2.2. From START to LIVE................................ 11 98 9.2.2.1. Trigger Event................................ 11 99 9.2.2.2. Event Validation............................. 11 100 9.2.2.3. Following Actions............................ 12 101 9.2.3. From LIVE to DETECTION............................ 12 102 9.2.3.2. Event Validation............................. 12 103 9.2.3.3. Following Actions............................ 12 104 9.2.4. From DETECTION to BOUND........................... 13 105 9.2.4.1. Trigger Event................................ 13 106 9.2.4.2. Following Actions............................ 13 107 9.2.5. Binding Deletion in DETECTION State............... 13 108 9.2.5.1. Trigger Event................................ 13 109 9.2.5.2. Following Actions............................ 14 110 9.2.6. After BOUND....................................... 14 111 9.3. State Machine of DHCP Snooping......................... 15 112 10. Supplemental Binding Process:Handling Link Topology Change. 16 113 10.1. Binding Recovery Process.............................. 17 114 10.2. External Control Packet Snooping Process.............. 18 115 11. Filtering Specification.................................... 18 116 11.1. Data Packet Filtering................................. 19 117 11.2. Control Packet Filtering.............................. 19 118 12. Format and Delivery of Probe Messages...................... 19 119 12.1. Duplicate Detection................................... 20 120 13. Binding Remove ............................................ 20 121 14. Handle Binding Anchor Off-link Event....................... 20 122 15. About Collision in Detection............................... 21 123 16. Binding Number Limitation.................................. 21 124 17. MLD Consideration ......................................... 22 125 18. State Restoration ......................................... 22 126 19. Confirm Triggered Binding.................................. 22 127 20. Consideration on Link Layer Routing Complexity............. 23 128 21. Duplicate Bindings of Same Address......................... 23 129 22. Constants ................................................. 23 130 23. Security Considerations.................................... 24 131 24. IANA Considerations........................................ 24 132 25. References ................................................ 24 133 25.1. Normative References.................................. 24 134 25.2. Informative References................................ 24 135 26. Acknowledgments ........................................... 25 136 27. Change Log ................................................ 26 138 1. Introduction 140 This document describes the procedure for creating bindings between 141 DHCP assigned addresses and a binding anchor (refer to [savi- 142 framework]). Other related details about this procedure are also 143 specified in this document. 145 These bindings can be used to filter packets with forged IP address. 146 Section 12 suggests usage of these bindings for common practice. 147 [savi-framework] may specify different usages of binding, depending 148 on the environment and configuration. The definition and examples of 149 binding anchor is specified in [savi-framework]. 151 The binding process is inspired by the work of IP Source Guard [IP 152 Source Guard]. This solution differs from IP Source Guard in the 153 specification for collision detection, which is essential in 154 environments with multiple address assignment methods. There are also 155 other differences in details. 157 In a stateless DHCP scenario [RFC3736], DHCP is used to configure 158 other parameters but rather IP address. The address of the client 159 SHOULD be bound based on other SAVI solutions, but rather this 160 solution designed for stateful DHCP. 162 2. Conventions used in this document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 3. Mechanism Overview 170 The mechanism specified in this document is designed to provide an 171 address level source IP address validation granularity, as a 172 supplement to BCP38 [BCP38]. This mechanism is deployed on the access 173 device (including access switch, wireless access point/controller, 174 etc), and performs mainly DHCP snooping to set up bindings between 175 DHCP assigned IP addresses and corresponding binding anchors. The 176 bindings can be used to validate the source address in the packets. 178 4. Terminology 180 Main terms used in this document are described in [savi-framework], 181 [RFC2131] and [RFC3315]. 183 5. Conceptual Data Structures 185 This section describes the possible conceptual data structures used 186 in this mechanism. 188 Two main data structures are used to record bindings and their states 189 respectively. There is redundancy between the two structures, for the 190 consideration of separation of data plane and control plane. 192 5.1. Control Plane Data Structure: Binding State Table (BST) 194 This table contains the state of binding between source address and 195 binding anchor. Entries are keyed on the binding anchor and source IP 196 address. Each entry has a lifetime field recording the remaining 197 lifetime of the entry, a state field recording the state of the 198 binding and a field recording other information. The lifetime field 199 is used to help remove expired bindings. The state field is used to 200 identify state. The other field is used to keep temporary information, 201 e.g., the transaction ID in DHCP request. Before a binding is 202 finished, the lease time of the address is also kept in this field 203 because it is improper to keep it in the lifetime field which keeps 204 the lifetime of the binding entry but not the address. 206 +---------+----------+-------+-----------+-------+ 207 | Anchor | Address | State | Lifetime |Other | 208 +---------+----------+-------+-----------+-------+ 209 | A | IP_1 | Bound | 65535 | | 210 +---------+----------+-------+-----------+-------+ 211 | A | IP_2 | Bound | 10000 | | 212 +---------+----------+-------+-----------+-------+ 213 | B | IP_3 |_Start | 1 | | 214 +---------+----------+-------+-----------+-------+ 215 Figure 1 Instance of BST 217 5.2. Data Plane Data Structure: Filtering Table (FT) 219 This table contains the bindings between binding anchor and address, 220 keyed on binding anchor and address. This table doesn't contain any 221 state of the binding. This table is only used to filter packets. An 222 Access Control List can be regarded as a practical instance of this 223 table. 225 +---------+----------+ 226 | Anchor |Address | 227 +---------+----------+ 228 |A |IP_1 | 229 +---------+----------+ 230 |A |IP_2 | 231 +---------+----------+ 232 Figure 2 Instance of FT 234 6. Binding States Description 236 This section describes the binding states of this mechanism. 238 START A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 239 Solicitation with Rapid Commit option) has been received from host, 240 and it may trigger a new binding. 242 LIVE A DHCP address has been acknowledged by a DHCP server. 244 DETECTION A gratuitous ARP or Duplicate Address Detection NSOL 245 has been sent by the host (or the SAVI device). 247 BOUND The address has passed duplicate detection and 248 it is bound with the binding anchor. 250 7. DHCP Scenario 252 Figure 3 shows the main elements in a DHCP enabled network. At least 253 one DHCP server must be deployed in the network, and DHCP relay may 254 be used to relay message between client and server. Other address 255 assignment mechanisms may be also used in such network. 257 +--------+ 258 | DHCP | 259 | Server | 260 +--------+ 261 | 262 | 263 | 264 +----'-----+ 265 | SAVI | 266 | Device | 267 +-/------/-+ 268 | | 269 +----\-+ +\-----+ 270 |DHCP | |Client| 271 |Relay | | | 272 +------+ +------+ 273 Figure 3 DHCP Scenario 275 8. Binding Anchor Attributes 277 This section specifies the binding anchor attributes involved in this 278 mechanism. 280 Binding anchor is defined in the [savi-framework]. Attribute of each 281 binding anchor is configurable. In default, binding anchor has no 282 attribute. A binding anchor MAY be configured to have one or more 283 compatible attributes. However, a binding anchor MAY have no 284 attribute. 286 8.1. No Attribute 288 By default, a binding anchor has no attribute. Server type DHCP 289 message from binding anchor with no attribute MUST be dropped. 290 However, other packets SHOULD NOT be dropped. 292 8.2. SAVI-Validation Attribute 294 SAVI-Validation attribute is used on binding anchor on which the 295 source addresses are to be validated. The filtering process on 296 binding anchor with such attribute is described in section 13. 298 8.3. SAVI-DHCP-Trust Attribute 300 SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a 301 trustable DHCP server/relay. 303 DHCP server/relay message coming from binding anchor with this 304 attribute will be forwarded. 306 8.4. SAVI-SAVI Attribute 308 This attribute is used on binding anchor from which the traffic is 309 not to be checked. All traffic from binding anchor with this 310 attribute will be forwarded without check. Note that DHCP server 311 message and router message will also be trusted. 313 Through configuring this attribute on binding anchor that joins two 314 or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes 315 implement the security perimeter concept in [savi-framework]. Since 316 no binding entry is needed on such binding anchor, the binding entry 317 resource requirement can be reduced greatly. 319 This attribute can also be set on other binding anchors if the 320 administrator decides not to validate the traffic from the binding 321 anchor. 323 This attribute is mutually exclusive with SAVI-Validation. 325 8.5. SAVI-BindRecovery Attribute 327 This attribute is used on binding anchor that requires binding 328 recovery described in section 10.1. 330 This attribute is mutually exclusive with SAVI-SAVI. 332 8.6. SAVI-ExtSnooping Attribute 334 This attribute is used on binding anchor that requires external 335 control packet snooping described in section 10.2. 337 This attribute is mutually exclusive with SAVI-SAVI. 339 9. Binding Set Up 341 This section specifies the procedure of setting up bindings based on 342 control packet snooping. The binding procedure specified here is 343 exclusively designed for binding anchor with SAVI-Validation 344 attribute. 346 9.1. Rationale 348 The rationale of this mechanism is that if a node attached to a 349 binding anchor intends to use a valid DHCP address, the DHCP 350 procedure which assigns the address to the node goes first on the 351 same binding anchor. This basis stands when the link layer routing is 352 stable. However, unstable link layer routing may result in that data 353 packet is received from a different binding anchor with the DHCP 354 messages. Infrequent link layer path change can be handled (but not 355 perfectly) by the mechanism described in section 10. Section 20 356 discusses the situation that link layer routing is naturedly unstable. 357 To handle this situation is above the scope of this document. 359 This mechanism is mainly composed by 1: DHCP snooping; 2: Duplicate 360 Address Detection (DAD) snooping. DHCP snooping alone is not 361 sufficient to finish a binding. Three reasons are listed to support 362 this point: 364 (1) The assigned address may be already configured on another 365 host through SLAAC or manual configuration. 367 (2) If multiple DHCP servers exist in the network, or the 368 server(s) loses state, an assigned address may be assigned 369 again before withdraw. 371 (3) Bogus/misconfigured DHCP server may also assign an already 372 assigned address. 374 For the above reasons, set up a binding solely on DHCP snooping may 375 violate existing binding or address assignment. Thus, DAD snooping is 376 necessary for finishing a binding. 378 Due to DAD may not be performed by host (especially for IPv4 address) 379 or the DAD NS may get lost, SAVI devices are required to perform DAD 380 on behavior of the host. 382 9.2. Process of Control Packet Snooping 384 9.2.1. Initialization 386 A binding entry is initialized in this step. 388 9.2.1.1. Trigger Event 390 A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with 391 Rapid Commit option is received. 393 Or a DHCP Reply is received from binding anchor with SAVI-DHCP-Trust 394 attribute. Note that vulnerability may be caused by DHCP Reply 395 triggered initialization. The binding of assigned address and binding 396 anchor may be threatened if the binding mechanism between binding 397 anchor and link layer address is not secure. If one of the following 398 conditions is satisfied, the security can be ensured. 400 1. Option 82 is used to keep binding anchor in DHCP Request and Reply, 401 or 403 2. Unspoofable MAC is used as binding anchor(802.11i,802.1ae/af), or 405 3. The mapping table from MAC to binding anchor is secure. 407 It is SUGGESTED not to initialize a binding based on DHCP Reply, 408 until the associated mechanism is also implemented. 410 9.2.1.2. Event Validation 412 The SAVI device checks current BST as follows: 414 1. Whether the limitation on binding entry number of this binding 415 anchor will be exceeded if a new entry is triggered. 417 9.2.1.3. Following Actions 419 If the check fails, the triggering message SHOULD be discarded. This 420 event MAY be announced on console interface. 422 If the check is passed: 424 If the triggering message is DHCP Request/Confirm/Solicitation with 425 Rapid Commit Option: 427 The SAVI device MUST forward the message. 429 The SAVI device MUST generate an entry for the binding anchor in the 430 Binding State Table (BST) and set the state field to START. The 431 lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The 432 Transaction ID (Refer to Section 2 in [RFC2131] and Section 4.2 in 433 [RFC3315]) field of the request packet MUST be recorded in the entry, 434 except that the mapping from link layer address to binding anchor is 435 secure as specified in section 9.2.1.1. 437 +---------+----------+-------+-----------------------+-------+ 438 | Anchor | Address | State | Lifetime |Other | 439 +---------+----------+-------+-----------------------+-------+ 440 | A | | START |MAX_DHCP_RESPONSE_TIME | TID | 441 +---------+----------+-------+-----------------------+-------+ 442 Figure 4 Binding entry in BST on client triggered initialization 444 The TID is kept as a mediator of assigned address and the binding 445 anchor of requesting node, to assure that the assigned address can be 446 bound with binding anchor secure. 448 If the triggering message is DHCP Reply: 450 The SAVI device MUST deliver the message to the destination. 452 The SAVI device MUST generate a new entry in BST and FT. The binding 453 anchor in entry is looked up based on the destination link layer 454 address, from mapping table from link layer address to binding anchor 455 (e.g., the MAC-Port mapping table in case that port is used as 456 binding anchor). The state of the corresponding entry is set to be 457 LIVE. The lifetime of the entry MUST be set to be 458 MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY respectively. The 459 lease time MUST be recorded in the entry. 461 +---------+----------+-------+------------------------+-------+ 462 | Anchor | Address | State | Lifetime |Other | 463 +---------+----------+-------+------------------------+-------+ 464 | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | 465 | | | |MAX_DAD_PREPARE_DELAY | Time | 466 +---------+----------+-------+------------------------+-------+ 467 Figure 5 Binding entry in BST on Reply triggered initialization 469 +---------+----------+ 470 | Anchor |Address | 471 +---------+----------+ 472 |A |Addr | 473 +---------+----------+ 474 Figure 6 Binding entry in FT on Reply triggered initialization 476 9.2.2. From START to LIVE 478 9.2.2.1. Trigger Event 480 A DHCPv4 DHCPACK or DHCPv6 REPLY message is received from SAVI-DHCP- 481 Trust binding anchor. 483 9.2.2.2. Event Validation 485 The SAVI device checks the message and BST as follows: 487 1. Whether there exists an entry in the BST with corresponding TID in 488 the START state. 490 9.2.2.3. Following Actions 492 If the check fails, the message may be used to trigger binding 493 initialization, specified in section 11.1.1. 495 If the check is passed: 497 The SAVI device MUST deliver the message to the destination. 499 The state of the corresponding entry is changed to be LIVE. The 500 lifetime of the entry MUST be set to be MAX_ARP_PREPARE_DELAY or 501 MAX_DAD_PREPARE_DELAY respectively. The lease time MUST be recorded 502 in the entry. 504 +---------+----------+-------+------------------------+-------+ 505 | Anchor | Address | State | Lifetime |Other | 506 +---------+----------+-------+------------------------+-------+ 507 | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | 508 | | | |MAX_DAD_PREPARE_DELAY | Time | 509 +---------+----------+-------+------------------------+-------+ 510 Figure 7 From START to LIVE 512 A corresponding entry MUST also be generated in FT. 514 9.2.3. From LIVE to DETECTION 516 9.2.3.1. Trigger Event 518 A gratuitous ARP Request or Duplicate Address Detection Neighbor 519 Solicitation is received from binding anchor. Or a timeout event of 520 an entry with state LIVE happens. 522 9.2.3.2. Event Validation 524 The SAVI device checks the message and BST as follows: 526 1. Whether the Target IP Address field of the ARP Request or Neighbor 527 Solicitation has been bound with the corresponding binding anchor 528 in BST or FT, and the state in BST must be LIVE. 530 9.2.3.3. Following Actions 532 If the check fails because of the Target Address is not in BST, the 533 packet MUST be discarded. If the entry state is not LIVE, the message 534 MUST be forwarded. 536 If the check is passed: 538 If the event is triggered by client, SAVI device MUST set the state 539 of the corresponding entry to be DETECTION. 541 +---------+----------+-----------+-----------------+-------+ 542 | Anchor | Address | State | Lifetime |Other | 543 +---------+----------+-----------+-----------------+-------+ 544 | A | Addr | DETECTION |MAX_ARP_DELAY or | Lease | 545 | | | |MAX_DAD_DELAY | Time | 546 +---------+----------+-----------+-----------------+-------+ 547 Figure 8 From LIVE to DETECTION 549 If triggered by timeout event on an entry in state LIVE, the SAVI 550 device MUST send one or more ARP Request or DAD NSOL, with Target 551 Address set to the recorded address in the entry. The format of 552 detection packet is specified in section 14. The state MUST be 553 changed to DETECTION. The lifetime of the entry MUST be set to be 554 MAX_ARP_DELAY or MAX_DAD_DELAY respectively. 556 9.2.4. From DETECTION to BOUND 558 9.2.4.1. Trigger Event 560 A timeout event of an entry with state DETECTION occurs. 562 9.2.4.2. Following Actions 564 If a timeout event of an entry with state DETECTION occurs, set the 565 state of the entry to be BOUND. The lifetime of the entry is set to 566 be the Lease time acknowledged by DHCP server. 568 +---------+----------+-----------+----------------+-------+ 569 | Anchor | Address | State | Lifetime |Other | 570 +---------+----------+-----------+----------------+-------+ 571 | A | Addr | BOUND | Lease time | | 572 +---------+----------+-----------+----------------+-------+ 573 Figure 9 Binding entry in BST on finalization 575 If an ARP Response or NA for an address in BST with state DETECTION 576 is received, remove the corresponding entry in BST and FT. The ARP 577 Response or NA MUST be delivered to the client. 579 9.2.5. Binding Deletion in DETECTION State 581 9.2.5.1. Trigger Event 583 An ARP Response or NA/DAD NS targeting at an address in BST with 584 state DETECTION is received from a different binding anchor. 586 9.2.5.2. Following Actions 588 If ARP Response or NA is received from binding anchor with SAVI- 589 Validation attribute, but the address is not bound with the binding 590 anchor, the packet MUST be dropped. If DAD NS is received from 591 binding anchor with SAVI-Validation, the message MUST be delivered to 592 the former detecting node. The binding SHOULD be removed. 594 If the message is received from binding anchor with SAVI-Validation 595 attribute, and the address is bound with binding anchor, the message 596 MUST be delivered to the detecting node, and the binding MUST be 597 removed. 599 If the message is received from binding anchor without SAVI- 600 Validation attribute, the message MUST be delivered to the detecting 601 node. The binding SHOULD be removed. 603 9.2.6. After BOUND 605 Once a binding entry is set up for a binding anchor, the binding will 606 be used to filter packet with the binding anchor, as specified in 607 section 13. On the other hand, DHCP messages with the binding anchor 608 will affect the binding. The binding is also affected by DHCP server 609 message toward the binding anchor. 611 Before a DHCP message is found that it may change the corresponding 612 binding, its validity MUST be checked as described in section 13.2. 614 Whenever a DHCP Decline is received, delete the corresponding entry 615 in BST and FT. 617 Whenever a DHCP Release is received, if the state of the entry is 618 BOUND, delete the entry in BST and FT. 620 If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is 621 received from the server, set lifetime of the entry in BST to be the 622 new lease time. 624 If the lifetime of an entry with state BOUND expires, delete the 625 entry in BST and Filter Table. 627 Switch port down event (or in a more general expression, binding 628 anchor turns off-link) will change the corresponding entry, as 629 described in section 16. 631 9.3. State Machine of DHCP Snooping 633 The main state transits are listed as follows. Note that precondition 634 of state transit is not included. Triggering message/event must 635 satisfy the preconditions before changing the state. 637 State Message/Event Action Next State 639 - REQ/CFM/SOL+RC Generate entry START 641 *- ACK/RPL Generate entry with lease LIVE 643 START ACK/RPL Record lease time LIVE 645 START Timeout Remove entry - 647 LIVE Gra ARP REQ/DAD NS - DETECTION 649 LIVE DECLINE/RELEASE Remove entry - 651 LIVE Timeout Send probe DETECTION 653 DETECTION Timeout - BOUND 655 DETECTION ARP RES/DAD NS/NA Remove entry - 657 DETECTION DECLINE/RELEASE Remove entry - 659 BOUND RELEASE/DECLINE Remove entry - 661 BOUND Timeout Remove entry - 663 BOUND RPL with REN/REB Set new lifetime BOUND 665 *: optional but NOT SUGGESTED. 667 REQ: DHCP REQUEST 669 CFM: DHCP CONFIRM 671 SOL: DHCP SOLICITATION 673 RC: Rapid Commit option 675 ACK: DHCP ACKNOWLEDGEMENT 677 RPL: DHCP REPLY 678 Probe Gratuitous ARP REQUEST or Duplicate Address Detection Neighbor 679 Solicitation, described in section 11.1.3 and section 14. 681 Gra ARP REQ: Gratuitous ARP REQUEST 683 ARP RES: ARP RESPONSE 685 DAD NS: Duplicate Address Detection Neighbor Solicitation 687 DAD NA: Neighbor Advertisement targeting at a tentative address 689 DECLINE: DHCP DECLINE 691 RELEASE: DHCP RELEASE 693 REN: DHCP RENEW 695 REB: DHCP REBOUND 697 10. Supplemental Binding Process: Handling Link Topology Change 699 Supplemental binding process is designed to cover conditions that 700 packet is sent by node without previous DHCP procedure sensed by the 701 SAVI device. A typical situation is that the link topology change 702 after the binding has been set up, and then the node will send packet 703 to a different port with the bound port. Another scenario is that a 704 node moves on the local link without re-configuration process, which 705 can be regarded as a special case of link topology change. In DHCP 706 scenario, till this document is finished, link topology change is the 707 only two events that must be handled through this supplemental 708 binding process. 710 Supplemental binding process is designed to avoid permanent 711 legitimate traffic blocking. It is not supposed to set up a binding 712 whenever a data packet with unbound source address is received. 713 Generally, longer time and more packets are needed to trigger 714 supplemental binding processes. 716 For implementations that will face the above problem: 718 1. Binding Recovery Process is a conditional SHOULD. This process 719 SHOULD be implemented, unless the managed nodes are directly 720 attached to the SAVI device. If the mechanism is not implemented 721 and managed nodes are not directly attached, permanent blocking 722 will happen until the node is re-configured. 724 2. Extended Control Packet Snooping Process is a MUST. 726 Other techniques may be prudently chosen as alternative if found to 727 have equivalent or even better function to avoid permanently blocking 728 after discussion, implementation and deployment. 730 10.1. Binding Recovery Process 732 Refer to [draft-baker-savi-one-implementation-approach] for a 733 detailed implementation suggestion. The process specified here can 734 only be enabled in condition that implementation can meet the 735 specified hardware requirements described in [draft-baker-savi-one- 736 implementation-approach]. 738 If a binding anchor is set to have SAVI-BindRecovery attribute, a 739 FIFO queue or register MUST be used to save recently filtered packets. 740 The SAVI device will fetch packet from the queue/register to check 741 the source address can be used by corresponding client on the local 742 link with limited rate: 744 1. If the address has a local conflict, meaning the DAD on the 745 address fails, the packet MUST be discarded. If the address is not 746 being used, go to the next step. 748 2. 750 IPv4 address: 752 Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all 753 DHCPv4 servers for IPv4 address or a configured server address. The 754 server addresses may be discovered through DHCPv4 Discovery. If no 755 DHCPLEASEACTIVE message is received, discard the packet; otherwise 756 generate a new binding entry for the address. 758 IPv6 address: 760 Send a LEASEQUERY [RFC5007] message querying by IP address to 761 All_DHCP_Relay_Agents_and_Servers multicast address or a configured 762 server address. If no successful LEASEQUERY-REPLY is received, 763 discard the packet; otherwise generate a new binding entry for the 764 address. The SAVI device may repeat this process if a LEASEQUERY- 765 REPLY with OPTION_CLIENT_LINK is received, in order to set up binding 766 entries for all the address of the client. 768 This process MUST be rate limited to avoid Denial of Services attack 769 against the SAVI device itself. A constant BIND_RECOVERY_INTERVAL is 770 used to control the frequency. Two data based processes on one 771 binding anchor must have a minimum interval time 772 BIND_RECOVERY_INTERVAL. This constant SHOULD be configured prudently 773 to avoid Denial of Services. 775 This process is not strict secure. The node with SAVI-BindRecovery 776 binding anchor has the ability to use the address of an inactive node, 777 which doesn't reply to the DAD probe. 779 In case that the SAVI device is a pure layer-2 device, DHCP Confirm 780 MAY be used to replace the DHCP LEASEQUERY. The security degree may 781 degrade for the address may not be assigned by DHCP server. 783 This process may fail if any DHCP server doesn't support LEASEQUERY. 785 10.2. External Control Packet Snooping Process 787 In this snooping process, other than DHCP initialization messages, 788 other types of control packets processed by processor of SAVI device, 789 if the source address is not bound, may trigger the device to perform 790 binding process. 792 The control messages that MUST be processed include: (1) address 793 resolution Neighbor Solicitation; (2) Neighbor Advertisement; (3) 794 neighbor unreachability detection; (4) Multicast Listener Discovery; 795 (5) Address Resolution Protocol; (6) DHCP Renew/Rebind. Other ICMP 796 messages that may be processed by intermediate device may also 797 trigger the binding process. 799 The SAVI device MUST first perform DAD to check if the address has a 800 local conflict, and then send DHCP LEASEQUERY or Confirm to recover 801 binding based on DHCP server message. 803 A minimum time interval EXT_SNOOPING_INTERVAL MUST be set to limit 804 the rate of such triggering process. 806 Note that this process may not be able to avoid permanent block, in 807 case that only data packets are sent by node. Generally, this 808 mechanism is still practical, because data packet sending without 809 control plane communication is rare and suspicious in reality. Normal 810 traffic will contain control plane communication packets to help 811 traffic setup and fault diagnosis. 813 11. Filtering Specification 815 This section specifies how to use bindings to filter packets. 817 Filtering policies are different for data packet and control packet. 818 DHCP and ND messages that may cause state transit are classified into 819 control packet. Neighbor Advertisement and ARP Response are also 820 included in control packet, because the Target Address of NA and ARP 821 Response should be checked to prevent spoofing. All other packets are 822 considered to be data packets. 824 11.1. Data Packet Filtering 826 Data packets with a binding anchor which has attribute SAVI- 827 Validation MUST be checked. 829 If the source of a packet associated with its binding anchor is in 830 the FT, this packet SHOULD be forwarded; or else the packet SHOULD be 831 discarded, or alternatively the SAVI SHOULD record this violation. 833 11.2. Control Packet Filtering 835 For binding anchors with SAVI-Validation attribute: 837 Discard/record DHCPv4 Discovery with non-all-zeros source IP address. 838 Discard/record DHCPv4 Request whose source IP address is neither all 839 zeros nor a bound address in FT. 841 Discard/record DHCPv6 Request whose source is not bound with the 842 corresponding binding anchor in FT. Discard/record DHCPv6 Confirm/ 843 Solicit whose source is not a link local address bound with the 844 corresponding binding anchor in FT. The link layer address may be 845 bound based on SAVI-SLAAC solution or other solutions. 847 Discard/record other types of DHCP messages whose source is not an 848 address bound with the corresponding binding anchor. 850 Discard/record IPv6 NS and IPv4 gratuitous ARP whose source is not an 851 address bound with the corresponding binding anchor. 853 Discard/record NA and ARP Replies messages whose target address and 854 source address are not bound with the corresponding binding anchor. 856 For other binding anchors: 858 Discard DHCP Reply/Ack messages not from binding anchor with the 859 SAVI-DHCP-Trust attribute or SAVI-SAVI attribute. 861 12. Format and Delivery of Probe Messages 863 As described in section 11.1.3, the SAVI device MAY send detection 864 probes on behavior of client to determine whether the assigned 865 address is duplicated. Currently no other probes are designed in this 866 solution. 868 12.1. Duplicate Detection 870 Message Type: DAD NS, Gratuitous ARP Request 872 Format: 874 Link layer source - link layer address of host; 876 Link layer destination - For IPv6, use multicast address 877 specified in [RFC3307]; For IPv4, use broadcast address; 879 IP source - Unspecified address for IPv6; The tentative 881 address for IPv4; 883 IP destination - For IPv6, multicast address specified in 884 section 5.4.2 of [RFC4861]; For IPv4, the tentative address; 886 Delivery: 888 MUST not be delivered to the host which the SAVI device is 889 performing DAD on behavior of. 891 13. Binding Remove 893 If the lifetime of an entry with state BOUND expires, the entry MUST 894 be removed. 896 14. Handle Binding Anchor Off-link Event 898 Port DOWN event MUST be handled if switch port is used as binding 899 anchor. In more general case, if a binding anchor turns off-link, 900 this event MUST be handled. 902 Whenever a binding anchor with attribute SAVI-Validation turns down, 903 the bindings with the binding anchor MUST be kept for a short time. 905 To handle movement, if receiving DAD NS/Gra ARP request targeting at 906 the address during the period, the entry MAY be removed. 908 If the binding anchor turns on-link during the period, recover 909 bindings. It may result in some security problem, e.g., a malicious 910 node immediately associates with the binding anchor got off by a 911 previous node, and then it can use the address assigned to the 912 previous node. However, this situation is very rare in reality. 913 Authors decide not to handle this situation. 915 15. About Collision in Detection 917 The SAVI device may find a collision in detection. Some related 918 details are specified here. 920 Whether to notify the DHCP server: 922 To conform to current standard, the host should send a Decline 923 message to refuse the collision address. If the host doesn't do it, 924 it is still improper for the SAVI device to decline the address. 926 The result of detection without host aware: 928 In case the SAVI device send detection packet instead of the host, 929 the host will not be aware of the detection result. If the detection 930 succeeds, there is no problem. However, if the detection fails, the 931 packets from the host with the assigned address will be filtered out. 932 This result can be regarded as a reasonable punishment for not 933 performing duplicate detection and using a collision address. The 934 SAVI device MAY choose to notice the client that the assigned address 935 has been used, through a NA message. This mechanism is not required 936 in this solution. 938 16. Binding Number Limitation 940 It is suggested to configure some mechanism in order to prevent a 941 single node from exhausting the binding table entries on the SAVI 942 device. Either of the following mechanism is sufficient to prevent 943 such attack. 945 1. Set the upper bound of binding number for each binding anchor with 946 SAVI-Validation. 948 2. Reserve a number of binding entries for each binding anchor with 949 SAVI-Validation attribute and all binding anchors share a pool of 950 the other binding entries. 952 3. Limit DHCP Request rate per binding anchor, using the bound entry 953 number of each binding anchor as reverse indicator. 955 17. MLD Consideration 957 The SAVI device MUST join the solicited-node multicast address of the 958 tentative address whenever perform duplicate detection on behavior of 959 host. 961 18. State Restoration 963 If a SAVI device reboots accidentally or designedly, the states kept 964 in volatile memory will get lost. This may cause hosts indirectly 965 attached to the SAVI device to be broken away from the network, 966 because they can't recover bindings on the SAVI device of themselves. 967 Thus, binding entries MUST be saved into non-volatile storage 968 whenever a new binding entry changes to BOUND state or a binding with 969 state BOUND is removed in condition that this function is supported 970 by hardware. Immediately after reboot, the SAVI device MUST restore 971 binding states from the non-volatile storage. The lifetime and the 972 system time of save process MUST be stored. Then the device MUST 973 check whether the saved entries are obsolete when rebooting. 975 The possible alternatives proposed but not suitable for general cases 976 are: 978 If the SAVI device is also the DHCP relay, an alternative mechanism 979 is fetching the bindings through bulk DHCP LEASEQUERY [RFC5460]. 981 If the network enables 802.1ag, the bindings can be recovered with 982 the help of the first hop routers through snooping unicast Neighbor 983 Solicitations sent by routers based on the Neighbor Table. 985 19. Confirm Triggered Binding 987 If a binding entry is triggered by a CONFIRM message from the client, 988 no lease time will be contained in the REPLY from DHCP server. The 989 SAVI device MUST send LEASEQUERY message to get the lease time of the 990 address to complete the binding entry. If no successful LEASEQUERY- 991 REPLY is received, the binding entry SHOULD be removed. In this 992 scenario, the address is not regarded as assigned by DHCP, and it MAY 993 be bound through other SAVI solution. 995 If the confirmed address has local conflict, the Client-ID field of 996 Confirm and LEASEQUERY-REPLY MUST be compared. If they are not match, 997 the new binding entry MUST be deleted. 999 20. Consideration on Link Layer Routing Complexity 1001 An implicit assumption of this solution is that data packet must 1002 arrive at the same binding anchor of the control packet. If this 1003 assumption is not valid, this control packet based solution may fail 1004 or at least discard legitimate packet. Unfortunately, if the link 1005 layer routing between host and SAVI device is inconsistent from time 1006 to time, this assumption doesn't stand. Time consistency of link 1007 layer routing is not assured by link layer routing protocol. TRILL, a 1008 recent link layer routing protocol, is flexible and multiple link 1009 layer paths are allowed. 1011 To make the basic assumption stand, the best way is enforcing that 1012 there should be only one topology path from downstream host to the 1013 SAVI device. 1015 If the assumption doesn't stand, a better solution is requiring 1016 inter-operation between SAVI protocol and the link layer routing 1017 protocol to make SAVI protocol sensitive to the link layer routing 1018 change. This solution is above the scope of this document. 1020 21. Duplicate Bindings of Same Address 1022 Note that the same address may be bound with multiple binding anchors, 1023 only if the binding processes are finished on each binding anchor 1024 successfully respectively. 1026 This mechanism is designed in consideration that a node may move on 1027 the local ink, and a node may have multiple binding anchors. 1029 Note that the local link movement scenario is not handled perfectly. 1030 The former binding may not be removed, unless the node is directly 1031 attached to the SAVI device. The nodes sharing the same former 1032 binding anchor of the moving node have the ability to use its address. 1034 22. Constants 1036 MAX_DHCP_RESPONSE_TIME 120s 1038 MAX_ARP_PREPARE_DELAY Default 1s but configurable 1040 MAX_ARP_DELAY Default 1s but configurable 1042 MAX_DAD_PREPARE_DELAY Default 1s but configurable 1044 MAX_DAD_DELAY Default 1s but configurable 1045 BIND_RECOVERY_INTERVAL Device capacity depended and configurable 1047 23. Security Considerations 1049 For prefix level granularity filtering is the basis of host level 1050 granularity filtering, to learn and configure correct prefix is of 1051 great importance to this mechanism. Thus, it's important to keep RA 1052 and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a 1053 mechanism to improve the security of RA message. 1055 24. IANA Considerations 1057 There is no IANA consideration currently. 1059 25. References 1061 25.1. Normative References 1063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1064 Requirement Levels", BCP 14, RFC 2119, March 1997. 1066 25.2. Informative References 1068 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 1069 March 1997. 1071 [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast 1072 Addresses", RFC3307, August 2002. 1074 [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6 1075 (DHCPv6)", RFC3315, July 2003. 1077 [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration 1078 Protocol (DHCP) Leasequery", RFC4388, February 2006. 1080 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 1081 "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September 2007. 1083 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 1084 Autoconfiguration", RFC4862, September, 2007. 1086 [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6 1087 Leasequery", RFC5007, September 2007. 1089 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 1090 July 2008. 1092 [IP Source Guard] Cisco, "Network Security Technologies and 1093 Solutions", chapter 7, Cisco Press, May 20, 2008. 1095 [draft-baker-savi-one-implementation-approach] F. Baker, "An 1096 implementation approach to Source Address Validation", 1097 draft-baker-savi-one-implementation-approach-00. 1099 26. Acknowledgments 1101 Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik 1102 Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David 1103 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg 1104 Daley, Joel M. Halpern, Mikael Abrahamsson, John Kaippallimalil and Tao 1105 Lin for their valuable contributions. 1107 Authors' Addresses 1109 Jun Bi 1110 CERNET 1111 Network Research Center, Tsinghua University 1112 Beijing 100084 1113 China 1114 Email: junbi@cernet.edu.cn 1116 Jianping Wu 1117 CERNET 1118 Computer Science, Tsinghua University 1119 Beijing 100084 1120 China 1121 Email: jianping@cernet.edu.cn 1123 Guang Yao 1124 CERNET 1125 Network Research Center, Tsinghua University 1126 Beijing 100084 1127 China 1128 Email: yaog@netarchlab.tsinghua.edu.cn 1130 Fred Baker 1131 Cisco Systems 1132 Email: fred@cisco.com 1134 27. Change Log 1136 From 02 to 03: Section 12, data trigger and counter trigger are 1137 combined to binding recovery process. The expression "one of MUST" is 1138 changed to "conditional MUST. Conditions related with the 1139 implementation are specified. Related constants are changed in 1140 section 26." 1142 Main changes from 03 to 04: 1144 - Section "Prefix configuration" is removed. 1146 - Section "Supplemental binding process" is modified in 1147 requirement level. 1149 - Sub-section 9.1 "Rationale" is added. 1151 - Section "Filtering during Detection" is removed. 1153 - Section "Handling layer 2 path change" is changed to 1154 "Consideration on Link layer routing complexity" 1156 - Section "Background and related protocols" is removed.