idnits 2.17.1 draft-ietf-savi-dhcp-17.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 (June 21, 2013) is 3962 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Bi 3 Internet-Draft J. Wu 4 Intended status: Standards Track G. Yao 5 Expires: December 23, 2013 Tsinghua Univ. 6 F. Baker 7 Cisco 8 June 21, 2013 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-17 13 Abstract 15 This document specifies the procedure for creating a binding between 16 a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI 17 (Source Address Validation Improvements) device. The bindings set up 18 by this procedure can be used to filter out packets with forged 19 source IP address in DHCP scenario. This mechanism is proposed as a 20 complement to ingress filtering to provide finer-grained source IP 21 address validation. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 23, 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . 11 79 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . . 11 80 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . . 11 81 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . . 12 83 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13 84 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 14 85 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 15 86 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 15 87 6.2. Binding States Description . . . . . . . . . . . . . . . . 15 88 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . . 16 90 6.3.2. Control Message Arriving Events . . . . . . . . . . . 16 91 6.4. State Machine of DHCP Packet Snooping . . . . . . . . . . 18 92 6.4.1. From NO_BIND to Other States . . . . . . . . . . . . . 18 93 6.4.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 18 94 6.4.1.2. Following Actions . . . . . . . . . . . . . . . . 18 95 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 20 96 6.4.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 21 97 6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 21 98 6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 22 99 6.4.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 22 100 6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 23 101 6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 23 102 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 25 103 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 26 105 7.3. Additional Binding States Description . . . . . . . . . . 26 106 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 26 107 7.5. State Machine of Binding Recovery Process . . . . . . . . 27 108 7.5.1. From NO_BIND to Other States . . . . . . . . . . . . . 27 109 7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 27 110 7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 27 111 7.5.2. From DETECTION to Other States . . . . . . . . . . . . 28 112 7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 28 113 7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 28 114 7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 29 115 7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 29 116 7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 29 117 7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 30 118 7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 30 119 7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 30 120 7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 30 121 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 32 122 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 32 123 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 32 124 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 33 125 9.1. Attribute Configuration Restoration . . . . . . . . . . . 33 126 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 33 127 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 34 128 11. MLD Consideration . . . . . . . . . . . . . . . . . . . . . . 34 129 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 130 12.1. Security Problem about Binding Setup Triggered by 131 EVE_DHCP_REPLY_NULL . . . . . . . . . . . . . . . . . . . 34 132 12.2. Security Problems about the Data Snooping Process . . . . 35 133 12.3. Issues about Leaving Clients . . . . . . . . . . . . . . . 36 134 12.4. Duplicate Bindings of the Same Address . . . . . . . . . . 36 135 12.5. Compatibility with DNA (Detecting Network Attachment) . . 37 136 12.6. Bogus DHCP Server Threat . . . . . . . . . . . . . . . . . 38 137 12.7. Authentication in DHCPv6 Leasequery . . . . . . . . . . . 38 138 12.8. Binding Number Limitation . . . . . . . . . . . . . . . . 38 139 12.9. Residual Threats . . . . . . . . . . . . . . . . . . . . . 39 140 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 141 14. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 40 142 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 143 15.1. Informative References . . . . . . . . . . . . . . . . . . 40 144 15.2. Normative References . . . . . . . . . . . . . . . . . . . 40 145 Appendix A. change log . . . . . . . . . . . . . . . . . . . . . 41 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 148 1. Introduction 150 This document describes a fine-grained source IP address validation 151 mechanism. This mechanism creates bindings between addresses 152 assigned to network attachment points by DHCP and suitable binding 153 anchors (refer to Section 3) of the attachments. Then the bindings 154 are used to identify and filter out packets originated from these 155 attachments with forged source IP addresses. In this way, this 156 mechanism can prevent hosts from spoofing IP addresses assigned to 157 the other attachment points. Compared with [BCP38], which provides 158 prefix granularity source IP address validity, this mechanism can 159 benefit the network with finer-grained validity and traceability of 160 source IP addresses. 162 This mechanism primarily performs DHCP snooping to set up bindings 163 between IP addresses assigned by DHCP and corresponding binding 164 anchors. This binding process is inspired by the work of [BA2007]. 165 Different from [BA2007], which designs specifications about DHCPv4, 166 this mechanism covers the DHCPv6 snooping process, the data snooping 167 process (refer to Section 7), as well as a number of other technical 168 details. Specially, the data snooping process is a data-triggered 169 binding setup procedure designed to avoid permanent block of valid 170 address in case that DHCP snooping is insufficient to set up all the 171 valid bindings. 173 This mechanism is designed for the stateful DHCP scenario [RFC2131], 174 [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this 175 document, because it has nothing to do with IP address allocation. A 176 client doing stateless DHCP acquires its IP address(es) using some 177 other mechanism. It is through that mechanism that SAVI must be 178 accomplished. Besides, this mechanism is primarily designed for pure 179 DHCP scenarios in which only addresses assigned through DHCP are 180 allowed. However, it does not block any link-local address. It is 181 because link-local addresses are used by DHCPv6 clients before the 182 clients are assigned a DHCPv6 address. Considering that link-local 183 addresses are generally self-generated, and the spoofing of link 184 local address may disturb this mechanism, it is RECOMMENDED to enable 185 a SAVI solution for link-local addresses, e.g., the SAVI-FCFS 186 [savi-fcfs]. 188 2. Requirements Language 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 3. Terminology 196 Binding anchor: A "binding anchor" is defined to be a link layer 197 property of network attachment in [savi-framework]. A list of proper 198 binding anchors can be found in Section 3.2 of [savi-framework]. 200 Attribute: A configurable property of each network attachment which 201 indicates the actions to be performed on packets received from the 202 network attachment. 204 DHCP address: An IP address assigned to an interface via DHCP. 206 SAVI-DHCP: The name of this SAVI function for DHCP address. 208 SAVI device: A network device on which this SAVI function is enabled. 210 Non-SAVI device: A network device on which this SAVI function is not 211 enabled. 213 DHCP Client-Server message: A message that is sent from a DHCP client 214 to a DHCP server or DHCP servers. Such a message is of one of the 215 following types: 217 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 219 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 220 [RFC2131] 222 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 223 [RFC2131] 225 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 226 [RFC2131] 228 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 229 [RFC2131] 231 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 233 o DHCPv4 Release: DHCPRELEASE [RFC2131] 235 o DHCPv4 Inform: DHCPINFORM [RFC2131] 237 o DHCPv6 Request: REQUEST [RFC3315] 239 o DHCPv6 Solicit: SOLICIT [RFC3315] 240 o DHCPv6 Confirm: CONFIRM [RFC3315] 242 o DHCPv6 Decline: DECLINE [RFC3315] 244 o DHCPv6 Release: RELEASE [RFC3315] 246 o DHCPv6 Rebind: REBIND [RFC3315] 248 o DHCPv6 Renew: RENEW [RFC3315] 250 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 252 DHCP Server-Client message: A message that is sent from a DHCP server 253 to a DHCP client. Such a message is of one of the following types: 255 o DHCPv4 ACK: DHCPACK [RFC2131] 257 o DHCPv4 NAK: DHCPNAK [RFC2131] 259 o DHCPv4 Offer: DHCPOFFER [RFC2131] 261 o DHCPv6 Reply: REPLY [RFC3315] 263 o DHCPv6 Advertise: ADVERTISE [RFC3315] 265 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 267 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 268 IPv6 [RFC3315]. 270 Binding entry: An 'permit' rule that defines a valid association 271 between an IP address and a binding anchor. 273 Binding State Table: The data structure that contains all the binding 274 entries. 276 Binding entry limit: The maximum number of binding entries that may 277 be associated with any one binding anchor. Limiting the number of 278 binding entries per binding anchor prevents a malicious or 279 malfunctioning node from overloading the binding table on a SAVI 280 device. 282 4. Deployment Scenario and Configuration 283 4.1. Elements and Scenario 285 A list of essential elements in a SAVI-DHCP deployment scenario is 286 given as follows: 288 (1) DHCP server 290 (2) DHCP client 292 (3) SAVI device 294 And there may be following optional elements in a SAVI-DHCP 295 deployment scenario: 297 (1) DHCP relay 299 (2) Non-SAVI device 301 Figure 1 shows a deployment scenario that contains these elements. 302 Note that a physical device can be multiple elements, e.g, a switch 303 can be both a SAVI device and a DHCP relay. In such cases, the links 304 are logic links rather than physical links. 306 +--------+ +------------+ 307 |DHCP |-----| Non-SAVI | 308 |Server A| | Device 1 | 309 +--------+ +-----|------+ 310 ......................|............................ 311 . | upstream link . 312 . Protection +---|------+ . 313 . Perimeter | SAVI | . 314 . | Device C| . 315 . +---|------+ . 316 . | . 317 . +----------+ +---|------+ +----------+ . 318 downstream . | SAVI | | Non SAVI| | SAVI | . 319 link +----.-| Device A|----| Device 3|-------| Device B| . 320 | . +----|--|--+ +----------+ +-|---|----+ . 321 | . | +----------+ ............ | | . 322 | '.............. | . . | | . 323 | | . | . +--------+ | . 324 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 325 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 326 | Device 2 | |A | . |Relay | . |B | . |Server B| . 327 +----------+ +------+ . +------+ . +------+ . +--------+ . 328 ............ ............... 330 Figure 1: SAVI-DHCP Scenario 332 4.2. Attribute 334 As illustrated in Figure 1, an attachment to a SAVI device can be 335 from either a DHCP client, or a DHCP relay/server, or a SAVI device, 336 or a non-SAVI device. Different actions are performed on traffic 337 originated from different elements. To distinguish different types 338 of attachments, an attachment property named 'attribute' is 339 configured on SAVI devices. This section specifies the attributes 340 used by SAVI-DHCP. 342 Before configuration, an attachment is with no attribute. An 343 attachment MAY be configured to have one or more compatible 344 attributes(refer to Section 4.2.6). The attributes of each 345 attachment MUST be configured before this SAVI-DHCP function is 346 enabled on the attachment. The procedure performed by SAVI devices 347 on traffic from each attachment is determined by the attribute(s) set 348 on the attachment. 350 Particularly, if an attachment has no attribute, no actions will be 351 performed by SAVI-DHCP on traffic from such attachments. This 352 prevents SAVI-DHCP from causing a break in the network when it is 353 turned on without any binding anchors configured. However, if a 354 binding anchor has no attributes, this means that the SAVI-DHCP-Trust 355 attribute is not present. Because of this, DHCP server messages from 356 that binding anchor will be discarded. This prevents a host from 357 connecting to an unconfigured binding anchor and acting as a DHCP 358 server. It is SUGGESTED to configure SAVI-DHCP-Trust on necessary 359 binding anchors before turning on the SAVI-DHCP function. 361 However, binding anchors associated with upstream links MAY have no 362 attribute after configuration. For example, in Figure 1, the 363 attachment from the Non-SAVI Device 1 to the SAVI Device B should be 364 configured with no attribute. It means 1) SAVI devices will neither 365 set up bindings for upstream hosts nor check traffic from upstream 366 hosts; 2) SAVI devices will not snoop DHCP messages from upstream 367 devices unless the DHCP-Trust attribute (refer to Section 4.2.2) is 368 set on the corresponding attachment. The reason that DHCP messages 369 from upstream devices are not trusted by default is discussed in 370 Section 12.6. 372 4.2.1. Trust Attribute 374 The "Trust Attribute" indicates the packets from the corresponding 375 attachment are completely trustable. 377 SAVI devices will not set up bindings for attachments with Trust 378 attribute; DHCP messages and data packets from such attachments with 379 this attribute will not be checked. If the DHCP Server-Client 380 messages from attachments with this attribute can trigger the state 381 transitions specified in Section 6 and Section 7, these messages will 382 be handled by the corresponding processes in Section 6 and Section 7. 384 This attribute is generally configured on the attachments from other 385 SAVI devices. For example, in Figure 1, the attachment from the SAVI 386 Device A to the SAVI Device B and the attachment from the SAVI Device 387 B to the SAVI Device A should be configured with this attribute. 388 Besides, it can be configured on attachments from Non-SAVI devices 389 only if the Non-SAVI devices will not introduce unchecked traffic 390 from DHCP clients. For example, the attachments from Non-SAVI device 391 3 to SAVI device A, SAVI device B and SAVI device C can be configured 392 with this attribute, only if Non-SAVI device 3 does not have 393 attachment from DHCP clients. 395 4.2.2. DHCP-Trust Attribute 397 The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages 398 from the corresponding attachment is trustable. 400 SAVI devices will forward DHCP Server-Client messages coming from the 401 attachments with this attribute. If the DHCP Server-Client messages 402 can trigger the state transitions, they will be handled by the 403 binding setup processes specified in Section 6 and Section 7. 405 This attribute is generally used on the direct attachments from the 406 trusted DHCP servers/relays. In Figure 1, the attachment from the 407 DHCP Relay to the SAVI Device B, and the attachment from the DHCP 408 Server B to the SAVI Device B should be configured with this 409 attribute. It is NOT RECOMMENDED to configure this attribute on the 410 indirect attachments from the non-neighboring DHCP servers/relays 411 unless the attachments do not introduce bogus DHCP Server-Client 412 messages. For example, in Figure 1, the attachment from the Non-SAVI 413 Device 1 to the SAVI Device C should not be configured with this 414 attribute. The related security problem is discussed in 415 Section 12.6. 417 4.2.3. DHCP-Snooping Attribute 419 The "DHCP-Snooping Attribute" indicates bindings will be set up based 420 on DHCP snooping. 422 DHCP Client-Server messages from attachments with this attribute will 423 trigger the setup of bindings. SAVI devices will set up bindings on 424 attachments with this attribute based on the DHCP snooping procedure 425 described in Section 6. 427 DHCP-Snooping attribute is configured on the attachments from DHCP 428 clients. This attribute can be also used on the attachments from 429 downstream Non-SAVI devices which are attached by DHCP clients. In 430 Figure 1, the attachment from the Client A to the SAVI Device A, the 431 attachment from the Client B to the SAVI Device B, and the attachment 432 from the Non-SAVI Device 2 to the SAVI Device A can be configured 433 with this attribute. 435 4.2.4. Data-Snooping Attribute 437 The "Data-Snooping Attribute" indicates data packets from the 438 corresponding attachment may trigger binding setup procedure. 440 Data packets from attachments with this attribute may trigger the 441 setup of bindings. SAVI devices will set up bindings on attachments 442 with this attribute based on the data-triggered process described in 443 Section 7. 445 If DHCP-Snooping attribute is configured on an attachment, the 446 bindings on this attachment are set up based on DHCP message 447 snooping. However, in some scenarios, a DHCP address may be used by 448 a DHCP client without DHCP address assignment procedure performed on 449 its current attachment. For such attachments, the Data-Snooping 450 process, which is described in Section 7, is necessary. This 451 attribute is configured on such attachments. The usage of this 452 attribute is further discussed in Section 7. 454 4.2.5. Validating Attribute 456 The "Validating Attribute" indicates packets from the corresponding 457 attachment will be checked based on binding entries on the 458 attachment. 460 Packets coming from attachments with this attribute will be checked 461 based on binding entries on the attachment as specified in Section 8. 463 Validating attribute is configured on the attachments from which the 464 data packets should be checked. For example, the DHCP clients. 466 4.2.6. Table of Mutual Exclusions 468 Different types of attributes may indicate mutually exclusive actions 469 on packet. Mutually exclusive attributes MUST NOT be set on the same 470 attachment. The compatibility of different attributes is listed in 471 Figure 2. Note that although Trust and DHCP-Trust are compatible, 472 there is no need to configure DHCP-Trust on an attachment with Trust 473 attribute. 475 +----------+----------+----------+----------+----------+----------+ 476 | | | | DHCP- | Data- | | 477 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 478 +----------+----------+----------+----------+----------+----------+ 479 | | | | mutually | mutually | mutually | 480 | Trust | - |compatible| exclusive| exclusive| exclusive| 481 +----------+----------+----------+----------+----------+----------+ 482 | | | | | | | 483 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 484 +----------+----------+----------+----------+----------+----------+ 485 |DHCP- |mutually | | | | | 486 |Snooping |exclusive |compatible| - |compatible|compatible| 487 +----------+----------+----------+----------+----------+----------+ 488 |Data- |mutually | | | | | 489 |Snooping |exclusive |compatible|compatible| - |compatible| 490 +----------+----------+----------+----------+----------+----------+ 491 | |mutually | | | | | 492 |Validating|exclusive |compatible|compatible|compatible| - | 493 +----------+----------+----------+----------+----------+----------+ 495 Figure 2: Table of Mutual Exclusions 497 4.3. Perimeter 499 4.3.1. SAVI-DHCP Perimeter Overview 501 SAVI devices can form a perimeter separating untrusted and trusted 502 areas, similarly to SAVI-FCFS (refer to Section 2.5 of [savi-fcfs]). 503 Each SAVI device need only establish bindings for a node if it is 504 connected to that node by a link that crosses the perimeter that 505 encloses the SAVI device. 507 The perimeter is primarily designed for scalability. This has two 508 implications. First, SAVI devices only need to establish bindings 509 for clients directly attached or indirectly attached through Non-SAVI 510 devices, rather than all the clients in the network. Second, each 511 SAVI device only need to check traffic from clients managed by it, 512 without checking all the traffic passing by. 514 Consider for example Figure 1. The protection perimeter is formed by 515 SAVI Device A and SAVI Device B. In this case, SAVI device B doesn't 516 create a binding for client A. SAVI device A doesn't create a binding 517 for client B. But the SAVI device B is still protected from spoofing 518 from client A and the SAVI device A is still protected from spoofing 519 from client B. 521 There is only one difference between the SAVI-DHCP protection 522 perimeter and SAVI-FCFS protection perimeter: SAVI-DHCP follows the 523 state announced in DHCP messages, so there is no need to distribute 524 state using NS/NA messages. 526 Particularly, SAVI-DHCP perimeter only contains trusted DHCP servers/ 527 relays inside. The SAVI devices only trust DHCP Server-Client 528 messages originated inside the perimeter. Because bogus DHCP servers 529 are out of the perimeter, the SAVI devices can be protected from 530 fabricated DHCP messages. Note that even if a DHCP server is valid, 531 it may be not contained in the perimeter. For example, in Figure 1, 532 DHCP server A is valid, but it is attached to a Non-SAVI device. The 533 Non-SAVI device may be attached by attackers which generate 534 fabricated DHCP messages. This binding based mechanism may not have 535 the ability to distinguish whether a message received from the 536 attachment of the Non-SAVI device 1 is from DHCP server A or the 537 attackers. If the DHCP server A is contained in the perimeter, the 538 Non-SAVI device 1 will also be contained in the perimter. However, 539 the Non-SAVI device 1 can introduce fabricated DHCP messages into the 540 perimeter. Thus, the DHCP server A cannot be contained in the 541 perimeter. In this case, the SAVI devices can set up bindings for 542 addresses assigned by DHCP server A through snooping the messages 543 relayed by trusted relay in the network. For example, the DHCP relay 544 may relay messages between DHCP server A and the clients in the 545 network, and the SAVI devices can snoop messages from the DHCP relay 546 which is inside the perimeter. The authentication mechanism enforced 547 between the DHCP relay and the DHCP server outside the perimeter can 548 compensate this binding based mechanism. 550 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 552 Through configuring attribute of each attachment properly, a 553 perimeter separating untrusted area and trusted area can be formed: 555 (1) Configure Validating attribute on the attachments of all the 556 DHCP clients. Configure DHCP-Snooping attribute on these 557 attachments. 559 (2) Configure Validating attribute on the attachments of downstream 560 Non-SAVI devices which are attached by DHCP clients. Configure 561 DHCP-Snooping attribute on these attachments. 563 (3) Configure Trust attribute on the attachments of other SAVI 564 devices. 566 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 567 have only attachments from SAVI devices or upstream devices, set 568 their attachments to SAVI devices with Trust attribute. 570 (5) Configure DHCP-Trust attribute on the direct attachments of DHCP 571 relays/servers. 573 In this way, attachments with Validating attribute (and generally 574 together with attachments of upstream devices) can form a perimeter 575 separating DHCP clients and trusted devices. Data packet check is 576 only performed on the perimeter. 578 5. Binding State Table (BST) 580 Binding State Table is used to contain the bindings between the IP 581 addresses assigned to the attachments and the corresponding binding 582 anchors of the attachments. Each entry of the table, i.e., binding 583 entry, has 5 fields: 585 o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer 586 property of the attachment. 588 o IP Address(Address): the IP address assigned to the attachment by 589 DHCP. 591 o State: the state of the binding. Possible values of this field 592 are listed in Section 6.2 and Section 7.3. 594 o Lifetime: the remaining seconds of the binding. The Lifetime 595 field counts down automatically. 597 o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of 598 the corresponding DHCP transaction. TID field is used to 599 associate DHCP Server-Client messages with corresponding binding 600 entries. 602 An instance of this table is shown in Figure 3. 604 +---------+----------+----------+-----------+-------+ 605 | Anchor | Address | State | Lifetime |TID | 606 +---------+----------+----------+-----------+-------+ 607 | A | IP_1 | BOUND | 65535 |TID_1 | 608 +---------+----------+----------+-----------+-------+ 609 | A | IP_2 | BOUND | 10000 |TID_2 | 610 +---------+----------+----------+-----------+-------+ 611 | B | IP_3 |INIT_BIND | 1 |TID_3 | 612 +---------+----------+----------+-----------+-------+ 614 Figure 3: Instance of BST 616 6. DHCP Snooping Process 618 This section specifies the process of setting up bindings based on 619 DHCP snooping, named DHCP Snooping Process. This process is 620 illustrated making use of a state machine. 622 6.1. Rationale 624 The rationale of the DHCP Snooping Process is that if a DHCP client 625 is legitimate to use a DHCP address, the DHCP address assignment 626 procedure which assigns the IP address to the client must have been 627 performed on the attachment of the client. This basis stands when 628 the SAVI device is always on the path(s) from the DHCP client to the 629 DHCP server(s)/relay(s). Without considering the movement of DHCP 630 clients, the SAVI device should be the cut node which separates the 631 DHCP clients and the remaining network containing the DHCP server(s)/ 632 relay(s). For most of the layer-2 networks whose topologies are 633 simple, it is possible to deploy this SAVI function at proper devices 634 to meet this requirement. 636 However, a deployment of this SAVI function may not meet the 637 requirement. Besides, the movement of DHCP clients may make bindings 638 are not set up on their new attachments. These exceptions and the 639 solutions are discussed in Section 7. 641 6.2. Binding States Description 643 Following binding states present in this process and the 644 corresponding state machine: 646 NO_BIND: The state before a binding has been set up. 648 INIT_BIND: A potential binding has been set up. 650 BOUND: The binding has been set up. 652 6.3. Events 654 This section describes events in this process and the corresponding 655 state machine. 657 6.3.1. Timer Expiration Event 659 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 661 6.3.2. Control Message Arriving Events 663 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 664 received. 666 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 668 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 670 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 671 received. 673 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 675 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 676 option is received. 678 EVE_DHCP_REPLY_REQUEST: A DHCPv4 ACK or a DHCPv6 Reply message is 679 received, and there is an entry in the BST whose TID field is the 680 same as the message. The DHCPv6 Reply message must be in response to 681 a DHCPv6 Request message, and the assignment is successful. (Note: A 682 DHCPv6 Reply may be a response to DHCPv6 Request, DHCPv6 Confirm, 683 DHCPv6 Renew, DHCPv6 Rebind, DHCPv6 Decline, DHCPv6 Release and 684 DHCPv6 Information-request. Through checking the Status Code option, 685 IA options and other related options in the Reply message, it is 686 possible to determine the purpose of the DHCPv6 Reply. An 687 implementation should refer to [RFC3315] to identify such messages. 688 The processing of the following six events should check the purpose 689 of the DHCP Reply similarly.) 691 EVE_DHCP_REPLY_REQUEST_NULL: A DHCPv4 ACK or a DHCPv6 Reply message 692 is received, and there is no entry in the BST whose TID field is the 693 same as the message. The DHCPv6 Reply message must be in response to 694 a DHCPv6 Request message, and the assignment is successful. 696 EVE_DHCP_REPLY_REBIND: A DHCPv4 ACK or a DHCPv6 Reply message is 697 received, and there is an entry in the BST whose TID field is the 698 same as the message. The DHCPv6 Reply message must be in response to 699 a DHCPv6 Rebind message. 701 EVE_DHCP_REPLY_REBIND_NULL: A DHCPv4 ACK or a DHCPv6 Reply message is 702 received, and there is no entry in the BST whose TID field is the 703 same as the message. The DHCPv6 Reply message must be in response to 704 a DHCPv6 Rebind message. 706 EVE_DHCP_REPLY_CONFIRM: A DHCPv4 ACK or a DHCPv6 Reply message is 707 received, and there is an entry in the BST whose TID field is the 708 same as the message. The DHCPv6 Reply message must be in response to 709 a DHCPv6 Confirm message. 711 EVE_DHCP_REPLY_RENEW: A DHCPv4 ACK or a DHCPv6 Reply message is 712 received, and there is an entry in the BST whose TID field is the 713 same as the message. The DHCPv6 Reply message must be in response to 714 a DHCPv6 Renew message. 716 EVE_DHCP_REPLY_RENEW_NULL: A DHCPv4 ACK or a DHCPv6 Reply message is 717 received, and there is no entry in the BST whose TID field is the 718 same as the message. The DHCPv6 Reply message must be in response to 719 a DHCPv6 Renew message. 721 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 722 received. 724 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 725 received. 727 EVE_DCHP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 728 section 4.3.3 of [RFC5007]) is received. 730 Moreover, only if a DHCP message can pass the following checks, the 731 corresponding event is regarded as a valid event: 733 o Attribute check: the DHCP Server-Client messages and 734 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 735 attribute; the DHCP Client-Server messages should be from 736 attachments with DHCP-Snooping attribute. 738 o Destination check: the DHCP Server-Client messages should be 739 destined to attachments with DHCP-Snooping attribute. 741 o Binding anchor check: the DHCP Client-Server messages which may 742 trigger modification or removal of an existing binding entry must 743 have matched binding anchor with the corresponding entry. 745 o TID check: the DHCP Server-Client/Client-Server messages must 746 have matched TID with the corresponding entry. 748 o Binding limitation check: the DHCP messages must not cause new 749 binding setup on an attachment whose binding entry limitation has 750 been reached. (refer to Section 12.8). 752 o Address check: the address of the DHCP messages should pass the 753 check specified in Section 8.2. 755 On receiving a DHCP message without triggering a valid event, the 756 state will not transit and actions will not be performed. 758 6.4. State Machine of DHCP Packet Snooping 760 This section specifies the transits of each state and the 761 corresponding actions. 763 6.4.1. From NO_BIND to Other States 765 6.4.1.1. Trigger Event 767 EVE_DHCP_REQUEST, EVE_DHCP_OPTION_RC, EVE_DHCP_CONFIRM, 768 EVE_DHCP_REBOOT, EVE_DHCP_REBIND, EVE_DHCP_RENEW, 769 EVE_DHCP_REPLY_NULL. 771 6.4.1.2. Following Actions 773 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC/ 774 EVE_DHCP_REBOOT: 776 The SAVI device MUST forward the message. 778 The SAVI device will generate an entry in the Binding State Table 779 (BST). The Binding anchor field is set to the binding anchor of the 780 attachment from which the message is received. The State field is 781 set to INIT_BIND. The Lifetime field is set to be 782 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 783 message. If the message is DHCPv4 Request or DHCPv4 Reboot, the 784 Address field can be set to the address to request, i.e., the 785 'requested IP address'. An example of the entry is illustrated in 786 Figure 4. 788 +---------+-------+---------+-----------------------+-------+ 789 | Anchor |Address| State | Lifetime |TID | 790 +---------+-------+---------+-----------------------+-------+ 791 | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 792 +---------+-------+---------+-----------------------+-------+ 794 Figure 4: Binding entry in BST on Request/Rapid Commit/Reboot 795 triggered initialization 797 If the triggering event is EVE_DHCP_CONFIRM/EVE_DHCP_REBIND/ 798 EVE_DHCP_RENEW: 800 If the message is DHCPv4 Rebind/Renew, the message MUST be forwarded. 801 In DHCPv6, a DHCP client may try to confirm or rebind or renew 802 multiple addresses in a message. In such case, the SAVI device MUST 803 check whether setting up corresponding bindings will make the binding 804 number limitation exceeded. If the limitation will be exceeded, the 805 message MUST be discarded and the following actions will not be 806 performed; or else the message MUST be forwarded. 808 The SAVI device will generate corresponding entries in the Binding 809 State Table (BST). The Binding anchor field is set to the binding 810 anchor of the attachment from which the message is received. The 811 State field is set to INIT_BIND. The Lifetime field is set to be 812 MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the 813 message. The Address field is set to the address to confirm/ 814 rebind(i.e., 'ciaddr' in DHCPv4 Rebind, IPv6 address in IA Address 815 options of DHCPv6 Confirm/Rebind). An example of the entries is 816 illustrated in Figure 5. 818 +---------+--------+---------+-----------------------+-------+ 819 | Anchor | Address| State | Lifetime |TID | 820 +---------+--------+---------+-----------------------+-------+ 821 | A | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 822 +---------+--------+---------+-----------------------+-------+ 823 | A | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 824 +---------+--------+---------+-----------------------+-------+ 826 Figure 5: Binding entry in BST on Confirm/Rebind/Renew triggered 827 initialization 829 If the triggering event is EVE_DHCP_REPLY_REQUEST_NULL/ 830 EVE_DHCP_REPLY_REBIND_NULL/EVE_DHCP_REPLY_RENEW_NULL: 832 If the message is DHCPv4 ACK, the message MUST be forwarded. For 833 DHCPv6, a DHCPv6 Reply message may assign multiple addresses to an 834 attachment. In such case, the SAVI device MUST check whether setting 835 up corresponding bindings will make the binding number limitation 836 exceeded. If the limitation will be exceeded, the message MUST be 837 discarded and the following actions will not be performed; or else 838 the message MUST be forwarded. 840 If the message is DHCPv4 ACK, the SAVI device MUST generate a 841 corresponding entry in the BST. 843 If the message is DHCPv6 Reply, the SAVI device MUST generate as many 844 new entries in the BST as the number of assign addresses(IPv6 845 addresses in all the IA Address options of the message). The Binding 846 anchor field is set to the binding anchor of the destined attachment. 847 The State field is set to be BOUND. The Lifetime field is set to the 848 sum of the lease time in Reply message and MAX_DHCP_RESPONSE_TIME. 849 The Address field is set to the assigned address (i.e., 'yiaddr' in 850 DHCPv4 ACK, IPv6 address in IA Address options of DHCPv6 Reply). 852 An example of the entries is illustrated in Figure 6. 854 This process is designed to handle the situation that the client 855 moves after sending a Request/Rebind/Renew message. Vulnerability in 856 this process is discussed in Section 12.1. 858 +---------+----------+-------+------------------------+-------+ 859 | Anchor | Address | State | Lifetime |TID | 860 +---------+----------+-------+------------------------+-------+ 861 | A | Addr1 | BOUND | Lease time 1 |TID | 862 | | | | +MAX_DHCP_RESPONSE_TIME| | 863 +---------+----------+-------+------------------------+-------+ 864 | A | Addr2 | BOUND | Lease time 2 |TID | 865 | | | | +MAX_DHCP_RESPONSE_TIME| | 866 +---------+----------+-------+------------------------+-------+ 868 Figure 6: Binding entry in BST on Reply triggered initialization 870 6.4.2. From INIT_BIND to Other States 871 6.4.2.1. Trigger Event 873 EVE_DHCP_REPLY_REQUEST, EVE_DHCP_REPLY_REBIND, 874 EVE_DHCP_REPLY_CONFIRM, EVE_ENTRY_EXPIRE. 876 6.4.2.2. Following Actions 878 If the trigger event is EVE_DHCP_REPLY_REQUEST/EVE_DHCP_REPLY_REBIND/ 879 EVE_DHCP_REPLY_RENEW: 881 If the message is DHCPv4 ACK, the message MUST be forwarded. In 882 DHCPv6, a DHCPv6 Reply message may assign multiple addresses to an 883 attachment. In such case, the SAVI device MUST check whether setting 884 up corresponding bindings will make the binding number limitation 885 exceeded. If the limitation will be exceeded, the message MUST be 886 discarded and the following actions will not be performed; or else 887 the message MUST be forwarded. 889 The Address field of the corresponding entry in the BST is set to the 890 address in the message(i.e., 'yiaddr' in DHCPv4 ACK, IPv6 address in 891 IA Address options of DHCPv6 Reply). The Lifetime field is set to 892 the sum of the lease time in Reply message and 893 MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. For 894 DHCPv6, if more than one IA Address options is found in the message, 895 corresponding new entries MUST be generated. 897 An example of the entries is illustrated in Figure 7. 899 +---------+----------+-------+------------------------+-------+ 900 | Anchor | Address | State | Lifetime |TID | 901 +---------+----------+-------+------------------------+-------+ 902 | A | Addr1 | BOUND |Lease time+ |TID | 903 | | | |MAX_DHCP_RESPONSE_TIME | | 904 +---------+----------+-------+------------------------+-------+ 905 | A | Addr2 | BOUND |Lease time+ |TID | 906 | | | |MAX_DHCP_RESPONSE_TIME | | 907 +---------+----------+-------+------------------------+-------+ 909 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 910 Request/Rebind/Renew 912 If the trigger event is EVE_DHCP_REPLY_CONFIRM: 914 The DHCP Reply message is in response to a Confirm message. If the 915 Status Code option of the message is not Success (refer to Section 916 24.4 of [RFC3315]), the message will be forwarded, but no following 917 actions will be performed. If the Status Code option of the message 918 is Success, the state of the corresponding entry is changed to BOUND. 919 Because [RFC3315] does not require lease time of addresses to be 920 contained in the Reply message, the SAVI device MUST send a 921 LEASEQUERY [RFC5007] message querying by IP address to 922 All_DHCP_Relay_Agents_and_Servers multicast address [RFC3315] or a 923 configured server address. The Lifetime of corresponding entries is 924 set to MAX_LEASEQUERY_DELAY. 926 An example of the entries is illustrated in Figure 8. 928 The related security problem about DHCPv6 LEASEQUERY is discussed in 929 Section 12.7. 931 +---------+----------+-------+------------------------+-------+ 932 | Anchor | Address | State | Lifetime |TID | 933 +---------+----------+-------+------------------------+-------+ 934 | A | Addr1 | BOUND | MAX_LEASEQUERY_DELAY |TID | 935 +---------+----------+-------+------------------------+-------+ 936 | A | Addr2 | BOUND | MAX_LEASEQUERY_DELAY |TID | 937 +---------+----------+-------+------------------------+-------+ 939 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to 940 Confirm 942 If the trigger event is EVE_ENTRY_EXPIRE: 944 The entry MUST be deleted from BST. 946 Note: If no DHCP Server-Client messages which assign addresses or 947 confirm addresses are received, corresponding entries will expire 948 automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4 949 NAK) are not specially processed. 951 6.4.3. From BOUND to Other States 953 6.4.3.1. Trigger Event 955 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 956 EVE_DHCP_REPLY_REQUEST, EVE_DHCP_REPLY_RENEW, EVE_DHCP_REPLY_REBIND, 957 EVE_DCHP_LEASEQUERY. 959 6.4.3.2. Following Actions 961 If the trigger event is EVE_ENTRY_EXPIRE: 963 Remove the corresponding entry in BST. 965 If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE: 967 Remove the corresponding entry in BST. The Release or Decline 968 message MUST be forwarded. 970 If the trigger event is EVE_DHCP_REPLY_REQUEST/EVE_DHCP_REPLY_RENEW/ 971 EVE_DHCP_REPLY_REBIND: 973 Set the Lifetime field of the corresponding entries to be the sum of 974 the new lease time and MAX_DHCP_RESPONSE_TIME. 976 If the trigger event is EVE_DCHP_LEASEQUERY: 978 Set the Lifetime field to the sum of the lease time in the 979 LEASEQUERY_REPLY message and MAX_DHCP_RESPONSE_TIME. 981 6.5. Table of State Machine 983 The main state transits are listed as follows. 985 State Event Action Next State 986 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 987 NO_BIND RPL_NULL Generate entry with lease BOUND 988 INIT_BIND RPL_RE Record lease time BOUND 989 INIT_BIND RPL_CF Send Leasequery BOUND 990 INIT_BIND Timeout Remove entry NO_BIND 991 BOUND RLS/DCL Remove entry NO_BIND 992 BOUND Timeout Remove entry NO_BIND 993 BOUND RPL_RE Set new lifetime BOUND 994 BOUND LQR Record lease time BOUND 996 Figure 9: Table of Transit 998 RQ: EVE_DHCP_REQUEST 1000 CF: EVE_DHCP_CONFIRM 1001 RC: EVE_DHCP_OPTION_RC 1003 RE: EVE_DHCP_REBIND/EVE_DHCP_RENEW/EVE_DHCP_REBOOT 1005 RPL_NULL: EVE_DHCP_REPLY_REQUEST_NULL/EVE_DHCP_REPLY_REBIND_NULL/ 1006 EVE_DHCP_REPLY_RENEW_NULL 1008 RPL_RE: EVE_DHCP_REPLY_REQUEST/EVE_DHCP_REPLY_REBIND/ 1009 EVE_DHCP_REPLY_RENEW 1011 RPL_CF: EVE_DHCP_REPLY_CONFIRM 1013 DCL: EVE_DHCP_DECLINE 1015 RLS: EVE_DHCP_RELEASE 1017 LQR: EVE_DCHP_LEASEQUERY 1019 Timeout: EVE_ENTRY_EXPIRE 1021 +-------------+ 1022 | | 1023 /---------| NO_BIND |<----------\ 1024 | ------>| |---------\ | 1025 | | +-------------+ | |EVE_DHCP_RELEASE 1026 EVE_DHCP_REQUEST | | EVE_DHCP_RENEW_NULL| |EVE_DHCP_DECLINE 1027 EVE_DHCP_CONFIRM | |TIMEOUT EVE_DHCP_REPLY_NULL| |TIMEOUT 1028 EVE_DHCP_OPTION_RC| | EVE_DHCP_REBIND_NULL| | 1029 EVE_DHCP_REBIND | | | | 1030 EVE_DHCP_RENEW | | EVE_DHCP_REPLY_RENEW | | 1031 EVE_DHCP_REBOOT | | EVE_DHCP_REPLY_REBIND | | 1032 v | EVE_DHCP_REPLY_REQUEST v | 1033 +-------------+ EVE_DHCP_REPLY_CONFIRM +------------+ 1034 | | | | 1035 | INIT_BIND ------------------------>| BOUND |<-\ 1036 | | | | | 1037 +-------------+ +------------+ | 1038 | | 1039 \--------/ 1040 EVE_DHCP_REPLY_RENEW 1041 EVE_LEASEQUERY_REPLY 1042 EVE_DHCP_REPLY_REBIND 1043 EVE_DHCP_REPLY_REQUEST 1045 Figure 10: Diagram of Transit 1047 7. Data Snooping Process 1049 7.1. Scenario 1051 The rationale of the DHCP Snooping Process specified in Section 6 is 1052 that if a DHCP client is legitimate to use a DHCP address, the 1053 corresponding DHCP address assignment procedure must have been 1054 finished on the attachment of the DHCP client. This basis stands 1055 when the SAVI device is always on the path(s) from the DHCP client to 1056 the DHCP server(s)/relay(s). However, there are two exceptions: 1058 o Multiple paths: there are more than one feasible layer-2 paths 1059 from the client to the DHCP server/relay, and the SAVI device is 1060 not on all of them. The client may get the address through one 1061 of the paths not passing by the SAVI device, but packets from the 1062 client can travel through the other paths passing by the SAVI 1063 device. Because the SAVI device does not snoop the DHCP 1064 assignment procedure, the DHCP snooping procedure will not set up 1065 the corresponding binding. 1067 o Dynamic path: there is only one feasible layer-2 path from the 1068 client to the DHCP server/relay, but the path is dynamic due to 1069 topology change or layer-2 path change. This situation also 1070 covers the local-link movement of clients without address 1071 confirm/re-configuration process. In such cases, the DHCP 1072 snooping process will not set up the corresponding binding. 1074 Data Snooping Process is designed to avoid permanently blocking 1075 legitimate traffic in case of these two exceptions. This process is 1076 performed on attachments with Data-Snooping attribute. Data packets 1077 without matched binding entry may trigger this process to set up 1078 bindings. 1080 Snooping data traffic will introduce considerable burden on the 1081 processor and ASIC-to-Processor bandwidth of SAVI devices. 1082 Considering the overhead of this process, the implementation of this 1083 process is a conditional SHOULD. This function SHOULD be implemented 1084 unless the implementation is known to be used in the scenarios 1085 without the above exceptions. For example, if the implementation is 1086 to be used in networks with tree topology and without host local-link 1087 movement, there is no need to implement this process in such 1088 scenarios. 1090 This process is not supposed to set up a binding whenever a data 1091 packet without matched binding entry is received. Instead, unmatched 1092 data packets trigger this process with a probability and generally a 1093 number of unmatched packets will be discarded before the binding is 1094 set up. 1096 7.2. Rationale 1098 This process makes use of duplication detection and DHCP Leasequery 1099 to set up bindings. If an address is not used by another client in 1100 the network, and the address has been assigned in the network, the 1101 address can be bound with the binding anchor of the attachment from 1102 which the unmatched packet is received. 1104 The security issues about this process is discussed is Section 12.2. 1106 7.3. Additional Binding States Description 1108 In addition to Section 6.2, new states used in this process are 1109 listed here: 1111 DETECTION: The address in the entry is under local duplication 1112 detection. 1114 RECOVERY: The SAVI device is querying the assignment and lease time 1115 of the address in the entry through DHCP Leasequery. 1117 7.4. Events 1119 Additional events in this process are described here. Also, if an 1120 event will trigger to set up a new binding entry, the binding entry 1121 limit on the binding anchor MUST NOT have not been reached. 1123 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1125 EVE_DATA_CONFLICT: ARP Response/Neighbor Advertisement(NA) message 1126 against an address in DETECTION state is received. 1128 EVE_DATA_LEASEQUERY: 1130 IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1131 is received. 1133 IPv6: A successful LEASEQUERY-REPLY is received. 1135 The triggering packet should pass the following checks to trigger a 1136 valid event: 1138 o Attribute check: the data packet should be from attachments with 1139 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1140 messages should be from attachments with DHCP-Snooping attribute. 1142 o Binding limitation check: the DHCP messages must not cause new 1143 binding setup on an attachment whose binding entry limitation has 1144 been reached. (refer to Section 12.8). 1146 o Address check: the address of the DHCP/ARP/NA messages should 1147 pass the check specified in Section 8.2. 1149 o Interval check: the interval between two successive 1150 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1151 smaller than DATA_SNOOPING_INTERVAL. 1153 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must 1154 have matched TID with the corresponding entry. 1156 7.5. State Machine of Binding Recovery Process 1158 Through using additional states, the state machine of this process 1159 doesn't conflict the regular process described in Section 6. Thus, 1160 it can be implemented separately without changing the state machine 1161 in Section 6. 1163 7.5.1. From NO_BIND to Other States 1165 7.5.1.1. Trigger Event 1167 EVE_DATA_UNMATCH. 1169 7.5.1.2. Following Actions 1171 Determine whether to process this event with a probability. The 1172 probability can be configured or calculated based on the state of the 1173 SAVI device. This probability should be low enough to mitigate the 1174 damage from DoS attack against this process. 1176 Create a new entry in the BST. Set the Binding Anchor field to the 1177 corresponding binding anchor of the attachment. Set the Address 1178 field to be source address of the packet. Set the State field to 1179 DETECTION. Set the Lifetime of the created entry to 2*DAD_TIMEOUT. 1181 Check if the address has a local conflict (it violates an address 1182 being used by another node): 1184 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1185 [RFC826]or a ARP probe [RFC5227] on the address; if there is no 1186 response message after DAD_TIMEOUT, send another ARP Request or 1187 ARP probe; 1189 (2) IPv6 address: perform Duplicate Address Detection (DAD) 1190 [RFC4862] on the address; if there is no response message after 1191 DAD_TIMEOUT, perform another DAD procedure. 1193 Because the delivery of detection message is unreliable, the 1194 detection message is of a certain possibility of not reaching the 1195 targeting node. If the targeting node doesn't get the detection 1196 message, the address may be bound with a wrong binding anchor in the 1197 further stages. This fault may introduce attack against this 1198 mechanism. Thus, the detection is performed again if there is no 1199 response after the first detection. 1201 The messages MUST NOT be sent to the attachment from which the 1202 triggering packet is received. 1204 The packet which triggers this event SHOULD be discarded. 1206 An example of the entry is illustrated in Figure 11. 1208 +---------+-------+---------+-----------------------+-------+ 1209 | Anchor |Address| State | Lifetime |TID | 1210 +---------+-------+---------+-----------------------+-------+ 1211 | A | Addr1 |DETECTION|2*DAD_TIMEOUT | | 1212 +---------+-------+---------+-----------------------+-------+ 1214 Figure 11: Binding entry in BST on data triggered initialization 1216 7.5.2. From DETECTION to Other States 1218 7.5.2.1. Trigger Event 1220 EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT. 1222 7.5.2.2. Following Actions 1224 If the trigger event is EVE_ENTRY_EXPIRE: 1226 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1227 by IP address to all DHCPv4 servers with IP Address Lease Time 1228 option (option 51). The server addresses can be found through 1229 DHCPv4 Discovery or from configuration. Change the state of the 1230 corresponding entry to RECOVERY. Change the lifetime of the 1231 entry to be MAX_LEASEQUERY_DELAY. 1233 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1234 address to All_DHCP_Relay_Agents_and_Servers multicast address 1235 or a configured server address. 1237 Change the state of the corresponding entry to RECOVERY. Change the 1238 lifetime of the entry to be MAX_LEASEQUERY_DELAY. The TID field is 1239 set to the TID used in the Leasequery message. 1241 An example of the entry is illustrated in Figure 12. 1243 +---------+-------+---------+-----------------------+-------+ 1244 | Anchor |Address| State | Lifetime |TID | 1245 +---------+-------+---------+-----------------------+-------+ 1246 | A | Addr1 |RECOVERY |MAX_LEASEQUERY_DELAY |TID | 1247 +---------+-------+---------+-----------------------+-------+ 1249 Figure 12: Binding entry in BST on Lease Query 1251 If the trigger event is EVE_DATA_CONFLICT: 1253 Remove the entry. 1255 7.5.3. From RECOVERY to Other States 1257 7.5.3.1. Trigger Event 1259 EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY. 1261 7.5.3.2. Following Actions 1263 If the trigger event is EVE_DATA_LEASEQUERY: 1265 (1) IPv4 address: Check if the 'chaddr' field (hardware address) of 1266 the DHCPLEASEACTIVE message matches the hardware address of the 1267 triggering message. If the two addresses do not match, the 1268 following actions will not be performed. Change the state of 1269 the corresponding binding to BOUND. Set life time to the sum of 1270 the value encoded in IP Address Lease Time option of the 1271 DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Erase the 1272 TID field. 1274 (2) IPv6 address: Change the state of the corresponding binding to 1275 BOUND. Set the lifetime to the sum of the valid lifetime 1276 extracted from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY 1277 message and MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1279 If multiple addresses are specified in the LEASEQUERY-REPLY message, 1280 new entries MUST also be created correspondingly on the same binding 1281 anchor. 1283 If the trigger event is EVE_ENTRY_EXPIRE: 1285 Remove the entry. 1287 7.5.4. After BOUND 1289 Note that the TID field contains no value after the binding state 1290 changes to BOUND. The TID field is recovered from snooping DHCP 1291 Renew/Rebind messages. Because TID is used to associate binding 1292 entries with messages from DHCP servers, it must be recovered; or 1293 else a number of state transits of this mechanism will be not 1294 executed normally. 1296 7.5.4.1. Trigger Event 1298 EVE_DHCP_RENEW/EVE_DHCP_REBIND. 1300 7.5.4.2. Following Action 1302 Set the TID field of the corresponding entry to the TID in the 1303 triggering message. 1305 7.6. Table of State Machine 1307 The main state transits are listed as follows. 1309 State Event Action Next State 1310 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1311 DETECTION Timeout Send Leasequery RECOVERY 1312 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1313 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND 1314 RECOVERY Timeout Remove entry NO_BIND 1315 BOUND RENEW/REBIND Record TID BOUND 1317 Figure 13: Table of Transit 1319 RENEW: EVE_DHCP_RENEW 1321 REBIND: EVE_DHCP_REBIND 1323 Timeout: EVE_ENTRY_EXPIRE 1325 +-------------+ 1326 | | 1327 /---------| NO_BIND |<----------\ 1328 | ------>| | | 1329 | | +-------------+ | 1330 EVE_DATA_UNMATCH | |EVE_DATA_CONFLICT | 1331 | | |TIMEOUT 1332 | | | 1333 | | | 1334 | | | 1335 | | | 1336 v | | 1337 +-------------+ TIMEOUT +------------+ 1338 | | | | 1339 | DETECTION ------------------------>| RECOVERY | 1340 | | | | 1341 +-------------+ +------------+ 1342 EVE_DATA_LEASEQUERY| 1343 /----------\ | 1344 EVE_DHCP_RENEW| | | 1345 EVE_DHCP_REBIND| +-----v-------+ | 1346 | | | | 1347 \----| BOUND |<----------/ 1348 | | 1349 +-------------+ 1351 Figure 14: Diagram of Transit 1353 8. Filtering Specification 1355 This section specifies how to use bindings to filter out spoofing 1356 packets. 1358 Filtering policies are different for data packet and control packet. 1359 DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] messages that 1360 may cause state transit are classified into control packet. Neighbor 1361 Advertisement (NA) and ARP Response are also included in control 1362 packet because the Target Address of NA and ARP Response should be 1363 checked to prevent spoofing. All other packets are considered to be 1364 data packets. 1366 8.1. Data Packet Filtering 1368 Data packets from attachment with attribute Validating MUST be 1369 checked. 1371 Packet whose source IP address is a link-local address SHOULD be 1372 forwarded. 1374 If the source IP address of a packet is not a link-local address, but 1375 there is not a matched entry in BST with state BOUND, this packet 1376 MUST be discarded. However, the packet may trigger Data Snooping 1377 Process if Data-Snooping attribute is set on the attachment. 1379 The SAVI device MAY record any violation. 1381 8.2. Control Packet Filtering 1383 For attachments with Validating attribute: 1385 Discard DHCPv4 Request message whose source IP address is neither all 1386 zeros nor a bound address in BST. 1388 Discard DHCPv6 Request message whose source IP address is neither a 1389 link-local address nor bound with the corresponding binding anchor in 1390 BST. 1392 Discard NDP messages whose source IP address is neither a link-local 1393 address nor bound with the corresponding binding anchor. In 1394 addition, discard NA message whose target address is neither a link- 1395 local address nor bound with the corresponding binding anchor. 1397 Discard ARP messages whose protocol is IP and sender protocol address 1398 is neither all zeros address nor bound with the corresponding binding 1399 anchor. In addition, discard ARP Reply messages whose target address 1400 is not bound with the corresponding binding anchor. 1402 For attachments with other attributes: 1404 Discard DHCP server/relay type message not from attachments with the 1405 DHCP-Trust attribute or Trust attribute. 1407 The SAVI device MAY record any violation. 1409 For attachments with no attribute: 1411 No action will be performed on traffic from such attachments. 1413 9. State Restoration 1415 If a SAVI device reboots, the information kept in volatile memory 1416 will be lost. This section specifies the restoration of attribute 1417 configuration and BST. 1419 9.1. Attribute Configuration Restoration 1421 The lost of attribute configuration will not break the network: no 1422 action will be performed on traffic from attachments with no 1423 attribute. However, the lost of attribute configuration makes this 1424 SAVI function unable to work. 1426 To avoid the loss of binding anchor attribute configuration, the 1427 configuration MUST be able to be stored in non-volatile storage. 1428 After the reboot of SAVI device, if the configuration of binding 1429 anchor attribute can be found in non-volatile storage, the 1430 configuration MUST be used. 1432 9.2. Binding State Restoration 1434 The loss of binding state will cause the SAVI devices discard 1435 legitimate traffic. Purely using the Data Snooping Process to 1436 recover a large number of bindings is of heavy overhead and 1437 considerable delay. Thus, to recover bindings from non-volatile 1438 storage, as specified below, is RECOMMENDED. 1440 Binding entries MAY be saved into non-volatile storage whenever a new 1441 binding entry changes to BOUND state. If a binding with BOUND state 1442 is removed, the saved entry MUST be removed correspondingly. 1444 Immediately after reboot, the SAVI device SHOULD restore binding 1445 states from the non-volatile storage. The system time of save 1446 process MUST be stored. After rebooting, the SAVI device MUST check 1447 whether each entry has been obsolete through comparing the saved 1448 lifetime and the difference between the current system time and saved 1449 system time. 1451 10. Constants 1453 MAX_DHCP_RESPONSE_TIME 120s 1455 DATA_SNOOPING_INTERVAL 60s and configurable 1457 MAX_LEASEQUERY_DELAY 10s 1459 OFFLINK_DELAY 30s 1461 DAD_TIMEOUT 0.5s 1463 11. MLD Consideration 1465 To perform the duplicate detection in Data Snooping Process 1466 Section 7, the SAVI device MUST join the Solicited Node Multicast 1467 group of the source address of triggering IPv6 data packet whenever 1468 performing duplicate detection. 1470 12. Security Considerations 1472 12.1. Security Problem about Binding Setup Triggered by 1473 EVE_DHCP_REPLY_NULL 1475 Whenever the triggering event is EVE_DHCP_REPLY_NULL(EVE_DHCP_REPLY_R 1476 EQUEST_NULL/EVE_DHCP_REPLY_REBIND_NULL/EVE_DHCP_REPLY_RENEW_NULL), 1477 the SAVI device will try to bind the assigned address with the 1478 attachment whose link layer address is the destination link layer 1479 address of the message. However, the assigned address could be bound 1480 with a wrong attachment if an attacker can pollute the mapping from 1481 the link layer address to attachment in the SAVI device. 1483 For example, the SAVI device is a switch and switch port is used as 1484 binding anchor. When the SAVI device receives a DHCP Reply with 1485 assigned address IP_A and destination link layer address MAC_A, it 1486 will check its MAC-to-port table to find the right port. But the 1487 MAC-to-port table might be polluted. For example, the requester with 1488 MAC_A is attached to Port_A, but an attacker attached to Port_B 1489 announces it has MAC_A. If there is no security mechanism used to 1490 protect MAC addresses, the SAVI device can bind MAC_A with Port_B. 1491 Then the SAVI device will find MAC_A is at Port_B from the polluted 1492 MAC-to-port table and it will bind IP_A with Port_B. 1494 Protection from this attack can be ensured by making sure that one of 1495 the following conditions is satisfied: 1497 (1) DHCP Option 82 is used to keep binding anchor in DHCP Request 1498 and Reply. DHCP Option 82 can be used to keep the circuit 1499 information of the client and returned by the DHCP server. 1500 Thus, the binding anchor can be determined from the circuit 1501 information in the Option. It can be used whenever an 1502 implementation doesn't want to create an entry on receiving DHCP 1503 Request message. 1505 (2) MAC address is hard to spoof (e.g., 802.11i, 802.1ae/af). 1507 (3) The mapping table from MAC to binding anchor is secure. For 1508 example, whenever switch port is used as binding anchor, some 1509 security mechanism is used to ensure the mapping from MAC to 1510 switch port is secure. 1512 Specially, if the binding anchor is just link layer address, there is 1513 no such security problem due to there is no need to map link layer 1514 address to binding anchor. 1516 It is RECOMMENDED to implement/enable one of the mechanisms in the 1517 SAVI device. 1519 12.2. Security Problems about the Data Snooping Process 1521 There are two security problems about the Data Snooping Process 1522 Section 7: 1524 (1) The Data Snooping Process is costly, but an attacker can trigger 1525 it simply through sending a number of data packets. To avoid 1526 Denial of Services attack against the SAVI device itself, the 1527 Data Snooping Process MUST be rate limited. A constant 1528 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1529 Data Snooping Processes on one attachment MUST have a minimum 1530 interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be 1531 configured prudently to avoid Denial of Service attacks. 1533 (2) The Data Snooping Process may set up wrong bindings if the 1534 clients do not reply to the detection probes. An attack will 1535 pass the duplicate detection if the client assigned the target 1536 address does not reply to the detection probes. The DHCP 1537 Leasequery procedure performed by the SAVI device just tells 1538 whether the address is assigned in the network or not. However, 1539 the SAVI device cannot determine whether the address is just 1540 assigned to the triggering attachment from the DHCP Leasequery 1541 Reply. 1543 12.3. Issues about Leaving Clients 1545 After a binding is set up, the corresponding client may leave its 1546 attachment point. It may leave temporarily due to link flapping, or 1547 permanently due to it moves to a new attachment point or just leaves 1548 the network. Considering the client may be back shortly, the binding 1549 should be kept, or else the legtimate traffic from the client will be 1550 blocked. However, if the client leaves permanently, it may be 1551 insecure to keep the binding. In case that the binding anchor is a 1552 property of the attachment point rather than the client, e.g., the 1553 switch port, an attacker which is attached to the attachment point of 1554 the leaving client can send spoofing packets with the addresses 1555 assigned to the client. Even if the binding anchor is a property of 1556 the client, it is a waste of binding resource to keep bindings for 1557 left clients. 1559 The following mechanism is designed to handle the leaving of client: 1561 (1) Whenever a client of Validating attribute leaves, a timer of 1562 OFFLINK_DELAY is set with the corresponding binding entries. 1564 (2) If receiving DAD Neighbor Solicitation/Gratuitous ARP request 1565 targeting at the address during OFFLINK_DELAY, the entries MAY 1566 be removed. 1568 (3) If the binding anchor turns on-link during OFFLINK_DELAY, turn 1569 off the timer. 1571 In this way, the bindings of a leaving client is kept for 1572 OFFLINK_DELAY. In case of link flapping, the client will not be 1573 blocked. If the client leaves permanently, the bindings will be 1574 removes after OFFLINK_DELAY. 1576 12.4. Duplicate Bindings of the Same Address 1578 The same address may be bound with multiple binding anchors, only if 1579 the binding setup processes are finished on each binding anchor 1580 successfully. This mechanism is designed in consideration that a 1581 client may move on the local link, and a client may have multiple 1582 attachments to a SAVI device. 1584 There are two security issues about such a design: 1586 Firstly, due to allowing one address bound with multiple binding 1587 anchors, the traceability of address is weakened. An address can be 1588 traced to multiple attachments. 1590 Secondly, in the local link movement scenario, the former binding may 1591 not be removed and it can be made use of by an attacker sharing the 1592 same binding anchor. For example, when switch port is used as 1593 binding anchor and the port is shared by an attacker and a client 1594 with a hub, the attacker can make use of the address assigned to the 1595 client after the client leaves. 1597 12.5. Compatibility with DNA (Detecting Network Attachment) 1599 DNA [RFC4436] [RFC6059] is designed to decrease the handover latency 1600 after re-attachment to the same network. DNA mainly relies on 1601 performing reachability test through sending unicast Neighbor 1602 Solicitation/Router Solicitation/ARP Request message to determine 1603 whether a previously configured address is still valid. Though DNA 1604 provides optimization for clients, there is not sufficient 1605 information for this mechanism to migrate the previous binding or 1606 establish a new binding. If a binding is set up only through 1607 snooping the reachability test message, the binding can be invalid. 1608 For example, an attacker can perform reachability test with address 1609 bound to another client. If binding is migrated to the attacker, the 1610 attacker can successful obtain the binding from the victim. Because 1611 this mechanism wouldn't set up a binding based on snooping the DNA 1612 procedure, it cannot achieve perfect compatibility with DNA. 1613 However, it only means the re-configuration of the interface is 1614 slowed but not prevented. Details are discussed as follows. 1616 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1617 set to a link-local address, and such messages will not be discarded 1618 by the policy specified in section Section 8.2. If a client is re- 1619 attached to a previous network, the detection will be completed, and 1620 the address will be regarded as valid by the client. However, the 1621 candidate address is not contained in the probe. Thus, the binding 1622 cannot be recovered through snooping the probe. As the client will 1623 perform DHCP procedure at the same time, the binding will be 1624 recovered from the DHCP Snooping Process. The DHCP Request messages 1625 will not be filtered out by this solution as they have link-local 1626 source addresses. Before the DHCP procedure is completed, packets 1627 will be filtered out by the SAVI device. In another word, if this 1628 SAVI function is enabled, Simple DNAv6 will not help reduce the 1629 handover latency. If Data-Snooping attribute is configured on the 1630 new attachment of the client, the data triggered procedure may reduce 1631 the latency. 1633 In DNAv4 [RFC4436], the ARP probe will be discarded because unbound 1634 address is used as sender protocol address. As a result, the client 1635 will regard the address under detection is valid. However, the data 1636 traffic will be filtered. The DHCP Request message sent by the 1637 client will not be discarded, because the source IP address field 1638 should be all zero as required by [RFC2131]. Thus, if the address is 1639 still valid, the binding will be recovered from the DHCP Snooping 1640 Process. 1642 12.6. Bogus DHCP Server Threat 1644 DHCP-Trust attribute is designed to prevent attacks from bogus DHCP 1645 servers. However, the security is not strict because messages from 1646 the valid DHCP server and the bogus DHCP server may arrive at the 1647 SAVI device through the same attachment point. As a result, the SAVI 1648 device cannot distinguish valid messages from bogus messages. 1649 Because the bindings are set up primarily based on DHCP message from 1650 DHCP server, bogus DHCP servers can assign invalid addresses to 1651 clients and bindings for these addresses will be set up by the SAVI 1652 device. 1654 Thus, each valid DHCP server/relay MUST NOT share a binding anchor 1655 with a untrusted device. In case that a binding anchor is shared by 1656 a DHCP server/relay and an untrusted device, DHCP-Trust MUST NOT be 1657 configured on the corresponding attachment. For example, in 1658 Figure 1, if the SAVI device is a switch and the switch port is used 1659 as binding anchor, the attachment from Non-SAVI Device 1 to SAVI 1660 Device C cannot be configured with DHCP-Trust because the port is 1661 shared by DHCP server A and other clients which are untrusted. 1663 12.7. Authentication in DHCPv6 Leasequery 1665 As required in section 5 of RFC5007, DHCPv6 Leasequery 'Should' use 1666 IPsec-based authentication specified in the section 21.1 of RFC3315. 1667 However, with the deployment of this mechanism, there may be no need 1668 to enforce IPSec to perform DHCP Leasequery. 1670 Through containing the DHCP servers in the protection perimeter, the 1671 DHCP servers can be protected from spoofing based attacks. Then 1672 through checking the source IP address of Leasequery messages, the 1673 DHCP server can identify if the messages are from SAVI devices or 1674 not. For the SAVI devices, because the perimeter filters out bogus 1675 DHCP messages, they can trust the DHCP Leasequery responses. Thus, 1676 there is no need to enforce IPSec to validate the DHCP Leasequery 1677 messages in this mechanism. 1679 12.8. Binding Number Limitation 1681 A binding entry will cost a certain high-speed memory resource. In 1682 general, a SAVI device can only afford a quite limited number of 1683 binding entries. In order to prevent an attacker from overloading 1684 the resource of the SAVI device, binding entry limit is set on each 1685 attachment. The binding entry limit is the upper bound of binding 1686 number for each attachment with Validating attribute. No new binding 1687 should be set up after the limit has been reached. Besides, if a 1688 DHCP Reply assigns more addresses than the remaining binding entry 1689 quota of each client, the message will be discarded and no binding 1690 will be set up. 1692 12.9. Residual Threats 1694 As described in [savi-framework], this solution cannot strictly 1695 prevent spoofing. There are two scenarios in which spoofing can 1696 still happen: 1698 (1) The binding anchor is spoofable. If the binding anchor is 1699 spoofable, e.g., plain MAC address, an attacker can use forged 1700 binding anchor to send packet which will not be regarded as 1701 spoofing by SAVI device. Indeed, using binding anchor that can 1702 be easily spoofed is more serious than allowing IP spoofing 1703 traffic. For example, an attacker can use the binding anchor of 1704 another client to get a large number of addresses, and the SAVI 1705 device will refuse to set up new binding for the client whenever 1706 the binding number limitation has been reached. Thus, it is 1707 RECOMMENDED to use strong enough binding anchor, e.g., switch 1708 port, secure association in 802.11ae/af and 802.11i. 1710 (2) The binding anchor is shared by more than one clients. If the 1711 binding anchor is shared by more than one clients, the clients 1712 can spoof the addresses of each other. For example, if switch 1713 port is used as binding anchor a number of clients can attach to 1714 the same switch port of a SAVI device through a hub. The SAVI 1715 device cannot distinguish packets from different clients and 1716 thus the spoofing between them will not be detected. A number 1717 of the above security problems are caused by sharing binding 1718 anchor. Besides, if binding anchor is shared, TID spoofing 1719 based attack is possible. Thus, it is RECOMMENDED to use 1720 exclusive binding anchor. 1722 13. IANA Considerations 1724 This memo asks the IANA for no new parameters. 1726 Note to RFC Editor: This section will have served its purpose if it 1727 correctly tells IANA that no new assignments or registries are 1728 required, or if those assignments or registries are created during 1729 the RFC publication process. From the authors' perspective, it may 1730 therefore be removed upon publication as an RFC at the RFC Editor's 1731 discretion. 1733 14. Acknowledgment 1735 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 1736 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 1737 Davies, Barry Leiba, Ted Lemon and Alberto Garcia for careful review 1738 and valuation comments on the mechanism and text. 1740 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 1741 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 1742 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 1743 their valuable contributions. 1745 This document was generated using the xml2rfc tool. 1747 15. References 1749 15.1. Informative References 1751 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 1752 Internet draft (work in progress), November 2007. 1754 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 1755 Defeating Denial of Service Attacks which employ IP Source 1756 Address Spoofing", RFC 2827, BCP 38, May 2000. 1758 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1759 (DHCP) Service for IPv6", RFC 3736, April 2004. 1761 15.2. Normative References 1763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1764 Requirement Levels", RFC 2119, BCP 14, Match 1997. 1766 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1767 RFC 2131, March 1997. 1769 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1770 and M. Carney, "Dynamic Host Configuration Protocol for 1771 IPv6 (DHCPv6)", RFC 3315, July 2003. 1773 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1774 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1776 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1777 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1779 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1780 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1781 September 2007. 1783 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1784 Address Autoconfiguration", RFC 4862, September 2007. 1786 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1787 "DHCPv6 Leasequery", RFC 5007, September 2007. 1789 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1790 July 2008. 1792 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1793 Detecting Network Attachment in IPv6", RFC 6059, 1794 November 2010. 1796 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1797 converting network protocol addresses to 48.bit Ethernet 1798 address for transmission on Ethernet hardware", RFC 826, 1799 November 1982. 1801 [savi-fcfs] 1802 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1803 SAVI: First-Come First-Serve Source-Address Validation for 1804 Locally Assigned Addresses", RFC 6620, May 2012. 1806 [savi-framework] 1807 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1808 "Source Address Validation Improvement Framework", 1809 draft-ietf-savi-framework-06 (work in progress), 1810 December 2011. 1812 Appendix A. change log 1814 Main changes from 02 to 03: 1816 (1) Section 12, data trigger and counter trigger are combined to 1817 binding recovery process. The expression "one of MUST" is 1818 changed to "conditional MUST. Conditions related with the 1819 implementation are specified. Related constants are changed in 1820 section 26." 1822 Main changes from 03 to 04: 1824 (1) Section "Prefix configuration" is removed. 1826 (2) Section "Supplemental binding process" is modified in 1827 requirement level. 1829 (3) Sub-section 9.1 "Rationale" is added. 1831 (4) Section "Filtering during Detection" is removed. 1833 (5) Section "Handling layer 2 path change" is changed to 1834 "Consideration on Link layer routing complexity" 1836 (6) Section "Background and related protocols" is removed. 1838 Main changes from 04 to 05: 1840 (1) Trigger events are listed explicitly in section 8. 1842 (2) Detection and Live states are deleted, together with 1843 corresponding sections. 1845 Main change from 05 to 06: 1847 (1) Section 8.1: reference to section 20 is changed to section 15. 1849 Main changes from 06 to 07: 1851 (1) So many changes in this modification. We suggest to track 1852 http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht ml. 1853 Changes are made according to the comments. 1855 Main changes from 07 to 08,09: 1857 (1) The modifications are made according to the comments from Jean- 1858 Michel Combes. 1860 Main changes from 09 to 11: 1862 (1) DNA issues raised by Jari Arkko 1864 Main changes from 11 to 12: 1866 (1) The modifications are made according to the comments from Eric, 1867 http://www.ietf.org/mail-archive/web/savi/current/msg01778.html. 1869 Main changes from 12 to 13: 1871 (1) Main modifications are made based on comments from Elwyn Davies. 1872 http://www.ietf.org/mail-archive/web/gen-art/current/ 1873 msg07297.html. 1875 (2) Other modifications are made based on comments from Barry Leiba. 1877 Main changes from 13 to 14: 1879 (1) A symbol error is corrected. 1881 Main changes from 14 to 15: 1883 (1) In corresponding to "1. Does section 8 describe the mechanism 1884 that a SAVI device must perform if it has been unable to snoop 1885 the DHCP traffic between a host and a DHCP server? It appears 1886 that way in the document, but it would be good to explicitly 1887 state that early in the document when the discussion of 1888 topologies is being carried out. This becomes important when 1889 arbitrary topologies do not provide a means for the SAVI device 1890 to eavesdrop on the DHCP traffic." We specified in s7.1 p1 that 1891 arbitrary topologies may result in the regular process cannot 1892 set up correct bindings. This is also specified in the 1893 beginning of s8. 1895 (2) In corresponding to "2. Section 12 refers to the "tentative 1896 address multicast group". Do you really mean the Solicited Node 1897 Multicast address that is generated from the configured IPv6 1898 unicast address?" Yes. We have changed s12 to "the SAVI device 1899 MUST join the Solicited Node Multicast group of the source 1900 address of triggering IPv6 data packet whenever performing 1901 duplicate detection." 1903 (3) Other modifications are made according to the gen-art review. 1904 Refer to http://netarchlab.tsinghua.edu.cn/~yaog/review.txt. 1906 Main changes from 15 to 16: 1908 (1) Main modifications are made according to the second-round gen- 1909 art review. 1911 (2) Improve the quality of writing. 1913 Main changes from 16 to 17: 1915 (1) Main modifications are made according to the review from Ted 1916 Lemon. 1918 Authors' Addresses 1920 Jun Bi 1921 Tsinghua University 1922 Network Research Center, Tsinghua University 1923 Beijing 100084 1924 China 1926 Email: junbi@tsinghua.edu.cn 1928 Jianping Wu 1929 Tsinghua University 1930 Computer Science, Tsinghua University 1931 Beijing 100084 1932 China 1934 Email: jianping@cernet.edu.cn 1936 Guang Yao 1937 Tsinghua University 1938 Network Research Center, Tsinghua University 1939 Beijing 100084 1940 China 1942 Email: yaoguang@cernet.edu.cn 1944 Fred Baker 1945 Cisco Systems 1946 Santa Barbara, CA 93117 1947 United States 1949 Email: fred@cisco.com