idnits 2.17.1 draft-ietf-savi-dhcp-03.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 11 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 (May 28, 2010) is 5081 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: 'BCP38' is mentioned on line 172, but not defined == Missing Reference: 'RFC4429' is mentioned on line 959, but not defined == Missing Reference: 'RFC5460' is mentioned on line 1008, but not defined == Missing Reference: 'RFC3736' is mentioned on line 1016, but not defined ** Obsolete undefined reference: RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 9 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: November 2010 Tsinghua Univ. 5 F. Baker 6 Cisco 7 May 28, 2010 9 SAVI Solution for DHCP 10 draft-ietf-savi-dhcp-03.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 November 28, 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 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in 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 IP addresses. 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. Background and Related Protocols............................. 4 78 5. Terminology ................................................. 5 79 6. Conceptual Data Structures................................... 5 80 6.1. Binding State Table (BST)............................... 5 81 6.2. Filtering Table (FT).................................... 6 82 7. Binding States Description................................... 6 83 8. DHCP Scenario ............................................... 7 84 9. Anchor Attributes ........................................... 7 85 9.1. SAVI-Validation Attribute............................... 7 86 9.2. SAVI-DHCP-Trust Attribute............................... 8 87 9.3. SAVI-SAVI Attribute..................................... 8 88 9.4. Optional Attributes..................................... 8 89 10. Prefix Configuration........................................ 8 90 11. Binding Set Up ............................................. 9 91 11.1. Process of Control Packet Snooping..................... 9 92 11.1.1. Initialization.................................... 9 93 11.1.1.1. Trigger Event................................ 9 94 11.1.1.2. Event Validation............................. 9 95 11.1.1.3. Following Actions............................ 9 96 11.1.2. From START to LIVE............................... 11 97 11.1.2.1. Trigger Event............................... 11 98 11.1.2.2. Event Validation............................ 11 99 11.1.2.3. Following Actions........................... 11 100 11.1.3. From LIVE to DETECTION........................... 12 101 11.1.3.2. Event Validation............................ 12 102 11.1.3.3. Following Actions........................... 12 103 11.1.4. From DETECTION to BOUND.......................... 12 104 11.1.4.1. Trigger Event............................... 12 105 11.1.4.2. Following Actions........................... 13 106 11.1.5. Binding Deletion in DETECTION State.............. 13 107 11.1.5.1. Trigger Event............................... 13 108 11.1.5.2. Following Actions........................... 13 109 11.1.6. After BOUND...................................... 13 110 11.2. State Machine of DHCP Snooping........................ 14 111 12. Supplemental Binding Process............................... 15 112 12.1. Data Packet based Binding Process..................... 16 113 12.1.1. SAVI-DataBased Attribute......................... 16 114 12.1.2. Data Packet based Binding Process................ 16 115 12.2. External Control Packet Snooping Process.............. 18 116 12.2.1. SAVI-ExtSnooping Attribute....................... 18 117 12.2.2. Extended Control Packet Snooping................. 18 118 13. Filtering Specification.................................... 18 119 13.1. Data Packet Filtering................................. 19 120 13.2. Control Packet Filtering.............................. 19 121 14. Format and Delivery of Probe Messages...................... 20 122 14.1. Duplicate detection................................... 20 123 15. Binding Remove ............................................ 20 124 16. Handle Anchor Off-link event............................... 20 125 17. About Collision in Detection............................... 21 126 17.1. Whether to Notify the DHCP Server..................... 21 127 17.2. The Result of Detection without Host Aware............ 21 128 18. Filtering during Detection................................. 21 129 19. Binding Number Limitation.................................. 22 130 20. MLD Consideration ......................................... 22 131 21. State Restoration ......................................... 22 132 22. Stateless DHCP ............................................ 23 133 23. Confirm Triggered Binding.................................. 23 134 24. Handle Layer 2 Path Change................................. 23 135 25. Duplicate Bindings on Same Address......................... 23 136 26. Constants ................................................. 24 137 27. Security Considerations.................................... 24 138 28. IANA Considerations........................................ 24 139 29. References ................................................ 24 140 29.1. Normative References.................................. 24 141 29.2. Informative References................................ 24 142 30. Acknowledgments ........................................... 25 144 1. Introduction 146 This document describes the procedure for creating bindings between 147 DHCP assigned addresses and an anchor (refer to [savi-framework]). 148 Other related details about this procedure are also specified in this 149 document. 151 These bindings can be used to filter packets with forged IP addresses. 152 How to use these bindings is specified in [savi-framework], depending 153 on the environment and configuration. The definition and examples of 154 anchor is also specified in [savi-framework]. 156 The binding process is inspired by the work of IP Source Guard [IP 157 Source Guard]. This solution differs from IP Source Guard in the 158 specification for collision detection, which is essential in 159 environments with multiple address assignment methods. There are also 160 other differences in details. 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 a 171 host level source IP address validation granularity, as a supplement 172 to BCP38 [BCP38]. This mechanism is deployed on the access device 173 (including access switch, wireless access point/controller, etc), and 174 performs mainly DHCP snooping to set up bindings between DHCP 175 assigned IP addresses and corresponding anchors. The bindings can be 176 used to validate the source address in the packets. 178 4. Background and Related Protocols 180 This mechanism is an instance of a SAVI [savi-framework] solution, 181 specialized for addresses assigned using the DHCP protocol. 183 Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic 184 Host Configuration Protocol version 6 [RFC3315] specify the 185 procedures for providing a client with assigned address and other 186 configuration information from a DHCP server. If a client gets an 187 address through the DHCP protocol, the address should be regarded as 188 a potential "authorized" or "registered" address of the client. 190 In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as 191 another address assignment mechanism. A node can use this mechanism 192 to auto-configure an IPv6 address. A DHCPv6 client may use a 193 stateless address to send message to DHCP server. Even in a DHCPv6- 194 only environment, a node must assign its link-local address through 195 this mechanism. [RFC4862] clearly requires that duplicated address 196 detection must be performed on any IPv6 address, including DHCPv6 197 address. 199 [RFC4861] specifies the Neighbor Discovery protocol, which is an 200 essential part of IPv6 address assignment. 202 [RFC5227] specifies the procedure to detect IPv4 address collision. 203 It is not required currently. However, this feature is useful to 204 determine the uniqueness of an IPv4 address on the link. Considering 205 not all the operating systems support [RFC5227], this solution is 206 designed to be compatible with operating systems not complying with 207 [RFC5227]. 209 5. Terminology 211 Main terms used in this document are described in [savi-framework], 212 [RFC2131] and [RFC3315]. 214 6. Conceptual Data Structures 216 This section describes the possible conceptual data structures used 217 in this mechanism. 219 Two main data structures are used to record bindings and their states 220 respectively. There is redundancy between the two structures, for the 221 consideration of separation of data plane and control plane. 223 6.1. Binding State Table (BST) 225 This table contains the state of binding between source address and 226 anchor. Entries are keyed on the anchor and source IP address. Each 227 entry has a lifetime field recording the remaining lifetime of the 228 entry, a state field recording the state of the binding and a field 229 recording other information. 231 +---------+----------+-------+-----------+-------+ 232 | Anchor | Address | State | Lifetime |Other | 233 +---------+----------+-------+-----------+-------+ 234 | A | IP_1 | Bound | 65535 | | 235 +---------+----------+-------+-----------+-------+ 236 | A | IP_2 | Bound | 10000 | | 237 +---------+----------+-------+-----------+-------+ 238 | B | IP_3 |_Start | 1 | | 239 +---------+----------+-------+-----------+-------+ 240 Figure 1 Instance of BST 242 6.2. Filtering Table (FT) 244 This table contains the bindings between anchor and address, keyed on 245 anchor. This table doesn't contain any state of the binding. This 246 table is only used to filter packets. An Access Control List can be 247 regarded as a practical instance of this table. 249 +---------+----------+ 250 |Anchor |Address | 251 +---------+----------+ 252 |A |IP_1 | 253 +---------+----------+ 254 |A |IP_2 | 255 +---------+----------+ 256 Figure 2 Instance of FT 258 7. Binding States Description 260 This section describes the binding states of this mechanism. 262 START A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 263 Solicitation with Rapid Commit option) has been received from host, 264 and it may trigger a new binding. 266 LIVE A DHCP address has been acknowledged by a DHCP server. 268 DETECTION A gratuitous ARP or Duplicate Address Detection NSOL 269 has been sent by the host (or the SAVI device). 271 BOUND The address has passed duplicate detection and 272 it is bound with the anchor. 274 8. DHCP Scenario 276 Figure 3 shows the main elements in a DHCP enabled network. At least 277 one DHCP server MUST be deployed in the network, and DHCP relay MAY 278 be used to relay message between client and server. Other address 279 assignment mechanisms may be also used in such network. 281 +--------+ 282 | DHCP | 283 | Server | 284 +-------,+ 285 | 286 | 287 | 288 +----'-----+ 289 | SAVI | 290 | Device | 291 +-/------/-+ 292 | | 293 +----\-+ +\-----+ 294 |DHCP | |Client| 295 |Relay | | | 296 +------+ +------+ 297 Figure 3 DHCP Scenario 299 9. Anchor Attributes 301 This section specifies the anchor attributes involved in this 302 mechanism. 304 Anchor is defined in the [savi-framework]. Attribute of each anchor 305 is configurable. In default, anchor has no attribute. An anchor MAY 306 be configured to have one or more compatible attributes. However, an 307 anchor MAY have no attribute. 309 If an anchor has no attribute, server type DHCP message from this 310 anchor MUST be dropped. However, other packets SHOULD NOT be dropped. 312 9.1. SAVI-Validation Attribute 314 If and only if source address validation must be performed on the 315 traffic from an anchor, this anchor MUST be set to have SAVI- 316 Validation attribute. The filtering process on anchor with such 317 attribute is described in section 13. 319 9.2. SAVI-DHCP-Trust Attribute 321 If and only if an anchor is associated with a trustable DHCP 322 server/relay, it SHOULD be set to have this attribute. 324 If DHCP is used to assign address in the network, there MUST be at 325 least one anchor with this attribute. DHCP Reply message not coming 326 from such ports MUST be dropped. 328 9.3. SAVI-SAVI Attribute 330 If and only if an anchor is associated with another SAVI device, it 331 SHOULD be set to have this attribute. All traffic from anchor with 332 this attribute will be forwarded without check. 334 This attribute can also be set on other anchors if the administrator 335 decides not to validate the traffic from the anchor. Note that DHCP 336 server message and router message will also be trusted. 338 This attribute is mutually exclusive with SAVI-Validation. 340 9.4. Optional Attributes 342 Section 12 describes some optional attributes. At least one of these 343 attributes MUST be implemented. 345 10. Prefix Configuration 347 In DHCP scenario, address advertised by DHCP server should be 348 believed in. However, in this solution, a node shares the same anchor 349 as the DHCP server can disguise as the DHCP server and offer the 350 client incorrect configuration information. Without fully deployment 351 of SAVI, this problem is difficult to solve. Thus, it is SUGGESTED 352 that correct address prefix should be configured, and DHCP server 353 message which assigns address out of the scope should be dropped. 354 This mechanism can ensure the client can at least get an address with 355 proper prefix. 357 The SAVI device enabled this solution SHOULD set allowed prefix 358 through RA snooping, DHCP-PD protocol, or manual configuration. 360 There is no need to explicitly present these prefix scopes. But these 361 restrictions SHOULD be used as premier check in binding set up. 363 Refer to security consideration for other discussions. 365 11. Binding Set Up 367 This section specifies the procedure of setting up bindings based on 368 control packet snooping. The binding procedure specified here is 369 exclusively designed for anchor with SAVI-Validation attribute. 371 11.1. Process of Control Packet Snooping 373 11.1.1. Initialization 375 A binding entry is initialized in this step. 377 11.1.1.1. Trigger Event 379 A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with 380 Rapid Commit option is received. 382 Or a DHCP Reply is received from anchor with SAVI-DHCP-Trust 383 attribute. Note that vulnerability may be caused by DHCP Reply 384 triggered initialization. The binding of assigned address and anchor 385 may be threatened if the binding mechanism between anchor and link 386 layer address is not secure. If one of the following conditions is 387 satisfied, the security can be ensured. 389 1. Option 82 is used to keep anchor in DHCP Request and Reply, or 391 2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or 393 3. The mapping table from MAC to anchor is secure. 395 It is SUGGESTED not to initialize a binding based on DHCP Reply, 396 until the associated mechanism is also implemented. 398 11.1.1.2. Event Validation 400 The SAVI device checks current BST as follows: 402 1. Whether the limitation on binding entry number of this anchor will 403 be exceeded if a new entry is triggered. 405 11.1.1.3. Following Actions 407 If the check fails, the triggering message SHOULD be discarded. This 408 event MAY be announced on console interface. 410 If the check is passed: 412 If the triggering message is DHCP Request/Confirm/Solicitation with 413 Rapid Commit Option: 415 The SAVI device MUST forward the message. 417 The SAVI device MUST generate an entry for the anchor in the Binding 418 State Table (BST) and set the state field to START. The lifetime of 419 this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The Transaction ID 420 (Refer to Section 2 in [RFC2131] and Section 4.2 in [RFC3315]) field 421 of the request packet SHOULD be recorded in the entry. 423 +---------+----------+-------+-----------------------+-------+ 424 | Anchor | Address | State | Lifetime |Other | 425 +---------+----------+-------+-----------------------+-------+ 426 | A | | START |MAX_DHCP_RESPONSE_TIME | TID | 427 +---------+----------+-------+-----------------------+-------+ 428 Figure 4 Binding entry in BST on client triggered initialization 430 The TID is kept as a mediator of assigned address and the anchor of 431 requesting node, to assure that the assigned address can be bound 432 with anchor secure. 434 If the triggering message is DHCP Reply: 436 The SAVI device MUST deliver the message to the destination. 438 The SAVI device MUST generate a new entry in BST and FT. The anchor 439 in entry is looked up based on the destination link layer address, 440 from mapping table from link layer address to anchor (e.g., the MAC- 441 Port mapping table in case that port is used as anchor). The state of 442 the corresponding entry is set to be LIVE. The lifetime of the entry 443 MUST be set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY 444 respectively. The lease time MUST be recorded in the entry. 446 +---------+----------+-------+------------------------+-------+ 447 | Anchor | Address | State | Lifetime |Other | 448 +---------+----------+-------+------------------------+-------+ 449 | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | 450 | | | |MAX_DAD_PREPARE_DELAY | Time | 451 +---------+----------+-------+------------------------+-------+ 452 Figure 5 Binding entry in BST on Reply triggered initialization 453 +---------+----------+ 454 |Anchor |Address | 455 +---------+----------+ 456 |A |Addr | 457 +---------+----------+ 458 Figure 6 Binding entry in FT on Reply triggered initialization 460 11.1.2. From START to LIVE 462 11.1.2.1. Trigger Event 464 A DHCPv4 DHCPACK or DHCPv6 REPLY message is received from SAVI-DHCP- 465 Trust anchor. 467 11.1.2.2. Event Validation 469 The SAVI device checks the message and BST as follows: 471 1. Whether there exists an entry in the BST with corresponding TID in 472 the START state. 474 11.1.2.3. Following Actions 476 If the check fails, the message may be used to trigger binding 477 initialization, specified in section 11.1.1. 479 If the check is passed: 481 The SAVI device MUST deliver the message to the destination. 483 The state of the corresponding entry is changed to be LIVE. The 484 lifetime of the entry MUST be set to be MAX_ARP_PREPARE_DELAY or 485 MAX_DAD_PREPARE_DELAY respectively. The lease time MUST be recorded 486 in the entry. 488 +---------+----------+-------+------------------------+-------+ 489 | Anchor | Address | State | Lifetime |Other | 490 +---------+----------+-------+------------------------+-------+ 491 | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | 492 | | | |MAX_DAD_PREPARE_DELAY | Time | 493 +---------+----------+-------+------------------------+-------+ 494 Figure 7 From START to LIVE 496 A corresponding entry MUST also be generated in FT. 498 11.1.3. From LIVE to DETECTION 500 11.1.3.1. Trigger Event 502 A gratuitous ARP Request or Duplicate Address Detection Neighbor 503 Solicitation is received from anchor. Or a timeout event of an entry 504 with state LIVE happens. 506 11.1.3.2. Event Validation 508 The SAVI device checks the message and BST as follows: 510 1. Whether the Target IP Address field of the ARP Request or Neighbor 511 Solicitation has been bound with the corresponding anchor in BST 512 or FT, and the state in BST must be LIVE. 514 11.1.3.3. Following Actions 516 If the check fails because of the Target Address is not in BST, the 517 packet MUST be discarded. If the entry state is not LIVE, the message 518 MUST be forwarded. 520 If the check is passed: 522 If the event is triggered by client, SAVI device MUST set the state 523 of the corresponding entry to be DETECTION. 525 +---------+----------+-----------+-----------------+-------+ 526 | Anchor | Address | State | Lifetime |Other | 527 +---------+----------+-----------+-----------------+-------+ 528 | A | Addr | DETECTION |MAX_ARP_DELAY or | Lease | 529 | | | |MAX_DAD_DELAY | Time | 530 +---------+----------+-----------+-----------------+-------+ 531 Figure 8 From LIVE to DETECTION 533 If the triggering event is timeout event, the SAVI device MUST send 534 one or more ARP Request or DAD NSOL, with Target Address set to the 535 recorded address in the entry. The format of detection packet is 536 specified in section 14. The state MUST be changed to DETECTION. The 537 lifetime of the entry MUST be set to be MAX_ARP_DELAY or 538 MAX_DAD_DELAY respectively. 540 11.1.4. From DETECTION to BOUND 542 11.1.4.1. Trigger Event 544 A timeout event of an entry with state DETECTION occurs. 546 11.1.4.2. Following Actions 548 If a timeout event of an entry with state DETECTION occurs, set the 549 state of the entry to be BOUND. The lifetime of the entry is set to 550 be the Lease time acknowledged by DHCP server. 552 +---------+----------+-----------+----------------+-------+ 553 | Anchor | Address | State | Lifetime |Other | 554 +---------+----------+-----------+----------------+-------+ 555 | A | Addr | BOUND | Lease time | | 556 +---------+----------+-----------+----------------+-------+ 557 Figure 9 Binding entry in BST on finalization 559 If an ARP Response or NA for an address in BST with state DETECTION 560 is received, remove the corresponding entry in BST and FT. The ARP 561 Response or NA MUST be delivered to the client. 563 11.1.5. Binding Deletion in DETECTION State 565 11.1.5.1. Trigger Event 567 An ARP Response or NA/DAD NS targeting at an address in BST with 568 state DETECTION is received from a different anchor. 570 11.1.5.2. Following Actions 572 If ARP Response or NA is received from anchor with SAVI-Validation 573 attribute, but the address is not bound with the anchor, the packet 574 MUST be dropped. If DAD NS is received from anchor with SAVI- 575 Validation, the message MUST be delivered to the former detecting 576 node. The binding SHOULD be removed. 578 If the message is received from anchor with SAVI-Validation attribute, 579 and the address is bound with anchor, the message MUST be delivered 580 to the detecting node, and the binding MUST be removed. 582 If the message is received from anchor without SAVI-Validation 583 attribute, the message MUST be delivered to the detecting node. The 584 binding SHOULD be removed. 586 11.1.6. After BOUND 588 Once a binding entry is set up for an anchor, the binding will be 589 used to filter packet with the anchor, as specified in section 13. On 590 the other hand, DHCP messages with the anchor will affect the binding. 591 The binding is also affected by DHCP server message toward the anchor. 593 Before a DHCP message is found that it may change the corresponding 594 binding, its validity MUST be checked as described in section 13.2. 596 Whenever a DHCP Decline is received, delete the corresponding entry 597 in BST and FT. 599 Whenever a DHCP Release is received, if the state of the entry is 600 BOUND, delete the entry in BST and FT. 602 If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is 603 received from the server, set lifetime of the entry in BST to be the 604 new lease time. 606 If the lifetime of an entry with state BOUND expires, delete the 607 entry in BST and Filter Table. 609 Switch port down event (or in a more general expression, anchor turns 610 off-link) will change the corresponding entry, as described in 611 section 16. 613 11.2. State Machine of DHCP Snooping 615 The main state transits are listed as follows. Note that precondition 616 of state transit is not included. Triggering message/event must 617 satisfy the preconditions before changing the state. 619 State Message/Event Action Next State 621 - REQ/CFM/SOL+RC Generate entry START 623 *- ACK/RPL Generate entry with lease LIVE 625 START ACK/RPL Record lease time LIVE 627 START Timeout Remove entry - 629 LIVE Gra ARP REQ/DAD NS - DETECTION 631 LIVE DECLINE/RELEASE Remove entry - 633 LIVE Timeout Send probe DETECTION 635 DETECTION Timeout - BOUND 637 DETECTION ARP RES/DAD NS/NA Remove entry - 639 DETECTION DECLINE/RELEASE Remove entry - 640 BOUND RELEASE/DECLINE Remove entry - 642 BOUND Timeout Remove entry - 644 BOUND RPL with REN/REB Set new lifetime BOUND 646 *: optional but NOT SUGGESTED. 648 REQ: DHCP REQUEST 650 CFM: DHCP CONFIRM 652 SOL: DHCP SOLICITATION 654 RC: Rapid Commit option 656 ACK: DHCP ACKNOWLEDGEMENT 658 RPL: DHCP REPLY 660 Probe Gratuitous ARP REQUEST or Duplicate Address Detection Neighbor 661 Solicitation, described in section 11.1.3 and section 14. 663 Gra ARP REQ: Gratuitous ARP REQUEST 665 ARP RES: ARP RESPONSE 667 DAD NS: Duplicate Address Detection Neighbor Solicitation 669 DAD NA: Neighbor Advertisement targeting at a tentative address 671 DECLINE: DHCP DECLINE 673 RELEASE: DHCP RELEASE 675 REN: DHCP RENEW 677 REB: DHCP REBOUND 679 12. Supplemental Binding Process 681 Supplemental binding process is designed to cover conditions that 682 packet is sent by node without previous DHCP procedure sensed by the 683 SAVI device. A typical situation is that the layer-2 path changes 684 after the binding has been set up, then the node will send packet to 685 a different port with the bound port. Another scenario is that a node 686 moves on the local link without re-configuration process. In DHCP 687 scenario, till this document is finished, layer-2 path change and 688 local link movement are the only two events that must be handled 689 through this supplemental binding process. 691 This process is designed to avoid permanent legitimate traffic 692 blocking. It is not supposed to set up a binding whenever a data 693 packet with unbound source address is received. Generally, longer 694 time and more packets are needed to trigger supplemental binding 695 processes. 697 For implementations that will face the above problem: 699 1. Binding Recovery Process is a conditional MUST. If an 700 implementation has sufficient capability to handle the potential 701 overhead and security risk, and has ability to meet the specified 702 requirements in hardware which may exceed general implementation 703 practice, and the market of this implementation clearly requires 704 this process, this process MUST be implemented. 706 2. Extended Control Packet Snooping Process is a MUST. 708 Other techniques may be prudently chosen as alternative if found to 709 have equivalent or even better function to avoid permanently blocking 710 after discussion, implementation and deployment. 712 12.1. Binding Recovery Process 714 12.1.1. SAVI-BindRecovery Attribute 716 If binding recovery process is implemented as a supplemental binding 717 process, an additional anchor attribute, named SAVI-BindRecovery, 718 MUST be implemented. 720 This attribute is mutually exclusive with SAVI-SAVI. 722 Data based binding process will be performed on the anchor with such 723 attribute. 725 12.1.2. Bind Recovery Process 727 Refer to [draft-baker-savi-one-implementation-approach] for a 728 detailed implementation suggestion. The process specified here can 729 only be enabled in condition that implementation can meet the 730 specified hardware requirements described in [draft-baker-savi-one- 731 implementation-approach]. 733 If an anchor is set to have SAVI-BindRecovery attribute, a FIFO queue 734 or register MUST be used to save recently filtered packets. The SAVI 735 device will fetch packet from the queue/register to check the source 736 address can be used by corresponding client on the local link with 737 limited rate: 739 1. If the address has a local conflict, meaning the DAD on the 740 address fails, the packet MUST be discarded. If the address is not 741 being used, go to the next step. 743 2. 745 IPv4 address: 747 Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all 748 DHCPv4 servers for IPv4 address or a configured server address. The 749 server addresses may be discovered through DHCPv4 Discovery. If no 750 DHCPLEASEACTIVE message is received, discard the packet; otherwise 751 generate a new binding entry for the address. 753 IPv6 address: 755 Send a LEASEQUERY [RFC5007] message querying by IP address to 756 All_DHCP_Relay_Agents_and_Servers multicast address or a configured 757 server address. If no successful LEASEQUERY-REPLY is received, 758 discard the packet; otherwise generate a new binding entry for the 759 address. The SAVI device may repeat this process if a LEASEQUERY- 760 REPLY with OPTION_CLIENT_LINK is received, in order to set up binding 761 entries for all the address of the client. 763 This process MUST be rate limited to avoid Denial of Services attack 764 against the SAVI device itself. A constant BIND_RECOVERY_INTERVAL is 765 used to control the frequency. Two data based processes on one anchor 766 must have a minimum interval time BIND_RECOVERY_INTERVAL. This 767 constant SHOULD be configured prudently to avoid Denial of Services. 769 This process is not strict secure. The node with SAVI-BindRecovery 770 anchor has the ability to use the address of an inactive node, which 771 doesn't reply to the DAD probe. 773 In case that the SAVI device is a pure layer-2 device, DHCP Confirm 774 MAY be used to replace the DHCP LEASEQUERY. The security degree may 775 degrade for the address may not be assigned by DHCP server. 777 This process may fail if any DHCP server doesn't support LEASEQUERY. 779 12.2. External Control Packet Snooping Process 781 12.2.1. SAVI-ExtSnooping Attribute 783 An additional anchor attribute, named SAVI-ExSnooping, MUST be 784 implemented. 786 This attribute is mutually exclusive with SAVI-SAVI. 788 Extended control packet snooping process will be performed on the 789 anchor with such attribute. 791 12.2.2. Extended Control Packet Snooping 793 In this snooping process, other than DHCP initialization messages, 794 other types of control packets processed by processor of SAVI device, 795 if the source address is not bound, may trigger the device to perform 796 binding process. 798 The control messages that MUST be processed include: (1) address 799 resolution Neighbor Solicitation; (2) Neighbor Advertisement; (3) 800 neighbor unreachability detection; (4) Multicast Listener Discovery; 801 (5) Address Resolution Protocol; (6) DHCP Renew/Rebind. Other ICMP 802 messages that may be processed by intermediate device may also 803 trigger the binding process. 805 The SAVI device MUST first perform DAD to check if the address has a 806 local conflict, and then send DHCP LEASEQUERY or Confirm to recover 807 binding based on DHCP server message. 809 A minimum time interval EXT_SNOOPING_INTERVAL MUST be set to limit 810 the rate of such triggering process. 812 Note that this process may not be able to avoid permanent block, in 813 case that only data packets are sent by node. Generally, this 814 mechanism is still practical, because data packet sending without 815 control plane communication is rare and suspicious in reality. Normal 816 traffic will contain control plane communication packets to help 817 traffic setup and fault diagnosis. 819 13. Filtering Specification 821 This section specifies how to use bindings to filter packets. Because 822 the Filtering Table is an allow-table, packet with source address not 823 in the table will be filtered. Considering DHCP may coexist with 824 other address assignment methods, e.g., Stateless Auto-configuration, 825 the specification made here is based on the assumption that other 826 SAVI solutions will also use BST and FT to keep bindings and filter 827 packets. Otherwise this solution will conflict with other SAVI 828 solutions. 830 Filtering policies are different for data packet and control packet. 831 DHCP and ND messages that may cause state transit are classified into 832 control packet. Neighbor Advertisement and ARP Response are also 833 included in control packet, because the Target Address of NA and ARP 834 Response should be checked to prevent spoofing. All other packets are 835 considered to be data packets. 837 13.1. Data Packet Filtering 839 Data packets with an anchor which has attribute SAVI-Validation MUST 840 be checked. 842 If the source of a packet associated with its anchor is in the FT, 843 this packet SHOULD be forwarded; or else the packet SHOULD be 844 discarded, or alternatively the SAVI SHOULD record this violation. 846 13.2. Control Packet Filtering 848 For anchors with SAVI-Validation attribute: 850 The source address of DHCPv4 Discovery MUST be set to all zeros. The 851 source address of DHCPv4 Request MUST be set to all zeros or a bound 852 address in FT. 854 The source address of DHCPv6 Request MUST be an address associated 855 with the corresponding anchor in FT. The source address of DHCPv6 856 Confirm MUST be a link local address associated with the 857 corresponding anchor in FT. The source address of DHCPv6 Solicit MUST 858 be a link layer address bound with corresponding anchor. The link 859 layer address MAY be bound based on SAVI-SLAAC solution or other 860 solutions. 862 The source address of other types of DHCP messages MUST be an address 863 bound with the corresponding anchor. 865 The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the 866 check on FT. 868 The target address and source address in all the Neighbor 869 Advertisement packets and ARP replies MUST also pass the checks on FT. 871 For other anchors: 873 All DHCP Reply/Ack packets MUST be from anchor with the SAVI-DHCP- 874 Trust attribute. 876 14. Format and Delivery of Probe Messages 878 As described in section 11.1.3, the SAVI device MAY send detection 879 probes on behavior of client to determine whether the assigned 880 address is duplicated. Currently no other probes are designed in this 881 solution. 883 14.1. Duplicate detection 885 Message Type: DAD NS, Gratuitous ARP Request 887 Format: 889 Link layer source - link layer address of host; 891 Link layer destination - For IPv6, use multicast address 892 specified in [RFC3307]; For IPv4, use broadcast address; 894 IP source - Unspecified address for IPv6; The tentative 896 address for IPv4; 898 IP destination - For IPv6, multicast address specified in 899 section 5.4.2 of [RFC4861]; For IPv4, the tentative address; 901 Delivery: 903 MUST not be delivered to the host which the SAVI device is 904 performing DAD on behavior of. 906 15. Binding Remove 908 If the lifetime of an entry with state BOUND expires, the entry MUST 909 be removed. 911 16. Handle Anchor Off-link event 913 Port DOWN event MUST be handled if switch port is used as anchor. In 914 more general case, if an anchor turns off-link, this event MUST be 915 handled. 917 Whenever an anchor with attribute SAVI-Validation turns down, the 918 bindings with the anchor MUST be kept for a short time. 920 To handle movement, if receiving DAD NS/Gra ARP request targeting at 921 the address during the period, the entry MAY be removed. 923 If the anchor turns on-link during the period, recover bindings. It 924 may result in some security problem, e.g., a malicious node 925 immediately associates with the anchor got off by a previous node, 926 and then it can use the address assigned to the previous node. 927 However, this situation is very rare in reality. Authors decide not 928 to handle this situation. 930 17. About Collision in Detection 932 The SAVI device may receive a response in detection. Some related 933 details are specified here. 935 17.1. Whether to Notify the DHCP Server 937 It is unnecessary for the SAVI device to notify the DHCP server, 938 because the host will send a DECLINE message to it once it finds the 939 advertised address is conflict. 941 17.2. The Result of Detection without Host Aware 943 In case the SAVI device send detection packet instead of the host, 944 the host will not be aware of the detection result. If the detection 945 succeeds, there is no problem. However, if the detection fails, the 946 packets from the host with the assigned address will be filtered out. 947 This result can be regarded as a reasonable punishment for not 948 performing duplicate detection and using a collision address. The 949 SAVI device MAY choose to notice the client that the assigned address 950 has been used, through a NA message. This mechanism is not required 951 in this solution. 953 18. Filtering during Detection 955 In this mechanism, whenever the DHCP server replies an address, this 956 address will be allowed immediately even before duplicate detection 957 is completed. This design is in consideration of a host may start to 958 send packets straightway without detection. Also this design is to be 959 compatible with optimistic DAD [RFC4429]. 961 However, this feature may allow an attacker to send quantities of 962 packets with source addresses already assigned to other nodes. A 963 practical solution for this vulnerability is configuring the address 964 pool and allocation algorithm of the DHCP server carefully. 966 19. Binding Number Limitation 968 It is suggested to configure some mechanism in order to prevent a 969 single node from exhausting the binding table entries on the SAVI 970 device. Either of the following mechanism is sufficient to prevent 971 such attack. 973 1. Set the upper bound of binding number for each anchor with SAVI- 974 Validation. 976 2. Reserve a number of binding entries for each anchor with SAVI- 977 Validation attribute and all anchors share a pool of the other 978 binding entries. 980 3. Limit DHCP Request rate per anchor, using the bound entry number 981 of each anchor as reverse indicator. 983 20. MLD Consideration 985 The SAVI device MUST join the tentative address multicast group 986 whenever perform duplicate detection on behavior of host. 988 21. State Restoration 990 If a SAVI device reboots accidentally or designedly, the states kept 991 in volatile memory will get lost. This may cause hosts indirectly 992 attached to the SAVI device to be broken away from the network, 993 because they can't recover bindings on the SAVI device of themselves. 994 Thus, binding entries MUST be saved into non-volatile storage 995 whenever a new binding entry changes to BOUND state or a binding with 996 state BOUND is removed in condition that this function is supported 997 by hardware, unless other alternatives specified here is implemented. 999 If binding is saved into non-volatile memory, immediately after 1000 reboot, the SAVI device MUST restore binding states from the non- 1001 volatile storage. The lifetime and the system time of save process 1002 MUST be stored. Then the device MUST check whether the saved entries 1003 are obsolete when rebooting. 1005 The possible alternatives are: 1007 If the SAVI device is also the DHCP relay, an alternative mechanism 1008 is fetching the bindings through bulk DHCP LEASEQUERY [RFC5460]. 1010 If the network enables 802.1ag, the bindings can be recovered with 1011 the help of the first hop routers through snooping unicast Neighbor 1012 Solicitations sent by routers based on the Neighbor Table. 1014 22. Stateless DHCP 1016 In a stateless DHCP scenario [RFC3736], DHCP is used to configure 1017 other parameters but rather IP address. The address of the client 1018 SHOULD be bound based on other SAVI solutions, but rather this 1019 solution designed for stateful DHCP. 1021 23. Confirm Triggered Binding 1023 If a binding entry is triggered by a CONFIRM message from the client, 1024 no lease time will be contained in the REPLY from DHCP server. The 1025 SAVI device MUST send LEASEQUERY message to get the lease time of the 1026 address to complete the binding entry. If no successful LEASEQUERY- 1027 REPLY is received, the binding entry SHOULD be removed. In this 1028 scenario, the address is not regarded as assigned by DHCP, and it may 1029 be bound through other SAVI solution. 1031 If the confirmed address has local conflict, the Client-ID field of 1032 Confirm and LEASEQUERY-REPLY MUST be compared. If they are not match, 1033 the new binding entry MUST be deleted. 1035 24. Handle Layer 2 Path Change 1037 Layer 2 path change is an important challenge on this control plane 1038 based solution. The SAVI device MUST be sensitive to any layer 2 path 1039 change. Whenever a layer 2 control protocol frame, including STP, 1040 RSTP, TRILL, is received from some anchor, which announces a layer 2 1041 incoming path is changed to the anchor, data packet trigger process 1042 SHOULD be enabled on the anchor for a period, or alternatively the 1043 device SHOULD forward the packets directly for a period, and set up 1044 bindings from Neighbor Table. Although generally such events can be 1045 handled through pre-configuration of data-trigger attribute, the 1046 future layer 2 protocol may be flexible and hard to handle through 1047 manual configuration. 1049 25. Duplicate Bindings on Same Address 1051 Note that the same address may be bound with multiple anchors, only 1052 if the binding processes are finished on each anchor successfully 1053 respectively. 1055 This mechanism is designed in consideration that a node may move on 1056 the local ink, and a node may have multiple anchors. 1058 Note that the local link movement scenario is not handled perfectly. 1059 The former binding may not be removed, unless the node is directly 1060 attached to the SAVI device. The nodes sharing the same former anchor 1061 of the moving node have the ability to use its address. 1063 26. Constants 1065 MAX_DHCP_RESPONSE_TIME 120s 1067 MAX_ARP_PREPARE_DELAY Default 1s but configurable 1069 MAX_ARP_DELAY Default 1s but configurable 1071 MAX_DAD_PREPARE_DELAY Default 1s but configurable 1073 MAX_DAD_DELAY Default 1s but configurable 1075 BIND_RECOVERY_INTERVAL Device capacity depended and configurable 1077 27. Security Considerations 1079 For prefix level granularity filtering is the basis of host level 1080 granularity filtering, to learn and configure correct prefix is of 1081 great importance to this mechanism. Thus, it's important to keep RA 1082 and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a 1083 mechanism to improve the security of RA message. 1085 28. IANA Considerations 1087 There is no IANA consideration currently. 1089 29. References 1091 29.1. Normative References 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1096 29.2. Informative References 1098 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 1099 March 1997. 1101 [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast 1102 Addresses", RFC3307, August 2002. 1104 [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6 1105 (DHCPv6)", RFC3315, July 2003. 1107 [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration 1108 Protocol (DHCP) Leasequery", RFC4388, February 2006. 1110 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 1111 "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September 2007. 1113 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 1114 Autoconfiguration", RFC4862, September, 2007. 1116 [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6 1117 Leasequery", RFC5007, September 2007. 1119 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 1120 July 2008. 1122 [IP Source Guard] Cisco, "Network Security Technologies and 1123 Solutions", chapter 7, Cisco Press, May 20, 2008. 1125 [draft-baker-savi-one-implementation-approach] F. Baker, "An 1126 implementation approach to Source Address Validation", 1127 draft-baker-savi-one-implementation-approach-00. 1129 30. Acknowledgments 1131 Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik 1132 Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David 1133 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg 1134 Daley, Joel M. Halpern, Mikael Abrahamsson, John Kaippallimalil and Tao 1135 Lin for their valuable contributions. 1137 Authors' Addresses 1139 Jun Bi 1140 CERNET 1141 Network Research Center, Tsinghua University 1142 Beijing 100084 1143 China 1144 Email: junbi@cernet.edu.cn 1146 Jianping Wu 1147 CERNET 1148 Computer Science, Tsinghua University 1149 Beijing 100084 1150 China 1151 Email: jianping@cernet.edu.cn 1153 Guang Yao 1154 CERNET 1155 Network Research Center, Tsinghua University 1156 Beijing 100084 1157 China 1158 Email: yaog@netarchlab.tsinghua.edu.cn 1160 Fred Baker 1161 Cisco Systems 1162 Email: fred@cisco.com 1164 31. Change Log 1166 From 02 to 03: Section 12, data trigger and counter trigger are 1167 combined to binding recovery process. The expression "one of MUST" is 1168 changed to "conditional MUST. Conditions related with the 1169 implementation are specified. Related constants are changed in 1170 section 26."