idnits 2.17.1 draft-ietf-savi-dhcp-32.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 (January 26, 2015) is 3378 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: July 30, 2015 Tsinghua Univ. 6 F. Baker 7 Cisco 8 January 26, 2015 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-32 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 July 30, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Deployment Scenario and Configuration . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 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.9. Table of State Machine . . . . . . . . . . . . . . . . . 36 114 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 38 115 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 38 116 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 38 117 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 39 118 9.1. Attribute Configuration Restoration . . . . . . . . . . . 39 119 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 39 120 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 40 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 122 11.1. Security Problems about the Data Snooping Process . . . 40 123 11.2. Client departure issues . . . . . . . . . . . . . . . . 41 124 11.3. Duplicate Bindings to the Same Address . . . . . . . . . 42 125 11.4. Compatibility with DNA (Detecting Network Attachment) . 42 126 11.5. Binding Number Limitation . . . . . . . . . . . . . . . 43 127 11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 43 128 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 129 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 44 130 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 131 14.1. Normative References . . . . . . . . . . . . . . . . . . 44 132 14.2. Informative References . . . . . . . . . . . . . . . . . 45 134 1. Introduction 136 This document describes a fine-grained source IPv4 or IPv6 source 137 address validation mechanism. This mechanism creates bindings 138 between IP addresses assigned to network interfaces by DHCP and 139 suitable binding anchors (Section 4.3.5). As discussed in Section 3 140 and [RFC7039], a "binding anchor" is an attribute that is immutable 141 or difficult to change that may be used to identify the system an IP 142 address has been assigned to; common examples include a MAC address 143 found on an Ethernet switch port or WiFi security association. The 144 bindings are used to identify and filter packets originated by these 145 interfaces using forged source IP addresses. In this way, this 146 mechanism can prevent hosts from using IP addresses assigned to the 147 other attachment points or invalid in the network. This behavior is 148 referred to as "spoofing", and is key to amplification attacks, in 149 which a set of systems send messages to another set of systems 150 claiming to be from a third set of systems, and sending the replies 151 to systems that don't expect them. If [RFC2827] protects a network 152 from a neighboring network by providing prefix granularity source IP 153 address validity, this mechanism protects a network, including a 154 Local Area Network, from itself by providing address granularity 155 source IP validity when DHCP/DHCPv6 is used to assign IPv4/IPv6 156 addresses. Both provide a certain level of traceability, in that 157 packet drops indicate the presence of a system that is producing 158 packets with spoofed IP addresses. 160 SAVI-DHCP snoops DHCP address assignments to set up bindings between 161 IP addresses assigned by DHCP and corresponding binding anchors. It 162 includes the DHCPv4 and v6 snooping process (Section 6), the Data 163 Snooping process (Section 7), as well as a number of other technical 164 details. The Data Snooping process is a data-triggered procedure 165 that snoops the header of data packet to set up bindings. It is 166 designed to avoid a permanent block of valid addresses in the case 167 that DHCP snooping is insufficient to set up all the valid bindings. 169 This mechanism is designed for the stateful DHCP scenario [RFC2131], 170 [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this 171 document, as it has nothing to do with IP address allocation. The 172 appropriate SAVI method must be used in those cases. For hosts using 173 Stateless Auto-Configuration to allocate addresses, SAVI-FCFS 174 [RFC6620] should be enabled. Besides, this mechanism is primarily 175 designed for pure DHCP scenarios in which only addresses assigned 176 through DHCP are allowed. However, it does not block link-local 177 addresses, as they are not assigned using DHCP. It is RECOMMENDED 178 that the administration enable a SAVI solution for link-local 179 addresses, e.g., SAVI-FCFS [RFC6620]. 181 This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and 182 DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6 183 transition scenarios, e.g., [RFC7341], are beyond the scope of this 184 document. 186 2. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 3. Terminology 194 Binding anchor: A "binding anchor" is defined to be a physical and/or 195 link-layer property of an attached device, as in [RFC7039]. A list 196 of sample binding anchors can be found in Section 3.2 of that 197 document. To the degree possible, a binding anchor associates an IP 198 address with something unspoofable that identifies a single client 199 system or one of its interfaces. See Section 4.3.5 for more detail. 201 Attribute: A configurable property of each binding anchor (port, MAC 202 Address, or other information) that indicates the actions to be 203 performed on packets received from the attached network device. 205 DHCP address: An IP address assigned via DHCP. 207 SAVI-DHCP: The name of this SAVI function for DHCP-assigned 208 addresses. 210 SAVI device: A network device on which SAVI-DHCP is enabled. 212 Non-SAVI device: A network device on which SAVI-DHCP is not enabled. 214 DHCP Client-Server message: A message that is sent from a DHCP client 215 to a DHCP server or DHCP servers. Such a message is of one of the 216 following types: 218 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 220 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 221 [RFC2131] 223 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 224 [RFC2131] 226 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 227 [RFC2131] 229 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 230 [RFC2131] 232 o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be 233 identified based on the Table 4 of [RFC2131] 235 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 237 o DHCPv4 Release: DHCPRELEASE [RFC2131] 239 o DHCPv4 Inform: DHCPINFORM [RFC2131] 240 o DHCPv6 Request: REQUEST [RFC3315] 242 o DHCPv6 Solicit: SOLICIT [RFC3315] 244 o DHCPv6 Confirm: CONFIRM [RFC3315] 246 o DHCPv6 Decline: DECLINE [RFC3315] 248 o DHCPv6 Release: RELEASE [RFC3315] 250 o DHCPv6 Rebind: REBIND [RFC3315] 252 o DHCPv6 Renew: RENEW [RFC3315] 254 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 256 DHCP Server-to-Client message: A message that is sent from a DHCP 257 server to a DHCP client. Such a message is of one of the following 258 types: 260 o DHCPv4 ACK: DHCPACK [RFC2131] 262 o DHCPv4 NAK: DHCPNAK [RFC2131] 264 o DHCPv4 Offer: DHCPOFFER [RFC2131] 266 o DHCPv6 Reply: REPLY [RFC3315] 268 o DHCPv6 Advertise: ADVERTISE [RFC3315] 270 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 272 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 273 IPv6 [RFC3315]. 275 Binding entry: A rule that associates an IP address with a binding 276 anchor. 278 Binding State Table (BST): The data structure that contains the 279 binding entries. 281 Binding entry limit: The maximum number of binding entries that may 282 be associated with a binding anchor. Limiting the number of binding 283 entries per binding anchor prevents a malicious or malfunctioning 284 node from overloading the binding table on a SAVI device. 286 Direct attachment: Ideally, a SAVI device is an access device that 287 hosts are attached to directly. In such a case, the hosts are direct 288 attachments (e.g., they attach directly) to the SAVI device. 290 Indirect attachment: A SAVI device MAY be an aggregation device that 291 other access devices are attached to, and which hosts in turn attach 292 to. In such a case, the hosts are indirect attachments (e.g., they 293 attach indirectly) to the SAVI device. 295 Unprotected link: Unprotected links are links that connect to hosts 296 or networks of hosts that the device may not see DHCP messages to, 297 and are therefore outside the SAVI perimeter. 299 Unprotected device: An unprotected device is a device associated with 300 an unprotected link. One example might be the gateway router of a 301 network. 303 Protected link: Protected links are links that connect to hosts that 304 the device will invariably see DHCP messages to, and are therefore 305 within the SAVI perimeter. 307 Protected device: A protected device is a device associated with a 308 protected link. One example might be a desktop switch in the 309 network, or a host. 311 Cut Vertex: A cut vertex is any vertex whose removal increases the 312 number of connected components. This is a concept in graph theory. 313 This term is used in Section 6.1 to accurately specify the required 314 deployment location of SAVI devices when they only perform the DHCP 315 snooping process. 317 Identity Association (IA): "A collection of addresses assigned to a 318 client." [RFC3315] 320 Detection message: a Neighbor Solicitation or ARP message intended to 321 detect a duplicate address by the Data Snooping Process. 323 DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the 324 binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease 325 query exchange [RFC5007] cannot be performed by the SAVI device to 326 fetch the lease. 328 4. Deployment Scenario and Configuration 329 4.1. Elements and Scenario 331 The essential elements in a SAVI-DHCP deployment scenario include a 332 DHCP server (which may or may not be assigned an address using DHCP, 333 and therefore may or may not be protected), zero or more protected 334 DHCP clients, and one or more SAVI devices. It may also include DHCP 335 relays, when the DHCP server is not co-located with a set of clients, 336 and zero or more protected Non-SAVI devices. Outside the perimeter, 337 via unprotected links, there may be many unprotected devices. 339 +--------+ +------------+ +----------+ 340 |DHCP |-----| Non-SAVI |----|Bogus DHCP| 341 |Server A| | Device 1 | |Server | 342 +--------+ +-----|------+ +----------+ 343 |unprotected link 344 . . . . . . . . . . .|. . . . . . . . . . . . . . 345 . | . 346 . Protection +---|------+ . 347 . Perimeter | SAVI |--------------+ . 348 . | Device C| | . 349 . +---|------+ | . 350 . | | . 351 . +----------+ +---|------+ +------|---+ . 352 protected . | SAVI | | Non SAVI| | SAVI | . 353 link +----.-| Device A|----| Device 3|-------| Device B| . 354 | . +----|--|--+ +----------+ +-|---|----+ . 355 | . | +----------+ . . . . . | | . 356 | '. . . . . . . | . . | | . 357 | | . | . +--------+ | . 358 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 359 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 360 | Device 2 | |A | . |Relay | . |B | . |Server B| . 361 +----------+ +------+ . +------+ . +------+ . +--------+ . 362 . . . . . . . . . . . . 364 Figure 1: SAVI-DHCP Scenario 366 Figure 1 shows a deployment scenario that contains these elements. 367 Note that a physical device can instantiate multiple elements, e.g., 368 a switch can be both a SAVI device and a DHCP relay, or in a cloud 369 computing environment, a physical host may contain a virtual switch 370 plus some number of virtual hosts. In such cases, the links are 371 logical links rather than physical links. 373 Networks are not usually isolated. As a result, traffic from other 374 networks, including transit traffic as specified in [RFC6620] (e.g., 375 traffic from another SAVI switch or a router) may enter a SAVI-DHCP 376 network through the unprotected links. Since SAVI solutions are 377 limited to validating traffic generated from a local link, SAVI-DHCP 378 does not set up bindings for addresses assigned in other networks and 379 cannot validate them. Traffic from unprotected links should be 380 checked by an unprotected system or [RFC2827] mechanisms. The 381 generation and deployment of such a mechanism is beyond the scope of 382 this document. 384 Traffic from protected links is, however, locally generated, and 385 should be checked by SAVI-DHCP if possible. In the event that there 386 is an intervening protected non-SAVI device between the host and the 387 SAVI device, however, use of the physical attachment point alone as a 388 binding anchor is insufficiently secure, as the several devices on a 389 port or other point of attachment can spoof each other. Hence, 390 additional information such as a MAC address SHOULD be used to 391 disambiguate them. 393 4.2. SAVI Binding Type Attributes 395 As illustrated in Figure 1, a system attached to a SAVI device can be 396 a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI 397 device. Different actions are performed on traffic originated from 398 different elements. To distinguish among their requirements, several 399 properties are associated with their point of attachment on the SAVI 400 device. 402 When a binding association is uninstantiated, e.g., when no host is 403 attached to the SAVI device using a given port or other binding 404 anchor, the binding port attributes take default values unless 405 overridden by configuration. By default, a SAVI switch does not 406 filter DHCP messages, nor does it attempt to validate source 407 addresses, which is to say that the binding attributes are ignored 408 until SAVI-DHCP is itself enabled. This is because a SAVI switch 409 that depends on DHCP cannot tell, a priori, which ports have valid 410 DHCP servers attached, or which have routers or other equipment that 411 would validly appear to use an arbitrary set of source addresses. 412 When SAVI has been enabled, the attributes take effect. 414 4.2.1. Trust Attribute 416 The "Trust Attribute" is a Boolean value. If TRUE, it indicates that 417 the packets from the corresponding attached device need not have 418 their source addresses validated. Examples of a trusted binding 419 anchor would be a port to another SAVI device, or to an IP router, as 420 shown in Figure 1. In both cases, traffic using many source IP 421 addresses will be seen. By default, the Trust attribute is FALSE, 422 indicating that any device found on that port will seek an address 423 using DHCP and be limited to using such addresses. 425 SAVI devices will not set up bindings for points of attachment with 426 the Trust attribute set TRUE; DHCP messages and data packets from 427 attached devices with this attribute will not be checked. If the 428 DHCP Server-to-Client messages from attached devices with this 429 attribute can trigger the state transitions specified in Section 6 430 and Section 7, the corresponding processes in Section 6 and Section 7 431 will handle these messages. 433 4.2.2. DHCP-Trust Attribute 435 The "DHCP-Trust Attribute" is similarly a Boolean attribute. It 436 indicates whether the attached device is permitted to initiate DHCP 437 Server-to-Client messages. In Figure 1, the points of attachment of 438 the DHCP Server and the DHCP Relay would have this attribute set 439 TRUE, and ports that are trusted would have it set TRUE. 441 If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP 442 Server-to-Client messages from the points of attachment with this 443 attribute. If the DHCP Server-to-Client messages can trigger the 444 state transitions, the binding setup processes specified in Section 6 445 and Section 7 will handle them. By default, the DHCP-Trust attribute 446 is FALSE, indicating that the attached system is not a DHCP server. 448 A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for 449 more details. 451 4.2.3. DHCP-Snooping Attribute 453 The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It 454 indicates whether bindings will be set up based on DHCP snooping. 456 If this attribute is TRUE, DHCP Client-Server messages to points of 457 attachment with this attribute will trigger creation of bindings 458 based on the DHCP snooping procedure described in Section 6. If it 459 is FALSE, either the Trust attribute must be TRUE (so that bindings 460 become irrelevant) or another SAVI mechanism such as SAVI-FCFS must 461 be used on the point of attachment. 463 The DHCP-Snooping attribute is configured on the DHCP Client's point 464 of attachment. This attribute can be also used on the attachments to 465 protected Non-SAVI devices that are used by DHCP clients. In 466 Figure 1, the attachment from the Client A to the SAVI Device A, the 467 attachment from the Client B to the SAVI Device B, and the attachment 468 from the Non-SAVI Device 2 to the SAVI Device A can be configured 469 with this attribute. 471 Whenever this attribute is set TRUE on a point of attachment, the 472 "Validating Attribute" MUST also be set TRUE. 474 4.2.4. Data-Snooping Attribute 476 The "Data-Snooping Attribute" is a Boolean attribute. It indicates 477 whether data packets from the corresponding point of attachment may 478 trigger the binding setup procedure. 480 Data packets from points of attachment with this attribute may 481 trigger the setup of bindings. SAVI devices will set up bindings on 482 points of attachment with this attribute based on the data-triggered 483 process described in Section 7. 485 If the DHCP-Snooping attribute is configured on a point of 486 attachment, the bindings on this attachment are set up based on DHCP 487 message snooping. However, in some scenarios, a DHCP client may use 488 a DHCP address without the DHCP address assignment procedure being 489 performed on its current attachment. For such attached devices, the 490 Data-Snooping process, which is described in Section 7, is necessary. 491 This attribute is configured on such attachments. The usage of this 492 attribute is further discussed in Section 7. 494 Whenever this attribute is set on an attachment, the "Validating 495 Attribute" MUST be set on the same attachment. Since some networks 496 require DHCP deployment and others avoid it, there is no obvious 497 universal default value for the Data-Snooping Attribute. However, 498 note that deployment of SLAAC (and therefore SAVI-FCFS) is generally 499 configuration-free, while the deployment of DHCP involves at minimum 500 the deployment of a server. Hence, the Data-Snooping Attribute 501 should default to FALSE, and a mechanism should be implemented to 502 conveniently set it to TRUE on all points of attachment for which the 503 Trust attribute is FALSE. 505 4.2.5. Validating Attribute 507 The "Validating Attribute" is a Boolean attribute. It indicates 508 whether packets from the corresponding attachment will have their IP 509 source addresses validated based on binding entries on the 510 attachment. 512 If it is TRUE, packets coming from attachments with this attribute 513 will be checked based on binding entries on the attachment as 514 specified in Section 8. If it is FALSE, they will not. Since the 515 binding table is used in common with other SAVI algorithms, it merely 516 signifies whether the check will be done, not whether it will be done 517 for SAVI-DHCP originated bindings. 519 This attribute is by default the inverse of the Trust attribute; 520 source addresses on untrusted links are validated by default. It MAY 521 be set FALSE by the administration. 523 The expected use case is when SAVI is used to monitor but not block 524 unvalidated transmissions. The network manager, in that case, may 525 set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the 526 VALIDATING attribute FALSE. 528 4.2.6. Table of Mutual Exclusions 530 Different types of attributes may indicate mutually exclusive actions 531 on a packet. Mutually exclusive attributes MUST NOT be set TRUE on 532 the same attachment. The compatibility of different attributes is 533 listed in Figure 2. Note that although Trust and DHCP-Trust are 534 compatible, there is no need to configure DHCP-Trust to TRUE on an 535 attachment with Trust attribute TRUE. 537 +----------+----------+----------+----------+----------+----------+ 538 | | | | DHCP- | Data- | | 539 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 540 +----------+----------+----------+----------+----------+----------+ 541 | | | | mutually | mutually | mutually | 542 | Trust | - |compatible| exclusive| exclusive| exclusive| 543 +----------+----------+----------+----------+----------+----------+ 544 | | | | | | | 545 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 546 +----------+----------+----------+----------+----------+----------+ 547 |DHCP- |mutually | | | | | 548 |Snooping |exclusive |compatible| - |compatible|compatible| 549 +----------+----------+----------+----------+----------+----------+ 550 |Data- |mutually | | | | | 551 |Snooping |exclusive |compatible|compatible| - |compatible| 552 +----------+----------+----------+----------+----------+----------+ 553 | |mutually | | | | | 554 |Validating|exclusive |compatible|compatible|compatible| - | 555 +----------+----------+----------+----------+----------+----------+ 557 Figure 2: Table of Mutual Exclusions 559 4.3. Perimeter 561 4.3.1. SAVI-DHCP Perimeter Overview 563 SAVI devices form a perimeter separating trusted and untrusted 564 regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]). 565 The perimeter is primarily designed for scalability. It has two 566 implications. 568 o SAVI devices only need to establish bindings for directly attached 569 clients, or clients indirectly attached through a non-SAVI 570 protected device, rather than all of the clients in the network. 572 o Each SAVI device only need to validate traffic from clients 573 attached to it, without checking all the traffic passing by. 575 Consider the example in Figure 1. The protection perimeter is formed 576 by SAVI Devices A, B and C. In this case, SAVI device B does not 577 create a binding for client A. However, because SAVI device A filters 578 spoofed traffic from client A, SAVI device B can avoid receiving 579 spoofed traffic from client A. 581 The perimeter in SAVI-DHCP is not only a perimeter for data packets, 582 but also a perimeter for DHCP messages. The placement of the DHCP 583 Relay and DHCP Server, which are not involved in [RFC6620], is 584 related to the construction of the perimeter. The requirement on the 585 placement and configuration of DHCP Relay and DHCP Server are 586 discussed in Section 4.3.3. 588 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 590 A perimeter separating trusted and untrusted regions of the network 591 is formed as follows: 593 (1) Configure the Validating and DHCP-Snooping attributes TRUE on 594 the direct attachments of all DHCP clients. 596 (2) Configure the Validating and DHCP-Snooping attributes TRUE on 597 the indirect attachments of all DHCP clients (i.e., DHCP clients 598 on protected links). 600 (3) Configure the Trust attribute TRUE on the attachments to other 601 SAVI devices. 603 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 604 are attached only to SAVI devices, set the Trust attribute TRUE 605 on their attachments. 607 (5) Configure the DHCP-Trust attribute TRUE on the direct 608 attachments to trusted DHCP relays and servers. 610 In this way, the points of attachments with the Validating attribute 611 TRUE (and generally together with attachments of unprotected devices) 612 on SAVI devices can form a perimeter separating DHCP clients and 613 trusted devices. Data packet checks are only performed on the 614 perimeter. The perimeter is also a perimeter for DHCP messages. The 615 DHCP-Trust attribute is only TRUE on the inside links of the 616 perimeter. Only DHCP server-to-client messages originated within the 617 perimeter are trusted. 619 4.3.3. On the Placement of the DHCP Server and Relay 621 As a result of the configuration guideline, SAVI devices only trust 622 DHCP Server-to-Client messages originated inside the perimeter. 623 Thus, the trusted DHCP Relays and DHCP Servers must be placed within 624 the perimeter. DHCP server-to-client messages will be filtered on 625 the perimeter. Server-to-relay messages will not be filtered, as 626 they are within the perimeter. In this way, DHCP server-to-client 627 messages from bogus DHCP servers are filtered on the perimeter, 628 having entered through untrusted points of attachment. The SAVI 629 devices are protected from forged DHCP messages. 631 DHCP server-to-client messages arriving at the perimeter from outside 632 the perimeter are not trusted. There is no distinction between a 633 DHCP server owned and operated by the correct administration but 634 outside the SAVI perimeter and a bogus DHCP server. For example, in 635 Figure 1, DHCP server A is valid, but it is attached to Non-SAVI 636 device 1. A bogus DHCP server is also attached Non-SAVI device 1. 637 While one could imagine a scenario in which the valid one had a 638 statistically configured port number and MAC address, and therefore a 639 binding, by default SAVI-DHCP cannot distinguish whether a message 640 received from the port of Non-SAVI device 1 is from DHCP server A or 641 the bogus DHCP server. If the DHCP server A is contained in the 642 perimeter, Non-SAVI device 1 will also be contained in the perimeter. 643 Thus, the DHCP server A cannot be contained within the perimeter 644 apart from manual configuration of the binding anchor. 646 Another consideration on the placement is that if the DHCP server/ 647 relay is not inside the perimeter, the SAVI devices may not be able 648 to set up bindings correctly, because the SAVI devices may not be on 649 the path between the clients and the server/relay, or the DHCP 650 messages are encapsulated (e.g., Relay-reply and Relay-forward). 652 4.3.4. An Alternative Deployment 654 In common deployment practice, the traffic from the unprotected 655 network is treated as trustworthy, which is to say that it is not 656 filtered. In such a case, the Trust attribute can be set TRUE on the 657 unprotected link. If Non-SAVI devices, or a number of connected Non- 658 SAVI devices, are only attached to SAVI devices and unprotected 659 devices, their attachment to SAVI devices can have the Trust 660 attribute set TRUE. Then an unclosed perimeter will be formed, as 661 illustrated in Figure 3. 663 To configure such a perimeter, at minimum the DHCP messages from 664 unprotected networks MUST be ensured to be trustworthy. Achieving 665 this is beyond the scope of this document. 667 | . . Protection | 668 | | | Perimeter | 669 | | | | 670 | Unprotected | | Unprotected | 671 | Link | | Link | 672 | | | | 673 | | | | 674 | +--------+ +--------+ +--------+ | 675 | |SAVI |----|Non-SAVI|----|SAVI | | 676 | |Device | |Device | |Device | | 677 | +--------+ +--------+ +--------+ | 678 | | | | 679 \__________________________________________________/ 680 | | 681 | | 682 +--------+ +--------+ 683 |DHCP | |DHCP | 684 |Client | |Client | 685 +--------+ +--------+ 687 Figure 3: Alternative Perimeter Configuration 689 4.3.5. Considerations regarding Binding Anchors 691 The strength of this binding-based mechanism depends on the strength 692 of the binding anchor. The sample binding anchors in [RFC7039] have 693 the property that they associate an IP address with a direct physical 694 or secure virtual interface such as a switch port, a subscriber 695 association, or a security association. In addition, especially in 696 the case that a protected non-SAVI device such as a desktop switch or 697 a hub is between the client device and the SAVI switch, they MAY be 698 extended to also include a MAC address or other link-layer attribute. 699 In short, a binding anchor is intended to associate an IP address 700 with something unspoofable that identifies a single client system or 701 one of its interfaces; this may be a physical or virtual interface or 702 that plus disambiguating link-layer information. 704 If the binding anchor is spoofable, such as a plain MAC address, or 705 non-exclusive, such as a switch port extended using a non-SAVI 706 device, an attacker can use a forged binding anchor to evade 707 validation. Indeed, using a binding anchor that can be easily 708 spoofed can lead to worse outcomes than allowing IP spoofing traffic. 709 Thus, a SAVI device MUST use a non-spoofable and exclusive binding 710 anchor. 712 4.4. Other Device Configuration 714 In addition to a possible binding anchor configuration specified in 715 Section 4.2, an implementation has the following configuration 716 requirements: 718 (1) Address configuration. For DHCPv4: the client of a SAVI device 719 MUST have an IPv4 address. For DHCPv6: the client of a SAVI 720 device MUST have a link-local address; when the DHCPv6 server is 721 not on the same link as the SAVI device, the SAVI device MUST 722 also have a global IPv6 address. 724 (2) DHCP server address configuration: a SAVI device MUST store the 725 list of the DHCP server addresses that it could contact during a 726 Lease query process. 728 5. Binding State Table (BST) 730 The Binding State Table, which may be implemented centrally in the 731 switch or distributed among its ports, is used to contain the 732 bindings between the IP addresses assigned to the attachments and the 733 corresponding binding anchors of the attachments. Note that in this 734 description, there is a binding entry for each IPv4 or IPv6 address 735 associated with each binding anchor, and there may be several of each 736 such address, especially if the port is extended using a protected 737 non-SAVI device. Each binding entry, has 5 fields: 739 o Binding Anchor(Anchor): the binding anchor, i.e., a physical and/ 740 or link-layer property of the attachment. 742 o IP Address(Address): the IPv4 or IPv6 address assigned to the 743 attachment by DHCP. 745 o State: the state of the binding. Possible values of this field 746 are listed in Section 6.2 and Section 7.3. 748 o Lifetime: the remaining seconds of the binding. Internally, this 749 MAY be stored as the timestamp value at which the lifetime 750 expires. 752 o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the 753 corresponding DHCP transaction. TID field is used to associate 754 DHCP Server-to-Client messages with corresponding binding entries. 756 The IA is not present in the BST for three reasons: 758 o The lease of each address in one IA is assigned separately. 760 o When the binding is set up based on data-snooping, the IA cannot 761 be recovered from the lease query protocol. 763 o DHCPv4 does not define an IA. 765 An instance of this table is shown in Figure 4. 767 +---------+----------+----------+-----------+-------+ 768 | Anchor | Address | State | Lifetime |TID | 769 +---------+----------+----------+-----------+-------+ 770 | Port_1 | IP_1 | BOUND | 65535 |TID_1 | 771 +---------+----------+----------+-----------+-------+ 772 | Port_1 | IP_2 | BOUND | 10000 |TID_2 | 773 +---------+----------+----------+-----------+-------+ 774 | Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | 775 +---------+----------+----------+-----------+-------+ 777 Figure 4: Instance of BST 779 6. DHCP Snooping Process 781 This section specifies the process of setting up bindings based on 782 DHCP snooping. This process is illustrated using a state machine. 784 6.1. Rationale 786 The rationale of the DHCP Snooping Process is that if a DHCP client 787 is legitimately using a DHCP-assigned address, the DHCP address 788 assignment procedure that assigns the IP address to the client must 789 have been performed on the client's point of attachment. This basis 790 works when the SAVI device is always on the path(s) from the DHCP 791 client to the DHCP server(s)/relay(s). Without considering the 792 movement of DHCP clients, the SAVI device should be the cut vertex 793 whose removal will separate the DHCP client and the remaining network 794 containing the DHCP server(s)/ and relay(s). For most of the 795 networks whose topologies are simple, it is possible to deploy this 796 SAVI function at proper devices to meet this requirement. 798 However, if there are multiple paths from a DHCP client to the DHCP 799 server and the SAVI device is only on one of them, there is an 800 obvious failure case: the SAVI device may not be able to snoop the 801 DHCP procedure. Host movement may also make this requirement 802 difficult to meet. For example, when a DHCP client moves from one 803 attachment to another attachment in the same network, it may fail to 804 reinitialize its interface or send a Confirm message because of 805 incomplete protocol implementation. Thus, there can be scenarios in 806 which only performing this DHCP snooping process is insufficient to 807 set up bindings for all the valid DHCP addresses. These exceptions 808 and the solutions are discussed in Section 7. 810 6.2. Binding States Description 812 Following binding states are present in this process and the 813 corresponding state machine: 815 NO_BIND: No binding has been set up. 817 INIT_BIND: A potential binding has been set up. 819 BOUND: The binding has been set up. 821 6.3. Events 823 This section describes events in this process and the corresponding 824 state machine. 826 6.3.1. Timer Expiration Event 828 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 830 6.3.2. Control Message Arriving Events 832 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 833 received. 835 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 837 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 839 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 840 received. 842 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 844 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 845 option is received. 847 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 849 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 850 received. 852 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 853 received. 855 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 856 section 4.3.3 of [RFC5007]) is received. 858 Note: the events listed here do not cover all the DHCP messages in 859 section 3. The messages which do not really determine address usage 860 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 861 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 862 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 863 to section 6.4.2.1), are not included. 865 Moreover, only if a DHCP message can pass the following checks, the 866 corresponding event is regarded as a valid event: 868 o Attribute check: the DHCP Server-to-Client messages and 869 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 870 attribute; the DHCP Client-Server messages should be from 871 attachments with DHCP-Snooping attribute. 873 o Destination check: the DHCP Server-to-Client messages should be 874 destined to attachments with DHCP-Snooping attribute. This check 875 is performed to ensure the binding is set up on the SAVI device 876 which is nearest to the destination client. 878 o Binding anchor check: the DHCP Client-Server messages which may 879 trigger modification or removal of an existing binding entry must 880 have a matching binding anchor with the corresponding entry. 882 o TID check: the DHCP Server-to-Client/Client-Server messages which 883 may cause modification on existing binding entries must have 884 matched TID with the corresponding entry. Note that this check is 885 not performed on Lease query and Lease query-reply messages as 886 they are exchanged between the SAVI devices and the DHCP servers. 887 Besides, this check is not performed on DHCP Renew/Rebind 888 messages. 890 o Binding limitation check: the DHCP messages must not cause new 891 binding setup on an attachment whose binding entry limitation has 892 been reached. (refer to Section 11.5). 894 o Address check: the source address of the DHCP messages should pass 895 the check specified in Section 8.2. 897 On receiving a DHCP message without triggering a valid event, the 898 state will not change, and the actions will not be performed. Note 899 that if a message does not trigger a valid event but it can pass the 900 checks in Section 8.2, it MUST be forwarded. 902 6.4. The State Machine of DHCP Snooping Process 904 This section specifies state transitions and their corresponding 905 actions. 907 6.4.1. Initial State: NO_BIND - No binding has been set up 909 6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request 910 message is received 912 The SAVI device MUST forward the message. 914 The SAVI device will generate an entry in the BST. The Binding 915 anchor field is set to the binding anchor of the attachment from 916 which the message is received. The State field is set to INIT_BIND. 917 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 918 field is set to the TID of the message. If the message is DHCPv4 919 Request or DHCPv4 Reboot, the Address field can be set to the address 920 to request, i.e., the 'requested IP address'. An example of the 921 entry is illustrated in Figure 5. 923 +---------+-------+---------+-----------------------+-------+ 924 | Anchor |Address| State | Lifetime |TID | 925 +---------+-------+---------+-----------------------+-------+ 926 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 927 +---------+-------+---------+-----------------------+-------+ 929 Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot 930 triggered initialization 932 Resulting state: INIT_BIND - A potential binding has been set up 934 6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received 936 The SAVI device MUST forward the message. 938 The SAVI device will generate an entry in the BST. The Binding 939 anchor field is set to the binding anchor of the attachment from 940 which the message is received. The State field is set to INIT_BIND. 941 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 942 field is set to the TID of the message. If the message is DHCPv4 943 Request or DHCPv4 Reboot, the Address field can be set to the address 944 to request, i.e., the 'requested IP address'. An example of the 945 entry is illustrated in Figure 5. 947 Resulting state: INIT_BIND - A potential binding has been set up 949 6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message 950 with Rapid Commit option is received 952 The SAVI device MUST forward the message. 954 The SAVI device will generate an entry in the BST. The Binding 955 anchor field is set to the binding anchor of the attachment from 956 which the message is received. The State field is set to INIT_BIND. 957 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 958 field is set to the TID of the message. If the message is DHCPv4 959 Request or DHCPv4 Reboot, the Address field can be set to the address 960 to request, i.e., the 'requested IP address'. An example of the 961 entry is illustrated in Figure 5. 963 Resulting state: INIT_BIND - A potential binding has been set up 965 6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received 967 The SAVI device MUST forward the message. 969 The SAVI device will generate corresponding entries in the BST for 970 each address in each Identity Association (IA) option of the Confirm 971 message. The Binding anchor field is set to the binding anchor of 972 the attachment from which the message is received. The State field 973 is set to INIT_BIND. The Lifetime field is set to be 974 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 975 message. The Address field is set to the address(es) to confirm. An 976 example of the entries is illustrated in Figure 6. 978 +---------+--------+---------+-----------------------+-------+ 979 | Anchor | Address| State | Lifetime |TID | 980 +---------+--------+---------+-----------------------+-------+ 981 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 982 +---------+--------+---------+-----------------------+-------+ 983 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 984 +---------+--------+---------+-----------------------+-------+ 986 Figure 6: Binding entry in BST on Confirm triggered initialization 988 Resulting state: INIT_BIND - A potential binding has been set up 990 6.4.1.5. Events that cannot happen in the NO_BIND state 992 o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires 994 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 995 received 997 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 998 received 1000 o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received 1002 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1003 received 1005 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1006 received 1008 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is 1009 received 1011 These cannot happen because they are each something that happens 1012 AFTER a binding has been created. 1014 6.4.2. Initial State: INIT_BIND - A potential binding has been set up 1016 6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1017 is received 1019 The message MUST be forwarded to the corresponding client. 1021 If the message is DHCPv4 ACK, the Address field of the corresponding 1022 entry (i.e., the binding entry whose TID is the same of the message) 1023 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 1024 The Lifetime field is set to the sum of the lease time in ACK message 1025 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1027 If the message is DHCPv6 Reply, there are following cases: 1029 1. If the status code is not "Success", no modification on 1030 corresponding entries will be made. Corresponding entries will 1031 expire automatically if no "Success" Reply is received during the 1032 lifetime. The entries are not removed immediately due to the 1033 client may be able to use the addresses whenever a "Success" 1034 Reply is received ("If the client receives any Reply messages 1035 that do not indicate a NotOnLink status, the client can use the 1036 addresses in the IA and ignore any messages that indicate a 1037 NotOnLink status." [RFC3315]). 1039 2. If the status code is "Success", the SAVI device checks the IA 1040 options in the Reply message. 1042 A. If there are IA options in the Reply message, the SAVI device 1043 checks each IA option. When the first assigned address is 1044 found, the Address field of the binding entry with matched 1045 TID is set to the address. The Lifetime field is set to the 1046 sum of the lease time in Reply message and 1047 MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1048 If there are more than one address assigned in the message, 1049 new binding entries are set up for the remaining address 1050 assigned in the IA options. An example of the entries is 1051 illustrated in Figure 8. SAVI devices do not specially 1052 process IA options with NoAddrsAvail status, because there 1053 should be no address contained in such IA options. 1055 B. Otherwise, the DHCP Reply message is in response to a Confirm 1056 message. The state of the binding entries with matched TID 1057 is changed to BOUND. Because [RFC3315] does not require 1058 lease time of addresses to be contained in the Reply message, 1059 the SAVI device SHOULD send a LEASEQUERY [RFC5007] message 1060 querying by IP address to All_DHCP_Servers multicast address 1061 [RFC3315] or a list of configured DHCP server addresses. The 1062 Lease query message is generated for each IP address if 1063 multiple addresses are confirmed. The Lifetime of 1064 corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If 1065 there is no response message after MAX_LEASEQUERY_DELAY, send 1066 the LEASEQUERY message again. An example of the entries is 1067 illustrated in Figure 7. If the SAVI device does not send 1068 the LEASEQUERY message, a pre-configured lifetime 1069 DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 1070 (Note: it is RECOMMENDED to use T1 configured on DHCP servers 1071 as the DHCP_DEFAULT_LEASE.) 1073 Note: the SAVI devices do not check if the assigned addresses are 1074 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 1075 only source of valid addresses. However, the DHCP servers should be 1076 configured to make sure no duplicated addresses are assigned. 1078 +---------+----------+-------+------------------------+-------+ 1079 | Anchor | Address | State | Lifetime |TID | 1080 +---------+----------+-------+------------------------+-------+ 1081 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1082 +---------+----------+-------+------------------------+-------+ 1083 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1084 +---------+----------+-------+------------------------+-------+ 1086 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1087 Confirm 1089 +---------+----------+-------+------------------------+-------+ 1090 | Anchor | Address | State | Lifetime |TID | 1091 +---------+----------+-------+------------------------+-------+ 1092 | Port_1 | Addr1 | BOUND |Lease time+ |TID | 1093 | | | |MAX_DHCP_RESPONSE_TIME | | 1094 +---------+----------+-------+------------------------+-------+ 1095 | Port_1 | Addr2 | BOUND |Lease time+ |TID | 1096 | | | |MAX_DHCP_RESPONSE_TIME | | 1097 +---------+----------+-------+------------------------+-------+ 1099 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 1100 Request 1102 Resulting state: BOUND - The binding has been set up 1104 6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1105 expires 1107 The entry MUST be deleted from BST. 1109 Resulting state: An entry that has been deleted from the BST may be 1110 considered to be in the state "NO_BIND" - No binding has been set up. 1112 6.4.2.3. Events that are ignored in INIT_BIND 1114 If no DHCP Server-to-Client messages which assign addresses or 1115 confirm addresses are received, corresponding entries will expire 1116 automatically. Thus, other DHCP Server-to-Client messages (e.g., 1117 DHCPv4 NAK) are not specially processed. 1119 As a result, the following events, should they occur, are ignored 1120 until either a DHCPv4 ACK or a DHCPv6 Reply message is received or 1121 the lifetime of the binding entry expires. 1123 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1124 received 1126 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1128 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1130 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1131 received 1133 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 1134 received 1136 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1137 Commit option is received 1139 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1140 received 1142 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1143 received 1145 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is 1146 received 1148 In each case, the message MUST be forwarded. 1150 Resulting state: INIT_BIND - A potential binding has been set up 1152 6.4.3. Initial State: BOUND - The binding has been set up 1154 6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1155 expires 1157 The entry MUST be deleted from BST. 1159 Resulting state: An entry that has been deleted from the BST may be 1160 considered to be in the state "NO_BIND" - No binding has been set up. 1162 6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline 1163 message is received 1165 The message MUST be forwarded. 1167 The SAVI device first gets all the addresses ("Requested IP address" 1168 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1169 IA options of DHCPv6 Decline/Release) to decline/release in the 1170 message. Then the corresponding entries MUST be removed. 1172 Resulting state in each relevant BST entry: An entry that has been 1173 deleted from the BST may be considered to be in the state "NO_BIND" - 1174 No binding has been set up. 1176 6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release 1177 message is received 1179 The message MUST be forwarded. 1181 The SAVI device first gets all the addresses ("Requested IP address" 1182 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1183 IA options of DHCPv6 Decline/Release) to decline/release in the 1184 message. Then the corresponding entries MUST be removed. 1186 Resulting state in each relevant BST entry: An entry that has been 1187 deleted from the BST may be considered to be in the state "NO_BIND" - 1188 No binding has been set up. 1190 6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind 1191 message is received 1193 The message MUST be forwarded. 1195 In such case, a new TID will be used by the client. The TID field of 1196 the corresponding entries MUST be set to the new TID. Note that TID 1197 check will not be performed on such messages. 1199 Resulting state: BOUND: The binding has been set up 1201 6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew 1202 message is received 1204 The message MUST be forwarded. 1206 In such case, a new TID will be used by the client. The TID field of 1207 the corresponding entries MUST be set to the new TID. Note that TID 1208 check will not be performed on such messages. 1210 Resulting state: BOUND: The binding has been set up 1212 6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1213 is received 1215 The message MUST be forwarded. 1217 The DHCP Reply messages received in current states should be in 1218 response to DHCP Renew/Rebind. 1220 If the message is DHCPv4 ACK, the SAVI device updates the binding 1221 entry with matched TID, with the Lifetime field set to be the sum of 1222 the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in 1223 the state BOUND. 1225 If the message is DHCPv6 Reply, the SAVI device checks each IA 1226 Address option in each IA option. For each: 1228 1. If the IA entry in the REPLY message has the status "NoBinding", 1229 there is no address in the option, and no operation on an address 1230 is performed. 1232 2. If the valid lifetime of an IA address option is 0, the binding 1233 entry with matched TID and address is removed, leaving it 1234 effectively in the state NO_BIND. 1236 3. Otherwise, set the Lifetime field of the binding entry with 1237 matched TID and address to be the sum of the new valid lifetime 1238 and MAX_DHCP_RESPONSE_TIME, leaving the entry in the state BOUND. 1240 Resulting state: NO_BIND or BOUND, as specified. 1242 6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 1243 LEASEQUERY_REPLY is received 1245 The message MUST be forwarded. 1247 The message should be in response to the Lease query message sent in 1248 Section 6.4.2. The related binding entry can be determined based on 1249 the address in the IA Address option in the Lease query-reply 1250 message. The Lifetime field of the corresponding binding entry is 1251 set to the sum of the lease time in the LEASEQUERY_REPLY message and 1252 MAX_DHCP_RESPONSE_TIME. 1254 Resulting state: BOUND: The binding has been set up 1256 6.4.3.8. Events not processed in the state BOUND 1258 The following events are ignored if received while the indicated 1259 entry is in the state BOUND. Any required action will be the result 1260 of the next message in the client/server exchange. 1262 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1263 received 1265 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1267 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1269 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1270 Commit option is received 1272 6.4.4. Table of State Machine 1274 The main state transits are listed as follows. Note that not all the 1275 details are specified in the table and the diagram. 1277 State Event Action Next State 1278 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1279 INIT_BIND RPL Record lease time BOUND 1280 (send lease query if no lease) 1281 INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1282 BOUND RLS/DCL Remove entry NO_BIND 1283 BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1284 BOUND RPL Set new lifetime BOUND 1285 BOUND LQR Record lease time BOUND 1287 Figure 9: Table of Transit 1289 RQ: EVE_DHCP_REQUEST 1291 CF: EVE_DHCP_CONFIRM 1293 RC: EVE_DHCP_SOLICIT_RC 1295 RE: EVE_DHCP_REBOOT 1297 RPL: EVE_DHCP_REPLY 1299 DCL: EVE_DHCP_DECLINE 1301 RLS: EVE_DHCP_RELEASE 1303 LQR: EVE_DHCP_LEASEQUERY 1304 +-------------+ 1305 | | 1306 /---------| NO_BIND |<----------\ 1307 | ------>| | | 1308 | | +-------------+ |EVE_DHCP_RELEASE 1309 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1310 EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE 1311 EVE_DHCP_SOLICIT_RC| | | 1312 EVE_DHCP_REBOOT | | | 1313 | | | 1314 | | | 1315 v | | 1316 +-------------+ +------------+ 1317 | | EVE_DHCP_REPLY | | 1318 | INIT_BIND ------------------------>| BOUND |<-\ 1319 | | | | | 1320 +-------------+ +------------+ | 1321 | | 1322 \--------/ 1323 EVE_DHCP_REPLY 1324 EVE_DHCP_LEASEQUERY 1326 Figure 10: Diagram of Transit 1328 7. Data Snooping Process 1330 7.1. Scenario 1332 The rationale of the DHCP Snooping Process specified in Section 6 is 1333 that if a DHCP client's use of a DHCP address is legitimate, the 1334 corresponding DHCP address assignment procedure must have been 1335 finished on the attachment of the DHCP client. This is the case 1336 stands when the SAVI device is persistently on the path(s) from the 1337 DHCP client to the DHCP server(s)/relay(s). However, there are two 1338 case when this does not work: 1340 o Multiple paths: there is more than one feasible link-layer paths 1341 from the client to the DHCP server/relay, and the SAVI device is 1342 not on everyone of them. The client may get its address through 1343 one of the paths not passing by the SAVI device, but packets from 1344 the client can travel through paths that pass through the SAVI 1345 device. Because the SAVI device could not snoop the DHCP packet 1346 exchange procedure, the DHCP snooping procedure cannot set up the 1347 corresponding binding. 1349 o Dynamic path: there is only one feasible link-layer path from the 1350 client to the DHCP server/relay, but the path is dynamic due to 1351 topology change (for example, some link turns broken due to 1352 failure or as planned) or link-layer path change. This situation 1353 also covers the local-link movement of clients without address 1354 confirm/re-configuration process. For example, a host changes its 1355 attached switch port in a very short time. In such cases, the 1356 DHCP snooping process will not set up the corresponding binding. 1358 Data Snooping Process prevents permanently blocking legitimate 1359 traffic in case of these two exceptions. This process is performed 1360 on attachments with the Data-Snooping attribute. Data packets 1361 without matching binding entry may trigger this process to set up 1362 bindings. 1364 Snooping data traffic introduces considerable burden on the processor 1365 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1366 overhead of this process, the implementation of this process is a 1367 conditional SHOULD. This function SHOULD be enabled unless the 1368 implementation is known to be used in the scenarios without the above 1369 exceptions. For example, if the implementation is to be used in 1370 networks with tree topology and without host local-link movement, 1371 there is no need to implement this process in such scenarios. 1373 This process is not intended to set up a binding whenever a data 1374 packet without matched binding entry is received. Instead, unmatched 1375 data packets trigger this process probabilistically and generally a 1376 number of unmatched packets will be discarded before the binding is 1377 set up. 1379 7.2. Rationale 1381 This process makes use of NS/ARP and DHCP LEASEQUERY to set up 1382 bindings. If an address is not used by another client in the 1383 network, and the address has been assigned in the network, the 1384 address can be bound with the binding anchor of the attachment from 1385 which the unmatched packet is received. 1387 The security issues about this process is discussed is Section 11.1. 1389 7.3. Additional Binding States Description 1391 In addition to NO_BIND and BOUND from Section 6.2, two new states 1392 used in this process are listed here. The INIT_BIND state is not 1393 used, as it is entered by observing a DHCP message. 1395 DETECTION: The address in the entry is under local duplication 1396 detection. 1398 RECOVERY: The SAVI device is querying the assignment and lease time 1399 of the address in the entry through DHCP Lease query. 1401 7.4. Events 1403 In addition to EVE_DATA_LEASEQUERY and EVE_DHCP_REBIND, these 1404 additional events are described here. If an event will trigger the 1405 creation of a new binding entry, the binding entry limit on the 1406 binding anchor MUST NOT be exceeded. 1408 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1410 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1411 against an address in DETECTION state is received from a host other 1412 than the one for which the entry was added. 1414 EVE_DATA_LEASEQUERY: 1416 o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1417 is received. 1419 o IPv6: A successful LEASEQUERY-REPLY is received. 1421 The triggering packet should pass the following checks to trigger a 1422 valid event: 1424 o Attribute check: the data packet should be from attachments with 1425 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1426 messages should be from attachments with DHCP-Snooping attribute. 1428 o Binding limitation check: the DHCP messages must not cause new 1429 binding setup on an attachment whose binding entry limitation has 1430 been reached. (refer to Section 11.5). 1432 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1433 DHCP Lease query messages must pass the check specified in 1434 Section 8.2. For EVE_DATA_CONFLICT, the source address and target 1435 address of the ARP or NA messages must pass the check specified in 1436 Section 8.2. 1438 o Interval check: the interval between two successive 1439 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1440 smaller than DATA_SNOOPING_INTERVAL. 1442 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have 1443 matched TID with the corresponding entry. 1445 o Prefix check: the source address of the data packet should be of a 1446 valid local prefix, as specified in section 7 of [RFC7039]. 1448 EVE_ENTRY_EXPIRE: A timer expires. 1450 7.5. Initial State: state NO_BIND - No binding has been set up 1452 7.5.1. Event: EVE_DATA_UNMATCH: A data packet without matched binding 1453 is received 1455 Make a probabilistic determination whether to act on this event. The 1456 probability may be configured or calculated based on the state of the 1457 SAVI device. This probability should be low enough to mitigate the 1458 damage from DoS attack against this process. 1460 Create a new entry in the BST. Set the Binding Anchor field to the 1461 corresponding binding anchor of the attachment. Set the Address 1462 field to the source address of the packet. Set the State field to 1463 DETECTION. Set the Lifetime of the created entry to 1464 2*DETECTION_TIMEOUT. 1466 Check if the address has a local conflict (it violates an address 1467 being used by another node): 1469 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1470 [RFC0826] or an ARP probe [RFC5227] on the address; if there is 1471 no response message after DETECTION_TIMEOUT, send another ARP 1472 Request or ARP probe; 1474 (2) IPv6 address: send a Duplicate Address Detection message 1475 [RFC4861] targeting the address; ideally, only the host on that 1476 point of attachment responds with a Neighbor Advertisement; if 1477 more than one Neighbor Advertisement is observed, the BST entry 1478 should be removed. 1480 As Duplicate Address Detection is an unreliable process (either the 1481 packet to or from the other system may be lost in transit), if there 1482 is no response, it should be repeated, as described in [RFC6620]. 1484 The packet that triggers this event SHOULD be discarded. 1486 This local conflict process SHOULD be performed. If it is not 1487 performed, the state of the entry is set to RECOVERY, the lifetime is 1488 set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified 1489 in the following section will be performed directly. 1491 An example of the entry is illustrated in Figure 11. 1493 +---------+-------+---------+-----------------------+-------+ 1494 | Anchor |Address| State | Lifetime |TID | 1495 +---------+-------+---------+-----------------------+-------+ 1496 | Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | 1497 +---------+-------+---------+-----------------------+-------+ 1499 Figure 11: Binding entry in BST on data triggered initialization 1501 Resulting state: DETECTION - The address in the entry is under local 1502 duplication detection 1504 7.5.2. Events not observed in NO_BIND 1506 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1507 received from unexpected system 1509 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1511 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1512 received 1514 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1515 received 1517 EVE_ENTRY_EXPIRE 1519 7.6. Initial State: state DETECTION - The address in the entry is under 1520 local duplication detection 1522 7.6.1. Event: EVE_ENTRY_EXPIRE 1524 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1525 by IP address to each DHCPv4 server with IP Address Lease Time 1526 option (option 51). A list of authorized DHCP servers are kept 1527 by the SAVI device. The list should be pre-configured or 1528 discovered by sending DHCPv4 Discover messages and parsing the 1529 replied DHCPv4 Offer messages. Change the state of the 1530 corresponding entry to RECOVERY. Change the lifetime of the 1531 entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the 1532 TID used in the DHCPLEASEQUERY message. If there is no response 1533 message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to each 1534 DHCPv4 server again. 1536 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1537 address to All_DHCP_Relay_Agents_and_Servers multicast address or 1538 a list of pre-configured DHCPv6 server addresses. Change the 1539 state of the corresponding entry to RECOVERY. Change the 1540 lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID 1541 field is set to the TID used in the LEASEQUERY message. If there 1542 is no response message after MAX_LEASEQUERY_DELAY, send the 1543 LEASEQUERY message again. 1545 An example of the entry is illustrated in Figure 12. 1547 +---------+-------+---------+-----------------------+-------+ 1548 | Anchor |Address| State | Lifetime |TID | 1549 +---------+-------+---------+-----------------------+-------+ 1550 | Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | 1551 +---------+-------+---------+-----------------------+-------+ 1553 Figure 12: Binding entry in BST on Lease Query 1555 Resulting state: RECOVERY - The SAVI device is querying the 1556 assignment and lease time of the address in the entry through DHCP 1557 Leasequery 1559 7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) 1560 message received from unexpected system 1562 Remove the entry. 1564 Resulting state: NO_BIND - No binding has been set up 1566 7.6.3. Events not observed in DETECTION 1568 EVE_DATA_UNMATCH: A data packet without matched binding is received 1570 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1572 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1573 received 1575 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1576 received 1578 7.7. Initial State: state RECOVERY - The SAVI device is querying the 1579 assignment and lease time of the address in the entry through DHCP 1580 Leasequery 1582 7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 1583 LEASEQUERY-REPLY is received 1585 IPv4 address: 1587 (1) Send an ARP Request with the Target Protocol Address set to the 1588 IP address in the corresponding entry. The ARP Request is only 1589 sent to the attachment which triggers the binding. If there is 1590 no response after DETECTION_TIMEOUT, send another ARP Request. 1591 If there is still no response, remove the entry. 1593 (2) If there is only one identical response, get the sender hardware 1594 address. Check if the 'chaddr' field (hardware address) of the 1595 DHCPLEASEACTIVE message matches the sender hardware address. If 1596 the two addresses do not match, the following actions will not be 1597 performed. If there is more than one response, if any of the 1598 sender hardware addresses matches the 'chaddr' field (hardware 1599 address) of the DHCPLEASEACTIVE message, 1601 * Set life time to the sum of the value encoded in IP Address 1602 Lease Time option of the DHCPLEASEACTIVE message and 1603 MAX_DHCP_RESPONSE_TIME. 1605 * Erase the TID field. 1607 IPv6 address: 1609 (1) Send a Neighbor Solicitation message with the target address set 1610 to the IP address in the corresponding entry. The Neighbor 1611 Solicitation is only sent to the attachment which triggers the 1612 binding. If there is no response after DETECTION_TIMEOUT, send 1613 another Neighbor Solicitation. If there is still no response, 1614 remove the entry. 1616 (2) On receipt of a valid Neighbor Announcement, 1618 * Set the lifetime to the sum of the valid lifetime extracted 1619 from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY 1620 message and MAX_DHCP_RESPONSE_TIME. 1622 * Erase the TID field. 1624 * After the above checks, if multiple addresses are specified 1625 in the LEASEQUERY-REPLY message and there are no 1626 corresponding binding entries, new entries MUST also be 1627 created correspondingly on the same binding anchor. 1629 In the event that responses are received from multiple DHCP servers, 1630 the conflict resolution mechanisms specified in section 6.8 of 1631 [RFC4388] and section 4.3.4 of [RFC5007] will be used to determine 1632 which message should be used. 1634 Resulting state: if ARP or ND succeeds (there is a valid response), 1635 BOUND - The binding has been set up. Otherwise, the resulting state 1636 is NO_BIND - No binding has been set up 1638 7.7.2. Event: EVE_ENTRY_EXPIRE 1640 Remove the entry. 1642 Resulting state: NO_BIND - No binding has been set up 1644 7.7.3. Events not observed in RECOVERY 1646 EVE_DATA_UNMATCH: A data packet without matched binding is received 1648 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1649 received from unexpected system 1651 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1653 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1654 received 1656 7.8. Initial State: state BOUND - The binding has been set up 1658 Upon entry to the state BOUND, control the system continues as if a 1659 DHCP message assigning the address has been observed, as in 1660 Section 6.4.3. The BST entry has been restored. 1662 Note that the TID field contains no value after the binding state 1663 changes to BOUND. The TID field is recovered from snooping DHCP 1664 Renew/Rebind messages. Because TID is used to associate binding 1665 entries with messages from DHCP servers, it must be recovered; or 1666 else a number of state transits of this mechanism will be not 1667 executed normally. 1669 7.9. Table of State Machine 1671 The main state transits are listed as follows. 1673 State Event Action Next State 1674 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1675 DETECTION EVE_ENTRY_EXPIRE Send Leasequery RECOVERY 1676 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1677 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND 1678 RECOVERY EVE_ENTRY_EXPIRE Remove entry NO_BIND 1679 BOUND RENEW/REBIND Record TID BOUND 1681 Figure 13: Table of Transit 1683 RENEW: EVE_DHCP_RENEW 1685 REBIND: EVE_DHCP_REBIND 1687 +-------------+ 1688 | | 1689 /---------| NO_BIND |<--------\ 1690 | ------>| | | EVE_ENTRY_EXPIRE 1691 | | +-------------+ |(2nd LQ_DELAY) 1692 EVE_DATA_UNMATCH | | | 1693 | | | 1694 1st | | | 1695 DETECTION_TIMEOUT | | | 1st LQ_DELAY 1696 /------\ | | | /---------\ 1697 | | | | EVE_DATA_CONFLICT | | | 1698 | v v | | v | 1699 | +-------------+ EVE_ENTRY_EXPIRE +------------+ | 1700 | | |(2nd DETECTION_TIMEOUT) | | | 1701 \----| DETECTION ------------------------>| RECOVERY ----/ 1702 | | | | 1703 +-------------+ +------------+ 1704 EVE_DATA_LEASEQUERY| 1705 /----------\ (+ 2x DETECTION) | 1706 EVE_DHCP_RENEW| | | 1707 EVE_DHCP_REBIND| +-----v-------+ | 1708 | | | | 1709 \----| BOUND |<----------/ 1710 | | 1711 +-------------+ 1713 Figure 14: Diagram of Transit 1715 LQ_DELAY: MAX_LEASEQUERY_DELAY 1717 8. Filtering Specification 1719 This section specifies how to use bindings to filter out packets with 1720 spoofed source addresses. 1722 Filtering policies are different for data packets and control 1723 packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861] 1724 messages are classified as control packets. All other packets are 1725 classified as data packets. 1727 8.1. Data Packet Filtering 1729 Data packets from attachments with the Validating attribute TRUE MUST 1730 be checked. There is one exception to this rule. 1732 A packet whose source IP address is a link-local address cannot be 1733 checked against DHCP assignments, as it is not assigned using DHCP. 1734 Note: as explained in Section 1, a SAVI solution for link-local 1735 addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to check 1736 packets with a link-local source address. 1738 If the source IP address of a packet is not a link-local address, but 1739 there is not a matching entry in BST with state BOUND, this packet 1740 MUST be discarded. However, the packet may trigger the Data Snooping 1741 Process Section 7 if the Data-Snooping attribute is set on the 1742 attachment. 1744 Data packets from an attachment with the VALIDATING attribute set 1745 FALSE will be forwarded without being validated. 1747 The SAVI device MAY log packets that fail source address validation. 1749 8.2. Control Packet Filtering 1751 For attachments with the Validating attribute: 1753 DHCPv4 Client-Server messages in which the source IP address is 1754 neither all zeros nor bound with the corresponding binding anchor in 1755 the BST MUST be discarded. 1757 DHCPv6 Client-Server messages in which the source IP address is 1758 neither a link-local address nor bound with the corresponding binding 1759 anchor in the BST MUST be discarded. 1761 NDP messages in which the source IP address is neither a link-local 1762 address nor bound with the corresponding binding anchor MUST be 1763 discarded. 1765 NA messages in which the target address is neither a link-local 1766 address nor bound with the corresponding binding anchor MUST be 1767 discarded. 1769 ARP messages in which the protocol is IP and sender protocol address 1770 is neither all zeros address nor bound with the corresponding binding 1771 anchor MUST be discarded. 1773 ARP Reply messages in which the target protocol address is not bound 1774 with the corresponding binding anchor MUST be discarded. 1776 For attachments with other attributes: 1778 DHCP Server-to-Client messages not from attachments with the DHCP- 1779 Trust attribute or Trust attribute MUST be discarded. 1781 For attachments with no attribute: 1783 DHCP Server-to-Client messages from such attachments MUST be 1784 discarded. 1786 The SAVI device MAY record any messages that are discarded. 1788 9. State Restoration 1790 If a SAVI device reboots, the information kept in volatile memory 1791 will be lost. This section specifies the restoration of attribute 1792 configuration and BST. 1794 9.1. Attribute Configuration Restoration 1796 The loss of attribute configuration will not break the network: no 1797 action will be performed on traffic from attachments with no 1798 attribute. However, the loss of attribute configuration makes this 1799 SAVI function unable to work. 1801 To avoid the loss of binding anchor attribute configuration, the 1802 configuration MUST be able to be stored in non-volatile storage. 1803 After the reboot of SAVI device, if the configuration of binding 1804 anchor attribute can be found in non-volatile storage, the 1805 configuration MUST be used. 1807 9.2. Binding State Restoration 1809 The loss of binding state will cause the SAVI devices discard 1810 legitimate traffic. Purely using the Data Snooping Process to 1811 recover a large number of bindings is of heavy overhead and 1812 considerable delay. Thus, to recover bindings from non-volatile 1813 storage, as specified below, is RECOMMENDED. 1815 Binding entries MAY be saved into non-volatile storage whenever a new 1816 binding entry changes to BOUND state. If a binding with BOUND state 1817 is removed, the saved entry MUST be removed correspondingly. The 1818 time when each binding entry is established is also saved. 1820 Immediately after reboot, the SAVI device SHOULD restore binding 1821 states from the non-volatile storage. The system time of save 1822 process MUST be stored. After rebooting, the SAVI device MUST check 1823 whether each entry has been obsolete by comparing the saved lifetime 1824 and the difference between the current time and time when the binding 1825 entry is established. 1827 10. Constants 1829 The following constants are recommended for use in this context: 1831 o MAX_DHCP_RESPONSE_TIME 120s (SOL_MAX_RT from [RFC3315]) 1833 o MAX_LEASEQUERY_DELAY 10s (LQ_MAX_RT from [RFC5007]) 1835 o DETECTION_TIMEOUT 0.5s (TENT_LT from [RFC6620]) 1837 o DATA_SNOOPING_INTERVAL 60s and configurable (recommendation) 1839 o OFFLINK_DELAY 30s (recommendation) 1841 11. Security Considerations 1843 11.1. Security Problems about the Data Snooping Process 1845 There are two security problems about the Data Snooping Process 1846 Section 7: 1848 (1) The Data Snooping Process is costly, but an attacker can trigger 1849 it simply through sending a number of data packets. To avoid 1850 Denial of Services attack against the SAVI device itself, the 1851 Data Snooping Process MUST be rate limited. A constant 1852 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1853 Data Snooping Processes on one attachment MUST be separated by a 1854 minimum interval time DATA_SNOOPING_INTERVAL. If this value is 1855 changed, the value needs to be large enough to minimize denial of 1856 service attacks. 1858 (2) The Data Snooping Process may set up incorrect bindings if the 1859 clients do not reply to the detection probes Section 7.5.1. An 1860 attack will pass the duplicate detection if the client assigned 1861 the target address does not reply to the detection probes. The 1862 DHCP Lease query procedure performed by the SAVI device just 1863 tells whether the address is assigned in the network or not. 1864 However, the SAVI device cannot determine whether the address is 1865 just assigned to the triggering attachment from the DHCP 1866 LEASEQUERY Reply. 1868 11.2. Client departure issues 1870 After a binding is set up, the corresponding client may leave its 1871 attachment point. It may depart temporarily due to signal fade, or 1872 permanently by moving to a new attachment point or leaving the 1873 network. In the signal fade case, since the client may return 1874 shortly, the binding should be kept momentarily, lest legitimate 1875 traffic from the client be blocked. However, if the client leaves 1876 permanently, keeping the binding can be a security issue. If the 1877 binding anchor is a property of the attachment point rather than the 1878 client, e.g., the switch port but not incorporating the MAC Address, 1879 an attacker using the same binding anchor can send packets using IP 1880 addresses assigned to the client. Even if the binding anchor is a 1881 property of the client, retaining binding state for a departed client 1882 for a long time is a waste of resources. 1884 Whenever a direct client departs from the network, a link-down event 1885 associated with the binding anchor will be triggered. SAVI-DHCP 1886 monitors such events, and performs the following mechanism. 1888 (1) Whenever a client with the Validating attribute leaves, a timer 1889 of duration OFFLINK_DELAY is set on the corresponding binding 1890 entries. 1892 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 1893 received that targets the address during OFFLINK_DELAY, the entry 1894 MAY be removed. 1896 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 1897 timer. 1899 In this way, the bindings of a departing client are kept for 1900 OFFLINK_DELAY. In case of link flapping, the client will not be 1901 blocked. If the client leaves permanently, the bindings will be 1902 removed after OFFLINK_DELAY. 1904 SAVI-DHCP does not handle the departure of indirect clients, because 1905 it will not be notified of such events. Switches supporting indirect 1906 attachment (e.g., through a separate non-SAVI switch) SHOULD use 1907 information specific to the client such as its MAC address as part of 1908 the binding anchor. 1910 11.3. Duplicate Bindings to the Same Address 1912 The same address may be bound to multiple binding anchors only if the 1913 binding setup processes successfully complete for each binding 1914 anchor. This mechanism is designed to address the case where a 1915 client moves on the local link, and the case where a client has 1916 multiple attachments to a SAVI device. 1918 There are two security issues with such a design: 1920 First, by allowing one address to be bound to multiple binding 1921 anchors, the traceability of the address is weakened. An address can 1922 be traced to multiple attachments. 1924 Second, in the local link movement scenario, the former binding may 1925 not be removed and it can be used by an attacker sharing the same 1926 binding anchor. For example, when a switch port is used as binding 1927 anchor and the port is shared by an attacker and a client with a hub, 1928 the attacker can make use of the address assigned to the client after 1929 the client leaves. 1931 11.4. Compatibility with DNA (Detecting Network Attachment) 1933 DNA [RFC4436][RFC6059] is designed to decrease the handover latency 1934 after re-attachment to the same network. DNA mainly relies on 1935 performing reachability test by sending unicast Neighbor Solicitation 1936 /Router Solicitation/ARP Request message to determine whether a 1937 previously configured address is still valid. 1939 Although DNA provides optimization for clients, there is insufficient 1940 information for this mechanism to migrate the previous binding or 1941 establish a new binding. If a binding is set up only by snooping the 1942 reachability test message, the binding may be invalid. For example, 1943 an attacker can perform reachability test with an address bound to 1944 another client. If binding is migrated to the attacker, the attacker 1945 can successfully obtain the binding from the victim. Because this 1946 mechanism wouldn't set up a binding based on snooping the DNA 1947 procedure, it cannot achieve perfect compatibility with DNA. 1948 However, it only means the re-configuration of the interface is 1949 slowed but not prevented. Details are discussed as follows. 1951 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1952 set to a link-local address, and such messages will not be discarded 1953 by the policy specified in Section 8.2. If a client is re-attached 1954 to a previous network, the detection will be completed, and the 1955 address will be regarded as valid by the client. However, the 1956 candidate address is not contained in the probe. Thus, the binding 1957 cannot be recovered through snooping the probe. As the client will 1958 perform DHCP exchange at the same time, the binding will be recovered 1959 from the DHCP Snooping Process. The DHCP Request messages will not 1960 be filtered out in this case because they have link-local source 1961 addresses. Before the DHCP procedure is completed, packets will be 1962 filtered out by the SAVI device. In other words, if this SAVI 1963 function is enabled, Simple DNAv6 will not help reduce the handover 1964 latency. If Data-Snooping attribute is configured on the new 1965 attachment of the client, the data triggered procedure may reduce 1966 latency. 1968 In DNAv4 [RFC4436], the ARP probe will be discarded because an 1969 unbound address is used as the sender protocol address. As a result, 1970 the client will regard the address under detection is valid. 1971 However, the data traffic will be filtered. The DHCP Request message 1972 sent by the client will not be discarded, because the source IP 1973 address field should be all zero as required by [RFC2131]. Thus, if 1974 the address is still valid, the binding will be recovered from the 1975 DHCP Snooping Process. 1977 11.5. Binding Number Limitation 1979 A binding entry will consume a certain high-speed memory resources. 1980 In general, a SAVI device can afford only a quite limited number of 1981 binding entries. In order to prevent an attacker from overloading 1982 the resource of the SAVI device, a binding entry limit is set on each 1983 attachment. The binding entry limit is the maximum number of 1984 bindings supported on each attachment with Validating attribute. No 1985 new binding should be set up after the limit has been reached. If a 1986 DHCP Reply assigns more addresses than the remaining binding entry 1987 quota of each client, the message will be discarded and no binding 1988 will be set up. 1990 11.6. Privacy Considerations 1992 A SAVI device MUST delete binding anchor information as soon as 1993 possible (i.e., as soon as the state for a given address is back to 1994 NO_BIND), except where there is an identified reason why that 1995 information is likely to be involved in the detection, prevention, or 1996 tracing of actual source address spoofing. Information about the 1997 majority of hosts that never spoof SHOULD NOT be logged. 1999 12. IANA Considerations 2001 This memo asks the IANA for no new parameters. 2003 13. Acknowledgment 2005 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 2006 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 2007 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 2008 Garcia for careful review and valuation comments on the mechanism and 2009 text. 2011 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 2012 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 2013 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 2014 their valuable contributions. 2016 This document was generated using the xml2rfc tool. 2018 14. References 2020 14.1. Normative References 2022 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2023 converting network protocol addresses to 48.bit Ethernet 2024 address for transmission on Ethernet hardware", STD 37, 2025 RFC 826, November 1982. 2027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2028 Requirement Levels", BCP 14, RFC 2119, March 1997. 2030 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2031 2131, March 1997. 2033 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2034 and M. Carney, "Dynamic Host Configuration Protocol for 2035 IPv6 (DHCPv6)", RFC 3315, July 2003. 2037 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 2038 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 2040 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 2041 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 2043 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2044 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2045 September 2007. 2047 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 2048 "DHCPv6 Leasequery", RFC 5007, September 2007. 2050 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 2051 July 2008. 2053 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 2054 Detecting Network Attachment in IPv6", RFC 6059, November 2055 2010. 2057 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2058 SAVI: First-Come, First-Served Source Address Validation 2059 Improvement for Locally Assigned IPv6 Addresses", RFC 2060 6620, May 2012. 2062 14.2. Informative References 2064 [I-D.ietf-opsec-dhcpv6-shield] 2065 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 2066 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 2067 opsec-dhcpv6-shield-04 (work in progress), July 2014. 2069 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2070 Defeating Denial of Service Attacks which employ IP Source 2071 Address Spoofing", BCP 38, RFC 2827, May 2000. 2073 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 2074 (DHCP) Service for IPv6", RFC 3736, April 2004. 2076 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 2077 "Source Address Validation Improvement (SAVI) Framework", 2078 RFC 7039, October 2013. 2080 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 2081 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 2082 7341, August 2014. 2084 Authors' Addresses 2086 Jun Bi 2087 Tsinghua University 2088 Network Research Center, Tsinghua University 2089 Beijing 100084 2090 China 2092 EMail: junbi@tsinghua.edu.cn 2093 Jianping Wu 2094 Tsinghua University 2095 Computer Science, Tsinghua University 2096 Beijing 100084 2097 China 2099 EMail: jianping@cernet.edu.cn 2101 Guang Yao 2102 Tsinghua University 2103 Network Research Center, Tsinghua University 2104 Beijing 100084 2105 China 2107 EMail: yaoguang@cernet.edu.cn 2109 Fred Baker 2110 Cisco Systems 2111 Santa Barbara, CA 93117 2112 United States 2114 EMail: fred@cisco.com