idnits 2.17.1 draft-ietf-savi-dhcp-33.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 12, 2015) is 3361 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 16, 2015 Tsinghua Univ. 6 F. Baker 7 Cisco 8 February 12, 2015 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-33 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 16, 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 [RFC4388] 291 o DHCPv6 Reply: REPLY [RFC3315] 293 o DHCPv6 Advertise: ADVERTISE [RFC3315] 295 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 297 o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request. 298 [RFC5007] 300 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 301 IPv6 [RFC3315]. 303 Binding entry: A rule that associates an IP address with a binding 304 anchor. 306 Binding State Table (BST): The data structure that contains the 307 binding entries. 309 Binding entry limit: The maximum number of binding entries that may 310 be associated with a binding anchor. Limiting the number of binding 311 entries per binding anchor prevents a malicious or malfunctioning 312 node from overloading the binding table on a SAVI device. 314 Direct attachment: Ideally, a SAVI device is an access device that 315 hosts are attached to directly. In such a case, the hosts are direct 316 attachments (i.e., they attach directly) to the SAVI device. 318 Indirect attachment: A SAVI device MAY be an aggregation device that 319 other access devices are attached to, and which hosts in turn attach 320 to. In such a case, the hosts are indirect attachments (i.e., they 321 attach indirectly) to the SAVI device. 323 Unprotected link: Unprotected links are links that connect to hosts 324 or networks of hosts receive their DHCP traffic by another path, and 325 are therefore outside the SAVI perimeter. 327 Unprotected device: An unprotected device is a device associated with 328 an unprotected link. One example might be the gateway router of a 329 network. 331 Protected link: If DHCP messages for a given attached device always 332 use a given link, the link is considered to be "protected" by the 333 SAVI Device, and is therefore within the SAVI perimeter. 335 Protected device: A protected device is a device associated with a 336 protected link. One example might be a desktop switch in the 337 network, or a host. 339 Cut Vertex: A cut vertex is any vertex whose removal increases the 340 number of connected components in a (network) graph. This is a 341 concept in graph theory. This term is used in Section 6.1 to 342 accurately specify the required deployment location of SAVI devices 343 when they only perform the DHCP Snooping Process. 345 Identity Association (IA): "A collection of addresses assigned to a 346 client." [RFC3315] 348 Detection message: a Neighbor Solicitation or ARP message intended by 349 the Data Snooping Process to detect a duplicate address. 351 DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the 352 binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease 353 query exchange [RFC5007] cannot be performed by the SAVI device to 354 fetch the lease. 356 4. Deployment Scenario and Configuration 358 4.1. Elements and Scenario 360 The essential elements in a SAVI-DHCP deployment scenario include at 361 least one DHCP server (which may or may not be assigned an address 362 using DHCP, and therefore may or may not be protected), zero or more 363 protected DHCP clients, and one or more SAVI devices. It may also 364 include DHCP relays, when the DHCP server is not co-located with a 365 set of clients, and zero or more protected Non-SAVI devices. Outside 366 the perimeter, via unprotected links, there may be many unprotected 367 devices. 369 +-------------+ 370 | unprotected | 371 | device | 372 +------+------+ 373 | 374 +--------+ +-----+------+ +----------+ 375 |DHCP +-----+ Non-SAVI +----+Bogus DHCP| 376 |Server A| | Device 1 | |Server | 377 +--------+ +-----+------+ +----------+ 378 |trusted, unprotected link 379 . . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . . 380 . | . 381 . Protection +---+------+ trusted link . 382 . Perimeter | SAVI +--------------+ . 383 . | Device C| | . 384 . +---+------+ | . 385 . | | . 386 . untrusted, +----------+ +---+------+ +------+---+ . 387 . protected | SAVI | | Non SAVI| | SAVI | . 388 . link+------+ Device A+----+ Device 3+-------+ Device B| . 389 . | +----+--+--+ +----------+ +-+---+----+ . 390 . | | +----------+ . . . . . | | . 391 . | . . . . . . | . . | | . 392 . | . | . | . +--------+ | . 393 . +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ . 394 . | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | . 395 . | Device 2 |. |A | . |Relay | . |B | . |Server B| . 396 . +----------+. +------+ . +------+ . +------+ . +--------+ . 397 . . . . . . . . . . . . . . . . . . . 399 Figure 1: SAVI-DHCP Scenario 401 Figure 1 shows a deployment scenario that contains these elements. 402 Note that a physical device can instantiate multiple elements, e.g., 403 a switch can be both a SAVI device and a DHCP relay, or in a cloud 404 computing environment, a physical host may contain a virtual switch 405 plus some number of virtual hosts. In such cases, the links are 406 logical links rather than physical links. 408 Networks are not usually isolated. As a result, traffic from other 409 networks, including transit traffic as specified in [RFC6620] (e.g., 410 traffic from another SAVI switch or a router) may enter a SAVI-DHCP 411 network through the unprotected links. Since SAVI solutions are 412 limited to validating traffic generated from a local link, SAVI-DHCP 413 does not set up bindings for addresses assigned in other networks and 414 cannot validate them. Traffic from unprotected links should be 415 checked by an unprotected device or [RFC2827] mechanisms. The 416 generation and deployment of such a mechanism is beyond the scope of 417 this document. 419 Traffic from protected links is, however, locally generated, and 420 should have its source addresses validated by SAVI-DHCP if possible. 421 In the event that there is an intervening protected non-SAVI device 422 between the host and the SAVI device, however, use of the physical 423 attachment point alone as a binding anchor is insufficiently secure, 424 as the several devices on a port or other point of attachment can 425 spoof each other. Hence, additional information such as a MAC 426 address SHOULD be used to disambiguate them. 428 4.2. SAVI Binding Type Attributes 430 As illustrated in Figure 1, a system attached to a SAVI device can be 431 a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI 432 device. Different actions are performed on traffic originated from 433 different elements. To distinguish among their requirements, several 434 properties are associated with their point of attachment on the SAVI 435 device. 437 When a binding association is uninstantiated, e.g., when no host is 438 attached to the SAVI device using a given port or other binding 439 anchor, the binding port attributes take default values unless 440 overridden by configuration. By default, a SAVI switch does not 441 filter DHCP messages, nor does it attempt to validate source 442 addresses, which is to say that the binding attributes are ignored 443 until SAVI-DHCP is itself enabled. This is because a SAVI switch 444 that depends on DHCP cannot tell, a priori, which ports have valid 445 DHCP servers attached, or which have routers or other equipment that 446 would validly appear to use an arbitrary set of source addresses. 447 When SAVI has been enabled, the attributes take effect. 449 4.2.1. Trust Attribute 451 The "Trust Attribute" is a Boolean value. If TRUE, it indicates that 452 the packets from the corresponding attached device need not have 453 their source addresses validated. Examples of a trusted attachment 454 would be a port to another SAVI device, or to an IP router, as shown 455 in Figure 1. In both cases, traffic using many source IP addresses 456 will be seen. By default, the Trust attribute is FALSE, indicating 457 that any device found on that port will seek an address using DHCP 458 and be limited to using such addresses. 460 SAVI devices will not set up bindings for points of attachment with 461 the Trust attribute set TRUE; no packets, including DHCP messages, 462 from devices with this attribute on their attachments will be 463 validated. However DHCP Server-to-Client messages will be snooped on 464 attachment points with the Trust attribute set TRUE in the same way 465 as if they had the DHCP-Trust attribute set (see Section 4.2.2.) 467 4.2.2. DHCP-Trust Attribute 469 The "DHCP-Trust Attribute" is similarly a Boolean attribute. It 470 indicates whether the attached device is permitted to initiate DHCP 471 Server-to-Client messages. In Figure 1, the points of attachment of 472 the DHCP Server and the DHCP Relay would have this attribute set 473 TRUE, and attachment points that have Trust set TRUE are implicitly 474 treated as if DHCP-Trust is TRUE.. 476 If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP 477 Server-to-Client messages from the points of attachment with this 478 attribute. If the DHCP Server-to-Client messages can trigger the 479 state transitions, the binding setup processes specified in Section 6 480 and Section 7 will handle them. By default, the DHCP-Trust attribute 481 is FALSE, indicating that the attached system is not a DHCP server. 483 A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for 484 more details. 486 4.2.3. DHCP-Snooping Attribute 488 The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It 489 indicates whether bindings will be set up based on DHCP snooping. 491 If this attribute is TRUE, DHCP Client-Server messages to points of 492 attachment with this attribute will trigger creation of bindings 493 based on the DHCP Snooping Process described in Section 6. If it is 494 FALSE, either the Trust attribute must be TRUE (so that bindings 495 become irrelevant) or another SAVI mechanism such as SAVI-FCFS must 496 be used on the point of attachment. 498 The DHCP-Snooping attribute is configured on the DHCP Client's point 499 of attachment. This attribute can be also used on the attachments to 500 protected Non-SAVI devices that are used by DHCP clients. In 501 Figure 1, the attachment from the Client A to the SAVI Device A, the 502 attachment from the Client B to the SAVI Device B, and the attachment 503 from the Non-SAVI Device 2 to the SAVI Device A can be configured 504 with this attribute. 506 4.2.4. Data-Snooping Attribute 508 The "Data-Snooping Attribute" is a Boolean attribute. It indicates 509 whether data packets from the corresponding point of attachment may 510 trigger the binding setup procedure. 512 Data packets from points of attachment with this attribute may 513 trigger the setup of bindings. SAVI devices will set up bindings on 514 points of attachment with this attribute based on the data-triggered 515 process described in Section 7. 517 If the DHCP-Snooping attribute is configured on a point of 518 attachment, the bindings on this attachment are set up based on DHCP 519 message snooping. However, in some scenarios, a DHCP client may use 520 a DHCP address without the DHCP address assignment procedure being 521 performed on its current attachment. For such attached devices, the 522 Data Snooping Process, which is described in Section 7, is necessary. 523 This attribute is configured on such attachments. The usage of this 524 attribute is further discussed in Section 7. 526 Since some networks require DHCP deployment and others avoid it, 527 there is no obvious universal default value for the Data-Snooping 528 Attribute. Hence, the Data-Snooping Attribute should default to 529 FALSE, and a mechanism should be implemented to conveniently set it 530 to TRUE on all points of attachment for which the Trust attribute is 531 FALSE. 533 4.2.5. Validating Attribute 535 The "Validating Attribute" is a Boolean attribute. It indicates 536 whether packets from the corresponding attachment will have their IP 537 source addresses validated based on binding entries on the 538 attachment. 540 If it is TRUE, packets coming from attachments with this attribute 541 will be validated based on binding entries on the attachment as 542 specified in Section 8. If it is FALSE, they will not. Since the 543 binding table is used in common with other SAVI algorithms, it merely 544 signifies whether the check will be done, not whether it will be done 545 for SAVI-DHCP originated bindings. 547 This attribute is by default the inverse of the Trust attribute; 548 source addresses on untrusted links are validated by default. It MAY 549 be set FALSE by the administration. 551 The expected use case is when SAVI is used to monitor but not block 552 forged transmissions. The network manager, in that case, may set the 553 DHCP-Snooping and/or Data-Snooping attribute TRUE but the Validating 554 attribute FALSE. 556 4.2.6. Table of Mutual Exclusions 558 Different types of attributes may indicate mutually exclusive actions 559 on a packet. Mutually exclusive attributes MUST NOT be set TRUE on 560 the same attachment. The compatibility of different attributes is 561 listed in Figure 2. Note that although Trust and DHCP-Trust are 562 compatible, there is no need to configure DHCP-Trust to TRUE on an 563 attachment with Trust attribute TRUE. 565 +----------+----------+----------+----------+----------+----------+ 566 | | | | DHCP- | Data- | | 567 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 568 +----------+----------+----------+----------+----------+----------+ 569 | | | | mutually | mutually | mutually | 570 | Trust | - |compatible| exclusive| exclusive| exclusive| 571 +----------+----------+----------+----------+----------+----------+ 572 | | | | | | | 573 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 574 +----------+----------+----------+----------+----------+----------+ 575 |DHCP- |mutually | | | | | 576 |Snooping |exclusive |compatible| - |compatible|compatible| 577 +----------+----------+----------+----------+----------+----------+ 578 |Data- |mutually | | | | | 579 |Snooping |exclusive |compatible|compatible| - |compatible| 580 +----------+----------+----------+----------+----------+----------+ 581 | |mutually | | | | | 582 |Validating|exclusive |compatible|compatible|compatible| - | 583 +----------+----------+----------+----------+----------+----------+ 585 Figure 2: Table of Mutual Exclusions 587 4.3. Perimeter 589 4.3.1. SAVI-DHCP Perimeter Overview 591 SAVI devices form a perimeter separating trusted and untrusted 592 regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]). 593 The perimeter is primarily designed for scalability. It has two 594 implications. 596 o SAVI devices only need to establish bindings for directly attached 597 clients, or clients indirectly attached through a non-SAVI 598 protected device, rather than all of the clients in the network. 600 o Each SAVI device only needs to validate the source addresses in 601 traffic from clients attached to it, without checking all the 602 traffic passing by. 604 Consider the example in Figure 1. The protection perimeter is formed 605 by SAVI Devices A, B and C. In this case, SAVI device B does not 606 create a binding for client A. However, because SAVI device A 607 filters spoofed traffic from client A, SAVI device B can avoid 608 receiving spoofed traffic from client A. 610 The perimeter in SAVI-DHCP is not only a perimeter for data packets, 611 but also a perimeter for DHCP messages. DHCP server response 612 messages incoming across the perimeter will be dropped (Section 8). 613 The placement of the DHCP Relay and DHCP Server, which are not 614 involved in [RFC6620], is related to the construction of the 615 perimeter. The requirement on the placement and configuration of 616 DHCP Relay and DHCP Server are discussed in Section 4.3.3. 618 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 620 A perimeter separating trusted and untrusted regions of the network 621 is formed as follows: 623 (1) Configure the Validating and DHCP-Snooping attributes TRUE on 624 the direct attachments of all DHCP clients. 626 (2) Configure the Validating and DHCP-Snooping attributes TRUE on 627 the indirect attachments of all DHCP clients (i.e., DHCP clients 628 on protected links). 630 (3) Configure the Trust attribute TRUE on the attachments to other 631 SAVI devices. 633 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 634 are attached only to SAVI devices, set the Trust attribute TRUE 635 on their attachments. 637 (5) Configure the DHCP-Trust attribute TRUE on the direct 638 attachments to trusted DHCP relays and servers. 640 In this way, the points of attachments with the Validating attribute 641 TRUE (and generally together with attachments of unprotected devices) 642 on SAVI devices can form a perimeter separating DHCP clients and 643 trusted devices. Data packet checks are only performed on the 644 perimeter. The perimeter is also a perimeter for DHCP messages. The 645 DHCP-Trust attribute is only TRUE on links inside the perimeter. 646 Only DHCP Server-to-Client messages originated within the perimeter 647 are trusted. 649 4.3.3. On the Placement of the DHCP Server and Relay 651 As a result of the configuration guidelines, SAVI devices only trust 652 DHCP Server-to-Client messages originated inside the perimeter. 653 Thus, the trusted DHCP Relays and DHCP Servers must be placed within 654 the perimeter. DHCP Server-to-Client messages will be filtered on 655 the perimeter. Server-to-relay messages will not be filtered, as 656 they are within the perimeter. In this way, DHCP Server-to-Client 657 messages from bogus DHCP servers are filtered on the perimeter, 658 having entered through untrusted points of attachment. The SAVI 659 devices are protected from forged DHCP messages. 661 DHCP Server-to-Client messages arriving at the perimeter from outside 662 the perimeter are not trusted. There is no distinction between a 663 DHCP server owned and operated by the correct administration but 664 outside the SAVI perimeter and a bogus DHCP server. For example, in 665 Figure 1, DHCP server A is valid, but it is attached to Non-SAVI 666 device 1. A bogus DHCP server is also attached Non-SAVI device 1. 667 While one could imagine a scenario in which the valid one had a 668 statistically configured port number and MAC address, and therefore a 669 binding, by default SAVI-DHCP cannot distinguish whether a message 670 received from the port of Non-SAVI device 1 is from DHCP server A or 671 the bogus DHCP server. If the DHCP server A is contained in the 672 perimeter, Non-SAVI device 1 will also be contained in the perimeter. 673 Thus, the DHCP server A cannot be contained within the perimeter 674 apart from manual configuration of the binding anchor. 676 Another consideration on the placement is that if the DHCP server/ 677 relay is not inside the perimeter, the SAVI devices may not be able 678 to set up bindings correctly, because the SAVI devices may not be on 679 the path between the clients and the server/relay, or the DHCP 680 messages are encapsulated (e.g., Relay-reply and Relay-forward). 682 4.3.4. An Alternative Deployment 684 In common deployment practice, the traffic from the unprotected 685 network is treated as trustworthy, which is to say that it is not 686 filtered. In such a case, the Trust attribute can be set TRUE on the 687 unprotected link. If Non-SAVI devices, or a number of connected Non- 688 SAVI devices, are only attached to SAVI devices and unprotected 689 devices, their attachment to SAVI devices can have the Trust 690 attribute set TRUE. Then an unclosed perimeter will be formed, as 691 illustrated in Figure 3. 693 | . . Protection | 694 | | | Perimeter | 695 | | | | 696 | Unprotected | | Unprotected | 697 | Link | | Link | 698 | | | | 699 | | | | 700 | +----+---+ +----+---+ +--------+ | 701 | |SAVI +----+Non-SAVI+----+SAVI | | 702 | |Device | |Device | |Device | | 703 | +----+---+ +--------+ +----+---+ | 704 | | | | 705 \_____________+___________________________+________/ 706 | | 707 | | 708 +--------+ +--------+ 709 |DHCP | |DHCP | 710 |Client | |Client | 711 +--------+ +--------+ 713 Figure 3: Alternative Perimeter Configuration 715 4.3.5. Considerations regarding Binding Anchors 717 The strength of this binding-based mechanism depends on the strength 718 of the binding anchor. The sample binding anchors in [RFC7039] have 719 the property that they associate an IP address with a direct physical 720 or secure virtual interface such as a switch port, a subscriber 721 association, or a security association. In addition, especially in 722 the case that a protected non-SAVI device such as a desktop switch or 723 a hub is between the client and SAVI devices, they MAY be extended to 724 also include a MAC address or other link-layer attribute. In short, 725 a binding anchor is intended to associate an IP address with 726 something unspoofable that identifies a single client system or one 727 of its interfaces; this may be a physical or virtual interface or 728 that plus disambiguating link-layer information. 730 If the binding anchor is spoofable, such as a plain MAC address, or 731 non-exclusive, such as a switch port extended using a non-SAVI 732 device, an attacker can use a forged binding anchor to evade 733 validation. Indeed, using a binding anchor that can be easily 734 spoofed can lead to worse outcomes than allowing spoofed IP traffic. 735 Thus, a SAVI device MUST use a non-spoofable and exclusive binding 736 anchor. 738 4.4. Other Device Configuration 740 In addition to a possible binding anchor configuration specified in 741 Section 4.2, an implementation has the following configuration 742 requirements: 744 (1) Address configuration. For DHCPv4: the SAVI device MUST have an 745 IPv4 address. For DHCPv6: the client of a SAVI device MUST have 746 a link-local address; when the DHCPv6 server is not on the same 747 link as the SAVI device, the SAVI device MUST also have an IPv6 748 address of at least the same scope as the DHCPv6 Server. 750 (2) DHCP server address configuration: a SAVI device MUST store the 751 list of the DHCP server addresses that it could contact during a 752 Lease query process. 754 (3) A SAVI device may also require security parameters, such as pre- 755 configured keys to establish a secure connection for the Lease 756 query process [RFC4388][RFC5007] connection. 758 5. Binding State Table (BST) 760 The Binding State Table, which may be implemented centrally in the 761 switch or distributed among its ports, is used to contain the 762 bindings between the IP addresses assigned to the attachments and the 763 corresponding binding anchors of the attachments. Note that in this 764 description, there is a binding entry for each IPv4 or IPv6 address 765 associated with each binding anchor, and there may be several of each 766 such address, especially if the port is extended using a protected 767 non-SAVI device. Each binding entry, has 5 fields: 769 o Binding Anchor(Anchor): the binding anchor, i.e., one or more 770 physical and/ or link-layer properties of the attachment. 772 o IP Address(Address): the IPv4 or IPv6 address assigned to the 773 attachment by DHCP. 775 o State: the state of the binding. Possible values of this field 776 are listed in Section 6.2 and Section 7.3. 778 o Lifetime: the remaining seconds of the binding. Internally, this 779 MAY be stored as the timestamp value at which the lifetime 780 expires. 782 o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the 783 corresponding DHCP transaction. TID field is used to associate 784 DHCP Server-to-Client messages with corresponding binding entries. 786 o Timeouts: the number of timeouts that expired in the current state 787 (only used in Data Snooping Process, see Section 7.) 789 The IA is not present in the BST for three reasons: 791 o The lease of each address in one IA is assigned separately. 793 o When the binding is set up based on data snooping, the IA cannot 794 be recovered from the lease query protocol. 796 o DHCPv4 does not define an IA. 798 An example of such a table is shown in Figure 4. 800 +---------+----------+-----------+-----------+--------+----------+ 801 | Anchor | Address | State | Lifetime | TID | Timeouts | 802 +---------+----------+-----------+-----------+--------+----------+ 803 | Port_1 | IP_1 | BOUND | 65535 | TID_1 | 0 | 804 +---------+----------+-----------+-----------+--------+----------+ 805 | Port_1 | IP_2 | BOUND | 10000 | TID_2 | 0 | 806 +---------+----------+-----------+-----------+--------+----------+ 807 | Port_2 | IP_3 | INIT_BIND | 1 | TID_3 | 0 | 808 +---------+----------+-----------+-----------+--------+----------+ 810 Figure 4: Example Binding State Table 812 6. DHCP Snooping Process 814 This section specifies the process of setting up bindings based on 815 DHCP snooping. This process is illustrated using a state machine. 817 6.1. Rationale 819 The rationale of the DHCP Snooping Process is that if a DHCP client 820 is legitimately using a DHCP-assigned address, the DHCP address 821 assignment procedure that assigns the IP address to the client must 822 have been performed via the client's point of attachment. This 823 assumption works when the SAVI device is always on the path(s) from 824 the DHCP client to the DHCP server(s)/relay(s). Without considering 825 the movement of DHCP clients, the SAVI device should be the cut 826 vertex whose removal will separate the DHCP client and the remaining 827 network containing the DHCP server(s)/ and relay(s). For most of the 828 networks whose topologies are simple, it is possible to deploy this 829 SAVI function at proper devices to meet this requirement. 831 However, if there are multiple paths from a DHCP client to the DHCP 832 server and the SAVI device is only on one of them, there is an 833 obvious failure case: the SAVI device may not be able to snoop the 834 DHCP procedure. Host movement may also make this requirement 835 difficult to meet. For example, when a DHCP client moves from one 836 attachment to another attachment in the same network, it may fail to 837 reinitialize its interface or send a Confirm message because of 838 incomplete protocol implementation. Thus, there can be scenarios in 839 which only performing this DHCP Snooping Process is insufficient to 840 set up bindings for all the valid DHCP addresses. These exceptions 841 and the solutions are discussed in Section 7. 843 6.2. Binding States Description 845 Following binding states are present in this process and the 846 corresponding state machine: 848 NO_BIND: No binding has been set up. 850 INIT_BIND: A potential binding has been set up. 852 BOUND: The binding has been set up. 854 6.3. Events 856 This section describes events in this process and the corresponding 857 state machine transitions. The DHCP message categories (e.g., DHCPv4 858 Discover) defined in Section 3 are used extensively in the 859 definitions of events and elsewhere in the state machine definition. 860 If an event will trigger the creation of a new binding entry, the 861 binding entry limit on the binding anchor MUST NOT be exceeded. 863 6.3.1. Timer Expiration Event 865 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 867 6.3.2. Control Message Arriving Events 869 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 870 received. 872 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 874 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 876 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 877 received. 879 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 881 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 882 option is received. 884 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 886 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 887 received. 889 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 890 received. 892 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer to 893 section 4.3.3 of [RFC5007]) is received. 895 Note: the events listed here do not cover all the DHCP messages in 896 Section 3. The messages which do not really determine address usage 897 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 898 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 899 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 900 to section 6.4.2.1), are not included. Note also that DHCPv4 901 DHCPLEASEQUERY is not used in the DHCP Snooping process to avoid 902 confusion with Section 7. Also since the LEASEQUERY should have been 903 originated by the SAVI Device itself, the destination check should 904 verify that the message is directed to this SAVI device - and it 905 should not be forwarded once it has been processed here. 907 Moreover, only if a DHCP message can pass the following checks, the 908 corresponding event is regarded as a valid event: 910 o Attribute check: the DHCP Server-to-Client messages and 911 LEASEQUERY-REPLY should be from attachments with DHCP-Trust 912 attribute; the DHCP Client-Server messages should be from 913 attachments with DHCP-Snooping attribute. 915 o Destination check: the DHCP Server-to-Client messages should be 916 destined to attachments with DHCP-Snooping attribute. This check 917 is performed to ensure the binding is set up on the SAVI device 918 which is nearest to the destination client. 920 o Binding anchor check: the DHCP Client-Server messages which may 921 trigger modification or removal of an existing binding entry must 922 have a matching binding anchor with the corresponding entry. 924 o TID check: the DHCP Server-to-Client/Client-Server messages which 925 may cause modification on existing binding entries must have 926 matched TID with the corresponding entry. Note that this check is 927 not performed on Lease query and Lease query-reply messages as 928 they are exchanged between the SAVI devices and the DHCP servers. 930 Besides, this check is not performed on DHCP Renew/Rebind 931 messages. 933 o Binding limitation check: the DHCP messages must not cause new 934 binding setup on an attachment whose binding entry limitation has 935 been reached. (refer to Section 11.5). 937 o Address check: the source address of the DHCP messages should pass 938 the check specified in Section 8.2. 940 On receiving a DHCP message without triggering a valid event, the 941 state will not change, and the actions will not be performed. Note 942 that if a message does not trigger a valid event but it can pass the 943 checks in Section 8.2, it MUST be forwarded. 945 6.4. The State Machine of DHCP Snooping Process 947 This section specifies state transitions and their corresponding 948 actions. 950 6.4.1. Initial State: NO_BIND - No binding has been set up 952 6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request 953 message is received 955 The SAVI device MUST forward the message. 957 The SAVI device will generate an entry in the BST. The Binding 958 anchor field is set to the binding anchor of the attachment from 959 which the message is received. The State field is set to INIT_BIND. 960 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 961 field is set to the TID of the message. If the message is DHCPv4 962 Request, the Address field can be set to the address to request, 963 i.e., the 'requested IP address'. An example of the entry is 964 illustrated in Figure 5. 966 +--------+-------+---------+-----------------------+-----+----------+ 967 | Anchor |Address| State | Lifetime | TID | Timeouts | 968 +--------+-------+---------+-----------------------+-----+----------+ 969 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | 970 +--------+-------+---------+-----------------------+-----+----------+ 972 Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot 973 triggered initialization 975 Resulting state: INIT_BIND - A potential binding has been set up 977 6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received 979 The SAVI device MUST forward the message. 981 The SAVI device will generate an entry in the BST. The Binding 982 anchor field is set to the binding anchor of the attachment from 983 which the message is received. The State field is set to INIT_BIND. 984 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 985 field is set to the TID of the message. If the message is DHCPv4 986 Reboot, the Address field can be set to the address to request, i.e., 987 the 'requested IP address'. An example of the entry is illustrated 988 in Figure 5. 990 Resulting state: INIT_BIND - A potential binding has been set up 992 6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message 993 with Rapid Commit option is received 995 The SAVI device MUST forward the message. 997 The SAVI device will generate an entry in the BST. The Binding 998 anchor field is set to the binding anchor of the attachment from 999 which the message is received. The State field is set to INIT_BIND. 1000 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 1001 field is set to the TID of the message. An example of the entry is 1002 illustrated in Figure 5. 1004 Resulting state: INIT_BIND - A potential binding has been set up 1006 6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received 1008 The SAVI device MUST forward the message. 1010 The SAVI device will generate corresponding entries in the BST for 1011 each address in each Identity Association (IA) option of the Confirm 1012 message. The Binding anchor field is set to the binding anchor of 1013 the attachment from which the message is received. The State field 1014 is set to INIT_BIND. The Lifetime field is set to be 1015 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 1016 message. The Address field is set to the address(es) to confirm. An 1017 example of the entries is illustrated in Figure 6. 1019 +--------+-------+---------+-----------------------+-----+----------+ 1020 | Anchor |Address| State | Lifetime | TID | Timeouts | 1021 +--------+-------+---------+-----------------------+-----+----------+ 1022 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | 1023 +--------+-------+---------+-----------------------+-----+----------+ 1024 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | 1025 +--------+-------+---------+-----------------------+-----+----------+ 1027 Figure 6: Binding entry in BST on Confirm triggered initialization 1029 Resulting state: INIT_BIND - A potential binding has been set up 1031 6.4.1.5. Events that cannot happen in the NO_BIND state 1033 o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires 1035 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1036 received 1038 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 1039 received 1041 o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received 1043 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1044 received 1046 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1047 received 1049 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is 1050 received 1052 These cannot happen because they are each something that happens 1053 AFTER a binding has been created. 1055 6.4.2. Initial State: INIT_BIND - A potential binding has been set up 1057 6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1058 is received 1060 The message MUST be forwarded to the corresponding client. 1062 If the message is DHCPv4 ACK, the Address field of the corresponding 1063 entry (i.e., the binding entry whose TID is the same of the message) 1064 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 1065 The Lifetime field is set to the sum of the lease time in ACK message 1066 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1068 If the message is DHCPv6 Reply, there are following cases: 1070 1. If the status code is not "Success", no modification on 1071 corresponding entries will be made. Corresponding entries will 1072 expire automatically if no "Success" Reply is received during the 1073 lifetime. The entries are not removed immediately due to the 1074 client may be able to use the addresses whenever a "Success" 1075 Reply is received ("If the client receives any Reply messages 1076 that do not indicate a NotOnLink status, the client can use the 1077 addresses in the IA and ignore any messages that indicate a 1078 NotOnLink status." [RFC3315]). 1080 2. If the status code is "Success", the SAVI device checks the IA 1081 options in the Reply message. 1083 A. If there are IA options in the Reply message, the SAVI device 1084 checks each IA option. When the first assigned address is 1085 found, the Address field of the binding entry with matched 1086 TID is set to the address. The Lifetime field is set to the 1087 sum of the lease time in Reply message and 1088 MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1089 If there are more than one address assigned in the message, 1090 new binding entries are set up for the remaining address 1091 assigned in the IA options. An example of the entries is 1092 illustrated in Figure 8. SAVI devices do not specially 1093 process IA options with NoAddrsAvail status, because there 1094 should be no address contained in such IA options. 1096 B. Otherwise, the DHCP Reply message is in response to a Confirm 1097 message. The state of the binding entries with matched TID 1098 is changed to BOUND. Because [RFC3315] does not require 1099 lease time of addresses to be contained in the Reply message, 1100 the SAVI device SHOULD send a LEASEQUERY [RFC5007] message 1101 querying by IP address to All_DHCP_Servers multicast address 1102 [RFC3315] or a list of configured DHCP server addresses. The 1103 Lease query message is generated for each IP address if 1104 multiple addresses are confirmed. The Lifetime of 1105 corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If 1106 there is no response message after MAX_LEASEQUERY_DELAY, send 1107 the LEASEQUERY message again. An example of the entries is 1108 illustrated in Figure 7. If the SAVI device does not send 1109 the LEASEQUERY message, a pre-configured lifetime 1110 DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 1111 (Note: it is RECOMMENDED to use T1 configured on DHCP servers 1112 as the DHCP_DEFAULT_LEASE.) 1114 Note: the SAVI devices do not check if the assigned addresses are 1115 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 1116 only source of valid addresses. However, the DHCP servers should be 1117 configured to make sure no duplicated addresses are assigned. 1119 +--------+-------+-------+------------------------+-----+----------+ 1120 | Anchor |Address| State | Lifetime | TID | Timeouts | 1121 +--------+-------+-------+------------------------+-----+----------+ 1122 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 | 1123 +--------+-------+-------+------------------------+-----+----------+ 1124 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 | 1125 +--------+-------+-------+------------------------+-----+----------+ 1127 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1128 Confirm 1130 Transition 1131 +--------+-------+-------+------------------------+-----+----------+ 1132 | Anchor |Address| State | Lifetime | TID | Timeouts | 1133 +--------+-------+-------+------------------------+-----+----------+ 1134 | Port_1 | Addr1 | BOUND |Lease time+ | TID | 0 | 1135 | | | |MAX_DHCP_RESPONSE_TIME | | | 1136 +--------+-------+-------+------------------------+-----+----------+ 1137 | Port_1 | Addr2 | BOUND |Lease time+ | TID | 0 | 1138 | | | |MAX_DHCP_RESPONSE_TIME | | | 1139 +--------+-------+-------+------------------------+-----+----------+ 1141 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 1142 Request 1144 Resulting state: BOUND - The binding has been set up 1146 6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1147 expires 1149 The entry MUST be deleted from BST. 1151 Resulting state: An entry that has been deleted from the BST may be 1152 considered to be in the state "NO_BIND" - No binding has been set up. 1154 6.4.2.3. Events that are ignored in INIT_BIND 1156 If no DHCP Server-to-Client messages which assign addresses or 1157 confirm addresses are received, corresponding entries will expire 1158 automatically. Thus, other DHCP Server-to-Client messages (e.g., 1159 DHCPv4 NAK) are not specially processed. 1161 As a result, the following events, should they occur, are ignored 1162 until either a DHCPv4 ACK or a DHCPv6 Reply message is received or 1163 the lifetime of the binding entry expires. 1165 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1166 received 1168 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1170 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1172 o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1173 received 1175 o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is 1176 received 1178 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1179 Commit option is received 1181 o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 1182 received 1184 o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 1185 received 1187 o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is 1188 received 1190 In each case, the message MUST be forwarded. 1192 Resulting state: INIT_BIND - A potential binding has been set up 1194 6.4.3. Initial State: BOUND - The binding has been set up 1196 6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 1197 expires 1199 The entry MUST be deleted from BST. 1201 Resulting state: An entry that has been deleted from the BST may be 1202 considered to be in the state "NO_BIND" - No binding has been set up. 1204 6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline 1205 message is received 1207 The message MUST be forwarded. 1209 The SAVI device first gets all the addresses ("Requested IP address" 1210 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1211 IA options of DHCPv6 Decline/Release) to decline/release in the 1212 message. Then the corresponding entries MUST be removed. 1214 Resulting state in each relevant BST entry: An entry that has been 1215 deleted from the BST may be considered to be in the state "NO_BIND" - 1216 No binding has been set up. 1218 6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release 1219 message is received 1221 The message MUST be forwarded. 1223 The SAVI device first gets all the addresses ("Requested IP address" 1224 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1225 IA options of DHCPv6 Decline/Release) to decline/release in the 1226 message. Then the corresponding entries MUST be removed. 1228 Resulting state in each relevant BST entry: An entry that has been 1229 deleted from the BST may be considered to be in the state "NO_BIND" - 1230 No binding has been set up. 1232 6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind 1233 message is received 1235 The message MUST be forwarded. 1237 In such case, a new TID will be used by the client. The TID field of 1238 the corresponding entries MUST be set to the new TID. Note that TID 1239 check will not be performed on such messages. 1241 Resulting state: BOUND: The binding has been set up 1243 6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew 1244 message is received 1246 The message MUST be forwarded. 1248 In such case, a new TID will be used by the client. The TID field of 1249 the corresponding entries MUST be set to the new TID. Note that TID 1250 check will not be performed on such messages. 1252 Resulting state: BOUND: The binding has been set up 1254 6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 1255 is received 1257 The message MUST be forwarded. 1259 The DHCP Reply messages received in current states should be in 1260 response to DHCP Renew/Rebind. 1262 If the message is DHCPv4 ACK, the SAVI device updates the binding 1263 entry with matched TID, with the Lifetime field set to be the sum of 1264 the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in 1265 the state BOUND. 1267 If the message is DHCPv6 Reply, the SAVI device checks each IA 1268 Address option in each IA option. For each: 1270 1. If the IA entry in the REPLY message has the status "NoBinding", 1271 there is no address in the option, and no operation on an address 1272 is performed. 1274 2. If the valid lifetime of an IA address option is 0, the binding 1275 entry with matched TID and address is removed, leaving it 1276 effectively in the state NO_BIND. 1278 3. Otherwise, set the Lifetime field of the binding entry with 1279 matched TID and address to be the sum of the new valid lifetime 1280 and MAX_DHCP_RESPONSE_TIME, leaving the entry in the state BOUND. 1282 Resulting state: NO_BIND or BOUND, as specified. 1284 6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 1285 LEASEQUERY_REPLY is received 1287 The message MUST be forwarded. 1289 The message should be in response to the Lease query message sent in 1290 Section 6.4.2. The related binding entry can be determined based on 1291 the address in the IA Address option in the Lease query-reply 1292 message. The Lifetime field of the corresponding binding entry is 1293 set to the sum of the lease time in the LEASEQUERY-REPLY message and 1294 MAX_DHCP_RESPONSE_TIME. 1296 Resulting state: BOUND: The binding has been set up 1298 6.4.3.8. Events not processed in the state BOUND 1300 The following events are ignored if received while the indicated 1301 entry is in the state BOUND. Any required action will be the result 1302 of the next message in the client/server exchange. 1304 o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 1305 received 1307 o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received 1309 o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received 1310 o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid 1311 Commit option is received 1313 6.4.4. Table of State Machine 1315 The main state transits are listed as follows. Note that not all the 1316 details are specified in the table and the diagram. 1318 State Event Action Next State 1319 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1320 INIT_BIND RPL Record lease time BOUND 1321 (send lease query if no lease) 1322 INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1323 BOUND RLS/DCL Remove entry NO_BIND 1324 BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND 1325 BOUND RPL Set new lifetime BOUND 1326 BOUND LQR Record lease time BOUND 1328 Figure 9: State Transition Table 1330 RQ: EVE_DHCP_REQUEST 1332 CF: EVE_DHCP_CONFIRM 1334 RC: EVE_DHCP_SOLICIT_RC 1336 RE: EVE_DHCP_REBOOT 1338 RPL: EVE_DHCP_REPLY 1340 DCL: EVE_DHCP_DECLINE 1342 RLS: EVE_DHCP_RELEASE 1344 LQR: EVE_DHCP_LEASEQUERY 1345 +-------------+ 1346 | | 1347 /--------+ NO_BIND |<--------\ 1348 | ----->| | | 1349 | | +-------------+ |EVE_DHCP_RELEASE 1350 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1351 EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE 1352 EVE_DHCP_SOLICIT_RC| | | 1353 EVE_DHCP_REBOOT | | | 1354 | | | 1355 | | | 1356 v | | 1357 +-------------+ +------------+ 1358 | | EVE_DHCP_REPLY | | 1359 | INIT_BIND --------------------->| BOUND |<-\ 1360 | | | | | 1361 +-------------+ +------------+ | 1362 | | 1363 \--------/ 1364 EVE_DHCP_REPLY 1365 EVE_DHCP_LEASEQUERY 1367 Figure 10: Diagram of Transit 1369 7. Data Snooping Process 1370 7.1. Scenario 1372 The rationale of the DHCP Snooping Process specified in Section 6 is 1373 that if a DHCP client's use of a DHCP address is legitimate, the 1374 corresponding DHCP address assignment procedure must have been 1375 finished during the attachment of the DHCP client. This is the case 1376 when the SAVI device is continuously on the path(s) from the DHCP 1377 client to the DHCP server(s)/relay(s). However, there are two cases 1378 in which this does not work: 1380 o Multiple paths: there is more than one feasible link-layer path 1381 from the client to the DHCP server/relay, and the SAVI device is 1382 not on every one of them. The client may get its address through 1383 one of the paths does not pass through the SAVI device, but 1384 packets from the client can travel on paths that pass through the 1385 SAVI device, such as when the path through the link layer network 1386 changes. Because the SAVI device could not snoop the DHCP packet 1387 exchange procedure, the DHCP Snooping Process cannot set up the 1388 corresponding binding. 1390 o Dynamic path: there is only one feasible link-layer path from the 1391 client to the DHCP server/relay, but the path is dynamic due to 1392 topology change (for example, some link becomes broken due to 1393 failure or some planned change) or link-layer path change. This 1394 situation also covers the local-link movement of clients without 1395 address confirm/re-configuration process. For example, a host 1396 changes its attached switch port in a very short time. In such 1397 cases, the DHCP Snooping Process will not set up the corresponding 1398 binding. 1400 The Data Snooping Process can avoid the permanent blocking of 1401 legitimate traffic in case one of these two exceptions occurs. This 1402 process is performed on attachments with the Data-Snooping attribute. 1403 Data packets without a matching binding entry may trigger this 1404 process to set up bindings. 1406 Snooping data traffic introduces considerable burden on the processor 1407 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1408 overhead of this process, the implementation of this process is 1409 OPTIONAL. This function SHOULD be enabled unless the implementation 1410 is known to be used in the scenarios without the above exceptions. 1411 For example, if the implementation is to be used in networks with 1412 tree topology and without host local-link movement, there is no need 1413 to implement this process in such scenarios. 1415 This process is not intended to set up a binding whenever a data 1416 packet without a matched binding entry is received. Instead, 1417 unmatched data packets trigger this process probabilistically and 1418 generally a number of unmatched packets will be discarded before the 1419 binding is set up. The parameter(s) of this probabilistic process 1420 SHOULD be configurable, defaulting to a situation where data snooping 1421 is disabled. 1423 7.2. Rationale 1425 This process makes use of NS/ARP and DHCP LEASEQUERY to set up 1426 bindings. If an address is not used by another client in the 1427 network, and the address has been assigned in the network, the 1428 address can be bound with the binding anchor of the attachment from 1429 which the unmatched packet is received. 1431 The Data Snooping Process provides an alternative path for binding 1432 entries to reach the BOUND state in the exceptional cases explained 1433 in Section 7.1 when there are no DHCP messages that can be snooped by 1434 the SAVI device. 1436 In some of the exceptional cases (especially the dynamic topology 1437 case), by the time the binding has reached the BOUND state the DHCP 1438 messages may be passing through the SAVI device. In this case the 1439 events driven by DHCP messages that are expected in the BOUND state 1440 in the DHCP Snooping Process may occur and the binding can be handled 1441 by the DHCP Snooping Process state machine. 1443 In any event, the lease expiry timeout event will occur even if no 1444 others do. This will cause the binding to be deleted and the state 1445 to logically return to NO_BIND state. Either the DHCP or the Data 1446 Snooping Process will be reinvoked if the lease is still place. If 1447 DHCP messages are still not passing through the SAVI device, there 1448 will be a brief disconnection during which data packets passing 1449 through the SAVI device will be dropped. The probabilistic 1450 initiation of the Data Snooping Process can then take over again and 1451 return the binding state to BOUND in due course. 1453 The security issues concerning this process are discussed is 1454 Section 11.1. 1456 7.3. Additional Binding States Description 1458 In addition to NO_BIND and BOUND from Section 6.2, three new states 1459 used in this process are listed here. The INIT_BIND state is not 1460 used, as it is entered by observing a DHCP message. 1462 DETECTION: The address in the entry is undergoing local duplication 1463 detection. 1465 RECOVERY: The SAVI device is querying the assignment and lease time 1466 of the address in the entry through DHCP lease query. 1468 VERIFY: The SAVI device is verifying that the device connected to the 1469 attachment point has a hardware address that matches the one returned 1470 in the DHCP lease query. 1472 Because the mechanisms used for the operations carried out while the 1473 binding is in these three states operate over unreliable protocols, 1474 each operation is carried out twice with a timeout that is triggered 1475 if no response is received. 1477 7.4. Events 1479 To handle the Data Snooping Process, five extra events, described 1480 here, are needed in addition to those used by the DHCP Snooping 1481 Process (see Section 6.3). If an event will trigger the creation of 1482 a new binding entry, the binding entry limit on the binding anchor 1483 MUST NOT be exceeded. 1485 EVE_DATA_UNMATCH: A data packet without a matched binding is 1486 received. 1488 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1489 against an address in DETECTION state is received from a host other 1490 than the one for which the entry was added (i.e., a host attached at 1491 another point than the one on which the triggering data packet was 1492 received). 1494 EVE_DATA_LEASEQUERY: 1496 o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1497 is received. 1499 o IPv6: A successful LEASEQUERY-REPLY is received. 1501 EVE_DATA_VERIFY: An ARP Reply/Neighbor Advertisement(NA) message has 1502 been received in the VERIFY state from the device connected to the 1503 attachment point on which the data packet was received. 1505 The triggering packet should pass the following checks to trigger a 1506 valid event: 1508 o Attribute check: the data packet should be from attachments with 1509 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY-REPLY 1510 messages should be from attachments with DHCP-Snooping attribute. 1512 o Binding limitation check: the data messages must not cause new 1513 binding setup on an attachment whose binding entry limitation has 1514 been reached. (refer to Section 11.5). 1516 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1517 DHCP Lease query messages must pass the check specified in 1518 Section 8.2. For EVE_DATA_CONFLICT and EVE_DATA_VERIFY, the 1519 source address and target address of the ARP or NA messages must 1520 pass the check specified in Section 8.2. 1522 o Interval check: the interval between two successive 1523 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1524 smaller than DATA_SNOOPING_INTERVAL. 1526 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have 1527 matched TID with the corresponding entry. 1529 o Prefix check: the source address of the data packet should be of a 1530 valid local prefix, as specified in section 7 of [RFC7039]. 1532 EVE_DATA_EXPIRE: A timer expires indicating that a response to a 1533 hardware address verification message sent in the VERIFY state has 1534 not been received within the specified DETECTION_TIMEOUT period. 1536 EVE_ENTRY_EXPIRE: A timer expires after the Lifetime indicated in the 1537 relevant BST entry has elapsed. This is identical to the usage in 1538 the DHCP Snooping Process. 1540 7.5. Message Sender Functions 1542 The Data Snooping Process involves sending three different messages 1543 to other network devices. Each message may be sent up to twice since 1544 they are sent over unreliable transports and are sent in different 1545 states. The functions defined in this section specify the messages 1546 to be sent in the three cases. In each case the message to be sent 1547 depends on whether the triggering data packet is an IPv4 or an IPv6 1548 packet. 1550 7.5.1. Duplicate Detection Message Sender 1552 Send a message to check if the source address in the data packet that 1553 triggered the data snooping process has a local conflict (that is, it 1554 uses an address that is being used by another node): 1556 IPv4 address: broadcast an Address Resolution Protocol (ARP) Request 1557 [RFC0826] or an ARP probe [RFC5227] for the address to the 1558 local network. An ARP Response will be expected from the 1559 device on the attachment point on which the triggering data 1560 packet was received. An ARP Reply received on any other port 1561 indicates a duplicate address. 1563 IPv6 address: send a Duplicate Address Detection (DAD) message 1564 (Neighbor Solicitation message) to the solicited node multicast 1565 address [RFC4861] targeting the address. Ideally, only the 1566 host on that point of attachment responds with a Neighbor 1567 Advertisement. A Neighbor Advertisement received on any other 1568 port indicates a duplicate address. 1570 As both the ARP and DAD processes are unreliable (either the packet 1571 to or from the other system may be lost in transit, see [RFC6620]), 1572 if there is no response after the DETECTION_TIMEOUT an 1573 EVE_ENTRY_EXPIRE is generated. 1575 7.5.2. Lease Query Message Sender 1577 Send a DHCP lease query message to the DHCP server(s) to determine if 1578 it has given out a lease for the source address in the triggering 1579 data packet. A list of authorized DHCP servers is kept by the SAVI 1580 device. The list should be either pre-configured with the IPv4 and/ 1581 or IPv6 addresses or dynamically discovered: For networks using IPV4 1582 this can be done by sending DHCPv4 Discover messages and parsing the 1583 returned DHCPv4 Offer messages; for networks using IPv6 discovery can 1584 be done by sending DHCPv6 SOLICIT messages and parsing the returned 1585 ADVERTISE messages. See Section 11.2 regarding the securing of the 1586 process and the advisability of using the DHCPv6 1587 All_DHCP_Relay_Agents_and_Servers or All_DHCP_Servers multicast 1588 addresses. The same TID should be used for all lease query messages 1589 sent in response to a triggering data message on an attachment point. 1590 The TID is generated if the TID field in the BST entry is empty and 1591 recorded in the TID field of the BST entry when the first message is 1592 sent. Subsequent messages use the TID from the BST entry. 1594 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1595 by IP address to each DHCPv4 server in the list of authorized 1596 servers with an IP Address Lease Time option (option 51). If the 1597 server has a valid lease for the address, the requested 1598 information will be returned in a DHCPLEASEACTIVE message. 1600 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1601 address to each DHCPv6 server in the list of authorized servers 1602 using the server address as the link-address in the LEASEQUERY 1603 message. If the server has a valid lease for the address, the 1604 requested information will be returned in a LEASEQUERY-REPLY 1605 message marked as successful (i.e., without an OPTION_STATUS_CODE 1606 in the reply). The IA Address option(s) returned contain any 1607 IPv6 addresses bound to the same link together with the lease 1608 validity time. 1610 As DHCP lease queries are an unreliable process (either the packet to 1611 or from the server may be lost in transit), if there is no response 1612 after the MAX_LEASEQUERY_DELAY an EVE_DATA_EXPIRE is generated. Note 1613 that multiple response messages may be received if the list of 1614 authorized servers contains more than one address of the appropriate 1615 type and, in the case of DHCPv6, the responses may contain additional 1616 addresses for which leases have been allocated. 1618 7.5.3. Address Verification Message Sender 1620 Send a message to verify that the link layer address in the attached 1621 device that sent the triggering data packet matches the link layer 1622 address contained in the lease query response: 1624 IPv4 address: Send an ARP Request with the Target Protocol Address 1625 set to the IP address in the BST entry. The ARP Request is 1626 only sent to the attachment that triggered the binding. If the 1627 attached device has the IP address bound to the interface 1628 attached to the SAVI device, an ARP Reply should be received 1629 containing the hardware address of the interface on the 1630 attached device that can be compared with the lease query 1631 value. 1633 IPv6 address: Send a Neighbor Solicitation (NS) message with the 1634 target address set to the IP address in the BST entry. The NS 1635 is only sent to the attachment that triggered the binding. If 1636 the attached device has the IP address bound to the interface 1637 attached to the SAVI device, a Neighbor Announcement (NA) 1638 should be received indicating that the attached device has the 1639 IP address configured on the interface. 1641 As both the ARP and NS/NA processes are unreliable (either the packet 1642 to or from the other system may be lost in transit, see [RFC6620]), 1643 if there is no response after the DETECTION_TIMEOUT an 1644 EVE_DATA_EXPIRE is generated. 1646 7.6. Initial State: state NO_BIND - No binding has been set up 1648 7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding 1649 is received 1651 Make a probabilistic determination as to whether to act on this 1652 event. The probability may be configured or calculated based on the 1653 state of the SAVI device. This probability should be low enough to 1654 mitigate the damage from DoS attack against this process. 1656 Create a new entry in the BST. Set the Binding Anchor field to the 1657 corresponding binding anchor of the attachment. Set the Address 1658 field to the source address of the packet. 1660 Address conflicts MUST be detected and prevented. 1662 If local address detection is performed: 1663 Set the State field to DETECTION. Set the Lifetime of the 1664 created entry to DETECTION_TIMEOUT. Set the Timeouts field to 1665 0. Start the detection of any local address conflicts by 1666 sending a Duplicate Address Detection Message (Section 7.5.1)). 1667 Transition to state DETECTION. 1669 If local address detection is not performed: 1670 Set the State field to RECOVERY. Set the Lifetime of the 1671 created entry to LEASEQUERY_DELAY. Set the Timeouts field to 1672 0. Start the recovery of any DHCP lease associated with the 1673 source IP address by sending one or more lease query messages 1674 (Section 7.5.2)). Transition to state RECOVERY. 1676 The packet that triggers this event SHOULD be discarded. 1678 An example of the BST entry during duplicate address detection is 1679 illustrated in Figure 11. 1681 +--------+-------+---------+-----------------------+-----+----------+ 1682 | Anchor |Address| State | Lifetime | TID | Timeouts | 1683 +--------+-------+---------+-----------------------+-----+----------+ 1684 | Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 | 1685 +--------+-------+---------+-----------------------+-----+----------+ 1687 Figure 11: Binding entry in BST on data triggered initialization 1689 Resulting state: DETECTION - The address in the entry is undergoing 1690 local duplication detection - or RECOVERY - DHCP lease(s) associated 1691 with the address are being queried. 1693 7.6.2. Events not observed in NO_BIND for data snooping 1695 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1696 received from unexpected system 1698 EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is 1699 received 1701 EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the 1702 attached device 1703 All EVE_DHCP_* events defined in Section 6.3.2 are treated as 1704 described in the DHCP Snooping Process (Section 6.4.1) and may result 1705 in that process being triggered. 1707 EVE_ENTRY_EXPIRE: 1709 EVE_DATA_EXPIRE: 1711 7.7. Initial State: state DETECTION - The address in the entry is 1712 undergoing local duplication detection 1714 7.7.1. Event: EVE_ENTRY_EXPIRE 1716 When this event occurs, no address conflict has been detected during 1717 the previous DETECTION_TIMEOUT period. 1719 If the Timeouts field in the BST entry is 0: 1720 Set the Lifetime of the BST entry to DETECTION_TIMEOUT. Set 1721 the Timeouts field to 1. Restart the detection of any local 1722 address conflicts by sending a second Duplicate Address 1723 Detection Message (Section 7.5.1)). Remain in state DETECTION. 1725 If the Timeouts field in the BST entry is 1: 1726 Assume that there is no local address conflict. Set the State 1727 field to RECOVERY. Set the Lifetime of the BST entry to 1728 LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the 1729 recovery of any DHCP lease associated with the source IP 1730 address by sending one or more lease query messages 1731 (Section 7.5.2)). Transition to state RECOVERY. 1733 An example of the entry is illustrated in Figure 12. 1735 +--------+-------+----------+----------------------+-----+----------+ 1736 | Anchor |Address| State | Lifetime | TID | Timeouts | 1737 +--------+-------+----------+----------------------+-----+----------+ 1738 | Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 | 1739 +--------+-------+----------+----------------------+-----+----------+ 1741 Figure 12: Binding entry in BST on Lease Query 1743 Resulting state: DETECTION - If a second local conflict period is 1744 required - or RECOVERY - The SAVI device is querying the assignment 1745 and lease time of the address in the entry through DHCP Leasequery 1747 7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) 1748 message received from unexpected system 1750 Remove the entry. 1752 Resulting state: NO_BIND - No binding has been set up 1754 7.7.3. Events not observed in DETECTION 1756 EVE_DATA_UNMATCH: A data packet without matched binding is received 1758 All EVE_DHCP_* events defined in Section 6.3.2 1760 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 1761 received 1763 7.8. Initial State: state RECOVERY - The SAVI device is querying the 1764 assignment and lease time of the address in the entry through DHCP 1765 Leasequery 1767 7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 1768 successful LEASEQUERY-REPLY is received 1770 Set the State in the BST entry to VERIFY. Depending on the type of 1771 triggering source IP address, process the received DHCP lease query 1772 response: 1774 IPv4 address: Update the Lifetime field in the BST entry to the sum 1775 of the value encoded in IP Address Lease Time option of the 1776 DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Record the 1777 value of the "chaddr" field (hardware address) in the message 1778 for checking against the hardware address received during 1779 verification in the next state. Set the Timeouts field to 0. 1780 Start the verification process by sending an Address 1781 Verification Message (see Section 7.5.3). Transition to state 1782 VERIFY. Start an additional verification timer with a duration 1783 of DETECTION_TIMEOUT. When this expires an EVE_DATA_EXPIRE 1784 event will be generated. 1786 IPv6 address: Update the Lifetime field in the BST entry to the sum 1787 of the valid lifetime extracted from OPTION_CLIENT_DATA option 1788 in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME. 1789 Set the Timeouts field to 0. Start the verification process by 1790 sending an Address Verification Message (see Section 7.5.3). 1791 Transition to state VERIFY. Start an additional verification 1792 timer with a duration of DETECTION_TIMEOUT. When this expires 1793 an EVE_DATA_EXPIRE event will be generated. 1795 If multiple addresses are received in the LEASEQUERY-REPLY, new 1796 BST entries MUST be created for the additional addresses using 1797 the same binding anchor. The entries are created with State 1798 set to VERIFY and the other fields set as described in this 1799 section for the triggering source IP address. Also start the 1800 verification process and start verification timers for each 1801 additional address. 1803 Resulting state: VERIFY - awaiting verification or otherwise of the 1804 association of the IP address with the connected interface. 1806 7.8.2. Event: EVE_ENTRY_EXPIRE 1808 Depending on the value of the Timeouts field in the BST entry, either 1809 send repeat lease query messages or discard the binding: 1811 If the Timeouts field in the BST entry is 0: 1812 No responses to the lease query message(s) sent have been 1813 received during the first LEASEQUERY_DELAY period. Set the 1814 Lifetime of the BST entry to LEASEQUERY_DELAY. Set the 1815 Timeouts field to 1. Restart the recovery of any DHCP lease 1816 associated with the source IP address by sending one or more 1817 lease query messages (Section 7.5.2)). Remain in state 1818 RECOVERY. 1820 If the Timeouts field in the BST entry is 1: 1821 No responses to the lease query messages sent during two 1822 LEASEQUERY_DELAY periods were received. Assume that no leases 1823 exist and hence that the source IP address is bogus. Delete 1824 the BST entry. Transition to state NO_BIND. 1826 Resulting state: RECOVERY - if repeat lease queries are sent - or 1827 NO_BIND - if no successful responses to lease query messages have 1828 been received. 1830 7.8.3. Events not observed in RECOVERY 1832 EVE_DATA_UNMATCH: A data packet without matched binding is received 1834 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1835 received from unexpected system 1837 EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the 1838 attached device 1840 All EVE_DHCP_* events defined in Section 6.3.2 1842 EVE_DATA_EXPIRE: 1844 7.9. Initial State: state VERIFY - Verification of the use of the 1845 source IP address by the device interface attached to the SAVI 1846 device 1848 7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 1849 successful LEASEQUERY-REPLY is received 1851 If lease query messages were sent to more than one DHCP server during 1852 RECOVERY state, additional successful lease query responses may be 1853 received relating to the source IP address. The conflict resolution 1854 mechanisms specified in Section 6.8 of [RFC4388] and Section 4.3.4 of 1855 [RFC5007] can be used to determine the message from which values are 1856 used to update the BST Lifetime entry and the hardware address 1857 obtained from DHCP, as described in Section 7.8.1. In the case of 1858 DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses 1859 as described in Section 7.8.1. If so additional BST entries MUST be 1860 created or ones previously created updated as described in that 1861 section. 1863 Resulting state: VERIFY (no change). 1865 7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is received from 1866 the device attached via the binding anchor 1868 Depending on the type of triggering source IP address, this event may 1869 indicate that the device attached via the binding anchor in the BST 1870 entry is configured by DHCP using the IP address: 1872 IPv4 address: Check that the value of sender hardware address in the 1873 ARP Reply matches the saved "chaddr" field (hardware address) 1874 from the previously received DHCPLEASEACTIVE message. If not, 1875 ignore this event; a subsequent retry may provide verification. 1876 If the hardware addresses match, the binding entry has been 1877 verified. 1879 IPv6 address: Simple receipt of a valid NA from the triggering 1880 source IP address at the binding anchor port provides 1881 verification for the binding entry. 1883 If the binding entry has been verified, set the State in the BST 1884 entry to BOUND. Clear the TID field. Cancel the verification timer. 1886 Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY "chaddr" 1887 address does not match ARP Reply hardware address - or BOUND - 1888 otherwise. 1890 7.9.3. Event: EVE_ENTRY_EXPIRE 1892 The DHCP lease lifetime has expired before the entry could be 1893 verified. Remove the entry. Transition to NO_BIND state. 1895 Resulting state: NO_BIND - No binding has been set up 1897 7.9.4. Event: EVE_DATA_EXPIRE 1899 Depending on the value of the Timeouts field in the BST entry, either 1900 send a repeat validation message or discard the binding: 1902 If the Timeouts field in the BST entry is 0: 1903 No response to the verification message sent has been received 1904 during the first DETECTION_TIMEOUT period. Set the Timeouts 1905 field to 1. Restart the verification process by sending an 1906 Address Verification Message (see Section 7.5.3). Start a 1907 verification timer with a duration of DETECTION_TIMEOUT. When 1908 this expires an EVE_DATA_EXPIRE event will be generated. 1909 Remain in state VERIFY. 1911 If the Timeouts field in the BST entry is 1: 1912 No responses to the verification messages sent during two 1913 DETECTION_TIMEOUT periods were received. Assume that the 1914 configuration of the triggering source IP address cannot be 1915 verified and hence that the source IP address is bogus. Delete 1916 the BST entry. Transition to state NO_BIND. 1918 Resulting state: VERIFY - additional verification message sent - or 1919 NO_BIND - No binding has been set up 1921 7.9.5. Events not observed in VERIFY 1923 EVE_DATA_UNMATCH: A data packet without matched binding is received 1925 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1926 received from unexpected system 1928 All EVE_DHCP_* events defined in Section 6.3.2 1930 7.10. Initial State: state BOUND - The binding has been set up 1932 Upon entry to the state BOUND, control the system continues as if a 1933 DHCP message assigning the address has been observed, as in 1934 Section 6.4.3. The BST entry has been restored. 1936 Note that the TID field contains no value after the binding state 1937 changes to BOUND. The TID field is recovered from snooping DHCP 1938 Renew/Rebind messages if these are observed as described in the DHCP 1939 Snooping Process. Because TID is used to associate binding entries 1940 with messages from DHCP servers, it must be recovered; or else a 1941 number of state transitions of this mechanism will be not executed 1942 normally. 1944 7.11. Table of State Machine 1946 The main state transitions are listed as follows. 1948 State Event Action Next State 1949 NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION 1950 DETECTION EVE_ENTRY_EXPIRE 1 Repeat duplicate detect DETECTION 1951 DETECTION EVE_ENTRY_EXPIRE 2 Start lease query RECOVERY 1952 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1953 RECOVERY EVE_ENTRY_EXPIRE 1 Repeat lease query RECOVERY 1954 RECOVERY EVE_ENTRY_EXPIRE 2 No lease found; remove entry NO_BIND 1955 RECOVERY EVE_DATA_LEASEQUERY Set lease time; Start verify VERIFY 1956 VERIFY EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND 1957 VERIFY EVE_DATA_LEASEQUERY Resolve lease conflict(s) VERIFY 1958 VERIFY EVE_DATA_VERIFY Finish validation BOUND or NO_BIND 1959 VERIFY EVE_DATA_EXPIRE 1 Repeat verify VERIFY 1960 VERIFY EVE_DATA_EXPIRE 2 Verify failed; remove entry NO_BIND 1961 BOUND EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND 1962 BOUND RENEW/REBIND Record TID BOUND 1964 Figure 13: State Transition Table 1965 +-------------+ EVE_ENTRY_EXPIRE 1966 /---------+ |<------------------------\ 1967 | | NO_BIND | EVE_DATA_EXPIRE | 1968 EVE_DATA_UNMATCH | /----->| |<----\ (2nd VRF_DELAY) | 1969 | | +-------------+ | | 1970 | | EVE_ENTRY_EXPIRE | | 1971 | | (2nd LQ_DELAY) | | 1972 EVE_ENTRY_EXPIRE | | | EVE_ENTRY_EXPIRE | 1973 (1st DAD_DELAY) | | | (1st LQ_DELAY) | 1974 /------\ | | | /--------\ | 1975 | | | | EVE_DATA_CONFLICT \---\ | | | 1976 | v v | | v | | 1977 | +-------------+ EVE_ENTRY_EXPIRE +------------+ | | 1978 | | | (2nd DAD_DELAY) | | | | 1979 \----+ DETECTION ------------------------>| RECOVERY +--/ | 1980 | | | | | 1981 +-------------+ (To NO_BIND) +------------+ | 1982 ^ | | 1983 | EVE_DATA_LEASEQUERY | | 1984 /----------\ | | | 1985 | | | EVE_ENTRY_EXPIRE | | 1986 EVE_DHCP_RENEW| v | v | 1987 EVE_DHCP_REBIND| +-------------+ +-------------+ | 1988 | | | | +--/ 1989 \----+ BOUND |<---------------+ VERIFY | 1990 | | EVE_DATA_VERIFY| |<-\ 1991 +-------------+ +-------------+ | 1992 | | 1993 \----------/ 1994 EVE_DATA_LEASEQUERY 1995 EVE_DATA_EXPIRE 1996 (1st VRF_DELAY) 1998 Figure 14: Diagram of Transit 2000 LQ_DELAY: MAX_LEASEQUERY_DELAY 2001 VRF_DELAY: DETECTION_TIMEOUT 2003 8. Filtering Specification 2005 This section specifies how to use bindings to filter out packets with 2006 spoofed source addresses. 2008 Filtering policies are different for data packets and control 2009 packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861] 2010 messages are classified as control packets. All other packets are 2011 classified as data packets. 2013 8.1. Data Packet Filtering 2015 Data packets from attachments with the Validating attribute TRUE MUST 2016 have their source addresses validated. There is one exception to 2017 this rule. 2019 A packet whose source IP address is a link-local address cannot be 2020 checked against DHCP assignments, as it is not assigned using DHCP. 2021 Note: as explained in Section 1, a SAVI solution for link-local 2022 addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to check 2023 packets with a link-local source address. 2025 If the source IP address of a packet is not a link-local address, but 2026 there is not a matching entry in BST with state BOUND, this packet 2027 MUST be discarded. However, the packet may trigger the Data Snooping 2028 Process Section 7 if the Data-Snooping attribute is set on the 2029 attachment. 2031 Data packets from an attachment with the Validating attribute set 2032 FALSE will be forwarded without having their source addresses 2033 validated. 2035 The SAVI device MAY log packets that fail source address validation. 2037 8.2. Control Packet Filtering 2039 For attachments with the Validating attribute: 2041 DHCPv4 Client-Server messages in which the source IP address is 2042 neither all zeros nor bound with the corresponding binding anchor in 2043 the BST MUST be discarded. 2045 DHCPv6 Client-Server messages in which the source IP address is 2046 neither a link-local address nor bound with the corresponding binding 2047 anchor in the BST MUST be discarded. 2049 NDP messages in which the source IP address is neither a link-local 2050 address nor bound with the corresponding binding anchor MUST be 2051 discarded. 2053 NA messages in which the target address is neither a link-local 2054 address nor bound with the corresponding binding anchor MUST be 2055 discarded. 2057 ARP messages in which the protocol is IP and sender protocol address 2058 is neither all zeros address nor bound with the corresponding binding 2059 anchor MUST be discarded. 2061 ARP Reply messages in which the target protocol address is not bound 2062 with the corresponding binding anchor MUST be discarded. 2064 For attachments with other attributes: 2066 DHCP Server-to-Client messages not from attachments with the DHCP- 2067 Trust attribute or Trust attribute MUST be discarded. 2069 For attachments with no attribute: 2071 DHCP Server-to-Client messages from such attachments MUST be 2072 discarded. 2074 The SAVI device MAY record any messages that are discarded. 2076 9. State Restoration 2078 If a SAVI device reboots, the information kept in volatile memory 2079 will be lost. This section specifies the restoration of attribute 2080 configuration and BST. 2082 9.1. Attribute Configuration Restoration 2084 The loss of attribute configuration will not break the network: no 2085 action will be performed on traffic from attachments with no 2086 attribute. However, the loss of attribute configuration makes this 2087 SAVI function unable to work. 2089 To avoid the loss of binding anchor attribute configuration, the 2090 configuration MUST be able to be stored in non-volatile storage. 2091 After the reboot of SAVI device, if the configuration of binding 2092 anchor attributes is found in non-volatile storage, the configuration 2093 MUST be used. 2095 9.2. Binding State Restoration 2097 The loss of binding state will cause the SAVI devices to discard 2098 legitimate traffic. Simply using the Data Snooping Process to 2099 recover a large number of bindings is a heavy overhead and may cause 2100 considerable delay. Thus, to recover bindings from non-volatile 2101 storage, as specified below, is RECOMMENDED. 2103 Binding entries MAY be saved into non-volatile storage whenever a new 2104 binding entry changes to BOUND state. If a binding with BOUND state 2105 is removed, the saved entry MUST be removed correspondingly. The 2106 time when each binding entry is established is also saved. 2108 If the BST is stored in non-volatile storage, the SAVI device SHOULD 2109 restore binding state from the non-volatile storage immediately after 2110 reboot. Using the time when each binding entry was saved, the SAVI 2111 device should check whether the entry has become obsolete by 2112 comparing the saved lifetime and the difference between the current 2113 time and time when the binding entry was established. Obsolete 2114 entries which would have expired before the reboot MUST be removed. 2116 10. Constants 2118 The following constants are recommended for use in this context: 2120 o MAX_DHCP_RESPONSE_TIME 120s Maximum Solicit timeout value 2121 (SOL_MAX_RT from [RFC3315]) 2123 o MAX_LEASEQUERY_DELAY 10s Maximum LEASEQUERY timeout value 2124 (LQ_MAX_RT from [RFC5007]) 2126 o DETECTION_TIMEOUT 0.5s Maximum duration of a hardware address 2127 verification step in the VERIFY state (TENT_LT from [RFC6620]) 2129 o DATA_SNOOPING_INTERVAL Minimum interval between two successive 2130 EVE_DATA_UNMATCH events triggered by an attachment. 60s and 2131 configurable (recommendation) 2133 o OFFLINK_DELAY 30s Period after a client is last detected before 2134 the binding anchor being removed. (recommendation) 2136 11. Security Considerations 2138 11.1. Security Problems about the Data Snooping Process 2140 There are two security problems about the Data Snooping Process 2141 Section 7: 2143 (1) The Data Snooping Process is costly, but an attacker can trigger 2144 it simply through sending a number of data packets. To avoid 2145 Denial of Services attack against the SAVI device itself, the 2146 Data Snooping Process MUST be rate limited. A constant 2147 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 2148 Data Snooping Processes on one attachment MUST be separated by a 2149 minimum interval time DATA_SNOOPING_INTERVAL. If this value is 2150 changed, the value needs to be large enough to minimize denial of 2151 service attacks. 2153 (2) The Data Snooping Process may set up incorrect bindings if the 2154 clients do not reply to the detection probes Section 7.6.1. An 2155 attack will pass the duplicate detection if the client assigned 2156 the target address does not reply to the detection probes. The 2157 DHCP Lease query procedure performed by the SAVI device just 2158 tells whether the address is assigned in the network or not. 2159 However, the SAVI device cannot determine whether the address is 2160 just assigned to the triggering attachment from the DHCP 2161 LEASEQUERY Reply. 2163 11.2. Securing Lease Query Operations 2165 In [RFC4388] and [RFC5007] the specific case of DHCP lease queries 2166 originated by "access concentrators" is addressed extensively. SAVI 2167 devices are very similar to access concentrators in that they snoop 2168 on DHCP traffic and seek to validate source addresses based on the 2169 results. Accordingly the recommendations for securing lease query 2170 operations for access concentrators in Section 7 of [RFC4388] and 2171 Section 5 of [RFC5007] MUST be followed when lease queries are made 2172 from SAVI devices. [RFC5007] RECOMMENDS that communications between 2173 the querier and the DHCP server are protected with IPsec. It is 2174 pointed out that there are relatively few devices involved in a given 2175 administrative domain (SAVI devices, DHCP relays and servers) so that 2176 manual configuration of keying material would not be overly 2177 burdensome. 2179 11.3. Client departure issues 2181 After a binding is set up, the corresponding client may leave its 2182 attachment point. It may depart temporarily due to signal fade, or 2183 permanently by moving to a new attachment point or leaving the 2184 network. In the signal fade case, since the client may return 2185 shortly, the binding should be kept momentarily, lest legitimate 2186 traffic from the client be blocked. However, if the client leaves 2187 permanently, keeping the binding can be a security issue. If the 2188 binding anchor is a property of the attachment point rather than the 2189 client, e.g., the switch port but not incorporating the MAC Address, 2190 an attacker using the same binding anchor can send packets using IP 2191 addresses assigned to the client. Even if the binding anchor is a 2192 property of the client, retaining binding state for a departed client 2193 for a long time is a waste of resources. 2195 Whenever a direct client departs from the network, a link-down event 2196 associated with the binding anchor will be triggered. SAVI-DHCP 2197 monitors such events, and performs the following mechanism. 2199 (1) Whenever a client with the Validating attribute leaves, a timer 2200 of duration OFFLINK_DELAY is set on the corresponding binding 2201 entries. 2203 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 2204 received that targets the address during OFFLINK_DELAY, the entry 2205 MAY be removed. 2207 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 2208 timer. 2210 In this way, the bindings of a departing client are kept for 2211 OFFLINK_DELAY. In case of link flapping, the client will not be 2212 blocked. If the client leaves permanently, the bindings will be 2213 removed after OFFLINK_DELAY. 2215 SAVI-DHCP does not handle the departure of indirect clients, because 2216 it will not be notified of such events. Switches supporting indirect 2217 attachment (e.g., through a separate non-SAVI switch) SHOULD use 2218 information specific to the client such as its MAC address as part of 2219 the binding anchor. 2221 11.4. Compatibility with DNA (Detecting Network Attachment) 2223 DNA [RFC4436][RFC6059] is designed to decrease the handover latency 2224 after re-attachment to the same network. DNA mainly relies on 2225 performing reachability test by sending unicast Neighbor 2226 Solicitation/Router Solicitation/ARP Request message to determine 2227 whether a previously configured address is still valid. 2229 Although DNA provides optimization for clients, there is insufficient 2230 information for this mechanism to migrate the previous binding or 2231 establish a new binding. If a binding is set up only by snooping the 2232 reachability test message, the binding may be invalid. For example, 2233 an attacker can perform reachability test with an address bound to 2234 another client. If binding is migrated to the attacker, the attacker 2235 can successfully obtain the binding from the victim. Because this 2236 mechanism wouldn't set up a binding based on snooping the DNA 2237 procedure, it cannot achieve perfect compatibility with DNA. 2238 However, it only means the re-configuration of the interface is 2239 slowed but not prevented. Details are discussed as follows. 2241 In Simple DNAv6 [RFC6059], the probe is sent with the source address 2242 set to a link-local address, and such messages will not be discarded 2243 by the policy specified in Section 8.2. If a client is re-attached 2244 to a previous network, the detection will be completed, and the 2245 address will be regarded as valid by the client. However, the 2246 candidate address is not contained in the probe. Thus, the binding 2247 cannot be recovered through snooping the probe. As the client will 2248 perform DHCP exchange at the same time, the binding will be recovered 2249 from the DHCP Snooping Process. The DHCP Request messages will not 2250 be filtered out in this case because they have link-local source 2251 addresses. Before the DHCP procedure is completed, packets will be 2252 filtered out by the SAVI device. In other words, if this SAVI 2253 function is enabled, Simple DNAv6 will not help reduce the handover 2254 latency. If Data-Snooping attribute is configured on the new 2255 attachment of the client, the data triggered procedure may reduce 2256 latency. 2258 In DNAv4 [RFC4436], the ARP probe will be discarded because an 2259 unbound address is used as the sender protocol address. As a result, 2260 the client will regard the address under detection is valid. 2261 However, the data traffic will be filtered. The DHCP Request message 2262 sent by the client will not be discarded, because the source IP 2263 address field should be all zero as required by [RFC2131]. Thus, if 2264 the address is still valid, the binding will be recovered from the 2265 DHCP Snooping Process. 2267 11.5. Binding Number Limitation 2269 A binding entry will consume a certain high-speed memory resources. 2270 In general, a SAVI device can afford only a quite limited number of 2271 binding entries. In order to prevent an attacker from overloading 2272 the resource of the SAVI device, a binding entry limit is set on each 2273 attachment. The binding entry limit is the maximum number of 2274 bindings supported on each attachment with Validating attribute. No 2275 new binding should be set up after the limit has been reached. If a 2276 DHCP Reply assigns more addresses than the remaining binding entry 2277 quota of each client, the message will be discarded and no binding 2278 will be set up. 2280 11.6. Privacy Considerations 2282 A SAVI device MUST delete binding anchor information as soon as 2283 possible (i.e., as soon as the state for a given address is back to 2284 NO_BIND), except where there is an identified reason why that 2285 information is likely to be involved in the detection, prevention, or 2286 tracing of actual source address spoofing. Information about the 2287 majority of hosts that never spoof SHOULD NOT be logged. 2289 11.7. Fragmented DHCP Messages 2291 This specification does not preclude reassembly of fragmented DHCP 2292 messages, but it also does not require it. If DHCP fragmentation 2293 proves to be an issue, that will need to be specified. 2295 12. IANA Considerations 2297 This memo asks the IANA for no new parameters. 2299 13. Acknowledgment 2301 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 2302 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 2303 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 2304 Garcia for careful review and valuation comments on the mechanism and 2305 text. 2307 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 2308 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 2309 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 2310 their valuable contributions. 2312 This document was generated using the xml2rfc tool. 2314 14. References 2316 14.1. Normative References 2318 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2319 converting network protocol addresses to 48.bit Ethernet 2320 address for transmission on Ethernet hardware", STD 37, 2321 RFC 826, November 1982. 2323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2324 Requirement Levels", BCP 14, RFC 2119, March 1997. 2326 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2327 2131, March 1997. 2329 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2330 and M. Carney, "Dynamic Host Configuration Protocol for 2331 IPv6 (DHCPv6)", RFC 3315, July 2003. 2333 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 2334 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 2336 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 2337 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 2339 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2340 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2341 September 2007. 2343 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 2344 "DHCPv6 Leasequery", RFC 5007, September 2007. 2346 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 2347 July 2008. 2349 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 2350 Detecting Network Attachment in IPv6", RFC 6059, November 2351 2010. 2353 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2354 SAVI: First-Come, First-Served Source Address Validation 2355 Improvement for Locally Assigned IPv6 Addresses", RFC 2356 6620, May 2012. 2358 14.2. Informative References 2360 [I-D.ietf-opsec-dhcpv6-shield] 2361 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 2362 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 2363 opsec-dhcpv6-shield-05 (work in progress), January 2015. 2365 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2366 Defeating Denial of Service Attacks which employ IP Source 2367 Address Spoofing", BCP 38, RFC 2827, May 2000. 2369 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 2370 (DHCP) Service for IPv6", RFC 3736, April 2004. 2372 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 2373 "Source Address Validation Improvement (SAVI) Framework", 2374 RFC 7039, October 2013. 2376 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 2377 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 2378 7341, August 2014. 2380 Authors' Addresses 2382 Jun Bi 2383 Tsinghua University 2384 Network Research Center, Tsinghua University 2385 Beijing 100084 2386 China 2388 EMail: junbi@tsinghua.edu.cn 2389 Jianping Wu 2390 Tsinghua University 2391 Computer Science, Tsinghua University 2392 Beijing 100084 2393 China 2395 EMail: jianping@cernet.edu.cn 2397 Guang Yao 2398 Tsinghua University 2399 Network Research Center, Tsinghua University 2400 Beijing 100084 2401 China 2403 EMail: yaoguang@cernet.edu.cn 2405 Fred Baker 2406 Cisco Systems 2407 Santa Barbara, CA 93117 2408 United States 2410 EMail: fred@cisco.com