idnits 2.17.1 draft-ietf-savi-dhcp-16.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 6, 2013) is 4001 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: November 7, 2013 Tsinghua Univ. 6 F. Baker 7 Cisco 8 May 6, 2013 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-16 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 November 7, 2013. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . 7 73 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 7 74 4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 9 76 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . . 10 77 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 10 78 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 10 79 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . . 11 80 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . . 11 81 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 12 82 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 13 83 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 14 84 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.2. Binding States Description . . . . . . . . . . . . . . . . 15 86 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . . 15 88 6.3.2. Control Message Arriving Events . . . . . . . . . . . 15 89 6.4. State Machine of DHCP Packet Snooping . . . . . . . . . . 17 90 6.4.1. From NO_BIND to Other States . . . . . . . . . . . . . 17 91 6.4.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 17 92 6.4.1.2. Following Actions . . . . . . . . . . . . . . . . 18 93 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 20 94 6.4.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 20 95 6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 20 96 6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 22 97 6.4.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 22 98 6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 22 99 6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 22 100 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 24 101 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 25 103 7.3. Additional Binding States Description . . . . . . . . . . 25 104 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 7.5. State Machine of Binding Recovery Process . . . . . . . . 26 106 7.5.1. From NO_BIND to Other States . . . . . . . . . . . . . 27 107 7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 27 108 7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 27 109 7.5.2. From DETECTION to Other States . . . . . . . . . . . . 28 110 7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 28 111 7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 28 112 7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 29 113 7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 29 114 7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 29 116 7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 29 117 7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 30 118 7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 30 119 7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 30 120 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 31 121 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 31 122 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 32 123 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 32 124 9.1. Attribute Configuration Restoration . . . . . . . . . . . 33 125 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 33 126 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 33 127 11. MLD Consideration . . . . . . . . . . . . . . . . . . . . . . 34 128 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 129 12.1. Security Problem about Binding Setup Triggered by 130 EVE_DHCP_REPLY_NULL . . . . . . . . . . . . . . . . . . . 34 131 12.2. Security Problems about the Data Snooping Process . . . . 35 132 12.3. Issues about Leaving Clients . . . . . . . . . . . . . . . 35 133 12.4. Duplicate Bindings of the Same Address . . . . . . . . . . 36 134 12.5. Compatibility with DNA (Detecting Network Attachment) . . 36 135 12.6. Bogus DHCP Server Threat . . . . . . . . . . . . . . . . . 37 136 12.7. Authentication in DHCPv6 Leasequery . . . . . . . . . . . 38 137 12.8. Binding Number Limitation . . . . . . . . . . . . . . . . 38 138 12.9. Residual Threats . . . . . . . . . . . . . . . . . . . . . 38 139 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 140 14. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 39 141 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 142 15.1. Informative References . . . . . . . . . . . . . . . . . . 40 143 15.2. Normative References . . . . . . . . . . . . . . . . . . . 40 144 Appendix A. change log . . . . . . . . . . . . . . . . . . . . . 41 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 147 1. Introduction 149 This document describes a fine-grained source IP address validation 150 mechanism. This mechanism creates bindings between addresses 151 assigned to network attachment points by DHCP and suitable binding 152 anchors (refer to Section 3) of the attachments. Then the bindings 153 are used to identify and filter out packets originated from these 154 attachments with forged source IP addresses. In this way, this 155 mechanism can prevent hosts from spoofing IP addresses assigned to 156 the other attachment points. Compared with [BCP38], which provides 157 prefix granularity source IP address validity, this mechanism can 158 benefit the network with finer-grained validity and traceability of 159 source IP addresses. 161 This mechanism primarily performs DHCP snooping to set up bindings 162 between IP addresses assigned by DHCP and corresponding binding 163 anchors. This binding process is inspired by the work of [BA2007]. 164 Different from [BA2007], which designs specifications about DHCPv4, 165 this mechanism covers the DHCPv6 snooping process, the data snooping 166 process (refer to Section 7), as well as a number of other technical 167 details. Specially, the data snooping process is a data-triggered 168 binding setup procedure designed to avoid permanent block of valid 169 address in case that DHCP snooping is insufficient to set up all the 170 valid bindings. 172 This mechanism is designed for the stateful DHCP scenario [rfc2131], 173 [rfc3315]. In the stateless DHCP scenario [rfc3736], a client 174 obtains its addresses through some other mechanisms and so the 175 addresses of the client MUST be bound based on other SAVI solutions, 176 for example, SAVI FCFS[savi-fcfs]. Besides, this mechanism is 177 primarily designed for pure DHCP scenarios in which only addresses 178 assigned through DHCP are allowed. However, it does not block any 179 link-local address. It is because link-local addresses are used by 180 DHCPv6 clients before the clients are assigned a DHCPv6 address. 181 Considering that link-local addresses are generally self-generated, 182 and the spoofing of link local address may disturb this mechanism, it 183 is RECOMMENDED to enable a SAVI solution for link-local addresses, 184 e.g., the SAVI-FCFS [savi-fcfs]. 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 [savi-framework]. A list of proper 196 binding anchors can be found in Section 3.2 of [savi-framework]. 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 to an interface 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 DHCPv4 Decline: DHCPDECLINE [rfc2131] 231 o DHCPv4 Release: DHCPRELEASE [rfc2131] 233 o DHCPv4 Inform: DHCPINFORM [rfc2131] 235 o DHCPv6 Request: REQUEST [rfc3315] 237 o DHCPv6 Solicit: SOLICIT [rfc3315] 238 o DHCPv6 Confirm: CONFIRM [rfc3315] 240 o DHCPv6 Decline: DECLINE [rfc3315] 242 o DHCPv6 Release: RELEASE [rfc3315] 244 o DHCPv6 Rebind: REBIND [rfc3315] 246 o DHCPv6 Renew: RENEW [rfc3315] 248 o DHCPv6 Information-Request: INFORMATION-REQUEST [rfc3315] 250 DHCP Server-Client message: A message that is sent from a DHCP server 251 to a DHCP client. Such a message is of one of the following types: 253 o DHCPv4 ACK: DHCPACK [rfc2131] 255 o DHCPv4 NAK: DHCPNAK [rfc2131] 257 o DHCPv4 OFFER: DHCPOFFER [rfc2131] 259 o DHCPv6 Reply: REPLY [rfc3315] 261 o DHCPv6 Advertise: ADVERTISE [rfc3315] 263 o DHCPv6 Reconfigure: RECONFIGURE [rfc3315] 265 Lease time: The lease time in IPv4 [rfc2131] or the valid lifetime in 266 IPv6 [rfc3315]. 268 Binding entry: An 'permit' rule that defines a valid association 269 between an IP address and a binding anchor. 271 Binding State Table: The data structure that contains all the binding 272 entries. 274 4. Deployment Scenario and Configuration 276 4.1. Elements and Scenario 278 A list of essential elements in a SAVI-DHCP deployment scenario is 279 given as follows: 281 (1) DHCP server 283 (2) DHCP client 285 (3) SAVI device 287 And there may be following optional elements in a SAVI-DHCP 288 deployment scenario: 290 (1) DHCP relay 292 (2) Non-SAVI device 294 Figure 1 shows a deployment scenario that contains these elements. 295 Note that a physical device can be multiple elements, e.g, a switch 296 can be both a SAVI device and a DHCP relay. In such cases, the links 297 are logic links rather than physical links. 299 +--------+ +------------+ 300 |DHCP |-----| Non-SAVI | 301 |Server A| | Device 1 | 302 +--------+ +-----|------+ 303 ......................|............................ 304 . | . 305 . Protection +---|------+ . 306 . Perimeter | SAVI | . 307 . | Device C| . 308 . +---|------+ . 309 . | . 310 . +----------+ +---|------+ +----------+ . 311 downstream . | SAVI | | Non SAVI| | SAVI | . 312 link +----.-| Device A|----| Device 3|-------| Device B| . 313 | . +----|--|--+ +----------+ +-|---|----+ . 314 | . | +----------+ ............ | | . 315 | '.............. | . . | | . 316 | | . | . +--------+ | . 317 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 318 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 319 | Device 2 | |A | . |Relay | . |B | . |Server B| . 320 +----------+ +------+ . +------+ . +------+ . +--------+ . 321 ............ ............... 323 Figure 1: SAVI-DHCP Scenario 325 4.2. Attribute 327 As illustrated in Figure 1, an attachment to a SAVI device can be 328 from either a DHCP client, or a DHCP relay/server, or a SAVI device, 329 or a non-SAVI device. Different actions are performed on traffic 330 originated from different elements. To distinguish different types 331 of attachments, an attachment property named 'attribute' is 332 configured on SAVI devices. This section specifies the attributes 333 used by this mechanism. 335 Before configuration, an attachment is with no attribute. An 336 attachment MAY be configured to have one or more compatible 337 attributes(refer to Section 4.2.6). The attributes of each 338 attachment MUST be configured before this SAVI-DHCP function is 339 enabled on the attachment. The procedure performed by SAVI devices 340 on traffic from each attachment is determined by the attributes set 341 on the attachment. 343 Particularly, if an attachment has no attribute, no actions will be 344 performed by this SAVI function on traffic from such attachments. 345 For example, in Figure 1, the attachment from the Non-SAVI Device 1 346 to the SAVI Device B should be configured with no attribute. It 347 means 1) SAVI devices will neither set up bindings for upstream hosts 348 nor check traffic from upstream hosts; 2) SAVI devices will not snoop 349 DHCP messages from upstream devices unless the DHCP-Trust attribute 350 (refer to Section 4.2.2) is set on the corresponding attachment. The 351 reason that DHCP messages from upstream devices are not trusted by 352 default is discussed in Section 12.6. 354 4.2.1. Trust Attribute 356 The "Trust Attribute" indicates the packets from the corresponding 357 attachment are completely trustable. 359 SAVI devices will not set up bindings for attachments with Trust 360 attribute; DHCP messages and data packets from such attachments with 361 this attribute will not be checked. If the DHCP Server-Client 362 messages from attachments with this attribute can trigger the state 363 transitions specified in Section 6 and Section 7, these messages will 364 be handled by the corresponding processes in Section 6 and Section 7. 366 This attribute is generally configured on the attachments from other 367 SAVI devices. For example, in Figure 1, the attachment from the SAVI 368 Device A to the SAVI Device B and the attachment from the SAVI Device 369 B to the SAVI Device A should be configured with this attribute. 370 Besides, it can be configured on attachments from Non-SAVI devices 371 only if the Non-SAVI devices will not introduce unchecked traffic 372 from DHCP clients. For example, the attachments from Non-SAVI device 373 3 to SAVI device A, SAVI device B and SAVI device C can be configured 374 with this attribute, only if Non-SAVI device 3 does not have 375 attachment from DHCP clients. 377 4.2.2. DHCP-Trust Attribute 379 The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages 380 from the corresponding attachment is trustable. 382 SAVI devices will forward DHCP Server-Client messages coming from the 383 attachments with this attribute. If the DHCP Server-Client messages 384 can trigger the state transitions, they will be handled by the 385 binding setup processes specified in Section 6 and Section 7. 387 This attribute is generally used on the direct attachments from the 388 trusted DHCP servers/relays. In Figure 1, the attachment from the 389 DHCP Relay to the SAVI Device B, and the attachment from the DHCP 390 Server B to the SAVI Device B should be configured with this 391 attribute. It is NOT RECOMMENDED to configure this attribute on the 392 indirect attachments from the non-neighboring DHCP servers/relays 393 unless the attachments do not introduce bogus DHCP Server-Client 394 messages. For example, in Figure 1, the attachment from the Non-SAVI 395 Device 1 to the SAVI Device C should not be configured with this 396 attribute. The related security problem is discussed in 397 Section 12.6. 399 4.2.3. DHCP-Snooping Attribute 401 The "DHCP-Snooping Attribute" indicates bindings will be set up based 402 on DHCP snooping. 404 DHCP Client-Server messages from attachments with this attribute will 405 trigger the setup of bindings. SAVI devices will set up bindings on 406 attachments with this attribute based on the DHCP snooping procedure 407 described in Section 6. 409 DHCP-Snooping attribute is configured on the attachments from DHCP 410 clients. This attribute can be also used on the attachments from 411 downstream Non-SAVI devices which are attached by DHCP clients. In 412 Figure 1, the attachment from the Client A to the SAVI Device A, the 413 attachment from the Client B to the SAVI Device B, and the attachment 414 from the Non-SAVI Device 2 to the SAVI Device A can be configured 415 with this attribute. 417 4.2.4. Data-Snooping Attribute 419 The "Data-Snooping Attribute" indicates data packets from the 420 corresponding attachment may trigger binding setup procedure. 422 Data packets from attachments with this attribute may trigger the 423 setup of bindings. SAVI devices will set up bindings on attachments 424 with this attribute based on the data-triggered process described in 425 Section 7. 427 If DHCP-Snooping attribute is configured on an attachment, the 428 bindings on this attachment are set up based on DHCP message 429 snooping. However, in some scenarios, a DHCP address may be used by 430 a DHCP client without DHCP address assignment procedure performed on 431 its current attachment. For such attachments, the Data-Snooping 432 process, which is described in Section 7, is necessary. This 433 attribute is configured on such attachments. The usage of this 434 attribute is further discussed in Section 7. 436 4.2.5. Validating Attribute 438 The "Validating Attribute" indicates packets from the corresponding 439 attachment will be checked based on binding entries on the 440 attachment. 442 Packets coming from attachments with this attribute will be checked 443 based on binding entries on the attachment as specified in Section 8. 445 Validating attribute is configured on the attachments from which the 446 data packets should be checked. For example, the DHCP clients. 448 4.2.6. Table of Mutual Exclusions 450 Different types of attributes may indicate mutually exclusive actions 451 on packet. Mutually exclusive attributes MUST NOT be set on the same 452 attachment. The compatibility of different attributes is listed in 453 Figure 2. Note that although Trust and DHCP-Trust are compatible, 454 there is no need to configure DHCP-Trust on an attachment with Trust 455 attribute. 457 +----------+----------+----------+----------+----------+----------+ 458 | | | | DHCP- | Data- | | 459 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 460 +----------+----------+----------+----------+----------+----------+ 461 | | | | mutually | mutually | mutually | 462 | Trust | - |compatible| exclusive| exclusive| exclusive| 463 +----------+----------+----------+----------+----------+----------+ 464 | | | | | | | 465 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 466 +----------+----------+----------+----------+----------+----------+ 467 |DHCP- |mutually | | | | | 468 |Snooping |exclusive |compatible| - |compatible|compatible| 469 +----------+----------+----------+----------+----------+----------+ 470 |Data- |mutually | | | | | 471 |Snooping |exclusive |compatible|compatible| - |compatible| 472 +----------+----------+----------+----------+----------+----------+ 473 | |mutually | | | | | 474 |Validating|exclusive |compatible|compatible|compatible| - | 475 +----------+----------+----------+----------+----------+----------+ 477 Figure 2: Table of Mutual Exclusions 479 4.3. Perimeter 481 SAVI-DHCP can provide perimetrical security as SAVI-FCFS (refer to 482 Section 2.5 in [savi-fcfs]). Through configuring attribute of each 483 attachment properly, a perimeter separating untrusted area and 484 trusted area can be formed: 486 (1) Configure Validating attribute on the attachments of all the 487 DHCP clients. Configure DHCP-Snooping attribute on these 488 attachments. 490 (2) Configure Validating attribute on the attachments of downstream 491 Non-SAVI devices which are attached by DHCP clients. Configure 492 DHCP-Snooping attribute on these attachments. 494 (3) Configure Trust attribute on the attachments of other SAVI 495 devices. 497 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 498 have only attachments from SAVI devices or upstream devices, set 499 their attachments to SAVI devices with Trust attribute. 501 (5) Configure DHCP-Trust attribute on the direct attachments of DHCP 502 relays/servers. 504 In this way, attachments with Validating attribute (and generally 505 together with attachments of upstream devices) can form a perimeter 506 separating DHCP clients and trusted devices. Data packet check is 507 only performed on the perimeter. 509 The perimeter is primarily designed for scalability. Each SAVI 510 device only needs to establish bindings for clients directly attached 511 or indirectly attached through Non-SAVI devices. Binding entries for 512 addresses in the network are distributed on SAVI devices. Then the 513 SAVI devices can protect the inside of the perimeter collaboratively, 514 and each SAVI device is not requred to set up bindings for all the 515 addresses assigned in the network. 517 Particularly, SAVI-DHCP perimeter only contains trusted DHCP servers/ 518 relays inside. The SAVI devices only trust DHCP Server-Client 519 messages originated inside the perimeter. Because bogus DHCP servers 520 are out of the perimeter, the SAVI devices can be protected from 521 fabricated DHCP messages. Note that even if a DHCP server is valid, 522 it may be not contained in the perimeter. For example, in Figure 1, 523 DHCP server A is valid, but it is attached to a Non-SAVI device. The 524 Non-SAVI device may be attached by attackers which generate 525 fabricated DHCP messages. This binding based mechanism may not have 526 the ability to distinguish whether a message received from the 527 attachment of the Non-SAVI device 1 is from DHCP server A or the 528 attackers. If the DHCP server A is contained in the perimeter, the 529 Non-SAVI device 1 will also be contained in the perimter. However, 530 the Non-SAVI device 1 can introduce fabricated DHCP messages into the 531 perimeter. Thus, the DHCP server A cannot be contained in the 532 perimeter. In this case, the SAVI devices can set up bindings for 533 addresses assigned by DHCP server A through snooping the messages 534 relayed by trusted relay in the network. For example, the DHCP relay 535 may relay messages between DHCP server A and the clients in the 536 network, and the SAVI devices can snoop messages from the DHCP relay 537 which is inside the perimeter. The authentication mechanism enforced 538 between the DHCP relay and the DHCP server outside the perimeter can 539 compensate this binding based mechanism. 541 5. Binding State Table (BST) 543 Binding State Table is used to contain the bindings between the IP 544 addresses assigned to the attachments and the corresponding binding 545 anchors of the attachments. Each entry of the table, i.e., binding 546 entry, has 5 fields: 548 o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer 549 property of the attachment. 551 o IP Address(Address): the IP address assigned to the attachment by 552 DHCP. 554 o State: the state of the binding. Possible values of this field 555 are listed in Section 6.2 and Section 7.3. 557 o Lifetime: the remaining seconds of the binding. The Lifetime 558 field counts down automatically. 560 o TID: the Transaction ID (TID) (refer to [rfc2131] [rfc3315]) of 561 the corresponding DHCP transaction. TID field is used to 562 associate DHCP Server-Client messages with corresponding binding 563 entries. 565 An instance of this table is shown in Figure 3. 567 +---------+----------+----------+-----------+-------+ 568 | Anchor | Address | State | Lifetime |TID | 569 +---------+----------+----------+-----------+-------+ 570 | A | IP_1 | BOUND | 65535 |TID_1 | 571 +---------+----------+----------+-----------+-------+ 572 | A | IP_2 | BOUND | 10000 |TID_2 | 573 +---------+----------+----------+-----------+-------+ 574 | B | IP_3 |INIT_BIND | 1 |TID_3 | 575 +---------+----------+----------+-----------+-------+ 577 Figure 3: Instance of BST 579 6. DHCP Snooping Process 581 This section specifies the process of setting up bindings based on 582 DHCP snooping, named DHCP Snooping Process. This process is 583 illustrated making use of a state machine. 585 6.1. Rationale 587 The rationale of the DHCP Snooping Process is that if a DHCP client 588 is legitimate to use a DHCP address, the DHCP address assignment 589 procedure which assigns the IP address to the client must have been 590 performed on the attachment of the client. This basis stands when 591 the SAVI device is always on the path(s) from the DHCP client to the 592 DHCP server(s)/relay(s). Without considering the movement of DHCP 593 clients, the SAVI device should be the cut node which separates the 594 DHCP clients and the remaining network containing the DHCP server(s)/ 595 relay(s). For most of the layer-2 networks whose topologies are 596 simple, it is possible to deploy this SAVI function at proper devices 597 to meet this requirement. 599 However, a deployment of this SAVI function may not meet the 600 requirement. Besides, the movement of DHCP clients may make bindings 601 are not set up on their new attachments. These exceptions and the 602 solutions are discussed in Section 7. 604 6.2. Binding States Description 606 Following binding states present in this process and the 607 corresponding state machine: 609 NO_BIND: The state before a binding has been set up. 611 INIT_BIND: A potential binding has been set up. 613 BOUND: The binding has been set up. 615 6.3. Events 617 This section describes events in this process and the corresponding 618 state machine. 620 6.3.1. Timer Expiration Event 622 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 624 6.3.2. Control Message Arriving Events 626 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 627 received. 629 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 631 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 633 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 634 received. 636 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 638 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 639 option is received. 641 EVE_DHCP_REPLY_REQUEST: A DHCPv4 ACK or a DHCPv6 Reply message is 642 received, and there is an entry in the BST whose TID field is the 643 same as the message. The DHCPv6 Reply message must be in response to 644 a DHCPv6 Request message, and the assignment is successful. (Note: A 645 DHCPv6 Reply may be a response to DHCPv6 Request, DHCPv6 Confirm, 646 DHCPv6 Renew, DHCPv6 Rebind, DHCPv6 Decline, DHCPv6 Release and 647 DHCPv6 Information-request. Through checking the Status Code option, 648 IA options and other related options in the Reply message, it is 649 possible to determine the purpose of the DHCPv6 Reply. An 650 implementation should refer to [rfc3315] to identify such messages. 651 The processing of the following six events should check the purpose 652 of the DHCP Reply similarly.) 654 EVE_DHCP_REPLY_REQUEST_NULL: A DHCPv4 ACK or a DHCPv6 Reply message 655 is received, and there is no entry in the BST whose TID field is the 656 same as the message. The DHCPv6 Reply message must be in response to 657 a DHCPv6 Request message, and the assignment is successful. 659 EVE_DHCP_REPLY_REBIND: A DHCPv4 ACK or a DHCPv6 Reply message is 660 received, and there is an entry in the BST whose TID field is the 661 same as the message. The DHCPv6 Reply message must be in response to 662 a DHCPv6 Rebind message. 664 EVE_DHCP_REPLY_REBIND_NULL: A DHCPv4 ACK or a DHCPv6 Reply message is 665 received, and there is no entry in the BST whose TID field is the 666 same as the message. The DHCPv6 Reply message must be in response to 667 a DHCPv6 Rebind message. 669 EVE_DHCP_REPLY_CONFIRM: A DHCPv4 ACK or a DHCPv6 Reply message is 670 received, and there is an entry in the BST whose TID field is the 671 same as the message. The DHCPv6 Reply message must be in response to 672 a DHCPv6 Confirm message. 674 EVE_DHCP_REPLY_RENEW: A DHCPv4 ACK or a DHCPv6 Reply message is 675 received, and there is an entry in the BST whose TID field is the 676 same as the message. The DHCPv6 Reply message must be in response to 677 a DHCPv6 Renew message. 679 EVE_DHCP_REPLY_RENEW_NULL: A DHCPv4 ACK or a DHCPv6 Reply message is 680 received, and there is no entry in the BST whose TID field is the 681 same as the message. The DHCPv6 Reply message must be in response to 682 a DHCPv6 Renew message. 684 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 685 received. 687 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 688 received. 690 EVE_DCHP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 691 section 4.3.3 of [rfc5007]) is received. 693 Moreover, only if a DHCP message can pass the following checks, the 694 corresponding event is regarded as a valid event: 696 o Attribute check: the DHCP Server-Client messages and 697 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 698 attribute; the DHCP Client-Server messages should be from 699 attachments with DHCP-Snooping attribute. 701 o Destination check: the DHCP Server-Client messages should be 702 destined to attachments with DHCP-Snooping attribute. 704 o Binding anchor check: the DHCP Client-Server messages which may 705 trigger modification or removal of an existing binding entry must 706 have matched binding anchor with the corresponding entry. 708 o TID check: the DHCP Server-Client/Client-Server messages must 709 have matched TID with the corresponding entry. 711 o Binding limitation check: the DHCP messages must not cause new 712 binding setup on an attachment whose binding entry limitation has 713 been reached. (refer to Section 12.8). 715 o Address check: the address of the DHCP messages should pass the 716 check specified in Section 8.2. 718 On receiving a DHCP message without triggering a valid event, the 719 state will not transit and actions will not be performed. 721 6.4. State Machine of DHCP Packet Snooping 723 This section specifies the transits of each state and the 724 corresponding actions. 726 6.4.1. From NO_BIND to Other States 728 6.4.1.1. Trigger Event 730 EVE_DHCP_REQUEST, EVE_DHCP_OPTION_RC, EVE_DHCP_CONFIRM, 731 EVE_DHCP_REBOOT, EVE_DHCP_REBIND, EVE_DHCP_RENEW, 732 EVE_DHCP_REPLY_NULL. 734 6.4.1.2. Following Actions 736 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC/ 737 EVE_DHCP_REBOOT: 739 The SAVI device MUST forward the message. 741 The SAVI device will generate an entry in the Binding State Table 742 (BST). The Binding anchor field is set to the binding anchor of the 743 attachment from which the message is received. The State field is 744 set to INIT_BIND. The Lifetime field is set to be 745 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 746 message. If the message is DHCPv4 Request or DHCPv4 Reboot, the 747 Address field can be set to the address to request, i.e., the 748 'requested IP address'. An example of the entry is illustrated in 749 Figure 4. 751 +---------+-------+---------+-----------------------+-------+ 752 | Anchor |Address| State | Lifetime |TID | 753 +---------+-------+---------+-----------------------+-------+ 754 | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 755 +---------+-------+---------+-----------------------+-------+ 757 Figure 4: Binding entry in BST on Request/Rapid Commit/Reboot 758 triggered initialization 760 If the triggering event is EVE_DHCP_CONFIRM/EVE_DHCP_REBIND/ 761 EVE_DHCP_RENEW: 763 If the message is DHCPv4 Rebind/Renew, the message MUST be forwarded. 764 In DHCPv6, a DHCP client may try to confirm or rebind or renew 765 multiple addresses in a message. In such case, the SAVI device MUST 766 check whether setting up corresponding bindings will make the binding 767 number limitation exceeded. If the limitation will be exceeded, the 768 message MUST be discarded and the following actions will not be 769 performed; or else the message MUST be forwarded. 771 The SAVI device will generate corresponding entries in the Binding 772 State Table (BST). The Binding anchor field is set to the binding 773 anchor of the attachment from which the message is received. The 774 State field is set to INIT_BIND. The Lifetime field is set to be 775 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 776 message. The Address field is set to the address to confirm/ 777 rebind(i.e., 'ciaddr' in DHCPv4 Rebind, IPv6 address in IA Address 778 options of DHCPv6 Confirm/Rebind). An example of the entries is 779 illustrated in Figure 5. 781 +---------+--------+---------+-----------------------+-------+ 782 | Anchor | Address| State | Lifetime |TID | 783 +---------+--------+---------+-----------------------+-------+ 784 | A | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 785 +---------+--------+---------+-----------------------+-------+ 786 | A | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 787 +---------+--------+---------+-----------------------+-------+ 789 Figure 5: Binding entry in BST on Confirm/Rebind/Renew triggered 790 initialization 792 If the triggering event is EVE_DHCP_REPLY_REQUEST_NULL/ 793 EVE_DHCP_REPLY_REBIND_NULL/EVE_DHCP_REPLY_RENEW_NULL: 795 If the message is DHCPv4 ACK, the message MUST be forwarded. For 796 DHCPv6, a DHCPv6 Reply message may assign multiple addresses to an 797 attachment. In such case, the SAVI device MUST check whether setting 798 up corresponding bindings will make the binding number limitation 799 exceeded. If the limitation will be exceeded, the message MUST be 800 discarded and the following actions will not be performed; or else 801 the message MUST be forwarded. 803 If the message is DHCPv4 ACK, the SAVI device MUST generate a 804 corresponding entry in the BST. 806 If the message is DHCPv6 Reply, the SAVI device MUST generate as many 807 new entries in the BST as the number of assign addresses(IPv6 808 addresses in all the IA Address options of the message). The Binding 809 anchor field is set to the binding anchor of the destined attachment. 810 The State field is set to be BOUND. The Lifetime field is set to the 811 sum of the lease time in Reply message and MAX_DHCP_RESPONSE_TIME. 812 The Address field is set to the assigned address (i.e., 'yiaddr' in 813 DHCPv4 ACK, IPv6 address in IA Address options of DHCPv6 Reply). 815 An example of the entries is illustrated in Figure 6. 817 This process is designed to handle the situation that the client 818 moves after sending a Request/Rebind/Renew message. Vulnerability in 819 this process is discussed in Section 12.1. 821 +---------+----------+-------+------------------------+-------+ 822 | Anchor | Address | State | Lifetime |TID | 823 +---------+----------+-------+------------------------+-------+ 824 | A | Addr1 | BOUND | Lease time 1 |TID | 825 | | | | +MAX_DHCP_RESPONSE_TIME| | 826 +---------+----------+-------+------------------------+-------+ 827 | A | Addr2 | BOUND | Lease time 2 |TID | 828 | | | | +MAX_DHCP_RESPONSE_TIME| | 829 +---------+----------+-------+------------------------+-------+ 831 Figure 6: Binding entry in BST on Reply triggered initialization 833 6.4.2. From INIT_BIND to Other States 835 6.4.2.1. Trigger Event 837 EVE_DHCP_REPLY_REQUEST, EVE_DHCP_REPLY_REBIND, 838 EVE_DHCP_REPLY_CONFIRM, EVE_ENTRY_EXPIRE. 840 6.4.2.2. Following Actions 842 If the trigger event is EVE_DHCP_REPLY_REQUEST/EVE_DHCP_REPLY_REBIND/ 843 EVE_DHCP_REPLY_RENEW: 845 If the message is DHCPv4 ACK, the message MUST be forwarded. In 846 DHCPv6, a DHCPv6 Reply message may assign multiple addresses to an 847 attachment. In such case, the SAVI device MUST check whether setting 848 up corresponding bindings will make the binding number limitation 849 exceeded. If the limitation will be exceeded, the message MUST be 850 discarded and the following actions will not be performed; or else 851 the message MUST be forwarded. 853 The Address field of the corresponding entry in the BST is set to the 854 address in the message(i.e., 'yiaddr' in DHCPv4 ACK, IPv6 address in 855 IA Address options of DHCPv6 Reply). The Lifetime field is set to 856 the sum of the lease time in Reply message and 857 MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. For 858 DHCPv6, if more than one IA Address options is found in the message, 859 corresponding new entries MUST be generated. 861 An example of the entries is illustrated in Figure 7. 863 +---------+----------+-------+------------------------+-------+ 864 | Anchor | Address | State | Lifetime |TID | 865 +---------+----------+-------+------------------------+-------+ 866 | A | Addr1 | BOUND |Lease time+ |TID | 867 | | | |MAX_DHCP_RESPONSE_TIME | | 868 +---------+----------+-------+------------------------+-------+ 869 | A | Addr2 | BOUND |Lease time+ |TID | 870 | | | |MAX_DHCP_RESPONSE_TIME | | 871 +---------+----------+-------+------------------------+-------+ 873 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 874 Request/Rebind/Renew 876 If the trigger event is EVE_DHCP_REPLY_CONFIRM: 878 The DHCP Reply message is in response to a Confirm message. If the 879 Status Code option of the message is not Success (refer to Section 880 24.4 of [rfc3315]), the message will be forwarded, but no following 881 actions will be performed. If the Status Code option of the message 882 is Success, the state of the corresponding entry is changed to BOUND. 883 Because [rfc3315] does not require lease time of addresses to be 884 contained in the Reply message, the SAVI device MUST send a 885 LEASEQUERY [rfc5007] message querying by IP address to 886 All_DHCP_Relay_Agents_and_Servers multicast address [rfc3315] or a 887 configured server address. The Lifetime of corresponding entries is 888 set to MAX_LEASEQUERY_DELAY. 890 An example of the entries is illustrated in Figure 8. 892 The related security problem about DHCPv6 LEASEQUERY is discussed in 893 Section 12.7. 895 +---------+----------+-------+------------------------+-------+ 896 | Anchor | Address | State | Lifetime |TID | 897 +---------+----------+-------+------------------------+-------+ 898 | A | Addr1 | BOUND | MAX_LEASEQUERY_DELAY |TID | 899 +---------+----------+-------+------------------------+-------+ 900 | A | Addr2 | BOUND | MAX_LEASEQUERY_DELAY |TID | 901 +---------+----------+-------+------------------------+-------+ 903 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 904 Confirm 906 If the trigger event is EVE_ENTRY_EXPIRE: 908 The entry MUST be deleted from BST. 910 Note: If no DHCP Server-Client messages which assign addresses or 911 confirm addresses are received, corresponding entries will expire 912 automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4 913 NAK) are not specially processed. 915 6.4.3. From BOUND to Other States 917 6.4.3.1. Trigger Event 919 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 920 EVE_DHCP_REPLY_REQUEST, EVE_DHCP_REPLY_RENEW, EVE_DHCP_REPLY_REBIND, 921 EVE_DCHP_LEASEQUERY. 923 6.4.3.2. Following Actions 925 If the trigger event is EVE_ENTRY_EXPIRE: 927 Remove the corresponding entry in BST. 929 If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE: 931 Remove the corresponding entry in BST. The Release or Decline 932 message MUST be forwarded. 934 If the trigger event is EVE_DHCP_REPLY_REQUEST/EVE_DHCP_REPLY_RENEW/ 935 EVE_DHCP_REPLY_REBIND: 937 Set the Lifetime field of the corresponding entries to be the sum of 938 the new lease time and MAX_DHCP_RESPONSE_TIME. 940 If the trigger event is EVE_DCHP_LEASEQUERY: 942 Set the Lifetime field to the sum of the lease time in the 943 LEASEQUERY_REPLY message and MAX_DHCP_RESPONSE_TIME. 945 6.5. Table of State Machine 947 The main state transits are listed as follows. 949 State Event Action Next State 950 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 951 NO_BIND RPL_NULL Generate entry with lease BOUND 952 INIT_BIND RPL_RE Record lease time BOUND 953 INIT_BIND RPL_CF Send Leasequery BOUND 954 INIT_BIND Timeout Remove entry NO_BIND 955 BOUND RLS/DCL Remove entry NO_BIND 956 BOUND Timeout Remove entry NO_BIND 957 BOUND RPL_RE Set new lifetime BOUND 958 BOUND LQR Record lease time BOUND 960 Figure 9: Table of Transit 962 RQ: EVE_DHCP_REQUEST 964 CF: EVE_DHCP_CONFIRM 966 RC: EVE_DHCP_OPTION_RC 968 RE: EVE_DHCP_REBIND/EVE_DHCP_RENEW/EVE_DHCP_REBOOT 970 RPL_NULL: EVE_DHCP_REPLY_REQUEST_NULL/EVE_DHCP_REPLY_REBIND_NULL/ 971 EVE_DHCP_REPLY_RENEW_NULL 973 RPL_RE: EVE_DHCP_REPLY_REQUEST/EVE_DHCP_REPLY_REBIND/ 974 EVE_DHCP_REPLY_RENEW 976 RPL_CF: EVE_DHCP_REPLY_CONFIRM 978 DCL: EVE_DHCP_DECLINE 980 RLS: EVE_DHCP_RELEASE 982 LQR: EVE_DCHP_LEASEQUERY 984 Timeout: EVE_ENTRY_EXPIRE 985 +-------------+ 986 | | 987 /---------| NO_BIND |<----------\ 988 | ------>| |---------\ | 989 | | +-------------+ | |EVE_DHCP_RELEASE 990 EVE_DHCP_REQUEST | | EVE_DHCP_RENEW_NULL| |EVE_DHCP_DECLINE 991 EVE_DHCP_CONFIRM | |TIMEOUT EVE_DHCP_REPLY_NULL| |TIMEOUT 992 EVE_DHCP_OPTION_RC| | EVE_DHCP_REBIND_NULL| | 993 EVE_DHCP_REBIND | | | | 994 EVE_DHCP_RENEW | | EVE_DHCP_REPLY_RENEW | | 995 EVE_DHCP_REBOOT | | EVE_DHCP_REPLY_REBIND | | 996 v | EVE_DHCP_REPLY_REQUEST v | 997 +-------------+ EVE_DHCP_REPLY_CONFIRM +------------+ 998 | | | | 999 | INIT_BIND ------------------------>| BOUND |<-\ 1000 | | | | | 1001 +-------------+ +------------+ | 1002 | | 1003 \--------/ 1004 EVE_DHCP_REPLY_RENEW 1005 EVE_LEASEQUERY_REPLY 1006 EVE_DHCP_REPLY_REBIND 1007 EVE_DHCP_REPLY_REQUEST 1009 Figure 10: Diagram of Transit 1011 7. Data Snooping Process 1013 7.1. Scenario 1015 The rationale of the DHCP Snooping Process specified in Section 6 is 1016 that if a DHCP client is legitimate to use a DHCP address, the 1017 corresponding DHCP address assignment procedure must have been 1018 finished on the attachment of the DHCP client. This basis stands 1019 when the SAVI device is always on the path(s) from the DHCP client to 1020 the DHCP server(s)/relay(s). However, there are two exceptions: 1022 o Multiple paths: there are more than one feasible layer-2 paths 1023 from the client to the DHCP server/relay, and the SAVI device is 1024 not on all of them. The client may get the address through one 1025 of the paths not passing by the SAVI device, but packets from the 1026 client can travel through the other paths passing by the SAVI 1027 device. Because the SAVI device does not snoop the DHCP 1028 assignment procedure, the DHCP snooping procedure will not set up 1029 the corresponding binding. 1031 o Dynamic path: there is only one feasible layer-2 path from the 1032 client to the DHCP server/relay, but the path is dynamic due to 1033 topology change or layer-2 path change. This situation also 1034 covers the local-link movement of clients without address 1035 confirm/re-configuration process. In such cases, the DHCP 1036 snooping process will not set up the corresponding binding. 1038 Data Snooping Process is designed to avoid permanently blocking 1039 legitimate traffic in case of these two exceptions. This process is 1040 performed on attachments with Data-Snooping attribute. Data packets 1041 without matched binding entry may trigger this process to set up 1042 bindings. 1044 Snooping data traffic will introduce considerable burden on the 1045 processor and ASIC-to-Processor bandwidth of SAVI devices. 1046 Considering the overhead of this process, the implementation of this 1047 process is a conditional SHOULD. This function SHOULD be implemented 1048 unless the implementation is known to be used in the scenarios 1049 without the above exceptions. For example, if the implementation is 1050 to be used in networks with tree topology and without host local-link 1051 movement, there is no need to implement this process in such 1052 scenarios. 1054 This process is not supposed to set up a binding whenever a data 1055 packet without matched binding entry is received. Instead, unmatched 1056 data packets trigger this process with a probability and generally a 1057 number of unmatched packets will be discarded before the binding is 1058 set up. 1060 7.2. Rationale 1062 This process makes use of duplication detection and DHCP Leasequery 1063 to set up bindings. If an address is not used by another client in 1064 the network, and the address has been assigned in the network, the 1065 address can be bound with the binding anchor of the attachment from 1066 which the unmatched packet is received. 1068 The security issues about this process is discussed is Section 12.2. 1070 7.3. Additional Binding States Description 1072 In addition to Section 6.2, new states used in this process are 1073 listed here: 1075 DETECTION: The address in the entry is under local duplication 1076 detection. 1078 RECOVERY: The SAVI device is querying the assignment and lease time 1079 of the address in the entry through DHCP Leasequery. 1081 7.4. Events 1083 Additional events in this process are described here. Also, if an 1084 event will trigger to set up a new binding entry, the binding entry 1085 limit on the binding anchor MUST NOT have not been reached. 1087 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1089 EVE_DATA_CONFLICT: ARP Response/Neighbor Advertisement(NA) message 1090 against an address in DETECTION state is received. 1092 EVE_DATA_LEASEQUERY: 1094 IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1095 is received. 1097 IPv6: A successful LEASEQUERY-REPLY is received. 1099 The triggering packet should pass the following checks to trigger a 1100 valid event: 1102 o Attribute check: the data packet should be from attachments with 1103 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1104 messages should be from attachments with DHCP-Snooping attribute. 1106 o Binding limitation check: the DHCP messages must not cause new 1107 binding setup on an attachment whose binding entry limitation has 1108 been reached. (refer to Section 12.8). 1110 o Address check: the address of the DHCP/ARP/NA messages should 1111 pass the check specified in Section 8.2. 1113 o Interval check: the interval between two successive 1114 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1115 smaller than DATA_SNOOPING_INTERVAL. 1117 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must 1118 have matched TID with the corresponding entry. 1120 7.5. State Machine of Binding Recovery Process 1122 Through using additional states, the state machine of this process 1123 doesn't conflict the regular process described in Section 6. Thus, 1124 it can be implemented separately without changing the state machine 1125 in Section 6. 1127 7.5.1. From NO_BIND to Other States 1129 7.5.1.1. Trigger Event 1131 EVE_DATA_UNMATCH. 1133 7.5.1.2. Following Actions 1135 Determine whether to process this event with a probability. The 1136 probability can be configured or calculated based on the state of the 1137 SAVI device. This probability should be low enough to mitigate the 1138 damage from DoS attack against this process. 1140 Create a new entry in the BST. Set the Binding Anchor field to the 1141 corresponding binding anchor of the attachment. Set the Address 1142 field to be source address of the packet. Set the State field to 1143 DETECTION. Set the Lifetime of the created entry to 2*DAD_TIMEOUT. 1145 Check if the address has a local conflict (it violates an address 1146 being used by another node): 1148 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1149 [rfc826]or a ARP probe [rfc5227] on the address; if there is no 1150 response message after DAD_TIMEOUT, send another ARP Request or 1151 ARP probe; 1153 (2) IPv6 address: perform Duplicate Address Detection (DAD) 1154 [rfc4862] on the address; if there is no response message after 1155 DAD_TIMEOUT, perform another DAD procedure. 1157 Because the delivery of detection message is unreliable, the 1158 detection message is of a certain possibility of not reaching the 1159 targeting node. If the targeting node doesn't get the detection 1160 message, the address may be bound with a wrong binding anchor in the 1161 further stages. This fault may introduce attack against this 1162 mechanism. Thus, the detection is performed again if there is no 1163 response after the first detection. 1165 The messages MUST NOT be sent to the attachment from which the 1166 triggering packet is received. 1168 The packet which triggers this event SHOULD be discarded. 1170 An example of the entry is illustrated in Figure 11. 1172 +---------+-------+---------+-----------------------+-------+ 1173 | Anchor |Address| State | Lifetime |TID | 1174 +---------+-------+---------+-----------------------+-------+ 1175 | A | Addr1 |DETECTION|2*DAD_TIMEOUT | | 1176 +---------+-------+---------+-----------------------+-------+ 1178 Figure 11: Binding entry in BST on data triggered initialization 1180 7.5.2. From DETECTION to Other States 1182 7.5.2.1. Trigger Event 1184 EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT. 1186 7.5.2.2. Following Actions 1188 If the trigger event is EVE_ENTRY_EXPIRE: 1190 (1) IPv4 address: Send a DHCPLEASEQUERY [rfc4388] message querying 1191 by IP address to all DHCPv4 servers with IP Address Lease Time 1192 option (option 51). The server addresses can be found through 1193 DHCPv4 Discovery or from configuration. Change the state of the 1194 corresponding entry to RECOVERY. Change the lifetime of the 1195 entry to be MAX_LEASEQUERY_DELAY. 1197 (2) IPv6 address: Send a LEASEQUERY [rfc5007] message querying by IP 1198 address to All_DHCP_Relay_Agents_and_Servers multicast address 1199 or a configured server address. 1201 Change the state of the corresponding entry to RECOVERY. Change the 1202 lifetime of the entry to be MAX_LEASEQUERY_DELAY. The TID field is 1203 set to the TID used in the Leasequery message. 1205 An example of the entry is illustrated in Figure 12. 1207 +---------+-------+---------+-----------------------+-------+ 1208 | Anchor |Address| State | Lifetime |TID | 1209 +---------+-------+---------+-----------------------+-------+ 1210 | A | Addr1 |RECOVERY |MAX_LEASEQUERY_DELAY |TID | 1211 +---------+-------+---------+-----------------------+-------+ 1213 Figure 12: Binding entry in BST on Lease Query 1215 If the trigger event is EVE_DATA_CONFLICT: 1217 Remove the entry. 1219 7.5.3. From RECOVERY to Other States 1221 7.5.3.1. Trigger Event 1223 EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY. 1225 7.5.3.2. Following Actions 1227 If the trigger event is EVE_DATA_LEASEQUERY: 1229 (1) IPv4 address: Check if the 'chaddr' field (hardware address) of 1230 the DHCPLEASEACTIVE message matches the hardware address of the 1231 triggering message. If the two addresses do not match, the 1232 following actions will not be performed. Change the state of 1233 the corresponding binding to BOUND. Set life time to the sum of 1234 the value encoded in IP Address Lease Time option of the 1235 DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Erase the 1236 TID field. 1238 (2) IPv6 address: Change the state of the corresponding binding to 1239 BOUND. Set the lifetime to the sum of the valid lifetime 1240 extracted from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY 1241 message and MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1243 If multiple addresses are specified in the LEASEQUERY-REPLY message, 1244 new entries MUST also be created correspondingly on the same binding 1245 anchor. 1247 If the trigger event is EVE_ENTRY_EXPIRE: 1249 Remove the entry. 1251 7.5.4. After BOUND 1253 Note that the TID field contains no value after the binding state 1254 changes to BOUND. The TID field is recovered from snooping DHCP 1255 Renew/Rebind messages. Because TID is used to associate binding 1256 entries with messages from DHCP servers, it must be recovered; or 1257 else a number of state transits of this mechanism will be not 1258 executed normally. 1260 7.5.4.1. Trigger Event 1262 EVE_DHCP_RENEW/EVE_DHCP_REBIND. 1264 7.5.4.2. Following Action 1266 Set the TID field of the corresponding entry to the TID in the 1267 triggering message. 1269 7.6. Table of State Machine 1271 The main state transits are listed as follows. 1273 State Event Action Next State 1274 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1275 DETECTION Timeout Send Leasequery RECOVERY 1276 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1277 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND 1278 RECOVERY Timeout Remove entry NO_BIND 1279 BOUND RENEW/REBIND Record TID BOUND 1281 Figure 13: Table of Transit 1283 RENEW: EVE_DHCP_RENEW 1285 REBIND: EVE_DHCP_REBIND 1287 Timeout: EVE_ENTRY_EXPIRE 1288 +-------------+ 1289 | | 1290 /---------| NO_BIND |<----------\ 1291 | ------>| | | 1292 | | +-------------+ | 1293 EVE_DATA_UNMATCH | |EVE_DATA_CONFLICT | 1294 | | |TIMEOUT 1295 | | | 1296 | | | 1297 | | | 1298 | | | 1299 v | | 1300 +-------------+ TIMEOUT +------------+ 1301 | | | | 1302 | DETECTION ------------------------>| RECOVERY | 1303 | | | | 1304 +-------------+ +------------+ 1305 EVE_DATA_LEASEQUERY| 1306 /----------\ | 1307 EVE_DHCP_RENEW| | | 1308 EVE_DHCP_REBIND| +-----v-------+ | 1309 | | | | 1310 \----| BOUND |<----------/ 1311 | | 1312 +-------------+ 1314 Figure 14: Diagram of Transit 1316 8. Filtering Specification 1318 This section specifies how to use bindings to filter out spoofing 1319 packets. 1321 Filtering policies are different for data packet and control packet. 1322 DHCP and NDP (Neighbor Discovery Protocol) [rfc4861] messages that 1323 may cause state transit are classified into control packet. Neighbor 1324 Advertisement (NA) and ARP Response are also included in control 1325 packet because the Target Address of NA and ARP Response should be 1326 checked to prevent spoofing. All other packets are considered to be 1327 data packets. 1329 8.1. Data Packet Filtering 1331 Data packets from attachment with attribute Validating MUST be 1332 checked. 1334 Packet whose source IP address is a link-local address SHOULD be 1335 forwarded. 1337 If the source IP address of a packet is not a link-local address, but 1338 there is not a matched entry in BST with state BOUND, this packet 1339 MUST be discarded. However, the packet may trigger Data Snooping 1340 Process if Data-Snooping attribute is set on the attachment. 1342 The SAVI device MAY record any violation. 1344 8.2. Control Packet Filtering 1346 For attachments with Validating attribute: 1348 Discard DHCPv4 Request message whose source IP address is neither all 1349 zeros nor a bound address in BST. 1351 Discard DHCPv6 Request message whose source IP address is neither a 1352 link-local address nor bound with the corresponding binding anchor in 1353 BST. 1355 Discard NDP messages whose source IP address is neither a link-local 1356 address nor bound with the corresponding binding anchor. In 1357 addition, discard NA message whose target address is neither a link- 1358 local address nor bound with the corresponding binding anchor. 1360 Discard ARP messages whose protocol is IP and sender protocol address 1361 is neither all zeros address nor bound with the corresponding binding 1362 anchor. In addition, discard ARP Reply messages whose target address 1363 is not bound with the corresponding binding anchor. 1365 For attachments with other attributes: 1367 Discard DHCP server/relay type message not from attachments with the 1368 DHCP-Trust attribute or Trust attribute. 1370 The SAVI device MAY record any violation. 1372 For attachments with no attribute: 1374 No action will be performed on traffic from such attachments. 1376 9. State Restoration 1378 If a SAVI device reboots, the information kept in volatile memory 1379 will be lost. This section specifies the restoration of attribute 1380 configuration and BST. 1382 9.1. Attribute Configuration Restoration 1384 The lost of attribute configuration will not break the network: no 1385 action will be performed on traffic from attachments with no 1386 attribute. However, the lost of attribute configuration makes this 1387 SAVI function unable to work. 1389 To avoid the loss of binding anchor attribute configuration, the 1390 configuration MUST be able to be stored in non-volatile storage. 1391 After the reboot of SAVI device, if the configuration of binding 1392 anchor attribute can be found in non-volatile storage, the 1393 configuration MUST be used. 1395 9.2. Binding State Restoration 1397 The loss of binding state will cause the SAVI devices discard 1398 legitimate traffic. Purely using the Data Snooping Process to 1399 recover a large number of bindings is of heavy overhead and 1400 considerable delay. Thus, to recover bindings from non-volatile 1401 storage, as specified below, is RECOMMENDED. 1403 Binding entries MAY be saved into non-volatile storage whenever a new 1404 binding entry changes to BOUND state. If a binding with BOUND state 1405 is removed, the saved entry MUST be removed correspondingly. 1407 Immediately after reboot, the SAVI device SHOULD restore binding 1408 states from the non-volatile storage. The system time of save 1409 process MUST be stored. After rebooting, the SAVI device MUST check 1410 whether each entry has been obsolete through comparing the saved 1411 lifetime and the difference between the current system time and saved 1412 system time. 1414 10. Constants 1416 MAX_DHCP_RESPONSE_TIME 120s 1418 DATA_SNOOPING_INTERVAL 60s and configurable 1420 MAX_LEASEQUERY_DELAY 10s 1422 OFFLINK_DELAY 30s 1424 DAD_TIMEOUT 0.5s 1426 11. MLD Consideration 1428 To perform the duplicate detection in Data Snooping Process 1429 Section 7, the SAVI device MUST join the Solicited Node Multicast 1430 group of the source address of triggering IPv6 data packet whenever 1431 performing duplicate detection. 1433 12. Security Considerations 1435 12.1. Security Problem about Binding Setup Triggered by 1436 EVE_DHCP_REPLY_NULL 1438 Whenever the triggering event is EVE_DHCP_REPLY_NULL(EVE_DHCP_REPLY_R 1439 EQUEST_NULL/EVE_DHCP_REPLY_REBIND_NULL/EVE_DHCP_REPLY_RENEW_NULL), 1440 the SAVI device will try to bind the assigned address with the 1441 attachment whose link layer address is the destination link layer 1442 address of the message. However, the assigned address could be bound 1443 with a wrong attachment if an attacker can pollute the mapping from 1444 the link layer address to attachment in the SAVI device. 1446 For example, the SAVI device is a switch and switch port is used as 1447 binding anchor. When the SAVI device receives a DHCP Reply with 1448 assigned address IP_A and destination link layer address MAC_A, it 1449 will check its MAC-to-port table to find the right port. But the 1450 MAC-to-port table might be polluted. For example, the requester with 1451 MAC_A is attached to Port_A, but an attacker attached to Port_B 1452 announces it has MAC_A. If there is no security mechanism used to 1453 protect MAC addresses, the SAVI device can bind MAC_A with Port_B. 1454 Then the SAVI device will find MAC_A is at Port_B from the polluted 1455 MAC-to-port table and it will bind IP_A with Port_B. 1457 Protection from this attack can be ensured by making sure that one of 1458 the following conditions is satisfied: 1460 (1) DHCP Option 82 is used to keep binding anchor in DHCP Request 1461 and Reply. DHCP Option 82 can be used to keep the circuit 1462 information of the client and returned by the DHCP server. 1463 Thus, the binding anchor can be determined from the circuit 1464 information in the Option. It can be used whenever an 1465 implementation doesn't want to create an entry on receiving DHCP 1466 Request message. 1468 (2) MAC address is hard to spoof (e.g., 802.11i, 802.1ae/af). 1470 (3) The mapping table from MAC to binding anchor is secure. For 1471 example, whenever switch port is used as binding anchor, some 1472 security mechanism is used to ensure the mapping from MAC to 1473 switch port is secure. 1475 Specially, if the binding anchor is just link layer address, there is 1476 no such security problem due to there is no need to map link layer 1477 address to binding anchor. 1479 It is RECOMMENDED to implement/enable one of the mechanisms in the 1480 SAVI device. 1482 12.2. Security Problems about the Data Snooping Process 1484 There are two security problems about the Data Snooping Process 1485 Section 7: 1487 (1) The Data Snooping Process is costly, but an attacker can trigger 1488 it simply through sending a number of data packets. To avoid 1489 Denial of Services attack against the SAVI device itself, the 1490 Data Snooping Process MUST be rate limited. A constant 1491 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1492 Data Snooping Processes on one attachment MUST have a minimum 1493 interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be 1494 configured prudently to avoid Denial of Service attacks. 1496 (2) The Data Snooping Process may set up wrong bindings if the 1497 clients do not reply to the detection probes. An attack will 1498 pass the duplicate detection if the client assigned the target 1499 address does not reply to the detection probes. The DHCP 1500 Leasequery procedure performed by the SAVI device just tells 1501 whether the address is assigned in the network or not. However, 1502 the SAVI device cannot determine whether the address is just 1503 assigned to the triggering attachment from the DHCP Leasequery 1504 Reply. 1506 12.3. Issues about Leaving Clients 1508 After a binding is set up, the corresponding client may leave its 1509 attachment point. It may leave temporarily due to link flapping, or 1510 permanently due to it moves to a new attachment point or just leaves 1511 the network. Considering the client may be back shortly, the binding 1512 should be kept, or else the legtimate traffic from the client will be 1513 blocked. However, if the client leaves permanently, it may be 1514 insecure to keep the binding. In case that the binding anchor is a 1515 property of the attachment point rather than the client, e.g., the 1516 switch port, an attacker which is attached to the attachment point of 1517 the leaving client can send spoofing packets with the addresses 1518 assigned to the client. Even if the binding anchor is a property of 1519 the client, it is a waste of binding resource to keep bindings for 1520 left clients. 1522 The following mechanism is designed to handle the leaving of client: 1524 (1) Whenever a client of Validating attribute leaves, a timer of 1525 OFFLINK_DELAY is set with the corresponding binding entries. 1527 (2) If receiving DAD Neighbor Solicitation/Gratuitous ARP request 1528 targeting at the address during OFFLINK_DELAY, the entries MAY 1529 be removed. 1531 (3) If the binding anchor turns on-link during OFFLINK_DELAY, turn 1532 off the timer. 1534 In this way, the bindings of a leaving client is kept for 1535 OFFLINK_DELAY. In case of link flapping, the client will not be 1536 blocked. If the client leaves permanently, the bindings will be 1537 removes after OFFLINK_DELAY. 1539 12.4. Duplicate Bindings of the Same Address 1541 The same address may be bound with multiple binding anchors, only if 1542 the binding setup processes are finished on each binding anchor 1543 successfully. This mechanism is designed in consideration that a 1544 client may move on the local link, and a client may have multiple 1545 attachments to a SAVI device. 1547 There are two security issues about such a design: 1549 Firstly, due to allowing one address bound with multiple binding 1550 anchors, the traceability of address is weakened. An address can be 1551 traced to multiple attachments. 1553 Secondly, in the local link movement scenario, the former binding may 1554 not be removed and it can be made use of by an attacker sharing the 1555 same binding anchor. For example, when switch port is used as 1556 binding anchor and the port is shared by an attacker and a client 1557 with a hub, the attacker can make use of the address assigned to the 1558 client after the client leaves. 1560 12.5. Compatibility with DNA (Detecting Network Attachment) 1562 DNA [rfc4436] [rfc6059] is designed to decrease the handover latency 1563 after re-attachment to the same network. DNA mainly relies on 1564 performing reachability test through sending unicast Neighbor 1565 Solicitation/Router Solicitation/ARP Request message to determine 1566 whether a previously configured address is still valid. Though DNA 1567 provides optimization for clients, there is not sufficient 1568 information for this mechanism to migrate the previous binding or 1569 establish a new binding. If a binding is set up only through 1570 snooping the reachability test message, the binding can be invalid. 1571 For example, an attacker can perform reachability test with address 1572 bound to another client. If binding is migrated to the attacker, the 1573 attacker can successful obtain the binding from the victim. Because 1574 this mechanism wouldn't set up a binding based on snooping the DNA 1575 procedure, it cannot achieve perfect compatibility with DNA. 1576 However, it only means the re-configuration of the interface is 1577 slowed but not prevented. Details are discussed as follows. 1579 In Simple DNAv6 [rfc6059], the probe is sent with the source address 1580 set to a link-local address, and such messages will not be discarded 1581 by the policy specified in section Section 8.2. If a client is re- 1582 attached to a previous network, the detection will be completed, and 1583 the address will be regarded as valid by the client. However, the 1584 candidate address is not contained in the probe. Thus, the binding 1585 cannot be recovered through snooping the probe. As the client will 1586 perform DHCP procedure at the same time, the binding will be 1587 recovered from the DHCP Snooping Process. The DHCP Request messages 1588 will not be filtered out by this solution as they have link-local 1589 source addresses. Before the DHCP procedure is completed, packets 1590 will be filtered out by the SAVI device. In another word, if this 1591 SAVI function is enabled, Simple DNAv6 will not help reduce the 1592 handover latency. If Data-Snooping attribute is configured on the 1593 new attachment of the client, the data triggered procedure may reduce 1594 the latency. 1596 In DNAv4 [rfc4436], the ARP probe will be discarded because unbound 1597 address is used as sender protocol address. As a result, the client 1598 will regard the address under detection is valid. However, the data 1599 traffic will be filtered. The DHCP Request message sent by the 1600 client will not be discarded, because the source IP address field 1601 should be all zero as required by [rfc2131]. Thus, if the address is 1602 still valid, the binding will be recovered from the DHCP Snooping 1603 Process. 1605 12.6. Bogus DHCP Server Threat 1607 DHCP-Trust attribute is designed to prevent attacks from bogus DHCP 1608 servers. However, the security is not strict because messages from 1609 the valid DHCP server and the bogus DHCP server may arrive at the 1610 SAVI device through the same attachment point. As a result, the SAVI 1611 device cannot distinguish valid messages from bogus messages. 1612 Because the bindings are set up primarily based on DHCP message from 1613 DHCP server, bogus DHCP servers can assign invalid addresses to 1614 clients and bindings for these addresses will be set up by the SAVI 1615 device. 1617 Thus, each valid DHCP server/relay MUST NOT share a binding anchor 1618 with a untrusted device. In case that a binding anchor is shared by 1619 a DHCP server/relay and an untrusted device, DHCP-Trust MUST NOT be 1620 configured on the corresponding attachment. For example, in 1621 Figure 1, if the SAVI device is a switch and the switch port is used 1622 as binding anchor, the attachment from Non-SAVI Device 1 to SAVI 1623 Device C cannot be configured with DHCP-Trust because the port is 1624 shared by DHCP server A and other clients which are untrusted. 1626 12.7. Authentication in DHCPv6 Leasequery 1628 As required in section 5 of RFC5007, DHCPv6 Leasequery 'Should' use 1629 IPsec-based authentication specified in the section 21.1 of RFC3315. 1630 However, with the deployment of this mechanism, there may be no need 1631 to enforce IPSec to perform DHCP Leasequery. 1633 Through containing the DHCP servers in the protection perimeter, the 1634 DHCP servers can be protected from spoofing based attacks. Then 1635 through checking the source IP address of Leasequery messages, the 1636 DHCP server can identify if the messages are from SAVI devices or 1637 not. For the SAVI devices, because the perimeter filters out bogus 1638 DHCP messages, they can trust the DHCP Leasequery responses. Thus, 1639 there is no need to enforce IPSec to validate the DHCP Leasequery 1640 messages in this mechanism. 1642 12.8. Binding Number Limitation 1644 A binding entry will cost a certain high-speed memory resource. In 1645 general, a SAVI device can only afford a quite limited number of 1646 binding entries. In order to prevent an attacker from overloading 1647 the resource of the SAVI device, binding entry limit is set on each 1648 attachment. The binding entry limit is the upper bound of binding 1649 number for each attachment with Validating attribute. No new binding 1650 should be set up after the limit has been reached. Besides, if a 1651 DHCP Reply assigns more addresses than the remaining binding entry 1652 quota of each client, the message will be discarded and no binding 1653 will be set up. 1655 12.9. Residual Threats 1657 As described in [savi-framework], this solution cannot strictly 1658 prevent spoofing. There are two scenarios in which spoofing can 1659 still happen: 1661 (1) The binding anchor is spoofable. If the binding anchor is 1662 spoofable, e.g., plain MAC address, an attacker can use forged 1663 binding anchor to send packet which will not be regarded as 1664 spoofing by SAVI device. Indeed, using binding anchor that can 1665 be easily spoofed is more serious than allowing IP spoofing 1666 traffic. For example, an attacker can use the binding anchor of 1667 another client to get a large number of addresses, and the SAVI 1668 device will refuse to set up new binding for the client whenever 1669 the binding number limitation has been reached. Thus, it is 1670 RECOMMENDED to use strong enough binding anchor, e.g., switch 1671 port, secure association in 802.11ae/af and 802.11i. 1673 (2) The binding anchor is shared by more than one clients. If the 1674 binding anchor is shared by more than one clients, the clients 1675 can spoof the addresses of each other. For example, if switch 1676 port is used as binding anchor a number of clients can attach to 1677 the same switch port of a SAVI device through a hub. The SAVI 1678 device cannot distinguish packets from different clients and 1679 thus the spoofing between them will not be detected. A number 1680 of the above security problems are caused by sharing binding 1681 anchor. Besides, if binding anchor is shared, TID spoofing 1682 based attack is possible. Thus, it is RECOMMENDED to use 1683 exclusive binding anchor. 1685 13. IANA Considerations 1687 This memo asks the IANA for no new parameters. 1689 Note to RFC Editor: This section will have served its purpose if it 1690 correctly tells IANA that no new assignments or registries are 1691 required, or if those assignments or registries are created during 1692 the RFC publication process. From the authors' perspective, it may 1693 therefore be removed upon publication as an RFC at the RFC Editor's 1694 discretion. 1696 14. Acknowledgment 1698 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 1699 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 1700 Davies, Barry Leiba and Alberto Garcia for careful review and 1701 valuation comments on the mechanism and text. 1703 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 1704 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 1705 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 1706 their valuable contributions. 1708 This document was generated using the xml2rfc tool. 1710 15. References 1712 15.1. Informative References 1714 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 1715 Internet draft (work in progress), November 2007. 1717 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 1718 Defeating Denial of Service Attacks which employ IP Source 1719 Address Spoofing", RFC 2827, BCP 38, May 2000. 1721 [rfc3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1722 (DHCP) Service for IPv6", RFC 3736, April 2004. 1724 15.2. Normative References 1726 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 1727 Requirement Levels", RFC 2119, BCP 14, Match 1997. 1729 [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", 1730 RFC 2131, March 1997. 1732 [rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1733 and M. Carney, "Dynamic Host Configuration Protocol for 1734 IPv6 (DHCPv6)", RFC 3315, July 2003. 1736 [rfc4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1737 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1739 [rfc4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1740 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1742 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1743 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1744 September 2007. 1746 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1747 Address Autoconfiguration", RFC 4862, September 2007. 1749 [rfc5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1750 "DHCPv6 Leasequery", RFC 5007, September 2007. 1752 [rfc5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1753 July 2008. 1755 [rfc6059] Krishnan, S. and G. Daley, "Simple Procedures for 1756 Detecting Network Attachment in IPv6", RFC 6059, 1757 November 2010. 1759 [rfc826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1760 converting network protocol addresses to 48.bit Ethernet 1761 address for transmission on Ethernet hardware", RFC 826, 1762 November 1982. 1764 [savi-fcfs] 1765 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1766 SAVI: First-Come First-Serve Source-Address Validation for 1767 Locally Assigned Addresses", RFC 6620, May 2012. 1769 [savi-framework] 1770 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1771 "Source Address Validation Improvement Framework", 1772 draft-ietf-savi-framework-06 (work in progress), 1773 December 2011. 1775 Appendix A. change log 1777 Main changes from 02 to 03: 1779 (1) Section 12, data trigger and counter trigger are combined to 1780 binding recovery process. The expression "one of MUST" is 1781 changed to "conditional MUST. Conditions related with the 1782 implementation are specified. Related constants are changed in 1783 section 26." 1785 Main changes from 03 to 04: 1787 (1) Section "Prefix configuration" is removed. 1789 (2) Section "Supplemental binding process" is modified in 1790 requirement level. 1792 (3) Sub-section 9.1 "Rationale" is added. 1794 (4) Section "Filtering during Detection" is removed. 1796 (5) Section "Handling layer 2 path change" is changed to 1797 "Consideration on Link layer routing complexity" 1799 (6) Section "Background and related protocols" is removed. 1801 Main changes from 04 to 05: 1803 (1) Trigger events are listed explicitly in section 8. 1805 (2) Detection and Live states are deleted, together with 1806 corresponding sections. 1808 Main change from 05 to 06: 1810 (1) Section 8.1: reference to section 20 is changed to section 15. 1812 Main changes from 06 to 07: 1814 (1) So many changes in this modification. We suggest to track 1815 http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht ml. 1816 Changes are made according to the comments. 1818 Main changes from 07 to 08,09: 1820 (1) The modifications are made according to the comments from Jean- 1821 Michel Combes. 1823 Main changes from 09 to 11: 1825 (1) DNA issues raised by Jari Arkko 1827 Main changes from 11 to 12: 1829 (1) The modifications are made according to the comments from Eric, 1830 http://www.ietf.org/mail-archive/web/savi/current/msg01778.html. 1832 Main changes from 12 to 13: 1834 (1) Main modifications are made based on comments from Elwyn Davies. 1835 http://www.ietf.org/mail-archive/web/gen-art/current/ 1836 msg07297.html. 1838 (2) Other modifications are made based on comments from Barry Leiba. 1840 Main changes from 13 to 14: 1842 (1) A symbol error is corrected. 1844 Main changes from 14 to 15: 1846 (1) In corresponding to "1. Does section 8 describe the mechanism 1847 that a SAVI device must perform if it has been unable to snoop 1848 the DHCP traffic between a host and a DHCP server? It appears 1849 that way in the document, but it would be good to explicitly 1850 state that early in the document when the discussion of 1851 topologies is being carried out. This becomes important when 1852 arbitrary topologies do not provide a means for the SAVI device 1853 to eavesdrop on the DHCP traffic." We specified in s7.1 p1 that 1854 arbitrary topologies may result in the regular process cannot 1855 set up correct bindings. This is also specified in the 1856 beginning of s8. 1858 (2) In corresponding to "2. Section 12 refers to the "tentative 1859 address multicast group". Do you really mean the Solicited Node 1860 Multicast address that is generated from the configured IPv6 1861 unicast address?" Yes. We have changed s12 to "the SAVI device 1862 MUST join the Solicited Node Multicast group of the source 1863 address of triggering IPv6 data packet whenever performing 1864 duplicate detection." 1866 (3) Other modifications are made according to the gen-art review. 1867 Refer to http://netarchlab.tsinghua.edu.cn/~yaog/review.txt. 1869 Main changes from 15 to 16: 1871 (1) Main modifications are made according to the second-round gen- 1872 art review. 1874 (2) Improve the quality of writing. 1876 Authors' Addresses 1878 Jun Bi 1879 Tsinghua University 1880 Network Research Center, Tsinghua University 1881 Beijing 100084 1882 China 1884 Email: junbi@tsinghua.edu.cn 1885 Jianping Wu 1886 Tsinghua University 1887 Computer Science, Tsinghua University 1888 Beijing 100084 1889 China 1891 Email: jianping@cernet.edu.cn 1893 Guang Yao 1894 Tsinghua University 1895 Network Research Center, Tsinghua University 1896 Beijing 100084 1897 China 1899 Email: yaoguang@cernet.edu.cn 1901 Fred Baker 1902 Cisco Systems 1903 Santa Barbara, CA 93117 1904 United States 1906 Email: fred@cisco.com