idnits 2.17.1 draft-ietf-savi-dhcp-34.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 (February 19, 2015) is 3344 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-05 -- 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: August 23, 2015 Tsinghua Univ. 6 F. Baker 7 Cisco 8 February 19, 2015 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-34 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 August 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Deployment Scenario and Configuration . . . . . . . . . . . . 8 60 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8 61 4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 10 62 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10 63 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 11 64 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11 65 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11 66 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 12 67 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 13 68 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13 70 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14 71 4.3.3. On the Placement of the DHCP Server and Relay . . . . 15 72 4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15 73 4.3.5. Considerations regarding Binding Anchors . . . . . . 16 74 4.4. Other Device Configuration . . . . . . . . . . . . . . . 17 75 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17 76 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18 77 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18 78 6.2. Binding States Description . . . . . . . . . . . . . . . 19 79 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19 81 6.3.2. Control Message Arriving Events . . . . . . . . . . . 19 82 6.4. The State Machine of DHCP Snooping Process . . . . . . . 21 83 6.4.1. Initial State: NO_BIND - No binding has been set up . 21 84 6.4.2. Initial State: INIT_BIND - A potential binding has 85 been set up . . . . . . . . . . . . . . . . . . . . . 23 86 6.4.3. Initial State: BOUND - The binding has been set up . 26 87 6.4.4. Table of State Machine . . . . . . . . . . . . . . . 29 88 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 30 89 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 31 90 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 32 91 7.3. Additional Binding States Description . . . . . . . . . . 32 92 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 7.5. Message Sender Functions . . . . . . . . . . . . . . . . 34 94 7.5.1. Duplicate Detection Message Sender . . . . . . . . . 34 95 7.5.2. Lease Query Message Sender . . . . . . . . . . . . . 35 96 7.5.3. Address Verification Message Sender . . . . . . . . . 36 98 7.6. Initial State: state NO_BIND - No binding has been set up 36 99 7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a 100 matched binding is received . . . . . . . . . . . . . 36 101 7.6.2. Events not observed in NO_BIND for data snooping . . 37 102 7.7. Initial State: state DETECTION - The address in the entry 103 is undergoing local duplication detection . . . . . . . . 38 104 7.7.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 38 105 7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor 106 Advertisement(NA) message received from unexpected 107 system . . . . . . . . . . . . . . . . . . . . . . . 39 108 7.7.3. Events not observed in DETECTION . . . . . . . . . . 39 109 7.8. Initial State: state RECOVERY - The SAVI device is 110 querying the assignment and lease time of the address in 111 the entry through DHCP Leasequery . . . . . . . . . . . . 39 112 7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE 113 or successful LEASEQUERY-REPLY is received . . . . . 39 114 7.8.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 40 115 7.8.3. Events not observed in RECOVERY . . . . . . . . . . . 40 116 7.9. Initial State: state VERIFY - Verification of the use of 117 the source IP address by the device interface attached to 118 the SAVI device . . . . . . . . . . . . . . . . . . . . . 41 119 7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE 120 or successful LEASEQUERY-REPLY is received . . . . . 41 121 7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is 122 received from the device attached via the binding 123 anchor . . . . . . . . . . . . . . . . . . . . . . . 41 124 7.9.3. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 42 125 7.9.4. Event: EVE_DATA_EXPIRE . . . . . . . . . . . . . . . 42 126 7.9.5. Events not observed in VERIFY . . . . . . . . . . . . 42 127 7.10. Initial State: state BOUND - The binding has been set up 42 128 7.11. Table of State Machine . . . . . . . . . . . . . . . . . 43 129 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 44 130 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 45 131 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 45 132 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 46 133 9.1. Attribute Configuration Restoration . . . . . . . . . . . 46 134 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 46 135 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 47 136 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 137 11.1. Security Problems about the Data Snooping Process . . . 47 138 11.2. Securing Lease Query Operations . . . . . . . . . . . . 48 139 11.3. Client departure issues . . . . . . . . . . . . . . . . 48 140 11.4. Compatibility with DNA (Detecting Network Attachment) . 49 141 11.5. Binding Number Limitation . . . . . . . . . . . . . . . 50 142 11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 50 143 11.7. Fragmented DHCP Messages . . . . . . . . . . . . . . . . 50 144 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 145 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 51 146 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 147 14.1. Normative References . . . . . . . . . . . . . . . . . . 51 148 14.2. Informative References . . . . . . . . . . . . . . . . . 52 150 1. Introduction 152 This document describes a fine-grained source address validation 153 mechanism for IPv4 and IPv6 packets. This mechanism creates bindings 154 between IP addresses assigned to network interfaces by DHCP and 155 suitable binding anchors (Section 4.3.5). As discussed in Section 3 156 and [RFC7039], a "binding anchor" is an attribute that is immutable 157 or difficult to change that may be used to identify the system an IP 158 address has been assigned to; common examples include a MAC address 159 found on an Ethernet switch port or WiFi security association. The 160 bindings are used to identify and filter packets originated by these 161 interfaces using forged source IP addresses. In this way, this 162 mechanism can prevent hosts from using IP addresses assigned to any 163 other attachment point in or not associated with the network. This 164 behavior is referred to as "spoofing", and is key to amplification 165 attacks, in which a set of systems send messages to another set of 166 systems claiming to be from a third set of systems, and sending the 167 replies to systems that don't expect them. Whereas BCP 38 [RFC2827] 168 protects a network from a neighboring network by providing prefix 169 granularity source IP address validity, this mechanism protects a 170 network, including a Local Area Network, from itself by providing 171 address granularity source IP validity when DHCP/DHCPv6 is used to 172 assign IPv4/IPv6 addresses. Both provide a certain level of 173 traceability, in that packet drops indicate the presence of a system 174 that is producing packets with spoofed IP addresses. 176 SAVI-DHCP snoops DHCP address assignments to set up bindings between 177 IP addresses assigned by DHCP and corresponding binding anchors. It 178 includes the DHCPv4 and v6 snooping process (Section 6), the Data 179 Snooping process (Section 7), as well as a number of other technical 180 details. The Data Snooping process is a data-triggered procedure 181 that snoops the IP header of data packets to set up bindings. It is 182 designed to avoid a permanent blockage of valid addresses in the case 183 that DHCP snooping is insufficient to set up all the valid bindings. 185 This mechanism is designed for the stateful DHCP scenario [RFC2131], 186 [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this 187 document, as it has nothing to do with IP address allocation. An 188 alternative SAVI method would have be used in those cases. For hosts 189 using Stateless Address Auto-Configuration (SLAAC) to allocate 190 addresses, SAVI-FCFS [RFC6620] should be enabled. SAVI-DHCP is 191 primarily designed for pure DHCP scenarios in which only addresses 192 assigned through DHCP are allowed. However, it does not block link- 193 local addresses, as they are not assigned using DHCP. It is 194 RECOMMENDED that the administration deploy a SAVI solution for link- 195 local addresses, e.g., SAVI-FCFS [RFC6620]. 197 This mechanism works for networks that use DHCPv4 only, DHCPv6 only, 198 or both DHCPv4 and DHCPv6. However, the DHCP address assignment 199 mechanism in IPv4/IPv6 transition scenarios, e.g., [RFC7341], are 200 beyond the scope of this document. 202 2. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in RFC 2119 [RFC2119]. 208 3. Terminology 210 Binding anchor: A "binding anchor" is defined to be a physical and/or 211 link-layer property of an attached device, as in [RFC7039]. A list 212 of sample binding anchors can be found in Section 3.2 of that 213 document. To the degree possible, a binding anchor associates an IP 214 address with something unspoofable that identifies a single client 215 system or one of its interfaces. See Section 4.3.5 for more detail. 217 Attribute: A configurable property of each binding anchor (port, MAC 218 Address, or other information) that indicates the actions to be 219 performed on packets received from the attached network device. 221 DHCP address: An IP address assigned via DHCP. 223 SAVI-DHCP: The name of this SAVI function for DHCP-assigned 224 addresses. 226 SAVI device: A network device on which SAVI-DHCP is enabled. 228 Non-SAVI device: A network device on which SAVI-DHCP is not enabled. 230 DHCP Client-Server message: A message that is sent from a DHCP client 231 to a DHCP server or DHCP servers. Such a message is of one of the 232 following types: 234 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 236 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 237 [RFC2131] 239 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 240 [RFC2131] 242 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 243 [RFC2131] 245 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 246 [RFC2131] 248 o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be 249 identified based on the Table 4 of [RFC2131] 251 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 253 o DHCPv4 Release: DHCPRELEASE [RFC2131] 255 o DHCPv4 Inform: DHCPINFORM [RFC2131] 257 o DHCPv4 DHCPLEASEQUERY: A message sent to enquire about the lease 258 that might exist for an IPv4 address. [RFC4388] 260 o DHCPv6 Request: REQUEST [RFC3315] 262 o DHCPv6 Solicit: SOLICIT [RFC3315] 264 o DHCPv6 Confirm: CONFIRM [RFC3315] 266 o DHCPv6 Decline: DECLINE [RFC3315] 268 o DHCPv6 Release: RELEASE [RFC3315] 270 o DHCPv6 Rebind: REBIND [RFC3315] 272 o DHCPv6 Renew: RENEW [RFC3315] 274 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 276 o DHCPv6 LEASEQUERY: A message sent to enquire about the lease that 277 might exist for an IPv6 address. [RFC5007] 279 DHCP Server-to-Client message: A message that is sent from a DHCP 280 server to a DHCP client. Such a message is of one of the following 281 types: 283 o DHCPv4 ACK: DHCPACK [RFC2131] 285 o DHCPv4 NAK: DHCPNAK [RFC2131] 287 o DHCPv4 Offer: DHCPOFFER [RFC2131] 288 o DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request 289 containing lease information. [RFC4388] 291 o DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request 292 indicating that the server does not manage the address. [RFC4388] 294 o DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY request 295 indicating that the server manages the address and there is no 296 current lease. [RFC4388] 298 o DHCPv6 Reply: REPLY [RFC3315] 300 o DHCPv6 Advertise: ADVERTISE [RFC3315] 302 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 304 o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request. 305 [RFC5007] 307 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 308 IPv6 [RFC3315]. 310 Binding entry: A rule that associates an IP address with a binding 311 anchor. 313 Binding State Table (BST): The data structure that contains the 314 binding entries. 316 Binding entry limit: The maximum number of binding entries that may 317 be associated with a binding anchor. Limiting the number of binding 318 entries per binding anchor prevents a malicious or malfunctioning 319 node from overloading the binding table on a SAVI device. 321 Direct attachment: Ideally, a SAVI device is an access device that 322 hosts are attached to directly. In such a case, the hosts are direct 323 attachments (i.e., they attach directly) to the SAVI device. 325 Indirect attachment: A SAVI device MAY be an aggregation device that 326 other access devices are attached to, and which hosts in turn attach 327 to. In such a case, the hosts are indirect attachments (i.e., they 328 attach indirectly) to the SAVI device. 330 Unprotected link: Unprotected links are links that connect to hosts 331 or networks of hosts receive their DHCP traffic by another path, and 332 are therefore outside the SAVI perimeter. 334 Unprotected device: An unprotected device is a device associated with 335 an unprotected link. One example might be the gateway router of a 336 network. 338 Protected link: If DHCP messages for a given attached device always 339 use a given link, the link is considered to be "protected" by the 340 SAVI Device, and is therefore within the SAVI perimeter. 342 Protected device: A protected device is a device associated with a 343 protected link. One example might be a desktop switch in the 344 network, or a host. 346 Cut Vertex: A cut vertex is any vertex whose removal increases the 347 number of connected components in a (network) graph. This is a 348 concept in graph theory. This term is used in Section 6.1 to 349 accurately specify the required deployment location of SAVI devices 350 when they only perform the DHCP Snooping Process. 352 Identity Association (IA): "A collection of addresses assigned to a 353 client." [RFC3315] 355 Detection message: a Neighbor Solicitation or ARP message intended by 356 the Data Snooping Process to detect a duplicate address. 358 DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the 359 binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease 360 query exchange [RFC5007] cannot be performed by the SAVI device to 361 fetch the lease. 363 4. Deployment Scenario and Configuration 365 4.1. Elements and Scenario 367 The essential elements in a SAVI-DHCP deployment scenario include at 368 least one DHCP server (which may or may not be assigned an address 369 using DHCP, and therefore may or may not be protected), zero or more 370 protected DHCP clients, and one or more SAVI devices. It may also 371 include DHCP relays, when the DHCP server is not co-located with a 372 set of clients, and zero or more protected Non-SAVI devices. Outside 373 the perimeter, via unprotected links, there may be many unprotected 374 devices. 376 +-------------+ 377 | unprotected | 378 | device | 379 +------+------+ 380 | 381 +--------+ +-----+------+ +----------+ 382 |DHCP +-----+ Non-SAVI +----+Bogus DHCP| 383 |Server A| | Device 1 | |Server | 384 +--------+ +-----+------+ +----------+ 385 |trusted, unprotected link 386 . . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . . 387 . | . 388 . Protection +---+------+ trusted link . 389 . Perimeter | SAVI +--------------+ . 390 . | Device C| | . 391 . +---+------+ | . 392 . | | . 393 . untrusted, +----------+ +---+------+ +------+---+ . 394 . protected | SAVI | | Non SAVI| | SAVI | . 395 . link+------+ Device A+----+ Device 3+-------+ Device B| . 396 . | +----+--+--+ +----------+ +-+---+----+ . 397 . | | +----------+ . . . . . | | . 398 . | . . . . . . | . . | | . 399 . | . | . | . +--------+ | . 400 . +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ . 401 . | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | . 402 . | Device 2 |. |A | . |Relay | . |B | . |Server B| . 403 . +----------+. +------+ . +------+ . +------+ . +--------+ . 404 . . . . . . . . . . . . . . . . . . . 406 Figure 1: SAVI-DHCP Scenario 408 Figure 1 shows a deployment scenario that contains these elements. 409 Note that a physical device can instantiate multiple elements, e.g., 410 a switch can be both a SAVI device and a DHCP relay, or in a cloud 411 computing environment, a physical host may contain a virtual switch 412 plus some number of virtual hosts. In such cases, the links are 413 logical links rather than physical links. 415 Networks are not usually isolated. As a result, traffic from other 416 networks, including transit traffic as specified in [RFC6620] (e.g., 417 traffic from another SAVI switch or a router) may enter a SAVI-DHCP 418 network through the unprotected links. Since SAVI solutions are 419 limited to validating traffic generated from a local link, SAVI-DHCP 420 does not set up bindings for addresses assigned in other networks and 421 cannot validate them. Traffic from unprotected links should be 422 checked by an unprotected device or [RFC2827] mechanisms. The 423 generation and deployment of such a mechanism is beyond the scope of 424 this document. 426 Traffic from protected links is, however, locally generated, and 427 should have its source addresses validated by SAVI-DHCP if possible. 428 In the event that there is an intervening protected non-SAVI device 429 between the host and the SAVI device, however, use of the physical 430 attachment point alone as a binding anchor is insufficiently secure, 431 as the several devices on a port or other point of attachment can 432 spoof each other. Hence, additional information such as a MAC 433 address SHOULD be used to disambiguate them. 435 4.2. SAVI Binding Type Attributes 437 As illustrated in Figure 1, a system attached to a SAVI device can be 438 a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI 439 device. Different actions are performed on traffic originated from 440 different elements. To distinguish among their requirements, several 441 properties are associated with their point of attachment on the SAVI 442 device. 444 When a binding association is uninstantiated, e.g., when no host is 445 attached to the SAVI device using a given port or other binding 446 anchor, the binding port attributes take default values unless 447 overridden by configuration. By default, a SAVI switch does not 448 filter DHCP messages, nor does it attempt to validate source 449 addresses, which is to say that the binding attributes are ignored 450 until SAVI-DHCP is itself enabled. This is because a SAVI switch 451 that depends on DHCP cannot tell, a priori, which ports have valid 452 DHCP servers attached, or which have routers or other equipment that 453 would validly appear to use an arbitrary set of source addresses. 454 When SAVI has been enabled, the attributes take effect. 456 4.2.1. Trust Attribute 458 The "Trust Attribute" is a Boolean value. If TRUE, it indicates that 459 the packets from the corresponding attached device need not have 460 their source addresses validated. Examples of a trusted attachment 461 would be a port to another SAVI device, or to an IP router, as shown 462 in Figure 1. In both cases, traffic using many source IP addresses 463 will be seen. By default, the Trust attribute is FALSE, indicating 464 that any device found on that port will seek an address using DHCP 465 and be limited to using such addresses. 467 SAVI devices will not set up bindings for points of attachment with 468 the Trust attribute set TRUE; no packets, including DHCP messages, 469 from devices with this attribute on their attachments will be 470 validated. However DHCP Server-to-Client messages will be snooped on 471 attachment points with the Trust attribute set TRUE in the same way 472 as if they had the DHCP-Trust attribute set (see Section 4.2.2.) 474 4.2.2. DHCP-Trust Attribute 476 The "DHCP-Trust Attribute" is similarly a Boolean attribute. It 477 indicates whether the attached device is permitted to initiate DHCP 478 Server-to-Client messages. In Figure 1, the points of attachment of 479 the DHCP Server and the DHCP Relay would have this attribute set 480 TRUE, and attachment points that have Trust set TRUE are implicitly 481 treated as if DHCP-Trust is TRUE.. 483 If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP 484 Server-to-Client messages from the points of attachment with this 485 attribute. If the DHCP Server-to-Client messages can trigger the 486 state transitions, the binding setup processes specified in Section 6 487 and Section 7 will handle them. By default, the DHCP-Trust attribute 488 is FALSE, indicating that the attached system is not a DHCP server. 490 A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for 491 more details. 493 4.2.3. DHCP-Snooping Attribute 495 The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It 496 indicates whether bindings will be set up based on DHCP snooping. 498 If this attribute is TRUE, DHCP Client-Server messages to points of 499 attachment with this attribute will trigger creation of bindings 500 based on the DHCP Snooping Process described in Section 6. If it is 501 FALSE, either the Trust attribute must be TRUE (so that bindings 502 become irrelevant) or another SAVI mechanism such as SAVI-FCFS must 503 be used on the point of attachment. 505 The DHCP-Snooping attribute is configured on the DHCP Client's point 506 of attachment. This attribute can be also used on the attachments to 507 protected Non-SAVI devices that are used by DHCP clients. In 508 Figure 1, the attachment from the Client A to the SAVI Device A, the 509 attachment from the Client B to the SAVI Device B, and the attachment 510 from the Non-SAVI Device 2 to the SAVI Device A can be configured 511 with this attribute. 513 4.2.4. Data-Snooping Attribute 515 The "Data-Snooping Attribute" is a Boolean attribute. It indicates 516 whether data packets from the corresponding point of attachment may 517 trigger the binding setup procedure. 519 Data packets from points of attachment with this attribute may 520 trigger the setup of bindings. SAVI devices will set up bindings on 521 points of attachment with this attribute based on the data-triggered 522 process described in Section 7. 524 If the DHCP-Snooping attribute is configured on a point of 525 attachment, the bindings on this attachment are set up based on DHCP 526 message snooping. However, in some scenarios, a DHCP client may use 527 a DHCP address without the DHCP address assignment procedure being 528 performed on its current attachment. For such attached devices, the 529 Data Snooping Process, which is described in Section 7, is necessary. 530 This attribute is configured on such attachments. The usage of this 531 attribute is further discussed in Section 7. 533 Since some networks require DHCP deployment and others avoid it, 534 there is no obvious universal default value for the Data-Snooping 535 Attribute. Hence, the Data-Snooping Attribute should default to 536 FALSE, and a mechanism should be implemented to conveniently set it 537 to TRUE on all points of attachment for which the Trust attribute is 538 FALSE. 540 4.2.5. Validating Attribute 542 The "Validating Attribute" is a Boolean attribute. It indicates 543 whether packets from the corresponding attachment will have their IP 544 source addresses validated based on binding entries on the 545 attachment. 547 If it is TRUE, packets coming from attachments with this attribute 548 will be validated based on binding entries on the attachment as 549 specified in Section 8. If it is FALSE, they will not. Since the 550 binding table is used in common with other SAVI algorithms, it merely 551 signifies whether the check will be done, not whether it will be done 552 for SAVI-DHCP originated bindings. 554 This attribute is by default the inverse of the Trust attribute; 555 source addresses on untrusted links are validated by default. It MAY 556 be set FALSE by the administration. 558 The expected use case is when SAVI is used to monitor but not block 559 forged transmissions. The network manager, in that case, may set the 560 DHCP-Snooping and/or Data-Snooping attribute TRUE but the Validating 561 attribute FALSE. 563 4.2.6. Table of Mutual Exclusions 565 Different types of attributes may indicate mutually exclusive actions 566 on a packet. Mutually exclusive attributes MUST NOT be set TRUE on 567 the same attachment. The compatibility of different attributes is 568 listed in Figure 2. Note that although Trust and DHCP-Trust are 569 compatible, there is no need to configure DHCP-Trust to TRUE on an 570 attachment with Trust attribute TRUE. 572 +----------+----------+----------+----------+----------+----------+ 573 | | | | DHCP- | Data- | | 574 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 575 +----------+----------+----------+----------+----------+----------+ 576 | | | | mutually | mutually | mutually | 577 | Trust | - |compatible| exclusive| exclusive| exclusive| 578 +----------+----------+----------+----------+----------+----------+ 579 | | | | | | | 580 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 581 +----------+----------+----------+----------+----------+----------+ 582 |DHCP- |mutually | | | | | 583 |Snooping |exclusive |compatible| - |compatible|compatible| 584 +----------+----------+----------+----------+----------+----------+ 585 |Data- |mutually | | | | | 586 |Snooping |exclusive |compatible|compatible| - |compatible| 587 +----------+----------+----------+----------+----------+----------+ 588 | |mutually | | | | | 589 |Validating|exclusive |compatible|compatible|compatible| - | 590 +----------+----------+----------+----------+----------+----------+ 592 Figure 2: Table of Mutual Exclusions 594 4.3. Perimeter 596 4.3.1. SAVI-DHCP Perimeter Overview 598 SAVI devices form a perimeter separating trusted and untrusted 599 regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]). 600 The perimeter is primarily designed for scalability. It has two 601 implications. 603 o SAVI devices only need to establish bindings for directly attached 604 clients, or clients indirectly attached through a non-SAVI 605 protected device, rather than all of the clients in the network. 607 o Each SAVI device only needs to validate the source addresses in 608 traffic from clients attached to it, without checking all the 609 traffic passing by. 611 Consider the example in Figure 1. The protection perimeter is formed 612 by SAVI Devices A, B and C. In this case, SAVI device B does not 613 create a binding for client A. However, because SAVI device A 614 filters spoofed traffic from client A, SAVI device B can avoid 615 receiving spoofed traffic from client A. 617 The perimeter in SAVI-DHCP is not only a perimeter for data packets, 618 but also a perimeter for DHCP messages. DHCP server response 619 messages incoming across the perimeter will be dropped (Section 8). 620 The placement of the DHCP Relay and DHCP Server, which are not 621 involved in [RFC6620], is related to the construction of the 622 perimeter. The requirement on the placement and configuration of 623 DHCP Relay and DHCP Server are discussed in Section 4.3.3. 625 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 627 A perimeter separating trusted and untrusted regions of the network 628 is formed as follows: 630 (1) Configure the Validating and DHCP-Snooping attributes TRUE on 631 the direct attachments of all DHCP clients. 633 (2) Configure the Validating and DHCP-Snooping attributes TRUE on 634 the indirect attachments of all DHCP clients (i.e., DHCP clients 635 on protected links). 637 (3) Configure the Trust attribute TRUE on the attachments to other 638 SAVI devices. 640 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 641 are attached only to SAVI devices, set the Trust attribute TRUE 642 on their attachments. 644 (5) Configure the DHCP-Trust attribute TRUE on the direct 645 attachments to trusted DHCP relays and servers. 647 In this way, the points of attachments with the Validating attribute 648 TRUE (and generally together with attachments of unprotected devices) 649 on SAVI devices can form a perimeter separating DHCP clients and 650 trusted devices. Data packet checks are only performed on the 651 perimeter. The perimeter is also a perimeter for DHCP messages. The 652 DHCP-Trust attribute is only TRUE on links inside the perimeter. 653 Only DHCP Server-to-Client messages originated within the perimeter 654 are trusted. 656 4.3.3. On the Placement of the DHCP Server and Relay 658 As a result of the configuration guidelines, SAVI devices only trust 659 DHCP Server-to-Client messages originated inside the perimeter. 660 Thus, the trusted DHCP Relays and DHCP Servers must be placed within 661 the perimeter. DHCP Server-to-Client messages will be filtered on 662 the perimeter. Server-to-relay messages will not be filtered, as 663 they are within the perimeter. In this way, DHCP Server-to-Client 664 messages from bogus DHCP servers are filtered on the perimeter, 665 having entered through untrusted points of attachment. The SAVI 666 devices are protected from forged DHCP messages. 668 DHCP Server-to-Client messages arriving at the perimeter from outside 669 the perimeter are not trusted. There is no distinction between a 670 DHCP server owned and operated by the correct administration but 671 outside the SAVI perimeter and a bogus DHCP server. For example, in 672 Figure 1, DHCP server A is valid, but it is attached to Non-SAVI 673 device 1. A bogus DHCP server is also attached Non-SAVI device 1. 674 While one could imagine a scenario in which the valid one had a 675 statistically configured port number and MAC address, and therefore a 676 binding, by default SAVI-DHCP cannot distinguish whether a message 677 received from the port of Non-SAVI device 1 is from DHCP server A or 678 the bogus DHCP server. If the DHCP server A is contained in the 679 perimeter, Non-SAVI device 1 will also be contained in the perimeter. 680 Thus, the DHCP server A cannot be contained within the perimeter 681 apart from manual configuration of the binding anchor. 683 Another consideration on the placement is that if the DHCP server/ 684 relay is not inside the perimeter, the SAVI devices may not be able 685 to set up bindings correctly, because the SAVI devices may not be on 686 the path between the clients and the server/relay, or the DHCP 687 messages are encapsulated (e.g., Relay-reply and Relay-forward). 689 4.3.4. An Alternative Deployment 691 In common deployment practice, the traffic from the unprotected 692 network is treated as trustworthy, which is to say that it is not 693 filtered. In such a case, the Trust attribute can be set TRUE on the 694 unprotected link. If Non-SAVI devices, or a number of connected Non- 695 SAVI devices, are only attached to SAVI devices and unprotected 696 devices, their attachment to SAVI devices can have the Trust 697 attribute set TRUE. Then an unclosed perimeter will be formed, as 698 illustrated in Figure 3. 700 | . . Protection | 701 | | | Perimeter | 702 | | | | 703 | Unprotected | | Unprotected | 704 | Link | | Link | 705 | | | | 706 | | | | 707 | +----+---+ +----+---+ +--------+ | 708 | |SAVI +----+Non-SAVI+----+SAVI | | 709 | |Device | |Device | |Device | | 710 | +----+---+ +--------+ +----+---+ | 711 | | | | 712 \_____________+___________________________+________/ 713 | | 714 | | 715 +--------+ +--------+ 716 |DHCP | |DHCP | 717 |Client | |Client | 718 +--------+ +--------+ 720 Figure 3: Alternative Perimeter Configuration 722 4.3.5. Considerations regarding Binding Anchors 724 The strength of this binding-based mechanism depends on the strength 725 of the binding anchor. The sample binding anchors in [RFC7039] have 726 the property that they associate an IP address with a direct physical 727 or secure virtual interface such as a switch port, a subscriber 728 association, or a security association. In addition, especially in 729 the case that a protected non-SAVI device such as a desktop switch or 730 a hub is between the client and SAVI devices, they MAY be extended to 731 also include a MAC address or other link-layer attribute. In short, 732 a binding anchor is intended to associate an IP address with 733 something unspoofable that identifies a single client system or one 734 of its interfaces; this may be a physical or virtual interface or 735 that plus disambiguating link-layer information. 737 If the binding anchor is spoofable, such as a plain MAC address, or 738 non-exclusive, such as a switch port extended using a non-SAVI 739 device, an attacker can use a forged binding anchor to evade 740 validation. Indeed, using a binding anchor that can be easily 741 spoofed can lead to worse outcomes than allowing spoofed IP traffic. 742 Thus, a SAVI device MUST use a non-spoofable and exclusive binding 743 anchor. 745 4.4. Other Device Configuration 747 In addition to a possible binding anchor configuration specified in 748 Section 4.2, an implementation has the following configuration 749 requirements: 751 (1) Address configuration. For DHCPv4: the SAVI device MUST have an 752 IPv4 address. For DHCPv6: the client of a SAVI device MUST have 753 a link-local address; when the DHCPv6 server is not on the same 754 link as the SAVI device, the SAVI device MUST also have an IPv6 755 address of at least the same scope as the DHCPv6 Server. 757 (2) DHCP server address configuration: a SAVI device MUST store the 758 list of the DHCP server addresses that it could contact during a 759 Lease query process. 761 (3) A SAVI device may also require security parameters, such as pre- 762 configured keys to establish a secure connection for the Lease 763 query process [RFC4388][RFC5007] connection. 765 5. Binding State Table (BST) 767 The Binding State Table, which may be implemented centrally in the 768 switch or distributed among its ports, is used to contain the 769 bindings between the IP addresses assigned to the attachments and the 770 corresponding binding anchors of the attachments. Note that in this 771 description, there is a binding entry for each IPv4 or IPv6 address 772 associated with each binding anchor, and there may be several of each 773 such address, especially if the port is extended using a protected 774 non-SAVI device. Each binding entry, has 5 fields: 776 o Binding Anchor(Anchor): the binding anchor, i.e., one or more 777 physical and/ or link-layer properties of the attachment. 779 o IP Address(Address): the IPv4 or IPv6 address assigned to the 780 attachment by DHCP. 782 o State: the state of the binding. Possible values of this field 783 are listed in Section 6.2 and Section 7.3. 785 o Lifetime: the remaining seconds of the binding. Internally, this 786 MAY be stored as the timestamp value at which the lifetime 787 expires. 789 o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the 790 corresponding DHCP transaction. TID field is used to associate 791 DHCP Server-to-Client messages with corresponding binding entries. 793 o Timeouts: the number of timeouts that expired in the current state 794 (only used in Data Snooping Process, see Section 7.) 796 The IA is not present in the BST for three reasons: 798 o The lease of each address in one IA is assigned separately. 800 o When the binding is set up based on data snooping, the IA cannot 801 be recovered from the lease query protocol. 803 o DHCPv4 does not define an IA. 805 An example of such a table is shown in Figure 4. 807 +---------+----------+-----------+-----------+--------+----------+ 808 | Anchor | Address | State | Lifetime | TID | Timeouts | 809 +---------+----------+-----------+-----------+--------+----------+ 810 | Port_1 | IP_1 | BOUND | 65535 | TID_1 | 0 | 811 +---------+----------+-----------+-----------+--------+----------+ 812 | Port_1 | IP_2 | BOUND | 10000 | TID_2 | 0 | 813 +---------+----------+-----------+-----------+--------+----------+ 814 | Port_2 | IP_3 | INIT_BIND | 1 | TID_3 | 0 | 815 +---------+----------+-----------+-----------+--------+----------+ 817 Figure 4: Example Binding State Table 819 6. DHCP Snooping Process 821 This section specifies the process of setting up bindings based on 822 DHCP snooping. This process is illustrated using a state machine. 824 6.1. Rationale 826 The rationale of the DHCP Snooping Process is that if a DHCP client 827 is legitimately using a DHCP-assigned address, the DHCP address 828 assignment procedure that assigns the IP address to the client must 829 have been performed via the client's point of attachment. This 830 assumption works when the SAVI device is always on the path(s) from 831 the DHCP client to the DHCP server(s)/relay(s). Without considering 832 the movement of DHCP clients, the SAVI device should be the cut 833 vertex whose removal will separate the DHCP client and the remaining 834 network containing the DHCP server(s)/ and relay(s). For most of the 835 networks whose topologies are simple, it is possible to deploy this 836 SAVI function at proper devices to meet this requirement. 838 However, if there are multiple paths from a DHCP client to the DHCP 839 server and the SAVI device is only on one of them, there is an 840 obvious failure case: the SAVI device may not be able to snoop the 841 DHCP procedure. Host movement may also make this requirement 842 difficult to meet. For example, when a DHCP client moves from one 843 attachment to another attachment in the same network, it may fail to 844 reinitialize its interface or send a Confirm message because of 845 incomplete protocol implementation. Thus, there can be scenarios in 846 which only performing this DHCP Snooping Process is insufficient to 847 set up bindings for all the valid DHCP addresses. These exceptions 848 and the solutions are discussed in Section 7. 850 6.2. Binding States Description 852 Following binding states are present in this process and the 853 corresponding state machine: 855 NO_BIND: No binding has been set up. 857 INIT_BIND: A potential binding has been set up. 859 BOUND: The binding has been set up. 861 6.3. Events 863 This section describes events in this process and the corresponding 864 state machine transitions. The DHCP message categories (e.g., DHCPv4 865 Discover) defined in Section 3 are used extensively in the 866 definitions of events and elsewhere in the state machine definition. 867 If an event will trigger the creation of a new binding entry, the 868 binding entry limit on the binding anchor MUST NOT be exceeded. 870 6.3.1. Timer Expiration Event 872 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 874 6.3.2. Control Message Arriving Events 876 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 877 received. 879 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 881 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 883 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 884 received. 886 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 888 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 889 option is received. 891 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 893 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 894 received. 896 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 897 received. 899 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer to 900 section 4.3.3 of [RFC5007]) is received. 902 Note: the events listed here do not cover all the DHCP messages in 903 Section 3. The messages which do not really determine address usage 904 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 905 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 906 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 907 to section 6.4.2.1), are not included. Note also that DHCPv4 908 DHCPLEASEQUERY is not used in the DHCP Snooping process to avoid 909 confusion with Section 7. Also since the LEASEQUERY should have been 910 originated by the SAVI Device itself, the destination check should 911 verify that the message is directed to this SAVI device - and it 912 should not be forwarded once it has been processed here. 914 Moreover, only if a DHCP message can pass the following checks, the 915 corresponding event is regarded as a valid event: 917 o Attribute check: the DHCP Server-to-Client messages and 918 LEASEQUERY-REPLY should be from attachments with DHCP-Trust 919 attribute; the DHCP Client-Server messages should be from 920 attachments with DHCP-Snooping attribute. 922 o Destination check: the DHCP Server-to-Client messages should be 923 destined to attachments with DHCP-Snooping attribute. This check 924 is performed to ensure the binding is set up on the SAVI device 925 which is nearest to the destination client. 927 o Binding anchor check: the DHCP Client-Server messages which may 928 trigger modification or removal of an existing binding entry must 929 have a matching binding anchor with the corresponding entry. 931 o TID check: the DHCP Server-to-Client/Client-Server messages which 932 may cause modification on existing binding entries must have 933 matched TID with the corresponding entry. Note that this check is 934 not performed on Lease query and Lease query-reply messages as 935 they are exchanged between the SAVI devices and the DHCP servers. 937 Besides, this check is not performed on DHCP Renew/Rebind 938 messages. 940 o Binding limitation check: the DHCP messages must not cause new 941 binding setup on an attachment whose binding entry limitation has 942 been reached. (refer to Section 11.5). 944 o Address check: the source address of the DHCP messages should pass 945 the check specified in Section 8.2. 947 On receiving a DHCP message without triggering a valid event, the 948 state will not change, and the actions will not be performed. Note 949 that if a message does not trigger a valid event but it can pass the 950 checks in Section 8.2, it MUST be forwarded. 952 6.4. The State Machine of DHCP Snooping Process 954 This section specifies state transitions and their corresponding 955 actions. 957 6.4.1. Initial State: NO_BIND - No binding has been set up 959 6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request 960 message is received 962 The SAVI device MUST forward the message. 964 The SAVI device will generate an entry in the BST. The Binding 965 anchor field is set to the binding anchor of the attachment from 966 which the message is received. The State field is set to INIT_BIND. 967 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 968 field is set to the TID of the message. If the message is DHCPv4 969 Request, the Address field can be set to the address to request, 970 i.e., the 'requested IP address'. An example of the entry is 971 illustrated in Figure 5. 973 +--------+-------+---------+-----------------------+-----+----------+ 974 | Anchor |Address| State | Lifetime | TID | Timeouts | 975 +--------+-------+---------+-----------------------+-----+----------+ 976 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | 977 +--------+-------+---------+-----------------------+-----+----------+ 979 Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot 980 triggered initialization 982 Resulting state: INIT_BIND - A potential binding has been set up 984 6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received 986 The SAVI device MUST forward the message. 988 The SAVI device will generate an entry in the BST. The Binding 989 anchor field is set to the binding anchor of the attachment from 990 which the message is received. The State field is set to INIT_BIND. 991 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 992 field is set to the TID of the message. If the message is DHCPv4 993 Reboot, the Address field can be set to the address to request, i.e., 994 the 'requested IP address'. An example of the entry is illustrated 995 in Figure 5. 997 Resulting state: INIT_BIND - A potential binding has been set up 999 6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message 1000 with Rapid Commit option is received 1002 The SAVI device MUST forward the message. 1004 The SAVI device will generate an entry in the BST. The Binding 1005 anchor field is set to the binding anchor of the attachment from 1006 which the message is received. The State field is set to INIT_BIND. 1007 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 1008 field is set to the TID of the message. An example of the entry is 1009 illustrated in Figure 5. 1011 Resulting state: INIT_BIND - A potential binding has been set up 1013 6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received 1015 The SAVI device MUST forward the message. 1017 The SAVI device will generate corresponding entries in the BST for 1018 each address in each Identity Association (IA) option of the Confirm 1019 message. The Binding anchor field is set to the binding anchor of 1020 the attachment from which the message is received. The State field 1021 is set to INIT_BIND. The Lifetime field is set to be 1022 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 1023 message. The Address field is set to the address(es) to confirm. An 1024 example of the entries is illustrated in Figure 6. 1026 +--------+-------+---------+-----------------------+-----+----------+ 1027 | Anchor |Address| State | Lifetime | TID | Timeouts | 1028 +--------+-------+---------+-----------------------+-----+----------+ 1029 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | 1030 +--------+-------+---------+-----------------------+-----+----------+ 1031 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | 1032 +--------+-------+---------+-----------------------+-----+----------+ 1034 Figure 6: Binding entry in BST on Confirm triggered initialization 1036 Resulting state: INIT_BIND - A potential binding has been set up 1038 6.4.1.5. Events that cannot happen in the NO_BIND state 1040 o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires 1042 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1043 received 1045 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 1046 received 1048 o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received 1050 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1051 received 1053 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1054 received 1056 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is 1057 received 1059 These cannot happen because they are each something that happens 1060 AFTER a binding has been created. 1062 6.4.2. Initial State: INIT_BIND - A potential binding has been set up 1064 6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1065 is received 1067 The message MUST be forwarded to the corresponding client. 1069 If the message is DHCPv4 ACK, the Address field of the corresponding 1070 entry (i.e., the binding entry whose TID is the same of the message) 1071 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 1072 The Lifetime field is set to the sum of the lease time in ACK message 1073 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1075 If the message is DHCPv6 Reply, there are following cases: 1077 1. If the status code is not "Success", no modification on 1078 corresponding entries will be made. Corresponding entries will 1079 expire automatically if no "Success" Reply is received during the 1080 lifetime. The entries are not removed immediately due to the 1081 client may be able to use the addresses whenever a "Success" 1082 Reply is received ("If the client receives any Reply messages 1083 that do not indicate a NotOnLink status, the client can use the 1084 addresses in the IA and ignore any messages that indicate a 1085 NotOnLink status." [RFC3315]). 1087 2. If the status code is "Success", the SAVI device checks the IA 1088 options in the Reply message. 1090 A. If there are IA options in the Reply message, the SAVI device 1091 checks each IA option. When the first assigned address is 1092 found, the Address field of the binding entry with matched 1093 TID is set to the address. The Lifetime field is set to the 1094 sum of the lease time in Reply message and 1095 MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1096 If there are more than one address assigned in the message, 1097 new binding entries are set up for the remaining address 1098 assigned in the IA options. An example of the entries is 1099 illustrated in Figure 8. SAVI devices do not specially 1100 process IA options with NoAddrsAvail status, because there 1101 should be no address contained in such IA options. 1103 B. Otherwise, the DHCP Reply message is in response to a Confirm 1104 message. The state of the binding entries with matched TID 1105 is changed to BOUND. Because [RFC3315] does not require 1106 lease time of addresses to be contained in the Reply message, 1107 the SAVI device SHOULD send a LEASEQUERY [RFC5007] message 1108 querying by IP address to All_DHCP_Servers multicast address 1109 [RFC3315] or a list of configured DHCP server addresses. The 1110 Lease query message is generated for each IP address if 1111 multiple addresses are confirmed. The Lifetime of 1112 corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If 1113 there is no response message after MAX_LEASEQUERY_DELAY, send 1114 the LEASEQUERY message again. An example of the entries is 1115 illustrated in Figure 7. If the SAVI device does not send 1116 the LEASEQUERY message, a pre-configured lifetime 1117 DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 1118 (Note: it is RECOMMENDED to use T1 configured on DHCP servers 1119 as the DHCP_DEFAULT_LEASE.) 1121 Note: the SAVI devices do not check if the assigned addresses are 1122 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 1123 only source of valid addresses. However, the DHCP servers should be 1124 configured to make sure no duplicated addresses are assigned. 1126 +--------+-------+-------+------------------------+-----+----------+ 1127 | Anchor |Address| State | Lifetime | TID | Timeouts | 1128 +--------+-------+-------+------------------------+-----+----------+ 1129 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 | 1130 +--------+-------+-------+------------------------+-----+----------+ 1131 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 | 1132 +--------+-------+-------+------------------------+-----+----------+ 1134 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1135 Confirm 1137 Transition 1138 +--------+-------+-------+------------------------+-----+----------+ 1139 | Anchor |Address| State | Lifetime | TID | Timeouts | 1140 +--------+-------+-------+------------------------+-----+----------+ 1141 | Port_1 | Addr1 | BOUND |Lease time+ | TID | 0 | 1142 | | | |MAX_DHCP_RESPONSE_TIME | | | 1143 +--------+-------+-------+------------------------+-----+----------+ 1144 | Port_1 | Addr2 | BOUND |Lease time+ | TID | 0 | 1145 | | | |MAX_DHCP_RESPONSE_TIME | | | 1146 +--------+-------+-------+------------------------+-----+----------+ 1148 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 1149 Request 1151 Resulting state: BOUND - The binding has been set up 1153 6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1154 expires 1156 The entry MUST be deleted from BST. 1158 Resulting state: An entry that has been deleted from the BST may be 1159 considered to be in the state "NO_BIND" - No binding has been set up. 1161 6.4.2.3. Events that are ignored in INIT_BIND 1163 If no DHCP Server-to-Client messages which assign addresses or 1164 confirm addresses are received, corresponding entries will expire 1165 automatically. Thus, other DHCP Server-to-Client messages (e.g., 1166 DHCPv4 NAK) are not specially processed. 1168 As a result, the following events, should they occur, are ignored 1169 until either a DHCPv4 ACK or a DHCPv6 Reply message is received or 1170 the lifetime of the binding entry expires. 1172 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1173 received 1175 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1177 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1179 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1180 received 1182 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 1183 received 1185 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1186 Commit option is received 1188 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1189 received 1191 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1192 received 1194 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is 1195 received 1197 In each case, the message MUST be forwarded. 1199 Resulting state: INIT_BIND - A potential binding has been set up 1201 6.4.3. Initial State: BOUND - The binding has been set up 1203 6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1204 expires 1206 The entry MUST be deleted from BST. 1208 Resulting state: An entry that has been deleted from the BST may be 1209 considered to be in the state "NO_BIND" - No binding has been set up. 1211 6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline 1212 message is received 1214 The message MUST be forwarded. 1216 The SAVI device first gets all the addresses ("Requested IP address" 1217 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1218 IA options of DHCPv6 Decline/Release) to decline/release in the 1219 message. Then the corresponding entries MUST be removed. 1221 Resulting state in each relevant BST entry: An entry that has been 1222 deleted from the BST may be considered to be in the state "NO_BIND" - 1223 No binding has been set up. 1225 6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release 1226 message is received 1228 The message MUST be forwarded. 1230 The SAVI device first gets all the addresses ("Requested IP address" 1231 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1232 IA options of DHCPv6 Decline/Release) to decline/release in the 1233 message. Then the corresponding entries MUST be removed. 1235 Resulting state in each relevant BST entry: An entry that has been 1236 deleted from the BST may be considered to be in the state "NO_BIND" - 1237 No binding has been set up. 1239 6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind 1240 message is received 1242 The message MUST be forwarded. 1244 In such case, a new TID will be used by the client. The TID field of 1245 the corresponding entries MUST be set to the new TID. Note that TID 1246 check will not be performed on such messages. 1248 Resulting state: BOUND: The binding has been set up 1250 6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew 1251 message is received 1253 The message MUST be forwarded. 1255 In such case, a new TID will be used by the client. The TID field of 1256 the corresponding entries MUST be set to the new TID. Note that TID 1257 check will not be performed on such messages. 1259 Resulting state: BOUND: The binding has been set up 1261 6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1262 is received 1264 The message MUST be forwarded. 1266 The DHCP Reply messages received in current states should be in 1267 response to DHCP Renew/Rebind. 1269 If the message is DHCPv4 ACK, the SAVI device updates the binding 1270 entry with matched TID, with the Lifetime field set to be the sum of 1271 the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in 1272 the state BOUND. 1274 If the message is DHCPv6 Reply, the SAVI device checks each IA 1275 Address option in each IA option. For each: 1277 1. If the IA entry in the REPLY message has the status "NoBinding", 1278 there is no address in the option, and no operation on an address 1279 is performed. 1281 2. If the valid lifetime of an IA address option is 0, the binding 1282 entry with matched TID and address is removed, leaving it 1283 effectively in the state NO_BIND. 1285 3. Otherwise, set the Lifetime field of the binding entry with 1286 matched TID and address to be the sum of the new valid lifetime 1287 and MAX_DHCP_RESPONSE_TIME, leaving the entry in the state BOUND. 1289 Resulting state: NO_BIND or BOUND, as specified. 1291 6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 1292 LEASEQUERY_REPLY is received 1294 The message MUST be forwarded. 1296 The message should be in response to the Lease query message sent in 1297 Section 6.4.2. The related binding entry can be determined based on 1298 the address in the IA Address option in the Lease query-reply 1299 message. The Lifetime field of the corresponding binding entry is 1300 set to the sum of the lease time in the LEASEQUERY-REPLY message and 1301 MAX_DHCP_RESPONSE_TIME. 1303 Resulting state: BOUND: The binding has been set up 1305 6.4.3.8. Events not processed in the state BOUND 1307 The following events are ignored if received while the indicated 1308 entry is in the state BOUND. Any required action will be the result 1309 of the next message in the client/server exchange. 1311 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1312 received 1314 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1316 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1317 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1318 Commit option is received 1320 6.4.4. Table of State Machine 1322 The main state transits are listed as follows. Note that not all the 1323 details are specified in the table and the diagram. 1325 State Event Action Next State 1326 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1327 INIT_BIND RPL Record lease time BOUND 1328 (send lease query if no lease) 1329 INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1330 BOUND RLS/DCL Remove entry NO_BIND 1331 BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1332 BOUND RPL Set new lifetime BOUND 1333 BOUND LQR Record lease time BOUND 1335 Figure 9: State Transition Table 1337 RQ: EVE_DHCP_REQUEST 1339 CF: EVE_DHCP_CONFIRM 1341 RC: EVE_DHCP_SOLICIT_RC 1343 RE: EVE_DHCP_REBOOT 1345 RPL: EVE_DHCP_REPLY 1347 DCL: EVE_DHCP_DECLINE 1349 RLS: EVE_DHCP_RELEASE 1351 LQR: EVE_DHCP_LEASEQUERY 1352 +-------------+ 1353 | | 1354 /--------+ NO_BIND |<--------\ 1355 | ----->| | | 1356 | | +-------------+ |EVE_DHCP_RELEASE 1357 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1358 EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE 1359 EVE_DHCP_SOLICIT_RC| | | 1360 EVE_DHCP_REBOOT | | | 1361 | | | 1362 | | | 1363 v | | 1364 +-------------+ +------------+ 1365 | | EVE_DHCP_REPLY | | 1366 | INIT_BIND --------------------->| BOUND |<-\ 1367 | | | | | 1368 +-------------+ +------------+ | 1369 | | 1370 \--------/ 1371 EVE_DHCP_REPLY 1372 EVE_DHCP_LEASEQUERY 1374 Figure 10: Diagram of Transit 1376 7. Data Snooping Process 1377 7.1. Scenario 1379 The rationale of the DHCP Snooping Process specified in Section 6 is 1380 that if a DHCP client's use of a DHCP address is legitimate, the 1381 corresponding DHCP address assignment procedure must have been 1382 finished during the attachment of the DHCP client. This is the case 1383 when the SAVI device is continuously on the path(s) from the DHCP 1384 client to the DHCP server(s)/relay(s). However, there are two cases 1385 in which this does not work: 1387 o Multiple paths: there is more than one feasible link-layer path 1388 from the client to the DHCP server/relay, and the SAVI device is 1389 not on every one of them. The client may get its address through 1390 one of the paths does not pass through the SAVI device, but 1391 packets from the client can travel on paths that pass through the 1392 SAVI device, such as when the path through the link layer network 1393 changes. Because the SAVI device could not snoop the DHCP packet 1394 exchange procedure, the DHCP Snooping Process cannot set up the 1395 corresponding binding. 1397 o Dynamic path: there is only one feasible link-layer path from the 1398 client to the DHCP server/relay, but the path is dynamic due to 1399 topology change (for example, some link becomes broken due to 1400 failure or some planned change) or link-layer path change. This 1401 situation also covers the local-link movement of clients without 1402 address confirm/re-configuration process. For example, a host 1403 changes its attached switch port in a very short time. In such 1404 cases, the DHCP Snooping Process will not set up the corresponding 1405 binding. 1407 The Data Snooping Process can avoid the permanent blocking of 1408 legitimate traffic in case one of these two exceptions occurs. This 1409 process is performed on attachments with the Data-Snooping attribute. 1410 Data packets without a matching binding entry may trigger this 1411 process to set up bindings. 1413 Snooping data traffic introduces considerable burden on the processor 1414 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1415 overhead of this process, the implementation of this process is 1416 OPTIONAL. This function SHOULD be enabled unless the implementation 1417 is known to be used in the scenarios without the above exceptions. 1418 For example, if the implementation is to be used in networks with 1419 tree topology and without host local-link movement, there is no need 1420 to implement this process in such scenarios. 1422 This process is not intended to set up a binding whenever a data 1423 packet without a matched binding entry is received. Instead, 1424 unmatched data packets trigger this process probabilistically and 1425 generally a number of unmatched packets will be discarded before the 1426 binding is set up. The parameter(s) of this probabilistic process 1427 SHOULD be configurable, defaulting to a situation where data snooping 1428 is disabled. 1430 7.2. Rationale 1432 This process makes use of NS/ARP and DHCP LEASEQUERY to set up 1433 bindings. If an address is not used by another client in the 1434 network, and the address has been assigned in the network, the 1435 address can be bound with the binding anchor of the attachment from 1436 which the unmatched packet is received. 1438 The Data Snooping Process provides an alternative path for binding 1439 entries to reach the BOUND state in the exceptional cases explained 1440 in Section 7.1 when there are no DHCP messages that can be snooped by 1441 the SAVI device. 1443 In some of the exceptional cases (especially the dynamic topology 1444 case), by the time the binding has reached the BOUND state the DHCP 1445 messages may be passing through the SAVI device. In this case the 1446 events driven by DHCP messages that are expected in the BOUND state 1447 in the DHCP Snooping Process may occur and the binding can be handled 1448 by the DHCP Snooping Process state machine. 1450 In any event, the lease expiry timeout event will occur even if no 1451 others do. This will cause the binding to be deleted and the state 1452 to logically return to NO_BIND state. Either the DHCP or the Data 1453 Snooping Process will be reinvoked if the lease is still place. If 1454 DHCP messages are still not passing through the SAVI device, there 1455 will be a brief disconnection during which data packets passing 1456 through the SAVI device will be dropped. The probabilistic 1457 initiation of the Data Snooping Process can then take over again and 1458 return the binding state to BOUND in due course. 1460 The security issues concerning this process are discussed is 1461 Section 11.1. 1463 7.3. Additional Binding States Description 1465 In addition to NO_BIND and BOUND from Section 6.2, three new states 1466 used in this process are listed here. The INIT_BIND state is not 1467 used, as it is entered by observing a DHCP message. 1469 DETECTION: The address in the entry is undergoing local duplication 1470 detection. 1472 RECOVERY: The SAVI device is querying the assignment and lease time 1473 of the address in the entry through DHCP lease query. 1475 VERIFY: The SAVI device is verifying that the device connected to the 1476 attachment point has a hardware address that matches the one returned 1477 in the DHCP lease query. 1479 Because the mechanisms used for the operations carried out while the 1480 binding is in these three states operate over unreliable protocols, 1481 each operation is carried out twice with a timeout that is triggered 1482 if no response is received. 1484 7.4. Events 1486 To handle the Data Snooping Process, five extra events, described 1487 here, are needed in addition to those used by the DHCP Snooping 1488 Process (see Section 6.3). If an event will trigger the creation of 1489 a new binding entry, the binding entry limit on the binding anchor 1490 MUST NOT be exceeded. 1492 EVE_DATA_UNMATCH: A data packet without a matched binding is 1493 received. 1495 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1496 against an address in DETECTION state is received from a host other 1497 than the one for which the entry was added (i.e., a host attached at 1498 another point than the one on which the triggering data packet was 1499 received). 1501 EVE_DATA_LEASEQUERY: 1503 o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1504 is received. Note that the DHCPLEASEUNKNOWN and 1505 DHCPLEASEUNASSIGNED replies are ignored. 1507 o IPv6: A successful LEASEQUERY-REPLY is received. 1509 EVE_DATA_VERIFY: An ARP Reply/Neighbor Advertisement(NA) message has 1510 been received in the VERIFY state from the device connected to the 1511 attachment point on which the data packet was received. 1513 The triggering packet should pass the following checks to trigger a 1514 valid event: 1516 o Attribute check: the data packet should be from attachments with 1517 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY-REPLY 1518 messages should be from attachments with DHCP-Snooping attribute. 1520 o Binding limitation check: the data messages must not cause new 1521 binding setup on an attachment whose binding entry limitation has 1522 been reached. (refer to Section 11.5). 1524 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1525 DHCP Lease query messages must pass the check specified in 1526 Section 8.2. For EVE_DATA_CONFLICT and EVE_DATA_VERIFY, the 1527 source address and target address of the ARP or NA messages must 1528 pass the check specified in Section 8.2. 1530 o Interval check: the interval between two successive 1531 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1532 smaller than DATA_SNOOPING_INTERVAL. 1534 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have 1535 matched TID with the corresponding entry. 1537 o Prefix check: the source address of the data packet should be of a 1538 valid local prefix, as specified in section 7 of [RFC7039]. 1540 EVE_DATA_EXPIRE: A timer expires indicating that a response to a 1541 hardware address verification message sent in the VERIFY state has 1542 not been received within the specified DETECTION_TIMEOUT period. 1544 EVE_ENTRY_EXPIRE: A timer expires after the Lifetime indicated in the 1545 relevant BST entry has elapsed. This is identical to the usage in 1546 the DHCP Snooping Process. 1548 7.5. Message Sender Functions 1550 The Data Snooping Process involves sending three different messages 1551 to other network devices. Each message may be sent up to twice since 1552 they are sent over unreliable transports and are sent in different 1553 states. The functions defined in this section specify the messages 1554 to be sent in the three cases. In each case the message to be sent 1555 depends on whether the triggering data packet is an IPv4 or an IPv6 1556 packet. 1558 7.5.1. Duplicate Detection Message Sender 1560 Send a message to check if the source address in the data packet that 1561 triggered the data snooping process has a local conflict (that is, it 1562 uses an address that is being used by another node): 1564 IPv4 address: broadcast an Address Resolution Protocol (ARP) Request 1565 [RFC0826] or an ARP probe [RFC5227] for the address to the 1566 local network. An ARP Response will be expected from the 1567 device on the attachment point on which the triggering data 1568 packet was received. An ARP Reply received on any other port 1569 indicates a duplicate address. 1571 IPv6 address: send a Duplicate Address Detection (DAD) message 1572 (Neighbor Solicitation message) to the solicited node multicast 1573 address [RFC4861] targeting the address. Ideally, only the 1574 host on that point of attachment responds with a Neighbor 1575 Advertisement. A Neighbor Advertisement received on any other 1576 port indicates a duplicate address. 1578 As both the ARP and DAD processes are unreliable (either the packet 1579 to or from the other system may be lost in transit, see [RFC6620]), 1580 if there is no response after the DETECTION_TIMEOUT an 1581 EVE_ENTRY_EXPIRE is generated. 1583 7.5.2. Lease Query Message Sender 1585 Send a DHCP lease query message to the DHCP server(s) to determine if 1586 it has given out a lease for the source address in the triggering 1587 data packet. A list of authorized DHCP servers is kept by the SAVI 1588 device. The list should be either pre-configured with the IPv4 and/ 1589 or IPv6 addresses or dynamically discovered: For networks using IPV4 1590 this can be done by sending DHCPv4 Discover messages and parsing the 1591 returned DHCPv4 Offer messages; for networks using IPv6 discovery can 1592 be done by sending DHCPv6 SOLICIT messages and parsing the returned 1593 ADVERTISE messages. See Section 11.2 regarding the securing of the 1594 process and the advisability of using the DHCPv6 1595 All_DHCP_Relay_Agents_and_Servers or All_DHCP_Servers multicast 1596 addresses. The same TID should be used for all lease query messages 1597 sent in response to a triggering data message on an attachment point. 1598 The TID is generated if the TID field in the BST entry is empty and 1599 recorded in the TID field of the BST entry when the first message is 1600 sent. Subsequent messages use the TID from the BST entry. 1602 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1603 by IP address to each DHCPv4 server in the list of authorized 1604 servers with an IP Address Lease Time option (option 51). If the 1605 server has a valid lease for the address, the requested 1606 information will be returned in a DHCPLEASEACTIVE message. 1608 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1609 address to each DHCPv6 server in the list of authorized servers 1610 using the server address as the link-address in the LEASEQUERY 1611 message. If the server has a valid lease for the address, the 1612 requested information will be returned in a LEASEQUERY-REPLY 1613 message marked as successful (i.e., without an OPTION_STATUS_CODE 1614 in the reply). The IA Address option(s) returned contain any 1615 IPv6 addresses bound to the same link together with the lease 1616 validity time. 1618 As DHCP lease queries are an unreliable process (either the packet to 1619 or from the server may be lost in transit), if there is no response 1620 after the MAX_LEASEQUERY_DELAY an EVE_DATA_EXPIRE is generated. Note 1621 that multiple response messages may be received if the list of 1622 authorized servers contains more than one address of the appropriate 1623 type and, in the case of DHCPv6, the responses may contain additional 1624 addresses for which leases have been allocated. 1626 7.5.3. Address Verification Message Sender 1628 Send a message to verify that the link layer address in the attached 1629 device that sent the triggering data packet matches the link layer 1630 address contained in the lease query response: 1632 IPv4 address: Send an ARP Request with the Target Protocol Address 1633 set to the IP address in the BST entry. The ARP Request is 1634 only sent to the attachment that triggered the binding. If the 1635 attached device has the IP address bound to the interface 1636 attached to the SAVI device, an ARP Reply should be received 1637 containing the hardware address of the interface on the 1638 attached device that can be compared with the lease query 1639 value. 1641 IPv6 address: Send a Neighbor Solicitation (NS) message with the 1642 target address set to the IP address in the BST entry. The NS 1643 is only sent to the attachment that triggered the binding. If 1644 the attached device has the IP address bound to the interface 1645 attached to the SAVI device, a Neighbor Announcement (NA) 1646 should be received indicating that the attached device has the 1647 IP address configured on the interface. 1649 As both the ARP and NS/NA processes are unreliable (either the packet 1650 to or from the other system may be lost in transit, see [RFC6620]), 1651 if there is no response after the DETECTION_TIMEOUT an 1652 EVE_DATA_EXPIRE is generated. 1654 7.6. Initial State: state NO_BIND - No binding has been set up 1656 7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding 1657 is received 1659 Make a probabilistic determination as to whether to act on this 1660 event. The probability may be configured or calculated based on the 1661 state of the SAVI device. This probability should be low enough to 1662 mitigate the damage from DoS attack against this process. 1664 Create a new entry in the BST. Set the Binding Anchor field to the 1665 corresponding binding anchor of the attachment. Set the Address 1666 field to the source address of the packet. 1668 Address conflicts MUST be detected and prevented. 1670 If local address detection is performed: 1671 Set the State field to DETECTION. Set the Lifetime of the 1672 created entry to DETECTION_TIMEOUT. Set the Timeouts field to 1673 0. Start the detection of any local address conflicts by 1674 sending a Duplicate Address Detection Message (Section 7.5.1)). 1675 Transition to state DETECTION. 1677 If local address detection is not performed: 1678 Set the State field to RECOVERY. Set the Lifetime of the 1679 created entry to LEASEQUERY_DELAY. Set the Timeouts field to 1680 0. Start the recovery of any DHCP lease associated with the 1681 source IP address by sending one or more lease query messages 1682 (Section 7.5.2)). Transition to state RECOVERY. 1684 The packet that triggers this event SHOULD be discarded. 1686 An example of the BST entry during duplicate address detection is 1687 illustrated in Figure 11. 1689 +--------+-------+---------+-----------------------+-----+----------+ 1690 | Anchor |Address| State | Lifetime | TID | Timeouts | 1691 +--------+-------+---------+-----------------------+-----+----------+ 1692 | Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 | 1693 +--------+-------+---------+-----------------------+-----+----------+ 1695 Figure 11: Binding entry in BST on data triggered initialization 1697 Resulting state: DETECTION - The address in the entry is undergoing 1698 local duplication detection - or RECOVERY - DHCP lease(s) associated 1699 with the address are being queried. 1701 7.6.2. Events not observed in NO_BIND for data snooping 1703 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1704 received from unexpected system 1706 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1707 received 1709 EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the 1710 attached device 1711 All EVE_DHCP_* events defined in Section 6.3.2 are treated as 1712 described in the DHCP Snooping Process (Section 6.4.1) and may result 1713 in that process being triggered. 1715 EVE_ENTRY_EXPIRE: 1717 EVE_DATA_EXPIRE: 1719 7.7. Initial State: state DETECTION - The address in the entry is 1720 undergoing local duplication detection 1722 7.7.1. Event: EVE_ENTRY_EXPIRE 1724 When this event occurs, no address conflict has been detected during 1725 the previous DETECTION_TIMEOUT period. 1727 If the Timeouts field in the BST entry is 0: 1728 Set the Lifetime of the BST entry to DETECTION_TIMEOUT. Set 1729 the Timeouts field to 1. Restart the detection of any local 1730 address conflicts by sending a second Duplicate Address 1731 Detection Message (Section 7.5.1)). Remain in state DETECTION. 1733 If the Timeouts field in the BST entry is 1: 1734 Assume that there is no local address conflict. Set the State 1735 field to RECOVERY. Set the Lifetime of the BST entry to 1736 LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the 1737 recovery of any DHCP lease associated with the source IP 1738 address by sending one or more lease query messages 1739 (Section 7.5.2)). Transition to state RECOVERY. 1741 An example of the entry is illustrated in Figure 12. 1743 +--------+-------+----------+----------------------+-----+----------+ 1744 | Anchor |Address| State | Lifetime | TID | Timeouts | 1745 +--------+-------+----------+----------------------+-----+----------+ 1746 | Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 | 1747 +--------+-------+----------+----------------------+-----+----------+ 1749 Figure 12: Binding entry in BST on Lease Query 1751 Resulting state: DETECTION - If a second local conflict period is 1752 required - or RECOVERY - The SAVI device is querying the assignment 1753 and lease time of the address in the entry through DHCP Leasequery 1755 7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) 1756 message received from unexpected system 1758 Remove the entry. 1760 Resulting state: NO_BIND - No binding has been set up 1762 7.7.3. Events not observed in DETECTION 1764 EVE_DATA_UNMATCH: A data packet without matched binding is received 1766 All EVE_DHCP_* events defined in Section 6.3.2 1768 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1769 received 1771 7.8. Initial State: state RECOVERY - The SAVI device is querying the 1772 assignment and lease time of the address in the entry through DHCP 1773 Leasequery 1775 7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 1776 successful LEASEQUERY-REPLY is received 1778 Set the State in the BST entry to VERIFY. Depending on the type of 1779 triggering source IP address, process the received DHCP lease query 1780 response: 1782 IPv4 address: Update the Lifetime field in the BST entry to the sum 1783 of the value encoded in IP Address Lease Time option of the 1784 DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Record the 1785 value of the "chaddr" field (hardware address) in the message 1786 for checking against the hardware address received during 1787 verification in the next state. Set the Timeouts field to 0. 1788 Start the verification process by sending an Address 1789 Verification Message (see Section 7.5.3). Transition to state 1790 VERIFY. Start an additional verification timer with a duration 1791 of DETECTION_TIMEOUT. When this expires an EVE_DATA_EXPIRE 1792 event will be generated. 1794 IPv6 address: Update the Lifetime field in the BST entry to the sum 1795 of the valid lifetime extracted from OPTION_CLIENT_DATA option 1796 in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME. 1797 Set the Timeouts field to 0. Start the verification process by 1798 sending an Address Verification Message (see Section 7.5.3). 1799 Transition to state VERIFY. Start an additional verification 1800 timer with a duration of DETECTION_TIMEOUT. When this expires 1801 an EVE_DATA_EXPIRE event will be generated. 1803 If multiple addresses are received in the LEASEQUERY-REPLY, new 1804 BST entries MUST be created for the additional addresses using 1805 the same binding anchor. The entries are created with State 1806 set to VERIFY and the other fields set as described in this 1807 section for the triggering source IP address. Also start the 1808 verification process and start verification timers for each 1809 additional address. 1811 Resulting state: VERIFY - awaiting verification or otherwise of the 1812 association of the IP address with the connected interface. 1814 7.8.2. Event: EVE_ENTRY_EXPIRE 1816 Depending on the value of the Timeouts field in the BST entry, either 1817 send repeat lease query messages or discard the binding: 1819 If the Timeouts field in the BST entry is 0: 1820 No responses to the lease query message(s) sent have been 1821 received during the first LEASEQUERY_DELAY period. Set the 1822 Lifetime of the BST entry to LEASEQUERY_DELAY. Set the 1823 Timeouts field to 1. Restart the recovery of any DHCP lease 1824 associated with the source IP address by sending one or more 1825 lease query messages (Section 7.5.2)). Remain in state 1826 RECOVERY. 1828 If the Timeouts field in the BST entry is 1: 1829 No responses to the lease query messages sent during two 1830 LEASEQUERY_DELAY periods were received. Assume that no leases 1831 exist and hence that the source IP address is bogus. Delete 1832 the BST entry. Transition to state NO_BIND. 1834 Resulting state: RECOVERY - if repeat lease queries are sent - or 1835 NO_BIND - if no successful responses to lease query messages have 1836 been received. 1838 7.8.3. Events not observed in RECOVERY 1840 EVE_DATA_UNMATCH: A data packet without matched binding is received 1842 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1843 received from unexpected system 1845 EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the 1846 attached device 1848 All EVE_DHCP_* events defined in Section 6.3.2 1850 EVE_DATA_EXPIRE: 1852 7.9. Initial State: state VERIFY - Verification of the use of the 1853 source IP address by the device interface attached to the SAVI 1854 device 1856 7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 1857 successful LEASEQUERY-REPLY is received 1859 If lease query messages were sent to more than one DHCP server during 1860 RECOVERY state, additional successful lease query responses may be 1861 received relating to the source IP address. The conflict resolution 1862 mechanisms specified in Section 6.8 of [RFC4388] and Section 4.3.4 of 1863 [RFC5007] can be used to determine the message from which values are 1864 used to update the BST Lifetime entry and the hardware address 1865 obtained from DHCP, as described in Section 7.8.1. In the case of 1866 DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses 1867 as described in Section 7.8.1. If so additional BST entries MUST be 1868 created or ones previously created updated as described in that 1869 section. 1871 Resulting state: VERIFY (no change). 1873 7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is received from 1874 the device attached via the binding anchor 1876 Depending on the type of triggering source IP address, this event may 1877 indicate that the device attached via the binding anchor in the BST 1878 entry is configured by DHCP using the IP address: 1880 IPv4 address: Check that the value of sender hardware address in the 1881 ARP Reply matches the saved "chaddr" field (hardware address) 1882 from the previously received DHCPLEASEACTIVE message. If not, 1883 ignore this event; a subsequent retry may provide verification. 1884 If the hardware addresses match, the binding entry has been 1885 verified. 1887 IPv6 address: Simple receipt of a valid NA from the triggering 1888 source IP address at the binding anchor port provides 1889 verification for the binding entry. 1891 If the binding entry has been verified, set the State in the BST 1892 entry to BOUND. Clear the TID field. Cancel the verification timer. 1894 Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY "chaddr" 1895 address does not match ARP Reply hardware address - or BOUND - 1896 otherwise. 1898 7.9.3. Event: EVE_ENTRY_EXPIRE 1900 The DHCP lease lifetime has expired before the entry could be 1901 verified. Remove the entry. Transition to NO_BIND state. 1903 Resulting state: NO_BIND - No binding has been set up 1905 7.9.4. Event: EVE_DATA_EXPIRE 1907 Depending on the value of the Timeouts field in the BST entry, either 1908 send a repeat validation message or discard the binding: 1910 If the Timeouts field in the BST entry is 0: 1911 No response to the verification message sent has been received 1912 during the first DETECTION_TIMEOUT period. Set the Timeouts 1913 field to 1. Restart the verification process by sending an 1914 Address Verification Message (see Section 7.5.3). Start a 1915 verification timer with a duration of DETECTION_TIMEOUT. When 1916 this expires an EVE_DATA_EXPIRE event will be generated. 1917 Remain in state VERIFY. 1919 If the Timeouts field in the BST entry is 1: 1920 No responses to the verification messages sent during two 1921 DETECTION_TIMEOUT periods were received. Assume that the 1922 configuration of the triggering source IP address cannot be 1923 verified and hence that the source IP address is bogus. Delete 1924 the BST entry. Transition to state NO_BIND. 1926 Resulting state: VERIFY - additional verification message sent - or 1927 NO_BIND - No binding has been set up 1929 7.9.5. Events not observed in VERIFY 1931 EVE_DATA_UNMATCH: A data packet without matched binding is received 1933 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1934 received from unexpected system 1936 All EVE_DHCP_* events defined in Section 6.3.2 1938 7.10. Initial State: state BOUND - The binding has been set up 1940 Upon entry to the state BOUND, control the system continues as if a 1941 DHCP message assigning the address has been observed, as in 1942 Section 6.4.3. The BST entry has been restored. 1944 Note that the TID field contains no value after the binding state 1945 changes to BOUND. The TID field is recovered from snooping DHCP 1946 Renew/Rebind messages if these are observed as described in the DHCP 1947 Snooping Process. Because TID is used to associate binding entries 1948 with messages from DHCP servers, it must be recovered; or else a 1949 number of state transitions of this mechanism will be not executed 1950 normally. 1952 7.11. Table of State Machine 1954 The main state transitions are listed as follows. 1956 State Event Action Next State 1957 NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION 1958 DETECTION EVE_ENTRY_EXPIRE 1 Repeat duplicate detect DETECTION 1959 DETECTION EVE_ENTRY_EXPIRE 2 Start lease query RECOVERY 1960 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1961 RECOVERY EVE_ENTRY_EXPIRE 1 Repeat lease query RECOVERY 1962 RECOVERY EVE_ENTRY_EXPIRE 2 No lease found; remove entry NO_BIND 1963 RECOVERY EVE_DATA_LEASEQUERY Set lease time; Start verify VERIFY 1964 VERIFY EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND 1965 VERIFY EVE_DATA_LEASEQUERY Resolve lease conflict(s) VERIFY 1966 VERIFY EVE_DATA_VERIFY Finish validation BOUND or NO_BIND 1967 VERIFY EVE_DATA_EXPIRE 1 Repeat verify VERIFY 1968 VERIFY EVE_DATA_EXPIRE 2 Verify failed; remove entry NO_BIND 1969 BOUND EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND 1970 BOUND RENEW/REBIND Record TID BOUND 1972 Figure 13: State Transition Table 1973 +-------------+ EVE_ENTRY_EXPIRE 1974 /---------+ |<------------------------\ 1975 | | NO_BIND | EVE_DATA_EXPIRE | 1976 EVE_DATA_UNMATCH | /----->| |<----\ (2nd VRF_DELAY) | 1977 | | +-------------+ | | 1978 | | EVE_ENTRY_EXPIRE | | 1979 | | (2nd LQ_DELAY) | | 1980 EVE_ENTRY_EXPIRE | | | EVE_ENTRY_EXPIRE | 1981 (1st DAD_DELAY) | | | (1st LQ_DELAY) | 1982 /------\ | | | /--------\ | 1983 | | | | EVE_DATA_CONFLICT \---\ | | | 1984 | v v | | v | | 1985 | +-------------+ EVE_ENTRY_EXPIRE +------------+ | | 1986 | | | (2nd DAD_DELAY) | | | | 1987 \----+ DETECTION ------------------------>| RECOVERY +--/ | 1988 | | | | | 1989 +-------------+ (To NO_BIND) +------------+ | 1990 ^ | | 1991 | EVE_DATA_LEASEQUERY | | 1992 /----------\ | | | 1993 | | | EVE_ENTRY_EXPIRE | | 1994 EVE_DHCP_RENEW| v | v | 1995 EVE_DHCP_REBIND| +-------------+ +-------------+ | 1996 | | | | +--/ 1997 \----+ BOUND |<---------------+ VERIFY | 1998 | | EVE_DATA_VERIFY| |<-\ 1999 +-------------+ +-------------+ | 2000 | | 2001 \----------/ 2002 EVE_DATA_LEASEQUERY 2003 EVE_DATA_EXPIRE 2004 (1st VRF_DELAY) 2006 Figure 14: Diagram of Transit 2008 LQ_DELAY: MAX_LEASEQUERY_DELAY 2009 VRF_DELAY: DETECTION_TIMEOUT 2011 8. Filtering Specification 2013 This section specifies how to use bindings to filter out packets with 2014 spoofed source addresses. 2016 Filtering policies are different for data packets and control 2017 packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861] 2018 messages are classified as control packets. All other packets are 2019 classified as data packets. 2021 8.1. Data Packet Filtering 2023 Data packets from attachments with the Validating attribute TRUE MUST 2024 have their source addresses validated. There is one exception to 2025 this rule. 2027 A packet whose source IP address is a link-local address cannot be 2028 checked against DHCP assignments, as it is not assigned using DHCP. 2029 Note: as explained in Section 1, a SAVI solution for link-local 2030 addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to check 2031 packets with a link-local source address. 2033 If the source IP address of a packet is not a link-local address, but 2034 there is not a matching entry in BST with state BOUND, this packet 2035 MUST be discarded. However, the packet may trigger the Data Snooping 2036 Process Section 7 if the Data-Snooping attribute is set on the 2037 attachment. 2039 Data packets from an attachment with the Validating attribute set 2040 FALSE will be forwarded without having their source addresses 2041 validated. 2043 The SAVI device MAY log packets that fail source address validation. 2045 8.2. Control Packet Filtering 2047 For attachments with the Validating attribute: 2049 DHCPv4 Client-Server messages in which the source IP address is 2050 neither all zeros nor bound with the corresponding binding anchor in 2051 the BST MUST be discarded. 2053 DHCPv6 Client-Server messages in which the source IP address is 2054 neither a link-local address nor bound with the corresponding binding 2055 anchor in the BST MUST be discarded. 2057 NDP messages in which the source IP address is neither a link-local 2058 address nor bound with the corresponding binding anchor MUST be 2059 discarded. 2061 NA messages in which the target address is neither a link-local 2062 address nor bound with the corresponding binding anchor MUST be 2063 discarded. 2065 ARP messages in which the protocol is IP and sender protocol address 2066 is neither all zeros address nor bound with the corresponding binding 2067 anchor MUST be discarded. 2069 ARP Reply messages in which the target protocol address is not bound 2070 with the corresponding binding anchor MUST be discarded. 2072 For attachments with other attributes: 2074 DHCP Server-to-Client messages not from attachments with the DHCP- 2075 Trust attribute or Trust attribute MUST be discarded. 2077 For attachments with no attribute: 2079 DHCP Server-to-Client messages from such attachments MUST be 2080 discarded. 2082 The SAVI device MAY record any messages that are discarded. 2084 9. State Restoration 2086 If a SAVI device reboots, the information kept in volatile memory 2087 will be lost. This section specifies the restoration of attribute 2088 configuration and BST. 2090 9.1. Attribute Configuration Restoration 2092 The loss of attribute configuration will not break the network: no 2093 action will be performed on traffic from attachments with no 2094 attribute. However, the loss of attribute configuration makes this 2095 SAVI function unable to work. 2097 To avoid the loss of binding anchor attribute configuration, the 2098 configuration MUST be able to be stored in non-volatile storage. 2099 After the reboot of SAVI device, if the configuration of binding 2100 anchor attributes is found in non-volatile storage, the configuration 2101 MUST be used. 2103 9.2. Binding State Restoration 2105 The loss of binding state will cause the SAVI devices to discard 2106 legitimate traffic. Simply using the Data Snooping Process to 2107 recover a large number of bindings is a heavy overhead and may cause 2108 considerable delay. Thus, to recover bindings from non-volatile 2109 storage, as specified below, is RECOMMENDED. 2111 Binding entries MAY be saved into non-volatile storage whenever a new 2112 binding entry changes to BOUND state. If a binding with BOUND state 2113 is removed, the saved entry MUST be removed correspondingly. The 2114 time when each binding entry is established is also saved. 2116 If the BST is stored in non-volatile storage, the SAVI device SHOULD 2117 restore binding state from the non-volatile storage immediately after 2118 reboot. Using the time when each binding entry was saved, the SAVI 2119 device should check whether the entry has become obsolete by 2120 comparing the saved lifetime and the difference between the current 2121 time and time when the binding entry was established. Obsolete 2122 entries which would have expired before the reboot MUST be removed. 2124 10. Constants 2126 The following constants are recommended for use in this context: 2128 o MAX_DHCP_RESPONSE_TIME 120s Maximum Solicit timeout value 2129 (SOL_MAX_RT from [RFC3315]) 2131 o MAX_LEASEQUERY_DELAY 10s Maximum LEASEQUERY timeout value 2132 (LQ_MAX_RT from [RFC5007]) 2134 o DETECTION_TIMEOUT 0.5s Maximum duration of a hardware address 2135 verification step in the VERIFY state (TENT_LT from [RFC6620]) 2137 o DATA_SNOOPING_INTERVAL Minimum interval between two successive 2138 EVE_DATA_UNMATCH events triggered by an attachment. 60s and 2139 configurable. (recommendation) 2141 o OFFLINK_DELAY 30s Period after a client is last detected before 2142 the binding anchor being removed. (recommendation) 2144 11. Security Considerations 2146 11.1. Security Problems about the Data Snooping Process 2148 There are two security problems about the Data Snooping Process 2149 Section 7: 2151 (1) The Data Snooping Process is costly, but an attacker can trigger 2152 it simply through sending a number of data packets. To avoid 2153 Denial of Services attack against the SAVI device itself, the 2154 Data Snooping Process MUST be rate limited. A constant 2155 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 2156 Data Snooping Processes on one attachment MUST be separated by a 2157 minimum interval time DATA_SNOOPING_INTERVAL. If this value is 2158 changed, the value needs to be large enough to minimize denial of 2159 service attacks. 2161 (2) The Data Snooping Process may set up incorrect bindings if the 2162 clients do not reply to the detection probes Section 7.6.1. An 2163 attack will pass the duplicate detection if the client assigned 2164 the target address does not reply to the detection probes. The 2165 DHCP Lease query procedure performed by the SAVI device just 2166 tells whether the address is assigned in the network or not. 2167 However, the SAVI device cannot determine whether the address is 2168 just assigned to the triggering attachment from the DHCP 2169 LEASEQUERY Reply. 2171 11.2. Securing Lease Query Operations 2173 In [RFC4388] and [RFC5007] the specific case of DHCP lease queries 2174 originated by "access concentrators" is addressed extensively. SAVI 2175 devices are very similar to access concentrators in that they snoop 2176 on DHCP traffic and seek to validate source addresses based on the 2177 results. Accordingly the recommendations for securing lease query 2178 operations for access concentrators in Section 7 of [RFC4388] and 2179 Section 5 of [RFC5007] MUST be followed when lease queries are made 2180 from SAVI devices. [RFC5007] RECOMMENDS that communications between 2181 the querier and the DHCP server are protected with IPsec. It is 2182 pointed out that there are relatively few devices involved in a given 2183 administrative domain (SAVI devices, DHCP relays and servers) so that 2184 manual configuration of keying material would not be overly 2185 burdensome. 2187 11.3. Client departure issues 2189 After a binding is set up, the corresponding client may leave its 2190 attachment point. It may depart temporarily due to signal fade, or 2191 permanently by moving to a new attachment point or leaving the 2192 network. In the signal fade case, since the client may return 2193 shortly, the binding should be kept momentarily, lest legitimate 2194 traffic from the client be blocked. However, if the client leaves 2195 permanently, keeping the binding can be a security issue. If the 2196 binding anchor is a property of the attachment point rather than the 2197 client, e.g., the switch port but not incorporating the MAC Address, 2198 an attacker using the same binding anchor can send packets using IP 2199 addresses assigned to the client. Even if the binding anchor is a 2200 property of the client, retaining binding state for a departed client 2201 for a long time is a waste of resources. 2203 Whenever a direct client departs from the network, a link-down event 2204 associated with the binding anchor will be triggered. SAVI-DHCP 2205 monitors such events, and performs the following mechanism. 2207 (1) Whenever a client with the Validating attribute leaves, a timer 2208 of duration OFFLINK_DELAY is set on the corresponding binding 2209 entries. 2211 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 2212 received that targets the address during OFFLINK_DELAY, the entry 2213 MAY be removed. 2215 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 2216 timer. 2218 In this way, the bindings of a departing client are kept for 2219 OFFLINK_DELAY. In case of link flapping, the client will not be 2220 blocked. If the client leaves permanently, the bindings will be 2221 removed after OFFLINK_DELAY. 2223 SAVI-DHCP does not handle the departure of indirect clients, because 2224 it will not be notified of such events. Switches supporting indirect 2225 attachment (e.g., through a separate non-SAVI switch) SHOULD use 2226 information specific to the client such as its MAC address as part of 2227 the binding anchor. 2229 11.4. Compatibility with DNA (Detecting Network Attachment) 2231 DNA [RFC4436][RFC6059] is designed to decrease the handover latency 2232 after re-attachment to the same network. DNA mainly relies on 2233 performing reachability test by sending unicast Neighbor 2234 Solicitation/Router Solicitation/ARP Request message to determine 2235 whether a previously configured address is still valid. 2237 Although DNA provides optimization for clients, there is insufficient 2238 information for this mechanism to migrate the previous binding or 2239 establish a new binding. If a binding is set up only by snooping the 2240 reachability test message, the binding may be invalid. For example, 2241 an attacker can perform reachability test with an address bound to 2242 another client. If binding is migrated to the attacker, the attacker 2243 can successfully obtain the binding from the victim. Because this 2244 mechanism wouldn't set up a binding based on snooping the DNA 2245 procedure, it cannot achieve perfect compatibility with DNA. 2246 However, it only means the re-configuration of the interface is 2247 slowed but not prevented. Details are discussed as follows. 2249 In Simple DNAv6 [RFC6059], the probe is sent with the source address 2250 set to a link-local address, and such messages will not be discarded 2251 by the policy specified in Section 8.2. If a client is re-attached 2252 to a previous network, the detection will be completed, and the 2253 address will be regarded as valid by the client. However, the 2254 candidate address is not contained in the probe. Thus, the binding 2255 cannot be recovered through snooping the probe. As the client will 2256 perform DHCP exchange at the same time, the binding will be recovered 2257 from the DHCP Snooping Process. The DHCP Request messages will not 2258 be filtered out in this case because they have link-local source 2259 addresses. Before the DHCP procedure is completed, packets will be 2260 filtered out by the SAVI device. In other words, if this SAVI 2261 function is enabled, Simple DNAv6 will not help reduce the handover 2262 latency. If Data-Snooping attribute is configured on the new 2263 attachment of the client, the data triggered procedure may reduce 2264 latency. 2266 In DNAv4 [RFC4436], the ARP probe will be discarded because an 2267 unbound address is used as the sender protocol address. As a result, 2268 the client will regard the address under detection is valid. 2269 However, the data traffic will be filtered. The DHCP Request message 2270 sent by the client will not be discarded, because the source IP 2271 address field should be all zero as required by [RFC2131]. Thus, if 2272 the address is still valid, the binding will be recovered from the 2273 DHCP Snooping Process. 2275 11.5. Binding Number Limitation 2277 A binding entry will consume a certain high-speed memory resources. 2278 In general, a SAVI device can afford only a quite limited number of 2279 binding entries. In order to prevent an attacker from overloading 2280 the resource of the SAVI device, a binding entry limit is set on each 2281 attachment. The binding entry limit is the maximum number of 2282 bindings supported on each attachment with Validating attribute. No 2283 new binding should be set up after the limit has been reached. If a 2284 DHCP Reply assigns more addresses than the remaining binding entry 2285 quota of each client, the message will be discarded and no binding 2286 will be set up. 2288 11.6. Privacy Considerations 2290 A SAVI device MUST delete binding anchor information as soon as 2291 possible (i.e., as soon as the state for a given address is back to 2292 NO_BIND), except where there is an identified reason why that 2293 information is likely to be involved in the detection, prevention, or 2294 tracing of actual source address spoofing. Information about the 2295 majority of hosts that never spoof SHOULD NOT be logged. 2297 11.7. Fragmented DHCP Messages 2299 This specification does not preclude reassembly of fragmented DHCP 2300 messages, but it also does not require it. If DHCP fragmentation 2301 proves to be an issue, that will need to be specified. 2303 12. IANA Considerations 2305 This memo asks the IANA for no new parameters. 2307 13. Acknowledgment 2309 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 2310 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 2311 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 2312 Garcia for careful review and valuation comments on the mechanism and 2313 text. 2315 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 2316 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 2317 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 2318 their valuable contributions. 2320 This document was generated using the xml2rfc tool. 2322 14. References 2324 14.1. Normative References 2326 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2327 converting network protocol addresses to 48.bit Ethernet 2328 address for transmission on Ethernet hardware", STD 37, 2329 RFC 826, November 1982. 2331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2332 Requirement Levels", BCP 14, RFC 2119, March 1997. 2334 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2335 2131, March 1997. 2337 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2338 and M. Carney, "Dynamic Host Configuration Protocol for 2339 IPv6 (DHCPv6)", RFC 3315, July 2003. 2341 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 2342 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 2344 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 2345 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 2347 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2348 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2349 September 2007. 2351 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 2352 "DHCPv6 Leasequery", RFC 5007, September 2007. 2354 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 2355 July 2008. 2357 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 2358 Detecting Network Attachment in IPv6", RFC 6059, November 2359 2010. 2361 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2362 SAVI: First-Come, First-Served Source Address Validation 2363 Improvement for Locally Assigned IPv6 Addresses", RFC 2364 6620, May 2012. 2366 14.2. Informative References 2368 [I-D.ietf-opsec-dhcpv6-shield] 2369 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 2370 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 2371 opsec-dhcpv6-shield-05 (work in progress), January 2015. 2373 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2374 Defeating Denial of Service Attacks which employ IP Source 2375 Address Spoofing", BCP 38, RFC 2827, May 2000. 2377 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 2378 (DHCP) Service for IPv6", RFC 3736, April 2004. 2380 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 2381 "Source Address Validation Improvement (SAVI) Framework", 2382 RFC 7039, October 2013. 2384 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 2385 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 2386 7341, August 2014. 2388 Authors' Addresses 2390 Jun Bi 2391 Tsinghua University 2392 Network Research Center, Tsinghua University 2393 Beijing 100084 2394 China 2396 EMail: junbi@tsinghua.edu.cn 2397 Jianping Wu 2398 Tsinghua University 2399 Computer Science, Tsinghua University 2400 Beijing 100084 2401 China 2403 EMail: jianping@cernet.edu.cn 2405 Guang Yao 2406 Tsinghua University 2407 Network Research Center, Tsinghua University 2408 Beijing 100084 2409 China 2411 EMail: yaoguang@cernet.edu.cn 2413 Fred Baker 2414 Cisco Systems 2415 Santa Barbara, CA 93117 2416 United States 2418 EMail: fred@cisco.com