idnits 2.17.1 draft-ietf-savi-dhcp-26.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2014) is 3612 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 informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 7039 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Bi 3 Internet-Draft J. Wu 4 Intended status: Standards Track G. Yao 5 Expires: December 2, 2014 Tsinghua Univ. 6 F. Baker 7 Cisco 8 May 31, 2014 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-26 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 SAVI 17 (Source Address Validation Improvements) device. The bindings set up 18 by this procedure can be used to filter out packets with forged 19 source IP address in DHCP scenario. This mechanism is proposed as a 20 complement to ingress filtering to provide finer-grained source IP 21 address validation. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 2, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Deployment Scenario and Configuration . . . . . . . . . . . . 8 73 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8 74 4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 11 76 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . . 11 77 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 12 78 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 12 79 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . . 13 80 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . . 13 81 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . . 14 83 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14 84 4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 15 85 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 16 86 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 17 87 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2. Binding States Description . . . . . . . . . . . . . . . . 18 89 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . . 18 91 6.3.2. Control Message Arriving Events . . . . . . . . . . . 18 92 6.4. The State Machine of DHCP Snooping Process . . . . . . . . 20 93 6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 20 94 6.4.1.1. Trigger Events . . . . . . . . . . . . . . . . . . 20 95 6.4.1.2. Following Actions . . . . . . . . . . . . . . . . 20 96 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 21 97 6.4.2.1. Trigger Events . . . . . . . . . . . . . . . . . . 21 98 6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 22 99 6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 24 100 6.4.3.1. Trigger Events . . . . . . . . . . . . . . . . . . 24 101 6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 24 102 6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 25 103 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 26 104 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27 106 7.3. Additional Binding States Description . . . . . . . . . . 28 107 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 7.5. State Machine of Binding Recovery Process . . . . . . . . 29 109 7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 29 110 7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 29 111 7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 29 112 7.5.2. From DETECTION to Other States . . . . . . . . . . . . 30 113 7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 30 114 7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 30 116 7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 31 117 7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 31 118 7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 32 119 7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 33 120 7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 33 121 7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 33 122 7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 33 123 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 34 124 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 35 125 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 35 126 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 36 127 9.1. Attribute Configuration Restoration . . . . . . . . . . . 36 128 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 36 129 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37 130 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 131 11.1. Security Problems about the Data Snooping Process . . . . 37 132 11.2. Issues about Leaving Clients . . . . . . . . . . . . . . . 37 133 11.3. Duplicate Bindings to the Same Address . . . . . . . . . . 38 134 11.4. Compatibility with DNA (Detecting Network Attachment) . . 39 135 11.5. Authentication in DHCPv6 Leasequery . . . . . . . . . . . 40 136 11.6. Binding Number Limitation . . . . . . . . . . . . . . . . 40 137 11.7. Residual Threats . . . . . . . . . . . . . . . . . . . . . 40 138 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 139 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 41 140 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 141 14.1. Informative References . . . . . . . . . . . . . . . . . . 41 142 14.2. Normative References . . . . . . . . . . . . . . . . . . . 42 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 145 1. Introduction 147 This document describes a fine-grained source IP address validation 148 mechanism. This mechanism creates bindings between addresses 149 assigned to network attachment points by DHCP and suitable binding 150 anchors (refer to Section 3) of the attachments. Then the bindings 151 are used to identify and filter out packets originated from these 152 attachments with forged source IP addresses. In this way, this 153 mechanism can prevent hosts from spoofing IP addresses assigned to 154 the other attachment points. Compared with [BCP38], which provides 155 prefix granularity source IP address validity, this mechanism can 156 benefit the network with finer-grained validity and traceability of 157 source IP addresses. 159 This mechanism primarily performs DHCP snooping to set up bindings 160 between IP addresses assigned by DHCP and corresponding binding 161 anchors. This binding process is inspired by the work of [BA2007]. 162 Different from [BA2007], which designs specifications about DHCPv4, 163 this mechanism covers the DHCPv6 snooping process, the Data Snooping 164 process(refer to Section 7), as well as a number of other technical 165 details. Specially, the Data Snooping process is a data-triggered 166 procedure which snoops the header of data packet to set up bindings. 167 It is designed to avoid permanent block of valid address in case that 168 DHCP snooping is insufficient to set up all the valid bindings. 170 This mechanism is designed for the stateful DHCP scenario [RFC2131], 171 [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this 172 document, because it has nothing to do with IP address allocation. A 173 client doing stateless DHCP acquires its IP address(es) using some 174 other mechanism. It is through that mechanism the client uses that 175 SAVI must be accomplished. For example, for hosts using Stateless 176 Auto-configuration address, SAVI-FCFS [RFC6620] should be enabled. 177 Besides, this mechanism is primarily designed for pure DHCP scenarios 178 in which only addresses assigned through DHCP are allowed. However, 179 it does not block any link-local address. It is because link-local 180 addresses are used by DHCPv6 clients before the clients are assigned 181 a DHCPv6 address. Considering that link-local addresses are 182 generally self-generated, and the spoofing of link local address may 183 disturb this mechanism, it is RECOMMENDED to enable a SAVI solution 184 for link-local addresses, e.g., the SAVI-FCFS [RFC6620]. 186 2. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 3. Terminology 194 Binding anchor: A "binding anchor" is defined to be a link layer 195 property of network attachment in [RFC7039]. A list of proper 196 binding anchors can be found in Section 3.2 of [RFC7039]. 198 Attribute: A configurable property of each network attachment which 199 indicates the actions to be performed on packets received from the 200 network attachment. 202 DHCP address: An IP address assigned via DHCP. 204 SAVI-DHCP: The name of this SAVI function for DHCP address. 206 SAVI device: A network device on which this SAVI function is enabled. 208 Non-SAVI device: A network device on which this SAVI function is not 209 enabled. 211 DHCP Client-Server message: A message that is sent from a DHCP client 212 to a DHCP server or DHCP servers. Such a message is of one of the 213 following types: 215 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 217 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 218 [RFC2131] 220 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 221 [RFC2131] 223 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 224 [RFC2131] 226 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 227 [RFC2131] 229 o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be 230 identified based on the Table 4 of [RFC2131] 232 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 234 o DHCPv4 Release: DHCPRELEASE [RFC2131] 236 o DHCPv4 Inform: DHCPINFORM [RFC2131] 238 o DHCPv6 Request: REQUEST [RFC3315] 239 o DHCPv6 Solicit: SOLICIT [RFC3315] 241 o DHCPv6 Confirm: CONFIRM [RFC3315] 243 o DHCPv6 Decline: DECLINE [RFC3315] 245 o DHCPv6 Release: RELEASE [RFC3315] 247 o DHCPv6 Rebind: REBIND [RFC3315] 249 o DHCPv6 Renew: RENEW [RFC3315] 251 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 253 DHCP Server-Client message: A message that is sent from a DHCP server 254 to a DHCP client. Such a message is of one of the following types: 256 o DHCPv4 ACK: DHCPACK [RFC2131] 258 o DHCPv4 NAK: DHCPNAK [RFC2131] 260 o DHCPv4 Offer: DHCPOFFER [RFC2131] 262 o DHCPv6 Reply: REPLY [RFC3315] 264 o DHCPv6 Advertise: ADVERTISE [RFC3315] 266 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 268 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 269 IPv6 [RFC3315]. 271 Binding entry: An 'permit' rule that defines a valid association 272 between an IP address and a binding anchor. 274 Binding State Table (BST): The data structure that contains all the 275 binding entries. 277 Binding entry limit: The maximum number of binding entries that may 278 be associated with any one binding anchor. Limiting the number of 279 binding entries per binding anchor prevents a malicious or 280 malfunctioning node from overloading the binding table on a SAVI 281 device. 283 Direct attachment: Ideally, a SAVI device should be an access device 284 which is directly attached by hosts. In such case, the hosts are 285 direct attachments of the SAVI device. 287 Indirect attachment: A SAVI device can be an aggregation device which 288 is connected with a number of access devices, which are attached by 289 hosts. In such case, the hosts are indirect attachments of the SAVI 290 device. Sometimes, it is expressed as "the hosts are indirectly 291 attached to the SAVI device". 293 Upstream link: Upstream links are links connected to non-SAVI devices 294 from which the valid source address space of traffic contains the 295 prefixes of other networks. 297 Upstream device: An upstream device is a non-SAVI device associated 298 with an upstream link. For example, the gateway router of the 299 network. 301 Downstream link: Downstream links are links connected to non-SAVI 302 devices from which the valid source address space of traffic only 303 contains the prefix(es) of the local network. 305 Downstream device: A downstream device is a non-SAVI device 306 associated with an downstream link. For example, an access switch in 307 the network. 309 CUT VERTEX: A cut vertex is 'any vertex whose removal increases the 310 number of connected components'. This is a concept in graph theory. 311 This term is used in Section 6.1 to accurately specify the required 312 deployment location of SAVI devices when they only perform the DHCP 313 snooping process. 315 Identity Association (IA): "A collection of addresses assigned to a 316 client." [RFC3315] 318 Detection message: a Neighbor Solicitation or ARP message intended to 319 detect a duplicate address by the Data Snooping Process. 321 DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the 322 binding the triggered by CONFIRM but LQ cannot be performed by the 323 SAVI device to fetch the lease. 325 4. Deployment Scenario and Configuration 327 4.1. Elements and Scenario 329 A list of essential elements in a SAVI-DHCP deployment scenario is 330 given as follows: 332 (1) DHCP server 334 (2) DHCP client 336 (3) SAVI device 338 And there may be following optional elements in a SAVI-DHCP 339 deployment scenario: 341 (1) DHCP relay 343 (2) Non-SAVI device 345 Figure 1 shows a deployment scenario that contains these elements. 346 Note that a physical device can be multiple elements, e.g, a switch 347 can be both a SAVI device and a DHCP relay. In such cases, the links 348 are logic links rather than physical links. 350 +--------+ +------------+ 351 |DHCP |-----| Non-SAVI | 352 |Server A| | Device 1 | 353 +--------+ +-----|------+ 354 ......................|............................ 355 . | upstream link . 356 . Protection +---|------+ . 357 . Perimeter | SAVI |--------------+ . 358 . | Device C| | . 359 . +---|------+ | . 360 . | | . 361 . +----------+ +---|------+ +------|---+ . 362 downstream . | SAVI | | Non SAVI| | SAVI | . 363 link +----.-| Device A|----| Device 3|-------| Device B| . 364 | . +----|--|--+ +----------+ +-|---|----+ . 365 | . | +----------+ ............ | | . 366 | '.............. | . . | | . 367 | | . | . +--------+ | . 368 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 369 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 370 | Device 2 | |A | . |Relay | . |B | . |Server B| . 371 +----------+ +------+ . +------+ . +------+ . +--------+ . 372 ............ ............... 374 Figure 1: SAVI-DHCP Scenario 376 Note: To distinguish upstream/downstream links is essential for SAVI- 377 DHCP. 379 Networks are not isolated and traffic from other networks, i.e., 380 transit traffic specified in RFC6620, may get into the network with 381 SAVI-DHCP deployed through the upstream links. Since SAVI solutions 382 are limited to check traffic generated from local link, SAVI-DHCP is 383 not to set up bindings for addresses assigned in other networks. 384 Thus, SAVI-DHCP will not set up bindings for addresses appearing on 385 upstream links and will not check data traffic from upstream links. 386 The traffic from upstream links should be checked by a prefix 387 granularity source address validation mechanism to avoid spoofing of 388 local addresses from other networks. How to generate and deploy such 389 a mechanism is out of the scope of this document. 391 However, traffic from downstream links are generated from local 392 network. For example, a hub, which is attached by some DHCP clients, 393 is on the downstream link of a SAVI device. The traffic from 394 downstream links should be checked by SAVI-DHCP if possible. 395 However, because DHCP clients on the downstream links are indirectly 396 attached, a number of security problems Section 11.7 can be 397 introduced. 399 4.2. Attribute 401 As illustrated in Figure 1, an attachment to a SAVI device can be 402 from either a DHCP client, or a DHCP relay/server, or a SAVI device, 403 or a non-SAVI device. Different actions are performed on traffic 404 originated from different elements. To distinguish different types 405 of attachments, an attachment property named 'attribute' is 406 configured on SAVI devices. This section specifies the attributes 407 used by SAVI-DHCP. 409 Before configuration, an attachment is with no attribute. An 410 attachment MAY be configured to have one or more compatible 411 attributes(refer to Section 4.2.6). The attributes of each 412 attachment MUST be configured before this SAVI-DHCP function is 413 enabled on the attachment. The procedure performed by SAVI devices 414 on traffic from each attachment is determined by the attribute(s) set 415 on the attachment. 417 Particularly, if an attachment has no attribute, data traffic from 418 such attachments will not be checked by SAVI-DHCP and will be 419 forwarded directly. This prevents SAVI-DHCP from causing a break in 420 the network when it is turned on without any binding anchors 421 configured. However, if a binding anchor has no attributes, this 422 means that the SAVI-DHCP-Trust attribute is not present. Because of 423 this, DHCP server-client messages from that binding anchor will be 424 discarded. This prevents a host from connecting to an unconfigured 425 binding anchor and acting as a DHCP server. It is SUGGESTED to 426 configure SAVI-DHCP-Trust on necessary binding anchors before turning 427 on the SAVI-DHCP function. 429 Binding anchors associated with upstream links MAY have no attribute 430 after configuration. For example, in Figure 1, the attachment from 431 the Non-SAVI Device 1 to the SAVI Device C should be configured with 432 no attribute. It means 1) SAVI devices will neither set up bindings 433 for upstream hosts nor check traffic from upstream hosts; 2) SAVI 434 devices will drop DHCP server-client messages from upstream devices 435 unless the DHCP-Trust attribute (refer to Section 4.2.2) is set on 436 the corresponding attachment. The reason that DHCP messages from 437 upstream devices are not trusted is discussed in Section 4.3.3. 439 4.2.1. Trust Attribute 441 The "Trust Attribute" indicates the packets from the corresponding 442 attachment are completely trustable. 444 SAVI devices will not set up bindings for attachments with Trust 445 attribute; DHCP messages and data packets from such attachments with 446 this attribute will not be checked. If the DHCP Server-Client 447 messages from attachments with this attribute can trigger the state 448 transitions specified in Section 6 and Section 7, these messages will 449 be handled by the corresponding processes in Section 6 and Section 7. 451 This attribute is generally configured on the attachments from other 452 SAVI devices. For example, in Figure 1, the attachment from the SAVI 453 Device B to the SAVI Device C and the attachment from the SAVI Device 454 C to the SAVI Device B should be configured with this attribute. 455 Besides, it can be configured on attachments from Non-SAVI devices 456 only if the Non-SAVI devices will not introduce unchecked traffic 457 from DHCP clients. For example, the attachments from Non-SAVI device 458 3 to SAVI device A, SAVI device B and SAVI device C can be configured 459 with this attribute, only if Non-SAVI device 3 does not have 460 attachment from DHCP clients. 462 4.2.2. DHCP-Trust Attribute 464 The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages 465 from the corresponding attachment is trustable. 467 SAVI devices will forward DHCP Server-Client messages coming from the 468 attachments with this attribute. If the DHCP Server-Client messages 469 can trigger the state transitions, they will be handled by the 470 binding setup processes specified in Section 6 and Section 7. 472 This attribute is generally used on the direct attachments from the 473 trusted DHCP servers/relays. In Figure 1, the attachment from the 474 DHCP Relay to the SAVI Device A, and the attachment from the DHCP 475 Server B to the SAVI Device B should be configured with this 476 attribute. It is NOT RECOMMENDED to configure this attribute on any 477 indirect attachment point of the non-neighboring DHCP servers and 478 relays, unless all the elements that can be reached through that 479 attachment point can be trusted, i.e., bogus DHCP Server-Client 480 messages will not be generated by these elements. For example, in 481 Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI 482 Device C should not be configured with this attribute. This issue is 483 discussed in Section 4.3.3. 485 4.2.3. DHCP-Snooping Attribute 487 The "DHCP-Snooping Attribute" indicates bindings will be set up based 488 on DHCP snooping. 490 DHCP Client-Server messages from attachments with this attribute will 491 trigger the setup of bindings. SAVI devices will set up bindings on 492 attachments with this attribute based on the DHCP snooping procedure 493 described in Section 6. 495 DHCP-Snooping attribute is configured on the attachments from DHCP 496 clients. This attribute can be also used on the attachments from 497 downstream Non-SAVI devices which are attached by DHCP clients. In 498 Figure 1, the attachment from the Client A to the SAVI Device A, the 499 attachment from the Client B to the SAVI Device B, and the attachment 500 from the Non-SAVI Device 2 to the SAVI Device A can be configured 501 with this attribute. 503 4.2.4. Data-Snooping Attribute 505 The "Data-Snooping Attribute" indicates data packets from the 506 corresponding attachment may trigger binding setup procedure. 508 Data packets from attachments with this attribute may trigger the 509 setup of bindings. SAVI devices will set up bindings on attachments 510 with this attribute based on the data-triggered process described in 511 Section 7. 513 If DHCP-Snooping attribute is configured on an attachment, the 514 bindings on this attachment are set up based on DHCP message 515 snooping. However, in some scenarios, a DHCP address may be used by 516 a DHCP client without DHCP address assignment procedure performed on 517 its current attachment. For such attachments, the Data-Snooping 518 process, which is described in Section 7, is necessary. This 519 attribute is configured on such attachments. The usage of this 520 attribute is further discussed in Section 7. 522 4.2.5. Validating Attribute 524 The "Validating Attribute" indicates packets from the corresponding 525 attachment will be checked based on binding entries on the 526 attachment. 528 Packets coming from attachments with this attribute will be checked 529 based on binding entries on the attachment as specified in Section 8. 531 Validating attribute is configured on the attachments from which the 532 data packets should be checked. For example, the DHCP clients. 534 4.2.6. Table of Mutual Exclusions 536 Different types of attributes may indicate mutually exclusive actions 537 on packet. Mutually exclusive attributes MUST NOT be set on the same 538 attachment. The compatibility of different attributes is listed in 539 Figure 2. Note that although Trust and DHCP-Trust are compatible, 540 there is no need to configure DHCP-Trust on an attachment with Trust 541 attribute. 543 +----------+----------+----------+----------+----------+----------+ 544 | | | | DHCP- | Data- | | 545 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 546 +----------+----------+----------+----------+----------+----------+ 547 | | | | mutually | mutually | mutually | 548 | Trust | - |compatible| exclusive| exclusive| exclusive| 549 +----------+----------+----------+----------+----------+----------+ 550 | | | | | | | 551 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 552 +----------+----------+----------+----------+----------+----------+ 553 |DHCP- |mutually | | | | | 554 |Snooping |exclusive |compatible| - |compatible|compatible| 555 +----------+----------+----------+----------+----------+----------+ 556 |Data- |mutually | | | | | 557 |Snooping |exclusive |compatible|compatible| - |compatible| 558 +----------+----------+----------+----------+----------+----------+ 559 | |mutually | | | | | 560 |Validating|exclusive |compatible|compatible|compatible| - | 561 +----------+----------+----------+----------+----------+----------+ 563 Figure 2: Table of Mutual Exclusions 565 4.3. Perimeter 567 4.3.1. SAVI-DHCP Perimeter Overview 569 SAVI devices can form a perimeter separating untrusted and trusted 570 areas, similarly to SAVI-FCFS (refer to Section 2.5 of [RFC6620]). 571 Each SAVI device need only establish bindings for a client if it is 572 connected to that client by a link that crosses the perimeter that 573 encloses the SAVI device. 575 The perimeter is primarily designed for scalability. This has two 576 implications. First, SAVI devices only need to establish bindings 577 for directly attached clients, or clients indirectly attached through 578 non-SAVI device, rather than all the clients in the network. Second, 579 each SAVI device only need to check traffic from clients attached to 580 it, without checking all the traffic passing by. 582 Consider the example in Figure 1. The protection perimeter is formed 583 by SAVI Device A, B and C. In this case, SAVI device B doesn't create 584 a binding for client A. However, because SAVI device A filters 585 spoofing traffic from client A, SAVI device B can avoid receiving 586 spoofing traffic from client A. 588 There is three main differences between the SAVI-DHCP protection 589 perimeter and SAVI-FCFS protection perimeter: 591 (1) SAVI-DHCP follows the state announced in DHCP messages, so there 592 is no need to distribute state using Neighbor Solicitation/ 593 Neighbor Advertisement messages. 595 (2) The perimeter in SAVI-DHCP is not only a perimeter for data 596 packets, but also a perimeter for DHCP messages. The placement 597 of DHCP Relay/Server, which is not involved in SAVI-FCFS , is 598 related with the construction of the perimeter. The requirement 599 on the placement and configuration of DHCP Relay/Server are 600 discussed in Section 4.3.3. 602 (3) Downstream/upstream links MUST be distinguished when configuring 603 the perimeter to avoid establishing binding for addresses of 604 other networks. 606 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 608 Through configuring attribute of each attachment properly, a 609 perimeter separating untrusted area and trusted area can be formed: 611 (1) Configure Validating and DHCP-Snooping attribute on the direct 612 attachments of all the DHCP clients. 614 (2) Configure Validating and DHCP-Snooping attribute on the indirect 615 attachments of all the DHCP clients(i.e., DHCP clients on the 616 downstream links). 618 (3) Configure Trust attribute on the attachments of other SAVI 619 devices. 621 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 622 have only attachments from SAVI devices or upstream devices, set 623 their attachments to SAVI devices with Trust attribute. 625 (5) Configure DHCP-Trust attribute on the direct attachments of 626 trusted DHCP relays/servers. 628 (6) Optional: configure filters on the upstream links to filter out 629 spoofing of local addresses from other networks. If the 630 upstream networks are completely trustable, Trust attribute can 631 be used on the upstream links. 633 In this way, the points of attachments with Validating attribute (and 634 generally together with attachments of upstream devices) on SAVI 635 devices can form a perimeter separating DHCP clients and trusted 636 devices. Data packet check is only performed on the perimeter. The 637 perimeter is also a perimeter for DHCP messages. DHCP-Trust 638 attribute is only configured on the inside links of the perimeter. 639 Only DHCP server-client messages originated in the perimeter is 640 trusted. 642 4.3.3. On the Placement of DHCP Server/Relay 644 Based on the configuration guideline, it can be found that the SAVI 645 devices only trust DHCP Server-Client messages originated inside the 646 perimeter. It means the trusted DHCP relays/servers must be placed 647 in the perimeter. DHCP server-client messages will be filtered on 648 the perimeter (Note: server-relay messages will not be filtered). In 649 this way, DHCP server-client messages from bogus DHCP servers are 650 filtered on the perimeter, and then the SAVI devices can be protected 651 from fabricated DHCP messages. 653 Such a requirement is due to the limitation of this binding based 654 mechanism. This document makes no assumption that the DHCP server- 655 client messages arriving the perimeter from the outside can be 656 trusted. The binding anchor of a trusted remote DHCP server can be 657 shared by a bogus DHCP server. Thus, the SAVI device cannot 658 distinguish bogus and valid DHCP messages only based on the 659 associated binding anchor of DHCP messages in such case. 661 Note that even if a DHCP server is valid, it may be not contained in 662 the perimeter based on the guideline. For example, in Figure 1, DHCP 663 server A is valid, but it is attached to a Non-SAVI device. The Non- 664 SAVI device may be attached by attackers which generate fabricated 665 DHCP messages. This binding based mechanism may not have the ability 666 to distinguish whether a message received from the attachment of the 667 Non-SAVI device 1 is from DHCP server A or the attackers. If the 668 DHCP server A is contained in the perimeter, the Non-SAVI device 1 669 will also be contained in the perimeter. However, the Non-SAVI 670 device 1 can introduce fabricated DHCP messages into the perimeter. 671 Thus, the DHCP server A cannot be contained in the perimeter. 673 In this case, the SAVI devices can set up bindings for addresses 674 assigned by DHCP server A through snooping the messages relayed by 675 trusted relay in the network. For example, the DHCP relay may relay 676 messages between DHCP server A and the clients in the network, and 677 the SAVI devices can snoop messages from the DHCP relay which is 678 inside the perimeter. The authentication mechanism (i.e., IPSec, as 679 specified in section 21.1 of [RFC3315]) enforced between the DHCP 680 relay and the DHCP server outside the perimeter can compensate this 681 binding based mechanism. It is SUGGESTED to configure IPSec between 682 the DHCP relay and the DHCP server in such case. If source address 683 validation is enforced in the whole network, which makes the source 684 IP address trustable, the DHCP relay and the DHCP server can simply 685 authenticate the messages from each other based on the source IP 686 address without the requirement to deploy IPSec. 688 Another consideration on the placement is that if the DHCP server/ 689 relay is not inside the perimeter, the SAVI devices may not be able 690 to set up bindings correctly, because the SAVI devices may not be on 691 the path between the clients and the server/relay, or the DHCP 692 messages are encapsulated (e.g., Relay-reply and Relay-forward). 694 5. Binding State Table (BST) 696 Binding State Table is used to contain the bindings between the IP 697 addresses assigned to the attachments and the corresponding binding 698 anchors of the attachments. Each entry of the table, i.e., binding 699 entry, has 5 fields: 701 o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer 702 property of the attachment. 704 o IP Address(Address): the IP address assigned to the attachment by 705 DHCP. 707 o State: the state of the binding. Possible values of this field 708 are listed in Section 6.2 and Section 7.3. 710 o Lifetime: the remaining seconds of the binding. The Lifetime 711 field counts down automatically. 713 o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of 714 the corresponding DHCP transaction. TID field is used to 715 associate DHCP Server-Client messages with corresponding binding 716 entries. 718 IA does not present in the BST. On the one hand, IA is not found to 719 be necessary because the lease of each address in one IA is assigned 720 respectively. On the other hand, when the binding is set up based on 721 data-snooping, IA cannot be recovered from the leasequery protocol. 722 Besides, there is no IA for DHCPv4. 724 An instance of this table is shown in Figure 3. 726 +---------+----------+----------+-----------+-------+ 727 | Anchor | Address | State | Lifetime |TID | 728 +---------+----------+----------+-----------+-------+ 729 | Port_1 | IP_1 | BOUND | 65535 |TID_1 | 730 +---------+----------+----------+-----------+-------+ 731 | Port_1 | IP_2 | BOUND | 10000 |TID_2 | 732 +---------+----------+----------+-----------+-------+ 733 | Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | 734 +---------+----------+----------+-----------+-------+ 736 Figure 3: Instance of BST 738 6. DHCP Snooping Process 740 This section specifies the process of setting up bindings based on 741 DHCP snooping, named DHCP Snooping Process. This process is 742 illustrated making use of a state machine. 744 6.1. Rationale 746 The rationale of the DHCP Snooping Process is that if a DHCP client 747 is legitimate to use a DHCP address, the DHCP address assignment 748 procedure which assigns the IP address to the client must have been 749 performed on the attachment of the client. This basis stands when 750 the SAVI device is always on the path(s) from the DHCP client to the 751 DHCP server(s)/relay(s). Without considering the movement of DHCP 752 clients, the SAVI device should be the CUT VERTEX whose removal will 753 disjoin the DHCP client and the remaining network containing the DHCP 754 server(s)/relay(s). For most of the networks whose topologies are 755 simple, it is possible to deploy this SAVI function at proper devices 756 to meet this requirement. 758 However, a deployment of this SAVI function may not meet the 759 requirement. For example, there are multiple paths from a DHCP 760 client to the DHCP server and the SAVI device is only on one of them. 761 Then the SAVI device may not be able to snoop the DHCP procedure. 762 Host movement may also make this requirement can not be met. For 763 example, when a DHCP client moves from one attachment to another 764 attachment in the same network, it may not reinitialize its interface 765 or send a Confirm message because of incomplete protocol 766 implementation. Thus, there can be scenarios in which only 767 performing this DHCP snooping process is insufficient to set up 768 bindings for all the valid DHCP addresses. These exceptions and the 769 solutions are discussed in Section 7. 771 6.2. Binding States Description 773 Following binding states present in this process and the 774 corresponding state machine: 776 NO_BIND: The state before a binding has been set up. 778 INIT_BIND: A potential binding has been set up. 780 BOUND: The binding has been set up. 782 6.3. Events 784 This section describes events in this process and the corresponding 785 state machine. 787 6.3.1. Timer Expiration Event 789 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 791 6.3.2. Control Message Arriving Events 793 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 794 received. 796 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 798 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 800 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 801 received. 803 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 805 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 806 option is received. 808 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 810 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 811 received. 813 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 814 received. 816 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 817 section 4.3.3 of [RFC5007]) is received. 819 Note: the events listed here do not cover all the DHCP messages in 820 section 3. The messages which do not really determine address usage 821 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 822 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 823 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 824 to section 6.4.2.1), are not included. 826 Moreover, only if a DHCP message can pass the following checks, the 827 corresponding event is regarded as a valid event: 829 o Attribute check: the DHCP Server-Client messages and 830 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 831 attribute; the DHCP Client-Server messages should be from 832 attachments with DHCP-Snooping attribute. 834 o Destination check: the DHCP Server-Client messages should be 835 destined to attachments with DHCP-Snooping attribute. This check 836 is performed to ensure the binding is set up on the SAVI device 837 which is nearest to the destination client. 839 o Binding anchor check: the DHCP Client-Server messages which may 840 trigger modification or removal of an existing binding entry must 841 have matched binding anchor with the corresponding entry. 843 o TID check: the DHCP Server-Client/Client-Server messages which 844 may cause modification on existing binding entries must have 845 matched TID with the corresponding entry. Note that this check 846 is not performed on Leasequery and Leasequery-reply messages as 847 they are exchanged between the SAVI devices and the DHCP servers. 848 Besides, this check is not performed on DHCP Renew/Rebind 849 messages (Section 6.4.3). 851 o Binding limitation check: the DHCP messages must not cause new 852 binding setup on an attachment whose binding entry limitation has 853 been reached. (refer to Section 11.6). 855 o Address check: the source address of the DHCP messages should 856 pass the check specified in Section 8.2. 858 On receiving a DHCP message without triggering a valid event, the 859 state will not transit and actions will not be performed. Note that 860 if a message does not trigger a valid event but it can pass the 861 checks in Section 8.2, it MUST be forwarded. 863 6.4. The State Machine of DHCP Snooping Process 865 This section specifies the transits of each state and the 866 corresponding actions. 868 6.4.1. From NO_BIND to INIT_BIND 870 6.4.1.1. Trigger Events 872 Trigger events: EVE_DHCP_REQUEST, EVE_DHCP_SOLICIT_RC, 873 EVE_DHCP_CONFIRM, EVE_DHCP_REBOOT. 875 6.4.1.2. Following Actions 877 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_SOLICIT_RC/ 878 EVE_DHCP_REBOOT: 880 The SAVI device MUST forward the message. 882 The SAVI device will generate an entry in the BST. The Binding 883 anchor field is set to the binding anchor of the attachment from 884 which the message is received. The State field is set to INIT_BIND. 885 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 886 field is set to the TID of the message. If the message is DHCPv4 887 Request or DHCPv4 Reboot, the Address field can be set to the address 888 to request, i.e., the 'requested IP address'. An example of the 889 entry is illustrated in Figure 4. 891 +---------+-------+---------+-----------------------+-------+ 892 | Anchor |Address| State | Lifetime |TID | 893 +---------+-------+---------+-----------------------+-------+ 894 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 895 +---------+-------+---------+-----------------------+-------+ 897 Figure 4: Binding entry in BST on Request/Rapid Commit/Reboot 898 triggered initialization 900 If the triggering event is EVE_DHCP_CONFIRM: 902 The SAVI device MUST forward the message. 904 The SAVI device will generate corresponding entries in the BST for 905 all the addresses in each the IA option of the Confirm message. The 906 Binding anchor field is set to the binding anchor of the attachment 907 from which the message is received. The State field is set to 908 INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. 909 The TID field is set to the TID of the message. The Address field is 910 set to the address(es) to confirm. An example of the entries is 911 illustrated in Figure 5. 913 +---------+--------+---------+-----------------------+-------+ 914 | Anchor | Address| State | Lifetime |TID | 915 +---------+--------+---------+-----------------------+-------+ 916 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 917 +---------+--------+---------+-----------------------+-------+ 918 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 919 +---------+--------+---------+-----------------------+-------+ 921 Figure 5: Binding entry in BST on Confirm triggered initialization 923 6.4.2. From INIT_BIND to Other States 925 6.4.2.1. Trigger Events 927 Trigger events: EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE. 929 Note: If no DHCP Server-Client messages which assign addresses or 930 confirm addresses are received, corresponding entries will expire 931 automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4 932 NAK) are not specially processed. 934 6.4.2.2. Following Actions 936 If the trigger event is EVE_DHCP_REPLY: 938 The message MUST be forwarded to the corresponding client. 940 If the message is DHCPv4 ACK, the Address field of the corresponding 941 entry (i.e., the binding entry whose TID is the same of the message) 942 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 943 The Lifetime field is set to the sum of the lease time in ACK message 944 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 946 If the message is DHCPv6 Reply, there are following cases: 948 1. If the status code is not "Success", no modification on 949 corresponding entries will be made. Corresponding entries will 950 expire automatically if no "Success" Reply is received during the 951 lifetime. The entries are not removed immediately due to the client 952 may be able to use the addresses whenever a "Success" Reply is 953 received ("If the client receives any Reply messages that do not 954 indicate a NotOnLink status, the client can use the addresses in the 955 IA and ignore any messages that indicate a NotOnLink status." 956 [RFC3315]). 958 2. If the status code is "Success", the SAVI device checks the IA 959 options in the Reply message. 961 2.1 If there are no IA options in the Reply message, the DHCP Reply 962 message is in response to a Confirm message. The state of the 963 binding entries with matched TID is changed to BOUND. Because 964 [RFC3315] does not require lease time of addresses to be contained in 965 the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] 966 message querying by IP address to All_DHCP_Servers multicast address 967 [RFC3315] or a list of configured DHCP server addresses. The 968 Leasequery message is generated for each IP address if multiple 969 addresses are confirmed. The Lifetime of corresponding entries is 970 set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after 971 MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example 972 of the entries is illustrated in Figure 6. The related security 973 problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the 974 SAVI device does not send the LEASEQUERY message, a pre-configured 975 lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 976 (Note: it is SUGGESUTED to use T1 configured on DHCP servers as the 977 DHCP_DEFAULT_LEASE.) 979 2.2 If there are IA options in the Reply message, the SAVI device 980 checks each IA option. When the first assigned address is found, the 981 Address field of the binding entry with matched TID is set to the 982 address. The Lifetime field is set to the sum of the lease time in 983 Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed 984 to BOUND. If there are more than one address assigned in the 985 message, new binding entries are set up for the remaining address 986 assigned in the IA options. An example of the entries is illustrated 987 in Figure 7. SAVI devices do not specially process IA options with 988 NoAddrsAvail status, because there should be no address contained in 989 such IA options. 991 Note: the SAVI devices do not check if the assigned addresses are 992 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 993 only source of valid addresses. However, the DHCP servers should be 994 configured to make sure no duplicated addresses are assigned. 996 +---------+----------+-------+------------------------+-------+ 997 | Anchor | Address | State | Lifetime |TID | 998 +---------+----------+-------+------------------------+-------+ 999 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1000 +---------+----------+-------+------------------------+-------+ 1001 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1002 +---------+----------+-------+------------------------+-------+ 1004 Figure 6: From INIT_BIND to BOUND on DHCP Reply in response to 1005 Confirm 1007 +---------+----------+-------+------------------------+-------+ 1008 | Anchor | Address | State | Lifetime |TID | 1009 +---------+----------+-------+------------------------+-------+ 1010 | Port_1 | Addr1 | BOUND |Lease time+ |TID | 1011 | | | |MAX_DHCP_RESPONSE_TIME | | 1012 +---------+----------+-------+------------------------+-------+ 1013 | Port_1 | Addr2 | BOUND |Lease time+ |TID | 1014 | | | |MAX_DHCP_RESPONSE_TIME | | 1015 +---------+----------+-------+------------------------+-------+ 1017 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1018 Request 1020 If the trigger event is EVE_ENTRY_EXPIRE: 1022 The entry MUST be deleted from BST. 1024 6.4.3. From BOUND to Other States 1026 6.4.3.1. Trigger Events 1028 Trigger events: EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 1029 EVE_DHCP_REPLY, EVE_DHCP_LEASEQUERY, EVE_DHCP_RENEW, EVE_DHCP_REBIND. 1031 6.4.3.2. Following Actions 1033 If the trigger event is EVE_ENTRY_EXPIRE: 1035 Remove the corresponding entry in BST. 1037 If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE: 1039 The message MUST be forwarded. 1041 The SAVI device first gets all the addresses ("Requested IP address" 1042 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1043 IA options of DHCPv6 Decline/Release) to decline/release in the 1044 message. Then the corresponding entries MUST be removed. 1046 If the trigger event is EVE_DHCP_RENEW/EVE_DHCP_REBIND: 1048 The message MUST be forwarded. 1050 In such case, a new TID will be used by the client. The TID field of 1051 the corresponding entries MUST be set to the new TID. Note that TID 1052 check will not be performed on such messages. 1054 If the trigger event is EVE_DHCP_REPLY: 1056 The message MUST be forwarded. 1058 The DHCP Reply messages received in current states should be in 1059 response to DHCP Renew/Rebind. 1061 If the message is DHCPv4 ACK, the SAVI device just simply update the 1062 binding entry with matched TID, with the Lifetime field set to be the 1063 sum of the new lease time and MAX_DHCP_RESPONSE_TIME. 1065 If the message is DHCPv6 Reply, the SAVI device checks each IA 1066 Address option in each IA option. If the valid lifetime of an IA 1067 address option is 0, the binding entry with matched TID and address 1068 is removed. Or else, set the Lifetime field of the binding entry 1069 with matched TID and address to be the sum of the new valid lifetime 1070 and MAX_DHCP_RESPONSE_TIME. 1072 The SAVI device does not specially process IA options in Reply 1073 message with status NoBinding, because no address is contained in 1074 such IA options and no actions will be performed. 1076 If the trigger event is EVE_DHCP_LEASEQUERY: 1078 The message MUST be forwarded. 1080 The message should be in response to the Leasequery message sent in 1081 Section 6.4.2. The related binding entry can be determined based on 1082 the address in the IA Address option in the Leasequery-reply message. 1083 The Lifetime field of the corresponding binding entry is set to the 1084 sum of the lease time in the LEASEQUERY_REPLY message and 1085 MAX_DHCP_RESPONSE_TIME. 1087 6.5. Table of State Machine 1089 The main state transits are listed as follows. Note that not all the 1090 details are specified in the table and the diagram. 1092 State Event Action Next State 1093 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1094 INIT_BIND RPL Record lease time BOUND 1095 (send lease query if no lease) 1096 INIT_BIND Timeout Remove entry NO_BIND 1097 BOUND RLS/DCL Remove entry NO_BIND 1098 BOUND Timeout Remove entry NO_BIND 1099 BOUND RPL Set new lifetime BOUND 1100 BOUND LQR Record lease time BOUND 1102 Figure 8: Table of Transit 1104 RQ: EVE_DHCP_REQUEST 1106 CF: EVE_DHCP_CONFIRM 1108 RC: EVE_DHCP_SOLICIT_RC 1110 RE: EVE_DHCP_REBOOT 1112 RPL: EVE_DHCP_REPLY 1113 DCL: EVE_DHCP_DECLINE 1115 RLS: EVE_DHCP_RELEASE 1117 LQR: EVE_DHCP_LEASEQUERY 1119 Timeout: EVE_ENTRY_EXPIRE 1121 +-------------+ 1122 | | 1123 /---------| NO_BIND |<----------\ 1124 | ------>| | | 1125 | | +-------------+ |EVE_DHCP_RELEASE 1126 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1127 EVE_DHCP_CONFIRM | |TIMEOUT |TIMEOUT 1128 EVE_DHCP_SOLICIT_RC| | | 1129 EVE_DHCP_REBOOT | | | 1130 | | | 1131 | | | 1132 v | | 1133 +-------------+ +------------+ 1134 | | EVE_DHCP_REPLY | | 1135 | INIT_BIND ------------------------>| BOUND |<-\ 1136 | | | | | 1137 +-------------+ +------------+ | 1138 | | 1139 \--------/ 1140 EVE_DHCP_REPLY 1141 EVE_DHCP_LEASEQUERY 1143 Figure 9: Diagram of Transit 1145 7. Data Snooping Process 1147 7.1. Scenario 1149 The rationale of the DHCP Snooping Process specified in Section 6 is 1150 that if a DHCP client's use of a DHCP address is legitimate, the 1151 corresponding DHCP address assignment procedure must have been 1152 finished on the attachment of the DHCP client. This is the case 1153 stands when the SAVI device is persistently on the path(s) from the 1154 DHCP client to the DHCP server(s)/relay(s). However, there are two 1155 case when this does not work: 1157 o Multiple paths: there is more than one feasible layer-2 paths 1158 from the client to the DHCP server/relay, and the SAVI device is 1159 not on everyone of them. The client may get its address through 1160 one of the paths not passing by the SAVI device, but packets from 1161 the client can travel through paths that pass through the SAVI 1162 device. Because the SAVI device could not snoop the DHCP packet 1163 exchange procedure, the DHCP snooping procedure cannot set up the 1164 corresponding binding. 1166 o Dynamic path: there is only one feasible layer-2 path from the 1167 client to the DHCP server/relay, but the path is dynamic due to 1168 topology change (for example, some link turns broken due to 1169 failure or as planned) or layer-2 path change. This situation 1170 also covers the local-link movement of clients without address 1171 confirm/re-configuration process. For example, a host changes 1172 its attached switch port in a very short time. In such cases, 1173 the DHCP snooping process will not set up the corresponding 1174 binding. 1176 Data Snooping Process prevents permanently blocking legitimate 1177 traffic in case of these two exceptions. This process is performed 1178 on attachments with the Data-Snooping attribute. Data packets 1179 without matching binding entry may trigger this process to set up 1180 bindings. 1182 Snooping data traffic introduces considerable burden on the processor 1183 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1184 overhead of this process, the implementation of this process is a 1185 conditional SHOULD. This function SHOULD be enabled unless the 1186 implementation is known to be used in the scenarios without the above 1187 exceptions. For example, if the implementation is to be used in 1188 networks with tree topology and without host local-link movement, 1189 there is no need to implement this process in such scenarios. 1191 This process is not intended to set up a binding whenever a data 1192 packet without matched binding entry is received. Instead, unmatched 1193 data packets trigger this process probabilistically and generally a 1194 number of unmatched packets will be discarded before the binding is 1195 set up. 1197 7.2. Rationale 1199 This process makes use of NS/ARP and DHCP Leasequery to set up 1200 bindings. If an address is not used by another client in the 1201 network, and the address has been assigned in the network, the 1202 address can be bound with the binding anchor of the attachment from 1203 which the unmatched packet is received. 1205 The security issues about this process is discussed is Section 11.1. 1207 7.3. Additional Binding States Description 1209 In addition to Section 6.2, new states used in this process are 1210 listed here: 1212 DETECTION: The address in the entry is under local duplication 1213 detection. 1215 RECOVERY: The SAVI device is querying the assignment and lease time 1216 of the address in the entry through DHCP Leasequery. 1218 7.4. Events 1220 Additional events in this process are described here. Also, if an 1221 event will trigger the creation of a new binding entry, the binding 1222 entry limit on the binding anchor MUST NOT be exceeded. 1224 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1226 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1227 against an address in DETECTION state is received from a host other 1228 than the one for which the entry was added. 1230 EVE_DATA_LEASEQUERY: 1232 IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1233 is received. 1235 IPv6: A successful LEASEQUERY-REPLY is received. 1237 The triggering packet should pass the following checks to trigger a 1238 valid event: 1240 o Attribute check: the data packet should be from attachments with 1241 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1242 messages should be from attachments with DHCP-Snooping attribute. 1244 o Binding limitation check: the DHCP messages must not cause new 1245 binding setup on an attachment whose binding entry limitation has 1246 been reached. (refer to Section 11.6). 1248 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1249 DHCP Leasequery messages must pass the check specified in 1250 Section 8.2. For EVE_DATA_CONFLICT, the source address and 1251 target address of the ARP or NA messages must pass the check 1252 specified in Section 8.2. 1254 o Interval check: the interval between two successive 1255 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1256 smaller than DATA_SNOOPING_INTERVAL. 1258 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must 1259 have matched TID with the corresponding entry. 1261 o Prefix check: the source address of the data packet should be of 1262 a valid local prefix, as specified in section 7 of [RFC7039]. 1264 7.5. State Machine of Binding Recovery Process 1266 Through using additional states, the state machine of this process 1267 doesn't conflict the regular process described in Section 6. Thus, 1268 it can be implemented separately without changing the state machine 1269 in Section 6. 1271 7.5.1. From NO_BIND to DETECTION 1273 7.5.1.1. Trigger Event 1275 Trigger event: EVE_DATA_UNMATCH. 1277 7.5.1.2. Following Actions 1279 Make a probabilistic determination whether to act on this event. The 1280 probability can be configured or calculated based on the state of the 1281 SAVI device. This probability should be low enough to mitigate the 1282 damage from DoS attack against this process. 1284 Create a new entry in the BST. Set the Binding Anchor field to the 1285 corresponding binding anchor of the attachment. Set the Address 1286 field to be source address of the packet. Set the State field to 1287 DETECTION. Set the Lifetime of the created entry to 1288 2*DETECTION_TIMEOUT. 1290 Check if the address has a local conflict (it violates an address 1291 being used by another node): 1293 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1294 [RFC826]or a ARP probe [RFC5227] on the address; if there is no 1295 response message after DETECTION_TIMEOUT, send another ARP 1296 Request or ARP probe; 1298 (2) IPv6 address: send a Neighbor Solicitation message [RFC4861] 1299 targeting on the address; if there is no response message after 1300 DETECTION_TIMEOUT, send another Neighbor Solicitation message. 1302 Because the delivery of detection message is unreliable, the 1303 detection message may fail to reach the targeting node. If there is 1304 a node that has the IP address seen in the Data Snooping Process, it 1305 may not get the detection messages. This failure mode enables an 1306 attack against the Data Snooping Process. Thus, the detection is 1307 performed again if there is no response after the first detection. 1309 The messages MUST NOT be sent to the attachment from which the 1310 triggering packet is received. 1312 The packet which triggers this event SHOULD be discarded. 1314 This local conflict process SHOULD be performed. If it is not 1315 performed, the state of the entry is set to RECOVERY, the lifetime is 1316 set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified 1317 in the following section will be performed directly. 1319 An example of the entry is illustrated in Figure 10. 1321 +---------+-------+---------+-----------------------+-------+ 1322 | Anchor |Address| State | Lifetime |TID | 1323 +---------+-------+---------+-----------------------+-------+ 1324 | Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | 1325 +---------+-------+---------+-----------------------+-------+ 1327 Figure 10: Binding entry in BST on data triggered initialization 1329 7.5.2. From DETECTION to Other States 1331 7.5.2.1. Trigger Event 1333 Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT. 1335 7.5.2.2. Following Actions 1337 If the trigger event is EVE_ENTRY_EXPIRE: 1339 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1340 by IP address to each DHCPv4 server with IP Address Lease Time 1341 option (option 51). A list of authorized DHCP servers are kept 1342 by the SAVI device. The list should be pre-configured or 1343 discovered by sending DHCPv4 Discover messages and parsing the 1344 replied DHCPv4 Offer messages. Change the state of the 1345 corresponding entry to RECOVERY. Change the lifetime of the 1346 entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the 1347 TID used in the DHCPLEASEQUERY message. If there is no response 1348 message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to 1349 each DHCPv4 server again. 1351 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1352 address to All_DHCP_Relay_Agents_and_Servers multicast address 1353 or a list of pre-configured DHCPv6 server addresses. Change the 1354 state of the corresponding entry to RECOVERY. Change the 1355 lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID 1356 field is set to the TID used in the LEASEQUERY message. If 1357 there is no response message after MAX_LEASEQUERY_DELAY, send 1358 the LEASEQUERY message again. 1360 An example of the entry is illustrated in Figure 11. 1362 +---------+-------+---------+-----------------------+-------+ 1363 | Anchor |Address| State | Lifetime |TID | 1364 +---------+-------+---------+-----------------------+-------+ 1365 | Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | 1366 +---------+-------+---------+-----------------------+-------+ 1368 Figure 11: Binding entry in BST on Lease Query 1370 If the trigger event is EVE_DATA_CONFLICT: 1372 Remove the entry. 1374 7.5.3. From RECOVERY to Other States 1376 7.5.3.1. Trigger Event 1378 Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY. 1380 7.5.3.2. Following Actions 1382 If the trigger event is EVE_DATA_LEASEQUERY: 1384 IPv4 address: 1386 (1) Send an ARP Request with the Target Protocol Address set to the 1387 IP address in the corresponding entry. The ARP Request is only 1388 sent to the attachment which triggers the binding. If there is 1389 no response after DETECTION_TIMEOUT, send another ARP Request. 1390 If there is still no response, the following actions will not be 1391 performed. If there is only one identical response, get the 1392 sender hardware address. Check if the 'chaddr' field (hardware 1393 address) of the DHCPLEASEACTIVE message matches the sender 1394 hardware address. If the two addresses do not match, the 1395 following actions will not be performed. If there is more than 1396 one response, if any of the sender hardware addresses matches 1397 the 'chaddr' field (hardware address) of the DHCPLEASEACTIVE 1398 message, the following actions are to be performed. 1400 (2) Change the state of the corresponding binding to BOUND. Set 1401 life time to the sum of the value encoded in IP Address Lease 1402 Time option of the DHCPLEASEACTIVE message and 1403 MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1405 IPv6 address: 1407 (1) Send a Neighbor Solicitation message with the target address set 1408 to the IP address in the corresponding entry. The Neighbor 1409 Solicitation is only sent to the attachment which triggers the 1410 binding. If there is no response after DETECTION_TIMEOUT, send 1411 another Neighbor Solicitation. If there is still no response, 1412 the following actions will not be performed. 1414 (2) Change the state of the corresponding binding to BOUND. Set the 1415 lifetime to the sum of the valid lifetime extracted from 1416 OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and 1417 MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1419 (3) After the above checks, if multiple addresses are specified in 1420 the LEASEQUERY-REPLY message and there are no corresponding 1421 binding entries, new entries MUST also be created 1422 correspondingly on the same binding anchor. 1424 If responses are received from multiple DHCP servers, the conflict 1425 resolution mechanisms specified in section 6.8 of [RFC4388] and 1426 section 4.3.4 of [RFC5007] will be used to determine which message 1427 should be used. 1429 If the trigger event is EVE_ENTRY_EXPIRE: 1431 Remove the entry. 1433 7.5.4. After BOUND 1435 Note that the TID field contains no value after the binding state 1436 changes to BOUND. The TID field is recovered from snooping DHCP 1437 Renew/Rebind messages. Because TID is used to associate binding 1438 entries with messages from DHCP servers, it must be recovered; or 1439 else a number of state transits of this mechanism will be not 1440 executed normally. 1442 7.5.4.1. Trigger Event 1444 Trigger events: EVE_DHCP_RENEW, EVE_DHCP_REBIND. 1446 7.5.4.2. Following Action 1448 Set the TID field of the corresponding entry to the TID in the 1449 triggering message. 1451 7.6. Table of State Machine 1453 The main state transits are listed as follows. 1455 State Event Action Next State 1456 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1457 DETECTION Timeout Send Leasequery RECOVERY 1458 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1459 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND 1460 RECOVERY Timeout Remove entry NO_BIND 1461 BOUND RENEW/REBIND Record TID BOUND 1463 Figure 12: Table of Transit 1465 RENEW: EVE_DHCP_RENEW 1467 REBIND: EVE_DHCP_REBIND 1469 Timeout: EVE_ENTRY_EXPIRE 1470 +-------------+ 1471 | | 1472 /---------| NO_BIND |<--------\ 1473 | ------>| | | TIMEOUT 1474 | | +-------------+ |(2nd LQ_DELAY) 1475 EVE_DATA_UNMATCH | | | 1476 | | | 1477 1st | | | 1478 DETECTION_TIMEOUT | | | 1st LQ_DELAY 1479 /------\ | | | /---------\ 1480 | | | | EVE_DATA_CONFLICT | | | 1481 | v v | | v | 1482 | +-------------+ TIMEOUT +------------+ | 1483 | | |(2nd DETECTION_TIMEOUT) | | | 1484 \----| DETECTION ------------------------>| RECOVERY ----/ 1485 | | | | 1486 +-------------+ +------------+ 1487 EVE_DATA_LEASEQUERY| 1488 /----------\ (+ 2x DETECTION) | 1489 EVE_DHCP_RENEW| | | 1490 EVE_DHCP_REBIND| +-----v-------+ | 1491 | | | | 1492 \----| BOUND |<----------/ 1493 | | 1494 +-------------+ 1496 Figure 13: Diagram of Transit 1498 LQ_DELAY: MAX_LEASEQUERY_DELAY 1500 8. Filtering Specification 1502 This section specifies how to use bindings to filter out spoofing 1503 packets. 1505 Filtering policies are different for data packets and control 1506 packets. DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] 1507 messages that may cause state transit are classified as control 1508 packet. Neighbor Advertisement (NA) and ARP Reply are also included 1509 in control packet because the Target Address of NA and ARP Reply 1510 should be checked to prevent spoofing. All other packets are 1511 classified as data packets. 1513 8.1. Data Packet Filtering 1515 Data packets from attachments with the Validating attribute MUST be 1516 checked. 1518 Packet whose source IP address is a link-local address will not be 1519 checked. Note: as explained in Section 1, a SAVI solution for link- 1520 local addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to 1521 check packets with link-local source address. 1523 If the source IP address of a packet is not a link-local address, but 1524 there is not a matched entry in BST with state BOUND, this packet 1525 MUST be discarded. However, the packet may trigger Data Snooping 1526 Process Section 7 if Data-Snooping attribute is set on the 1527 attachment. 1529 Data packets from attachments with no attribute will forwarded 1530 without checking. 1532 The SAVI device MAY record any violation. 1534 8.2. Control Packet Filtering 1536 For attachments with the Validating attribute: 1538 Discard DHCPv4 Client-Server message messages whose source IP address 1539 is neither all zeros nor bound with the corresponding binding anchor 1540 in the BST. 1542 Discard DHCPv6 Client-Server message messages whose source IP address 1543 is neither a link-local address nor bound with the corresponding 1544 binding anchor in the BST. 1546 Discard NDP messages whose source IP address is neither a link-local 1547 address nor bound with the corresponding binding anchor. Especially, 1548 discard NA message whose target address is neither a link-local 1549 address nor bound with the corresponding binding anchor. 1551 Discard ARP messages whose protocol is IP and sender protocol address 1552 is neither all zeros address nor bound with the corresponding binding 1553 anchor. Especially, discard ARP Reply messages whose target protocol 1554 address is not bound with the corresponding binding anchor. 1556 For attachments with other attributes: 1558 Discard DHCP Server-Client message not from attachments with the 1559 DHCP-Trust attribute or Trust attribute. 1561 For attachments with no attribute: 1563 Discard DHCP Server-Client message from such attachments. 1565 The SAVI device MAY record any violation. 1567 9. State Restoration 1569 If a SAVI device reboots, the information kept in volatile memory 1570 will be lost. This section specifies the restoration of attribute 1571 configuration and BST. 1573 9.1. Attribute Configuration Restoration 1575 The loss of attribute configuration will not break the network: no 1576 action will be performed on traffic from attachments with no 1577 attribute. However, the loss of attribute configuration makes this 1578 SAVI function unable to work. 1580 To avoid the loss of binding anchor attribute configuration, the 1581 configuration MUST be able to be stored in non-volatile storage. 1582 After the reboot of SAVI device, if the configuration of binding 1583 anchor attribute can be found in non-volatile storage, the 1584 configuration MUST be used. 1586 9.2. Binding State Restoration 1588 The loss of binding state will cause the SAVI devices discard 1589 legitimate traffic. Purely using the Data Snooping Process to 1590 recover a large number of bindings is of heavy overhead and 1591 considerable delay. Thus, to recover bindings from non-volatile 1592 storage, as specified below, is RECOMMENDED. 1594 Binding entries MAY be saved into non-volatile storage whenever a new 1595 binding entry changes to BOUND state. If a binding with BOUND state 1596 is removed, the saved entry MUST be removed correspondingly. The 1597 time when each binding entry is established is also saved. 1599 Immediately after reboot, the SAVI device SHOULD restore binding 1600 states from the non-volatile storage. The system time of save 1601 process MUST be stored. After rebooting, the SAVI device MUST check 1602 whether each entry has been obsolete by comparing the saved lifetime 1603 and the difference between the current time and time when the binding 1604 entry is established. 1606 10. Constants 1608 MAX_DHCP_RESPONSE_TIME 120s 1610 DATA_SNOOPING_INTERVAL 60s and configurable 1612 MAX_LEASEQUERY_DELAY 10s 1614 OFFLINK_DELAY 30s 1616 DETECTION_TIMEOUT 0.5s 1618 11. Security Considerations 1620 11.1. Security Problems about the Data Snooping Process 1622 There are two security problems about the Data Snooping Process 1623 Section 7: 1625 (1) The Data Snooping Process is costly, but an attacker can trigger 1626 it simply through sending a number of data packets. To avoid 1627 Denial of Services attack against the SAVI device itself, the 1628 Data Snooping Process MUST be rate limited. A constant 1629 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1630 Data Snooping Processes on one attachment MUST have a minimum 1631 interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be 1632 configured prudently to avoid Denial of Service attacks. 1634 (2) The Data Snooping Process may set up wrong bindings if the 1635 clients do not reply to the detection probes. An attack will 1636 pass the duplicate detection if the client assigned the target 1637 address does not reply to the detection probes. The DHCP 1638 Leasequery procedure performed by the SAVI device just tells 1639 whether the address is assigned in the network or not. However, 1640 the SAVI device cannot determine whether the address is just 1641 assigned to the triggering attachment from the DHCP Leasequery 1642 Reply. 1644 11.2. Issues about Leaving Clients 1646 After a binding is set up, the corresponding client may leave its 1647 attachment point. It may leave temporarily due to link flapping, or 1648 permanently by moving to a new attachment point or leaving the 1649 network. Since the client may return shortly, the binding should be 1650 kept, or legitimate traffic from the client will be blocked. 1651 However, if the client leaves permanently, it may be insecure to keep 1652 the binding. If the binding anchor is a property of the attachment 1653 point rather than the client, e.g., the switch port, an attacker 1654 which is attached to the attachment point of the leaving client can 1655 send spoofing packets with the addresses assigned to the client. 1656 Even if the binding anchor is a property of the client, it is a waste 1657 of binding resources to keep bindings for departed clients. 1659 The following mechanism is designed to handle the leaving of client: 1661 (1) Whenever a client with the Validating attribute leaves, a timer 1662 of duration OFFLINK_DELAY is set on the corresponding binding 1663 entries. 1665 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 1666 received that targets the address during OFFLINK_DELAY, the 1667 entry MAY be removed. 1669 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 1670 timer. 1672 In this way, the bindings of a departing client are kept for 1673 OFFLINK_DELAY. In case of link flapping, the client will not be 1674 blocked. If the client leaves permanently, the bindings will be 1675 removed after OFFLINK_DELAY. 1677 11.3. Duplicate Bindings to the Same Address 1679 The same address may be bound to multiple binding anchors only if the 1680 binding setup processes successfully complete for each binding 1681 anchor. This mechanism is designed to address the case where a 1682 client moves on the local link, and the case where a client has 1683 multiple attachments to a SAVI device. 1685 There are two security issues with such a design: 1687 First, by allowing one address to be bound to multiple binding 1688 anchors, the traceability of the address is weakened. An address can 1689 be traced to multiple attachments. 1691 Second, in the local link movement scenario, the former binding may 1692 not be removed and it can be used by an attacker sharing the same 1693 binding anchor. For example, when a switch port is used as binding 1694 anchor and the port is shared by an attacker and a client with a hub, 1695 the attacker can make use of the address assigned to the client after 1696 the client leaves. 1698 11.4. Compatibility with DNA (Detecting Network Attachment) 1700 DNA [RFC4436] [RFC6059] is designed to decrease the handover latency 1701 after re-attachment to the same network. DNA mainly relies on 1702 performing reachability test by sending unicast Neighbor 1703 Solicitation/Router Solicitation/ARP Request message to determine 1704 whether a previously configured address is still valid. 1706 Although DNA provides optimization for clients, there is insufficient 1707 information for this mechanism to migrate the previous binding or 1708 establish a new binding. If a binding is set up only by snooping the 1709 reachability test message, the binding may be invalid. For example, 1710 an attacker can perform reachability test with an address bound to 1711 another client. If binding is migrated to the attacker, the attacker 1712 can successfully obtain the binding from the victim. Because this 1713 mechanism wouldn't set up a binding based on snooping the DNA 1714 procedure, it cannot achieve perfect compatibility with DNA. 1715 However, it only means the re-configuration of the interface is 1716 slowed but not prevented. Details are discussed as follows. 1718 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1719 set to a link-local address, and such messages will not be discarded 1720 by the policy specified in Section 8.2. If a client is re-attached 1721 to a previous network, the detection will be completed, and the 1722 address will be regarded as valid by the client. However, the 1723 candidate address is not contained in the probe. Thus, the binding 1724 cannot be recovered through snooping the probe. As the client will 1725 perform DHCP exchange at the same time, the binding will be recovered 1726 from the DHCP Snooping Process. The DHCP Request messages will not 1727 be filtered out in this case because they have link-local source 1728 addresses. Before the DHCP procedure is completed, packets will be 1729 filtered out by the SAVI device. In other words, if this SAVI 1730 function is enabled, Simple DNAv6 will not help reduce the handover 1731 latency. If Data-Snooping attribute is configured on the new 1732 attachment of the client, the data triggered procedure may reduce 1733 latency. 1735 In DNAv4 [RFC4436], the ARP probe will be discarded because an 1736 unbound address is used as the sender protocol address. As a result, 1737 the client will regard the address under detection is valid. 1738 However, the data traffic will be filtered. The DHCP Request message 1739 sent by the client will not be discarded, because the source IP 1740 address field should be all zero as required by [RFC2131]. Thus, if 1741 the address is still valid, the binding will be recovered from the 1742 DHCP Snooping Process. 1744 11.5. Authentication in DHCPv6 Leasequery 1746 As required in section 5 of RFC5007, DHCPv6 Leasequery 'Should' use 1747 IPsec-based authentication specified in the section 21.1 of RFC3315. 1748 However, with the deployment of this mechanism, there may be no need 1749 to enforce IPSec to perform DHCP Leasequery. 1751 By containing the DHCP servers in the protection perimeter, the DHCP 1752 servers can be protected from spoofing based attacks. Then by 1753 checking the source IP address of Leasequery messages, the DHCP 1754 server can identify if the messages are from SAVI devices or not. 1755 For the SAVI devices, because the perimeter filters out bogus DHCP 1756 messages, they can trust the DHCP Leasequery responses. Thus, there 1757 is no need to enforce IPSec to validate the DHCP Leasequery messages 1758 in this mechanism. 1760 11.6. Binding Number Limitation 1762 A binding entry will consume a certain high-speed memory resources. 1763 In general, a SAVI device can afford only a quite limited number of 1764 binding entries. In order to prevent an attacker from overloading 1765 the resource of the SAVI device, a binding entry limit is set on each 1766 attachment. The binding entry limit is the maximum number of 1767 bindings supported on each attachment with Validating attribute. No 1768 new binding should be set up after the limit has been reached. If a 1769 DHCP Reply assigns more addresses than the remaining binding entry 1770 quota of each client, the message will be discarded and no binding 1771 will be set up. 1773 11.7. Residual Threats 1775 As described in [RFC7039], this solution cannot strictly prevent 1776 spoofing. There are two scenarios in which spoofing can still 1777 happen: 1779 (1) The binding anchor is spoofable. If the binding anchor is 1780 spoofable, e.g., plain MAC address, an attacker can use forged 1781 binding anchor to send packet which will not be regarded as 1782 spoofing by SAVI device. Indeed, using binding anchor that can 1783 be easily spoofed is more serious than allowing IP spoofing 1784 traffic. For example, an attacker can use the binding anchor of 1785 another client to get a large number of addresses, and the SAVI 1786 device will refuse to set up new binding for the client whenever 1787 the binding number limitation has been reached. Thus, it is 1788 RECOMMENDED to use strong enough binding anchor, e.g., switch 1789 port, secure association in 802.11ae/af and 802.11i. 1791 (2) The binding anchor is shared by more than one clients. If the 1792 binding anchor is shared by more than one clients, the clients 1793 can spoof each other addresses. For example, if a switch port 1794 is used as binding anchor, a number of clients can attach to the 1795 same switch port of a SAVI device through a hub. The SAVI 1796 device cannot distinguish packets from different clients and 1797 thus the spoofing between them will not be detected. A number 1798 of the above security problems are caused by sharing binding 1799 anchors. If binding anchor is shared, TID spoofing based attack 1800 is possible. Thus, it is RECOMMENDED to use exclusive binding 1801 anchor. 1803 12. IANA Considerations 1805 This memo asks the IANA for no new parameters. 1807 Note to RFC Editor: This section will have served its purpose if it 1808 correctly tells IANA that no new assignments or registries are 1809 required, or if those assignments or registries are created during 1810 the RFC publication process. From the authors' perspective, it may 1811 therefore be removed upon publication as an RFC at the RFC Editor's 1812 discretion. 1814 13. Acknowledgment 1816 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 1817 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 1818 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 1819 Garcia for careful review and valuation comments on the mechanism and 1820 text. 1822 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 1823 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 1824 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 1825 their valuable contributions. 1827 This document was generated using the xml2rfc tool. 1829 14. References 1831 14.1. Informative References 1833 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 1834 Internet draft (work in progress), November 2007. 1836 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 1837 Defeating Denial of Service Attacks which employ IP Source 1838 Address Spoofing", RFC 2827, BCP 38, May 2000. 1840 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1841 (DHCP) Service for IPv6", RFC 3736, April 2004. 1843 14.2. Normative References 1845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1846 Requirement Levels", RFC 2119, BCP 14, Match 1997. 1848 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1849 RFC 2131, March 1997. 1851 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1852 and M. Carney, "Dynamic Host Configuration Protocol for 1853 IPv6 (DHCPv6)", RFC 3315, July 2003. 1855 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1856 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1858 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1859 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1861 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1862 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1863 September 2007. 1865 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1866 "DHCPv6 Leasequery", RFC 5007, September 2007. 1868 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1869 July 2008. 1871 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1872 Detecting Network Attachment in IPv6", RFC 6059, 1873 November 2010. 1875 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1876 SAVI: First-Come First-Serve Source-Address Validation for 1877 Locally Assigned Addresses", RFC 6620, May 2012. 1879 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1880 "Source Address Validation Improvement Framework", 1881 RFC 7039, October 2013. 1883 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1884 converting network protocol addresses to 48.bit Ethernet 1885 address for transmission on Ethernet hardware", RFC 826, 1886 November 1982. 1888 Authors' Addresses 1890 Jun Bi 1891 Tsinghua University 1892 Network Research Center, Tsinghua University 1893 Beijing 100084 1894 China 1896 Email: junbi@tsinghua.edu.cn 1898 Jianping Wu 1899 Tsinghua University 1900 Computer Science, Tsinghua University 1901 Beijing 100084 1902 China 1904 Email: jianping@cernet.edu.cn 1906 Guang Yao 1907 Tsinghua University 1908 Network Research Center, Tsinghua University 1909 Beijing 100084 1910 China 1912 Email: yaoguang@cernet.edu.cn 1914 Fred Baker 1915 Cisco Systems 1916 Santa Barbara, CA 93117 1917 United States 1919 Email: fred@cisco.com