idnits 2.17.1 draft-ietf-savi-dhcp-30.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 date (December 3, 2014) is 3425 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-opsec-dhcpv6-shield-04 -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Source Address Validation Improvement J. Bi 3 Internet-Draft J. Wu 4 Intended status: Standards Track G. Yao 5 Expires: June 6, 2015 Tsinghua Univ. 6 F. Baker 7 Cisco 8 December 3, 2014 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-30 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 Source 17 Address Validation Improvements (SAVI) device. The bindings set up 18 by this procedure are used to filter packets with forged source IP 19 addresses. This mechanism complements BCP 38 ingress filtering, 20 providing finer-grained source IP address validation. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 6, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Deployment Scenario and Configuration . . . . . . . . . . . . 8 60 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8 61 4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 9 62 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 9 63 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10 64 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 10 65 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11 66 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11 67 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12 68 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 12 70 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13 71 4.3.3. On the Placement of the DHCP Server and Relay . . . . 14 72 4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 14 73 4.3.5. Considerations regarding Binding Anchors . . . . . . 15 74 4.4. Other Device Configuration . . . . . . . . . . . . . . . 16 75 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 16 76 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 17 77 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 17 78 6.2. Binding States Description . . . . . . . . . . . . . . . 18 79 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 18 81 6.3.2. Control Message Arriving Events . . . . . . . . . . . 18 82 6.4. The State Machine of DHCP Snooping Process . . . . . . . 20 83 6.4.1. Initial State: NO_BIND - No binding has been set up . 20 84 6.4.2. Initial State: INIT_BIND - A potential binding has 85 been set up . . . . . . . . . . . . . . . . . . . . . 22 86 6.4.3. Initial State: BOUND - The binding has been set up . 25 87 6.4.4. Table of State Machine . . . . . . . . . . . . . . . 27 88 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 29 89 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 29 90 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 30 91 7.3. Additional Binding States Description . . . . . . . . . . 30 92 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 7.5. Initial State: state NO_BIND - No binding has been set up 32 94 7.5.1. Event: EVE_DATA_UNMATCH: A data packet without 95 matched binding is received . . . . . . . . . . . . . 32 96 7.5.2. Events not observed in NO_BIND . . . . . . . . . . . 33 98 7.6. Initial State: state DETECTION - The address in the entry 99 is under local duplication detection . . . . . . . . . . 33 100 7.6.1. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) . . . . . . . 33 101 7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor 102 Advertisement(NA) message received from unexpected 103 system . . . . . . . . . . . . . . . . . . . . . . . 34 104 7.6.3. Events not observed in DETECTION . . . . . . . . . . 34 105 7.7. Initial State: state RECOVERY - The SAVI device is 106 querying the assignment and lease time of the address in 107 the entry through DHCP Leasequery . . . . . . . . . . . . 34 108 7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE 109 or LEASEQUERY-REPLY is received . . . . . . . . . . . 34 110 7.7.2. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) . . . . . . . 36 111 7.7.3. Events not observed in RECOVERY . . . . . . . . . . . 36 112 7.8. Initial State: state BOUND - The binding has been set up 36 113 7.8.1. Event: EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 114 Renew message is received . . . . . . . . . . . . . . 36 115 7.8.2. Event: EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 116 Rebind message is received . . . . . . . . . . . . . 36 117 7.8.3. Events not observed in BOUND . . . . . . . . . . . . 37 118 7.9. Table of State Machine . . . . . . . . . . . . . . . . . 37 119 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 38 120 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 38 121 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 39 122 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 40 123 9.1. Attribute Configuration Restoration . . . . . . . . . . . 40 124 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 40 125 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 41 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 127 11.1. Security Problems about the Data Snooping Process . . . 41 128 11.2. Client departure issues . . . . . . . . . . . . . . . . 41 129 11.3. Duplicate Bindings to the Same Address . . . . . . . . . 42 130 11.4. Compatibility with DNA (Detecting Network Attachment) . 43 131 11.5. Binding Number Limitation . . . . . . . . . . . . . . . 44 132 11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 44 133 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 134 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 44 135 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 136 14.1. Normative References . . . . . . . . . . . . . . . . . . 45 137 14.2. Informative References . . . . . . . . . . . . . . . . . 46 139 1. Introduction 141 This document describes a fine-grained source IPv4 or IPv6 source 142 address validation mechanism. This mechanism creates bindings 143 between IP addresses assigned to network interfaces by DHCP and 144 suitable binding anchors (Section 4.3.5). As discussed in Section 3 145 and [RFC7039], a "binding anchor" is an attribute that is immutable 146 or difficult to change that may be used to identify the system an IP 147 address has been assigned to; common examples include a MAC address 148 found on an Ethernet switch port or WiFi security association. The 149 bindings are used to identify and filter packets originated by these 150 interfaces using forged source IP addresses. In this way, this 151 mechanism can prevent hosts from using IP addresses assigned to the 152 other attachment points or invalid in the network. This behavior is 153 referred to as "spoofing", and is key to amplification attacks, in 154 which a set of systems send messages to another set of systems 155 claiming to be from a third set of systems, and sending the replies 156 to systems that don't expect them. If [RFC2827] protects a network 157 from a neighboring network by providing prefix granularity source IP 158 address validity, this mechanism protects a network, including a 159 Local Area Network, from itself by providing address granularity 160 source IP validity when DHCP/DHCPv6 is used to assign IPv4/IPv6 161 addresses. Both provide a certain level of traceability, in that 162 packet drops indicate the presence of a system that is producing 163 packets with spoofed IP addresses. 165 SAVI-DHCP snoops DHCP address assignments to set up bindings between 166 IP addresses assigned by DHCP and corresponding binding anchors. It 167 includes the DHCPv4 and v6 snooping process (Section 6), the Data 168 Snooping process (Section 7), as well as a number of other technical 169 details. The Data Snooping process is a data-triggered procedure 170 that snoops the header of data packet to set up bindings. It is 171 designed to avoid a permanent block of valid addresses in the case 172 that DHCP snooping is insufficient to set up all the valid bindings. 174 This mechanism is designed for the stateful DHCP scenario [RFC2131], 175 [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this 176 document, because it has nothing to do with IP address allocation. 177 The appropriate SAVI method must be used in those cases. For hosts 178 using Stateless Auto-Configuration to allocate addresses, SAVI-FCFS 179 [RFC6620] should be enabled. Besides, this mechanism is primarily 180 designed for pure DHCP scenarios in which only addresses assigned 181 through DHCP are allowed. However, it does not block link-local 182 addresses, as they are not assigned using DHCP. It is RECOMMENDED 183 that the administration enable a SAVI solution for link-local 184 addresses, e.g., SAVI-FCFS [RFC6620]. 186 This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and 187 DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6 188 transition scenarios, e.g., [RFC7341], are beyond the scope of this 189 document. 191 2. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119]. 197 3. Terminology 199 Binding anchor: A "binding anchor" is defined to be a physical and/or 200 link-layer property of an attached device, as in [RFC7039]. A list 201 of sample binding anchors can be found in Section 3.2 of that 202 document. To the degree possible, a binding anchor associates an IP 203 address with something unspoofable that identifies a single client 204 system or one of its interfaces. See Section 4.3.5 for more detail. 206 Attribute: A configurable property of each binding anchor (port, MAC 207 Address, or other information) that indicates the actions to be 208 performed on packets received from the attached network device. 210 DHCP address: An IP address assigned via DHCP. 212 SAVI-DHCP: The name of this SAVI function for DHCP-assigned 213 addresses. 215 SAVI device: A network device on which SAVI-DHCP is enabled. 217 Non-SAVI device: A network device on which SAVI-DHCP is not enabled. 219 DHCP Client-Server message: A message that is sent from a DHCP client 220 to a DHCP server or DHCP servers. Such a message is of one of the 221 following types: 223 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 225 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 226 [RFC2131] 228 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 229 [RFC2131] 231 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 232 [RFC2131] 234 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 235 [RFC2131] 237 o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be 238 identified based on the Table 4 of [RFC2131] 240 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 242 o DHCPv4 Release: DHCPRELEASE [RFC2131] 244 o DHCPv4 Inform: DHCPINFORM [RFC2131] 246 o DHCPv6 Request: REQUEST [RFC3315] 248 o DHCPv6 Solicit: SOLICIT [RFC3315] 250 o DHCPv6 Confirm: CONFIRM [RFC3315] 252 o DHCPv6 Decline: DECLINE [RFC3315] 254 o DHCPv6 Release: RELEASE [RFC3315] 256 o DHCPv6 Rebind: REBIND [RFC3315] 258 o DHCPv6 Renew: RENEW [RFC3315] 260 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 262 DHCP Server-to-Client message: A message that is sent from a DHCP 263 server to a DHCP client. Such a message is of one of the following 264 types: 266 o DHCPv4 ACK: DHCPACK [RFC2131] 268 o DHCPv4 NAK: DHCPNAK [RFC2131] 270 o DHCPv4 Offer: DHCPOFFER [RFC2131] 272 o DHCPv6 Reply: REPLY [RFC3315] 274 o DHCPv6 Advertise: ADVERTISE [RFC3315] 276 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 278 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 279 IPv6 [RFC3315]. 281 Binding entry: A rule that associates an IP address with a binding 282 anchor. 284 Binding State Table (BST): The data structure that contains the 285 binding entries. 287 Binding entry limit: The maximum number of binding entries that may 288 be associated with a binding anchor. Limiting the number of binding 289 entries per binding anchor prevents a malicious or malfunctioning 290 node from overloading the binding table on a SAVI device. 292 Direct attachment: Ideally, a SAVI device is an access device that 293 hosts are attached to directly. In such a case, the hosts are direct 294 attachments (e.g., they attach directly) to the SAVI device. 296 Indirect attachment: A SAVI device MAY be an aggregation device that 297 other access devices are attached to, and which hosts in turn attach 298 to. In such a case, the hosts are indirect attachments (e.g., they 299 attach indirectly) to the SAVI device. 301 Upstream link: Upstream links are links that connect to hosts that 302 the device may not see DHCP messages to, and are therefore outside 303 the SAVI perimiter. 305 Upstream device: An upstream device is a device associated with an 306 upstream link. One example might be the gateway router of a network. 308 Downstream link: Downstream inks are links that connect to hosts that 309 the device will invariably see DHCP messages to, and are therefore 310 within the SAVI perimiter.. 312 Downstream device: A downstream device is a device associated with a 313 downstream link. One example might be a desktop switch in the 314 network, or a host. 316 Cut Vertex: A cut vertex is any vertex whose removal increases the 317 number of connected components. This is a concept in graph theory. 318 This term is used in Section 6.1 to accurately specify the required 319 deployment location of SAVI devices when they only perform the DHCP 320 snooping process. 322 Identity Association (IA): "A collection of addresses assigned to a 323 client." [RFC3315] 325 Detection message: a Neighbor Solicitation or ARP message intended to 326 detect a duplicate address by the Data Snooping Process. 328 DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the 329 binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease 330 query exchange [RFC5007] cannot be performed by the SAVI device to 331 fetch the lease. 333 4. Deployment Scenario and Configuration 335 4.1. Elements and Scenario 337 The essential elements in a SAVI-DHCP deployment scenario include a 338 DHCP server, zero or more downstream DHCP clients, and one or more 339 SAVI devices. It may also include DHCP relays, when the DHCP server 340 is not co-located with a set of clients, and zero or more downstream 341 Non-SAVI devices. 343 +--------+ +------------+ +----------+ 344 |DHCP |-----| Non-SAVI |----|Bogus DHCP| 345 |Server A| | Device 1 | |Server | 346 +--------+ +-----|------+ +----------+ 347 |upstream link 348 . . . . . . . . . . .|. . . . . . . . . . . . . . 349 . | . 350 . Protection +---|------+ . 351 . Perimeter | SAVI |--------------+ . 352 . | Device C| | . 353 . +---|------+ | . 354 . | | . 355 . +----------+ +---|------+ +------|---+ . 356 downstream . | SAVI | | Non SAVI| | SAVI | . 357 link +----.-| Device A|----| Device 3|-------| Device B| . 358 | . +----|--|--+ +----------+ +-|---|----+ . 359 | . | +----------+ . . . . . | | . 360 | '. . . . . . . | . . | | . 361 | | . | . +--------+ | . 362 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 363 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 364 | Device 2 | |A | . |Relay | . |B | . |Server B| . 365 +----------+ +------+ . +------+ . +------+ . +--------+ . 366 . . . . . . . . . . . . 368 Figure 1: SAVI-DHCP Scenario 370 Figure 1 shows a deployment scenario that contains these elements. 371 Note that a physical device can instantiate multiple elements, e.g., 372 a switch can be both a SAVI device and a DHCP relay, or in a cloud 373 computing environment, a physical host may contain a virtual switch 374 plus some number of virtual hosts. In such cases, the links are 375 logical links rather than physical links. 377 Networks are not usually isolated. As a result, traffic from other 378 networks, including transit traffic as specified in [RFC6620] (e.g., 379 traffic from another SAVI switch or a router) may enter a SAVI-DHCP 380 network through the upstream links. Since SAVI solutions are limited 381 to validating traffic generated from a local link, SAVI-DHCP does not 382 set up bindings for addresses assigned in other networks and cannot 383 validate them. Traffic from upstream links should be checked by an 384 upstream system or [RFC2827] mechanisms. The generation and 385 deployment of such a mechanism is beyond the scope of this document. 387 Traffic from downstream links is, however, locally generated, and 388 should be checked by SAVI-DHCP if possible. In the event that there 389 is an intervening downstream non-SAVI device between the host and the 390 SAVI device, however, use of the physical attachment point alone as a 391 binding anchor is insufficiently secure, as the several devices on a 392 port or other point of attachment can spoof each other. Hence, 393 additional information such as a MAC address SHOULD be used to 394 disambiguate them. 396 4.2. SAVI Binding Type Attributes 398 As illustrated in Figure 1, an system attached to a SAVI device can 399 be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI 400 device. Different actions are performed on traffic originated from 401 different elements. To distinguish among their requirements, several 402 properties are associated with their point of attachment on the SAVI 403 device. 405 When a binding association is uninstantiated, e.g. when no host is 406 attached to the SAVI device using a given port or other binding 407 anchor, the binding port attributes take default values unless 408 overridden by configuration. By default, a SAVI switch does not 409 filter DHCP messages, nor does it attempt to validate source 410 addresses. This is because a SAVI switch that depends on DHCP cannot 411 tell, a priori, which ports have valid DHCP servers attached, or 412 which have routers or other equipment that would validly appear to 413 use an arbitrary set of source addresses. 415 4.2.1. Trust Attribute 417 The "Trust Attribute" is a Boolean value. If TRUE, it indicates that 418 the packets from the corresponding attached device need not have 419 their source addresses validated. Examples of a trusted binding 420 anchor would be a port to another SAVI device, or to an IP router, as 421 shown in Figure 1. In both cases, traffic using many source IP 422 addresses will be seen. By default, the Trust attribute is FALSE, 423 indicating that any device found on that port will seek an address 424 using DHCP and be limited to using such addresses. 426 SAVI devices will not set up bindings for points of attachment with 427 the Trust attribute set TRUE; DHCP messages and data packets from 428 attached devices with this attribute will not be checked. If the 429 DHCP Server-to-Client messages from attached devices with this 430 attribute can trigger the state transitions specified in Section 6 431 and Section 7, the corresponding processes in Section 6 and Section 7 432 will handle these messages. 434 4.2.2. DHCP-Trust Attribute 436 The "DHCP-Trust Attribute" is similarly a Boolean attribute. It 437 indicates whether the attached device is permitted to initiate DHCP 438 Server-to-Client messages. In Figure 1, the points of attachment of 439 the DHCP Server and the DHCP Relay would have this attribute set 440 TRUE, and ports that are trusted would have it set TRUE. 442 If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP 443 Server-to-Client messages from the points of attachment with this 444 attribute. If the DHCP Server-to-Client messages can trigger the 445 state transitions, the binding setup processes specified in Section 6 446 and Section 7 will handle them. By default, the DHCP-Trust attribute 447 is FALSE, indicating that the attached system is not a DHCP server. 449 A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for 450 more details. 452 4.2.3. DHCP-Snooping Attribute 454 The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It 455 indicates whether bindings will be set up based on DHCP snooping. 457 If this attribute is TRUE, DHCP Client-Server messages to points of 458 attachment with this attribute will trigger creation of bindings 459 based on the DHCP snooping procedure described in Section 6. If it 460 is FALSE, either the Trust attribute must be TRUE (so that bindings 461 become irrelevant) or another SAVI mechanism such as SAVI-FCFS must 462 be used on the point of attachment. 464 The DHCP-Snooping attribute is configured on the DHCP Client's point 465 of attachment. This attribute can be also used on the attachments to 466 downstream Non-SAVI devices that are used by DHCP clients. In 467 Figure 1, the attachment from the Client A to the SAVI Device A, the 468 attachment from the Client B to the SAVI Device B, and the attachment 469 from the Non-SAVI Device 2 to the SAVI Device A can be configured 470 with this attribute. 472 Whenever this attribute is set TRUE on a point of attachment, the 473 "Validating Attribute" MUST also be set TRUE. 475 4.2.4. Data-Snooping Attribute 477 The "Data-Snooping Attribute" is a Boolean attribute. It indicates 478 whether data packets from the corresponding point of attachment may 479 trigger the binding setup procedure. 481 Data packets from points of attachment with this attribute may 482 trigger the setup of bindings. SAVI devices will set up bindings on 483 points of attachment with this attribute based on the data-triggered 484 process described in Section 7. 486 If the DHCP-Snooping attribute is configured on a point of 487 attachment, the bindings on this attachment are set up based on DHCP 488 message snooping. However, in some scenarios, a DHCP client may use 489 a DHCP address without the DHCP address assignment procedure being 490 performed on its current attachment. For such attached devices, the 491 Data-Snooping process, which is described in Section 7, is necessary. 492 This attribute is configured on such attachments. The usage of this 493 attribute is further discussed in Section 7. 495 Whenever this attribute is set on an attachment, the "Validating 496 Attribute" MUST be set on the same attachment. Since some networks 497 require DHCP deployment and others avoid it, there is no obvious 498 universal default value for the Data-Snooping Attribute. However, 499 note that deployment of SLAAC (and therefore SAVI-FCFS) is generally 500 configuration-free, while the deployment of DHCP involves at minimum 501 the deployment of a server. Hence, the Data-Snooping Attribute 502 should default to FALSE, and a mechanism should be implemented to 503 conveniently set it to TRUE on all points of attachment for which the 504 Trust attribute is FALSE. 506 4.2.5. Validating Attribute 508 The "Validating Attribute" is a Boolean attribute. It indicates 509 whether packets from the corresponding attachment will have their IP 510 source addresses validated based on binding entries on the 511 attachment. 513 If it is TRUE, packets coming from attachments with this attribute 514 will be checked based on binding entries on the attachment as 515 specified in Section 8. If it is FALSE, they will not. Since the 516 binding table is used in common with other SAVI algorithms, it merely 517 signifies whether the check will be done, not whether it will be done 518 for SAVI-DHCP originated bindings. 520 This attribute is by default the inverse of the Trust attribute; 521 source addresses on untrusted links are validated by default. It MAY 522 be set FALSE by the administration. 524 4.2.6. Table of Mutual Exclusions 526 Different types of attributes may indicate mutually exclusive actions 527 on a packet. Mutually exclusive attributes MUST NOT be set TRUE on 528 the same attachment. The compatibility of different attributes is 529 listed in Figure 2. Note that although Trust and DHCP-Trust are 530 compatible, there is no need to configure DHCP-Trust to TRUE on an 531 attachment with Trust attribute TRUE. 533 +----------+----------+----------+----------+----------+----------+ 534 | | | | DHCP- | Data- | | 535 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 536 +----------+----------+----------+----------+----------+----------+ 537 | | | | mutually | mutually | mutually | 538 | Trust | - |compatible| exclusive| exclusive| exclusive| 539 +----------+----------+----------+----------+----------+----------+ 540 | | | | | | | 541 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 542 +----------+----------+----------+----------+----------+----------+ 543 |DHCP- |mutually | | | | | 544 |Snooping |exclusive |compatible| - |compatible|compatible| 545 +----------+----------+----------+----------+----------+----------+ 546 |Data- |mutually | | | | | 547 |Snooping |exclusive |compatible|compatible| - |compatible| 548 +----------+----------+----------+----------+----------+----------+ 549 | |mutually | | | | | 550 |Validating|exclusive |compatible|compatible|compatible| - | 551 +----------+----------+----------+----------+----------+----------+ 553 Figure 2: Table of Mutual Exclusions 555 4.3. Perimeter 557 4.3.1. SAVI-DHCP Perimeter Overview 559 SAVI devices form a perimeter separating trusted and untrusted 560 regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]). 561 The perimeter is primarily designed for scalability. It has two 562 implications. 564 o SAVI devices only need to establish bindings for directly attached 565 clients, or clients indirectly attached through a non-SAVI 566 downstream device, rather than all of the clients in the network. 568 o Each SAVI device only need to validate traffic from clients 569 attached to it, without checking all the traffic passing by. 571 Consider the example in Figure 1. The protection perimeter is formed 572 by SAVI Devices A, B and C. In this case, SAVI device B does not 573 create a binding for client A. However, because SAVI device A filters 574 spoofed traffic from client A, SAVI device B can avoid receiving 575 spoofed traffic from client A. 577 The perimeter in SAVI-DHCP is not only a perimeter for data packets, 578 but also a perimeter for DHCP messages. The placement of the DHCP 579 Relay and DHCP Server, which are not involved in [RFC6620], is 580 related to the construction of the perimeter. The requirement on the 581 placement and configuration of DHCP Relay and DHCP Server are 582 discussed in Section 4.3.3. 584 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 586 A perimeter separating trusted and untrusted regions of the network 587 is formed as follows: 589 (1) Configure the Validating and DHCP-Snooping attributes TRUE on 590 the direct attachments of all DHCP clients. 592 (2) Configure the Validating and DHCP-Snooping attributes TRUE on 593 the indirect attachments of all DHCP clients (i.e., DHCP clients 594 on downstream links). 596 (3) Configure the Trust attribute TRUE on the attachments to other 597 SAVI devices. 599 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 600 are attached only to SAVI devices, set the Trust attribute TRUE 601 on their attachments. 603 (5) Configure the DHCP-Trust attribute TRUE on the direct 604 attachments to trusted DHCP relays and servers. 606 In this way, the points of attachments with the Validating attribute 607 TRUE (and generally together with attachments of upstream devices) on 608 SAVI devices can form a perimeter separating DHCP clients and trusted 609 devices. Data packet checks are only performed on the perimeter. 610 The perimeter is also a perimeter for DHCP messages. The DHCP-Trust 611 attribute is only TRUE on the inside links of the perimeter. Only 612 DHCP server-to-client messages originated within the perimeter are 613 trusted. 615 4.3.3. On the Placement of the DHCP Server and Relay 617 As a result of the configuration guideline, SAVI devices only trust 618 DHCP Server-to-Client messages originated inside the perimeter. 619 Thus, the trusted DHCP Relays and DHCP Servers must be placed within 620 the perimeter. DHCP server-to-client messages will be filtered on 621 the perimeter. Server-to-relay messages will not be filtered, as 622 they are within the perimeter. In this way, DHCP server-to-client 623 messages from bogus DHCP servers are filtered on the perimeter, 624 having entered through untrusted points of attachment. The SAVI 625 devices are protected from forged DHCP messages. 627 DHCP server-to-client messages arriving at the perimeter from outside 628 the perimeter are not trusted. There is no distinction between a 629 DHCP server owned and operated by the correct administration but 630 outside the SAVI perimeter and a bogus DHCP server. For example, in 631 Figure 1, DHCP server A is valid, but it is attached to Non-SAVI 632 device 1. A bogus DHCP server is also attached Non-SAVI device 1. 633 While one could imagine a scenario in which the valid one had a 634 statistically configured port number and MAC address, and therefore a 635 binding, by default SAVI-DHCP cannot distinguish whether a message 636 received from the port of Non-SAVI device 1 is from DHCP server A or 637 the bogus DHCP server. If the DHCP server A is contained in the 638 perimeter, Non-SAVI device 1 will also be contained in the perimeter. 639 Thus, the DHCP server A cannot be contained within the perimeter 640 apart from manual configuration of the binding anchor. 642 Another consideration on the placement is that if the DHCP server/ 643 relay is not inside the perimeter, the SAVI devices may not be able 644 to set up bindings correctly, because the SAVI devices may not be on 645 the path between the clients and the server/relay, or the DHCP 646 messages are encapsulated (e.g., Relay-reply and Relay-forward). 648 4.3.4. An Alternative Deployment 650 In common deployment practice, the traffic from the upstream network 651 is treated as trustworthy, which is to say that it is not filtered. 652 In such a case, the Trust attribute can be set TRUE on the upstream 653 link. If Non-SAVI devices, or a number of connected Non-SAVI 654 devices, are only attached to SAVI devices and upstream devices, 655 their attachment to SAVI devices can have the Trust attribute set 656 TRUE. Then an unclosed perimeter will be formed, as illustrated in 657 Figure 3. 659 To configure such a perimeter, at minimum the DHCP messages from 660 upstream networks MUST be ensured to be trustworthy. Achieving this 661 is beyond the scope of this document. 663 | . . Protection | 664 | | | Perimeter | 665 | | | | 666 | Upstream | | Upstream | 667 | Link | | Link | 668 | | | | 669 | | | | 670 | +--------+ +--------+ +--------+ | 671 | |SAVI |----|Non-SAVI|----|SAVI | | 672 | |Device | |Device | |Device | | 673 | +--------+ +--------+ +--------+ | 674 | | | | 675 \________________________________________________/ 676 | | 677 | | 678 +--------+ +--------+ 679 |DHCP | |DHCP | 680 |Client | |Client | 681 +--------+ +--------+ 683 Figure 3: Alternative Perimeter Configuration 685 4.3.5. Considerations regarding Binding Anchors 687 The strength of this binding-based mechanism depends on the strength 688 of the binding anchor. The sample binding anchors in [RFC7039] have 689 the property that they associate an IP address with a direct physical 690 or secure virtual interface such as a switch port, a subscriber 691 association, or a security association. In addition, especially in 692 the case that a downstream non-SAVI device such as a desktop switch 693 or a hub is between the client device and the SAVI switch, they MAY 694 be extended to also include a MAC address or other link-layer 695 attribute. In short, a binding anchor is intended to associate an IP 696 address with something unspoofable that identifies a single client 697 system or one of its interfaces; this may be a physical or virtual 698 interface or that plus disambiguating link-layer information. 700 If the binding anchor is spoofable, such as a plain MAC address, or 701 non-exclusive, such as a switch port extended using a non-SAVI 702 device, an attacker can use a forged binding anchor to evade 703 validation. Indeed, using a binding anchor that can be easily 704 spoofed can lead to worse outcomes than allowing IP spoofing traffic. 705 Thus, a SAVI device MUST use a non-spoofable and exclusive binding 706 anchor. 708 4.4. Other Device Configuration 710 In addition to a possible binding anchor configuration specified in 711 Section 4.2, an implementation has the following configuration 712 requirements: 714 (1) Address configuration. For DHCPv4: the client of a SAVI device 715 MUST have an IPv4 address. For DHCPv6: the client of a SAVI 716 device MUST have a link-local address; when the DHCPv6 server is 717 not on the same link as the SAVI device, the SAVI device MUST 718 also have a global IPv6 address. 720 (2) DHCP server address configuration: a SAVI device MUST store the 721 list of the DHCP server addresses that it could contact during a 722 Lease query process. 724 5. Binding State Table (BST) 726 The Binding State Table, which may be implemented centrally in the 727 switch or distributed among its ports, is used to contain the 728 bindings between the IP addresses assigned to the attachments and the 729 corresponding binding anchors of the attachments. Note that in this 730 description, there is a binding entry for each IPv4 or IPv6 address 731 associated with each binding anchor, and there may be several of each 732 such address, especially if the port is extended using a downstream 733 non-SAVI device. Each binding entry, has 5 fields: 735 o Binding Anchor(Anchor): the binding anchor, i.e., a physical and/ 736 or link-layer property of the attachment. 738 o IP Address(Address): the IPv4 or IPv6 address assigned to the 739 attachment by DHCP. 741 o State: the state of the binding. Possible values of this field 742 are listed in Section 6.2 and Section 7.3. 744 o Lifetime: the remaining seconds of the binding. Internally, this 745 MAY be stored as the timestamp value at which the lifetime 746 expires. 748 o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the 749 corresponding DHCP transaction. TID field is used to associate 750 DHCP Server-to-Client messages with corresponding binding entries. 752 The IA is not present in the BST for three reasons: 754 o The lease of each address in one IA is assigned separately. 756 o When the binding is set up based on data-snooping, the IA cannot 757 be recovered from the lease query protocol. 759 o DHCPv4 does not define an IA. 761 An instance of this table is shown in Figure 4. 763 +---------+----------+----------+-----------+-------+ 764 | Anchor | Address | State | Lifetime |TID | 765 +---------+----------+----------+-----------+-------+ 766 | Port_1 | IP_1 | BOUND | 65535 |TID_1 | 767 +---------+----------+----------+-----------+-------+ 768 | Port_1 | IP_2 | BOUND | 10000 |TID_2 | 769 +---------+----------+----------+-----------+-------+ 770 | Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | 771 +---------+----------+----------+-----------+-------+ 773 Figure 4: Instance of BST 775 6. DHCP Snooping Process 777 This section specifies the process of setting up bindings based on 778 DHCP snooping. This process is illustrated using a state machine. 780 6.1. Rationale 782 The rationale of the DHCP Snooping Process is that if a DHCP client 783 is legitimately using a DHCP-assigned address, the DHCP address 784 assignment procedure that assigns the IP address to the client must 785 have been performed on the client's point of attachment. This basis 786 works when the SAVI device is always on the path(s) from the DHCP 787 client to the DHCP server(s)/relay(s). Without considering the 788 movement of DHCP clients, the SAVI device should be the cut vertex 789 whose removal will separate the DHCP client and the remaining network 790 containing the DHCP server(s)/ and relay(s). For most of the 791 networks whose topologies are simple, it is possible to deploy this 792 SAVI function at proper devices to meet this requirement. 794 However, if there are multiple paths from a DHCP client to the DHCP 795 server and the SAVI device is only on one of them, there is an 796 obvious failure case: the SAVI device may not be able to snoop the 797 DHCP procedure. Host movement may also make this requirement 798 difficult to meet. For example, when a DHCP client moves from one 799 attachment to another attachment in the same network, it may fail to 800 reinitialize its interface or send a Confirm message because of 801 incomplete protocol implementation. Thus, there can be scenarios in 802 which only performing this DHCP snooping process is insufficient to 803 set up bindings for all the valid DHCP addresses. These exceptions 804 and the solutions are discussed in Section 7. 806 6.2. Binding States Description 808 Following binding states are present in this process and the 809 corresponding state machine: 811 NO_BIND: No binding has been set up. 813 INIT_BIND: A potential binding has been set up. 815 BOUND: The binding has been set up. 817 6.3. Events 819 This section describes events in this process and the corresponding 820 state machine. 822 6.3.1. Timer Expiration Event 824 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 826 6.3.2. Control Message Arriving Events 828 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 829 received. 831 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 833 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 835 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 836 received. 838 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 840 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 841 option is received. 843 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 845 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 846 received. 848 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 849 received. 851 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 852 section 4.3.3 of [RFC5007]) is received. 854 Note: the events listed here do not cover all the DHCP messages in 855 section 3. The messages which do not really determine address usage 856 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 857 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 858 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 859 to section 6.4.2.1), are not included. 861 Moreover, only if a DHCP message can pass the following checks, the 862 corresponding event is regarded as a valid event: 864 o Attribute check: the DHCP Server-to-Client messages and 865 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 866 attribute; the DHCP Client-Server messages should be from 867 attachments with DHCP-Snooping attribute. 869 o Destination check: the DHCP Server-to-Client messages should be 870 destined to attachments with DHCP-Snooping attribute. This check 871 is performed to ensure the binding is set up on the SAVI device 872 which is nearest to the destination client. 874 o Binding anchor check: the DHCP Client-Server messages which may 875 trigger modification or removal of an existing binding entry must 876 have a matching binding anchor with the corresponding entry. 878 o TID check: the DHCP Server-to-Client/Client-Server messages which 879 may cause modification on existing binding entries must have 880 matched TID with the corresponding entry. Note that this check is 881 not performed on Lease query and Lease query-reply messages as 882 they are exchanged between the SAVI devices and the DHCP servers. 883 Besides, this check is not performed on DHCP Renew/Rebind 884 messages. 886 o Binding limitation check: the DHCP messages must not cause new 887 binding setup on an attachment whose binding entry limitation has 888 been reached. (refer to Section 11.5). 890 o Address check: the source address of the DHCP messages should pass 891 the check specified in Section 8.2. 893 On receiving a DHCP message without triggering a valid event, the 894 state will not change, and the actions will not be performed. Note 895 that if a message does not trigger a valid event but it can pass the 896 checks in Section 8.2, it MUST be forwarded. 898 6.4. The State Machine of DHCP Snooping Process 900 This section specifies state transitions and their corresponding 901 actions. 903 6.4.1. Initial State: NO_BIND - No binding has been set up 905 6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request 906 message is received 908 The SAVI device MUST forward the message. 910 The SAVI device will generate an entry in the BST. The Binding 911 anchor field is set to the binding anchor of the attachment from 912 which the message is received. The State field is set to INIT_BIND. 913 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 914 field is set to the TID of the message. If the message is DHCPv4 915 Request or DHCPv4 Reboot, the Address field can be set to the address 916 to request, i.e., the 'requested IP address'. An example of the 917 entry is illustrated in Figure 5. 919 +---------+-------+---------+-----------------------+-------+ 920 | Anchor |Address| State | Lifetime |TID | 921 +---------+-------+---------+-----------------------+-------+ 922 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 923 +---------+-------+---------+-----------------------+-------+ 925 Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot 926 triggered initialization 928 Resulting state: INIT_BIND - A potential binding has been set up 930 6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received 932 The SAVI device MUST forward the message. 934 The SAVI device will generate an entry in the BST. The Binding 935 anchor field is set to the binding anchor of the attachment from 936 which the message is received. The State field is set to INIT_BIND. 937 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 938 field is set to the TID of the message. If the message is DHCPv4 939 Request or DHCPv4 Reboot, the Address field can be set to the address 940 to request, i.e., the 'requested IP address'. An example of the 941 entry is illustrated in Figure 5. 943 Resulting state: INIT_BIND - A potential binding has been set up 945 6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message 946 with Rapid Commit option is received 948 The SAVI device MUST forward the message. 950 The SAVI device will generate an entry in the BST. The Binding 951 anchor field is set to the binding anchor of the attachment from 952 which the message is received. The State field is set to INIT_BIND. 953 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 954 field is set to the TID of the message. If the message is DHCPv4 955 Request or DHCPv4 Reboot, the Address field can be set to the address 956 to request, i.e., the 'requested IP address'. An example of the 957 entry is illustrated in Figure 5. 959 Resulting state: INIT_BIND - A potential binding has been set up 961 6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received 963 The SAVI device MUST forward the message. 965 The SAVI device will generate corresponding entries in the BST for 966 each address in each Identity Association (IA) option of the Confirm 967 message. The Binding anchor field is set to the binding anchor of 968 the attachment from which the message is received. The State field 969 is set to INIT_BIND. The Lifetime field is set to be 970 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 971 message. The Address field is set to the address(es) to confirm. An 972 example of the entries is illustrated in Figure 6. 974 +---------+--------+---------+-----------------------+-------+ 975 | Anchor | Address| State | Lifetime |TID | 976 +---------+--------+---------+-----------------------+-------+ 977 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 978 +---------+--------+---------+-----------------------+-------+ 979 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 980 +---------+--------+---------+-----------------------+-------+ 982 Figure 6: Binding entry in BST on Confirm triggered initialization 984 Resulting state: INIT_BIND - A potential binding has been set up 986 6.4.1.5. Events that cannot happen in the NO_BIND state 988 o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires 990 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 991 received 993 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 994 received 996 o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received 998 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 999 received 1001 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1002 received 1004 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is 1005 received 1007 These cannot happen because they are each something that happens 1008 AFTER a binding has been created. 1010 6.4.2. Initial State: INIT_BIND - A potential binding has been set up 1012 6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1013 is received 1015 The message MUST be forwarded to the corresponding client. 1017 If the message is DHCPv4 ACK, the Address field of the corresponding 1018 entry (i.e., the binding entry whose TID is the same of the message) 1019 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 1020 The Lifetime field is set to the sum of the lease time in ACK message 1021 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1023 If the message is DHCPv6 Reply, there are following cases: 1025 1. If the status code is not "Success", no modification on 1026 corresponding entries will be made. Corresponding entries will 1027 expire automatically if no "Success" Reply is received during the 1028 lifetime. The entries are not removed immediately due to the 1029 client may be able to use the addresses whenever a "Success" 1030 Reply is received ("If the client receives any Reply messages 1031 that do not indicate a NotOnLink status, the client can use the 1032 addresses in the IA and ignore any messages that indicate a 1033 NotOnLink status." [RFC3315]). 1035 2. If the status code is "Success", the SAVI device checks the IA 1036 options in the Reply message. 1038 A. If there are IA options in the Reply message, the SAVI device 1039 checks each IA option. When the first assigned address is 1040 found, the Address field of the binding entry with matched 1041 TID is set to the address. The Lifetime field is set to the 1042 sum of the lease time in Reply message and 1043 MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1044 If there are more than one address assigned in the message, 1045 new binding entries are set up for the remaining address 1046 assigned in the IA options. An example of the entries is 1047 illustrated in Figure 8. SAVI devices do not specially 1048 process IA options with NoAddrsAvail status, because there 1049 should be no address contained in such IA options. 1051 B. Otherwise, the DHCP Reply message is in response to a Confirm 1052 message. The state of the binding entries with matched TID 1053 is changed to BOUND. Because [RFC3315] does not require 1054 lease time of addresses to be contained in the Reply message, 1055 the SAVI device SHOULD send a LEASEQUERY [RFC5007] message 1056 querying by IP address to All_DHCP_Servers multicast address 1057 [RFC3315] or a list of configured DHCP server addresses. The 1058 Lease query message is generated for each IP address if 1059 multiple addresses are confirmed. The Lifetime of 1060 corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If 1061 there is no response message after MAX_LEASEQUERY_DELAY, send 1062 the LEASEQUERY message again. An example of the entries is 1063 illustrated in Figure 7. If the SAVI device does not send 1064 the LEASEQUERY message, a pre-configured lifetime 1065 DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 1066 (Note: it is RECOMMENDED to use T1 configured on DHCP servers 1067 as the DHCP_DEFAULT_LEASE.) 1069 Note: the SAVI devices do not check if the assigned addresses are 1070 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 1071 only source of valid addresses. However, the DHCP servers should be 1072 configured to make sure no duplicated addresses are assigned. 1074 +---------+----------+-------+------------------------+-------+ 1075 | Anchor | Address | State | Lifetime |TID | 1076 +---------+----------+-------+------------------------+-------+ 1077 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1078 +---------+----------+-------+------------------------+-------+ 1079 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1080 +---------+----------+-------+------------------------+-------+ 1082 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1083 Confirm 1085 +---------+----------+-------+------------------------+-------+ 1086 | Anchor | Address | State | Lifetime |TID | 1087 +---------+----------+-------+------------------------+-------+ 1088 | Port_1 | Addr1 | BOUND |Lease time+ |TID | 1089 | | | |MAX_DHCP_RESPONSE_TIME | | 1090 +---------+----------+-------+------------------------+-------+ 1091 | Port_1 | Addr2 | BOUND |Lease time+ |TID | 1092 | | | |MAX_DHCP_RESPONSE_TIME | | 1093 +---------+----------+-------+------------------------+-------+ 1095 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 1096 Request 1098 Resulting state: BOUND - The binding has been set up 1100 6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1101 expires 1103 The entry MUST be deleted from BST. 1105 Resulting state: An entry that has been deleted from the BST may be 1106 considered to be in the state "NO_BIND" - No binding has been set up. 1108 6.4.2.3. Events that are ignored in INIT_BIND 1110 If no DHCP Server-to-Client messages which assign addresses or 1111 confirm addresses are received, corresponding entries will expire 1112 automatically. Thus, other DHCP Server-to-Client messages (e.g., 1113 DHCPv4 NAK) are not specially processed. 1115 As a result, the following events, should they occur, are ignored 1116 until either a DHCPv4 ACK or a DHCPv6 Reply message is received or 1117 the lifetime of the binding entry expires. 1119 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1120 received 1122 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1124 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1126 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1127 received 1129 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 1130 received 1132 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1133 Commit option is received 1135 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1136 received 1138 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1139 received 1141 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is 1142 received 1144 In each case, the message MUST be forwarded. 1146 Resulting state: INIT_BIND - A potential binding has been set up 1148 6.4.3. Initial State: BOUND - The binding has been set up 1150 6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1151 expires 1153 The entry MUST be deleted from BST. 1155 Resulting state: An entry that has been deleted from the BST may be 1156 considered to be in the state "NO_BIND" - No binding has been set up. 1158 6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline 1159 message is received 1161 The message MUST be forwarded. 1163 The SAVI device first gets all the addresses ("Requested IP address" 1164 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1165 IA options of DHCPv6 Decline/Release) to decline/release in the 1166 message. Then the corresponding entries MUST be removed. 1168 Resulting state in each relevant BST entry: An entry that has been 1169 deleted from the BST may be considered to be in the state "NO_BIND" - 1170 No binding has been set up. 1172 6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release 1173 message is received 1175 The message MUST be forwarded. 1177 The SAVI device first gets all the addresses ("Requested IP address" 1178 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1179 IA options of DHCPv6 Decline/Release) to decline/release in the 1180 message. Then the corresponding entries MUST be removed. 1182 Resulting state in each relevant BST entry: An entry that has been 1183 deleted from the BST may be considered to be in the state "NO_BIND" - 1184 No binding has been set up. 1186 6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind 1187 message is received 1189 The message MUST be forwarded. 1191 In such case, a new TID will be used by the client. The TID field of 1192 the corresponding entries MUST be set to the new TID. Note that TID 1193 check will not be performed on such messages. 1195 Resulting state: BOUND: The binding has been set up 1197 6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew 1198 message is received 1200 The message MUST be forwarded. 1202 In such case, a new TID will be used by the client. The TID field of 1203 the corresponding entries MUST be set to the new TID. Note that TID 1204 check will not be performed on such messages. 1206 Resulting state: BOUND: The binding has been set up 1208 6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1209 is received 1211 The message MUST be forwarded. 1213 The DHCP Reply messages received in current states should be in 1214 response to DHCP Renew/Rebind. 1216 If the message is DHCPv4 ACK, the SAVI device updates the binding 1217 entry with matched TID, with the Lifetime field set to be the sum of 1218 the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in 1219 the state BOUND. 1221 If the message is DHCPv6 Reply, the SAVI device checks each IA 1222 Address option in each IA option. For each: 1224 1. If the IA entry in the REPLY message has the status "NoBinding", 1225 there is no address in the option, and no operation on an address 1226 is performed. 1228 2. If the valid lifetime of an IA address option is 0, the binding 1229 entry with matched TID and address is removed, leaving it 1230 effectively in the state NO_BIND. 1232 3. Otherwise, set the Lifetime field of the binding entry with 1233 matched TID and address to be the sum of the new valid lifetime 1234 and MAX_DHCP_RESPONSE_TIME, leaving the entry in the state BOUND. 1236 Resulting state: NO_BIND or BOUND, as specified. 1238 6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 1239 LEASEQUERY_REPLY is received 1241 The message MUST be forwarded. 1243 The message should be in response to the Lease query message sent in 1244 Section 6.4.2. The related binding entry can be determined based on 1245 the address in the IA Address option in the Lease query-reply 1246 message. The Lifetime field of the corresponding binding entry is 1247 set to the sum of the lease time in the LEASEQUERY_REPLY message and 1248 MAX_DHCP_RESPONSE_TIME. 1250 Resulting state: BOUND: The binding has been set up 1252 6.4.3.8. Events not processed in the state BOUND 1254 The following events are ignored if received while the indicated 1255 entry is in the state BOUND. Any required action will be the result 1256 of the next message in the client/server exchange. 1258 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1259 received 1261 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1263 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1265 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1266 Commit option is received 1268 6.4.4. Table of State Machine 1270 The main state transits are listed as follows. Note that not all the 1271 details are specified in the table and the diagram. 1273 State Event Action Next State 1274 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1275 INIT_BIND RPL Record lease time BOUND 1276 (send lease query if no lease) 1277 INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1278 BOUND RLS/DCL Remove entry NO_BIND 1279 BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1280 BOUND RPL Set new lifetime BOUND 1281 BOUND LQR Record lease time BOUND 1283 Figure 9: Table of Transit 1285 RQ: EVE_DHCP_REQUEST 1287 CF: EVE_DHCP_CONFIRM 1289 RC: EVE_DHCP_SOLICIT_RC 1291 RE: EVE_DHCP_REBOOT 1293 RPL: EVE_DHCP_REPLY 1295 DCL: EVE_DHCP_DECLINE 1297 RLS: EVE_DHCP_RELEASE 1299 LQR: EVE_DHCP_LEASEQUERY 1301 Timeout: EVE_ENTRY_EXPIRE 1302 +-------------+ 1303 | | 1304 /---------| NO_BIND |<----------\ 1305 | ------>| | | 1306 | | +-------------+ |EVE_DHCP_RELEASE 1307 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1308 EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE 1309 EVE_DHCP_SOLICIT_RC| | | 1310 EVE_DHCP_REBOOT | | | 1311 | | | 1312 | | | 1313 v | | 1314 +-------------+ +------------+ 1315 | | EVE_DHCP_REPLY | | 1316 | INIT_BIND ------------------------>| BOUND |<-\ 1317 | | | | | 1318 +-------------+ +------------+ | 1319 | | 1320 \--------/ 1321 EVE_DHCP_REPLY 1322 EVE_DHCP_LEASEQUERY 1324 Figure 10: Diagram of Transit 1326 7. Data Snooping Process 1328 7.1. Scenario 1330 The rationale of the DHCP Snooping Process specified in Section 6 is 1331 that if a DHCP client's use of a DHCP address is legitimate, the 1332 corresponding DHCP address assignment procedure must have been 1333 finished on the attachment of the DHCP client. This is the case 1334 stands when the SAVI device is persistently on the path(s) from the 1335 DHCP client to the DHCP server(s)/relay(s). However, there are two 1336 case when this does not work: 1338 o Multiple paths: there is more than one feasible link-layer paths 1339 from the client to the DHCP server/relay, and the SAVI device is 1340 not on everyone of them. The client may get its address through 1341 one of the paths not passing by the SAVI device, but packets from 1342 the client can travel through paths that pass through the SAVI 1343 device. Because the SAVI device could not snoop the DHCP packet 1344 exchange procedure, the DHCP snooping procedure cannot set up the 1345 corresponding binding. 1347 o Dynamic path: there is only one feasible link-layer path from the 1348 client to the DHCP server/relay, but the path is dynamic due to 1349 topology change (for example, some link turns broken due to 1350 failure or as planned) or link-layer path change. This situation 1351 also covers the local-link movement of clients without address 1352 confirm/re-configuration process. For example, a host changes its 1353 attached switch port in a very short time. In such cases, the 1354 DHCP snooping process will not set up the corresponding binding. 1356 Data Snooping Process prevents permanently blocking legitimate 1357 traffic in case of these two exceptions. This process is performed 1358 on attachments with the Data-Snooping attribute. Data packets 1359 without matching binding entry may trigger this process to set up 1360 bindings. 1362 Snooping data traffic introduces considerable burden on the processor 1363 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1364 overhead of this process, the implementation of this process is a 1365 conditional SHOULD. This function SHOULD be enabled unless the 1366 implementation is known to be used in the scenarios without the above 1367 exceptions. For example, if the implementation is to be used in 1368 networks with tree topology and without host local-link movement, 1369 there is no need to implement this process in such scenarios. 1371 This process is not intended to set up a binding whenever a data 1372 packet without matched binding entry is received. Instead, unmatched 1373 data packets trigger this process probabilistically and generally a 1374 number of unmatched packets will be discarded before the binding is 1375 set up. 1377 7.2. Rationale 1379 This process makes use of NS/ARP and DHCP LEASEQUERY to set up 1380 bindings. If an address is not used by another client in the 1381 network, and the address has been assigned in the network, the 1382 address can be bound with the binding anchor of the attachment from 1383 which the unmatched packet is received. 1385 The security issues about this process is discussed is Section 11.1. 1387 7.3. Additional Binding States Description 1389 In addition to NO_BIND and BOUND from Section 6.2, two new states 1390 used in this process are listed here. The INIT_BIND state is not 1391 used, as it is entered by observing a DHCP message. 1393 DETECTION: The address in the entry is under local duplication 1394 detection. 1396 RECOVERY: The SAVI device is querying the assignment and lease time 1397 of the address in the entry through DHCP Lease query. 1399 7.4. Events 1401 In addition to EVE_DATA_LEASEQUERY and EVE_DHCP_REBIND, these 1402 additional events are described here. If an event will trigger the 1403 creation of a new binding entry, the binding entry limit on the 1404 binding anchor MUST NOT be exceeded. 1406 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1408 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1409 against an address in DETECTION state is received from a host other 1410 than the one for which the entry was added. 1412 EVE_DATA_LEASEQUERY: 1414 o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1415 is received. 1417 o IPv6: A successful LEASEQUERY-REPLY is received. 1419 The triggering packet should pass the following checks to trigger a 1420 valid event: 1422 o Attribute check: the data packet should be from attachments with 1423 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1424 messages should be from attachments with DHCP-Snooping attribute. 1426 o Binding limitation check: the DHCP messages must not cause new 1427 binding setup on an attachment whose binding entry limitation has 1428 been reached. (refer to Section 11.5). 1430 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1431 DHCP Lease query messages must pass the check specified in 1432 Section 8.2. For EVE_DATA_CONFLICT, the source address and target 1433 address of the ARP or NA messages must pass the check specified in 1434 Section 8.2. 1436 o Interval check: the interval between two successive 1437 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1438 smaller than DATA_SNOOPING_INTERVAL. 1440 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have 1441 matched TID with the corresponding entry. 1443 o Prefix check: the source address of the data packet should be of a 1444 valid local prefix, as specified in section 7 of [RFC7039]. 1446 EVE_ENTRY_EXPIRE: A timer expires. 1448 7.5. Initial State: state NO_BIND - No binding has been set up 1450 7.5.1. Event: EVE_DATA_UNMATCH: A data packet without matched binding 1451 is received 1453 Make a probabilistic determination whether to act on this event. The 1454 probability may be configured or calculated based on the state of the 1455 SAVI device. This probability should be low enough to mitigate the 1456 damage from DoS attack against this process. 1458 Create a new entry in the BST. Set the Binding Anchor field to the 1459 corresponding binding anchor of the attachment. Set the Address 1460 field to the source address of the packet. Set the State field to 1461 DETECTION. Set the Lifetime of the created entry to 1462 2*DETECTION_TIMEOUT. 1464 Check if the address has a local conflict (it violates an address 1465 being used by another node): 1467 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1468 [RFC0826] or an ARP probe [RFC5227] on the address; if there is 1469 no response message after DETECTION_TIMEOUT, send another ARP 1470 Request or ARP probe; 1472 (2) IPv6 address: send a Duplicate Address Detection message 1473 [RFC4861] targeting the address; ideally, only the host on that 1474 point of attachment responds with a Neighbor Advertisement; if 1475 more than one Neighbor Advertisement is observed, the BST entry 1476 should be removed. 1478 Because the delivery of the detection message is unreliable, the 1479 detection message may fail to reach the targeting node. If there is 1480 a node that has the IP address seen in the Data Snooping Process, it 1481 may not get the detection messages. This failure mode enables an 1482 attack against the Data Snooping Process. Thus, the detection is 1483 performed again if there is no response after the first detection. 1485 The packet that triggers this event SHOULD be discarded. 1487 This local conflict process SHOULD be performed. If it is not 1488 performed, the state of the entry is set to RECOVERY, the lifetime is 1489 set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified 1490 in the following section will be performed directly. 1492 An example of the entry is illustrated in Figure 11. 1494 +---------+-------+---------+-----------------------+-------+ 1495 | Anchor |Address| State | Lifetime |TID | 1496 +---------+-------+---------+-----------------------+-------+ 1497 | Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | 1498 +---------+-------+---------+-----------------------+-------+ 1500 Figure 11: Binding entry in BST on data triggered initialization 1502 Resulting state: DETECTION - The address in the entry is under local 1503 duplication detection 1505 7.5.2. Events not observed in NO_BIND 1507 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1508 received from unexpected system 1510 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1512 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1513 received 1515 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1516 received 1518 EVE_ENTRY_EXPIRE 1520 7.6. Initial State: state DETECTION - The address in the entry is under 1521 local duplication detection 1523 7.6.1. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) 1525 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1526 by IP address to each DHCPv4 server with IP Address Lease Time 1527 option (option 51). A list of authorized DHCP servers are kept 1528 by the SAVI device. The list should be pre-configured or 1529 discovered by sending DHCPv4 Discover messages and parsing the 1530 replied DHCPv4 Offer messages. Change the state of the 1531 corresponding entry to RECOVERY. Change the lifetime of the 1532 entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the 1533 TID used in the DHCPLEASEQUERY message. If there is no response 1534 message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to each 1535 DHCPv4 server again. 1537 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1538 address to All_DHCP_Relay_Agents_and_Servers multicast address or 1539 a list of pre-configured DHCPv6 server addresses. Change the 1540 state of the corresponding entry to RECOVERY. Change the 1541 lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID 1542 field is set to the TID used in the LEASEQUERY message. If there 1543 is no response message after MAX_LEASEQUERY_DELAY, send the 1544 LEASEQUERY message again. 1546 An example of the entry is illustrated in Figure 12. 1548 +---------+-------+---------+-----------------------+-------+ 1549 | Anchor |Address| State | Lifetime |TID | 1550 +---------+-------+---------+-----------------------+-------+ 1551 | Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | 1552 +---------+-------+---------+-----------------------+-------+ 1554 Figure 12: Binding entry in BST on Lease Query 1556 Resulting state: RECOVERY - The SAVI device is querying the 1557 assignment and lease time of the address in the entry through DHCP 1558 Leasequery 1560 7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) 1561 message received from unexpected system 1563 Remove the entry. 1565 Resulting state: NO_BIND - No binding has been set up 1567 7.6.3. Events not observed in DETECTION 1569 EVE_DATA_UNMATCH: A data packet without matched binding is received 1571 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1573 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1574 received 1576 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1577 received 1579 7.7. Initial State: state RECOVERY - The SAVI device is querying the 1580 assignment and lease time of the address in the entry through DHCP 1581 Leasequery 1583 7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 1584 LEASEQUERY-REPLY is received 1586 IPv4 address: 1588 (1) Send an ARP Request with the Target Protocol Address set to the 1589 IP address in the corresponding entry. The ARP Request is only 1590 sent to the attachment which triggers the binding. If there is 1591 no response after DETECTION_TIMEOUT, send another ARP Request. 1592 If there is still no response, remove the entry. 1594 (2) If there is only one identical response, get the sender hardware 1595 address. Check if the 'chaddr' field (hardware address) of the 1596 DHCPLEASEACTIVE message matches the sender hardware address. If 1597 the two addresses do not match, the following actions will not be 1598 performed. If there is more than one response, if any of the 1599 sender hardware addresses matches the 'chaddr' field (hardware 1600 address) of the DHCPLEASEACTIVE message, 1602 * Set life time to the sum of the value encoded in IP Address 1603 Lease Time option of the DHCPLEASEACTIVE message and 1604 MAX_DHCP_RESPONSE_TIME. 1606 * Erase the TID field. 1608 IPv6 address: 1610 (1) Send a Neighbor Solicitation message with the target address set 1611 to the IP address in the corresponding entry. The Neighbor 1612 Solicitation is only sent to the attachment which triggers the 1613 binding. If there is no response after DETECTION_TIMEOUT, send 1614 another Neighbor Solicitation. If there is still no response, 1615 remove the entry. 1617 (2) On receipt of a valid Neighbor Announcement, 1619 * Set the lifetime to the sum of the valid lifetime extracted 1620 from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY 1621 message and MAX_DHCP_RESPONSE_TIME. 1623 * Erase the TID field. 1625 * After the above checks, if multiple addresses are specified 1626 in the LEASEQUERY-REPLY message and there are no 1627 corresponding binding entries, new entries MUST also be 1628 created correspondingly on the same binding anchor. 1630 In the event that responses are received from multiple DHCP servers, 1631 the conflict resolution mechanisms specified in section 6.8 of 1632 [RFC4388] and section 4.3.4 of [RFC5007] will be used to determine 1633 which message should be used. 1635 Resulting state: if ARP or ND succeeds (there is a valid response), 1636 BOUND - The binding has been set up. Otherwise, the resulting state 1637 is NO_BIND - No binding has been set up 1639 7.7.2. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) 1641 Remove the entry 1643 Resulting state: NO_BIND - No binding has been set up 1645 7.7.3. Events not observed in RECOVERY 1647 EVE_DATA_UNMATCH: A data packet without matched binding is received 1649 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1650 received from unexpected system 1652 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1654 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1655 received 1657 7.8. Initial State: state BOUND - The binding has been set up 1659 Note that the TID field contains no value after the binding state 1660 changes to BOUND. The TID field is recovered from snooping DHCP 1661 Renew/Rebind messages. Because TID is used to associate binding 1662 entries with messages from DHCP servers, it must be recovered; or 1663 else a number of state transits of this mechanism will be not 1664 executed normally. 1666 7.8.1. Event: EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message 1667 is received 1669 Set the TID field of the corresponding entry to the TID in the 1670 triggering message. 1672 Resulting state: BOUND - The binding has been set up 1674 7.8.2. Event: EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind 1675 message is received 1677 Set the TID field of the corresponding entry to the TID in the 1678 triggering message. 1680 Resulting state: BOUND - The binding has been set up 1682 7.8.3. Events not observed in BOUND 1684 EVE_DATA_UNMATCH: A data packet without matched binding is received 1686 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1687 received from unexpected system 1689 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1690 received 1692 EVE_ENTRY_EXPIRE 1694 7.9. Table of State Machine 1696 The main state transits are listed as follows. 1698 State Event Action Next State 1699 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1700 DETECTION EVE_ENTRY_EXPIRE Send Leasequery RECOVERY 1701 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1702 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND 1703 RECOVERY EVE_ENTRY_EXPIRE Remove entry NO_BIND 1704 BOUND RENEW/REBIND Record TID BOUND 1706 Figure 13: Table of Transit 1708 RENEW: EVE_DHCP_RENEW 1710 REBIND: EVE_DHCP_REBIND 1712 Timeout: EVE_ENTRY_EXPIRE 1713 +-------------+ 1714 | | 1715 /---------| NO_BIND |<--------\ 1716 | ------>| | | EVE_ENTRY_EXPIRE 1717 | | +-------------+ |(2nd LQ_DELAY) 1718 EVE_DATA_UNMATCH | | | 1719 | | | 1720 1st | | | 1721 DETECTION_TIMEOUT | | | 1st LQ_DELAY 1722 /------\ | | | /---------\ 1723 | | | | EVE_DATA_CONFLICT | | | 1724 | v v | | v | 1725 | +-------------+ EVE_ENTRY_EXPIRE +------------+ | 1726 | | |(2nd DETECTION_TIMEOUT) | | | 1727 \----| DETECTION ------------------------>| RECOVERY ----/ 1728 | | | | 1729 +-------------+ +------------+ 1730 EVE_DATA_LEASEQUERY| 1731 /----------\ (+ 2x DETECTION) | 1732 EVE_DHCP_RENEW| | | 1733 EVE_DHCP_REBIND| +-----v-------+ | 1734 | | | | 1735 \----| BOUND |<----------/ 1736 | | 1737 +-------------+ 1739 Figure 14: Diagram of Transit 1741 LQ_DELAY: MAX_LEASEQUERY_DELAY 1743 8. Filtering Specification 1745 This section specifies how to use bindings to filter out packets with 1746 spoofed source addresses. 1748 Filtering policies are different for data packets and control 1749 packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861] 1750 messages are classified as control packets. All other packets are 1751 classified as data packets. 1753 8.1. Data Packet Filtering 1755 Data packets from attachments with the Validating attribute MUST be 1756 checked. 1758 Packet whose source IP address is a link-local address will not be 1759 checked. Note: as explained in Section 1, a SAVI solution for link- 1760 local addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to 1761 check packets with link-local source address. 1763 If the source IP address of a packet is not a link-local address, but 1764 there is not a matched entry in BST with state BOUND, this packet 1765 MUST be discarded. However, the packet may trigger the Data Snooping 1766 Process Section 7 if the Data-Snooping attribute is set on the 1767 attachment. 1769 Data packets from attachments with no attribute will forwarded 1770 without being validated. 1772 The SAVI device MAY log packets that fail source address validation. 1774 8.2. Control Packet Filtering 1776 For attachments with the Validating attribute: 1778 DHCPv4 Client-Server messages in which the source IP address is 1779 neither all zeros nor bound with the corresponding binding anchor in 1780 the BST MUST be discarded. 1782 DHCPv6 Client-Server messages in which the source IP address is 1783 neither a link-local address nor bound with the corresponding binding 1784 anchor in the BST MUST be discarded. 1786 NDP messages in which the source IP address is neither a link-local 1787 address nor bound with the corresponding binding anchor MUST be 1788 discarded. 1790 NA messages in which the target address is neither a link-local 1791 address nor bound with the corresponding binding anchor MUST be 1792 discarded. 1794 ARP messages in which the protocol is IP and sender protocol address 1795 is neither all zeros address nor bound with the corresponding binding 1796 anchor MUST be discarded. 1798 ARP Reply messages in which the target protocol address is not bound 1799 with the corresponding binding anchor MUST be discarded. 1801 For attachments with other attributes: 1803 DHCP Server-to-Client messages not from attachments with the DHCP- 1804 Trust attribute or Trust attribute MUST be discarded. 1806 For attachments with no attribute: 1808 DHCP Server-to-Client messages from such attachments MUST be 1809 discarded. 1811 The SAVI device MAY record any messages that are discarded. 1813 9. State Restoration 1815 If a SAVI device reboots, the information kept in volatile memory 1816 will be lost. This section specifies the restoration of attribute 1817 configuration and BST. 1819 9.1. Attribute Configuration Restoration 1821 The loss of attribute configuration will not break the network: no 1822 action will be performed on traffic from attachments with no 1823 attribute. However, the loss of attribute configuration makes this 1824 SAVI function unable to work. 1826 To avoid the loss of binding anchor attribute configuration, the 1827 configuration MUST be able to be stored in non-volatile storage. 1828 After the reboot of SAVI device, if the configuration of binding 1829 anchor attribute can be found in non-volatile storage, the 1830 configuration MUST be used. 1832 9.2. Binding State Restoration 1834 The loss of binding state will cause the SAVI devices discard 1835 legitimate traffic. Purely using the Data Snooping Process to 1836 recover a large number of bindings is of heavy overhead and 1837 considerable delay. Thus, to recover bindings from non-volatile 1838 storage, as specified below, is RECOMMENDED. 1840 Binding entries MAY be saved into non-volatile storage whenever a new 1841 binding entry changes to BOUND state. If a binding with BOUND state 1842 is removed, the saved entry MUST be removed correspondingly. The 1843 time when each binding entry is established is also saved. 1845 Immediately after reboot, the SAVI device SHOULD restore binding 1846 states from the non-volatile storage. The system time of save 1847 process MUST be stored. After rebooting, the SAVI device MUST check 1848 whether each entry has been obsolete by comparing the saved lifetime 1849 and the difference between the current time and time when the binding 1850 entry is established. 1852 10. Constants 1854 MAX_DHCP_RESPONSE_TIME 120s 1856 DATA_SNOOPING_INTERVAL 60s and configurable 1858 MAX_LEASEQUERY_DELAY 10s 1860 OFFLINK_DELAY 30s 1862 DETECTION_TIMEOUT 0.5s 1864 11. Security Considerations 1866 11.1. Security Problems about the Data Snooping Process 1868 There are two security problems about the Data Snooping Process 1869 Section 7: 1871 (1) The Data Snooping Process is costly, but an attacker can trigger 1872 it simply through sending a number of data packets. To avoid 1873 Denial of Services attack against the SAVI device itself, the 1874 Data Snooping Process MUST be rate limited. A constant 1875 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1876 Data Snooping Processes on one attachment MUST have a minimum 1877 interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be 1878 configured prudently to avoid Denial of Service attacks. 1880 (2) The Data Snooping Process may set up wrong bindings if the 1881 clients do not reply to the detection probes. An attack will 1882 pass the duplicate detection if the client assigned the target 1883 address does not reply to the detection probes. The DHCP Lease 1884 query procedure performed by the SAVI device just tells whether 1885 the address is assigned in the network or not. However, the SAVI 1886 device cannot determine whether the address is just assigned to 1887 the triggering attachment from the DHCP LEASEQUERY Reply. 1889 11.2. Client departure issues 1891 After a binding is set up, the corresponding client may leave its 1892 attachment point. It may depart temporarily due to signal fade, or 1893 permanently by moving to a new attachment point or leaving the 1894 network. In the signal fade case, since the client may return 1895 shortly, the binding should be kept momentarily, lest legitimate 1896 traffic from the client be blocked. However, if the client leaves 1897 permanently, keeping the binding can be a security issue. If the 1898 binding anchor is a property of the attachment point rather than the 1899 client, e.g., the switch port but not incorporating the MAC Address, 1900 an attacker using the same binding anchor can send packets using IP 1901 addresses assigned to the client. Even if the binding anchor is a 1902 property of the client, retaining binding state for a departed client 1903 for a long time is a waste of resources. 1905 Whenever a direct client departs from the network, a link-down event 1906 associated with the binding anchor will be triggered. SAVI-DHCP 1907 monitors such events, and performs the following mechanism. 1909 (1) Whenever a client with the Validating attribute leaves, a timer 1910 of duration OFFLINK_DELAY is set on the corresponding binding 1911 entries. 1913 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 1914 received that targets the address during OFFLINK_DELAY, the entry 1915 MAY be removed. 1917 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 1918 timer. 1920 In this way, the bindings of a departing client are kept for 1921 OFFLINK_DELAY. In case of link flapping, the client will not be 1922 blocked. If the client leaves permanently, the bindings will be 1923 removed after OFFLINK_DELAY. 1925 SAVI-DHCP does not handle the departure of indirect clients, because 1926 it will not be notified of such events. Switches supporting indirect 1927 attachment (e.g., through a separate non-SAVI switch) SHOULD use 1928 information specific to the client such as its MAC address as part of 1929 the binding anchor. 1931 11.3. Duplicate Bindings to the Same Address 1933 The same address may be bound to multiple binding anchors only if the 1934 binding setup processes successfully complete for each binding 1935 anchor. This mechanism is designed to address the case where a 1936 client moves on the local link, and the case where a client has 1937 multiple attachments to a SAVI device. 1939 There are two security issues with such a design: 1941 First, by allowing one address to be bound to multiple binding 1942 anchors, the traceability of the address is weakened. An address can 1943 be traced to multiple attachments. 1945 Second, in the local link movement scenario, the former binding may 1946 not be removed and it can be used by an attacker sharing the same 1947 binding anchor. For example, when a switch port is used as binding 1948 anchor and the port is shared by an attacker and a client with a hub, 1949 the attacker can make use of the address assigned to the client after 1950 the client leaves. 1952 11.4. Compatibility with DNA (Detecting Network Attachment) 1954 DNA [RFC4436][RFC6059] is designed to decrease the handover latency 1955 after re-attachment to the same network. DNA mainly relies on 1956 performing reachability test by sending unicast Neighbor Solicitation 1957 /Router Solicitation/ARP Request message to determine whether a 1958 previously configured address is still valid. 1960 Although DNA provides optimization for clients, there is insufficient 1961 information for this mechanism to migrate the previous binding or 1962 establish a new binding. If a binding is set up only by snooping the 1963 reachability test message, the binding may be invalid. For example, 1964 an attacker can perform reachability test with an address bound to 1965 another client. If binding is migrated to the attacker, the attacker 1966 can successfully obtain the binding from the victim. Because this 1967 mechanism wouldn't set up a binding based on snooping the DNA 1968 procedure, it cannot achieve perfect compatibility with DNA. 1969 However, it only means the re-configuration of the interface is 1970 slowed but not prevented. Details are discussed as follows. 1972 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1973 set to a link-local address, and such messages will not be discarded 1974 by the policy specified in Section 8.2. If a client is re-attached 1975 to a previous network, the detection will be completed, and the 1976 address will be regarded as valid by the client. However, the 1977 candidate address is not contained in the probe. Thus, the binding 1978 cannot be recovered through snooping the probe. As the client will 1979 perform DHCP exchange at the same time, the binding will be recovered 1980 from the DHCP Snooping Process. The DHCP Request messages will not 1981 be filtered out in this case because they have link-local source 1982 addresses. Before the DHCP procedure is completed, packets will be 1983 filtered out by the SAVI device. In other words, if this SAVI 1984 function is enabled, Simple DNAv6 will not help reduce the handover 1985 latency. If Data-Snooping attribute is configured on the new 1986 attachment of the client, the data triggered procedure may reduce 1987 latency. 1989 In DNAv4 [RFC4436], the ARP probe will be discarded because an 1990 unbound address is used as the sender protocol address. As a result, 1991 the client will regard the address under detection is valid. 1992 However, the data traffic will be filtered. The DHCP Request message 1993 sent by the client will not be discarded, because the source IP 1994 address field should be all zero as required by [RFC2131]. Thus, if 1995 the address is still valid, the binding will be recovered from the 1996 DHCP Snooping Process. 1998 11.5. Binding Number Limitation 2000 A binding entry will consume a certain high-speed memory resources. 2001 In general, a SAVI device can afford only a quite limited number of 2002 binding entries. In order to prevent an attacker from overloading 2003 the resource of the SAVI device, a binding entry limit is set on each 2004 attachment. The binding entry limit is the maximum number of 2005 bindings supported on each attachment with Validating attribute. No 2006 new binding should be set up after the limit has been reached. If a 2007 DHCP Reply assigns more addresses than the remaining binding entry 2008 quota of each client, the message will be discarded and no binding 2009 will be set up. 2011 11.6. Privacy Considerations 2013 A SAVI device MUST delete binding anchor information as soon as 2014 possible (i.e., as soon as the state for a given address is back to 2015 NO_BIND), except where there is an identified reason why that 2016 information is likely to be involved in the detection, prevention, or 2017 tracing of actual source address spoofing. Information about the 2018 majority of hosts that never spoof SHOULD NOT be logged. 2020 12. IANA Considerations 2022 This memo asks the IANA for no new parameters. 2024 13. Acknowledgment 2026 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 2027 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 2028 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 2029 Garcia for careful review and valuation comments on the mechanism and 2030 text. 2032 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 2033 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 2034 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 2035 their valuable contributions. 2037 This document was generated using the xml2rfc tool. 2039 14. References 2041 14.1. Normative References 2043 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2044 converting network protocol addresses to 48.bit Ethernet 2045 address for transmission on Ethernet hardware", STD 37, 2046 RFC 826, November 1982. 2048 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2049 Requirement Levels", BCP 14, RFC 2119, March 1997. 2051 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2052 2131, March 1997. 2054 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2055 and M. Carney, "Dynamic Host Configuration Protocol for 2056 IPv6 (DHCPv6)", RFC 3315, July 2003. 2058 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 2059 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 2061 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 2062 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 2064 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2065 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2066 September 2007. 2068 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 2069 "DHCPv6 Leasequery", RFC 5007, September 2007. 2071 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 2072 July 2008. 2074 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 2075 Detecting Network Attachment in IPv6", RFC 6059, November 2076 2010. 2078 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2079 SAVI: First-Come, First-Served Source Address Validation 2080 Improvement for Locally Assigned IPv6 Addresses", RFC 2081 6620, May 2012. 2083 14.2. Informative References 2085 [I-D.ietf-opsec-dhcpv6-shield] 2086 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 2087 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 2088 opsec-dhcpv6-shield-04 (work in progress), July 2014. 2090 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2091 Defeating Denial of Service Attacks which employ IP Source 2092 Address Spoofing", BCP 38, RFC 2827, May 2000. 2094 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 2095 (DHCP) Service for IPv6", RFC 3736, April 2004. 2097 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 2098 "Source Address Validation Improvement (SAVI) Framework", 2099 RFC 7039, October 2013. 2101 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 2102 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 2103 7341, August 2014. 2105 Authors' Addresses 2107 Jun Bi 2108 Tsinghua University 2109 Network Research Center, Tsinghua University 2110 Beijing 100084 2111 China 2113 EMail: junbi@tsinghua.edu.cn 2115 Jianping Wu 2116 Tsinghua University 2117 Computer Science, Tsinghua University 2118 Beijing 100084 2119 China 2121 EMail: jianping@cernet.edu.cn 2122 Guang Yao 2123 Tsinghua University 2124 Network Research Center, Tsinghua University 2125 Beijing 100084 2126 China 2128 EMail: yaoguang@cernet.edu.cn 2130 Fred Baker 2131 Cisco Systems 2132 Santa Barbara, CA 93117 2133 United States 2135 EMail: fred@cisco.com