idnits 2.17.1 draft-ietf-savi-dhcp-27.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == 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 (June 26, 2014) is 3590 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) ** Downref: Normative reference to an Informational RFC: RFC 7039 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-opsec-dhcpv6-shield-03 -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Bi 3 Internet-Draft J. Wu 4 Intended status: Standards Track G. Yao 5 Expires: December 28, 2014 Tsinghua Univ. 6 F. Baker 7 Cisco 8 June 26, 2014 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-27 13 Abstract 15 This document specifies the procedure for creating a binding between 16 a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI 17 (Source Address Validation Improvements) device. The bindings set up 18 by this procedure is used to filter out packets with forged source IP 19 address in DHCP scenario. This mechanism is proposed as a complement 20 to ingress filtering to provide finer-grained source IP address 21 validation. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on December 28, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Deployment Scenario and Configuration . . . . . . . . . . . . 7 73 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 7 74 4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10 76 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10 77 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11 78 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11 79 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11 80 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12 81 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13 83 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13 84 4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 14 85 4.3.4. An alternative deployment . . . . . . . . . . . . . . 15 86 4.3.5. Considerations on Binding Anchor . . . . . . . . . . 16 87 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17 88 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18 89 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.2. Binding States Description . . . . . . . . . . . . . . . 19 91 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19 93 6.3.2. Control Message Arriving Events . . . . . . . . . . . 19 94 6.4. The State Machine of DHCP Snooping Process . . . . . . . 21 95 6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 21 96 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . 22 97 6.4.3. From BOUND to Other States . . . . . . . . . . . . . 24 98 6.5. Table of State Machine . . . . . . . . . . . . . . . . . 26 99 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 27 100 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 27 101 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 28 102 7.3. Additional Binding States Description . . . . . . . . . . 28 103 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 7.5. State Machine of Binding Recovery Process . . . . . . . . 30 105 7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 30 106 7.5.2. From DETECTION to Other States . . . . . . . . . . . 31 107 7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 32 108 7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 33 109 7.6. Table of State Machine . . . . . . . . . . . . . . . . . 34 110 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 35 111 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 36 112 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 36 113 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 37 114 9.1. Attribute Configuration Restoration . . . . . . . . . . . 37 115 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 37 116 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 38 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 118 11.1. Security Problems about the Data Snooping Process . . . 38 119 11.2. Issues about Leaving Clients . . . . . . . . . . . . . . 38 120 11.3. Duplicate Bindings to the Same Address . . . . . . . . . 39 121 11.4. Compatibility with DNA (Detecting Network Attachment) . 40 122 11.5. Authentication in DHCPv6 Leasequery . . . . . . . . . . 41 123 11.6. Binding Number Limitation . . . . . . . . . . . . . . . 41 124 11.7. Privacy Considerations . . . . . . . . . . . . . . . . . 41 125 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 126 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 42 127 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 128 14.1. Normative References . . . . . . . . . . . . . . . . . . 42 129 14.2. Informative References . . . . . . . . . . . . . . . . . 43 131 1. Introduction 133 This document describes a fine-grained source IP address validation 134 mechanism. This mechanism creates bindings between IP addresses 135 assigned to network attachment points by DHCP and suitable binding 136 anchors (refer to Section 3) of the attachments. Then the bindings 137 are used to identify and filter out packets originated from these 138 attachments with forged source IP addresses. In this way, this 139 mechanism can prevent hosts from spoofing IP addresses assigned to 140 the other attachment points. Compared with [RFC2827], which provides 141 prefix granularity source IP address validity, this mechanism can 142 benefit the network with finer-grained validity and traceability of 143 source IP addresses. 145 This mechanism primarily performs DHCP snooping to set up bindings 146 between IP addresses assigned by DHCP and corresponding binding 147 anchors. This binding process is inspired by the work of [BA2007]. 148 Different from [BA2007], which designs specifications about DHCPv4, 149 this mechanism covers the DHCPv6 snooping process, the Data Snooping 150 process (refer to Section 7), as well as a number of other technical 151 details. Specially, the Data Snooping process is a data-triggered 152 procedure which snoops the header of data packet to set up bindings. 153 It is designed to avoid permanent block of valid address in case that 154 DHCP snooping is insufficient to set up all the valid bindings. 156 This mechanism is designed for the stateful DHCP scenario [RFC2131], 157 [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this 158 document, because it has nothing to do with IP address allocation. A 159 client doing stateless DHCP acquires its IP address(es) using some 160 other mechanism. The appropriate SAVI method must be based on this 161 mechanism. For example, for hosts using Stateless Auto-configuration 162 address, SAVI-FCFS [RFC6620] should be enabled. Besides, this 163 mechanism is primarily designed for pure DHCP scenarios in which only 164 addresses assigned through DHCP are allowed. However, it does not 165 block any link-local address. It is because link-local addresses are 166 used by DHCPv6 clients before the clients are assigned a DHCPv6 167 address. Considering that link-local addresses are generally self- 168 generated, and the spoofing of link local address may disturb this 169 mechanism, it is RECOMMENDED to enable a SAVI solution for link-local 170 addresses, e.g., the SAVI-FCFS [RFC6620]. 172 This mechanism works with DHCPv4 and DHCPv6. However, the DHCP 173 address assignment mechanims in IPv4/IPv6 transition scenarios, e.g., 174 [I-D.ietf-dhc-dhcpv4-over-dhcpv6], are beyond the scope of this 175 document. 177 2. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 3. Terminology 185 Binding anchor: A "binding anchor" is defined to be a link layer 186 property of network attachment in [RFC7039]. A list of proper 187 binding anchors can be found in Section 3.2 of [RFC7039]. 189 Attribute: A configurable property of each network attachment which 190 indicates the actions to be performed on packets received from the 191 network attachment. 193 DHCP address: An IP address assigned via DHCP. 195 SAVI-DHCP: The name of this SAVI function for DHCP address. 197 SAVI device: A network device on which this SAVI function is enabled. 199 Non-SAVI device: A network device on which this SAVI function is not 200 enabled. 202 DHCP Client-Server message: A message that is sent from a DHCP client 203 to a DHCP server or DHCP servers. Such a message is of one of the 204 following types: 206 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 208 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 209 [RFC2131] 211 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 212 [RFC2131] 214 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 215 [RFC2131] 217 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 218 [RFC2131] 220 o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be 221 identified based on the Table 4 of [RFC2131] 223 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 225 o DHCPv4 Release: DHCPRELEASE [RFC2131] 227 o DHCPv4 Inform: DHCPINFORM [RFC2131] 229 o DHCPv6 Request: REQUEST [RFC3315] 231 o DHCPv6 Solicit: SOLICIT [RFC3315] 233 o DHCPv6 Confirm: CONFIRM [RFC3315] 235 o DHCPv6 Decline: DECLINE [RFC3315] 237 o DHCPv6 Release: RELEASE [RFC3315] 239 o DHCPv6 Rebind: REBIND [RFC3315] 240 o DHCPv6 Renew: RENEW [RFC3315] 242 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 244 DHCP Server-Client message: A message that is sent from a DHCP server 245 to a DHCP client. Such a message is of one of the following types: 247 o DHCPv4 ACK: DHCPACK [RFC2131] 249 o DHCPv4 NAK: DHCPNAK [RFC2131] 251 o DHCPv4 Offer: DHCPOFFER [RFC2131] 253 o DHCPv6 Reply: REPLY [RFC3315] 255 o DHCPv6 Advertise: ADVERTISE [RFC3315] 257 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 259 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 260 IPv6 [RFC3315]. 262 Binding entry: An 'permit' rule that defines a valid association 263 between an IP address and a binding anchor. 265 Binding State Table (BST): The data structure that contains all the 266 binding entries. 268 Binding entry limit: The maximum number of binding entries that may 269 be associated with any binding anchor. Limiting the number of 270 binding entries per binding anchor prevents a malicious or 271 malfunctioning node from overloading the binding table on a SAVI 272 device. 274 Direct attachment: Ideally, a SAVI device should be an access device 275 which is directly attached by hosts. In such case, the hosts are 276 direct attachments of the SAVI device. 278 Indirect attachment: A SAVI device can be an aggregation device which 279 is connected with a number of access devices, which are attached by 280 hosts. In such case, the hosts are indirect attachments of the SAVI 281 device. Sometimes, it is expressed as "the hosts are indirectly 282 attached to the SAVI device". 284 Upstream link: Upstream links are links connected to non-SAVI devices 285 from which the valid source address space of traffic contains the 286 prefixes of other networks. 288 Upstream device: An upstream device is a non-SAVI device associated 289 with an upstream link. For example, the gateway router of the 290 network. 292 Downstream link: Downstream links are links connected to non-SAVI 293 devices from which the valid source address space of traffic only 294 contains the prefix(es) of the local network. 296 Downstream device: A downstream device is a non-SAVI device 297 associated with an downstream link. For example, an access switch in 298 the network. 300 CUT VERTEX: A cut vertex is 'any vertex whose removal increases the 301 number of connected components'. This is a concept in graph theory. 302 This term is used in Section 6.1 to accurately specify the required 303 deployment location of SAVI devices when they only perform the DHCP 304 snooping process. 306 Identity Association (IA): "A collection of addresses assigned to a 307 client." [RFC3315] 309 Detection message: a Neighbor Solicitation or ARP message intended to 310 detect a duplicate address by the Data Snooping Process. 312 DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the 313 binding is triggered by a DHCPv6 Confirm message but a DHCPv6 314 leasequery exchange [RFC5007] cannot be performed by the SAVI device 315 to fetch the lease. 317 4. Deployment Scenario and Configuration 319 4.1. Elements and Scenario 321 A list of essential elements in a SAVI-DHCP deployment scenario is 322 given as follows: 324 (1) DHCP server 326 (2) DHCP client 328 (3) SAVI device 330 And there may be following optional elements in a SAVI-DHCP 331 deployment scenario: 333 (1) DHCP relay 335 (2) Non-SAVI device 336 Figure 1 shows a deployment scenario that contains these elements. 337 Note that a physical device can be multiple elements, e.g, a switch 338 can be both a SAVI device and a DHCP relay. In such cases, the links 339 are logic links rather than physical links. The "Bogus DHCP Server" 340 is only used to help illustrate the case in Section 4.3.3, but not a 341 necessary element. 343 +--------+ +------------+ +----------+ 344 |DHCP |-----| Non-SAVI |----|Bogus DHCP| 345 |Server A| | Device 1 | |Server | 346 +--------+ +-----|------+ +----------+ 347 ......................|............................ 348 . | upstream link . 349 . Protection +---|------+ . 350 . Perimeter | SAVI |--------------+ . 351 . | Device C| | . 352 . +---|------+ | . 353 . | | . 354 . +----------+ +---|------+ +------|---+ . 355 downstream . | SAVI | | Non SAVI| | SAVI | . 356 link +----.-| Device A|----| Device 3|-------| Device B| . 357 | . +----|--|--+ +----------+ +-|---|----+ . 358 | . | +----------+ ............ | | . 359 | '.............. | . . | | . 360 | | . | . +--------+ | . 361 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 362 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 363 | Device 2 | |A | . |Relay | . |B | . |Server B| . 364 +----------+ +------+ . +------+ . +------+ . +--------+ . 365 ............ ............... 367 Figure 1: SAVI-DHCP Scenario 369 Networks are not isolated and traffic from other networks, i.e., 370 transit traffic specified in [RFC6620], may get into the network with 371 SAVI-DHCP deployed through the upstream links. Since SAVI solutions 372 are limited to check traffic generated from local link, SAVI-DHCP is 373 not to set up bindings for addresses assigned in other networks. 374 Thus, SAVI-DHCP will not set up bindings for addresses appearing on 375 upstream links and will not check data traffic from upstream links. 376 This is why to distinguish upstream/downstream links is essential for 377 SAVI-DHCP. The traffic from upstream links should be checked by a 378 prefix granularity source address validation mechanism to avoid 379 spoofing of local addresses from other networks. How to generate and 380 deploy such a mechanism is beyond the scope of this document. 382 However, traffic from downstream links are generated from local 383 network. For example, a hub, which is attached by some DHCP clients, 384 is on the downstream link of a SAVI device. The traffic from 385 downstream links should be checked by SAVI-DHCP if possible. 386 However, because DHCP clients on the downstream links are indirectly 387 attached, the security problem caused by shared binding anchor, as 388 described in Section 4.3.5, can be introduced. 390 4.2. Attribute 392 As illustrated in Figure 1, an attachment to a SAVI device can be 393 from either a DHCP client, or a DHCP relay/server, or a SAVI device, 394 or a non-SAVI device. Different actions are performed on traffic 395 originated from different elements. To distinguish different types 396 of attachments, an attachment property named 'attribute' is 397 configured on SAVI devices. This section specifies the attributes 398 used by SAVI-DHCP. 400 Before configuration, an attachment is with no attribute. An 401 attachment MAY be configured to have one or more compatible 402 attributes (refer to Section 4.2.6). The attributes of each 403 attachment MUST be configured before the SAVI-DHCP function is 404 enabled. The procedure performed by SAVI devices on traffic from 405 each attachment is determined by the attribute(s) set on the 406 attachment. 408 Particularly, if an attachment has no attribute, data traffic from 409 this attachment will not be checked by SAVI-DHCP and will be 410 forwarded directly. This prevents SAVI-DHCP from causing a break in 411 the network when it is turned on without any binding anchors 412 configured. However, if a binding anchor has no attribute, this 413 means that the SAVI-DHCP-Trust attribute is not present. Because of 414 this, DHCP server-client messages associated to this binding anchor 415 will be discarded. This prevents a host from connecting to an 416 unconfigured binding anchor and acting as a DHCP server. It is 417 SUGGESTED to configure SAVI-DHCP-Trust on necessary binding anchors 418 before turning on the SAVI-DHCP function. 420 Binding anchors associated with upstream links MAY have no attribute 421 after configuration. For example, in Figure 1, the attachment from 422 the Non-SAVI Device 1 to the SAVI Device C should be configured with 423 no attribute. It means 1) SAVI devices will neither set up bindings 424 for upstream hosts nor check traffic from upstream hosts; 2) SAVI 425 devices will drop DHCP server-client messages from upstream devices 426 unless the DHCP-Trust attribute (refer to Section 4.2.2) is set on 427 the corresponding attachment. The reason that DHCP messages from 428 upstream devices are not trusted is discussed in Section 4.3.3. 430 4.2.1. Trust Attribute 432 The "Trust Attribute" indicates the packets from the corresponding 433 attachment are completely trustable. 435 SAVI devices will not set up bindings for attachments with Trust 436 attribute; DHCP messages and data packets from such attachments with 437 this attribute will not be checked. If the DHCP Server-Client 438 messages from attachments with this attribute can trigger the state 439 transitions specified in Section 6 and Section 7, these messages will 440 be handled by the corresponding processes in Section 6 and Section 7. 442 This attribute is generally configured on the attachments from other 443 SAVI devices. For example, in Figure 1, the attachment from the SAVI 444 Device B to the SAVI Device C and the attachment from the SAVI Device 445 C to the SAVI Device B should be configured with this attribute. 446 Besides, it can be configured on attachments from Non-SAVI devices 447 only if the Non-SAVI devices will not introduce unchecked traffic 448 from DHCP clients. For example, the attachments from Non-SAVI device 449 3 to SAVI device A, SAVI device B and SAVI device C can be configured 450 with this attribute, only if Non-SAVI device 3 does not have 451 attachment from DHCP clients. 453 4.2.2. DHCP-Trust Attribute 455 The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages 456 from the corresponding attachment is trustable. 458 SAVI devices will forward DHCP Server-Client messages coming from the 459 attachments with this attribute. If the DHCP Server-Client messages 460 can trigger the state transitions, they will be handled by the 461 binding setup processes specified in Section 6 and Section 7. 463 This attribute is generally used on the direct attachments from the 464 trusted DHCP servers/relays. In Figure 1, the attachment from the 465 DHCP Relay to the SAVI Device A, and the attachment from the DHCP 466 Server B to the SAVI Device B should be configured with this 467 attribute. It is NOT RECOMMENDED to configure this attribute on any 468 indirect attachment point of the non-neighboring DHCP servers and 469 relays, unless all the elements that can be reached through that 470 attachment point can be trusted, i.e., bogus DHCP Server-Client 471 messages will not be generated by these elements. For example, in 472 Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI 473 Device C should not be configured with this attribute. This issue is 474 discussed in Section 4.3.3. 476 The implementation for DHCPv6 can refer to 477 [I-D.ietf-opsec-dhcpv6-shield] for more details. 479 4.2.3. DHCP-Snooping Attribute 481 The "DHCP-Snooping Attribute" indicates bindings will be set up based 482 on DHCP snooping. 484 DHCP Client-Server messages from attachments with this attribute will 485 trigger the setup of bindings. SAVI devices will set up bindings on 486 attachments with this attribute based on the DHCP snooping procedure 487 described in Section 6. 489 DHCP-Snooping attribute is configured on the attachments from DHCP 490 clients. This attribute can be also used on the attachments from 491 downstream Non-SAVI devices which are attached by DHCP clients. In 492 Figure 1, the attachment from the Client A to the SAVI Device A, the 493 attachment from the Client B to the SAVI Device B, and the attachment 494 from the Non-SAVI Device 2 to the SAVI Device A can be configured 495 with this attribute. 497 Whenever this attribute is set on an attachment, the "Validating 498 Attribute" MUST be set on the same attachment. 500 4.2.4. Data-Snooping Attribute 502 The "Data-Snooping Attribute" indicates data packets from the 503 corresponding attachment may trigger binding setup procedure. 505 Data packets from attachments with this attribute may trigger the 506 setup of bindings. SAVI devices will set up bindings on attachments 507 with this attribute based on the data-triggered process described in 508 Section 7. 510 If DHCP-Snooping attribute is configured on an attachment, the 511 bindings on this attachment are set up based on DHCP message 512 snooping. However, in some scenarios, a DHCP address may be used by 513 a DHCP client without DHCP address assignment procedure performed on 514 its current attachment. For such attachments, the Data-Snooping 515 process, which is described in Section 7, is necessary. This 516 attribute is configured on such attachments. The usage of this 517 attribute is further discussed in Section 7. 519 Whenever this attribute is set on an attachment, the "Validating 520 Attribute" MUST be set on the same attachment. 522 4.2.5. Validating Attribute 524 The "Validating Attribute" indicates packets from the corresponding 525 attachment will be checked based on binding entries on the 526 attachment. 528 Packets coming from attachments with this attribute will be checked 529 based on binding entries on the attachment as specified in Section 8. 531 Validating attribute is configured on the attachments from which the 532 data packets should be checked. For example, the DHCP clients. 534 This attribute MUST be used together with "DHCP-Snooping Attribute" 535 or "Data-Snooping Attribute". 537 4.2.6. Table of Mutual Exclusions 539 Different types of attributes may indicate mutually exclusive actions 540 on packet. Mutually exclusive attributes MUST NOT be set on the same 541 attachment. The compatibility of different attributes is listed in 542 Figure 2. Note that although Trust and DHCP-Trust are compatible, 543 there is no need to configure DHCP-Trust on an attachment with Trust 544 attribute. 546 +----------+----------+----------+----------+----------+----------+ 547 | | | | DHCP- | Data- | | 548 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 549 +----------+----------+----------+----------+----------+----------+ 550 | | | | mutually | mutually | mutually | 551 | Trust | - |compatible| exclusive| exclusive| exclusive| 552 +----------+----------+----------+----------+----------+----------+ 553 | | | | | | | 554 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 555 +----------+----------+----------+----------+----------+----------+ 556 |DHCP- |mutually | | | | | 557 |Snooping |exclusive |compatible| - |compatible|compatible| 558 +----------+----------+----------+----------+----------+----------+ 559 |Data- |mutually | | | | | 560 |Snooping |exclusive |compatible|compatible| - |compatible| 561 +----------+----------+----------+----------+----------+----------+ 562 | |mutually | | | | | 563 |Validating|exclusive |compatible|compatible|compatible| - | 564 +----------+----------+----------+----------+----------+----------+ 566 Figure 2: Table of Mutual Exclusions 568 4.3. Perimeter 570 4.3.1. SAVI-DHCP Perimeter Overview 572 SAVI devices can form a perimeter separating untrusted and trusted 573 areas, similarly to SAVI-FCFS (refer to Section 2.5 of [RFC6620]). 574 Each SAVI device need only establish bindings for a client if it is 575 connected to that client by a link that crosses the perimeter that 576 encloses the SAVI device. 578 The perimeter is primarily designed for scalability. This has two 579 implications. First, SAVI devices only need to establish bindings 580 for directly attached clients, or clients indirectly attached through 581 non-SAVI device, rather than all the clients in the network. Second, 582 each SAVI device only need to check traffic from clients attached to 583 it, without checking all the traffic passing by. 585 Consider the example in Figure 1. The protection perimeter is formed 586 by SAVI Device A, B and C. In this case, SAVI device B doesn't 587 create a binding for client A. However, because SAVI device A 588 filters spoofing traffic from client A, SAVI device B can avoid 589 receiving spoofing traffic from client A. 591 The perimeter in SAVI-DHCP is not only a perimeter for data packets, 592 but also a perimeter for DHCP messages. The placement of DHCP Relay/ 593 Server, which is not involved in [RFC6620] , is related with the 594 construction of the perimeter. The requirement on the placement and 595 configuration of DHCP Relay/Server are discussed in Section 4.3.3. 597 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 599 Through configuring attribute of each attachment properly, a 600 perimeter separating untrusted area and trusted area MUST be formed 601 as follows: 603 (1) Configure Validating and DHCP-Snooping attribute on the direct 604 attachments of all the DHCP clients. 606 (2) Configure Validating and DHCP-Snooping attribute on the indirect 607 attachments of all the DHCP clients (i.e., DHCP clients on the 608 downstream links). 610 (3) Configure Trust attribute on the attachments of other SAVI 611 devices. 613 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 614 have only attachments from SAVI devices, set their attachments to 615 SAVI devices with Trust attribute. 617 (5) Configure DHCP-Trust attribute on the direct attachments of 618 trusted DHCP relays/servers. 620 In this way, the points of attachments with Validating attribute (and 621 generally together with attachments of upstream devices) on SAVI 622 devices can form a perimeter separating DHCP clients and trusted 623 devices. Data packet check is only performed on the perimeter. The 624 perimeter is also a perimeter for DHCP messages. DHCP-Trust 625 attribute is only configured on the inside links of the perimeter. 626 Only DHCP server-client messages originated in the perimeter are 627 trusted. 629 4.3.3. On the Placement of DHCP Server/Relay 631 Based on the configuration guideline, it can be found that the SAVI 632 devices only trust DHCP Server-Client messages originated inside the 633 perimeter. It means the trusted DHCP relays/servers must be placed 634 in the perimeter. DHCP server-client messages will be filtered on 635 the perimeter (Note: server-relay messages will not be filtered). In 636 this way, DHCP server-client messages from bogus DHCP servers are 637 filtered on the perimeter, and then the SAVI devices can be protected 638 from forged DHCP messages. 640 Such a requirement is due to the limitation of this binding based 641 mechanism. This document makes no assumption that the DHCP server- 642 client messages arriving the perimeter from the outside can be 643 trusted. The binding anchor of a trusted remote DHCP server can be 644 shared by a bogus DHCP server. Thus, the SAVI device cannot 645 distinguish bogus and valid DHCP messages only based on the 646 associated binding anchor of DHCP messages in such case. 648 Note that even if a DHCP server is valid, it may be not contained in 649 the perimeter based on the guideline. For example, in Figure 1, DHCP 650 server A is valid, but it is attached to a Non-SAVI device. The Non- 651 SAVI device may be attached by attackers which generate forged DHCP 652 messages. This binding based mechanism may not have the ability to 653 distinguish whether a message received from the attachment of the 654 Non-SAVI device 1 is from DHCP server A or the attackers. If the 655 DHCP server A is contained in the perimeter, the Non-SAVI device 1 656 will also be contained in the perimeter. However, the Non-SAVI 657 device 1 can introduce forged DHCP messages into the perimeter. 658 Thus, the DHCP server A cannot be contained in the perimeter. 660 In this case, the SAVI devices can set up bindings for addresses 661 assigned by DHCP server A through snooping the messages relayed by 662 trusted relay in the network. For example, the DHCP relay may relay 663 messages between DHCP server A and the clients in the network, and 664 the SAVI devices can snoop messages from the DHCP relay which is 665 inside the perimeter. The authentication mechanism (i.e., IPsec, as 666 specified in section 21.1 of [RFC3315]) enforced between the DHCP 667 relay and the DHCP server outside the perimeter can compensate this 668 binding based mechanism. It is SUGGESTED to configure IPsec between 669 the DHCP relay and the DHCP server in such case. If source address 670 validation is enforced in the whole network, which makes the source 671 IP address trustable, the DHCP relay and the DHCP server can simply 672 authenticate the messages from each other based on the source IP 673 address. Nevertheless, it should be noted that the integrity of the 674 messages is not ensured. 676 Another consideration on the placement is that if the DHCP server/ 677 relay is not inside the perimeter, the SAVI devices may not be able 678 to set up bindings correctly, because the SAVI devices may not be on 679 the path between the clients and the server/relay, or the DHCP 680 messages are encapsulated (e.g., Relay-reply and Relay-forward). 682 4.3.4. An alternative deployment 684 In a number of deployment practices, the traffic from the upstream 685 network are all treated as trustable. In such a case, Trust 686 attribute can be set on the upstream link; and if a Non-SAVI device, 687 or a number of connected Non-SAVI devices, have only attachments from 688 SAVI devices and upstream devices, their attachment to SAVI devices 689 can be set Trust attribute. Then an unclosed perimeter will be 690 formed, as illustrate in Figure 3. 692 | . . Protection | 693 | | | Perimeter | 694 | | | | 695 | Upstream | | Upstream | 696 | Link | | Link | 697 | | | | 698 | | | | 699 | +--------+ +--------+ +--------+ | 700 | |SAVI |----|Non-SAVI|----|SAVI | | 701 | |Device | |Device | |Device | | 702 | +--------+ +--------+ +--------+ | 703 | | | | 704 \________________________________________________/ 705 | | 706 | | 707 +--------+ +--------+ 708 |DHCP | |DHCP | 709 |Client | |Client | 710 +--------+ +--------+ 712 Figure 3: Alternative Perimeter Configuration 714 To configure such a perimeter, at least the DHCP messages from 715 upstream networks MUST be ensured to be trustable. How to achieve 716 this is beyond the scope of this document. 718 4.3.5. Considerations on Binding Anchor 720 The strength of this binding based mechanism depends on the strength 721 of the binding anchor. If the binding anchor is spoofable, e.g., 722 plain MAC address, an attacker can use forged binding anchor to send 723 packet which will not be regarded as spoofing by SAVI device. 724 Indeed, using binding anchor that can be easily spoofed can lead to 725 worse outcomes than allowing IP spoofing traffic. For example, an 726 attacker can use the binding anchor of another client to bind a large 727 number of addresses, and the SAVI device will refuse to set up new 728 binding for the client whenever the binding number limitation has 729 been reached; as a result, even the legitimate clients cannot access 730 the network. Thus, it is RECOMMENDED to use unspoofable binding 731 anchor, e.g., switch port. This document only focuses on switch port 732 as binding anchor. The implications of using other forms of binding 733 anchors should be properly analyzed. 735 If the binding anchor is shared by more than one clients, the clients 736 can spoof each other addresses. For example, if a switch port is 737 used as binding anchor, a number of clients can attach to the same 738 switch port of a SAVI device through a hub. The SAVI device cannot 739 distinguish packets from different clients and thus the spoofing 740 between them will not be detected. A number of the above security 741 problems are caused by sharing binding anchors. For example, an 742 attacker can send a DHCP Release message to remove the binding of a 743 client sharing the same binding anchor. Thus, it is RECOMMENDED to 744 use exclusive binding anchor. 746 5. Binding State Table (BST) 748 Binding State Table is used to contain the bindings between the IP 749 addresses assigned to the attachments and the corresponding binding 750 anchors of the attachments. Each entry of the table, i.e., binding 751 entry, has 5 fields: 753 o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer 754 property of the attachment. 756 o IP Address(Address): the IP address assigned to the attachment by 757 DHCP. 759 o State: the state of the binding. Possible values of this field 760 are listed in Section 6.2 and Section 7.3. 762 o Lifetime: the remaining seconds of the binding. The Lifetime 763 field counts down automatically. 765 o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of 766 the corresponding DHCP transaction. TID field is used to 767 associate DHCP Server-Client messages with corresponding binding 768 entries. 770 IA does not present in the BST because the lease of each address in 771 one IA is assigned respectively. Another reason is, when the binding 772 is set up based on data-snooping, IA cannot be recovered from the 773 leasequery protocol. Last reason is there is no IA for DHCPv4. 775 An instance of this table is shown in Figure 4. 777 +---------+----------+----------+-----------+-------+ 778 | Anchor | Address | State | Lifetime |TID | 779 +---------+----------+----------+-----------+-------+ 780 | Port_1 | IP_1 | BOUND | 65535 |TID_1 | 781 +---------+----------+----------+-----------+-------+ 782 | Port_1 | IP_2 | BOUND | 10000 |TID_2 | 783 +---------+----------+----------+-----------+-------+ 784 | Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | 785 +---------+----------+----------+-----------+-------+ 787 Figure 4: Instance of BST 789 6. DHCP Snooping Process 791 This section specifies the process of setting up bindings based on 792 DHCP snooping, named DHCP Snooping Process. This process is 793 illustrated making use of a state machine. 795 6.1. Rationale 797 The rationale of the DHCP Snooping Process is that if a DHCP client 798 is legitimate to use a DHCP address, the DHCP address assignment 799 procedure which assigns the IP address to the client must have been 800 performed on the attachment of the client. This basis stands when 801 the SAVI device is always on the path(s) from the DHCP client to the 802 DHCP server(s)/relay(s). Without considering the movement of DHCP 803 clients, the SAVI device should be the CUT VERTEX whose removal will 804 disjoin the DHCP client and the remaining network containing the DHCP 805 server(s)/relay(s). For most of the networks whose topologies are 806 simple, it is possible to deploy this SAVI function at proper devices 807 to meet this requirement. 809 However, a deployment of this SAVI function may not meet the 810 requirement. For example, there are multiple paths from a DHCP 811 client to the DHCP server and the SAVI device is only on one of them. 812 Then the SAVI device may not be able to snoop the DHCP procedure. 813 Host movement may also make this requirement can not be met. For 814 example, when a DHCP client moves from one attachment to another 815 attachment in the same network, it may not reinitialize its interface 816 or send a Confirm message because of incomplete protocol 817 implementation. Thus, there can be scenarios in which only 818 performing this DHCP snooping process is insufficient to set up 819 bindings for all the valid DHCP addresses. These exceptions and the 820 solutions are discussed in Section 7. 822 6.2. Binding States Description 824 Following binding states present in this process and the 825 corresponding state machine: 827 NO_BIND: The state before a binding has been set up. 829 INIT_BIND: A potential binding has been set up. 831 BOUND: The binding has been set up. 833 6.3. Events 835 This section describes events in this process and the corresponding 836 state machine. 838 6.3.1. Timer Expiration Event 840 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 842 6.3.2. Control Message Arriving Events 844 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 845 received. 847 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 849 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 851 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 852 received. 854 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 856 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 857 option is received. 859 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 861 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 862 received. 864 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 865 received. 867 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 868 section 4.3.3 of [RFC5007]) is received. 870 Note: the events listed here do not cover all the DHCP messages in 871 section 3. The messages which do not really determine address usage 872 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 873 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 874 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 875 to section 6.4.2.1), are not included. 877 Moreover, only if a DHCP message can pass the following checks, the 878 corresponding event is regarded as a valid event: 880 o Attribute check: the DHCP Server-Client messages and 881 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 882 attribute; the DHCP Client-Server messages should be from 883 attachments with DHCP-Snooping attribute. 885 o Destination check: the DHCP Server-Client messages should be 886 destined to attachments with DHCP-Snooping attribute. This check 887 is performed to ensure the binding is set up on the SAVI device 888 which is nearest to the destination client. 890 o Binding anchor check: the DHCP Client-Server messages which may 891 trigger modification or removal of an existing binding entry must 892 have matched binding anchor with the corresponding entry. 894 o TID check: the DHCP Server-Client/Client-Server messages which may 895 cause modification on existing binding entries must have matched 896 TID with the corresponding entry. Note that this check is not 897 performed on Leasequery and Leasequery-reply messages as they are 898 exchanged between the SAVI devices and the DHCP servers. Besides, 899 this check is not performed on DHCP Renew/Rebind messages 900 (Section 6.4.3). 902 o Binding limitation check: the DHCP messages must not cause new 903 binding setup on an attachment whose binding entry limitation has 904 been reached. (refer to Section 11.6). 906 o Address check: the source address of the DHCP messages should pass 907 the check specified in Section 8.2. 909 On receiving a DHCP message without triggering a valid event, the 910 state will not transit and actions will not be performed. Note that 911 if a message does not trigger a valid event but it can pass the 912 checks in Section 8.2, it MUST be forwarded. 914 6.4. The State Machine of DHCP Snooping Process 916 This section specifies the transits of each state and the 917 corresponding actions. 919 6.4.1. From NO_BIND to INIT_BIND 921 6.4.1.1. Trigger Events 923 Trigger events: EVE_DHCP_REQUEST, EVE_DHCP_SOLICIT_RC, 924 EVE_DHCP_CONFIRM, EVE_DHCP_REBOOT. 926 6.4.1.2. Following Actions 928 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_SOLICIT_RC/ 929 EVE_DHCP_REBOOT: 931 The SAVI device MUST forward the message. 933 The SAVI device will generate an entry in the BST. The Binding 934 anchor field is set to the binding anchor of the attachment from 935 which the message is received. The State field is set to INIT_BIND. 936 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 937 field is set to the TID of the message. If the message is DHCPv4 938 Request or DHCPv4 Reboot, the Address field can be set to the address 939 to request, i.e., the 'requested IP address'. An example of the 940 entry is illustrated in Figure 5. 942 +---------+-------+---------+-----------------------+-------+ 943 | Anchor |Address| State | Lifetime |TID | 944 +---------+-------+---------+-----------------------+-------+ 945 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 946 +---------+-------+---------+-----------------------+-------+ 948 Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot 949 triggered initialization 951 If the triggering event is EVE_DHCP_CONFIRM: 953 The SAVI device MUST forward the message. 955 The SAVI device will generate corresponding entries in the BST for 956 all the addresses in each the IA option of the Confirm message. The 957 Binding anchor field is set to the binding anchor of the attachment 958 from which the message is received. The State field is set to 959 INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. 961 The TID field is set to the TID of the message. The Address field is 962 set to the address(es) to confirm. An example of the entries is 963 illustrated in Figure 6. 965 +---------+--------+---------+-----------------------+-------+ 966 | Anchor | Address| State | Lifetime |TID | 967 +---------+--------+---------+-----------------------+-------+ 968 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 969 +---------+--------+---------+-----------------------+-------+ 970 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 971 +---------+--------+---------+-----------------------+-------+ 973 Figure 6: Binding entry in BST on Confirm triggered initialization 975 6.4.2. From INIT_BIND to Other States 977 6.4.2.1. Trigger Events 979 Trigger events: EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE. 981 Note: If no DHCP Server-Client messages which assign addresses or 982 confirm addresses are received, corresponding entries will expire 983 automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4 984 NAK) are not specially processed. 986 6.4.2.2. Following Actions 988 If the trigger event is EVE_DHCP_REPLY: 990 The message MUST be forwarded to the corresponding client. 992 If the message is DHCPv4 ACK, the Address field of the corresponding 993 entry (i.e., the binding entry whose TID is the same of the message) 994 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 995 The Lifetime field is set to the sum of the lease time in ACK message 996 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 998 If the message is DHCPv6 Reply, there are following cases: 1000 1. If the status code is not "Success", no modification on 1001 corresponding entries will be made. Corresponding entries will 1002 expire automatically if no "Success" Reply is received during the 1003 lifetime. The entries are not removed immediately due to the client 1004 may be able to use the addresses whenever a "Success" Reply is 1005 received ("If the client receives any Reply messages that do not 1006 indicate a NotOnLink status, the client can use the addresses in the 1007 IA and ignore any messages that indicate a NotOnLink status." 1008 [RFC3315]). 1010 2. If the status code is "Success", the SAVI device checks the IA 1011 options in the Reply message. 1013 2.1 If there are no IA options in the Reply message, the DHCP Reply 1014 message is in response to a Confirm message. The state of the 1015 binding entries with matched TID is changed to BOUND. Because 1016 [RFC3315] does not require lease time of addresses to be contained in 1017 the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] 1018 message querying by IP address to All_DHCP_Servers multicast address 1019 [RFC3315] or a list of configured DHCP server addresses. The 1020 Leasequery message is generated for each IP address if multiple 1021 addresses are confirmed. The Lifetime of corresponding entries is 1022 set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after 1023 MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example 1024 of the entries is illustrated in Figure 7. The related security 1025 problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the 1026 SAVI device does not send the LEASEQUERY message, a pre-configured 1027 lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 1028 (Note: it is SUGGESUTED to use T1 configured on DHCP servers as the 1029 DHCP_DEFAULT_LEASE.) 1031 2.2 If there are IA options in the Reply message, the SAVI device 1032 checks each IA option. When the first assigned address is found, the 1033 Address field of the binding entry with matched TID is set to the 1034 address. The Lifetime field is set to the sum of the lease time in 1035 Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed 1036 to BOUND. If there are more than one address assigned in the 1037 message, new binding entries are set up for the remaining address 1038 assigned in the IA options. An example of the entries is illustrated 1039 in Figure 8. SAVI devices do not specially process IA options with 1040 NoAddrsAvail status, because there should be no address contained in 1041 such IA options. 1043 Note: the SAVI devices do not check if the assigned addresses are 1044 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 1045 only source of valid addresses. However, the DHCP servers should be 1046 configured to make sure no duplicated addresses are assigned. 1048 +---------+----------+-------+------------------------+-------+ 1049 | Anchor | Address | State | Lifetime |TID | 1050 +---------+----------+-------+------------------------+-------+ 1051 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1052 +---------+----------+-------+------------------------+-------+ 1053 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1054 +---------+----------+-------+------------------------+-------+ 1056 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1057 Confirm 1059 +---------+----------+-------+------------------------+-------+ 1060 | Anchor | Address | State | Lifetime |TID | 1061 +---------+----------+-------+------------------------+-------+ 1062 | Port_1 | Addr1 | BOUND |Lease time+ |TID | 1063 | | | |MAX_DHCP_RESPONSE_TIME | | 1064 +---------+----------+-------+------------------------+-------+ 1065 | Port_1 | Addr2 | BOUND |Lease time+ |TID | 1066 | | | |MAX_DHCP_RESPONSE_TIME | | 1067 +---------+----------+-------+------------------------+-------+ 1069 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 1070 Request 1072 If the trigger event is EVE_ENTRY_EXPIRE: 1074 The entry MUST be deleted from BST. 1076 6.4.3. From BOUND to Other States 1078 6.4.3.1. Trigger Events 1080 Trigger events: EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 1081 EVE_DHCP_REPLY, EVE_DHCP_LEASEQUERY, EVE_DHCP_RENEW, EVE_DHCP_REBIND. 1083 6.4.3.2. Following Actions 1085 If the trigger event is EVE_ENTRY_EXPIRE: 1087 Remove the corresponding entry in BST. 1089 If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE: 1091 The message MUST be forwarded. 1093 The SAVI device first gets all the addresses ("Requested IP address" 1094 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1095 IA options of DHCPv6 Decline/Release) to decline/release in the 1096 message. Then the corresponding entries MUST be removed. 1098 If the trigger event is EVE_DHCP_RENEW/EVE_DHCP_REBIND: 1100 The message MUST be forwarded. 1102 In such case, a new TID will be used by the client. The TID field of 1103 the corresponding entries MUST be set to the new TID. Note that TID 1104 check will not be performed on such messages. 1106 If the trigger event is EVE_DHCP_REPLY: 1108 The message MUST be forwarded. 1110 The DHCP Reply messages received in current states should be in 1111 response to DHCP Renew/Rebind. 1113 If the message is DHCPv4 ACK, the SAVI device just simply update the 1114 binding entry with matched TID, with the Lifetime field set to be the 1115 sum of the new lease time and MAX_DHCP_RESPONSE_TIME. 1117 If the message is DHCPv6 Reply, the SAVI device checks each IA 1118 Address option in each IA option. If the valid lifetime of an IA 1119 address option is 0, the binding entry with matched TID and address 1120 is removed. Or else, set the Lifetime field of the binding entry 1121 with matched TID and address to be the sum of the new valid lifetime 1122 and MAX_DHCP_RESPONSE_TIME. 1124 The SAVI device does not specially process IA options in Reply 1125 message with status NoBinding, because no address is contained in 1126 such IA options and no actions will be performed. 1128 If the trigger event is EVE_DHCP_LEASEQUERY: 1130 The message MUST be forwarded. 1132 The message should be in response to the Leasequery message sent in 1133 Section 6.4.2. The related binding entry can be determined based on 1134 the address in the IA Address option in the Leasequery-reply message. 1135 The Lifetime field of the corresponding binding entry is set to the 1136 sum of the lease time in the LEASEQUERY_REPLY message and 1137 MAX_DHCP_RESPONSE_TIME. 1139 6.5. Table of State Machine 1141 The main state transits are listed as follows. Note that not all the 1142 details are specified in the table and the diagram. 1144 State Event Action Next State 1145 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1146 INIT_BIND RPL Record lease time BOUND 1147 (send lease query if no lease) 1148 INIT_BIND Timeout Remove entry NO_BIND 1149 BOUND RLS/DCL Remove entry NO_BIND 1150 BOUND Timeout Remove entry NO_BIND 1151 BOUND RPL Set new lifetime BOUND 1152 BOUND LQR Record lease time BOUND 1154 Figure 9: Table of Transit 1156 RQ: EVE_DHCP_REQUEST 1158 CF: EVE_DHCP_CONFIRM 1160 RC: EVE_DHCP_SOLICIT_RC 1162 RE: EVE_DHCP_REBOOT 1164 RPL: EVE_DHCP_REPLY 1166 DCL: EVE_DHCP_DECLINE 1168 RLS: EVE_DHCP_RELEASE 1170 LQR: EVE_DHCP_LEASEQUERY 1172 Timeout: EVE_ENTRY_EXPIRE 1173 +-------------+ 1174 | | 1175 /---------| NO_BIND |<----------\ 1176 | ------>| | | 1177 | | +-------------+ |EVE_DHCP_RELEASE 1178 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1179 EVE_DHCP_CONFIRM | |TIMEOUT |TIMEOUT 1180 EVE_DHCP_SOLICIT_RC| | | 1181 EVE_DHCP_REBOOT | | | 1182 | | | 1183 | | | 1184 v | | 1185 +-------------+ +------------+ 1186 | | EVE_DHCP_REPLY | | 1187 | INIT_BIND ------------------------>| BOUND |<-\ 1188 | | | | | 1189 +-------------+ +------------+ | 1190 | | 1191 \--------/ 1192 EVE_DHCP_REPLY 1193 EVE_DHCP_LEASEQUERY 1195 Figure 10: Diagram of Transit 1197 7. Data Snooping Process 1199 7.1. Scenario 1201 The rationale of the DHCP Snooping Process specified in Section 6 is 1202 that if a DHCP client's use of a DHCP address is legitimate, the 1203 corresponding DHCP address assignment procedure must have been 1204 finished on the attachment of the DHCP client. This is the case 1205 stands when the SAVI device is persistently on the path(s) from the 1206 DHCP client to the DHCP server(s)/relay(s). However, there are two 1207 case when this does not work: 1209 o Multiple paths: there is more than one feasible layer-2 paths from 1210 the client to the DHCP server/relay, and the SAVI device is not on 1211 everyone of them. The client may get its address through one of 1212 the paths not passing by the SAVI device, but packets from the 1213 client can travel through paths that pass through the SAVI device. 1214 Because the SAVI device could not snoop the DHCP packet exchange 1215 procedure, the DHCP snooping procedure cannot set up the 1216 corresponding binding. 1218 o Dynamic path: there is only one feasible layer-2 path from the 1219 client to the DHCP server/relay, but the path is dynamic due to 1220 topology change (for example, some link turns broken due to 1221 failure or as planned) or layer-2 path change. This situation 1222 also covers the local-link movement of clients without address 1223 confirm/re-configuration process. For example, a host changes its 1224 attached switch port in a very short time. In such cases, the 1225 DHCP snooping process will not set up the corresponding binding. 1227 Data Snooping Process prevents permanently blocking legitimate 1228 traffic in case of these two exceptions. This process is performed 1229 on attachments with the Data-Snooping attribute. Data packets 1230 without matching binding entry may trigger this process to set up 1231 bindings. 1233 Snooping data traffic introduces considerable burden on the processor 1234 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1235 overhead of this process, the implementation of this process is a 1236 conditional SHOULD. This function SHOULD be enabled unless the 1237 implementation is known to be used in the scenarios without the above 1238 exceptions. For example, if the implementation is to be used in 1239 networks with tree topology and without host local-link movement, 1240 there is no need to implement this process in such scenarios. 1242 This process is not intended to set up a binding whenever a data 1243 packet without matched binding entry is received. Instead, unmatched 1244 data packets trigger this process probabilistically and generally a 1245 number of unmatched packets will be discarded before the binding is 1246 set up. 1248 7.2. Rationale 1250 This process makes use of NS/ARP and DHCP Leasequery to set up 1251 bindings. If an address is not used by another client in the 1252 network, and the address has been assigned in the network, the 1253 address can be bound with the binding anchor of the attachment from 1254 which the unmatched packet is received. 1256 The security issues about this process is discussed is Section 11.1. 1258 7.3. Additional Binding States Description 1260 In addition to Section 6.2, new states used in this process are 1261 listed here: 1263 DETECTION: The address in the entry is under local duplication 1264 detection. 1266 RECOVERY: The SAVI device is querying the assignment and lease time 1267 of the address in the entry through DHCP Leasequery. 1269 7.4. Events 1271 Additional events in this process are described here. Also, if an 1272 event will trigger the creation of a new binding entry, the binding 1273 entry limit on the binding anchor MUST NOT be exceeded. 1275 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1277 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1278 against an address in DETECTION state is received from a host other 1279 than the one for which the entry was added. 1281 EVE_DATA_LEASEQUERY: 1283 IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1284 is received. 1286 IPv6: A successful LEASEQUERY-REPLY is received. 1288 The triggering packet should pass the following checks to trigger a 1289 valid event: 1291 o Attribute check: the data packet should be from attachments with 1292 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1293 messages should be from attachments with DHCP-Snooping attribute. 1295 o Binding limitation check: the DHCP messages must not cause new 1296 binding setup on an attachment whose binding entry limitation has 1297 been reached. (refer to Section 11.6). 1299 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1300 DHCP Leasequery messages must pass the check specified in 1301 Section 8.2. For EVE_DATA_CONFLICT, the source address and target 1302 address of the ARP or NA messages must pass the check specified in 1303 Section 8.2. 1305 o Interval check: the interval between two successive 1306 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1307 smaller than DATA_SNOOPING_INTERVAL. 1309 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have 1310 matched TID with the corresponding entry. 1312 o Prefix check: the source address of the data packet should be of a 1313 valid local prefix, as specified in section 7 of [RFC7039]. 1315 7.5. State Machine of Binding Recovery Process 1317 Through using additional states, the state machine of this process 1318 doesn't conflict the regular process described in Section 6. Thus, 1319 it can be implemented separately without changing the state machine 1320 in Section 6. 1322 7.5.1. From NO_BIND to DETECTION 1324 7.5.1.1. Trigger Event 1326 Trigger event: EVE_DATA_UNMATCH. 1328 7.5.1.2. Following Actions 1330 Make a probabilistic determination whether to act on this event. The 1331 probability can be configured or calculated based on the state of the 1332 SAVI device. This probability should be low enough to mitigate the 1333 damage from DoS attack against this process. 1335 Create a new entry in the BST. Set the Binding Anchor field to the 1336 corresponding binding anchor of the attachment. Set the Address 1337 field to be source address of the packet. Set the State field to 1338 DETECTION. Set the Lifetime of the created entry to 1339 2*DETECTION_TIMEOUT. 1341 Check if the address has a local conflict (it violates an address 1342 being used by another node): 1344 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1345 [RFC0826]or a ARP probe [RFC5227] on the address; if there is no 1346 response message after DETECTION_TIMEOUT, send another ARP 1347 Request or ARP probe; 1349 (2) IPv6 address: send a Neighbor Solicitation message [RFC4861] 1350 targeting on the address; if there is no response message after 1351 DETECTION_TIMEOUT, send another Neighbor Solicitation message. 1353 Because the delivery of detection message is unreliable, the 1354 detection message may fail to reach the targeting node. If there is 1355 a node that has the IP address seen in the Data Snooping Process, it 1356 may not get the detection messages. This failure mode enables an 1357 attack against the Data Snooping Process. Thus, the detection is 1358 performed again if there is no response after the first detection. 1360 The messages MUST NOT be sent to the attachment from which the 1361 triggering packet is received. 1363 The packet which triggers this event SHOULD be discarded. 1365 This local conflict process SHOULD be performed. If it is not 1366 performed, the state of the entry is set to RECOVERY, the lifetime is 1367 set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified 1368 in the following section will be performed directly. 1370 An example of the entry is illustrated in Figure 11. 1372 +---------+-------+---------+-----------------------+-------+ 1373 | Anchor |Address| State | Lifetime |TID | 1374 +---------+-------+---------+-----------------------+-------+ 1375 | Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | 1376 +---------+-------+---------+-----------------------+-------+ 1378 Figure 11: Binding entry in BST on data triggered initialization 1380 7.5.2. From DETECTION to Other States 1382 7.5.2.1. Trigger Event 1384 Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT. 1386 7.5.2.2. Following Actions 1388 If the trigger event is EVE_ENTRY_EXPIRE: 1390 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1391 by IP address to each DHCPv4 server with IP Address Lease Time 1392 option (option 51). A list of authorized DHCP servers are kept 1393 by the SAVI device. The list should be pre-configured or 1394 discovered by sending DHCPv4 Discover messages and parsing the 1395 replied DHCPv4 Offer messages. Change the state of the 1396 corresponding entry to RECOVERY. Change the lifetime of the 1397 entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the 1398 TID used in the DHCPLEASEQUERY message. If there is no response 1399 message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to each 1400 DHCPv4 server again. 1402 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1403 address to All_DHCP_Relay_Agents_and_Servers multicast address or 1404 a list of pre-configured DHCPv6 server addresses. Change the 1405 state of the corresponding entry to RECOVERY. Change the 1406 lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID 1407 field is set to the TID used in the LEASEQUERY message. If there 1408 is no response message after MAX_LEASEQUERY_DELAY, send the 1409 LEASEQUERY message again. 1411 An example of the entry is illustrated in Figure 12. 1413 +---------+-------+---------+-----------------------+-------+ 1414 | Anchor |Address| State | Lifetime |TID | 1415 +---------+-------+---------+-----------------------+-------+ 1416 | Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | 1417 +---------+-------+---------+-----------------------+-------+ 1419 Figure 12: Binding entry in BST on Lease Query 1421 If the trigger event is EVE_DATA_CONFLICT: 1423 Remove the entry. 1425 7.5.3. From RECOVERY to Other States 1427 7.5.3.1. Trigger Event 1429 Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY. 1431 7.5.3.2. Following Actions 1433 If the trigger event is EVE_DATA_LEASEQUERY: 1435 IPv4 address: 1437 (1) Send an ARP Request with the Target Protocol Address set to the 1438 IP address in the corresponding entry. The ARP Request is only 1439 sent to the attachment which triggers the binding. If there is 1440 no response after DETECTION_TIMEOUT, send another ARP Request. 1441 If there is still no response, the following actions will not be 1442 performed. If there is only one identical response, get the 1443 sender hardware address. Check if the 'chaddr' field (hardware 1444 address) of the DHCPLEASEACTIVE message matches the sender 1445 hardware address. If the two addresses do not match, the 1446 following actions will not be performed. If there is more than 1447 one response, if any of the sender hardware addresses matches the 1448 'chaddr' field (hardware address) of the DHCPLEASEACTIVE message, 1449 the following actions are to be performed. 1451 (2) Change the state of the corresponding binding to BOUND. Set 1452 life time to the sum of the value encoded in IP Address Lease 1453 Time option of the DHCPLEASEACTIVE message and 1454 MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1456 IPv6 address: 1458 (1) Send a Neighbor Solicitation message with the target address set 1459 to the IP address in the corresponding entry. The Neighbor 1460 Solicitation is only sent to the attachment which triggers the 1461 binding. If there is no response after DETECTION_TIMEOUT, send 1462 another Neighbor Solicitation. If there is still no response, 1463 the following actions will not be performed. 1465 (2) Change the state of the corresponding binding to BOUND. Set the 1466 lifetime to the sum of the valid lifetime extracted from 1467 OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and 1468 MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1470 (3) After the above checks, if multiple addresses are specified in 1471 the LEASEQUERY-REPLY message and there are no corresponding 1472 binding entries, new entries MUST also be created correspondingly 1473 on the same binding anchor. 1475 If responses are received from multiple DHCP servers, the conflict 1476 resolution mechanisms specified in section 6.8 of [RFC4388] and 1477 section 4.3.4 of [RFC5007] will be used to determine which message 1478 should be used. 1480 If the trigger event is EVE_ENTRY_EXPIRE: 1482 Remove the entry. 1484 7.5.4. After BOUND 1486 Note that the TID field contains no value after the binding state 1487 changes to BOUND. The TID field is recovered from snooping DHCP 1488 Renew/Rebind messages. Because TID is used to associate binding 1489 entries with messages from DHCP servers, it must be recovered; or 1490 else a number of state transits of this mechanism will be not 1491 executed normally. 1493 7.5.4.1. Trigger Event 1495 Trigger events: EVE_DHCP_RENEW, EVE_DHCP_REBIND. 1497 7.5.4.2. Following Action 1499 Set the TID field of the corresponding entry to the TID in the 1500 triggering message. 1502 7.6. Table of State Machine 1504 The main state transits are listed as follows. 1506 State Event Action Next State 1507 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1508 DETECTION Timeout Send Leasequery RECOVERY 1509 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1510 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND 1511 RECOVERY Timeout Remove entry NO_BIND 1512 BOUND RENEW/REBIND Record TID BOUND 1514 Figure 13: Table of Transit 1516 RENEW: EVE_DHCP_RENEW 1518 REBIND: EVE_DHCP_REBIND 1520 Timeout: EVE_ENTRY_EXPIRE 1521 +-------------+ 1522 | | 1523 /---------| NO_BIND |<--------\ 1524 | ------>| | | TIMEOUT 1525 | | +-------------+ |(2nd LQ_DELAY) 1526 EVE_DATA_UNMATCH | | | 1527 | | | 1528 1st | | | 1529 DETECTION_TIMEOUT | | | 1st LQ_DELAY 1530 /------\ | | | /---------\ 1531 | | | | EVE_DATA_CONFLICT | | | 1532 | v v | | v | 1533 | +-------------+ TIMEOUT +------------+ | 1534 | | |(2nd DETECTION_TIMEOUT) | | | 1535 \----| DETECTION ------------------------>| RECOVERY ----/ 1536 | | | | 1537 +-------------+ +------------+ 1538 EVE_DATA_LEASEQUERY| 1539 /----------\ (+ 2x DETECTION) | 1540 EVE_DHCP_RENEW| | | 1541 EVE_DHCP_REBIND| +-----v-------+ | 1542 | | | | 1543 \----| BOUND |<----------/ 1544 | | 1545 +-------------+ 1547 Figure 14: Diagram of Transit 1549 LQ_DELAY: MAX_LEASEQUERY_DELAY 1551 8. Filtering Specification 1553 This section specifies how to use bindings to filter out spoofing 1554 packets. 1556 Filtering policies are different for data packets and control 1557 packets. DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] 1558 messages that may cause state transit are classified as control 1559 packet. Neighbor Advertisement (NA) and ARP Reply are also included 1560 in control packet because the Target Address of NA and ARP Reply 1561 should be checked to prevent spoofing. All other packets are 1562 classified as data packets. 1564 8.1. Data Packet Filtering 1566 Data packets from attachments with the Validating attribute MUST be 1567 checked. 1569 Packet whose source IP address is a link-local address will not be 1570 checked. Note: as explained in Section 1, a SAVI solution for link- 1571 local addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to 1572 check packets with link-local source address. 1574 If the source IP address of a packet is not a link-local address, but 1575 there is not a matched entry in BST with state BOUND, this packet 1576 MUST be discarded. However, the packet may trigger Data Snooping 1577 Process Section 7 if Data-Snooping attribute is set on the 1578 attachment. 1580 Data packets from attachments with no attribute will forwarded 1581 without checking. 1583 The SAVI device MAY record any violation. 1585 8.2. Control Packet Filtering 1587 For attachments with the Validating attribute: 1589 DHCPv4 Client-Server messages where source IP address is neither all 1590 zeros nor bound with the corresponding binding anchor in the BST MUST 1591 be discarded. 1593 DHCPv6 Client-Server messages where source IP address is neither a 1594 link-local address nor bound with the corresponding binding anchor in 1595 the BST MUST be discarded. 1597 NDP messages where source IP address is neither a link-local address 1598 nor bound with the corresponding binding anchor MUST be discarded. 1600 NA messages where target address is neither a link-local address nor 1601 bound with the corresponding binding anchor MUST be discarded. 1603 ARP messages where protocol is IP and sender protocol address is 1604 neither all zeros address nor bound with the corresponding binding 1605 anchor MUST be discarded. 1607 ARP Reply messages where target protocol address is not bound with 1608 the corresponding binding anchor MUST be discarded. 1610 For attachments with other attributes: 1612 DHCP Server-Client messages not from attachments with the DHCP-Trust 1613 attribute or Trust attribute MUST be discarded. 1615 For attachments with no attribute: 1617 DHCP Server-Client messages from such attachments MUST be discarded. 1619 The SAVI device MAY record any violation. 1621 9. State Restoration 1623 If a SAVI device reboots, the information kept in volatile memory 1624 will be lost. This section specifies the restoration of attribute 1625 configuration and BST. 1627 9.1. Attribute Configuration Restoration 1629 The loss of attribute configuration will not break the network: no 1630 action will be performed on traffic from attachments with no 1631 attribute. However, the loss of attribute configuration makes this 1632 SAVI function unable to work. 1634 To avoid the loss of binding anchor attribute configuration, the 1635 configuration MUST be able to be stored in non-volatile storage. 1636 After the reboot of SAVI device, if the configuration of binding 1637 anchor attribute can be found in non-volatile storage, the 1638 configuration MUST be used. 1640 9.2. Binding State Restoration 1642 The loss of binding state will cause the SAVI devices discard 1643 legitimate traffic. Purely using the Data Snooping Process to 1644 recover a large number of bindings is of heavy overhead and 1645 considerable delay. Thus, to recover bindings from non-volatile 1646 storage, as specified below, is RECOMMENDED. 1648 Binding entries MAY be saved into non-volatile storage whenever a new 1649 binding entry changes to BOUND state. If a binding with BOUND state 1650 is removed, the saved entry MUST be removed correspondingly. The 1651 time when each binding entry is established is also saved. 1653 Immediately after reboot, the SAVI device SHOULD restore binding 1654 states from the non-volatile storage. The system time of save 1655 process MUST be stored. After rebooting, the SAVI device MUST check 1656 whether each entry has been obsolete by comparing the saved lifetime 1657 and the difference between the current time and time when the binding 1658 entry is established. 1660 10. Constants 1662 MAX_DHCP_RESPONSE_TIME 120s 1664 DATA_SNOOPING_INTERVAL 60s and configurable 1666 MAX_LEASEQUERY_DELAY 10s 1668 OFFLINK_DELAY 30s 1670 DETECTION_TIMEOUT 0.5s 1672 11. Security Considerations 1674 11.1. Security Problems about the Data Snooping Process 1676 There are two security problems about the Data Snooping Process 1677 Section 7: 1679 (1) The Data Snooping Process is costly, but an attacker can trigger 1680 it simply through sending a number of data packets. To avoid 1681 Denial of Services attack against the SAVI device itself, the 1682 Data Snooping Process MUST be rate limited. A constant 1683 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1684 Data Snooping Processes on one attachment MUST have a minimum 1685 interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be 1686 configured prudently to avoid Denial of Service attacks. 1688 (2) The Data Snooping Process may set up wrong bindings if the 1689 clients do not reply to the detection probes. An attack will 1690 pass the duplicate detection if the client assigned the target 1691 address does not reply to the detection probes. The DHCP 1692 Leasequery procedure performed by the SAVI device just tells 1693 whether the address is assigned in the network or not. However, 1694 the SAVI device cannot determine whether the address is just 1695 assigned to the triggering attachment from the DHCP Leasequery 1696 Reply. 1698 11.2. Issues about Leaving Clients 1700 After a binding is set up, the corresponding client may leave its 1701 attachment point. It may leave temporarily due to link flapping, or 1702 permanently by moving to a new attachment point or leaving the 1703 network. Since the client may return shortly, the binding should be 1704 kept, or legitimate traffic from the client will be blocked. 1705 However, if the client leaves permanently, it may be insecure to keep 1706 the binding. If the binding anchor is a property of the attachment 1707 point rather than the client, e.g., the switch port, an attacker 1708 which is attached to the attachment point of the leaving client can 1709 send spoofing packets with the addresses assigned to the client. 1710 Even if the binding anchor is a property of the client, it is a waste 1711 of binding resources to keep bindings for departed clients. 1713 SAVI-DHCP handles the leaving of directly attached clients. Whenever 1714 a direct client leaves, a link-down event associated with the binding 1715 anchor will be triggered. SAVI-DHCP monitors such events, and 1716 perform the following mechanism. 1718 (1) Whenever a client with the Validating attribute leaves, a timer 1719 of duration OFFLINK_DELAY is set on the corresponding binding 1720 entries. 1722 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 1723 received that targets the address during OFFLINK_DELAY, the entry 1724 MAY be removed. 1726 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 1727 timer. 1729 In this way, the bindings of a departing client are kept for 1730 OFFLINK_DELAY. In case of link flapping, the client will not be 1731 blocked. If the client leaves permanently, the bindings will be 1732 removed after OFFLINK_DELAY. 1734 SAVI-DHCP does not handle the leaving of indirect clients, because it 1735 will not be notified of such events. Then the threats illustrated at 1736 the beginning of this section will be introduced. If SAVI-DHCP is 1737 enabled on indirect DHCP clients, this problem should be well 1738 understood. 1740 11.3. Duplicate Bindings to the Same Address 1742 The same address may be bound to multiple binding anchors only if the 1743 binding setup processes successfully complete for each binding 1744 anchor. This mechanism is designed to address the case where a 1745 client moves on the local link, and the case where a client has 1746 multiple attachments to a SAVI device. 1748 There are two security issues with such a design: 1750 First, by allowing one address to be bound to multiple binding 1751 anchors, the traceability of the address is weakened. An address can 1752 be traced to multiple attachments. 1754 Second, in the local link movement scenario, the former binding may 1755 not be removed and it can be used by an attacker sharing the same 1756 binding anchor. For example, when a switch port is used as binding 1757 anchor and the port is shared by an attacker and a client with a hub, 1758 the attacker can make use of the address assigned to the client after 1759 the client leaves. 1761 11.4. Compatibility with DNA (Detecting Network Attachment) 1763 DNA [RFC4436] [RFC6059] is designed to decrease the handover latency 1764 after re-attachment to the same network. DNA mainly relies on 1765 performing reachability test by sending unicast Neighbor 1766 Solicitation/Router Solicitation/ARP Request message to determine 1767 whether a previously configured address is still valid. 1769 Although DNA provides optimization for clients, there is insufficient 1770 information for this mechanism to migrate the previous binding or 1771 establish a new binding. If a binding is set up only by snooping the 1772 reachability test message, the binding may be invalid. For example, 1773 an attacker can perform reachability test with an address bound to 1774 another client. If binding is migrated to the attacker, the attacker 1775 can successfully obtain the binding from the victim. Because this 1776 mechanism wouldn't set up a binding based on snooping the DNA 1777 procedure, it cannot achieve perfect compatibility with DNA. 1778 However, it only means the re-configuration of the interface is 1779 slowed but not prevented. Details are discussed as follows. 1781 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1782 set to a link-local address, and such messages will not be discarded 1783 by the policy specified in Section 8.2. If a client is re-attached 1784 to a previous network, the detection will be completed, and the 1785 address will be regarded as valid by the client. However, the 1786 candidate address is not contained in the probe. Thus, the binding 1787 cannot be recovered through snooping the probe. As the client will 1788 perform DHCP exchange at the same time, the binding will be recovered 1789 from the DHCP Snooping Process. The DHCP Request messages will not 1790 be filtered out in this case because they have link-local source 1791 addresses. Before the DHCP procedure is completed, packets will be 1792 filtered out by the SAVI device. In other words, if this SAVI 1793 function is enabled, Simple DNAv6 will not help reduce the handover 1794 latency. If Data-Snooping attribute is configured on the new 1795 attachment of the client, the data triggered procedure may reduce 1796 latency. 1798 In DNAv4 [RFC4436], the ARP probe will be discarded because an 1799 unbound address is used as the sender protocol address. As a result, 1800 the client will regard the address under detection is valid. 1801 However, the data traffic will be filtered. The DHCP Request message 1802 sent by the client will not be discarded, because the source IP 1803 address field should be all zero as required by [RFC2131]. Thus, if 1804 the address is still valid, the binding will be recovered from the 1805 DHCP Snooping Process. 1807 11.5. Authentication in DHCPv6 Leasequery 1809 As required in section 5 of [RFC5007], DHCPv6 Leasequery 'Should' use 1810 IPsec-based authentication specified in the section 21.1 of 1811 [RFC3315]. However, IPsec is generally considered heavyweight. With 1812 the deployment of this mechanism, the source IP address can be 1813 authenticated without enforcing IPsec. 1815 By containing the DHCP servers in the protection perimeter, the DHCP 1816 servers can be protected from spoofing based attacks. Then by 1817 checking the source IP address of Leasequery messages, the DHCP 1818 server can identify if the messages are from SAVI devices or not. 1819 For the SAVI devices, because the perimeter filters out bogus DHCP 1820 messages, they can trust the DHCP Leasequery responses. 1822 Again, it should be noted that although SAVI-DHCP can help 1823 authenticate the origin, it does not protect the integrity of the 1824 messages. If DHCPv6 Leasequery is performed without enforcing IPsec, 1825 this threat must be taken into account. 1827 11.6. Binding Number Limitation 1829 A binding entry will consume a certain high-speed memory resources. 1830 In general, a SAVI device can afford only a quite limited number of 1831 binding entries. In order to prevent an attacker from overloading 1832 the resource of the SAVI device, a binding entry limit is set on each 1833 attachment. The binding entry limit is the maximum number of 1834 bindings supported on each attachment with Validating attribute. No 1835 new binding should be set up after the limit has been reached. If a 1836 DHCP Reply assigns more addresses than the remaining binding entry 1837 quota of each client, the message will be discarded and no binding 1838 will be set up. 1840 11.7. Privacy Considerations 1842 A SAVI device MUST delete binding anchor information as soon as 1843 possible (i.e., as soon as the state for a given address is back to 1844 NO_BIND), except where there is an identified reason why that 1845 information is likely to be involved in the detection, prevention, or 1846 tracing of actual source address spoofing. Information about the 1847 majority of hosts that never spoof SHOULD NOT be logged. 1849 12. IANA Considerations 1851 This memo asks the IANA for no new parameters. 1853 Note to RFC Editor: This section will have served its purpose if it 1854 correctly tells IANA that no new assignments or registries are 1855 required, or if those assignments or registries are created during 1856 the RFC publication process. From the authors' perspective, it may 1857 therefore be removed upon publication as an RFC at the RFC Editor's 1858 discretion. 1860 13. Acknowledgment 1862 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 1863 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 1864 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 1865 Garcia for careful review and valuation comments on the mechanism and 1866 text. 1868 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 1869 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 1870 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 1871 their valuable contributions. 1873 This document was generated using the xml2rfc tool. 1875 14. References 1877 14.1. Normative References 1879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1880 Requirement Levels", BCP 14, RFC 2119, March 1997. 1882 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1883 "Source Address Validation Improvement (SAVI) Framework", 1884 RFC 7039, October 2013. 1886 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1887 and M. Carney, "Dynamic Host Configuration Protocol for 1888 IPv6 (DHCPv6)", RFC 3315, July 2003. 1890 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1891 2131, March 1997. 1893 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1894 SAVI: First-Come, First-Served Source Address Validation 1895 Improvement for Locally Assigned IPv6 Addresses", RFC 1896 6620, May 2012. 1898 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1899 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1900 September 2007. 1902 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1903 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1905 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1906 Detecting Network Attachment in IPv6", RFC 6059, November 1907 2010. 1909 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1910 converting network protocol addresses to 48.bit Ethernet 1911 address for transmission on Ethernet hardware", STD 37, 1912 RFC 826, November 1982. 1914 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1915 July 2008. 1917 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1918 "DHCPv6 Leasequery", RFC 5007, September 2007. 1920 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1921 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1923 [I-D.ietf-opsec-dhcpv6-shield] 1924 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 1925 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 1926 opsec-dhcpv6-shield-03 (work in progress), June 2014. 1928 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 1929 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 1930 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 1931 dhcpv4-over-dhcpv6-09 (work in progress), June 2014. 1933 14.2. Informative References 1935 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1936 (DHCP) Service for IPv6", RFC 3736, April 2004. 1938 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1939 Defeating Denial of Service Attacks which employ IP Source 1940 Address Spoofing", BCP 38, RFC 2827, May 2000. 1942 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 1943 Internet draft (work in progress), November 2007. 1945 Authors' Addresses 1947 Jun Bi 1948 Tsinghua University 1949 Network Research Center, Tsinghua University 1950 Beijing 100084 1951 China 1953 EMail: junbi@tsinghua.edu.cn 1955 Jianping Wu 1956 Tsinghua University 1957 Computer Science, Tsinghua University 1958 Beijing 100084 1959 China 1961 EMail: jianping@cernet.edu.cn 1963 Guang Yao 1964 Tsinghua University 1965 Network Research Center, Tsinghua University 1966 Beijing 100084 1967 China 1969 EMail: yaoguang@cernet.edu.cn 1971 Fred Baker 1972 Cisco Systems 1973 Santa Barbara, CA 93117 1974 United States 1976 EMail: fred@cisco.com