idnits 2.17.1 draft-ietf-savi-dhcp-31.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 9, 2015) is 3366 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 13, 2015 Tsinghua Univ. 6 F. Baker 7 Cisco 8 January 9, 2015 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-31 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 13, 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, an system attached to a SAVI device can 396 be 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. This is because a SAVI switch that depends on DHCP cannot 408 tell, a priori, which ports have valid DHCP servers attached, or 409 which have routers or other equipment that would validly appear to 410 use an arbitrary set of source addresses. 412 4.2.1. Trust Attribute 414 The "Trust Attribute" is a Boolean value. If TRUE, it indicates that 415 the packets from the corresponding attached device need not have 416 their source addresses validated. Examples of a trusted binding 417 anchor would be a port to another SAVI device, or to an IP router, as 418 shown in Figure 1. In both cases, traffic using many source IP 419 addresses will be seen. By default, the Trust attribute is FALSE, 420 indicating that any device found on that port will seek an address 421 using DHCP and be limited to using such addresses. 423 SAVI devices will not set up bindings for points of attachment with 424 the Trust attribute set TRUE; DHCP messages and data packets from 425 attached devices with this attribute will not be checked. If the 426 DHCP Server-to-Client messages from attached devices with this 427 attribute can trigger the state transitions specified in Section 6 428 and Section 7, the corresponding processes in Section 6 and Section 7 429 will handle these messages. 431 4.2.2. DHCP-Trust Attribute 433 The "DHCP-Trust Attribute" is similarly a Boolean attribute. It 434 indicates whether the attached device is permitted to initiate DHCP 435 Server-to-Client messages. In Figure 1, the points of attachment of 436 the DHCP Server and the DHCP Relay would have this attribute set 437 TRUE, and ports that are trusted would have it set TRUE. 439 If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP 440 Server-to-Client messages from the points of attachment with this 441 attribute. If the DHCP Server-to-Client messages can trigger the 442 state transitions, the binding setup processes specified in Section 6 443 and Section 7 will handle them. By default, the DHCP-Trust attribute 444 is FALSE, indicating that the attached system is not a DHCP server. 446 A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for 447 more details. 449 4.2.3. DHCP-Snooping Attribute 451 The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It 452 indicates whether bindings will be set up based on DHCP snooping. 454 If this attribute is TRUE, DHCP Client-Server messages to points of 455 attachment with this attribute will trigger creation of bindings 456 based on the DHCP snooping procedure described in Section 6. If it 457 is FALSE, either the Trust attribute must be TRUE (so that bindings 458 become irrelevant) or another SAVI mechanism such as SAVI-FCFS must 459 be used on the point of attachment. 461 The DHCP-Snooping attribute is configured on the DHCP Client's point 462 of attachment. This attribute can be also used on the attachments to 463 protected Non-SAVI devices that are used by DHCP clients. In 464 Figure 1, the attachment from the Client A to the SAVI Device A, the 465 attachment from the Client B to the SAVI Device B, and the attachment 466 from the Non-SAVI Device 2 to the SAVI Device A can be configured 467 with this attribute. 469 Whenever this attribute is set TRUE on a point of attachment, the 470 "Validating Attribute" MUST also be set TRUE. 472 4.2.4. Data-Snooping Attribute 474 The "Data-Snooping Attribute" is a Boolean attribute. It indicates 475 whether data packets from the corresponding point of attachment may 476 trigger the binding setup procedure. 478 Data packets from points of attachment with this attribute may 479 trigger the setup of bindings. SAVI devices will set up bindings on 480 points of attachment with this attribute based on the data-triggered 481 process described in Section 7. 483 If the DHCP-Snooping attribute is configured on a point of 484 attachment, the bindings on this attachment are set up based on DHCP 485 message snooping. However, in some scenarios, a DHCP client may use 486 a DHCP address without the DHCP address assignment procedure being 487 performed on its current attachment. For such attached devices, the 488 Data-Snooping process, which is described in Section 7, is necessary. 489 This attribute is configured on such attachments. The usage of this 490 attribute is further discussed in Section 7. 492 Whenever this attribute is set on an attachment, the "Validating 493 Attribute" MUST be set on the same attachment. Since some networks 494 require DHCP deployment and others avoid it, there is no obvious 495 universal default value for the Data-Snooping Attribute. However, 496 note that deployment of SLAAC (and therefore SAVI-FCFS) is generally 497 configuration-free, while the deployment of DHCP involves at minimum 498 the deployment of a server. Hence, the Data-Snooping Attribute 499 should default to FALSE, and a mechanism should be implemented to 500 conveniently set it to TRUE on all points of attachment for which the 501 Trust attribute is FALSE. 503 4.2.5. Validating Attribute 505 The "Validating Attribute" is a Boolean attribute. It indicates 506 whether packets from the corresponding attachment will have their IP 507 source addresses validated based on binding entries on the 508 attachment. 510 If it is TRUE, packets coming from attachments with this attribute 511 will be checked based on binding entries on the attachment as 512 specified in Section 8. If it is FALSE, they will not. Since the 513 binding table is used in common with other SAVI algorithms, it merely 514 signifies whether the check will be done, not whether it will be done 515 for SAVI-DHCP originated bindings. 517 This attribute is by default the inverse of the Trust attribute; 518 source addresses on untrusted links are validated by default. It MAY 519 be set FALSE by the administration. 521 The expected use case is when SAVI is used to monitor but not block 522 unvalidated transmissions. The network manager, in that case, may 523 set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the 524 VALIDATING attribute FALSE. 526 4.2.6. Table of Mutual Exclusions 528 Different types of attributes may indicate mutually exclusive actions 529 on a packet. Mutually exclusive attributes MUST NOT be set TRUE on 530 the same attachment. The compatibility of different attributes is 531 listed in Figure 2. Note that although Trust and DHCP-Trust are 532 compatible, there is no need to configure DHCP-Trust to TRUE on an 533 attachment with Trust attribute TRUE. 535 +----------+----------+----------+----------+----------+----------+ 536 | | | | DHCP- | Data- | | 537 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 538 +----------+----------+----------+----------+----------+----------+ 539 | | | | mutually | mutually | mutually | 540 | Trust | - |compatible| exclusive| exclusive| exclusive| 541 +----------+----------+----------+----------+----------+----------+ 542 | | | | | | | 543 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 544 +----------+----------+----------+----------+----------+----------+ 545 |DHCP- |mutually | | | | | 546 |Snooping |exclusive |compatible| - |compatible|compatible| 547 +----------+----------+----------+----------+----------+----------+ 548 |Data- |mutually | | | | | 549 |Snooping |exclusive |compatible|compatible| - |compatible| 550 +----------+----------+----------+----------+----------+----------+ 551 | |mutually | | | | | 552 |Validating|exclusive |compatible|compatible|compatible| - | 553 +----------+----------+----------+----------+----------+----------+ 555 Figure 2: Table of Mutual Exclusions 557 4.3. Perimeter 559 4.3.1. SAVI-DHCP Perimeter Overview 561 SAVI devices form a perimeter separating trusted and untrusted 562 regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]). 563 The perimeter is primarily designed for scalability. It has two 564 implications. 566 o SAVI devices only need to establish bindings for directly attached 567 clients, or clients indirectly attached through a non-SAVI 568 protected device, rather than all of the clients in the network. 570 o Each SAVI device only need to validate traffic from clients 571 attached to it, without checking all the traffic passing by. 573 Consider the example in Figure 1. The protection perimeter is formed 574 by SAVI Devices A, B and C. In this case, SAVI device B does not 575 create a binding for client A. However, because SAVI device A filters 576 spoofed traffic from client A, SAVI device B can avoid receiving 577 spoofed traffic from client A. 579 The perimeter in SAVI-DHCP is not only a perimeter for data packets, 580 but also a perimeter for DHCP messages. The placement of the DHCP 581 Relay and DHCP Server, which are not involved in [RFC6620], is 582 related to the construction of the perimeter. The requirement on the 583 placement and configuration of DHCP Relay and DHCP Server are 584 discussed in Section 4.3.3. 586 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 588 A perimeter separating trusted and untrusted regions of the network 589 is formed as follows: 591 (1) Configure the Validating and DHCP-Snooping attributes TRUE on 592 the direct attachments of all DHCP clients. 594 (2) Configure the Validating and DHCP-Snooping attributes TRUE on 595 the indirect attachments of all DHCP clients (i.e., DHCP clients 596 on protected links). 598 (3) Configure the Trust attribute TRUE on the attachments to other 599 SAVI devices. 601 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 602 are attached only to SAVI devices, set the Trust attribute TRUE 603 on their attachments. 605 (5) Configure the DHCP-Trust attribute TRUE on the direct 606 attachments to trusted DHCP relays and servers. 608 In this way, the points of attachments with the Validating attribute 609 TRUE (and generally together with attachments of unprotected devices) 610 on SAVI devices can form a perimeter separating DHCP clients and 611 trusted devices. Data packet checks are only performed on the 612 perimeter. The perimeter is also a perimeter for DHCP messages. The 613 DHCP-Trust attribute is only TRUE on the inside links of the 614 perimeter. Only DHCP server-to-client messages originated within the 615 perimeter are trusted. 617 4.3.3. On the Placement of the DHCP Server and Relay 619 As a result of the configuration guideline, SAVI devices only trust 620 DHCP Server-to-Client messages originated inside the perimeter. 621 Thus, the trusted DHCP Relays and DHCP Servers must be placed within 622 the perimeter. DHCP server-to-client messages will be filtered on 623 the perimeter. Server-to-relay messages will not be filtered, as 624 they are within the perimeter. In this way, DHCP server-to-client 625 messages from bogus DHCP servers are filtered on the perimeter, 626 having entered through untrusted points of attachment. The SAVI 627 devices are protected from forged DHCP messages. 629 DHCP server-to-client messages arriving at the perimeter from outside 630 the perimeter are not trusted. There is no distinction between a 631 DHCP server owned and operated by the correct administration but 632 outside the SAVI perimeter and a bogus DHCP server. For example, in 633 Figure 1, DHCP server A is valid, but it is attached to Non-SAVI 634 device 1. A bogus DHCP server is also attached Non-SAVI device 1. 635 While one could imagine a scenario in which the valid one had a 636 statistically configured port number and MAC address, and therefore a 637 binding, by default SAVI-DHCP cannot distinguish whether a message 638 received from the port of Non-SAVI device 1 is from DHCP server A or 639 the bogus DHCP server. If the DHCP server A is contained in the 640 perimeter, Non-SAVI device 1 will also be contained in the perimeter. 641 Thus, the DHCP server A cannot be contained within the perimeter 642 apart from manual configuration of the binding anchor. 644 Another consideration on the placement is that if the DHCP server/ 645 relay is not inside the perimeter, the SAVI devices may not be able 646 to set up bindings correctly, because the SAVI devices may not be on 647 the path between the clients and the server/relay, or the DHCP 648 messages are encapsulated (e.g., Relay-reply and Relay-forward). 650 4.3.4. An Alternative Deployment 652 In common deployment practice, the traffic from the unprotected 653 network is treated as trustworthy, which is to say that it is not 654 filtered. In such a case, the Trust attribute can be set TRUE on the 655 unprotected link. If Non-SAVI devices, or a number of connected Non- 656 SAVI devices, are only attached to SAVI devices and unprotected 657 devices, their attachment to SAVI devices can have the Trust 658 attribute set TRUE. Then an unclosed perimeter will be formed, as 659 illustrated in Figure 3. 661 To configure such a perimeter, at minimum the DHCP messages from 662 unprotected networks MUST be ensured to be trustworthy. Achieving 663 this is beyond the scope of this document. 665 | . . Protection | 666 | | | Perimeter | 667 | | | | 668 | Unprotected | | Unprotected | 669 | Link | | Link | 670 | | | | 671 | | | | 672 | +--------+ +--------+ +--------+ | 673 | |SAVI |----|Non-SAVI|----|SAVI | | 674 | |Device | |Device | |Device | | 675 | +--------+ +--------+ +--------+ | 676 | | | | 677 \__________________________________________________/ 678 | | 679 | | 680 +--------+ +--------+ 681 |DHCP | |DHCP | 682 |Client | |Client | 683 +--------+ +--------+ 685 Figure 3: Alternative Perimeter Configuration 687 4.3.5. Considerations regarding Binding Anchors 689 The strength of this binding-based mechanism depends on the strength 690 of the binding anchor. The sample binding anchors in [RFC7039] have 691 the property that they associate an IP address with a direct physical 692 or secure virtual interface such as a switch port, a subscriber 693 association, or a security association. In addition, especially in 694 the case that a protected non-SAVI device such as a desktop switch or 695 a hub is between the client device and the SAVI switch, they MAY be 696 extended to also include a MAC address or other link-layer attribute. 697 In short, a binding anchor is intended to associate an IP address 698 with something unspoofable that identifies a single client system or 699 one of its interfaces; this may be a physical or virtual interface or 700 that plus disambiguating link-layer information. 702 If the binding anchor is spoofable, such as a plain MAC address, or 703 non-exclusive, such as a switch port extended using a non-SAVI 704 device, an attacker can use a forged binding anchor to evade 705 validation. Indeed, using a binding anchor that can be easily 706 spoofed can lead to worse outcomes than allowing IP spoofing traffic. 707 Thus, a SAVI device MUST use a non-spoofable and exclusive binding 708 anchor. 710 4.4. Other Device Configuration 712 In addition to a possible binding anchor configuration specified in 713 Section 4.2, an implementation has the following configuration 714 requirements: 716 (1) Address configuration. For DHCPv4: the client of a SAVI device 717 MUST have an IPv4 address. For DHCPv6: the client of a SAVI 718 device MUST have a link-local address; when the DHCPv6 server is 719 not on the same link as the SAVI device, the SAVI device MUST 720 also have a global IPv6 address. 722 (2) DHCP server address configuration: a SAVI device MUST store the 723 list of the DHCP server addresses that it could contact during a 724 Lease query process. 726 5. Binding State Table (BST) 728 The Binding State Table, which may be implemented centrally in the 729 switch or distributed among its ports, is used to contain the 730 bindings between the IP addresses assigned to the attachments and the 731 corresponding binding anchors of the attachments. Note that in this 732 description, there is a binding entry for each IPv4 or IPv6 address 733 associated with each binding anchor, and there may be several of each 734 such address, especially if the port is extended using a protected 735 non-SAVI device. Each binding entry, has 5 fields: 737 o Binding Anchor(Anchor): the binding anchor, i.e., a physical and/ 738 or link-layer property of the attachment. 740 o IP Address(Address): the IPv4 or IPv6 address assigned to the 741 attachment by DHCP. 743 o State: the state of the binding. Possible values of this field 744 are listed in Section 6.2 and Section 7.3. 746 o Lifetime: the remaining seconds of the binding. Internally, this 747 MAY be stored as the timestamp value at which the lifetime 748 expires. 750 o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the 751 corresponding DHCP transaction. TID field is used to associate 752 DHCP Server-to-Client messages with corresponding binding entries. 754 The IA is not present in the BST for three reasons: 756 o The lease of each address in one IA is assigned separately. 758 o When the binding is set up based on data-snooping, the IA cannot 759 be recovered from the lease query protocol. 761 o DHCPv4 does not define an IA. 763 An instance of this table is shown in Figure 4. 765 +---------+----------+----------+-----------+-------+ 766 | Anchor | Address | State | Lifetime |TID | 767 +---------+----------+----------+-----------+-------+ 768 | Port_1 | IP_1 | BOUND | 65535 |TID_1 | 769 +---------+----------+----------+-----------+-------+ 770 | Port_1 | IP_2 | BOUND | 10000 |TID_2 | 771 +---------+----------+----------+-----------+-------+ 772 | Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | 773 +---------+----------+----------+-----------+-------+ 775 Figure 4: Instance of BST 777 6. DHCP Snooping Process 779 This section specifies the process of setting up bindings based on 780 DHCP snooping. This process is illustrated using a state machine. 782 6.1. Rationale 784 The rationale of the DHCP Snooping Process is that if a DHCP client 785 is legitimately using a DHCP-assigned address, the DHCP address 786 assignment procedure that assigns the IP address to the client must 787 have been performed on the client's point of attachment. This basis 788 works when the SAVI device is always on the path(s) from the DHCP 789 client to the DHCP server(s)/relay(s). Without considering the 790 movement of DHCP clients, the SAVI device should be the cut vertex 791 whose removal will separate the DHCP client and the remaining network 792 containing the DHCP server(s)/ and relay(s). For most of the 793 networks whose topologies are simple, it is possible to deploy this 794 SAVI function at proper devices to meet this requirement. 796 However, if there are multiple paths from a DHCP client to the DHCP 797 server and the SAVI device is only on one of them, there is an 798 obvious failure case: the SAVI device may not be able to snoop the 799 DHCP procedure. Host movement may also make this requirement 800 difficult to meet. For example, when a DHCP client moves from one 801 attachment to another attachment in the same network, it may fail to 802 reinitialize its interface or send a Confirm message because of 803 incomplete protocol implementation. Thus, there can be scenarios in 804 which only performing this DHCP snooping process is insufficient to 805 set up bindings for all the valid DHCP addresses. These exceptions 806 and the solutions are discussed in Section 7. 808 6.2. Binding States Description 810 Following binding states are present in this process and the 811 corresponding state machine: 813 NO_BIND: No binding has been set up. 815 INIT_BIND: A potential binding has been set up. 817 BOUND: The binding has been set up. 819 6.3. Events 821 This section describes events in this process and the corresponding 822 state machine. 824 6.3.1. Timer Expiration Event 826 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 828 6.3.2. Control Message Arriving Events 830 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 831 received. 833 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 835 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 837 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 838 received. 840 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 842 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 843 option is received. 845 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 847 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 848 received. 850 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 851 received. 853 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 854 section 4.3.3 of [RFC5007]) is received. 856 Note: the events listed here do not cover all the DHCP messages in 857 section 3. The messages which do not really determine address usage 858 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 859 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 860 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 861 to section 6.4.2.1), are not included. 863 Moreover, only if a DHCP message can pass the following checks, the 864 corresponding event is regarded as a valid event: 866 o Attribute check: the DHCP Server-to-Client messages and 867 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 868 attribute; the DHCP Client-Server messages should be from 869 attachments with DHCP-Snooping attribute. 871 o Destination check: the DHCP Server-to-Client messages should be 872 destined to attachments with DHCP-Snooping attribute. This check 873 is performed to ensure the binding is set up on the SAVI device 874 which is nearest to the destination client. 876 o Binding anchor check: the DHCP Client-Server messages which may 877 trigger modification or removal of an existing binding entry must 878 have a matching binding anchor with the corresponding entry. 880 o TID check: the DHCP Server-to-Client/Client-Server messages which 881 may cause modification on existing binding entries must have 882 matched TID with the corresponding entry. Note that this check is 883 not performed on Lease query and Lease query-reply messages as 884 they are exchanged between the SAVI devices and the DHCP servers. 885 Besides, this check is not performed on DHCP Renew/Rebind 886 messages. 888 o Binding limitation check: the DHCP messages must not cause new 889 binding setup on an attachment whose binding entry limitation has 890 been reached. (refer to Section 11.5). 892 o Address check: the source address of the DHCP messages should pass 893 the check specified in Section 8.2. 895 On receiving a DHCP message without triggering a valid event, the 896 state will not change, and the actions will not be performed. Note 897 that if a message does not trigger a valid event but it can pass the 898 checks in Section 8.2, it MUST be forwarded. 900 6.4. The State Machine of DHCP Snooping Process 902 This section specifies state transitions and their corresponding 903 actions. 905 6.4.1. Initial State: NO_BIND - No binding has been set up 907 6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request 908 message is received 910 The SAVI device MUST forward the message. 912 The SAVI device will generate an entry in the BST. The Binding 913 anchor field is set to the binding anchor of the attachment from 914 which the message is received. The State field is set to INIT_BIND. 915 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 916 field is set to the TID of the message. If the message is DHCPv4 917 Request or DHCPv4 Reboot, the Address field can be set to the address 918 to request, i.e., the 'requested IP address'. An example of the 919 entry is illustrated in Figure 5. 921 +---------+-------+---------+-----------------------+-------+ 922 | Anchor |Address| State | Lifetime |TID | 923 +---------+-------+---------+-----------------------+-------+ 924 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 925 +---------+-------+---------+-----------------------+-------+ 927 Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot 928 triggered initialization 930 Resulting state: INIT_BIND - A potential binding has been set up 932 6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received 934 The SAVI device MUST forward the message. 936 The SAVI device will generate an entry in the BST. The Binding 937 anchor field is set to the binding anchor of the attachment from 938 which the message is received. The State field is set to INIT_BIND. 939 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 940 field is set to the TID of the message. If the message is DHCPv4 941 Request or DHCPv4 Reboot, the Address field can be set to the address 942 to request, i.e., the 'requested IP address'. An example of the 943 entry is illustrated in Figure 5. 945 Resulting state: INIT_BIND - A potential binding has been set up 947 6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message 948 with Rapid Commit option is received 950 The SAVI device MUST forward the message. 952 The SAVI device will generate an entry in the BST. The Binding 953 anchor field is set to the binding anchor of the attachment from 954 which the message is received. The State field is set to INIT_BIND. 955 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 956 field is set to the TID of the message. If the message is DHCPv4 957 Request or DHCPv4 Reboot, the Address field can be set to the address 958 to request, i.e., the 'requested IP address'. An example of the 959 entry is illustrated in Figure 5. 961 Resulting state: INIT_BIND - A potential binding has been set up 963 6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received 965 The SAVI device MUST forward the message. 967 The SAVI device will generate corresponding entries in the BST for 968 each address in each Identity Association (IA) option of the Confirm 969 message. The Binding anchor field is set to the binding anchor of 970 the attachment from which the message is received. The State field 971 is set to INIT_BIND. The Lifetime field is set to be 972 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 973 message. The Address field is set to the address(es) to confirm. An 974 example of the entries is illustrated in Figure 6. 976 +---------+--------+---------+-----------------------+-------+ 977 | Anchor | Address| State | Lifetime |TID | 978 +---------+--------+---------+-----------------------+-------+ 979 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 980 +---------+--------+---------+-----------------------+-------+ 981 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 982 +---------+--------+---------+-----------------------+-------+ 984 Figure 6: Binding entry in BST on Confirm triggered initialization 986 Resulting state: INIT_BIND - A potential binding has been set up 988 6.4.1.5. Events that cannot happen in the NO_BIND state 990 o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires 992 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 993 received 995 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 996 received 998 o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received 1000 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1001 received 1003 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1004 received 1006 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is 1007 received 1009 These cannot happen because they are each something that happens 1010 AFTER a binding has been created. 1012 6.4.2. Initial State: INIT_BIND - A potential binding has been set up 1014 6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1015 is received 1017 The message MUST be forwarded to the corresponding client. 1019 If the message is DHCPv4 ACK, the Address field of the corresponding 1020 entry (i.e., the binding entry whose TID is the same of the message) 1021 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 1022 The Lifetime field is set to the sum of the lease time in ACK message 1023 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1025 If the message is DHCPv6 Reply, there are following cases: 1027 1. If the status code is not "Success", no modification on 1028 corresponding entries will be made. Corresponding entries will 1029 expire automatically if no "Success" Reply is received during the 1030 lifetime. The entries are not removed immediately due to the 1031 client may be able to use the addresses whenever a "Success" 1032 Reply is received ("If the client receives any Reply messages 1033 that do not indicate a NotOnLink status, the client can use the 1034 addresses in the IA and ignore any messages that indicate a 1035 NotOnLink status." [RFC3315]). 1037 2. If the status code is "Success", the SAVI device checks the IA 1038 options in the Reply message. 1040 A. If there are IA options in the Reply message, the SAVI device 1041 checks each IA option. When the first assigned address is 1042 found, the Address field of the binding entry with matched 1043 TID is set to the address. The Lifetime field is set to the 1044 sum of the lease time in Reply message and 1045 MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1046 If there are more than one address assigned in the message, 1047 new binding entries are set up for the remaining address 1048 assigned in the IA options. An example of the entries is 1049 illustrated in Figure 8. SAVI devices do not specially 1050 process IA options with NoAddrsAvail status, because there 1051 should be no address contained in such IA options. 1053 B. Otherwise, the DHCP Reply message is in response to a Confirm 1054 message. The state of the binding entries with matched TID 1055 is changed to BOUND. Because [RFC3315] does not require 1056 lease time of addresses to be contained in the Reply message, 1057 the SAVI device SHOULD send a LEASEQUERY [RFC5007] message 1058 querying by IP address to All_DHCP_Servers multicast address 1059 [RFC3315] or a list of configured DHCP server addresses. The 1060 Lease query message is generated for each IP address if 1061 multiple addresses are confirmed. The Lifetime of 1062 corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If 1063 there is no response message after MAX_LEASEQUERY_DELAY, send 1064 the LEASEQUERY message again. An example of the entries is 1065 illustrated in Figure 7. If the SAVI device does not send 1066 the LEASEQUERY message, a pre-configured lifetime 1067 DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 1068 (Note: it is RECOMMENDED to use T1 configured on DHCP servers 1069 as the DHCP_DEFAULT_LEASE.) 1071 Note: the SAVI devices do not check if the assigned addresses are 1072 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 1073 only source of valid addresses. However, the DHCP servers should be 1074 configured to make sure no duplicated addresses are assigned. 1076 +---------+----------+-------+------------------------+-------+ 1077 | Anchor | Address | State | Lifetime |TID | 1078 +---------+----------+-------+------------------------+-------+ 1079 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1080 +---------+----------+-------+------------------------+-------+ 1081 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1082 +---------+----------+-------+------------------------+-------+ 1084 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1085 Confirm 1087 +---------+----------+-------+------------------------+-------+ 1088 | Anchor | Address | State | Lifetime |TID | 1089 +---------+----------+-------+------------------------+-------+ 1090 | Port_1 | Addr1 | BOUND |Lease time+ |TID | 1091 | | | |MAX_DHCP_RESPONSE_TIME | | 1092 +---------+----------+-------+------------------------+-------+ 1093 | Port_1 | Addr2 | BOUND |Lease time+ |TID | 1094 | | | |MAX_DHCP_RESPONSE_TIME | | 1095 +---------+----------+-------+------------------------+-------+ 1097 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 1098 Request 1100 Resulting state: BOUND - The binding has been set up 1102 6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1103 expires 1105 The entry MUST be deleted from BST. 1107 Resulting state: An entry that has been deleted from the BST may be 1108 considered to be in the state "NO_BIND" - No binding has been set up. 1110 6.4.2.3. Events that are ignored in INIT_BIND 1112 If no DHCP Server-to-Client messages which assign addresses or 1113 confirm addresses are received, corresponding entries will expire 1114 automatically. Thus, other DHCP Server-to-Client messages (e.g., 1115 DHCPv4 NAK) are not specially processed. 1117 As a result, the following events, should they occur, are ignored 1118 until either a DHCPv4 ACK or a DHCPv6 Reply message is received or 1119 the lifetime of the binding entry expires. 1121 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1122 received 1124 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1126 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1128 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1129 received 1131 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 1132 received 1134 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1135 Commit option is received 1137 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1138 received 1140 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1141 received 1143 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is 1144 received 1146 In each case, the message MUST be forwarded. 1148 Resulting state: INIT_BIND - A potential binding has been set up 1150 6.4.3. Initial State: BOUND - The binding has been set up 1152 6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1153 expires 1155 The entry MUST be deleted from BST. 1157 Resulting state: An entry that has been deleted from the BST may be 1158 considered to be in the state "NO_BIND" - No binding has been set up. 1160 6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline 1161 message is received 1163 The message MUST be forwarded. 1165 The SAVI device first gets all the addresses ("Requested IP address" 1166 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1167 IA options of DHCPv6 Decline/Release) to decline/release in the 1168 message. Then the corresponding entries MUST be removed. 1170 Resulting state in each relevant BST entry: An entry that has been 1171 deleted from the BST may be considered to be in the state "NO_BIND" - 1172 No binding has been set up. 1174 6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release 1175 message is received 1177 The message MUST be forwarded. 1179 The SAVI device first gets all the addresses ("Requested IP address" 1180 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1181 IA options of DHCPv6 Decline/Release) to decline/release in the 1182 message. Then the corresponding entries MUST be removed. 1184 Resulting state in each relevant BST entry: An entry that has been 1185 deleted from the BST may be considered to be in the state "NO_BIND" - 1186 No binding has been set up. 1188 6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind 1189 message is received 1191 The message MUST be forwarded. 1193 In such case, a new TID will be used by the client. The TID field of 1194 the corresponding entries MUST be set to the new TID. Note that TID 1195 check will not be performed on such messages. 1197 Resulting state: BOUND: The binding has been set up 1199 6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew 1200 message is received 1202 The message MUST be forwarded. 1204 In such case, a new TID will be used by the client. The TID field of 1205 the corresponding entries MUST be set to the new TID. Note that TID 1206 check will not be performed on such messages. 1208 Resulting state: BOUND: The binding has been set up 1210 6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1211 is received 1213 The message MUST be forwarded. 1215 The DHCP Reply messages received in current states should be in 1216 response to DHCP Renew/Rebind. 1218 If the message is DHCPv4 ACK, the SAVI device updates the binding 1219 entry with matched TID, with the Lifetime field set to be the sum of 1220 the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in 1221 the state BOUND. 1223 If the message is DHCPv6 Reply, the SAVI device checks each IA 1224 Address option in each IA option. For each: 1226 1. If the IA entry in the REPLY message has the status "NoBinding", 1227 there is no address in the option, and no operation on an address 1228 is performed. 1230 2. If the valid lifetime of an IA address option is 0, the binding 1231 entry with matched TID and address is removed, leaving it 1232 effectively in the state NO_BIND. 1234 3. Otherwise, set the Lifetime field of the binding entry with 1235 matched TID and address to be the sum of the new valid lifetime 1236 and MAX_DHCP_RESPONSE_TIME, leaving the entry in the state BOUND. 1238 Resulting state: NO_BIND or BOUND, as specified. 1240 6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 1241 LEASEQUERY_REPLY is received 1243 The message MUST be forwarded. 1245 The message should be in response to the Lease query message sent in 1246 Section 6.4.2. The related binding entry can be determined based on 1247 the address in the IA Address option in the Lease query-reply 1248 message. The Lifetime field of the corresponding binding entry is 1249 set to the sum of the lease time in the LEASEQUERY_REPLY message and 1250 MAX_DHCP_RESPONSE_TIME. 1252 Resulting state: BOUND: The binding has been set up 1254 6.4.3.8. Events not processed in the state BOUND 1256 The following events are ignored if received while the indicated 1257 entry is in the state BOUND. Any required action will be the result 1258 of the next message in the client/server exchange. 1260 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1261 received 1263 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1265 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1267 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1268 Commit option is received 1270 6.4.4. Table of State Machine 1272 The main state transits are listed as follows. Note that not all the 1273 details are specified in the table and the diagram. 1275 State Event Action Next State 1276 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1277 INIT_BIND RPL Record lease time BOUND 1278 (send lease query if no lease) 1279 INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1280 BOUND RLS/DCL Remove entry NO_BIND 1281 BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1282 BOUND RPL Set new lifetime BOUND 1283 BOUND LQR Record lease time BOUND 1285 Figure 9: Table of Transit 1287 RQ: EVE_DHCP_REQUEST 1289 CF: EVE_DHCP_CONFIRM 1291 RC: EVE_DHCP_SOLICIT_RC 1293 RE: EVE_DHCP_REBOOT 1295 RPL: EVE_DHCP_REPLY 1297 DCL: EVE_DHCP_DECLINE 1299 RLS: EVE_DHCP_RELEASE 1301 LQR: EVE_DHCP_LEASEQUERY 1302 +-------------+ 1303 | | 1304 /---------| NO_BIND |<----------\ 1305 | ------>| | | 1306 | | +-------------+ |EVE_DHCP_RELEASE 1307 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1308 EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE 1309 EVE_DHCP_SOLICIT_RC| | | 1310 EVE_DHCP_REBOOT | | | 1311 | | | 1312 | | | 1313 v | | 1314 +-------------+ +------------+ 1315 | | EVE_DHCP_REPLY | | 1316 | INIT_BIND ------------------------>| BOUND |<-\ 1317 | | | | | 1318 +-------------+ +------------+ | 1319 | | 1320 \--------/ 1321 EVE_DHCP_REPLY 1322 EVE_DHCP_LEASEQUERY 1324 Figure 10: Diagram of Transit 1326 7. Data Snooping Process 1328 7.1. Scenario 1330 The rationale of the DHCP Snooping Process specified in Section 6 is 1331 that if a DHCP client's use of a DHCP address is legitimate, the 1332 corresponding DHCP address assignment procedure must have been 1333 finished on the attachment of the DHCP client. This is the case 1334 stands when the SAVI device is persistently on the path(s) from the 1335 DHCP client to the DHCP server(s)/relay(s). However, there are two 1336 case when this does not work: 1338 o Multiple paths: there is more than one feasible link-layer paths 1339 from the client to the DHCP server/relay, and the SAVI device is 1340 not on everyone of them. The client may get its address through 1341 one of the paths not passing by the SAVI device, but packets from 1342 the client can travel through paths that pass through the SAVI 1343 device. Because the SAVI device could not snoop the DHCP packet 1344 exchange procedure, the DHCP snooping procedure cannot set up the 1345 corresponding binding. 1347 o Dynamic path: there is only one feasible link-layer path from the 1348 client to the DHCP server/relay, but the path is dynamic due to 1349 topology change (for example, some link turns broken due to 1350 failure or as planned) or link-layer path change. This situation 1351 also covers the local-link movement of clients without address 1352 confirm/re-configuration process. For example, a host changes its 1353 attached switch port in a very short time. In such cases, the 1354 DHCP snooping process will not set up the corresponding binding. 1356 Data Snooping Process prevents permanently blocking legitimate 1357 traffic in case of these two exceptions. This process is performed 1358 on attachments with the Data-Snooping attribute. Data packets 1359 without matching binding entry may trigger this process to set up 1360 bindings. 1362 Snooping data traffic introduces considerable burden on the processor 1363 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1364 overhead of this process, the implementation of this process is a 1365 conditional SHOULD. This function SHOULD be enabled unless the 1366 implementation is known to be used in the scenarios without the above 1367 exceptions. For example, if the implementation is to be used in 1368 networks with tree topology and without host local-link movement, 1369 there is no need to implement this process in such scenarios. 1371 This process is not intended to set up a binding whenever a data 1372 packet without matched binding entry is received. Instead, unmatched 1373 data packets trigger this process probabilistically and generally a 1374 number of unmatched packets will be discarded before the binding is 1375 set up. 1377 7.2. Rationale 1379 This process makes use of NS/ARP and DHCP LEASEQUERY to set up 1380 bindings. If an address is not used by another client in the 1381 network, and the address has been assigned in the network, the 1382 address can be bound with the binding anchor of the attachment from 1383 which the unmatched packet is received. 1385 The security issues about this process is discussed is Section 11.1. 1387 7.3. Additional Binding States Description 1389 In addition to NO_BIND and BOUND from Section 6.2, two new states 1390 used in this process are listed here. The INIT_BIND state is not 1391 used, as it is entered by observing a DHCP message. 1393 DETECTION: The address in the entry is under local duplication 1394 detection. 1396 RECOVERY: The SAVI device is querying the assignment and lease time 1397 of the address in the entry through DHCP Lease query. 1399 7.4. Events 1401 In addition to EVE_DATA_LEASEQUERY and EVE_DHCP_REBIND, these 1402 additional events are described here. If an event will trigger the 1403 creation of a new binding entry, the binding entry limit on the 1404 binding anchor MUST NOT be exceeded. 1406 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1408 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1409 against an address in DETECTION state is received from a host other 1410 than the one for which the entry was added. 1412 EVE_DATA_LEASEQUERY: 1414 o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1415 is received. 1417 o IPv6: A successful LEASEQUERY-REPLY is received. 1419 The triggering packet should pass the following checks to trigger a 1420 valid event: 1422 o Attribute check: the data packet should be from attachments with 1423 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1424 messages should be from attachments with DHCP-Snooping attribute. 1426 o Binding limitation check: the DHCP messages must not cause new 1427 binding setup on an attachment whose binding entry limitation has 1428 been reached. (refer to Section 11.5). 1430 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1431 DHCP Lease query messages must pass the check specified in 1432 Section 8.2. For EVE_DATA_CONFLICT, the source address and target 1433 address of the ARP or NA messages must pass the check specified in 1434 Section 8.2. 1436 o Interval check: the interval between two successive 1437 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1438 smaller than DATA_SNOOPING_INTERVAL. 1440 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have 1441 matched TID with the corresponding entry. 1443 o Prefix check: the source address of the data packet should be of a 1444 valid local prefix, as specified in section 7 of [RFC7039]. 1446 EVE_ENTRY_EXPIRE: A timer expires. 1448 7.5. Initial State: state NO_BIND - No binding has been set up 1450 7.5.1. Event: EVE_DATA_UNMATCH: A data packet without matched binding 1451 is received 1453 Make a probabilistic determination whether to act on this event. The 1454 probability may be configured or calculated based on the state of the 1455 SAVI device. This probability should be low enough to mitigate the 1456 damage from DoS attack against this process. 1458 Create a new entry in the BST. Set the Binding Anchor field to the 1459 corresponding binding anchor of the attachment. Set the Address 1460 field to the source address of the packet. Set the State field to 1461 DETECTION. Set the Lifetime of the created entry to 1462 2*DETECTION_TIMEOUT. 1464 Check if the address has a local conflict (it violates an address 1465 being used by another node): 1467 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1468 [RFC0826] or an ARP probe [RFC5227] on the address; if there is 1469 no response message after DETECTION_TIMEOUT, send another ARP 1470 Request or ARP probe; 1472 (2) IPv6 address: send a Duplicate Address Detection message 1473 [RFC4861] targeting the address; ideally, only the host on that 1474 point of attachment responds with a Neighbor Advertisement; if 1475 more than one Neighbor Advertisement is observed, the BST entry 1476 should be removed. 1478 As Duplicate Address Detection is an unreliable process (either the 1479 packet to or from the other system may be lost in transit), if there 1480 is no response, it should be repeated, as described in [RFC6620]. 1482 The packet that triggers this event SHOULD be discarded. 1484 This local conflict process SHOULD be performed. If it is not 1485 performed, the state of the entry is set to RECOVERY, the lifetime is 1486 set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified 1487 in the following section will be performed directly. 1489 An example of the entry is illustrated in Figure 11. 1491 +---------+-------+---------+-----------------------+-------+ 1492 | Anchor |Address| State | Lifetime |TID | 1493 +---------+-------+---------+-----------------------+-------+ 1494 | Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | 1495 +---------+-------+---------+-----------------------+-------+ 1497 Figure 11: Binding entry in BST on data triggered initialization 1499 Resulting state: DETECTION - The address in the entry is under local 1500 duplication detection 1502 7.5.2. Events not observed in NO_BIND 1504 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1505 received from unexpected system 1507 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1509 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1510 received 1512 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1513 received 1515 EVE_ENTRY_EXPIRE 1517 7.6. Initial State: state DETECTION - The address in the entry is under 1518 local duplication detection 1520 7.6.1. Event: EVE_ENTRY_EXPIRE 1522 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1523 by IP address to each DHCPv4 server with IP Address Lease Time 1524 option (option 51). A list of authorized DHCP servers are kept 1525 by the SAVI device. The list should be pre-configured or 1526 discovered by sending DHCPv4 Discover messages and parsing the 1527 replied DHCPv4 Offer messages. Change the state of the 1528 corresponding entry to RECOVERY. Change the lifetime of the 1529 entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the 1530 TID used in the DHCPLEASEQUERY message. If there is no response 1531 message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to each 1532 DHCPv4 server again. 1534 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1535 address to All_DHCP_Relay_Agents_and_Servers multicast address or 1536 a list of pre-configured DHCPv6 server addresses. Change the 1537 state of the corresponding entry to RECOVERY. Change the 1538 lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID 1539 field is set to the TID used in the LEASEQUERY message. If there 1540 is no response message after MAX_LEASEQUERY_DELAY, send the 1541 LEASEQUERY message again. 1543 An example of the entry is illustrated in Figure 12. 1545 +---------+-------+---------+-----------------------+-------+ 1546 | Anchor |Address| State | Lifetime |TID | 1547 +---------+-------+---------+-----------------------+-------+ 1548 | Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | 1549 +---------+-------+---------+-----------------------+-------+ 1551 Figure 12: Binding entry in BST on Lease Query 1553 Resulting state: RECOVERY - The SAVI device is querying the 1554 assignment and lease time of the address in the entry through DHCP 1555 Leasequery 1557 7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) 1558 message received from unexpected system 1560 Remove the entry. 1562 Resulting state: NO_BIND - No binding has been set up 1564 7.6.3. Events not observed in DETECTION 1566 EVE_DATA_UNMATCH: A data packet without matched binding is received 1568 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1570 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1571 received 1573 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1574 received 1576 7.7. Initial State: state RECOVERY - The SAVI device is querying the 1577 assignment and lease time of the address in the entry through DHCP 1578 Leasequery 1580 7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 1581 LEASEQUERY-REPLY is received 1583 IPv4 address: 1585 (1) Send an ARP Request with the Target Protocol Address set to the 1586 IP address in the corresponding entry. The ARP Request is only 1587 sent to the attachment which triggers the binding. If there is 1588 no response after DETECTION_TIMEOUT, send another ARP Request. 1589 If there is still no response, remove the entry. 1591 (2) If there is only one identical response, get the sender hardware 1592 address. Check if the 'chaddr' field (hardware address) of the 1593 DHCPLEASEACTIVE message matches the sender hardware address. If 1594 the two addresses do not match, the following actions will not be 1595 performed. If there is more than one response, if any of the 1596 sender hardware addresses matches the 'chaddr' field (hardware 1597 address) of the DHCPLEASEACTIVE message, 1599 * Set life time to the sum of the value encoded in IP Address 1600 Lease Time option of the DHCPLEASEACTIVE message and 1601 MAX_DHCP_RESPONSE_TIME. 1603 * Erase the TID field. 1605 IPv6 address: 1607 (1) Send a Neighbor Solicitation message with the target address set 1608 to the IP address in the corresponding entry. The Neighbor 1609 Solicitation is only sent to the attachment which triggers the 1610 binding. If there is no response after DETECTION_TIMEOUT, send 1611 another Neighbor Solicitation. If there is still no response, 1612 remove the entry. 1614 (2) On receipt of a valid Neighbor Announcement, 1616 * Set the lifetime to the sum of the valid lifetime extracted 1617 from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY 1618 message and MAX_DHCP_RESPONSE_TIME. 1620 * Erase the TID field. 1622 * After the above checks, if multiple addresses are specified 1623 in the LEASEQUERY-REPLY message and there are no 1624 corresponding binding entries, new entries MUST also be 1625 created correspondingly on the same binding anchor. 1627 In the event that responses are received from multiple DHCP servers, 1628 the conflict resolution mechanisms specified in section 6.8 of 1629 [RFC4388] and section 4.3.4 of [RFC5007] will be used to determine 1630 which message should be used. 1632 Resulting state: if ARP or ND succeeds (there is a valid response), 1633 BOUND - The binding has been set up. Otherwise, the resulting state 1634 is NO_BIND - No binding has been set up 1636 7.7.2. Event: EVE_ENTRY_EXPIRE 1638 Remove the entry. 1640 Resulting state: NO_BIND - No binding has been set up 1642 7.7.3. Events not observed in RECOVERY 1644 EVE_DATA_UNMATCH: A data packet without matched binding is received 1646 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1647 received from unexpected system 1649 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received 1651 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1652 received 1654 7.8. Initial State: state BOUND - The binding has been set up 1656 Upon entry to the state BOUND, control the system continues as if a 1657 DHCP message assigning the address has been observed, as in 1658 Section 6.4.3. The BST entry has been restored. 1660 Note that the TID field contains no value after the binding state 1661 changes to BOUND. The TID field is recovered from snooping DHCP 1662 Renew/Rebind messages. Because TID is used to associate binding 1663 entries with messages from DHCP servers, it must be recovered; or 1664 else a number of state transits of this mechanism will be not 1665 executed normally. 1667 7.9. Table of State Machine 1669 The main state transits are listed as follows. 1671 State Event Action Next State 1672 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1673 DETECTION EVE_ENTRY_EXPIRE Send Leasequery RECOVERY 1674 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1675 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND 1676 RECOVERY EVE_ENTRY_EXPIRE Remove entry NO_BIND 1677 BOUND RENEW/REBIND Record TID BOUND 1679 Figure 13: Table of Transit 1681 RENEW: EVE_DHCP_RENEW 1683 REBIND: EVE_DHCP_REBIND 1685 +-------------+ 1686 | | 1687 /---------| NO_BIND |<--------\ 1688 | ------>| | | EVE_ENTRY_EXPIRE 1689 | | +-------------+ |(2nd LQ_DELAY) 1690 EVE_DATA_UNMATCH | | | 1691 | | | 1692 1st | | | 1693 DETECTION_TIMEOUT | | | 1st LQ_DELAY 1694 /------\ | | | /---------\ 1695 | | | | EVE_DATA_CONFLICT | | | 1696 | v v | | v | 1697 | +-------------+ EVE_ENTRY_EXPIRE +------------+ | 1698 | | |(2nd DETECTION_TIMEOUT) | | | 1699 \----| DETECTION ------------------------>| RECOVERY ----/ 1700 | | | | 1701 +-------------+ +------------+ 1702 EVE_DATA_LEASEQUERY| 1703 /----------\ (+ 2x DETECTION) | 1704 EVE_DHCP_RENEW| | | 1705 EVE_DHCP_REBIND| +-----v-------+ | 1706 | | | | 1707 \----| BOUND |<----------/ 1708 | | 1709 +-------------+ 1711 Figure 14: Diagram of Transit 1713 LQ_DELAY: MAX_LEASEQUERY_DELAY 1715 8. Filtering Specification 1717 This section specifies how to use bindings to filter out packets with 1718 spoofed source addresses. 1720 Filtering policies are different for data packets and control 1721 packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861] 1722 messages are classified as control packets. All other packets are 1723 classified as data packets. 1725 8.1. Data Packet Filtering 1727 Data packets from attachments with the Validating attribute TRUE MUST 1728 be checked. There is one exception to this rule. 1730 A packet whose source IP address is a link-local address cannot be 1731 checked against DHCP assignments, as it is not assigned using DHCP. 1732 Note: as explained in Section 1, a SAVI solution for link-local 1733 addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to check 1734 packets with a link-local source address. 1736 If the source IP address of a packet is not a link-local address, but 1737 there is not a matching entry in BST with state BOUND, this packet 1738 MUST be discarded. However, the packet may trigger the Data Snooping 1739 Process Section 7 if the Data-Snooping attribute is set on the 1740 attachment. 1742 Data packets from an attachment with the VALIDATING attribute set 1743 FALSE will be forwarded without being validated. 1745 The SAVI device MAY log packets that fail source address validation. 1747 8.2. Control Packet Filtering 1749 For attachments with the Validating attribute: 1751 DHCPv4 Client-Server messages in which the source IP address is 1752 neither all zeros nor bound with the corresponding binding anchor in 1753 the BST MUST be discarded. 1755 DHCPv6 Client-Server messages in which the source IP address is 1756 neither a link-local address nor bound with the corresponding binding 1757 anchor in the BST MUST be discarded. 1759 NDP messages in which the source IP address is neither a link-local 1760 address nor bound with the corresponding binding anchor MUST be 1761 discarded. 1763 NA messages in which the target address is neither a link-local 1764 address nor bound with the corresponding binding anchor MUST be 1765 discarded. 1767 ARP messages in which the protocol is IP and sender protocol address 1768 is neither all zeros address nor bound with the corresponding binding 1769 anchor MUST be discarded. 1771 ARP Reply messages in which the target protocol address is not bound 1772 with the corresponding binding anchor MUST be discarded. 1774 For attachments with other attributes: 1776 DHCP Server-to-Client messages not from attachments with the DHCP- 1777 Trust attribute or Trust attribute MUST be discarded. 1779 For attachments with no attribute: 1781 DHCP Server-to-Client messages from such attachments MUST be 1782 discarded. 1784 The SAVI device MAY record any messages that are discarded. 1786 9. State Restoration 1788 If a SAVI device reboots, the information kept in volatile memory 1789 will be lost. This section specifies the restoration of attribute 1790 configuration and BST. 1792 9.1. Attribute Configuration Restoration 1794 The loss of attribute configuration will not break the network: no 1795 action will be performed on traffic from attachments with no 1796 attribute. However, the loss of attribute configuration makes this 1797 SAVI function unable to work. 1799 To avoid the loss of binding anchor attribute configuration, the 1800 configuration MUST be able to be stored in non-volatile storage. 1801 After the reboot of SAVI device, if the configuration of binding 1802 anchor attribute can be found in non-volatile storage, the 1803 configuration MUST be used. 1805 9.2. Binding State Restoration 1807 The loss of binding state will cause the SAVI devices discard 1808 legitimate traffic. Purely using the Data Snooping Process to 1809 recover a large number of bindings is of heavy overhead and 1810 considerable delay. Thus, to recover bindings from non-volatile 1811 storage, as specified below, is RECOMMENDED. 1813 Binding entries MAY be saved into non-volatile storage whenever a new 1814 binding entry changes to BOUND state. If a binding with BOUND state 1815 is removed, the saved entry MUST be removed correspondingly. The 1816 time when each binding entry is established is also saved. 1818 Immediately after reboot, the SAVI device SHOULD restore binding 1819 states from the non-volatile storage. The system time of save 1820 process MUST be stored. After rebooting, the SAVI device MUST check 1821 whether each entry has been obsolete by comparing the saved lifetime 1822 and the difference between the current time and time when the binding 1823 entry is established. 1825 10. Constants 1827 The following constants are recommended for use in this context: 1829 o MAX_DHCP_RESPONSE_TIME 120s (SOL_MAX_RT from [RFC3315]) 1831 o MAX_LEASEQUERY_DELAY 10s (LQ_MAX_RT from [RFC5007]) 1833 o DETECTION_TIMEOUT 0.5s (TENT_LT from [RFC6620]) 1835 o DATA_SNOOPING_INTERVAL 60s and configurable (recommendation) 1837 o OFFLINK_DELAY 30s (recommendation) 1839 11. Security Considerations 1841 11.1. Security Problems about the Data Snooping Process 1843 There are two security problems about the Data Snooping Process 1844 Section 7: 1846 (1) The Data Snooping Process is costly, but an attacker can trigger 1847 it simply through sending a number of data packets. To avoid 1848 Denial of Services attack against the SAVI device itself, the 1849 Data Snooping Process MUST be rate limited. A constant 1850 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1851 Data Snooping Processes on one attachment MUST be separated by a 1852 minimum interval time DATA_SNOOPING_INTERVAL. If this value is 1853 changed, the value needs to be large enough to minimize denial of 1854 service attacks. 1856 (2) The Data Snooping Process may set up incorrect bindings if the 1857 clients do not reply to the detection probes Section 7.5.1. An 1858 attack will pass the duplicate detection if the client assigned 1859 the target address does not reply to the detection probes. The 1860 DHCP Lease query procedure performed by the SAVI device just 1861 tells whether the address is assigned in the network or not. 1862 However, the SAVI device cannot determine whether the address is 1863 just assigned to the triggering attachment from the DHCP 1864 LEASEQUERY Reply. 1866 11.2. Client departure issues 1868 After a binding is set up, the corresponding client may leave its 1869 attachment point. It may depart temporarily due to signal fade, or 1870 permanently by moving to a new attachment point or leaving the 1871 network. In the signal fade case, since the client may return 1872 shortly, the binding should be kept momentarily, lest legitimate 1873 traffic from the client be blocked. However, if the client leaves 1874 permanently, keeping the binding can be a security issue. If the 1875 binding anchor is a property of the attachment point rather than the 1876 client, e.g., the switch port but not incorporating the MAC Address, 1877 an attacker using the same binding anchor can send packets using IP 1878 addresses assigned to the client. Even if the binding anchor is a 1879 property of the client, retaining binding state for a departed client 1880 for a long time is a waste of resources. 1882 Whenever a direct client departs from the network, a link-down event 1883 associated with the binding anchor will be triggered. SAVI-DHCP 1884 monitors such events, and performs the following mechanism. 1886 (1) Whenever a client with the Validating attribute leaves, a timer 1887 of duration OFFLINK_DELAY is set on the corresponding binding 1888 entries. 1890 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 1891 received that targets the address during OFFLINK_DELAY, the entry 1892 MAY be removed. 1894 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 1895 timer. 1897 In this way, the bindings of a departing client are kept for 1898 OFFLINK_DELAY. In case of link flapping, the client will not be 1899 blocked. If the client leaves permanently, the bindings will be 1900 removed after OFFLINK_DELAY. 1902 SAVI-DHCP does not handle the departure of indirect clients, because 1903 it will not be notified of such events. Switches supporting indirect 1904 attachment (e.g., through a separate non-SAVI switch) SHOULD use 1905 information specific to the client such as its MAC address as part of 1906 the binding anchor. 1908 11.3. Duplicate Bindings to the Same Address 1910 The same address may be bound to multiple binding anchors only if the 1911 binding setup processes successfully complete for each binding 1912 anchor. This mechanism is designed to address the case where a 1913 client moves on the local link, and the case where a client has 1914 multiple attachments to a SAVI device. 1916 There are two security issues with such a design: 1918 First, by allowing one address to be bound to multiple binding 1919 anchors, the traceability of the address is weakened. An address can 1920 be traced to multiple attachments. 1922 Second, in the local link movement scenario, the former binding may 1923 not be removed and it can be used by an attacker sharing the same 1924 binding anchor. For example, when a switch port is used as binding 1925 anchor and the port is shared by an attacker and a client with a hub, 1926 the attacker can make use of the address assigned to the client after 1927 the client leaves. 1929 11.4. Compatibility with DNA (Detecting Network Attachment) 1931 DNA [RFC4436][RFC6059] is designed to decrease the handover latency 1932 after re-attachment to the same network. DNA mainly relies on 1933 performing reachability test by sending unicast Neighbor Solicitation 1934 /Router Solicitation/ARP Request message to determine whether a 1935 previously configured address is still valid. 1937 Although DNA provides optimization for clients, there is insufficient 1938 information for this mechanism to migrate the previous binding or 1939 establish a new binding. If a binding is set up only by snooping the 1940 reachability test message, the binding may be invalid. For example, 1941 an attacker can perform reachability test with an address bound to 1942 another client. If binding is migrated to the attacker, the attacker 1943 can successfully obtain the binding from the victim. Because this 1944 mechanism wouldn't set up a binding based on snooping the DNA 1945 procedure, it cannot achieve perfect compatibility with DNA. 1946 However, it only means the re-configuration of the interface is 1947 slowed but not prevented. Details are discussed as follows. 1949 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1950 set to a link-local address, and such messages will not be discarded 1951 by the policy specified in Section 8.2. If a client is re-attached 1952 to a previous network, the detection will be completed, and the 1953 address will be regarded as valid by the client. However, the 1954 candidate address is not contained in the probe. Thus, the binding 1955 cannot be recovered through snooping the probe. As the client will 1956 perform DHCP exchange at the same time, the binding will be recovered 1957 from the DHCP Snooping Process. The DHCP Request messages will not 1958 be filtered out in this case because they have link-local source 1959 addresses. Before the DHCP procedure is completed, packets will be 1960 filtered out by the SAVI device. In other words, if this SAVI 1961 function is enabled, Simple DNAv6 will not help reduce the handover 1962 latency. If Data-Snooping attribute is configured on the new 1963 attachment of the client, the data triggered procedure may reduce 1964 latency. 1966 In DNAv4 [RFC4436], the ARP probe will be discarded because an 1967 unbound address is used as the sender protocol address. As a result, 1968 the client will regard the address under detection is valid. 1969 However, the data traffic will be filtered. The DHCP Request message 1970 sent by the client will not be discarded, because the source IP 1971 address field should be all zero as required by [RFC2131]. Thus, if 1972 the address is still valid, the binding will be recovered from the 1973 DHCP Snooping Process. 1975 11.5. Binding Number Limitation 1977 A binding entry will consume a certain high-speed memory resources. 1978 In general, a SAVI device can afford only a quite limited number of 1979 binding entries. In order to prevent an attacker from overloading 1980 the resource of the SAVI device, a binding entry limit is set on each 1981 attachment. The binding entry limit is the maximum number of 1982 bindings supported on each attachment with Validating attribute. No 1983 new binding should be set up after the limit has been reached. If a 1984 DHCP Reply assigns more addresses than the remaining binding entry 1985 quota of each client, the message will be discarded and no binding 1986 will be set up. 1988 11.6. Privacy Considerations 1990 A SAVI device MUST delete binding anchor information as soon as 1991 possible (i.e., as soon as the state for a given address is back to 1992 NO_BIND), except where there is an identified reason why that 1993 information is likely to be involved in the detection, prevention, or 1994 tracing of actual source address spoofing. Information about the 1995 majority of hosts that never spoof SHOULD NOT be logged. 1997 12. IANA Considerations 1999 This memo asks the IANA for no new parameters. 2001 13. Acknowledgment 2003 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 2004 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 2005 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 2006 Garcia for careful review and valuation comments on the mechanism and 2007 text. 2009 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 2010 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 2011 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 2012 their valuable contributions. 2014 This document was generated using the xml2rfc tool. 2016 14. References 2018 14.1. Normative References 2020 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2021 converting network protocol addresses to 48.bit Ethernet 2022 address for transmission on Ethernet hardware", STD 37, 2023 RFC 826, November 1982. 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2026 Requirement Levels", BCP 14, RFC 2119, March 1997. 2028 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2029 2131, March 1997. 2031 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2032 and M. Carney, "Dynamic Host Configuration Protocol for 2033 IPv6 (DHCPv6)", RFC 3315, July 2003. 2035 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 2036 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 2038 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 2039 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 2041 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2042 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2043 September 2007. 2045 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 2046 "DHCPv6 Leasequery", RFC 5007, September 2007. 2048 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 2049 July 2008. 2051 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 2052 Detecting Network Attachment in IPv6", RFC 6059, November 2053 2010. 2055 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2056 SAVI: First-Come, First-Served Source Address Validation 2057 Improvement for Locally Assigned IPv6 Addresses", RFC 2058 6620, May 2012. 2060 14.2. Informative References 2062 [I-D.ietf-opsec-dhcpv6-shield] 2063 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 2064 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 2065 opsec-dhcpv6-shield-04 (work in progress), July 2014. 2067 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2068 Defeating Denial of Service Attacks which employ IP Source 2069 Address Spoofing", BCP 38, RFC 2827, May 2000. 2071 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 2072 (DHCP) Service for IPv6", RFC 3736, April 2004. 2074 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 2075 "Source Address Validation Improvement (SAVI) Framework", 2076 RFC 7039, October 2013. 2078 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 2079 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 2080 7341, August 2014. 2082 Authors' Addresses 2084 Jun Bi 2085 Tsinghua University 2086 Network Research Center, Tsinghua University 2087 Beijing 100084 2088 China 2090 EMail: junbi@tsinghua.edu.cn 2091 Jianping Wu 2092 Tsinghua University 2093 Computer Science, Tsinghua University 2094 Beijing 100084 2095 China 2097 EMail: jianping@cernet.edu.cn 2099 Guang Yao 2100 Tsinghua University 2101 Network Research Center, Tsinghua University 2102 Beijing 100084 2103 China 2105 EMail: yaoguang@cernet.edu.cn 2107 Fred Baker 2108 Cisco Systems 2109 Santa Barbara, CA 93117 2110 United States 2112 EMail: fred@cisco.com