idnits 2.17.1 draft-ietf-savi-dhcp-28.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 (July 5, 2014) is 3555 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) ** Downref: Normative reference to an Informational RFC: RFC 7039 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-opsec-dhcpv6-shield-03 -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 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: January 6, 2015 Tsinghua Univ. 6 F. Baker 7 Cisco 8 July 5, 2014 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-28 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 is used to filter out packets with forged source IP 19 address in DHCP scenario. This mechanism is proposed as a complement 20 to ingress filtering to provide finer-grained source IP address 21 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 January 6, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Deployment Scenario and Configuration . . . . . . . . . . . . 7 73 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 7 74 4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10 76 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10 77 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11 78 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11 79 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11 80 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12 81 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13 83 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13 84 4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 14 85 4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15 86 4.3.5. Considerations on Binding Anchor . . . . . . . . . . 16 87 4.4. Address Configuration . . . . . . . . . . . . . . . . . . 17 88 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17 89 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18 90 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18 91 6.2. Binding States Description . . . . . . . . . . . . . . . 19 92 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19 94 6.3.2. Control Message Arriving Events . . . . . . . . . . . 19 95 6.4. The State Machine of DHCP Snooping Process . . . . . . . 21 96 6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 21 97 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . 22 98 6.4.3. From BOUND to Other States . . . . . . . . . . . . . 24 99 6.5. Table of State Machine . . . . . . . . . . . . . . . . . 26 100 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 27 101 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 27 102 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 28 103 7.3. Additional Binding States Description . . . . . . . . . . 28 104 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 7.5. State Machine of Binding Recovery Process . . . . . . . . 30 106 7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 30 107 7.5.2. From DETECTION to Other States . . . . . . . . . . . 31 108 7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 32 109 7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 33 110 7.6. Table of State Machine . . . . . . . . . . . . . . . . . 34 111 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 35 112 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 36 113 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 36 114 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 37 115 9.1. Attribute Configuration Restoration . . . . . . . . . . . 37 116 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 37 117 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 38 118 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 119 11.1. Security Problems about the Data Snooping Process . . . 38 120 11.2. Issues about Leaving Clients . . . . . . . . . . . . . . 38 121 11.3. Duplicate Bindings to the Same Address . . . . . . . . . 39 122 11.4. Compatibility with DNA (Detecting Network Attachment) . 40 123 11.5. Authentication in DHCPv6 Leasequery . . . . . . . . . . 41 124 11.6. Binding Number Limitation . . . . . . . . . . . . . . . 41 125 11.7. Privacy Considerations . . . . . . . . . . . . . . . . . 41 126 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 127 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 42 128 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 129 14.1. Normative References . . . . . . . . . . . . . . . . . . 42 130 14.2. Informative References . . . . . . . . . . . . . . . . . 43 132 1. Introduction 134 This document describes a fine-grained source IP address validation 135 mechanism. This mechanism creates bindings between IP addresses 136 assigned to network attachment points by DHCP and suitable binding 137 anchors (refer to Section 3) of the attachments. Then the bindings 138 are used to identify and filter out packets originated from these 139 attachments with forged source IP addresses. In this way, this 140 mechanism can prevent hosts from spoofing IP addresses assigned to 141 the other attachment points. Compared with [RFC2827], which provides 142 prefix granularity source IP address validity, this mechanism can 143 benefit the network with finer-grained validity and traceability of 144 source IP addresses. 146 This mechanism primarily performs DHCP snooping to set up bindings 147 between IP addresses assigned by DHCP and corresponding binding 148 anchors. This binding process is inspired by the work of [BA2007]. 149 Different from [BA2007], which designs specifications about DHCPv4, 150 this mechanism covers the DHCPv6 snooping process, the Data Snooping 151 process (refer to Section 7), as well as a number of other technical 152 details. Specially, the Data Snooping process is a data-triggered 153 procedure which snoops the header of data packet to set up bindings. 154 It is designed to avoid permanent block of valid address in case that 155 DHCP snooping is insufficient to set up all the valid bindings. 157 This mechanism is designed for the stateful DHCP scenario [RFC2131], 158 [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this 159 document, because it has nothing to do with IP address allocation. A 160 client doing stateless DHCP acquires its IP address(es) using some 161 other mechanism. The appropriate SAVI method must be based on this 162 mechanism. For example, for hosts using Stateless Auto-configuration 163 address, SAVI-FCFS [RFC6620] should be enabled. Besides, this 164 mechanism is primarily designed for pure DHCP scenarios in which only 165 addresses assigned through DHCP are allowed. However, it does not 166 block any link-local address. It is because link-local addresses are 167 used by DHCPv6 clients before the clients are assigned a DHCPv6 168 address. Considering that link-local addresses are generally self- 169 generated, and the spoofing of link local address may disturb this 170 mechanism, it is RECOMMENDED to enable a SAVI solution for link-local 171 addresses, e.g., the SAVI-FCFS [RFC6620]. 173 This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and 174 DHCPv6. However, the DHCP address assignment mechanims in IPv4/IPv6 175 transition scenarios, e.g., [I-D.ietf-dhc-dhcpv4-over-dhcpv6], are 176 beyond the scope of this document. 178 2. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 3. Terminology 186 Binding anchor: A "binding anchor" is defined to be a link layer 187 property of network attachment in [RFC7039]. A list of proper 188 binding anchors can be found in Section 3.2 of [RFC7039]. 190 Attribute: A configurable property of each network attachment which 191 indicates the actions to be performed on packets received from the 192 network attachment. 194 DHCP address: An IP address assigned via DHCP. 196 SAVI-DHCP: The name of this SAVI function for DHCP address. 198 SAVI device: A network device on which this SAVI function is enabled. 200 Non-SAVI device: A network device on which this SAVI function is not 201 enabled. 203 DHCP Client-Server message: A message that is sent from a DHCP client 204 to a DHCP server or DHCP servers. Such a message is of one of the 205 following types: 207 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 209 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 210 [RFC2131] 212 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 213 [RFC2131] 215 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 216 [RFC2131] 218 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 219 [RFC2131] 221 o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be 222 identified based on the Table 4 of [RFC2131] 224 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 226 o DHCPv4 Release: DHCPRELEASE [RFC2131] 228 o DHCPv4 Inform: DHCPINFORM [RFC2131] 230 o DHCPv6 Request: REQUEST [RFC3315] 232 o DHCPv6 Solicit: SOLICIT [RFC3315] 234 o DHCPv6 Confirm: CONFIRM [RFC3315] 236 o DHCPv6 Decline: DECLINE [RFC3315] 238 o DHCPv6 Release: RELEASE [RFC3315] 240 o DHCPv6 Rebind: REBIND [RFC3315] 241 o DHCPv6 Renew: RENEW [RFC3315] 243 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 245 DHCP Server-Client message: A message that is sent from a DHCP server 246 to a DHCP client. Such a message is of one of the following types: 248 o DHCPv4 ACK: DHCPACK [RFC2131] 250 o DHCPv4 NAK: DHCPNAK [RFC2131] 252 o DHCPv4 Offer: DHCPOFFER [RFC2131] 254 o DHCPv6 Reply: REPLY [RFC3315] 256 o DHCPv6 Advertise: ADVERTISE [RFC3315] 258 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 260 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 261 IPv6 [RFC3315]. 263 Binding entry: An 'permit' rule that defines a valid association 264 between an IP address and a binding anchor. 266 Binding State Table (BST): The data structure that contains all the 267 binding entries. 269 Binding entry limit: The maximum number of binding entries that may 270 be associated with any binding anchor. Limiting the number of 271 binding entries per binding anchor prevents a malicious or 272 malfunctioning node from overloading the binding table on a SAVI 273 device. 275 Direct attachment: Ideally, a SAVI device should be an access device 276 which is directly attached by hosts. In such case, the hosts are 277 direct attachments of the SAVI device. 279 Indirect attachment: A SAVI device can be an aggregation device which 280 is connected with a number of access devices, which are attached by 281 hosts. In such case, the hosts are indirect attachments of the SAVI 282 device. Sometimes, it is expressed as "the hosts are indirectly 283 attached to the SAVI device". 285 Upstream link: Upstream links are links connected to non-SAVI devices 286 from which the valid source address space of traffic contains the 287 prefixes of other networks. 289 Upstream device: An upstream device is a non-SAVI device associated 290 with an upstream link. For example, the gateway router of the 291 network. 293 Downstream link: Downstream links are links connected to non-SAVI 294 devices from which the valid source address space of traffic only 295 contains the prefix(es) of the local network. 297 Downstream device: A downstream device is a non-SAVI device 298 associated with an downstream link. For example, an access switch in 299 the network. 301 CUT VERTEX: A cut vertex is 'any vertex whose removal increases the 302 number of connected components'. This is a concept in graph theory. 303 This term is used in Section 6.1 to accurately specify the required 304 deployment location of SAVI devices when they only perform the DHCP 305 snooping process. 307 Identity Association (IA): "A collection of addresses assigned to a 308 client." [RFC3315] 310 Detection message: a Neighbor Solicitation or ARP message intended to 311 detect a duplicate address by the Data Snooping Process. 313 DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the 314 binding is triggered by a DHCPv6 Confirm message but a DHCPv6 315 leasequery exchange [RFC5007] cannot be performed by the SAVI device 316 to fetch the lease. 318 4. Deployment Scenario and Configuration 320 4.1. Elements and Scenario 322 A list of essential elements in a SAVI-DHCP deployment scenario is 323 given as follows: 325 (1) DHCP server 327 (2) DHCP client 329 (3) SAVI device 331 And there may be following optional elements in a SAVI-DHCP 332 deployment scenario: 334 (1) DHCP relay 336 (2) Non-SAVI device 337 Figure 1 shows a deployment scenario that contains these elements. 338 Note that a physical device can be multiple elements, e.g, a switch 339 can be both a SAVI device and a DHCP relay. In such cases, the links 340 are logic links rather than physical links. The "Bogus DHCP Server" 341 is only used to help illustrate the case in Section 4.3.3, but not a 342 necessary element. 344 +--------+ +------------+ +----------+ 345 |DHCP |-----| Non-SAVI |----|Bogus DHCP| 346 |Server A| | Device 1 | |Server | 347 +--------+ +-----|------+ +----------+ 348 ......................|............................ 349 . | upstream link . 350 . Protection +---|------+ . 351 . Perimeter | SAVI |--------------+ . 352 . | Device C| | . 353 . +---|------+ | . 354 . | | . 355 . +----------+ +---|------+ +------|---+ . 356 downstream . | SAVI | | Non SAVI| | SAVI | . 357 link +----.-| Device A|----| Device 3|-------| Device B| . 358 | . +----|--|--+ +----------+ +-|---|----+ . 359 | . | +----------+ ............ | | . 360 | '.............. | . . | | . 361 | | . | . +--------+ | . 362 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 363 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 364 | Device 2 | |A | . |Relay | . |B | . |Server B| . 365 +----------+ +------+ . +------+ . +------+ . +--------+ . 366 ............ ............... 368 Figure 1: SAVI-DHCP Scenario 370 Networks are not isolated and traffic from other networks, i.e., 371 transit traffic specified in [RFC6620], may get into the network with 372 SAVI-DHCP deployed through the upstream links. Since SAVI solutions 373 are limited to check traffic generated from local link, SAVI-DHCP is 374 not to set up bindings for addresses assigned in other networks. 375 Thus, SAVI-DHCP will not set up bindings for addresses appearing on 376 upstream links and will not check data traffic from upstream links. 377 This is why to distinguish upstream/downstream links is essential for 378 SAVI-DHCP. The traffic from upstream links should be checked by a 379 prefix granularity source address validation mechanism to avoid 380 spoofing of local addresses from other networks. How to generate and 381 deploy such a mechanism is beyond the scope of this document. 383 However, traffic from downstream links are generated from local 384 network. For example, a hub, which is attached by some DHCP clients, 385 is on the downstream link of a SAVI device. The traffic from 386 downstream links should be checked by SAVI-DHCP if possible. 387 However, because DHCP clients on the downstream links are indirectly 388 attached, the security problem caused by shared binding anchor, as 389 described in Section 4.3.5, can be introduced. 391 4.2. Attribute 393 As illustrated in Figure 1, an attachment to a SAVI device can be 394 from either a DHCP client, or a DHCP relay/server, or a SAVI device, 395 or a non-SAVI device. Different actions are performed on traffic 396 originated from different elements. To distinguish different types 397 of attachments, an attachment property named 'attribute' is 398 configured on SAVI devices. This section specifies the attributes 399 used by SAVI-DHCP. 401 Before configuration, an attachment is with no attribute. An 402 attachment MAY be configured to have one or more compatible 403 attributes (refer to Section 4.2.6). The attributes of each 404 attachment MUST be configured before the SAVI-DHCP function is 405 enabled. The procedure performed by SAVI devices on traffic from 406 each attachment is determined by the attribute(s) set on the 407 attachment. 409 Particularly, if an attachment has no attribute, data traffic from 410 this attachment will not be checked by SAVI-DHCP and will be 411 forwarded directly. This prevents SAVI-DHCP from causing a break in 412 the network when it is turned on without any binding anchors 413 configured. However, if a binding anchor has no attribute, this 414 means that the SAVI-DHCP-Trust attribute is not present. Because of 415 this, DHCP server-client messages associated to this binding anchor 416 will be discarded. This prevents a host from connecting to an 417 unconfigured binding anchor and acting as a DHCP server. It is 418 SUGGESTED to configure SAVI-DHCP-Trust on necessary binding anchors 419 before turning on the SAVI-DHCP function. 421 Binding anchors associated with upstream links MAY have no attribute 422 after configuration. For example, in Figure 1, the attachment from 423 the Non-SAVI Device 1 to the SAVI Device C should be configured with 424 no attribute. It means 1) SAVI devices will neither set up bindings 425 for upstream hosts nor check traffic from upstream hosts; 2) SAVI 426 devices will drop DHCP server-client messages from upstream devices 427 unless the DHCP-Trust attribute (refer to Section 4.2.2) is set on 428 the corresponding attachment. The reason that DHCP messages from 429 upstream devices are not trusted is discussed in Section 4.3.3. 431 4.2.1. Trust Attribute 433 The "Trust Attribute" indicates the packets from the corresponding 434 attachment are completely trustable. 436 SAVI devices will not set up bindings for attachments with Trust 437 attribute; DHCP messages and data packets from such attachments with 438 this attribute will not be checked. If the DHCP Server-Client 439 messages from attachments with this attribute can trigger the state 440 transitions specified in Section 6 and Section 7, these messages will 441 be handled by the corresponding processes in Section 6 and Section 7. 443 This attribute is generally configured on the attachments from other 444 SAVI devices. For example, in Figure 1, the attachment from the SAVI 445 Device B to the SAVI Device C and the attachment from the SAVI Device 446 C to the SAVI Device B should be configured with this attribute. 447 Besides, it can be configured on attachments from Non-SAVI devices 448 only if the Non-SAVI devices will not introduce unchecked traffic 449 from DHCP clients. For example, the attachments from Non-SAVI device 450 3 to SAVI device A, SAVI device B and SAVI device C can be configured 451 with this attribute, only if Non-SAVI device 3 does not have 452 attachment from DHCP clients. 454 4.2.2. DHCP-Trust Attribute 456 The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages 457 from the corresponding attachment is trustable. 459 SAVI devices will forward DHCP Server-Client messages coming from the 460 attachments with this attribute. If the DHCP Server-Client messages 461 can trigger the state transitions, they will be handled by the 462 binding setup processes specified in Section 6 and Section 7. 464 This attribute is generally used on the direct attachments from the 465 trusted DHCP servers/relays. In Figure 1, the attachment from the 466 DHCP Relay to the SAVI Device A, and the attachment from the DHCP 467 Server B to the SAVI Device B should be configured with this 468 attribute. It is NOT RECOMMENDED to configure this attribute on any 469 indirect attachment point of the non-neighboring DHCP servers and 470 relays, unless all the elements that can be reached through that 471 attachment point can be trusted, i.e., bogus DHCP Server-Client 472 messages will not be generated by these elements. For example, in 473 Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI 474 Device C should not be configured with this attribute. This issue is 475 discussed in Section 4.3.3. 477 The implementation for DHCPv6 can refer to 478 [I-D.ietf-opsec-dhcpv6-shield] for more details. 480 4.2.3. DHCP-Snooping Attribute 482 The "DHCP-Snooping Attribute" indicates bindings will be set up based 483 on DHCP snooping. 485 DHCP Client-Server messages from attachments with this attribute will 486 trigger the setup of bindings. SAVI devices will set up bindings on 487 attachments with this attribute based on the DHCP snooping procedure 488 described in Section 6. 490 DHCP-Snooping attribute is configured on the attachments from DHCP 491 clients. This attribute can be also used on the attachments from 492 downstream Non-SAVI devices which are attached by DHCP clients. In 493 Figure 1, the attachment from the Client A to the SAVI Device A, the 494 attachment from the Client B to the SAVI Device B, and the attachment 495 from the Non-SAVI Device 2 to the SAVI Device A can be configured 496 with this attribute. 498 Whenever this attribute is set on an attachment, the "Validating 499 Attribute" MUST be set on the same attachment. 501 4.2.4. Data-Snooping Attribute 503 The "Data-Snooping Attribute" indicates data packets from the 504 corresponding attachment may trigger binding setup procedure. 506 Data packets from attachments with this attribute may trigger the 507 setup of bindings. SAVI devices will set up bindings on attachments 508 with this attribute based on the data-triggered process described in 509 Section 7. 511 If DHCP-Snooping attribute is configured on an attachment, the 512 bindings on this attachment are set up based on DHCP message 513 snooping. However, in some scenarios, a DHCP address may be used by 514 a DHCP client without DHCP address assignment procedure performed on 515 its current attachment. For such attachments, the Data-Snooping 516 process, which is described in Section 7, is necessary. This 517 attribute is configured on such attachments. The usage of this 518 attribute is further discussed in Section 7. 520 Whenever this attribute is set on an attachment, the "Validating 521 Attribute" MUST be set on the same attachment. 523 4.2.5. Validating Attribute 525 The "Validating Attribute" indicates packets from the corresponding 526 attachment will be checked based on binding entries on the 527 attachment. 529 Packets coming from attachments with this attribute will be checked 530 based on binding entries on the attachment as specified in Section 8. 532 Validating attribute is configured on the attachments from which the 533 data packets should be checked. For example, the DHCP clients. 535 This attribute MUST be used together with "DHCP-Snooping Attribute" 536 or "Data-Snooping Attribute". 538 4.2.6. Table of Mutual Exclusions 540 Different types of attributes may indicate mutually exclusive actions 541 on packet. Mutually exclusive attributes MUST NOT be set on the same 542 attachment. The compatibility of different attributes is listed in 543 Figure 2. Note that although Trust and DHCP-Trust are compatible, 544 there is no need to configure DHCP-Trust on an attachment with Trust 545 attribute. 547 +----------+----------+----------+----------+----------+----------+ 548 | | | | DHCP- | Data- | | 549 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 550 +----------+----------+----------+----------+----------+----------+ 551 | | | | mutually | mutually | mutually | 552 | Trust | - |compatible| exclusive| exclusive| exclusive| 553 +----------+----------+----------+----------+----------+----------+ 554 | | | | | | | 555 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 556 +----------+----------+----------+----------+----------+----------+ 557 |DHCP- |mutually | | | | | 558 |Snooping |exclusive |compatible| - |compatible|compatible| 559 +----------+----------+----------+----------+----------+----------+ 560 |Data- |mutually | | | | | 561 |Snooping |exclusive |compatible|compatible| - |compatible| 562 +----------+----------+----------+----------+----------+----------+ 563 | |mutually | | | | | 564 |Validating|exclusive |compatible|compatible|compatible| - | 565 +----------+----------+----------+----------+----------+----------+ 567 Figure 2: Table of Mutual Exclusions 569 4.3. Perimeter 571 4.3.1. SAVI-DHCP Perimeter Overview 573 SAVI devices can form a perimeter separating untrusted and trusted 574 areas, similarly to SAVI-FCFS (refer to Section 2.5 of [RFC6620]). 575 Each SAVI device need only establish bindings for a client if it is 576 connected to that client by a link that crosses the perimeter that 577 encloses the SAVI device. 579 The perimeter is primarily designed for scalability. This has two 580 implications. First, SAVI devices only need to establish bindings 581 for directly attached clients, or clients indirectly attached through 582 non-SAVI device, rather than all the clients in the network. Second, 583 each SAVI device only need to check traffic from clients attached to 584 it, without checking all the traffic passing by. 586 Consider the example in Figure 1. The protection perimeter is formed 587 by SAVI Device A, B and C. In this case, SAVI device B doesn't 588 create a binding for client A. However, because SAVI device A 589 filters spoofing traffic from client A, SAVI device B can avoid 590 receiving spoofing traffic from client A. 592 The perimeter in SAVI-DHCP is not only a perimeter for data packets, 593 but also a perimeter for DHCP messages. The placement of DHCP Relay/ 594 Server, which is not involved in [RFC6620] , is related with the 595 construction of the perimeter. The requirement on the placement and 596 configuration of DHCP Relay/Server are discussed in Section 4.3.3. 598 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 600 Through configuring attribute of each attachment properly, a 601 perimeter separating untrusted area and trusted area MUST be formed 602 as follows: 604 (1) Configure Validating and DHCP-Snooping attribute on the direct 605 attachments of all the DHCP clients. 607 (2) Configure Validating and DHCP-Snooping attribute on the indirect 608 attachments of all the DHCP clients (i.e., DHCP clients on the 609 downstream links). 611 (3) Configure Trust attribute on the attachments of other SAVI 612 devices. 614 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 615 have only attachments from SAVI devices, set their attachments to 616 SAVI devices with Trust attribute. 618 (5) Configure DHCP-Trust attribute on the direct attachments of 619 trusted DHCP relays/servers. 621 In this way, the points of attachments with Validating attribute (and 622 generally together with attachments of upstream devices) on SAVI 623 devices can form a perimeter separating DHCP clients and trusted 624 devices. Data packet check is only performed on the perimeter. The 625 perimeter is also a perimeter for DHCP messages. DHCP-Trust 626 attribute is only configured on the inside links of the perimeter. 627 Only DHCP server-client messages originated in the perimeter are 628 trusted. 630 4.3.3. On the Placement of DHCP Server/Relay 632 Based on the configuration guideline, it can be found that the SAVI 633 devices only trust DHCP Server-Client messages originated inside the 634 perimeter. It means the trusted DHCP relays/servers must be placed 635 in the perimeter. DHCP server-client messages will be filtered on 636 the perimeter (Note: server-relay messages will not be filtered). In 637 this way, DHCP server-client messages from bogus DHCP servers are 638 filtered on the perimeter, and then the SAVI devices can be protected 639 from forged DHCP messages. 641 Such a requirement is due to the limitation of this binding based 642 mechanism. This document makes no assumption that the DHCP server- 643 client messages arriving the perimeter from the outside can be 644 trusted. The binding anchor of a trusted remote DHCP server can be 645 shared by a bogus DHCP server. Thus, the SAVI device cannot 646 distinguish bogus and valid DHCP messages only based on the 647 associated binding anchor of DHCP messages in such case. 649 Note that even if a DHCP server is valid, it may be not contained in 650 the perimeter based on the guideline. For example, in Figure 1, DHCP 651 server A is valid, but it is attached to the Non-SAVI device 1. The 652 Non-SAVI device 1 is attached by a bogus DHCP server. This binding 653 based mechanism may not have the ability to distinguish whether a 654 message received from the port of the Non-SAVI device 1 is from DHCP 655 server A or the bogus DHCP server. If the DHCP server A is contained 656 in the perimeter, the Non-SAVI device 1 will also be contained in the 657 perimeter. However, the Non-SAVI device 1 can introduce forged DHCP 658 messages into the perimeter. Thus, the DHCP server A cannot be 659 contained in the perimeter. 661 In this case, the SAVI devices can set up bindings for addresses 662 assigned by DHCP server A through snooping the messages relayed by 663 trusted relay in the network. For example, the DHCP relay may relay 664 messages between DHCP server A and the clients in the network, and 665 the SAVI devices can snoop the last hop messages from the DHCP relay, 666 which is inside the perimeter. The authentication mechanism (i.e., 667 IPsec, as specified in section 21.1 of [RFC3315]) enforced between 668 the DHCP relay and the DHCP server outside the perimeter can 669 compensate this binding based mechanism. It is SUGGESTED to 670 configure IPsec between the DHCP relay and the DHCP server in such 671 case. If source address validation is enforced in the whole network, 672 which makes the source IP address trustable, the DHCP relay and the 673 DHCP server can simply authenticate the messages from each other 674 based on the source IP address. Nevertheless, it should be noted 675 that the integrity of the messages is not ensured. 677 Another consideration on the placement is that if the DHCP server/ 678 relay is not inside the perimeter, the SAVI devices may not be able 679 to set up bindings correctly, because the SAVI devices may not be on 680 the path between the clients and the server/relay, or the DHCP 681 messages are encapsulated (e.g., Relay-reply and Relay-forward). 683 4.3.4. An Alternative Deployment 685 In a number of deployment practices, the traffic from the upstream 686 network are all treated as trustable. In such a case, Trust 687 attribute can be set on the upstream link; and if a Non-SAVI device, 688 or a number of connected Non-SAVI devices, have only attachments from 689 SAVI devices and upstream devices, their attachment to SAVI devices 690 can be set Trust attribute. Then an unclosed perimeter will be 691 formed, as illustrate in Figure 3. 693 | . . Protection | 694 | | | Perimeter | 695 | | | | 696 | Upstream | | Upstream | 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 To configure such a perimeter, at least the DHCP messages from 716 upstream networks MUST be ensured to be trustable. How to achieve 717 this is beyond the scope of this document. 719 4.3.5. Considerations on Binding Anchor 721 The strength of this binding based mechanism depends on the strength 722 of the binding anchor. If the binding anchor is spoofable, e.g., 723 plain MAC address, an attacker can use forged binding anchor to send 724 packet which will not be regarded as spoofing by SAVI device. 725 Indeed, using binding anchor that can be easily spoofed can lead to 726 worse outcomes than allowing IP spoofing traffic. For example, an 727 attacker can use the binding anchor of another client to bind a large 728 number of addresses, and the SAVI device will refuse to set up new 729 binding for the client whenever the binding number limitation has 730 been reached; as a result, even the legitimate clients cannot access 731 the network. Thus, it is RECOMMENDED to use unspoofable binding 732 anchor, e.g., switch port. By default,t his document assumes the 733 binding anchor is switch port. The implications of using other forms 734 of binding anchors should be properly analyzed. 736 If the binding anchor is shared by more than one clients, the clients 737 can spoof each other addresses. For example, if a switch port is 738 used as binding anchor, a number of clients can attach to the same 739 switch port of a SAVI device through a hub. The SAVI device cannot 740 distinguish packets from different clients and thus the spoofing 741 between them will not be detected. A number of the above security 742 problems are caused by sharing binding anchors. For example, an 743 attacker can send a DHCP Release message to remove the binding of a 744 client sharing the same binding anchor. Thus, it is RECOMMENDED to 745 use exclusive binding anchor. 747 4.4. Address Configuration 749 If the implementation of this SAVI mechanism does not support the 750 DHCP Leasequery process specified in Section 6.4.1.2 and the Data 751 Snooping Process, it actually requires no address configuration. To 752 support the full features of this mechanism, an implementation has 753 the following address configuration requirements: 755 (1) For DHCPv4: the SAVI device needs an IPv4 address. 757 (2) For DHCPv6: the SAVI device needs a local address; when the 758 DHCPv6 server is not on the same link as the SAVI device, the 759 SAVI device needs also a global IPv6 address. 761 5. Binding State Table (BST) 763 Binding State Table is used to contain the bindings between the IP 764 addresses assigned to the attachments and the corresponding binding 765 anchors of the attachments. Each entry of the table, i.e., binding 766 entry, has 5 fields: 768 o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer 769 property of the attachment. 771 o IP Address(Address): the IP address assigned to the attachment by 772 DHCP. 774 o State: the state of the binding. Possible values of this field 775 are listed in Section 6.2 and Section 7.3. 777 o Lifetime: the remaining seconds of the binding. The Lifetime 778 field counts down automatically. 780 o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of 781 the corresponding DHCP transaction. TID field is used to 782 associate DHCP Server-Client messages with corresponding binding 783 entries. 785 IA does not present in the BST because the lease of each address in 786 one IA is assigned respectively. Another reason is, when the binding 787 is set up based on data-snooping, IA cannot be recovered from the 788 leasequery protocol. Last reason is there is no IA for DHCPv4. 790 An instance of this table is shown in Figure 4. 792 +---------+----------+----------+-----------+-------+ 793 | Anchor | Address | State | Lifetime |TID | 794 +---------+----------+----------+-----------+-------+ 795 | Port_1 | IP_1 | BOUND | 65535 |TID_1 | 796 +---------+----------+----------+-----------+-------+ 797 | Port_1 | IP_2 | BOUND | 10000 |TID_2 | 798 +---------+----------+----------+-----------+-------+ 799 | Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | 800 +---------+----------+----------+-----------+-------+ 802 Figure 4: Instance of BST 804 6. DHCP Snooping Process 806 This section specifies the process of setting up bindings based on 807 DHCP snooping, named DHCP Snooping Process. This process is 808 illustrated making use of a state machine. 810 6.1. Rationale 812 The rationale of the DHCP Snooping Process is that if a DHCP client 813 is legitimate to use a DHCP address, the DHCP address assignment 814 procedure which assigns the IP address to the client must have been 815 performed on the attachment of the client. This basis stands when 816 the SAVI device is always on the path(s) from the DHCP client to the 817 DHCP server(s)/relay(s). Without considering the movement of DHCP 818 clients, the SAVI device should be the CUT VERTEX whose removal will 819 disjoin the DHCP client and the remaining network containing the DHCP 820 server(s)/relay(s). For most of the networks whose topologies are 821 simple, it is possible to deploy this SAVI function at proper devices 822 to meet this requirement. 824 However, a deployment of this SAVI function may not meet the 825 requirement. For example, there are multiple paths from a DHCP 826 client to the DHCP server and the SAVI device is only on one of them. 827 Then the SAVI device may not be able to snoop the DHCP procedure. 828 Host movement may also make this requirement can not be met. For 829 example, when a DHCP client moves from one attachment to another 830 attachment in the same network, it may not reinitialize its interface 831 or send a Confirm message because of incomplete protocol 832 implementation. Thus, there can be scenarios in which only 833 performing this DHCP snooping process is insufficient to set up 834 bindings for all the valid DHCP addresses. These exceptions and the 835 solutions are discussed in Section 7. 837 6.2. Binding States Description 839 Following binding states present in this process and the 840 corresponding state machine: 842 NO_BIND: The state before a binding has been set up. 844 INIT_BIND: A potential binding has been set up. 846 BOUND: The binding has been set up. 848 6.3. Events 850 This section describes events in this process and the corresponding 851 state machine. 853 6.3.1. Timer Expiration Event 855 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 857 6.3.2. Control Message Arriving Events 859 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 860 received. 862 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 864 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 866 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 867 received. 869 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 871 EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit 872 option is received. 874 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 876 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 877 received. 879 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 880 received. 882 EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 883 section 4.3.3 of [RFC5007]) is received. 885 Note: the events listed here do not cover all the DHCP messages in 886 section 3. The messages which do not really determine address usage 887 (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, 888 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 889 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer 890 to section 6.4.2.1), are not included. 892 Moreover, only if a DHCP message can pass the following checks, the 893 corresponding event is regarded as a valid event: 895 o Attribute check: the DHCP Server-Client messages and 896 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 897 attribute; the DHCP Client-Server messages should be from 898 attachments with DHCP-Snooping attribute. 900 o Destination check: the DHCP Server-Client messages should be 901 destined to attachments with DHCP-Snooping attribute. This check 902 is performed to ensure the binding is set up on the SAVI device 903 which is nearest to the destination client. 905 o Binding anchor check: the DHCP Client-Server messages which may 906 trigger modification or removal of an existing binding entry must 907 have matched binding anchor with the corresponding entry. 909 o TID check: the DHCP Server-Client/Client-Server messages which may 910 cause modification on existing binding entries must have matched 911 TID with the corresponding entry. Note that this check is not 912 performed on Leasequery and Leasequery-reply messages as they are 913 exchanged between the SAVI devices and the DHCP servers. Besides, 914 this check is not performed on DHCP Renew/Rebind messages 915 (Section 6.4.3). 917 o Binding limitation check: the DHCP messages must not cause new 918 binding setup on an attachment whose binding entry limitation has 919 been reached. (refer to Section 11.6). 921 o Address check: the source address of the DHCP messages should pass 922 the check specified in Section 8.2. 924 On receiving a DHCP message without triggering a valid event, the 925 state will not transit and actions will not be performed. Note that 926 if a message does not trigger a valid event but it can pass the 927 checks in Section 8.2, it MUST be forwarded. 929 6.4. The State Machine of DHCP Snooping Process 931 This section specifies the transits of each state and the 932 corresponding actions. 934 6.4.1. From NO_BIND to INIT_BIND 936 6.4.1.1. Trigger Events 938 Trigger events: EVE_DHCP_REQUEST, EVE_DHCP_SOLICIT_RC, 939 EVE_DHCP_CONFIRM, EVE_DHCP_REBOOT. 941 6.4.1.2. Following Actions 943 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_SOLICIT_RC/ 944 EVE_DHCP_REBOOT: 946 The SAVI device MUST forward the message. 948 The SAVI device will generate an entry in the BST. The Binding 949 anchor field is set to the binding anchor of the attachment from 950 which the message is received. The State field is set to INIT_BIND. 951 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 952 field is set to the TID of the message. If the message is DHCPv4 953 Request or DHCPv4 Reboot, the Address field can be set to the address 954 to request, i.e., the 'requested IP address'. An example of the 955 entry is illustrated in Figure 5. 957 +---------+-------+---------+-----------------------+-------+ 958 | Anchor |Address| State | Lifetime |TID | 959 +---------+-------+---------+-----------------------+-------+ 960 | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 961 +---------+-------+---------+-----------------------+-------+ 963 Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot 964 triggered initialization 966 If the triggering event is EVE_DHCP_CONFIRM: 968 The SAVI device MUST forward the message. 970 The SAVI device will generate corresponding entries in the BST for 971 all the addresses in each the IA option of the Confirm message. The 972 Binding anchor field is set to the binding anchor of the attachment 973 from which the message is received. The State field is set to 974 INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. 976 The TID field is set to the TID of the message. The Address field is 977 set to the address(es) to confirm. An example of the entries is 978 illustrated in Figure 6. 980 +---------+--------+---------+-----------------------+-------+ 981 | Anchor | Address| State | Lifetime |TID | 982 +---------+--------+---------+-----------------------+-------+ 983 | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 984 +---------+--------+---------+-----------------------+-------+ 985 | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 986 +---------+--------+---------+-----------------------+-------+ 988 Figure 6: Binding entry in BST on Confirm triggered initialization 990 6.4.2. From INIT_BIND to Other States 992 6.4.2.1. Trigger Events 994 Trigger events: EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE. 996 Note: If no DHCP Server-Client messages which assign addresses or 997 confirm addresses are received, corresponding entries will expire 998 automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4 999 NAK) are not specially processed. 1001 6.4.2.2. Following Actions 1003 If the trigger event is EVE_DHCP_REPLY: 1005 The message MUST be forwarded to the corresponding client. 1007 If the message is DHCPv4 ACK, the Address field of the corresponding 1008 entry (i.e., the binding entry whose TID is the same of the message) 1009 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 1010 The Lifetime field is set to the sum of the lease time in ACK message 1011 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 1013 If the message is DHCPv6 Reply, there are following cases: 1015 1. If the status code is not "Success", no modification on 1016 corresponding entries will be made. Corresponding entries will 1017 expire automatically if no "Success" Reply is received during the 1018 lifetime. The entries are not removed immediately due to the client 1019 may be able to use the addresses whenever a "Success" Reply is 1020 received ("If the client receives any Reply messages that do not 1021 indicate a NotOnLink status, the client can use the addresses in the 1022 IA and ignore any messages that indicate a NotOnLink status." 1023 [RFC3315]). 1025 2. If the status code is "Success", the SAVI device checks the IA 1026 options in the Reply message. 1028 2.1 If there are no IA options in the Reply message, the DHCP Reply 1029 message is in response to a Confirm message. The state of the 1030 binding entries with matched TID is changed to BOUND. Because 1031 [RFC3315] does not require lease time of addresses to be contained in 1032 the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] 1033 message querying by IP address to All_DHCP_Servers multicast address 1034 [RFC3315] or a list of configured DHCP server addresses. The 1035 Leasequery message is generated for each IP address if multiple 1036 addresses are confirmed. The Lifetime of corresponding entries is 1037 set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after 1038 MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example 1039 of the entries is illustrated in Figure 7. The related security 1040 problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the 1041 SAVI device does not send the LEASEQUERY message, a pre-configured 1042 lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. 1043 (Note: it is SUGGESUTED to use T1 configured on DHCP servers as the 1044 DHCP_DEFAULT_LEASE.) 1046 2.2 If there are IA options in the Reply message, the SAVI device 1047 checks each IA option. When the first assigned address is found, the 1048 Address field of the binding entry with matched TID is set to the 1049 address. The Lifetime field is set to the sum of the lease time in 1050 Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed 1051 to BOUND. If there are more than one address assigned in the 1052 message, new binding entries are set up for the remaining address 1053 assigned in the IA options. An example of the entries is illustrated 1054 in Figure 8. SAVI devices do not specially process IA options with 1055 NoAddrsAvail status, because there should be no address contained in 1056 such IA options. 1058 Note: the SAVI devices do not check if the assigned addresses are 1059 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 1060 only source of valid addresses. However, the DHCP servers should be 1061 configured to make sure no duplicated addresses are assigned. 1063 +---------+----------+-------+------------------------+-------+ 1064 | Anchor | Address | State | Lifetime |TID | 1065 +---------+----------+-------+------------------------+-------+ 1066 | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1067 +---------+----------+-------+------------------------+-------+ 1068 | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | 1069 +---------+----------+-------+------------------------+-------+ 1071 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 1072 Confirm 1074 +---------+----------+-------+------------------------+-------+ 1075 | Anchor | Address | State | Lifetime |TID | 1076 +---------+----------+-------+------------------------+-------+ 1077 | Port_1 | Addr1 | BOUND |Lease time+ |TID | 1078 | | | |MAX_DHCP_RESPONSE_TIME | | 1079 +---------+----------+-------+------------------------+-------+ 1080 | Port_1 | Addr2 | BOUND |Lease time+ |TID | 1081 | | | |MAX_DHCP_RESPONSE_TIME | | 1082 +---------+----------+-------+------------------------+-------+ 1084 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 1085 Request 1087 If the trigger event is EVE_ENTRY_EXPIRE: 1089 The entry MUST be deleted from BST. 1091 6.4.3. From BOUND to Other States 1093 6.4.3.1. Trigger Events 1095 Trigger events: EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 1096 EVE_DHCP_REPLY, EVE_DHCP_LEASEQUERY, EVE_DHCP_RENEW, EVE_DHCP_REBIND. 1098 6.4.3.2. Following Actions 1100 If the trigger event is EVE_ENTRY_EXPIRE: 1102 Remove the corresponding entry in BST. 1104 If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE: 1106 The message MUST be forwarded. 1108 The SAVI device first gets all the addresses ("Requested IP address" 1109 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 1110 IA options of DHCPv6 Decline/Release) to decline/release in the 1111 message. Then the corresponding entries MUST be removed. 1113 If the trigger event is EVE_DHCP_RENEW/EVE_DHCP_REBIND: 1115 The message MUST be forwarded. 1117 In such case, a new TID will be used by the client. The TID field of 1118 the corresponding entries MUST be set to the new TID. Note that TID 1119 check will not be performed on such messages. 1121 If the trigger event is EVE_DHCP_REPLY: 1123 The message MUST be forwarded. 1125 The DHCP Reply messages received in current states should be in 1126 response to DHCP Renew/Rebind. 1128 If the message is DHCPv4 ACK, the SAVI device just simply update the 1129 binding entry with matched TID, with the Lifetime field set to be the 1130 sum of the new lease time and MAX_DHCP_RESPONSE_TIME. 1132 If the message is DHCPv6 Reply, the SAVI device checks each IA 1133 Address option in each IA option. If the valid lifetime of an IA 1134 address option is 0, the binding entry with matched TID and address 1135 is removed. Or else, set the Lifetime field of the binding entry 1136 with matched TID and address to be the sum of the new valid lifetime 1137 and MAX_DHCP_RESPONSE_TIME. 1139 The SAVI device does not specially process IA options in Reply 1140 message with status NoBinding, because no address is contained in 1141 such IA options and no actions will be performed. 1143 If the trigger event is EVE_DHCP_LEASEQUERY: 1145 The message MUST be forwarded. 1147 The message should be in response to the Leasequery message sent in 1148 Section 6.4.2. The related binding entry can be determined based on 1149 the address in the IA Address option in the Leasequery-reply message. 1150 The Lifetime field of the corresponding binding entry is set to the 1151 sum of the lease time in the LEASEQUERY_REPLY message and 1152 MAX_DHCP_RESPONSE_TIME. 1154 6.5. Table of State Machine 1156 The main state transits are listed as follows. Note that not all the 1157 details are specified in the table and the diagram. 1159 State Event Action Next State 1160 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1161 INIT_BIND RPL Record lease time BOUND 1162 (send lease query if no lease) 1163 INIT_BIND Timeout Remove entry NO_BIND 1164 BOUND RLS/DCL Remove entry NO_BIND 1165 BOUND Timeout Remove entry NO_BIND 1166 BOUND RPL Set new lifetime BOUND 1167 BOUND LQR Record lease time BOUND 1169 Figure 9: Table of Transit 1171 RQ: EVE_DHCP_REQUEST 1173 CF: EVE_DHCP_CONFIRM 1175 RC: EVE_DHCP_SOLICIT_RC 1177 RE: EVE_DHCP_REBOOT 1179 RPL: EVE_DHCP_REPLY 1181 DCL: EVE_DHCP_DECLINE 1183 RLS: EVE_DHCP_RELEASE 1185 LQR: EVE_DHCP_LEASEQUERY 1187 Timeout: EVE_ENTRY_EXPIRE 1188 +-------------+ 1189 | | 1190 /---------| NO_BIND |<----------\ 1191 | ------>| | | 1192 | | +-------------+ |EVE_DHCP_RELEASE 1193 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1194 EVE_DHCP_CONFIRM | |TIMEOUT |TIMEOUT 1195 EVE_DHCP_SOLICIT_RC| | | 1196 EVE_DHCP_REBOOT | | | 1197 | | | 1198 | | | 1199 v | | 1200 +-------------+ +------------+ 1201 | | EVE_DHCP_REPLY | | 1202 | INIT_BIND ------------------------>| BOUND |<-\ 1203 | | | | | 1204 +-------------+ +------------+ | 1205 | | 1206 \--------/ 1207 EVE_DHCP_REPLY 1208 EVE_DHCP_LEASEQUERY 1210 Figure 10: Diagram of Transit 1212 7. Data Snooping Process 1214 7.1. Scenario 1216 The rationale of the DHCP Snooping Process specified in Section 6 is 1217 that if a DHCP client's use of a DHCP address is legitimate, the 1218 corresponding DHCP address assignment procedure must have been 1219 finished on the attachment of the DHCP client. This is the case 1220 stands when the SAVI device is persistently on the path(s) from the 1221 DHCP client to the DHCP server(s)/relay(s). However, there are two 1222 case when this does not work: 1224 o Multiple paths: there is more than one feasible layer-2 paths from 1225 the client to the DHCP server/relay, and the SAVI device is not on 1226 everyone of them. The client may get its address through one of 1227 the paths not passing by the SAVI device, but packets from the 1228 client can travel through paths that pass through the SAVI device. 1229 Because the SAVI device could not snoop the DHCP packet exchange 1230 procedure, the DHCP snooping procedure cannot set up the 1231 corresponding binding. 1233 o Dynamic path: there is only one feasible layer-2 path from the 1234 client to the DHCP server/relay, but the path is dynamic due to 1235 topology change (for example, some link turns broken due to 1236 failure or as planned) or layer-2 path change. This situation 1237 also covers the local-link movement of clients without address 1238 confirm/re-configuration process. For example, a host changes its 1239 attached switch port in a very short time. In such cases, the 1240 DHCP snooping process will not set up the corresponding binding. 1242 Data Snooping Process prevents permanently blocking legitimate 1243 traffic in case of these two exceptions. This process is performed 1244 on attachments with the Data-Snooping attribute. Data packets 1245 without matching binding entry may trigger this process to set up 1246 bindings. 1248 Snooping data traffic introduces considerable burden on the processor 1249 and ASIC-to-Processor bandwidth of SAVI devices. Because of the 1250 overhead of this process, the implementation of this process is a 1251 conditional SHOULD. This function SHOULD be enabled unless the 1252 implementation is known to be used in the scenarios without the above 1253 exceptions. For example, if the implementation is to be used in 1254 networks with tree topology and without host local-link movement, 1255 there is no need to implement this process in such scenarios. 1257 This process is not intended to set up a binding whenever a data 1258 packet without matched binding entry is received. Instead, unmatched 1259 data packets trigger this process probabilistically and generally a 1260 number of unmatched packets will be discarded before the binding is 1261 set up. 1263 7.2. Rationale 1265 This process makes use of NS/ARP and DHCP Leasequery to set up 1266 bindings. If an address is not used by another client in the 1267 network, and the address has been assigned in the network, the 1268 address can be bound with the binding anchor of the attachment from 1269 which the unmatched packet is received. 1271 The security issues about this process is discussed is Section 11.1. 1273 7.3. Additional Binding States Description 1275 In addition to Section 6.2, new states used in this process are 1276 listed here: 1278 DETECTION: The address in the entry is under local duplication 1279 detection. 1281 RECOVERY: The SAVI device is querying the assignment and lease time 1282 of the address in the entry through DHCP Leasequery. 1284 7.4. Events 1286 Additional events in this process are described here. Also, if an 1287 event will trigger the creation of a new binding entry, the binding 1288 entry limit on the binding anchor MUST NOT be exceeded. 1290 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1292 EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message 1293 against an address in DETECTION state is received from a host other 1294 than the one for which the entry was added. 1296 EVE_DATA_LEASEQUERY: 1298 IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1299 is received. 1301 IPv6: A successful LEASEQUERY-REPLY is received. 1303 The triggering packet should pass the following checks to trigger a 1304 valid event: 1306 o Attribute check: the data packet should be from attachments with 1307 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1308 messages should be from attachments with DHCP-Snooping attribute. 1310 o Binding limitation check: the DHCP messages must not cause new 1311 binding setup on an attachment whose binding entry limitation has 1312 been reached. (refer to Section 11.6). 1314 o Address check: For EVE_DATA_LEASEQUERY, the source address of the 1315 DHCP Leasequery messages must pass the check specified in 1316 Section 8.2. For EVE_DATA_CONFLICT, the source address and target 1317 address of the ARP or NA messages must pass the check specified in 1318 Section 8.2. 1320 o Interval check: the interval between two successive 1321 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1322 smaller than DATA_SNOOPING_INTERVAL. 1324 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have 1325 matched TID with the corresponding entry. 1327 o Prefix check: the source address of the data packet should be of a 1328 valid local prefix, as specified in section 7 of [RFC7039]. 1330 7.5. State Machine of Binding Recovery Process 1332 Through using additional states, the state machine of this process 1333 doesn't conflict the regular process described in Section 6. Thus, 1334 it can be implemented separately without changing the state machine 1335 in Section 6. 1337 7.5.1. From NO_BIND to DETECTION 1339 7.5.1.1. Trigger Event 1341 Trigger event: EVE_DATA_UNMATCH. 1343 7.5.1.2. Following Actions 1345 Make a probabilistic determination whether to act on this event. The 1346 probability can be configured or calculated based on the state of the 1347 SAVI device. This probability should be low enough to mitigate the 1348 damage from DoS attack against this process. 1350 Create a new entry in the BST. Set the Binding Anchor field to the 1351 corresponding binding anchor of the attachment. Set the Address 1352 field to be source address of the packet. Set the State field to 1353 DETECTION. Set the Lifetime of the created entry to 1354 2*DETECTION_TIMEOUT. 1356 Check if the address has a local conflict (it violates an address 1357 being used by another node): 1359 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1360 [RFC0826]or a ARP probe [RFC5227] on the address; if there is no 1361 response message after DETECTION_TIMEOUT, send another ARP 1362 Request or ARP probe; 1364 (2) IPv6 address: send a Neighbor Solicitation message [RFC4861] 1365 targeting on the address; if there is no response message after 1366 DETECTION_TIMEOUT, send another Neighbor Solicitation message. 1368 Because the delivery of detection message is unreliable, the 1369 detection message may fail to reach the targeting node. If there is 1370 a node that has the IP address seen in the Data Snooping Process, it 1371 may not get the detection messages. This failure mode enables an 1372 attack against the Data Snooping Process. Thus, the detection is 1373 performed again if there is no response after the first detection. 1375 The messages MUST NOT be sent to the attachment from which the 1376 triggering packet is received. 1378 The packet which triggers this event SHOULD be discarded. 1380 This local conflict process SHOULD be performed. If it is not 1381 performed, the state of the entry is set to RECOVERY, the lifetime is 1382 set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified 1383 in the following section will be performed directly. 1385 An example of the entry is illustrated in Figure 11. 1387 +---------+-------+---------+-----------------------+-------+ 1388 | Anchor |Address| State | Lifetime |TID | 1389 +---------+-------+---------+-----------------------+-------+ 1390 | Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | 1391 +---------+-------+---------+-----------------------+-------+ 1393 Figure 11: Binding entry in BST on data triggered initialization 1395 7.5.2. From DETECTION to Other States 1397 7.5.2.1. Trigger Event 1399 Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT. 1401 7.5.2.2. Following Actions 1403 If the trigger event is EVE_ENTRY_EXPIRE: 1405 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1406 by IP address to each DHCPv4 server with IP Address Lease Time 1407 option (option 51). A list of authorized DHCP servers are kept 1408 by the SAVI device. The list should be pre-configured or 1409 discovered by sending DHCPv4 Discover messages and parsing the 1410 replied DHCPv4 Offer messages. Change the state of the 1411 corresponding entry to RECOVERY. Change the lifetime of the 1412 entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the 1413 TID used in the DHCPLEASEQUERY message. If there is no response 1414 message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to each 1415 DHCPv4 server again. 1417 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1418 address to All_DHCP_Relay_Agents_and_Servers multicast address or 1419 a list of pre-configured DHCPv6 server addresses. Change the 1420 state of the corresponding entry to RECOVERY. Change the 1421 lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID 1422 field is set to the TID used in the LEASEQUERY message. If there 1423 is no response message after MAX_LEASEQUERY_DELAY, send the 1424 LEASEQUERY message again. 1426 An example of the entry is illustrated in Figure 12. 1428 +---------+-------+---------+-----------------------+-------+ 1429 | Anchor |Address| State | Lifetime |TID | 1430 +---------+-------+---------+-----------------------+-------+ 1431 | Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | 1432 +---------+-------+---------+-----------------------+-------+ 1434 Figure 12: Binding entry in BST on Lease Query 1436 If the trigger event is EVE_DATA_CONFLICT: 1438 Remove the entry. 1440 7.5.3. From RECOVERY to Other States 1442 7.5.3.1. Trigger Event 1444 Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY. 1446 7.5.3.2. Following Actions 1448 If the trigger event is EVE_DATA_LEASEQUERY: 1450 IPv4 address: 1452 (1) Send an ARP Request with the Target Protocol Address set to the 1453 IP address in the corresponding entry. The ARP Request is only 1454 sent to the attachment which triggers the binding. If there is 1455 no response after DETECTION_TIMEOUT, send another ARP Request. 1456 If there is still no response, the following actions will not be 1457 performed. If there is only one identical response, get the 1458 sender hardware address. Check if the 'chaddr' field (hardware 1459 address) of the DHCPLEASEACTIVE message matches the sender 1460 hardware address. If the two addresses do not match, the 1461 following actions will not be performed. If there is more than 1462 one response, if any of the sender hardware addresses matches the 1463 'chaddr' field (hardware address) of the DHCPLEASEACTIVE message, 1464 the following actions are to be performed. 1466 (2) Change the state of the corresponding binding to BOUND. Set 1467 life time to the sum of the value encoded in IP Address Lease 1468 Time option of the DHCPLEASEACTIVE message and 1469 MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1471 IPv6 address: 1473 (1) Send a Neighbor Solicitation message with the target address set 1474 to the IP address in the corresponding entry. The Neighbor 1475 Solicitation is only sent to the attachment which triggers the 1476 binding. If there is no response after DETECTION_TIMEOUT, send 1477 another Neighbor Solicitation. If there is still no response, 1478 the following actions will not be performed. 1480 (2) Change the state of the corresponding binding to BOUND. Set the 1481 lifetime to the sum of the valid lifetime extracted from 1482 OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and 1483 MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1485 (3) After the above checks, if multiple addresses are specified in 1486 the LEASEQUERY-REPLY message and there are no corresponding 1487 binding entries, new entries MUST also be created correspondingly 1488 on the same binding anchor. 1490 If responses are received from multiple DHCP servers, the conflict 1491 resolution mechanisms specified in section 6.8 of [RFC4388] and 1492 section 4.3.4 of [RFC5007] will be used to determine which message 1493 should be used. 1495 If the trigger event is EVE_ENTRY_EXPIRE: 1497 Remove the entry. 1499 7.5.4. After BOUND 1501 Note that the TID field contains no value after the binding state 1502 changes to BOUND. The TID field is recovered from snooping DHCP 1503 Renew/Rebind messages. Because TID is used to associate binding 1504 entries with messages from DHCP servers, it must be recovered; or 1505 else a number of state transits of this mechanism will be not 1506 executed normally. 1508 7.5.4.1. Trigger Event 1510 Trigger events: EVE_DHCP_RENEW, EVE_DHCP_REBIND. 1512 7.5.4.2. Following Action 1514 Set the TID field of the corresponding entry to the TID in the 1515 triggering message. 1517 7.6. Table of State Machine 1519 The main state transits are listed as follows. 1521 State Event Action Next State 1522 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1523 DETECTION Timeout Send Leasequery RECOVERY 1524 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1525 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND 1526 RECOVERY Timeout Remove entry NO_BIND 1527 BOUND RENEW/REBIND Record TID BOUND 1529 Figure 13: Table of Transit 1531 RENEW: EVE_DHCP_RENEW 1533 REBIND: EVE_DHCP_REBIND 1535 Timeout: EVE_ENTRY_EXPIRE 1536 +-------------+ 1537 | | 1538 /---------| NO_BIND |<--------\ 1539 | ------>| | | TIMEOUT 1540 | | +-------------+ |(2nd LQ_DELAY) 1541 EVE_DATA_UNMATCH | | | 1542 | | | 1543 1st | | | 1544 DETECTION_TIMEOUT | | | 1st LQ_DELAY 1545 /------\ | | | /---------\ 1546 | | | | EVE_DATA_CONFLICT | | | 1547 | v v | | v | 1548 | +-------------+ TIMEOUT +------------+ | 1549 | | |(2nd DETECTION_TIMEOUT) | | | 1550 \----| DETECTION ------------------------>| RECOVERY ----/ 1551 | | | | 1552 +-------------+ +------------+ 1553 EVE_DATA_LEASEQUERY| 1554 /----------\ (+ 2x DETECTION) | 1555 EVE_DHCP_RENEW| | | 1556 EVE_DHCP_REBIND| +-----v-------+ | 1557 | | | | 1558 \----| BOUND |<----------/ 1559 | | 1560 +-------------+ 1562 Figure 14: Diagram of Transit 1564 LQ_DELAY: MAX_LEASEQUERY_DELAY 1566 8. Filtering Specification 1568 This section specifies how to use bindings to filter out spoofing 1569 packets. 1571 Filtering policies are different for data packets and control 1572 packets. DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] 1573 messages that may cause state transit are classified as control 1574 packet. Neighbor Advertisement (NA) and ARP Reply are also included 1575 in control packet because the Target Address of NA and ARP Reply 1576 should be checked to prevent spoofing. All other packets are 1577 classified as data packets. 1579 8.1. Data Packet Filtering 1581 Data packets from attachments with the Validating attribute MUST be 1582 checked. 1584 Packet whose source IP address is a link-local address will not be 1585 checked. Note: as explained in Section 1, a SAVI solution for link- 1586 local addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to 1587 check packets with link-local source address. 1589 If the source IP address of a packet is not a link-local address, but 1590 there is not a matched entry in BST with state BOUND, this packet 1591 MUST be discarded. However, the packet may trigger Data Snooping 1592 Process Section 7 if Data-Snooping attribute is set on the 1593 attachment. 1595 Data packets from attachments with no attribute will forwarded 1596 without checking. 1598 The SAVI device MAY record any violation. 1600 8.2. Control Packet Filtering 1602 For attachments with the Validating attribute: 1604 DHCPv4 Client-Server messages where source IP address is neither all 1605 zeros nor bound with the corresponding binding anchor in the BST MUST 1606 be discarded. 1608 DHCPv6 Client-Server messages where source IP address is neither a 1609 link-local address nor bound with the corresponding binding anchor in 1610 the BST MUST be discarded. 1612 NDP messages where source IP address is neither a link-local address 1613 nor bound with the corresponding binding anchor MUST be discarded. 1615 NA messages where target address is neither a link-local address nor 1616 bound with the corresponding binding anchor MUST be discarded. 1618 ARP messages where protocol is IP and sender protocol address is 1619 neither all zeros address nor bound with the corresponding binding 1620 anchor MUST be discarded. 1622 ARP Reply messages where target protocol address is not bound with 1623 the corresponding binding anchor MUST be discarded. 1625 For attachments with other attributes: 1627 DHCP Server-Client messages not from attachments with the DHCP-Trust 1628 attribute or Trust attribute MUST be discarded. 1630 For attachments with no attribute: 1632 DHCP Server-Client messages from such attachments MUST be discarded. 1634 The SAVI device MAY record any violation. 1636 9. State Restoration 1638 If a SAVI device reboots, the information kept in volatile memory 1639 will be lost. This section specifies the restoration of attribute 1640 configuration and BST. 1642 9.1. Attribute Configuration Restoration 1644 The loss of attribute configuration will not break the network: no 1645 action will be performed on traffic from attachments with no 1646 attribute. However, the loss of attribute configuration makes this 1647 SAVI function unable to work. 1649 To avoid the loss of binding anchor attribute configuration, the 1650 configuration MUST be able to be stored in non-volatile storage. 1651 After the reboot of SAVI device, if the configuration of binding 1652 anchor attribute can be found in non-volatile storage, the 1653 configuration MUST be used. 1655 9.2. Binding State Restoration 1657 The loss of binding state will cause the SAVI devices discard 1658 legitimate traffic. Purely using the Data Snooping Process to 1659 recover a large number of bindings is of heavy overhead and 1660 considerable delay. Thus, to recover bindings from non-volatile 1661 storage, as specified below, is RECOMMENDED. 1663 Binding entries MAY be saved into non-volatile storage whenever a new 1664 binding entry changes to BOUND state. If a binding with BOUND state 1665 is removed, the saved entry MUST be removed correspondingly. The 1666 time when each binding entry is established is also saved. 1668 Immediately after reboot, the SAVI device SHOULD restore binding 1669 states from the non-volatile storage. The system time of save 1670 process MUST be stored. After rebooting, the SAVI device MUST check 1671 whether each entry has been obsolete by comparing the saved lifetime 1672 and the difference between the current time and time when the binding 1673 entry is established. 1675 10. Constants 1677 MAX_DHCP_RESPONSE_TIME 120s 1679 DATA_SNOOPING_INTERVAL 60s and configurable 1681 MAX_LEASEQUERY_DELAY 10s 1683 OFFLINK_DELAY 30s 1685 DETECTION_TIMEOUT 0.5s 1687 11. Security Considerations 1689 11.1. Security Problems about the Data Snooping Process 1691 There are two security problems about the Data Snooping Process 1692 Section 7: 1694 (1) The Data Snooping Process is costly, but an attacker can trigger 1695 it simply through sending a number of data packets. To avoid 1696 Denial of Services attack against the SAVI device itself, the 1697 Data Snooping Process MUST be rate limited. A constant 1698 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1699 Data Snooping Processes on one attachment MUST have a minimum 1700 interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be 1701 configured prudently to avoid Denial of Service attacks. 1703 (2) The Data Snooping Process may set up wrong bindings if the 1704 clients do not reply to the detection probes. An attack will 1705 pass the duplicate detection if the client assigned the target 1706 address does not reply to the detection probes. The DHCP 1707 Leasequery procedure performed by the SAVI device just tells 1708 whether the address is assigned in the network or not. However, 1709 the SAVI device cannot determine whether the address is just 1710 assigned to the triggering attachment from the DHCP Leasequery 1711 Reply. 1713 11.2. Issues about Leaving Clients 1715 After a binding is set up, the corresponding client may leave its 1716 attachment point. It may leave temporarily due to link flapping, or 1717 permanently by moving to a new attachment point or leaving the 1718 network. Since the client may return shortly, the binding should be 1719 kept, or legitimate traffic from the client will be blocked. 1720 However, if the client leaves permanently, it may be insecure to keep 1721 the binding. If the binding anchor is a property of the attachment 1722 point rather than the client, e.g., the switch port, an attacker 1723 which is attached to the attachment point of the leaving client can 1724 send spoofing packets with the addresses assigned to the client. 1725 Even if the binding anchor is a property of the client, it is a waste 1726 of binding resources to keep bindings for departed clients. 1728 SAVI-DHCP handles the leaving of directly attached clients. Whenever 1729 a direct client leaves, a link-down event associated with the binding 1730 anchor will be triggered. SAVI-DHCP monitors such events, and 1731 perform the following mechanism. 1733 (1) Whenever a client with the Validating attribute leaves, a timer 1734 of duration OFFLINK_DELAY is set on the corresponding binding 1735 entries. 1737 (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is 1738 received that targets the address during OFFLINK_DELAY, the entry 1739 MAY be removed. 1741 (3) If the client returns on-link during OFFLINK_DELAY, cancel the 1742 timer. 1744 In this way, the bindings of a departing client are kept for 1745 OFFLINK_DELAY. In case of link flapping, the client will not be 1746 blocked. If the client leaves permanently, the bindings will be 1747 removed after OFFLINK_DELAY. 1749 SAVI-DHCP does not handle the leaving of indirect clients, because it 1750 will not be notified of such events. Then the threats illustrated at 1751 the beginning of this section will be introduced. If SAVI-DHCP is 1752 enabled on indirect DHCP clients, this problem should be well 1753 understood. 1755 11.3. Duplicate Bindings to the Same Address 1757 The same address may be bound to multiple binding anchors only if the 1758 binding setup processes successfully complete for each binding 1759 anchor. This mechanism is designed to address the case where a 1760 client moves on the local link, and the case where a client has 1761 multiple attachments to a SAVI device. 1763 There are two security issues with such a design: 1765 First, by allowing one address to be bound to multiple binding 1766 anchors, the traceability of the address is weakened. An address can 1767 be traced to multiple attachments. 1769 Second, in the local link movement scenario, the former binding may 1770 not be removed and it can be used by an attacker sharing the same 1771 binding anchor. For example, when a switch port is used as binding 1772 anchor and the port is shared by an attacker and a client with a hub, 1773 the attacker can make use of the address assigned to the client after 1774 the client leaves. 1776 11.4. Compatibility with DNA (Detecting Network Attachment) 1778 DNA [RFC4436] [RFC6059] is designed to decrease the handover latency 1779 after re-attachment to the same network. DNA mainly relies on 1780 performing reachability test by sending unicast Neighbor 1781 Solicitation/Router Solicitation/ARP Request message to determine 1782 whether a previously configured address is still valid. 1784 Although DNA provides optimization for clients, there is insufficient 1785 information for this mechanism to migrate the previous binding or 1786 establish a new binding. If a binding is set up only by snooping the 1787 reachability test message, the binding may be invalid. For example, 1788 an attacker can perform reachability test with an address bound to 1789 another client. If binding is migrated to the attacker, the attacker 1790 can successfully obtain the binding from the victim. Because this 1791 mechanism wouldn't set up a binding based on snooping the DNA 1792 procedure, it cannot achieve perfect compatibility with DNA. 1793 However, it only means the re-configuration of the interface is 1794 slowed but not prevented. Details are discussed as follows. 1796 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1797 set to a link-local address, and such messages will not be discarded 1798 by the policy specified in Section 8.2. If a client is re-attached 1799 to a previous network, the detection will be completed, and the 1800 address will be regarded as valid by the client. However, the 1801 candidate address is not contained in the probe. Thus, the binding 1802 cannot be recovered through snooping the probe. As the client will 1803 perform DHCP exchange at the same time, the binding will be recovered 1804 from the DHCP Snooping Process. The DHCP Request messages will not 1805 be filtered out in this case because they have link-local source 1806 addresses. Before the DHCP procedure is completed, packets will be 1807 filtered out by the SAVI device. In other words, if this SAVI 1808 function is enabled, Simple DNAv6 will not help reduce the handover 1809 latency. If Data-Snooping attribute is configured on the new 1810 attachment of the client, the data triggered procedure may reduce 1811 latency. 1813 In DNAv4 [RFC4436], the ARP probe will be discarded because an 1814 unbound address is used as the sender protocol address. As a result, 1815 the client will regard the address under detection is valid. 1816 However, the data traffic will be filtered. The DHCP Request message 1817 sent by the client will not be discarded, because the source IP 1818 address field should be all zero as required by [RFC2131]. Thus, if 1819 the address is still valid, the binding will be recovered from the 1820 DHCP Snooping Process. 1822 11.5. Authentication in DHCPv6 Leasequery 1824 As required in section 5 of [RFC5007], DHCPv6 Leasequery 'Should' use 1825 IPsec-based authentication specified in the section 21.1 of 1826 [RFC3315]. However, IPsec is generally considered heavyweight. With 1827 the deployment of this mechanism, the source IP address may be 1828 authenticated without enforcing IPsec. 1830 By containing the DHCP servers in the protection perimeter, the DHCP 1831 servers can be protected from spoofing based attacks. Then by 1832 maintaining a list of SAVI device addresses, the DHCP server can 1833 identify if the Leasequery messages are from SAVI devices or not. 1834 For the SAVI devices, because the perimeter filters out bogus DHCP 1835 messages, they can trust the DHCP Leasequery replies. 1837 Again, it should be noted that although SAVI-DHCP can help 1838 authenticate the origin, it does not protect the integrity of the 1839 messages. If DHCPv6 Leasequery is performed without enforcing IPsec, 1840 this threat must be taken into account. 1842 11.6. Binding Number Limitation 1844 A binding entry will consume a certain high-speed memory resources. 1845 In general, a SAVI device can afford only a quite limited number of 1846 binding entries. In order to prevent an attacker from overloading 1847 the resource of the SAVI device, a binding entry limit is set on each 1848 attachment. The binding entry limit is the maximum number of 1849 bindings supported on each attachment with Validating attribute. No 1850 new binding should be set up after the limit has been reached. If a 1851 DHCP Reply assigns more addresses than the remaining binding entry 1852 quota of each client, the message will be discarded and no binding 1853 will be set up. 1855 11.7. Privacy Considerations 1857 A SAVI device MUST delete binding anchor information as soon as 1858 possible (i.e., as soon as the state for a given address is back to 1859 NO_BIND), except where there is an identified reason why that 1860 information is likely to be involved in the detection, prevention, or 1861 tracing of actual source address spoofing. Information about the 1862 majority of hosts that never spoof SHOULD NOT be logged. 1864 12. IANA Considerations 1866 This memo asks the IANA for no new parameters. 1868 Note to RFC Editor: This section will have served its purpose if it 1869 correctly tells IANA that no new assignments or registries are 1870 required, or if those assignments or registries are created during 1871 the RFC publication process. From the authors' perspective, it may 1872 therefore be removed upon publication as an RFC at the RFC Editor's 1873 discretion. 1875 13. Acknowledgment 1877 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 1878 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 1879 Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto 1880 Garcia for careful review and valuation comments on the mechanism and 1881 text. 1883 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 1884 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 1885 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 1886 their valuable contributions. 1888 This document was generated using the xml2rfc tool. 1890 14. References 1892 14.1. Normative References 1894 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1895 Requirement Levels", BCP 14, RFC 2119, March 1997. 1897 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1898 "Source Address Validation Improvement (SAVI) Framework", 1899 RFC 7039, October 2013. 1901 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1902 and M. Carney, "Dynamic Host Configuration Protocol for 1903 IPv6 (DHCPv6)", RFC 3315, July 2003. 1905 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1906 2131, March 1997. 1908 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1909 SAVI: First-Come, First-Served Source Address Validation 1910 Improvement for Locally Assigned IPv6 Addresses", RFC 1911 6620, May 2012. 1913 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1914 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1915 September 2007. 1917 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1918 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1920 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1921 Detecting Network Attachment in IPv6", RFC 6059, November 1922 2010. 1924 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1925 converting network protocol addresses to 48.bit Ethernet 1926 address for transmission on Ethernet hardware", STD 37, 1927 RFC 826, November 1982. 1929 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1930 July 2008. 1932 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1933 "DHCPv6 Leasequery", RFC 5007, September 2007. 1935 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1936 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1938 [I-D.ietf-opsec-dhcpv6-shield] 1939 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 1940 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 1941 opsec-dhcpv6-shield-03 (work in progress), June 2014. 1943 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 1944 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 1945 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 1946 dhcpv4-over-dhcpv6-09 (work in progress), June 2014. 1948 14.2. Informative References 1950 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1951 (DHCP) Service for IPv6", RFC 3736, April 2004. 1953 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1954 Defeating Denial of Service Attacks which employ IP Source 1955 Address Spoofing", BCP 38, RFC 2827, May 2000. 1957 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 1958 Internet draft (work in progress), November 2007. 1960 Authors' Addresses 1962 Jun Bi 1963 Tsinghua University 1964 Network Research Center, Tsinghua University 1965 Beijing 100084 1966 China 1968 EMail: junbi@tsinghua.edu.cn 1970 Jianping Wu 1971 Tsinghua University 1972 Computer Science, Tsinghua University 1973 Beijing 100084 1974 China 1976 EMail: jianping@cernet.edu.cn 1978 Guang Yao 1979 Tsinghua University 1980 Network Research Center, Tsinghua University 1981 Beijing 100084 1982 China 1984 EMail: yaoguang@cernet.edu.cn 1986 Fred Baker 1987 Cisco Systems 1988 Santa Barbara, CA 93117 1989 United States 1991 EMail: fred@cisco.com