idnits 2.17.1 draft-ietf-savi-dhcp-01.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 12 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 -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This step MAY NOT be performed if: == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The TID is kept for assurance that the assigned address can be bound with anchor securely. It is suggested to keep TID in entry. However, TID MAY NOT be contained in the entry. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following steps after this step MAY NOT be performed. It is SUGGESTED to perform following steps unless in some specified scenario, e.g., a DHCP-only scenario. If the following steps are not performed because of implementation or configuration, the state of the corresponding entry MUST be changed to BOUND, and the lifetime is set to lease time. == 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 (March 8, 2010) is 5135 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: 'RFC2131' is mentioned on line 411, but not defined == Missing Reference: 'RFC3315' is mentioned on line 411, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Missing Reference: 'SAVI-framework' is mentioned on line 65, but not defined == Missing Reference: 'BCP38' is mentioned on line 155, but not defined == Missing Reference: 'RFC4861' is mentioned on line 757, but not defined == Missing Reference: 'RFC3307' is mentioned on line 750, but not defined == Missing Reference: 'RFC4429' is mentioned on line 822, but not defined Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi, J. Wu, G. Yao 2 Internet Draft CERNET 3 Intended status: Standard Tracks F. Baker 4 Expires: September 2010 Cisco 5 March 8, 2010 7 SAVI Solution for DHCP 8 draft-ietf-savi-dhcp-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to publish it 15 as an RFC and to translate it into languages other than English. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 10, 19 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on September 8, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Abstract 63 This document specifies the procedure for creating bindings between a 64 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an 65 anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation 66 Improvements) device. The bindings can be used to filter packets 67 generated on the local link with forged IP addresses. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Conventions used in this document..............................4 73 3. Mechanism Overview.............................................4 74 4. Background and Related Protocols...............................4 75 5. Terminology....................................................5 76 6. Conceptual Data Structures.....................................5 77 6.1. Binding State Table (BST).................................5 78 6.2. Filtering Table (FT)......................................5 79 7. Binding States Description.....................................6 80 8. DHCP Scenario..................................................6 81 9. Anchor Attributes..............................................7 82 9.1. SAVI-Validation Attribute.................................7 83 9.2. SAVI-DHCP-Trust Attribute.................................7 84 9.3. SAVI-SAVI Attribute.......................................8 85 10. Prefix Configuration..........................................8 86 11. Binding Set Up................................................9 87 11.1. Process of DHCP Snooping.................................9 88 11.1.1. Initialization......................................9 89 11.1.1.1. Trigger Event..................................9 90 11.1.1.2. Event Validation...............................9 91 11.1.1.3. Following Actions.............................10 93 11.1.2. From START to LIVE.................................10 94 11.1.2.1. Trigger Event.................................10 95 11.1.2.2. Event Validation..............................10 96 11.1.2.3. Following Actions.............................10 97 11.1.3. From LIVE to DETECTION.............................12 98 11.1.3.2. Event Validation..............................12 99 11.1.3.3. Following Actions.............................12 100 11.1.4. From DETECTION to BOUND............................13 101 11.1.4.1. Trigger Event.................................13 102 11.1.4.2. Following Actions.............................13 103 11.1.5. After BOUND........................................13 104 11.2. State Machine of DHCP Snooping..........................14 105 12. Filtering Specification......................................15 106 12.1. Data Packet Filtering...................................16 107 12.2. Control Packet Filtering................................16 108 13. Format and Delivery of Probe Messages........................17 109 13.1. Duplicate detection.....................................17 110 14. Binding Remove...............................................17 111 15. Handle Anchor Off-link event.................................18 112 16. About Collision in Detection.................................18 113 16.1. Whether to notify the DHCP server.......................18 114 16.2. The result of detection without host aware..............18 115 17. Filtering during detection...................................18 116 18. Binding Number Limitation....................................19 117 19. Movement without DHCP Procedure..............................19 118 20. MLD Consideration............................................19 119 21. State Restoration............................................19 120 22. Constants....................................................20 121 23. Security Considerations......................................20 122 24. IANA Considerations..........................................20 123 25. References...................................................20 124 25.1. Normative References....................................20 125 25.2. Informative References..................................21 126 26. Acknowledgments..............................................21 128 1. Introduction 130 This document describes the procedure for creating bindings between 131 DHCP assigned addresses and an anchor (refer to [savi-framework]). 132 Other related details about this procedure are also specified in this 133 document. 135 These bindings can be used to filter packets with forged IP addresses. 136 How to use these bindings is specified in [savi-framework], depending 137 on the environment and configuration. The definition and examples of 138 anchor is also specified in [savi-framework]. 140 The binding process is inspired by the work of IP Source Guard. This 141 specification differs from IP Source Guard in the specification for 142 collision detection, which is essential in environments with multiple 143 address assignment methods. 145 2. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. Mechanism Overview 153 The mechanism specified in this document is designed to provide a 154 host level source IP address validation granularity, as a supplement 155 to BCP38 [BCP38]. This mechanism is deployed on the access device 156 (including access switch, wireless access point/controller, etc), and 157 performs mainly DHCP snooping to set up bindings between DHCP 158 assigned IP addresses and corresponding anchors. The bindings can be 159 used to validate the source address in the packets. 161 4. Background and Related Protocols 163 This mechanism is an instance of a SAVI [savi-framework] solution, 164 specialized for addresses assigned using the DHCP protocol. 166 Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic 167 Host Configuration Protocol version 6 [RFC3315] specify the 168 procedures for providing a client with assigned address and other 169 configuration information from a DHCP server. If a client gets an 170 address through the DHCP protocol, the address should be regarded as 171 a potential "authorized" or "registered" address of the client. 173 In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as 174 another address assignment mechanism. A node can use this mechanism 175 to auto-configure an IPv6 address. A DHCPv6 client may use a 176 stateless address to send message to DHCP server. Even in a DHCPv6- 177 only environment, a node must assign its link-local address through 178 this mechanism. [RFC4862] clearly requires that duplicated address 179 detection must be performed on any IPv6 address, including DHCPv6 180 address. 182 [RFC4861] specifies the Neighbor Discovery protocol, which is an 183 essential part of IPv6 address assignment. 185 [RFC5227] specifies the procedure to detect IPv4 address collision. 186 It is not required currently. However, this feature is useful to 187 determine the uniqueness of an IPv4 address on the link. Considering 188 not all the operating systems support [RFC5227], this solution is 189 designed to be compatible with operating systems not complying with 190 [RFC5227]. 192 5. Terminology 194 Main terms used in this document are described in [savi-framework], 195 [RFC2131] and [RFC3315]. 197 6. Conceptual Data Structures 199 This section describes the possible conceptual data structures used 200 in this mechanism. 202 Two main data structures are used to record bindings and their states 203 respectively. There is redundancy between the two structures, for the 204 consideration of separation of data plane and control plane. 206 6.1. Binding State Table (BST) 208 This table contains the state of binding between source address and 209 anchor. Entries are keyed on the anchor and source IP address. Each 210 entry has a lifetime field recording the remaining lifetime of the 211 entry, a state field recording the state of the binding and a field 212 recording other information. 214 +---------+----------+-------+-----------+-------+ 215 | Anchor | Address | State | Lifetime |Other | 216 +---------+----------+-------+-----------+-------+ 217 | A | IP_1 | Bound | 65535 | | 218 +---------+----------+-------+-----------+-------+ 219 | A | IP_2 | Bound | 10000 | | 220 +---------+----------+-------+-----------+-------+ 221 | B | IP_3 |_Start | 1 | | 222 +---------+----------+-------+-----------+-------+ 223 Figure 1 Instance of BST 225 6.2. Filtering Table (FT) 227 This table contains the bindings between anchor and address, keyed on 228 anchor. This table doesn't contain any state of the binding. This 229 table is only used to filter packets. An Access Control List can be 230 regarded as a practical instance of this table. 232 +---------+----------+ 233 |Anchor |Address | 234 +---------+----------+ 235 |A |IP_1 | 236 +---------+----------+ 237 |A |IP_2 | 238 +---------+----------+ 239 Figure 2 Instance of FT 241 7. Binding States Description 243 This section describes the binding states of this mechanism. 245 START A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 246 Solicitation with Rapid Commit option) has been received from host, 247 and it may trigger a new binding. 249 LIVE A DHCP address has been acknowledged by a DHCP server. 251 DETECTION A gratuitous ARP or Duplicate Address Detection NSOL 252 has been sent by the host (or the SAVI device). 254 BOUND The address has passed duplicate detection and 255 it is bound with the anchor. 257 8. DHCP Scenario 259 Figure 3 shows the main elements in a DHCP enabled network. At least 260 one DHCP server MUST be deployed in the network, and DHCP relay MAY 261 be used to relay message between client and server. Other address 262 assignment mechanisms may be also used in such network. 264 +--------+ 265 | DHCP | 266 | Server | 267 +-------,+ 268 | 269 | 270 | 271 +----'-----+ 272 | SAVI | 273 | Device | 274 +-/------/-+ 275 | | 276 +----\-+ +\-----+ 277 |DHCP | |Client| 278 |Relay | | | 279 +------+ +------+ 280 Figure 3 DHCP Scenario 282 9. Anchor Attributes 284 This section specifies the anchor attributes involved in this 285 mechanism. 287 Anchor is defined in the [savi-framework]. Attribute of each anchor 288 is configurable. In default, anchor has no attribute. An anchor MAY 289 be configured to have one or more compatible attributes. However, an 290 anchor MAY have no attribute. 292 If an anchor has no attribute, server type DHCP message from this 293 anchor MUST be dropped. However, other packets SHOULD NOT be dropped. 295 9.1. SAVI-Validation Attribute 297 If and only if source address validation must be performed on the 298 traffic from an anchor, this anchor MUST be set to have SAVI- 299 Validation attribute. The filtering process on anchor with such 300 attribute is described in section 12. 302 9.2. SAVI-DHCP-Trust Attribute 304 If and only if an anchor is associated with a trustable DHCP 305 server/relay, it SHOULD be set to have this attribute. 307 If DHCP is used to assign address in the network, there MUST be at 308 least one anchor with this attribute. DHCP Reply message not coming 309 from such ports MUST be dropped. 311 9.3. SAVI-SAVI Attribute 313 If and only if an anchor is associated with another SAVI device, it 314 SHOULD be set to have this attribute. All traffic from anchor with 315 this attribute will be forwarded without check. 317 This attribute is mutually exclusive with SAVI-Validation. 319 10. Prefix Configuration 321 In DHCP scenario, address advertised by DHCP server should be 322 believed in. However, in this solution, a node shares the same anchor 323 as the DHCP server can disguise as the DHCP server and offer the 324 client incorrect configuration information. Without fully deployment 325 of SAVI, this problem is difficult to solve. Thus, it is SUGGESTED 326 that correct address prefix should be configured, and DHCP server 327 message which assigns address out of the scope should be dropped. 328 This mechanism can ensure the client can at least get an address with 329 proper prefix. 331 This document suggests set 3 prefix scopes: 333 IPv4 Prefix: 335 The allowed scope of any kind of IPv4 addresses. It can be set 336 manually. 338 IPv6 SLAAC Prefixes: 340 The allowed scope of SLAAC and manually configured IPv6 341 addresses. It can be set through snooping RA message from port 342 with SAVI-RA-Trust attribute, DHCP-PD or manual configuration. 344 FE80::/64 MUST be set to a feasible prefix. 346 IPv6 DHCPv6 Prefixes: 348 The allowed scope of DHCPv6 addresses. It can be set through RA 349 snooping, DHCP-PD protocol, or manual configuration. 351 There is no need to explicitly present these prefix scopes. But these 352 restrictions SHOULD be used as premier check in binding set up. 354 Refer to security consideration for other discussions. 356 11. Binding Set Up 358 This section specifies the procedure of setting up bindings based on 359 control packet snooping. All binding entries are set up on anchor 360 with SAVI-Validation attribute. 362 11.1. Process of DHCP Snooping 364 11.1.1. Initialization 366 A binding entry is initialized in this step. 368 This step MAY NOT be performed if: 370 1. Option 82 is used to keep anchor in DHCP Request and Reply, or 372 2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or 374 3. The mapping table from MAC to anchor is secure. 376 If none of these three requirements are satisfied, this step SHOULD 377 be performed. 379 If this step is not performed, then binding entry will be initialized 380 in the next step. 382 This step is performed for the consideration that anchor and DHCP 383 assigned address can be bound with security in the next step. 384 Otherwise the security of binding setup is based on the mapping 385 mechanism from MAC to anchor on SAVI device, which may be vulnerable. 387 This step can also help limit the request rate of client to prevent 388 Denial of Services attack against DHCP server. 390 11.1.1.1. Trigger Event 392 A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with 393 Rapid Commit option is received. 395 11.1.1.2. Event Validation 397 The SAVI device checks current BST as follows: 399 1. Whether the limitation on binding entry number of this anchor will 400 be exceeded if a new entry is triggered. 402 11.1.1.3. Following Actions 404 If the check is passed: 406 The SAVI device MUST forward the message. 408 The SAVI device MUST generate an entry for the anchor in the Binding 409 State Table (BST) and set the state field to START. The lifetime of 410 this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The Transaction ID 411 (Refer to Section 2 in [RFC2131] and Section 4.2 in [RFC3315]) field 412 of the request packet SHOULD be recorded in the entry. 414 +---------+----------+-------+-----------------------+-------+ 415 | Anchor | Address | State | Lifetime |Other | 416 +---------+----------+-------+-----------------------+-------+ 417 | A | | START |MAX_DHCP_RESPONSE_TIME | TID | 418 +---------+----------+-------+-----------------------+-------+ 419 Figure 4 Binding entry in BST on initialization 421 The TID is kept for assurance that the assigned address can be bound 422 with anchor securely. It is suggested to keep TID in entry. However, 423 TID MAY NOT be contained in the entry. 425 11.1.2. From START to LIVE 427 11.1.2.1. Trigger Event 429 A DHCPv4 DHCPACK or DHCPv6 REPLY message is received. 431 11.1.2.2. Event Validation 433 The SAVI device checks the message and BST as follows: 435 1. Whether the message is received from an anchor which has the SAVI- 436 DHCP-Trust attribute; 438 2. Whether the entry in the BST with corresponding TID is in the 439 START state. Or if the prior step is not performed, check whether 440 the binding number limitation will be exceeded. 442 11.1.2.3. Following Actions 444 If the check is passed: 446 The SAVI device MUST deliver the message to the destination. 448 The SAVI device MUST set the state of the corresponding entry to be 449 LIVE. If prior step is not performed, a new entry MUST be generated 450 in the BST. The lifetime of the entry MUST be set to be 451 MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY respectively. The 452 lease time MUST be recorded in the entry. 454 +---------+----------+-------+------------------------+-------+ 455 | Anchor | Address | State | Lifetime |Other | 456 +---------+----------+-------+------------------------+-------+ 457 | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | 458 | | | |MAX_DAD_PREPARE_DELAY | Time | 459 +---------+----------+-------+------------------------+-------+ 460 Figure 5 Binding entry in BST on assignment 462 Then, the SAVI device MAY set the state of the corresponding entry to 463 be DETECTION, and send two or more ARP Request or NSOL for the 464 assigned address. If the SAVI device sends detection packet directly, 465 the next step MUST be omitted. 467 +---------+----------+-----------+-----------------+-------+ 468 | Anchor | Address | State | Lifetime |Other | 469 +---------+----------+-----------+-----------------+-------+ 470 | A | Addr | DETECTION |MAX_ARP_DELAY or | Lease | 471 | | | |MAX_DAD_DELAY | Time | 472 +---------+----------+-----------+-----------------+-------+ 473 Figure 6 Binding entry in BST on assignment: another case 475 The SAVI device MUST insert an entry into the Filtering Table if the 476 assigned address is not bound with another anchor in current BST. If 477 the address has been bound with another anchor in current BST, the 478 SAVI device MUST check if the node associated with that anchor is 479 off-line. If yes, bind the address with the new entry and delete the 480 original binding; if no, keep the original entry and delete the new 481 entry in BST. This mechanism can handle local link movement, and 482 avoid attacker grabbing assigned bindings from other nodes. However, 483 if several hosts share the same anchor, and one of them moves to 484 another anchor, this mechanism may cause problem. 486 +---------+----------+ 487 |Anchor |Address | 488 +---------+----------+ 489 |A |Addr | 490 +---------+----------+ 491 Figure 7 Binding entry in FT on assignment 493 The following steps after this step MAY NOT be performed. It is 494 SUGGESTED to perform following steps unless in some specified 495 scenario, e.g., a DHCP-only scenario. If the following steps are not 496 performed because of implementation or configuration, the state of 497 the corresponding entry MUST be changed to BOUND, and the lifetime is 498 set to lease time. 500 11.1.3. From LIVE to DETECTION 502 11.1.3.1. Trigger Event 504 A gratuitous ARP Request or Duplicate Address Detection Neighbor 505 Solicitation is received from anchor. Or a timeout event of an entry 506 with state LIVE happens. 508 11.1.3.2. Event Validation 510 The SAVI device checks the message and BST as follows: 512 1. Whether the Target IP Address field of the ARP Request or Neighbor 513 Solicitation has been bound with the corresponding anchor in BST 514 or FT. 516 11.1.3.3. Following Actions 518 If the check is passed: 520 If timeout event of an entry with state LIVE happens, the SAVI device 521 MAY send one or more ARP Request or a DAD NSOL, with Target Address 522 set to the recorded address in the entry. If detection packets are 523 sent, the SAVI device MUST set the state of the entry to be DETECTION. 524 The lifetime of the entry MUST be set to be MAX_ARP_DELAY or 525 MAX_DAD_DELAY respectively. If no detection packet is sent, the entry 526 MUST be removed from BST and FT. If the SAVI device chooses not to 527 send detection packet, valid packets may get dropped because a number 528 of operating systems don't fully support [RFC4862] and [RFC5227] and 529 don't send detection packets themselves. Thus, it is SUGGESTED the 530 SAVI device SHOULD send detection packet in case the client doesn't 531 send that itself. 533 +---------+----------+-----------+-----------------+-------+ 534 | Anchor | Address | State | Lifetime |Other | 535 +---------+----------+-----------+-----------------+-------+ 536 | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | 537 | | | |MAX_DAD_DELAY | Time | 538 +---------+----------+-----------+-----------------+-------+ 539 Figure 8 Binding entry in BST on detection 541 11.1.4. From DETECTION to BOUND 543 11.1.4.1. Trigger Event 545 A timeout event of an entry with state DETECTION occurs or an ARP 546 Response or NA for an address in BST with state DETECTION is received. 548 11.1.4.2. Following Actions 550 If a timeout event of an entry with state DETECTION occurs, set the 551 state of the entry to be BOUND. The lifetime of the entry is set to 552 be the Lease time acknowledged by DHCP server. 554 +---------+----------+-----------+----------------+-------+ 555 | Anchor | Address | State | Lifetime |Other | 556 +---------+----------+-----------+----------------+-------+ 557 | A | Addr | BOUND | Lease time | | 558 +---------+----------+-----------+----------------+-------+ 559 Figure 9 Binding entry in BST on finalization 561 If an ARP Response or NA for an address in BST with state DETECTION 562 is received, remove the corresponding entry in BST and FT. The ARP 563 Response or NA MUST be delivered to the client. 565 11.1.5. After BOUND 567 Once a binding entry is set up for an anchor, the binding will be 568 used to filter packet with the anchor, as specified in section 12. On 569 the other hand, DHCP messages with the anchor will affect the binding. 570 The binding is also affected by DHCP server message toward the anchor. 572 Before a DHCP message is found that it may change the corresponding 573 binding, its validity MUST be checked as described in section 12.2. 575 Whenever a DHCP Decline is received, delete the corresponding entry 576 in BST and FT. 578 Whenever a DHCP Release is received, if the state of the entry is 579 BOUND, delete the entry in BST and FT. 581 If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is 582 received from the server, set lifetime of the entry in BST to be the 583 new lease time. 585 If the lifetime of an entry with state BOUND expires, delete the 586 entry in BST and Filter Table. 588 The binding may also be affected by control messages with or toward 589 another anchor. The binding MAY be move to another anchor to handle 590 local link movement, as described in section 11.1.2.3. In this 591 situation, the node assigned a DCHP address changes to associate with 592 another anchor, thus the address should be bound with the anchor 593 which the node migrates to. Other than this situation, the binding 594 will not be changed, for the consideration of simplicity. Even if an 595 attached node becomes inactive and doesn't reply to any NS or ARP 596 Request, the associated bindings will not be removed. 598 Switch port down event (or more general, anchor turns off-link) will 599 change the corresponding entry, as described in section 15. 601 11.2. State Machine of DHCP Snooping 603 The main state transits are listed as follows. Note that the anchor 604 migration of binding entry is not included. 606 State Message/Event Action Next State 608 - REQ/CFM/SOL+RC Generate entry START 610 *- ACK/RPL Generate entry with lease LIVE 612 *- ACK/RPL Generate entry with lease BOUND 614 **- ACK/RPL Generate entry with lease DETECTION 616 , send probe 618 START ACK/RPL Record lease time LIVE 620 **START ACK/RPL Send probe DETECTION 622 START Timeout Remove entry - 624 LIVE Gra ARP REQ/DAD NS - DETECTION 626 LIVE DECLINE Remove entry - 628 LIVE Timeout Send probe DETECTION 630 *LIVE Timeout Remove entry - 632 DETECTION Timeout - BOUND 634 DETECTION ARP RES/DAD NA Remove entry - 635 DETECTION DECLINE Remove entry - 637 BOUND RELEASE/DECLINE Remove entry - 639 BOUND Timeout Remove entry - 641 BOUND RENEW/REBOUND Set new lifetime BOUND 643 *: optional but NOT SUGGESTED. 645 **: optional and MAY conflict other transits 647 REQ: DHCP REQUEST 649 CFM: DHCP CONFIRM 651 SOL: DHCP SOLICITATION 653 RC: Rapid Commit option 655 ACK: DHCP ACKNOWLEDGEMENT 657 RPL: DHCP REPLY 659 Probe Gratuitous ARP REQUEST or Duplicate Address Detection Neighbor 660 Solicitation, described in section 13.1 662 Gra ARP REQ: Gratuitous ARP REQUEST 664 ARP RES: ARP RESPONSE 666 DAD NS: Duplicate Address Detection Neighbor Solicitation 668 DAD NA: Neighbor Advertisement targeting at a tentative address 670 DECLINE: DHCP DECLINE 672 RELEASE: DHCP RELEASE 674 RENEW: DHCP RENEW 676 REBOUND: DHCP REBOUND 678 12. Filtering Specification 680 This section specifies how to use bindings to filter packets. Because 681 the Filtering Table is an allow-table, packet with source address not 682 in the table will be filtered. Considering DHCP may coexist with 683 other address assignment methods, e.g., Stateless Auto-configuration, 684 the specification made here is based on the assumption that other 685 SAVI solutions will also use BST and FT to keep bindings and filter 686 packets. Otherwise this solution will conflict with other SAVI 687 solutions. 689 Filtering policies are different for data packet and control packet. 690 DHCP and ND messages that may cause state transit are classified into 691 control packet. Neighbor Advertisement and ARP Response are also 692 included in control packet, because the Target Address of NA and ARP 693 Response should be checked to prevent spoofing. All other packets are 694 considered to be data packets. 696 12.1. Data Packet Filtering 698 Data packets with an anchor which has attribute SAVI-Validation MUST 699 be checked. 701 If the source of a packet associated with its anchor is in the FT, 702 this packet SHOULD be forwarded; or else the packet MUST be discarded. 704 12.2. Control Packet Filtering 706 For anchors with SAVI-Validation attribute: 708 The source address of DHCPv4 Discovery SHOULD be set to all zeros. 709 The source address of DHCPv4 Request SHOULD be set to all zeros or a 710 bound address in FT. 712 The source address of DHCPv6 Request MUST be an address associated 713 with the corresponding anchor in FT. The source address of DHCPv6 714 Confirm MUST be a link local address associated with the 715 corresponding anchor in FT. The source address of DHCPv6 Solicit MUST 716 be a link layer address bound with corresponding anchor. The link 717 layer address MAY be bound based on SAVI-SLAAC solution or other 718 solutions. 720 The source address of other types of DHCP messages MUST be a address 721 bound with the corresponding anchor. 723 The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the 724 check on FT. 726 The target address and source address in all the Neighbor 727 Advertisement packets and ARP replies MUST also pass the checks on FT. 729 For other anchors: 731 All DHCP Reply/Ack packets MUST be from anchor with the SAVI-DHCP- 732 Trust attribute. 734 13. Format and Delivery of Probe Messages 736 As described in section 11.1.2.3 and 11.1.3.3, the SAVI device MAY 737 send detection probes on behavior of client to determine whether the 738 assigned address is duplicated. Currently no other probes are 739 designed in this solution. 741 13.1. Duplicate detection 743 Message Type: DAD NS, Gratuitous ARP Request 745 Format: 747 Link layer source - link layer address of host; 749 Link layer destination - For IPv6, use multicast address 750 specified in [RFC3307]; For IPv4, use broadcast address; 752 IP source - Unspecified address for IPv6; The tentative 754 address for IPv4; 756 IP destination - For IPv6, multicast address specified in 757 section 5.4.2 of [RFC4861]; For IPv4, the tentative address; 759 Delivery: 761 MUST not be delivered to the host which the SAVI device is 762 performing DAD on behavior of. 764 14. Binding Remove 766 If the lifetime of an entry with state BOUND expires, the entry MUST 767 be removed. 769 When the SAVI device receives a DAD NS/Gra ARP request target at an 770 address bound and there is no replies from the anchor, if the anchor 771 is a SAVI-Validation anchor, hold the binding entry through sending 772 NA/ARP Reply, or remove the binding. 774 15. Handle Anchor Off-link event 776 Port DOWN event MUST be handled if switch port is used as anchor. In 777 more general case, if an anchor turns off-link, this event MUST be 778 handled. 780 Whenever an anchor with attribute SAVI-Validation turns down, the 781 bindings with the anchor MUST be kept for a short time. 783 To handle movement, if receiving DAD NS/Gra ARP request targeting at 784 the address during the period, remove the entry. 786 If the anchor turns on-link during the period, recover bindings. It 787 may result in some security problem, e.g., a malicious node 788 immediately associates with the anchor got off by a previous node, 789 then it can use the address assigned to the previous node. However, 790 this situation is very rare in reality. Authors decide not to handle 791 this situation. 793 16. About Collision in Detection 795 The SAVI device may receive a response in detection. Some related 796 details are specified here. 798 16.1. Whether to notify the DHCP server 800 It is unnecessary for the SAVI device to notify the DHCP server, 801 because the host will send a DECLINE message to it once it finds the 802 advertised address is conflict. 804 16.2. The result of detection without host aware 806 In case the SAVI device send detection packet instead of the host, 807 the host will not be aware of the detection result. If the detection 808 succeeds, there is no problem. However, if the detection fails, the 809 packets from the host with the assigned address will be filtered out. 810 This result can be regarded as a reasonable punishment for not 811 performing duplicate detection and using a collision address. The 812 SAVI device MAY choose to notice the client that the assigned address 813 has been used, through a NA message. This mechanism is not required 814 in this solution. 816 17. Filtering during detection 818 In this mechanism, whenever the DHCP server replies an address, this 819 address will be allowed immediately even before duplicate detection 820 is completed. This design is in consideration of a host may start to 821 send packets straightway without detection. Also this design is to be 822 compatible with optimistic DAD [RFC4429]. 824 However, this feature may allow an attacker to send quantities of 825 packets with source addresses already assigned to other nodes. A 826 practical solution for this vulnerability is configuring the address 827 pool and allocation algorithm of the DHCP server carefully. 829 18. Binding Number Limitation 831 It is suggested to configure some mechanism in order to prevent a 832 single node from exhausting the binding table entries on the SAVI 833 device. Either of the following mechanism is sufficient to prevent 834 such attack. 836 1. Set the upper bound of binding number for each anchor with SAVI- 837 Validation. 839 2. Reserve a number of binding entries for each anchor with SAVI- 840 Validation attribute and all anchors share a pool of the other 841 binding entries. 843 3. Limit DHCP Request rate per anchor, using the bound entry number 844 of each anchor as reverse indicator. 846 19. Movement without DHCP Procedure 848 This mechanism currently doesn't handle any movement without DHCP 849 procedure, which means the change of anchor without triggering any 850 DHCP procedure. The scenario includes several hosts are attached a 851 SAVI-Validation port through a hub, and the hub changes from its 852 attaching port to another SAVI-Validation port. 854 For handling this situation will necessarily lead to a data packet 855 triggering procedure on SAVI device, and may violate the semantic of 856 DHCP protocol, this situation is not handled in this solution. 858 20. MLD Consideration 860 The SAVI device MUST join the tentative address multicast group 861 whenever perform duplicate detection on behavior of host. 863 21. State Restoration 865 If a SAVI device reboots accidentally or designedly, the states kept 866 in volatile memory will get lost. This may cause hosts indirectly 867 attached to the SAVI device to be broken away from the network, 868 because they can't recover bindings on the SAVI device of themselves. 869 Thus, it is SUGGESTED that binding entries can be saved into non- 870 volatile storage manually or regularly. Immediately after reboot, the 871 SAVI device can restore binding states from the non-volatile storage. 873 22. Constants 875 MAX_DHCP_RESPONSE_TIME 120s 877 MAX_ARP_PREPARE_DELAY Default 1s but configurable 879 MAX_ARP_DELAY Default 1s but configurable 881 MAX_DAD_PREPARE_DELAY Default 1s but configurable 883 MAX_DAD_DELAY Default 1s but configurable 885 23. Security Considerations 887 For prefix level granularity filtering is the basis of host level 888 granularity filtering, to learn and configure correct prefix is of 889 great importance to this mechanism. Thus, it's important to keep RA 890 and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a 891 mechanism to improve the security of RA message. 893 24. IANA Considerations 895 There is no IANA consideration currently. 897 25. References 899 25.1. Normative References 901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 902 Requirement Levels", BCP 14, RFC 2119, March 1997. 904 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 905 Autoconfiguration", RFC4862, September, 2007. 907 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 908 July 2008. 910 25.2. Informative References 912 26. Acknowledgments 914 Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik 915 Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David 916 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg 917 Daley, Joel M. Halpern, Mikael Abrahamsson and Tao Lin for their 918 valuable contributions. 920 Authors' Addresses 922 Jun Bi 923 CERNET 924 Network Research Center, Tsinghua University 925 Beijing 100084 926 China 927 Email: junbi@cernet.edu.cn 929 Jianping Wu 930 CERNET 931 Computer Science, Tsinghua University 932 Beijing 100084 933 China 934 Email: jianping@cernet.edu.cn 936 Guang Yao 937 CERNET 938 Network Research Center, Tsinghua University 939 Beijing 100084 940 China 941 Email: yaog@netarchlab.tsinghua.edu.cn 943 Fred Baker 944 Cisco Systems 945 Email: fred@cisco.com