idnits 2.17.1 draft-ietf-savi-dhcp-19.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 (March 7, 2014) is 3703 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: September 8, 2014 Tsinghua Univ. 6 F. Baker 7 Cisco 8 March 7, 2014 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-19 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 September 8, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Deployment Scenario and Configuration . . . . . . . . . . . . 8 73 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 9 74 4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10 76 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . . 11 77 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11 78 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 12 79 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . . 12 80 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . . 12 81 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . . 13 83 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14 84 4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 15 85 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 16 86 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 17 87 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2. Binding States Description . . . . . . . . . . . . . . . . 17 89 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . . 18 91 6.3.2. Control Message Arriving Events . . . . . . . . . . . 18 92 6.4. The State Machine of DHCP Snooping Process . . . . . . . . 19 93 6.4.1. From NO_BIND to Other States . . . . . . . . . . . . . 19 94 6.4.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 19 95 6.4.1.2. Following Actions . . . . . . . . . . . . . . . . 19 96 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 20 97 6.4.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 21 98 6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 21 99 6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 23 100 6.4.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 23 101 6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 23 102 6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 24 103 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 25 104 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 26 106 7.3. Additional Binding States Description . . . . . . . . . . 27 107 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 7.5. State Machine of Binding Recovery Process . . . . . . . . 28 109 7.5.1. From NO_BIND to Other States . . . . . . . . . . . . . 28 110 7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 28 111 7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 28 112 7.5.2. From DETECTION to Other States . . . . . . . . . . . . 29 113 7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 29 114 7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 29 116 7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 30 117 7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 30 118 7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 30 119 7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 31 120 7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 31 121 7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 31 122 7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 31 123 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 32 124 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 32 125 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 33 126 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 33 127 9.1. Attribute Configuration Restoration . . . . . . . . . . . 34 128 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 34 129 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 34 130 11. MLD Consideration . . . . . . . . . . . . . . . . . . . . . . 35 131 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 132 12.1. Security Problems about the Data Snooping Process . . . . 35 133 12.2. Issues about Leaving Clients . . . . . . . . . . . . . . . 35 134 12.3. Duplicate Bindings of the Same Address . . . . . . . . . . 36 135 12.4. Compatibility with DNA (Detecting Network Attachment) . . 36 136 12.5. Authentication in DHCPv6 Leasequery . . . . . . . . . . . 37 137 12.6. Binding Number Limitation . . . . . . . . . . . . . . . . 38 138 12.7. Residual Threats . . . . . . . . . . . . . . . . . . . . . 38 139 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 140 14. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 39 141 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 142 15.1. Informative References . . . . . . . . . . . . . . . . . . 39 143 15.2. Normative References . . . . . . . . . . . . . . . . . . . 39 144 Appendix A. change log . . . . . . . . . . . . . . . . . . . . . 40 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]. Stateless DHCP [RFC3736] is out of scope for this 174 document, because it has nothing to do with IP address allocation. A 175 client doing stateless DHCP acquires its IP address(es) using some 176 other mechanism. It is through that mechanism that SAVI must be 177 accomplished. Besides, this mechanism is primarily designed for pure 178 DHCP scenarios in which only addresses assigned through DHCP are 179 allowed. However, it does not block any link-local address. It is 180 because link-local addresses are used by DHCPv6 clients before the 181 clients are assigned a DHCPv6 address. Considering that link-local 182 addresses are generally self-generated, and the spoofing of link 183 local address may disturb this mechanism, it is RECOMMENDED to enable 184 a SAVI solution for link-local addresses, e.g., the SAVI-FCFS 185 [savi-fcfs]. 187 2. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 3. Terminology 195 Binding anchor: A "binding anchor" is defined to be a link layer 196 property of network attachment in [savi-framework]. A list of proper 197 binding anchors can be found in Section 3.2 of [savi-framework]. 199 Attribute: A configurable property of each network attachment which 200 indicates the actions to be performed on packets received from the 201 network attachment. 203 DHCP address: An IP address assigned to an interface via DHCP. 205 SAVI-DHCP: The name of this SAVI function for DHCP address. 207 SAVI device: A network device on which this SAVI function is enabled. 209 Non-SAVI device: A network device on which this SAVI function is not 210 enabled. 212 DHCP Client-Server message: A message that is sent from a DHCP client 213 to a DHCP server or DHCP servers. Such a message is of one of the 214 following types: 216 o DHCPv4 Discover: DHCPDISCOVER [RFC2131] 218 o DHCPv4 Request: DHCPREQUEST generated during SELECTING state 219 [RFC2131] 221 o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state 222 [RFC2131] 224 o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state 225 [RFC2131] 227 o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state 228 [RFC2131] 230 o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be 231 identified based on the Table 4 of [RFC2131] 233 o DHCPv4 Decline: DHCPDECLINE [RFC2131] 235 o DHCPv4 Release: DHCPRELEASE [RFC2131] 237 o DHCPv4 Inform: DHCPINFORM [RFC2131] 239 o DHCPv6 Request: REQUEST [RFC3315] 240 o DHCPv6 Solicit: SOLICIT [RFC3315] 242 o DHCPv6 Confirm: CONFIRM [RFC3315] 244 o DHCPv6 Decline: DECLINE [RFC3315] 246 o DHCPv6 Release: RELEASE [RFC3315] 248 o DHCPv6 Rebind: REBIND [RFC3315] 250 o DHCPv6 Renew: RENEW [RFC3315] 252 o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] 254 DHCP Server-Client message: A message that is sent from a DHCP server 255 to a DHCP client. Such a message is of one of the following types: 257 o DHCPv4 ACK: DHCPACK [RFC2131] 259 o DHCPv4 NAK: DHCPNAK [RFC2131] 261 o DHCPv4 Offer: DHCPOFFER [RFC2131] 263 o DHCPv6 Reply: REPLY [RFC3315] 265 o DHCPv6 Advertise: ADVERTISE [RFC3315] 267 o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] 269 Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in 270 IPv6 [RFC3315]. 272 Binding entry: An 'permit' rule that defines a valid association 273 between an IP address and a binding anchor. 275 Binding State Table (BST): The data structure that contains all the 276 binding entries. 278 Binding entry limit: The maximum number of binding entries that may 279 be associated with any one binding anchor. Limiting the number of 280 binding entries per binding anchor prevents a malicious or 281 malfunctioning node from overloading the binding table on a SAVI 282 device. 284 Direct attachment: Ideally, a SAVI device should be an access device 285 which is directly attached by hosts. In such case, the hosts are 286 direct attachments of the SAVI device. 288 Indirect attachment: A SAVI device can be an aggregration device 289 which is connected with a number of access devices, which are 290 attached by hosts. In such case, the hosts are indirect attachments 291 of the SAVI device. Sometimes, it is expressed as "the hosts are 292 indirectly attached to the SAVI device". 294 Upstream link: Upstream links are links connected to non-SAVI devices 295 from which the valid source address space of traffic contains the 296 prefixes of other networks. SAVI-DHCP will not set up bindings for 297 addresses appearing on upstream links and will not check data traffic 298 from upstream links. The traffic from upstream links should be 299 checked by a prefix granularity source address validation mechanism 300 to avoid spoofing of local addresses from other networks. 302 Upstream device: An upstream device is a non-SAVI device associated 303 with an upstream link. For example, the gateway router of the 304 network. 306 Downstream link: Downstream links are links connected to non-SAVI 307 devices from which the valid source address space of traffic only 308 contains the prefix(es) of the local network. SAVI-DHCP may check 309 traffic from downstream links. 311 Downstream device: A downstream device is a non-SAVI device 312 associated with an downstream link. For example, an access switch in 313 the network. 315 (Note: To distinguish upstream/downstream links is essential for 316 SAVI-DHCP. Networks are not isolated and traffic from other networks 317 may get into the network with SAVI-DHCP deployed. It is unreasonable 318 for SAVI-DHCP to set up bindings for addresses assigned in other 319 networks.) 321 CUT VERTEX: A cut vertex is 'any vertex whose removal increases the 322 number of connected components'. This is a concept in graph theory. 323 This term is used in Section 6.1 to accurately specify the required 324 deployment location of SAVI devices when they only perform the DHCP 325 snooping process. 327 Identity Association (IA): "A collection of addresses assigned to a 328 client." [RFC3315] 330 4. Deployment Scenario and Configuration 331 4.1. Elements and Scenario 333 A list of essential elements in a SAVI-DHCP deployment scenario is 334 given as follows: 336 (1) DHCP server 338 (2) DHCP client 340 (3) SAVI device 342 And there may be following optional elements in a SAVI-DHCP 343 deployment scenario: 345 (1) DHCP relay 347 (2) Non-SAVI device 349 Figure 1 shows a deployment scenario that contains these elements. 350 Note that a physical device can be multiple elements, e.g, a switch 351 can be both a SAVI device and a DHCP relay. In such cases, the links 352 are logic links rather than physical links. 354 +--------+ +------------+ 355 |DHCP |-----| Non-SAVI | 356 |Server A| | Device 1 | 357 +--------+ +-----|------+ 358 ......................|............................ 359 . | upstream link . 360 . Protection +---|------+ . 361 . Perimeter | SAVI | . 362 . | Device C| . 363 . +---|------+ . 364 . | . 365 . +----------+ +---|------+ +----------+ . 366 downstream . | SAVI | | Non SAVI| | SAVI | . 367 link +----.-| Device A|----| Device 3|-------| Device B| . 368 | . +----|--|--+ +----------+ +-|---|----+ . 369 | . | +----------+ ............ | | . 370 | '.............. | . . | | . 371 | | . | . +--------+ | . 372 +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . 373 | Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . 374 | Device 2 | |A | . |Relay | . |B | . |Server B| . 375 +----------+ +------+ . +------+ . +------+ . +--------+ . 376 ............ ............... 378 Figure 1: SAVI-DHCP Scenario 380 4.2. Attribute 382 As illustrated in Figure 1, an attachment to a SAVI device can be 383 from either a DHCP client, or a DHCP relay/server, or a SAVI device, 384 or a non-SAVI device. Different actions are performed on traffic 385 originated from different elements. To distinguish different types 386 of attachments, an attachment property named 'attribute' is 387 configured on SAVI devices. This section specifies the attributes 388 used by SAVI-DHCP. 390 Before configuration, an attachment is with no attribute. An 391 attachment MAY be configured to have one or more compatible 392 attributes(refer to Section 4.2.6). The attributes of each 393 attachment MUST be configured before this SAVI-DHCP function is 394 enabled on the attachment. The procedure performed by SAVI devices 395 on traffic from each attachment is determined by the attribute(s) set 396 on the attachment. 398 Particularly, if an attachment has no attribute, no actions will be 399 performed by SAVI-DHCP on traffic from such attachments. This 400 prevents SAVI-DHCP from causing a break in the network when it is 401 turned on without any binding anchors configured. However, if a 402 binding anchor has no attributes, this means that the SAVI-DHCP-Trust 403 attribute is not present. Because of this, DHCP server messages from 404 that binding anchor will be discarded. This prevents a host from 405 connecting to an unconfigured binding anchor and acting as a DHCP 406 server. It is SUGGESTED to configure SAVI-DHCP-Trust on necessary 407 binding anchors before turning on the SAVI-DHCP function. 409 However, binding anchors associated with upstream links MAY have no 410 attribute after configuration. For example, in Figure 1, the 411 attachment from the Non-SAVI Device 1 to the SAVI Device B should be 412 configured with no attribute. It means 1) SAVI devices will neither 413 set up bindings for upstream hosts nor check traffic from upstream 414 hosts; 2) SAVI devices will not snoop DHCP messages from upstream 415 devices unless the DHCP-Trust attribute (refer to Section 4.2.2) is 416 set on the corresponding attachment. The reason that DHCP messages 417 from upstream devices are not trusted is discussed in Section 4.3.3. 419 4.2.1. Trust Attribute 421 The "Trust Attribute" indicates the packets from the corresponding 422 attachment are completely trustable. 424 SAVI devices will not set up bindings for attachments with Trust 425 attribute; DHCP messages and data packets from such attachments with 426 this attribute will not be checked. If the DHCP Server-Client 427 messages from attachments with this attribute can trigger the state 428 transitions specified in Section 6 and Section 7, these messages will 429 be handled by the corresponding processes in Section 6 and Section 7. 431 This attribute is generally configured on the attachments from other 432 SAVI devices. For example, in Figure 1, the attachment from the SAVI 433 Device A to the SAVI Device B and the attachment from the SAVI Device 434 B to the SAVI Device A should be configured with this attribute. 435 Besides, it can be configured on attachments from Non-SAVI devices 436 only if the Non-SAVI devices will not introduce unchecked traffic 437 from DHCP clients. For example, the attachments from Non-SAVI device 438 3 to SAVI device A, SAVI device B and SAVI device C can be configured 439 with this attribute, only if Non-SAVI device 3 does not have 440 attachment from DHCP clients. 442 4.2.2. DHCP-Trust Attribute 444 The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages 445 from the corresponding attachment is trustable. 447 SAVI devices will forward DHCP Server-Client messages coming from the 448 attachments with this attribute. If the DHCP Server-Client messages 449 can trigger the state transitions, they will be handled by the 450 binding setup processes specified in Section 6 and Section 7. 452 This attribute is generally used on the direct attachments from the 453 trusted DHCP servers/relays. In Figure 1, the attachment from the 454 DHCP Relay to the SAVI Device B, and the attachment from the DHCP 455 Server B to the SAVI Device B should be configured with this 456 attribute. It is NOT RECOMMENDED to configure this attribute on the 457 indirect attachments from the non-neighboring DHCP servers/relays 458 unless the attachments do not introduce bogus DHCP Server-Client 459 messages. For example, in Figure 1, the attachment from the Non-SAVI 460 Device 1 to the SAVI Device C should not be configured with this 461 attribute. This issue is discussed in Section 4.3.3. 463 4.2.3. DHCP-Snooping Attribute 465 The "DHCP-Snooping Attribute" indicates bindings will be set up based 466 on DHCP snooping. 468 DHCP Client-Server messages from attachments with this attribute will 469 trigger the setup of bindings. SAVI devices will set up bindings on 470 attachments with this attribute based on the DHCP snooping procedure 471 described in Section 6. 473 DHCP-Snooping attribute is configured on the attachments from DHCP 474 clients. This attribute can be also used on the attachments from 475 downstream Non-SAVI devices which are attached by DHCP clients. In 476 Figure 1, the attachment from the Client A to the SAVI Device A, the 477 attachment from the Client B to the SAVI Device B, and the attachment 478 from the Non-SAVI Device 2 to the SAVI Device A can be configured 479 with this attribute. 481 4.2.4. Data-Snooping Attribute 483 The "Data-Snooping Attribute" indicates data packets from the 484 corresponding attachment may trigger binding setup procedure. 486 Data packets from attachments with this attribute may trigger the 487 setup of bindings. SAVI devices will set up bindings on attachments 488 with this attribute based on the data-triggered process described in 489 Section 7. 491 If DHCP-Snooping attribute is configured on an attachment, the 492 bindings on this attachment are set up based on DHCP message 493 snooping. However, in some scenarios, a DHCP address may be used by 494 a DHCP client without DHCP address assignment procedure performed on 495 its current attachment. For such attachments, the Data-Snooping 496 process, which is described in Section 7, is necessary. This 497 attribute is configured on such attachments. The usage of this 498 attribute is further discussed in Section 7. 500 4.2.5. Validating Attribute 502 The "Validating Attribute" indicates packets from the corresponding 503 attachment will be checked based on binding entries on the 504 attachment. 506 Packets coming from attachments with this attribute will be checked 507 based on binding entries on the attachment as specified in Section 8. 509 Validating attribute is configured on the attachments from which the 510 data packets should be checked. For example, the DHCP clients. 512 4.2.6. Table of Mutual Exclusions 514 Different types of attributes may indicate mutually exclusive actions 515 on packet. Mutually exclusive attributes MUST NOT be set on the same 516 attachment. The compatibility of different attributes is listed in 517 Figure 2. Note that although Trust and DHCP-Trust are compatible, 518 there is no need to configure DHCP-Trust on an attachment with Trust 519 attribute. 521 +----------+----------+----------+----------+----------+----------+ 522 | | | | DHCP- | Data- | | 523 | | Trust |DHCP-Trust| Snooping | Snooping |Validating| 524 +----------+----------+----------+----------+----------+----------+ 525 | | | | mutually | mutually | mutually | 526 | Trust | - |compatible| exclusive| exclusive| exclusive| 527 +----------+----------+----------+----------+----------+----------+ 528 | | | | | | | 529 |DHCP-Trust|compatible| - |compatible|compatible|compatible| 530 +----------+----------+----------+----------+----------+----------+ 531 |DHCP- |mutually | | | | | 532 |Snooping |exclusive |compatible| - |compatible|compatible| 533 +----------+----------+----------+----------+----------+----------+ 534 |Data- |mutually | | | | | 535 |Snooping |exclusive |compatible|compatible| - |compatible| 536 +----------+----------+----------+----------+----------+----------+ 537 | |mutually | | | | | 538 |Validating|exclusive |compatible|compatible|compatible| - | 539 +----------+----------+----------+----------+----------+----------+ 541 Figure 2: Table of Mutual Exclusions 543 4.3. Perimeter 545 4.3.1. SAVI-DHCP Perimeter Overview 547 SAVI devices can form a perimeter separating untrusted and trusted 548 areas, similarly to SAVI-FCFS (refer to Section 2.5 of [savi-fcfs]). 549 Each SAVI device need only establish bindings for a client if it is 550 connected to that client by a link that crosses the perimeter that 551 encloses the SAVI device. 553 The perimeter is primarily designed for scalability. This has two 554 implications. First, SAVI devices only need to establish bindings 555 for directly attached clients, or clients indirectly attached through 556 non-SAVI device, rather than all the clients in the network. Second, 557 each SAVI device only need to check traffic from clients attached to 558 it, without checking all the traffic passing by. 560 Consider the example in Figure 1. The protection perimeter is formed 561 by SAVI Device A, B and C. In this case, SAVI device B doesn't create 562 a binding for client A. SAVI device A doesn't create a binding for 563 client B. But the SAVI device B is still protected from spoofing from 564 client A and the SAVI device A is still protected from spoofing from 565 client B. 567 There is three main differences between the SAVI-DHCP protection 568 perimeter and SAVI-FCFS protection perimeter: 570 (1) SAVI-DHCP follows the state announced in DHCP messages, so there 571 is no need to distribute state using Neighbor Solicitation/ 572 Neighbor Advertisement messages. 574 (2) The perimeter in SAVI-DHCP is not only a perimeter for data 575 packets, but also a perimeter for DHCP messages. The placement 576 of DHCP Relay/Server, which is not involved in SAVI-FCFS , is 577 related with the construction of the perimeter. The requirement 578 on the placement and configuration of DHCP Relay/Server are 579 discussed in Section 4.3.3. 581 (3) The complexity caused by partial deployment, redundancy paths, 582 dynamic Layer-2 routing is considered in SAVI-DHCP. Thus, 583 downstream/upstream links MUST be distinguished when configuring 584 the perimeter to avoid estabilshing binding for addresses of 585 other networks. In SAVI-FCFS, it is underlyingly required all 586 the links crossed the perimeter must be downstream links. 587 However, it may not by the cases in real deployments. 589 4.3.2. SAVI-DHCP Perimeter Configuration Guideline 591 Through configuring attribute of each attachment properly, a 592 perimeter separating untrusted area and trusted area can be formed: 594 (1) Configure Validating attribute on the direct attachments of all 595 the DHCP clients. Configure DHCP-Snooping attribute on these 596 attachments. 598 (2) Configure Validating attribute on the indirect attachments of 599 all the DHCP clients. Configure DHCP-Snooping attribute on 600 these attachments. 602 (3) Configure Trust attribute on the attachments of other SAVI 603 devices. 605 (4) If a Non-SAVI device, or a number of connected Non-SAVI devices, 606 have only attachments from SAVI devices or upstream devices, set 607 their attachments to SAVI devices with Trust attribute. 609 (5) Configure DHCP-Trust attribute on the direct attachments of 610 trusted DHCP relays/servers. 612 In this way, attachments with Validating attribute (and generally 613 together with attachments of upstream devices) can form a perimeter 614 separating DHCP clients and trusted devices. Data packet check is 615 only performed on the perimeter. The perimeter is also a perimeter 616 for DHCP messages. DHCP-Trust attribute is only configured on the 617 inside links of the perimeter. Only DHCP server-client messages 618 originated in the perimeter is trusted. 620 4.3.3. On the Placement of DHCP Server/Relay 622 Based on the configuration guideline, it can be found that the SAVI 623 devices only trust DHCP Server-Client messages originated inside the 624 perimeter. It means there MUST be at least one trusted DHCP relay/ 625 server in the perimeter. DHCP server-client messages will be 626 filtered on the perimeter (Note: server-relay messages will not be 627 filtered). In this way, DHCP server-client messages from bogus DHCP 628 servers are filtered on the perimeter, and then the SAVI devices can 629 be protected from fabricated DHCP messages. 631 Such a requirement is due to the limitation of this binding based 632 mechanism. This document makes no assumption that the DHCP server- 633 client messages arriving the perimeter from the outside can be 634 trusted. The binding anchor of a trusted remote DHCP server can be 635 shared by a bogus DHCP server. Thus, the SAVI device cannot 636 distinguish bogus and valid DHCP messages only based on the 637 associated binding anchor of DHCP messages in such case. 639 Note that even if a DHCP server is valid, it may be not contained in 640 the perimeter based on the guideline. For example, in Figure 1, DHCP 641 server A is valid, but it is attached to a Non-SAVI device. The Non- 642 SAVI device may be attached by attackers which generate fabricated 643 DHCP messages. This binding based mechanism may not have the ability 644 to distinguish whether a message received from the attachment of the 645 Non-SAVI device 1 is from DHCP server A or the attackers. If the 646 DHCP server A is contained in the perimeter, the Non-SAVI device 1 647 will also be contained in the perimter. However, the Non-SAVI device 648 1 can introduce fabricated DHCP messages into the perimeter. Thus, 649 the DHCP server A cannot be contained in the perimeter. 651 In this case, the SAVI devices can set up bindings for addresses 652 assigned by DHCP server A through snooping the messages relayed by 653 trusted relay in the network. For example, the DHCP relay may relay 654 messages between DHCP server A and the clients in the network, and 655 the SAVI devices can snoop messages from the DHCP relay which is 656 inside the perimeter. The authentication mechanism (i.e., IPSec, as 657 specified in section 21.1 of [RFC3315]) enforced between the DHCP 658 relay and the DHCP server outside the perimeter can compensate this 659 binding based mechanism. It is SUGGESTED to configure IPSec between 660 the DHCP relay and the DHCP server in such case. If source address 661 validation is enforced in the whole network, which makes the source 662 IP address trustable, the DHCP relay and the DHCP server can simply 663 authenticate the messages from each other based on the source IP 664 address without the requriement to deploy IPSec. 666 5. Binding State Table (BST) 668 Binding State Table is used to contain the bindings between the IP 669 addresses assigned to the attachments and the corresponding binding 670 anchors of the attachments. Each entry of the table, i.e., binding 671 entry, has 5 fields: 673 o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer 674 property of the attachment. 676 o IP Address(Address): the IP address assigned to the attachment by 677 DHCP. 679 o State: the state of the binding. Possible values of this field 680 are listed in Section 6.2 and Section 7.3. 682 o Lifetime: the remaining seconds of the binding. The Lifetime 683 field counts down automatically. 685 o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of 686 the corresponding DHCP transaction. TID field is used to 687 associate DHCP Server-Client messages with corresponding binding 688 entries. 690 IA does not present in the BST. On the one hand, IA is not found to 691 be necessary because the lease of each address in one IA is assigned 692 respectively. On the other hand, when the binding is set up based on 693 data-snooping, IA cannot be recovered from the leasequery protocol. 694 Besides, there is no IA for DHCPv4. 696 An instance of this table is shown in Figure 3. 698 +---------+----------+----------+-----------+-------+ 699 | Anchor | Address | State | Lifetime |TID | 700 +---------+----------+----------+-----------+-------+ 701 | A | IP_1 | BOUND | 65535 |TID_1 | 702 +---------+----------+----------+-----------+-------+ 703 | A | IP_2 | BOUND | 10000 |TID_2 | 704 +---------+----------+----------+-----------+-------+ 705 | B | IP_3 |INIT_BIND | 1 |TID_3 | 706 +---------+----------+----------+-----------+-------+ 707 Figure 3: Instance of BST 709 6. DHCP Snooping Process 711 This section specifies the process of setting up bindings based on 712 DHCP snooping, named DHCP Snooping Process. This process is 713 illustrated making use of a state machine. 715 6.1. Rationale 717 The rationale of the DHCP Snooping Process is that if a DHCP client 718 is legitimate to use a DHCP address, the DHCP address assignment 719 procedure which assigns the IP address to the client must have been 720 performed on the attachment of the client. This basis stands when 721 the SAVI device is always on the path(s) from the DHCP client to the 722 DHCP server(s)/relay(s). Without considering the movement of DHCP 723 clients, the SAVI device should be the CUT VERTEX whose removal will 724 disjoin the DHCP client and the remaining network containing the DHCP 725 server(s)/relay(s). For most of the layer-2 networks whose 726 topologies are simple, it is possible to deploy this SAVI function at 727 proper devices to meet this requirement. 729 However, a deployment of this SAVI function may not meet the 730 requirement. For example, there are multiple paths from a DHCP 731 client to the DHCP server and the SAVI device is only on one of them. 732 Then the SAVI device may not be able to snoop the DHCP procedure. 733 Host movement may also make this requirement can not be met. For 734 exmaple, when a DHCP client moves from one attachment to another 735 attachment in the same network, it may not reinitialize its interface 736 or send a Confirm message because of imcomplete protocol 737 implementation. Thus, there can be scenarios in which only 738 performing this DHCP snooping process is insufficient to set up 739 bindings for all the valid DHCP addresses. These exceptions and the 740 solutions are discussed in Section 7. 742 6.2. Binding States Description 744 Following binding states present in this process and the 745 corresponding state machine: 747 NO_BIND: The state before a binding has been set up. 749 INIT_BIND: A potential binding has been set up. 751 BOUND: The binding has been set up. 753 6.3. Events 755 This section describes events in this process and the corresponding 756 state machine. 758 6.3.1. Timer Expiration Event 760 EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. 762 6.3.2. Control Message Arriving Events 764 EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is 765 received. 767 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. 769 EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. 771 EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is 772 received. 774 EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received. 776 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 777 option is received. 779 EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received. 781 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is 782 received. 784 EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is 785 received. 787 EVE_DCHP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to 788 section 4.3.3 of [RFC5007]) is received. 790 Moreover, only if a DHCP message can pass the following checks, the 791 corresponding event is regarded as a valid event: 793 o Attribute check: the DHCP Server-Client messages and 794 LEASEQUERY_REPLY should be from attachments with DHCP-Trust 795 attribute; the DHCP Client-Server messages should be from 796 attachments with DHCP-Snooping attribute. 798 o Destination check: the DHCP Server-Client messages should be 799 destined to attachments with DHCP-Snooping attribute. This check 800 is performed to ensure the binding is set up on the SAVI device 801 which is nearest to the destination client. 803 o Binding anchor check: the DHCP Client-Server messages which may 804 trigger modification or removal of an existing binding entry must 805 have matched binding anchor with the corresponding entry. 807 o TID check: the DHCP Server-Client/Client-Server messages which 808 may cause modification on existing binding entries must have 809 matched TID with the corresponding entry. Note that this check 810 is not performed on Leasequery and Leasequery-reply messages as 811 they are exchanged between the SAVI devices and the DHCP servers. 813 o Binding limitation check: the DHCP messages must not cause new 814 binding setup on an attachment whose binding entry limitation has 815 been reached. (refer to Section 12.6). 817 o Address check: the source address of the DHCP messages should 818 pass the check specified in Section 8.2. 820 On receiving a DHCP message without triggering a valid event, the 821 state will not transit and actions will not be performed. Note that 822 if a message does not trigger a valid event but it can pass the 823 checks in Section 8.2, it MUST be forwarded. 825 6.4. The State Machine of DHCP Snooping Process 827 This section specifies the transits of each state and the 828 corresponding actions. 830 6.4.1. From NO_BIND to Other States 832 6.4.1.1. Trigger Event 834 EVE_DHCP_REQUEST, EVE_DHCP_OPTION_RC, EVE_DHCP_CONFIRM, 835 EVE_DHCP_REBOOT. 837 6.4.1.2. Following Actions 839 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC/ 840 EVE_DHCP_REBOOT: 842 The SAVI device MUST forward the message. 844 The SAVI device will generate an entry in the BST. The Binding 845 anchor field is set to the binding anchor of the attachment from 846 which the message is received. The State field is set to INIT_BIND. 847 The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID 848 field is set to the TID of the message. If the message is DHCPv4 849 Request or DHCPv4 Reboot, the Address field can be set to the address 850 to request, i.e., the 'requested IP address'. An example of the 851 entry is illustrated in Figure 4. 853 +---------+-------+---------+-----------------------+-------+ 854 | Anchor |Address| State | Lifetime |TID | 855 +---------+-------+---------+-----------------------+-------+ 856 | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 857 +---------+-------+---------+-----------------------+-------+ 859 Figure 4: Binding entry in BST on Request/Rapid Commit/Reboot 860 triggered initialization 862 If the triggering event is EVE_DHCP_CONFIRM: 864 The SAVI device MUST forward the message. 866 The SAVI device will generate corresponding entries in the BST for 867 all the addresses in each the IA option of the Confirm message. The 868 Binding anchor field is set to the binding anchor of the attachment 869 from which the message is received. The State field is set to 870 INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. 871 The TID field is set to the TID of the message. The Address field is 872 set to the address(es) to confirm. An example of the entries is 873 illustrated in Figure 5. 875 +---------+--------+---------+-----------------------+-------+ 876 | Anchor | Address| State | Lifetime |TID | 877 +---------+--------+---------+-----------------------+-------+ 878 | A | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 879 +---------+--------+---------+-----------------------+-------+ 880 | A | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 881 +---------+--------+---------+-----------------------+-------+ 883 Figure 5: Binding entry in BST on Confirm triggered initialization 885 6.4.2. From INIT_BIND to Other States 886 6.4.2.1. Trigger Event 888 EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE. 890 Note: If no DHCP Server-Client messages which assign addresses or 891 confirm addresses are received, corresponding entries will expire 892 automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4 893 NAK) are not specially processed. 895 6.4.2.2. Following Actions 897 If the trigger event is EVE_DHCP_REPLY: 899 The message MUST be forwarded to the corresponding client. 901 If the message is DHCPv4 ACK, the Address field of the corresponding 902 entry (i.e., the binding entry whose TID is the same of the message) 903 is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). 904 The Lifetime field is set to the sum of the lease time in ACK message 905 and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. 907 If the message is DHCPv6 Reply, there are following cases: 909 1. If the status code is not "Success", no modification on 910 corresponding entries will be made. Corresponding entries will 911 expire automatically if no "Success" Reply is received during the 912 lifetime. The entries are not removed immediately due to the client 913 may be able to use the addresses whenever a "Success" Reply is 914 received ("If the client receives any Reply messages that do not 915 indicate a NotOnLink status, the client can use the addresses in the 916 IA and ignore any messages that indicate a NotOnLink status." 917 [RFC3315]). 919 2. If the status code is "Success", the SAVI device checks the IA 920 options in the Reply message. 922 2.1 If there are no IA options in the Reply message, the DHCP Reply 923 message is in response to a Confirm message. The state of the 924 binding entries with matched TID is changed to BOUND. Because 925 [RFC3315] does not require lease time of addresses to be contained in 926 the Reply message, the SAVI device MUST send a LEASEQUERY [RFC5007] 927 message querying by IP address to All_DHCP_Servers multicast address 928 [RFC3315] or a list of configured DHCP server addresses. The 929 Leasequery message is generated for each IP address if multiple 930 addresses are confirmed. The Lifetime of corresponding entries is 931 set to MAX_LEASEQUERY_DELAY. An example of the entries is 932 illustrated in Figure 6. The related security problem about DHCPv6 933 LEASEQUERY is discussed in Section 12.5. 935 2.2 If there are IA options in the Reply message, the SAVI device 936 checks each IA option. When the first assigned address is found, the 937 Address field of the binding entry with matched TID is set to the 938 address. The Lifetime field is set to the sum of the lease time in 939 Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed 940 to BOUND. If there are more than one address assigned in the 941 message, new binding entries are set up for the remaining address 942 assigned in the IA options. An example of the entries is illustrated 943 in Figure 7. SAVI devices do not specially process IA options with 944 NoAddrsAvail status, because there should be no address contained in 945 such IA options. 947 Note: the SAVI devices do not check if the assigned addresses are 948 duplicated because in SAVI-DHCP scenarios, the DHCP servers are the 949 only source of valid addresses. However, the DHCP servers should be 950 configured to make sure no duplicated addresses are assigned. 952 +---------+----------+-------+------------------------+-------+ 953 | Anchor | Address | State | Lifetime |TID | 954 +---------+----------+-------+------------------------+-------+ 955 | A | Addr1 | BOUND | MAX_LEASEQUERY_DELAY |TID | 956 +---------+----------+-------+------------------------+-------+ 957 | A | Addr2 | BOUND | MAX_LEASEQUERY_DELAY |TID | 958 +---------+----------+-------+------------------------+-------+ 960 Figure 6: From INIT_BIND to BOUND on DHCP Reply in response to 961 Confirm 963 +---------+----------+-------+------------------------+-------+ 964 | Anchor | Address | State | Lifetime |TID | 965 +---------+----------+-------+------------------------+-------+ 966 | A | Addr1 | BOUND |Lease time+ |TID | 967 | | | |MAX_DHCP_RESPONSE_TIME | | 968 +---------+----------+-------+------------------------+-------+ 969 | A | Addr2 | BOUND |Lease time+ |TID | 970 | | | |MAX_DHCP_RESPONSE_TIME | | 971 +---------+----------+-------+------------------------+-------+ 973 Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to 974 Request 976 If the trigger event is EVE_ENTRY_EXPIRE: 978 The entry MUST be deleted from BST. 980 6.4.3. From BOUND to Other States 982 6.4.3.1. Trigger Event 984 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, EVE_DHCP_REPLY, 985 EVE_DCHP_LEASEQUERY. 987 6.4.3.2. Following Actions 989 If the trigger event is EVE_ENTRY_EXPIRE: 991 Remove the corresponding entry in BST. 993 If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE: 995 The message MUST be forwarded. 997 The SAVI device first gets all the addresses ("Requested IP address" 998 in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the 999 IA options of DHCPv6 Decline/Release) to decline/release in the 1000 message. Then the corresponding entries MUST be removed. 1002 If the trigger event is EVE_DHCP_REPLY: 1004 The message MUST be forwarded. 1006 The DHCP Reply messages received in current states should be in 1007 response to DHCP Renew/Rebind. 1009 If the message is DHCPv4 ACK, the SAVI device just simply update the 1010 binding entry with matched TID, with the Lifetime field set to be the 1011 sum of the new lease time and MAX_DHCP_RESPONSE_TIME. 1013 If the message is DHCPv6 Reply, the SAVI device checks each IA 1014 Address option in each IA option. If the valid lifetime of an IA 1015 address option is 0, the binding entry with matched TID and address 1016 is removed. Or else, set the Lifetime field of the binding entry 1017 with matched TID and address to be the sum of the new valid lifetime 1018 and MAX_DHCP_RESPONSE_TIME. 1020 The SAVI device does not specially process IA options in Reply 1021 message with status NoBinding, because no address is contained in 1022 such IA options and no actions will be performed. 1024 If the trigger event is EVE_DCHP_LEASEQUERY: 1026 The message MUST be forwarded. 1028 The message should be in response to the Leasequery message sent in 1029 Section 6.4.2. The related binding entry can be determined based on 1030 the address in the IAADDR option in the Leasequery-reply message. 1031 The Lifetime field of the corresponding binding entry is set to the 1032 sum of the lease time in the LEASEQUERY_REPLY message and 1033 MAX_DHCP_RESPONSE_TIME. 1035 6.5. Table of State Machine 1037 The main state transits are listed as follows. Note that not all the 1038 details are specified in the table and the diagram. 1040 State Event Action Next State 1041 NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND 1042 INIT_BIND RPL Record lease time BOUND 1043 (send lease query if no lease) 1044 INIT_BIND Timeout Remove entry NO_BIND 1045 BOUND RLS/DCL Remove entry NO_BIND 1046 BOUND Timeout Remove entry NO_BIND 1047 BOUND RPL Set new lifetime BOUND 1048 BOUND LQR Record lease time BOUND 1050 Figure 8: Table of Transit 1052 RQ: EVE_DHCP_REQUEST 1054 CF: EVE_DHCP_CONFIRM 1056 RC: EVE_DHCP_OPTION_RC 1058 RE: EVE_DHCP_REBOOT 1060 RPL: EVE_DHCP_REPLY 1062 DCL: EVE_DHCP_DECLINE 1064 RLS: EVE_DHCP_RELEASE 1065 LQR: EVE_DCHP_LEASEQUERY 1067 Timeout: EVE_ENTRY_EXPIRE 1069 +-------------+ 1070 | | 1071 /---------| NO_BIND |<----------\ 1072 | ------>| | | 1073 | | +-------------+ |EVE_DHCP_RELEASE 1074 EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE 1075 EVE_DHCP_CONFIRM | |TIMEOUT |TIMEOUT 1076 EVE_DHCP_OPTION_RC| | | 1077 EVE_DHCP_REBOOT | | | 1078 | | | 1079 | | | 1080 v | | 1081 +-------------+ +------------+ 1082 | | EVE_DHCP_REPLY | | 1083 | INIT_BIND ------------------------>| BOUND |<-\ 1084 | | | | | 1085 +-------------+ +------------+ | 1086 | | 1087 \--------/ 1088 EVE_DHCP_REPLY 1089 EVE_DCHP_LEASEQUERY 1091 Figure 9: Diagram of Transit 1093 7. Data Snooping Process 1095 7.1. Scenario 1097 The rationale of the DHCP Snooping Process specified in Section 6 is 1098 that if a DHCP client is legitimate to use a DHCP address, the 1099 corresponding DHCP address assignment procedure must have been 1100 finished on the attachment of the DHCP client. This basis stands 1101 when the SAVI device is always on the path(s) from the DHCP client to 1102 the DHCP server(s)/relay(s). However, there are two exceptions: 1104 o Multiple paths: there are more than one feasible layer-2 paths 1105 from the client to the DHCP server/relay, and the SAVI device is 1106 not on all of them. The client may get the address through one 1107 of the paths not passing by the SAVI device, but packets from the 1108 client can travel through the other paths passing by the SAVI 1109 device. Because the SAVI device does not snoop the DHCP 1110 assignment procedure, the DHCP snooping procedure will not set up 1111 the corresponding binding. 1113 o Dynamic path: there is only one feasible layer-2 path from the 1114 client to the DHCP server/relay, but the path is dynamic due to 1115 topology change or layer-2 path change. This situation also 1116 covers the local-link movement of clients without address 1117 confirm/re-configuration process. In such cases, the DHCP 1118 snooping process will not set up the corresponding binding. 1120 Data Snooping Process is designed to avoid permanently blocking 1121 legitimate traffic in case of these two exceptions. This process is 1122 performed on attachments with Data-Snooping attribute. Data packets 1123 without matched binding entry may trigger this process to set up 1124 bindings. 1126 Snooping data traffic will introduce considerable burden on the 1127 processor and ASIC-to-Processor bandwidth of SAVI devices. 1128 Considering the overhead of this process, the implementation of this 1129 process is a conditional SHOULD. This function SHOULD be implemented 1130 unless the implementation is known to be used in the scenarios 1131 without the above exceptions. For example, if the implementation is 1132 to be used in networks with tree topology and without host local-link 1133 movement, there is no need to implement this process in such 1134 scenarios. 1136 This process is not supposed to set up a binding whenever a data 1137 packet without matched binding entry is received. Instead, unmatched 1138 data packets trigger this process with a probability and generally a 1139 number of unmatched packets will be discarded before the binding is 1140 set up. 1142 7.2. Rationale 1144 This process makes use of duplication detection and DHCP Leasequery 1145 to set up bindings. If an address is not used by another client in 1146 the network, and the address has been assigned in the network, the 1147 address can be bound with the binding anchor of the attachment from 1148 which the unmatched packet is received. 1150 The security issues about this process is discussed is Section 12.1. 1152 7.3. Additional Binding States Description 1154 In addition to Section 6.2, new states used in this process are 1155 listed here: 1157 DETECTION: The address in the entry is under local duplication 1158 detection. 1160 RECOVERY: The SAVI device is querying the assignment and lease time 1161 of the address in the entry through DHCP Leasequery. 1163 7.4. Events 1165 Additional events in this process are described here. Also, if an 1166 event will trigger to set up a new binding entry, the binding entry 1167 limit on the binding anchor MUST NOT have not been reached. 1169 EVE_DATA_UNMATCH: A data packet without matched binding is received. 1171 EVE_DATA_CONFLICT: ARP Response/Neighbor Advertisement(NA) message 1172 against an address in DETECTION state is received. 1174 EVE_DATA_LEASEQUERY: 1176 IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option 1177 is received. 1179 IPv6: A successful LEASEQUERY-REPLY is received. 1181 The triggering packet should pass the following checks to trigger a 1182 valid event: 1184 o Attribute check: the data packet should be from attachments with 1185 Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY 1186 messages should be from attachments with DHCP-Snooping attribute. 1188 o Binding limitation check: the DHCP messages must not cause new 1189 binding setup on an attachment whose binding entry limitation has 1190 been reached. (refer to Section 12.6). 1192 o Address check: the address of the DHCP/ARP/NA messages should 1193 pass the check specified in Section 8.2. 1195 o Interval check: the interval between two successive 1196 EVE_DATA_UNMATCH events triggered by an attachment MUST be no 1197 smaller than DATA_SNOOPING_INTERVAL. 1199 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must 1200 have matched TID with the corresponding entry. 1202 7.5. State Machine of Binding Recovery Process 1204 Through using additional states, the state machine of this process 1205 doesn't conflict the regular process described in Section 6. Thus, 1206 it can be implemented separately without changing the state machine 1207 in Section 6. 1209 7.5.1. From NO_BIND to Other States 1211 7.5.1.1. Trigger Event 1213 EVE_DATA_UNMATCH. 1215 7.5.1.2. Following Actions 1217 Determine whether to process this event with a probability. The 1218 probability can be configured or calculated based on the state of the 1219 SAVI device. This probability should be low enough to mitigate the 1220 damage from DoS attack against this process. 1222 Create a new entry in the BST. Set the Binding Anchor field to the 1223 corresponding binding anchor of the attachment. Set the Address 1224 field to be source address of the packet. Set the State field to 1225 DETECTION. Set the Lifetime of the created entry to 2*DAD_TIMEOUT. 1227 Check if the address has a local conflict (it violates an address 1228 being used by another node): 1230 (1) IPv4 address: send an Address Resolution Protocol (ARP) Request 1231 [RFC826]or a ARP probe [RFC5227] on the address; if there is no 1232 response message after DAD_TIMEOUT, send another ARP Request or 1233 ARP probe; 1235 (2) IPv6 address: perform Duplicate Address Detection (DAD) 1236 [RFC4862] on the address; if there is no response message after 1237 DAD_TIMEOUT, perform another DAD procedure. 1239 Because the delivery of detection message is unreliable, the 1240 detection message is of a certain possibility of not reaching the 1241 targeting node. If the targeting node doesn't get the detection 1242 message, the address may be bound with a wrong binding anchor in the 1243 further stages. This fault may introduce attack against this 1244 mechanism. Thus, the detection is performed again if there is no 1245 response after the first detection. 1247 The messages MUST NOT be sent to the attachment from which the 1248 triggering packet is received. 1250 The packet which triggers this event SHOULD be discarded. 1252 An example of the entry is illustrated in Figure 10. 1254 +---------+-------+---------+-----------------------+-------+ 1255 | Anchor |Address| State | Lifetime |TID | 1256 +---------+-------+---------+-----------------------+-------+ 1257 | A | Addr1 |DETECTION|2*DAD_TIMEOUT | | 1258 +---------+-------+---------+-----------------------+-------+ 1260 Figure 10: Binding entry in BST on data triggered initialization 1262 7.5.2. From DETECTION to Other States 1264 7.5.2.1. Trigger Event 1266 EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT. 1268 7.5.2.2. Following Actions 1270 If the trigger event is EVE_ENTRY_EXPIRE: 1272 (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 1273 by IP address to all DHCPv4 servers with IP Address Lease Time 1274 option (option 51). The server addresses can be found through 1275 DHCPv4 Discovery or from configuration. Change the state of the 1276 corresponding entry to RECOVERY. Change the lifetime of the 1277 entry to be MAX_LEASEQUERY_DELAY. 1279 (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP 1280 address to All_DHCP_Relay_Agents_and_Servers multicast address 1281 or a configured server address. 1283 Change the state of the corresponding entry to RECOVERY. Change the 1284 lifetime of the entry to be MAX_LEASEQUERY_DELAY. The TID field is 1285 set to the TID used in the Leasequery message. 1287 An example of the entry is illustrated in Figure 11. 1289 +---------+-------+---------+-----------------------+-------+ 1290 | Anchor |Address| State | Lifetime |TID | 1291 +---------+-------+---------+-----------------------+-------+ 1292 | A | Addr1 |RECOVERY |MAX_LEASEQUERY_DELAY |TID | 1293 +---------+-------+---------+-----------------------+-------+ 1295 Figure 11: Binding entry in BST on Lease Query 1297 If the trigger event is EVE_DATA_CONFLICT: 1299 Remove the entry. 1301 7.5.3. From RECOVERY to Other States 1303 7.5.3.1. Trigger Event 1305 EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY. 1307 7.5.3.2. Following Actions 1309 If the trigger event is EVE_DATA_LEASEQUERY: 1311 (1) IPv4 address: Check if the 'chaddr' field (hardware address) of 1312 the DHCPLEASEACTIVE message matches the hardware address of the 1313 triggering message. If the two addresses do not match, the 1314 following actions will not be performed. Change the state of 1315 the corresponding binding to BOUND. Set life time to the sum of 1316 the value encoded in IP Address Lease Time option of the 1317 DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Erase the 1318 TID field. 1320 (2) IPv6 address: Change the state of the corresponding binding to 1321 BOUND. Set the lifetime to the sum of the valid lifetime 1322 extracted from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY 1323 message and MAX_DHCP_RESPONSE_TIME. Erase the TID field. 1325 If multiple addresses are specified in the LEASEQUERY-REPLY message, 1326 new entries MUST also be created correspondingly on the same binding 1327 anchor. 1329 If the trigger event is EVE_ENTRY_EXPIRE: 1331 Remove the entry. 1333 7.5.4. After BOUND 1335 Note that the TID field contains no value after the binding state 1336 changes to BOUND. The TID field is recovered from snooping DHCP 1337 Renew/Rebind messages. Because TID is used to associate binding 1338 entries with messages from DHCP servers, it must be recovered; or 1339 else a number of state transits of this mechanism will be not 1340 executed normally. 1342 7.5.4.1. Trigger Event 1344 EVE_DHCP_RENEW/EVE_DHCP_REBIND. 1346 7.5.4.2. Following Action 1348 Set the TID field of the corresponding entry to the TID in the 1349 triggering message. 1351 7.6. Table of State Machine 1353 The main state transits are listed as follows. 1355 State Event Action Next State 1356 NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION 1357 DETECTION Timeout Send Leasequery RECOVERY 1358 DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND 1359 RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND 1360 RECOVERY Timeout Remove entry NO_BIND 1361 BOUND RENEW/REBIND Record TID BOUND 1363 Figure 12: Table of Transit 1365 RENEW: EVE_DHCP_RENEW 1367 REBIND: EVE_DHCP_REBIND 1369 Timeout: EVE_ENTRY_EXPIRE 1370 +-------------+ 1371 | | 1372 /---------| NO_BIND |<----------\ 1373 | ------>| | | 1374 | | +-------------+ | 1375 EVE_DATA_UNMATCH | |EVE_DATA_CONFLICT | 1376 | | |TIMEOUT 1377 | | | 1378 | | | 1379 | | | 1380 | | | 1381 v | | 1382 +-------------+ TIMEOUT +------------+ 1383 | | | | 1384 | DETECTION ------------------------>| RECOVERY | 1385 | | | | 1386 +-------------+ +------------+ 1387 EVE_DATA_LEASEQUERY| 1388 /----------\ | 1389 EVE_DHCP_RENEW| | | 1390 EVE_DHCP_REBIND| +-----v-------+ | 1391 | | | | 1392 \----| BOUND |<----------/ 1393 | | 1394 +-------------+ 1396 Figure 13: Diagram of Transit 1398 8. Filtering Specification 1400 This section specifies how to use bindings to filter out spoofing 1401 packets. 1403 Filtering policies are different for data packet and control packet. 1404 DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] messages that 1405 may cause state transit are classified into control packet. Neighbor 1406 Advertisement (NA) and ARP Response are also included in control 1407 packet because the Target Address of NA and ARP Response should be 1408 checked to prevent spoofing. All other packets are considered to be 1409 data packets. 1411 8.1. Data Packet Filtering 1413 Data packets from attachment with attribute Validating MUST be 1414 checked. 1416 Packet whose source IP address is a link-local address SHOULD be 1417 forwarded. 1419 If the source IP address of a packet is not a link-local address, but 1420 there is not a matched entry in BST with state BOUND, this packet 1421 MUST be discarded. However, the packet may trigger Data Snooping 1422 Process if Data-Snooping attribute is set on the attachment. 1424 The SAVI device MAY record any violation. 1426 8.2. Control Packet Filtering 1428 For attachments with Validating attribute: 1430 Discard DHCPv4 Request message whose source IP address is neither all 1431 zeros nor a bound address in BST. 1433 Discard DHCPv6 Request message whose source IP address is neither a 1434 link-local address nor bound with the corresponding binding anchor in 1435 BST. 1437 Discard NDP messages whose source IP address is neither a link-local 1438 address nor bound with the corresponding binding anchor. In 1439 addition, discard NA message whose target address is neither a link- 1440 local address nor bound with the corresponding binding anchor. 1442 Discard ARP messages whose protocol is IP and sender protocol address 1443 is neither all zeros address nor bound with the corresponding binding 1444 anchor. In addition, discard ARP Reply messages whose target address 1445 is not bound with the corresponding binding anchor. 1447 For attachments with other attributes: 1449 Discard DHCP server/relay type message not from attachments with the 1450 DHCP-Trust attribute or Trust attribute. 1452 The SAVI device MAY record any violation. 1454 For attachments with no attribute: 1456 No action will be performed on traffic from such attachments. 1458 9. State Restoration 1460 If a SAVI device reboots, the information kept in volatile memory 1461 will be lost. This section specifies the restoration of attribute 1462 configuration and BST. 1464 9.1. Attribute Configuration Restoration 1466 The lost of attribute configuration will not break the network: no 1467 action will be performed on traffic from attachments with no 1468 attribute. However, the lost of attribute configuration makes this 1469 SAVI function unable to work. 1471 To avoid the loss of binding anchor attribute configuration, the 1472 configuration MUST be able to be stored in non-volatile storage. 1473 After the reboot of SAVI device, if the configuration of binding 1474 anchor attribute can be found in non-volatile storage, the 1475 configuration MUST be used. 1477 9.2. Binding State Restoration 1479 The loss of binding state will cause the SAVI devices discard 1480 legitimate traffic. Purely using the Data Snooping Process to 1481 recover a large number of bindings is of heavy overhead and 1482 considerable delay. Thus, to recover bindings from non-volatile 1483 storage, as specified below, is RECOMMENDED. 1485 Binding entries MAY be saved into non-volatile storage whenever a new 1486 binding entry changes to BOUND state. If a binding with BOUND state 1487 is removed, the saved entry MUST be removed correspondingly. 1489 Immediately after reboot, the SAVI device SHOULD restore binding 1490 states from the non-volatile storage. The system time of save 1491 process MUST be stored. After rebooting, the SAVI device MUST check 1492 whether each entry has been obsolete through comparing the saved 1493 lifetime and the difference between the current system time and saved 1494 system time. 1496 10. Constants 1498 MAX_DHCP_RESPONSE_TIME 120s 1500 DATA_SNOOPING_INTERVAL 60s and configurable 1502 MAX_LEASEQUERY_DELAY 10s 1504 OFFLINK_DELAY 30s 1506 DAD_TIMEOUT 0.5s 1508 11. MLD Consideration 1510 To perform the duplicate detection in Data Snooping Process 1511 Section 7, the SAVI device MUST join the Solicited Node Multicast 1512 group of the source address of triggering IPv6 data packet whenever 1513 performing duplicate detection. 1515 12. Security Considerations 1517 12.1. Security Problems about the Data Snooping Process 1519 There are two security problems about the Data Snooping Process 1520 Section 7: 1522 (1) The Data Snooping Process is costly, but an attacker can trigger 1523 it simply through sending a number of data packets. To avoid 1524 Denial of Services attack against the SAVI device itself, the 1525 Data Snooping Process MUST be rate limited. A constant 1526 DATA_SNOOPING_INTERVAL is used to control the frequency. Two 1527 Data Snooping Processes on one attachment MUST have a minimum 1528 interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be 1529 configured prudently to avoid Denial of Service attacks. 1531 (2) The Data Snooping Process may set up wrong bindings if the 1532 clients do not reply to the detection probes. An attack will 1533 pass the duplicate detection if the client assigned the target 1534 address does not reply to the detection probes. The DHCP 1535 Leasequery procedure performed by the SAVI device just tells 1536 whether the address is assigned in the network or not. However, 1537 the SAVI device cannot determine whether the address is just 1538 assigned to the triggering attachment from the DHCP Leasequery 1539 Reply. 1541 12.2. Issues about Leaving Clients 1543 After a binding is set up, the corresponding client may leave its 1544 attachment point. It may leave temporarily due to link flapping, or 1545 permanently due to it moves to a new attachment point or just leaves 1546 the network. Considering the client may be back shortly, the binding 1547 should be kept, or else the legtimate traffic from the client will be 1548 blocked. However, if the client leaves permanently, it may be 1549 insecure to keep the binding. In case that the binding anchor is a 1550 property of the attachment point rather than the client, e.g., the 1551 switch port, an attacker which is attached to the attachment point of 1552 the leaving client can send spoofing packets with the addresses 1553 assigned to the client. Even if the binding anchor is a property of 1554 the client, it is a waste of binding resource to keep bindings for 1555 left clients. 1557 The following mechanism is designed to handle the leaving of client: 1559 (1) Whenever a client of Validating attribute leaves, a timer of 1560 OFFLINK_DELAY is set with the corresponding binding entries. 1562 (2) If receiving DAD Neighbor Solicitation/Gratuitous ARP request 1563 targeting at the address during OFFLINK_DELAY, the entries MAY 1564 be removed. 1566 (3) If the binding anchor turns on-link during OFFLINK_DELAY, turn 1567 off the timer. 1569 In this way, the bindings of a leaving client is kept for 1570 OFFLINK_DELAY. In case of link flapping, the client will not be 1571 blocked. If the client leaves permanently, the bindings will be 1572 removes after OFFLINK_DELAY. 1574 12.3. Duplicate Bindings of the Same Address 1576 The same address may be bound with multiple binding anchors, only if 1577 the binding setup processes are finished on each binding anchor 1578 successfully. This mechanism is designed in consideration that a 1579 client may move on the local link, and a client may have multiple 1580 attachments to a SAVI device. 1582 There are two security issues about such a design: 1584 Firstly, due to allowing one address bound with multiple binding 1585 anchors, the traceability of address is weakened. An address can be 1586 traced to multiple attachments. 1588 Secondly, in the local link movement scenario, the former binding may 1589 not be removed and it can be made use of by an attacker sharing the 1590 same binding anchor. For example, when switch port is used as 1591 binding anchor and the port is shared by an attacker and a client 1592 with a hub, the attacker can make use of the address assigned to the 1593 client after the client leaves. 1595 12.4. Compatibility with DNA (Detecting Network Attachment) 1597 DNA [RFC4436] [RFC6059] is designed to decrease the handover latency 1598 after re-attachment to the same network. DNA mainly relies on 1599 performing reachability test through sending unicast Neighbor 1600 Solicitation/Router Solicitation/ARP Request message to determine 1601 whether a previously configured address is still valid. 1603 Though DNA provides optimization for clients, there is not sufficient 1604 information for this mechanism to migrate the previous binding or 1605 establish a new binding. If a binding is set up only through 1606 snooping the reachability test message, the binding can be invalid. 1607 For example, an attacker can perform reachability test with address 1608 bound to another client. If binding is migrated to the attacker, the 1609 attacker can successful obtain the binding from the victim. Because 1610 this mechanism wouldn't set up a binding based on snooping the DNA 1611 procedure, it cannot achieve perfect compatibility with DNA. 1612 However, it only means the re-configuration of the interface is 1613 slowed but not prevented. Details are discussed as follows. 1615 In Simple DNAv6 [RFC6059], the probe is sent with the source address 1616 set to a link-local address, and such messages will not be discarded 1617 by the policy specified in section Section 8.2. If a client is re- 1618 attached to a previous network, the detection will be completed, and 1619 the address will be regarded as valid by the client. However, the 1620 candidate address is not contained in the probe. Thus, the binding 1621 cannot be recovered through snooping the probe. As the client will 1622 perform DHCP procedure at the same time, the binding will be 1623 recovered from the DHCP Snooping Process. The DHCP Request messages 1624 will not be filtered out by this solution as they have link-local 1625 source addresses. Before the DHCP procedure is completed, packets 1626 will be filtered out by the SAVI device. In another word, if this 1627 SAVI function is enabled, Simple DNAv6 will not help reduce the 1628 handover latency. If Data-Snooping attribute is configured on the 1629 new attachment of the client, the data triggered procedure may reduce 1630 the latency. 1632 In DNAv4 [RFC4436], the ARP probe will be discarded because unbound 1633 address is used as sender protocol address. As a result, the client 1634 will regard the address under detection is valid. However, the data 1635 traffic will be filtered. The DHCP Request message sent by the 1636 client will not be discarded, because the source IP address field 1637 should be all zero as required by [RFC2131]. Thus, if the address is 1638 still valid, the binding will be recovered from the DHCP Snooping 1639 Process. 1641 12.5. Authentication in DHCPv6 Leasequery 1643 As required in section 5 of RFC5007, DHCPv6 Leasequery 'Should' use 1644 IPsec-based authentication specified in the section 21.1 of RFC3315. 1645 However, with the deployment of this mechanism, there may be no need 1646 to enforce IPSec to perform DHCP Leasequery. 1648 Through containing the DHCP servers in the protection perimeter, the 1649 DHCP servers can be protected from spoofing based attacks. Then 1650 through checking the source IP address of Leasequery messages, the 1651 DHCP server can identify if the messages are from SAVI devices or 1652 not. For the SAVI devices, because the perimeter filters out bogus 1653 DHCP messages, they can trust the DHCP Leasequery responses. Thus, 1654 there is no need to enforce IPSec to validate the DHCP Leasequery 1655 messages in this mechanism. 1657 12.6. Binding Number Limitation 1659 A binding entry will cost a certain high-speed memory resource. In 1660 general, a SAVI device can only afford a quite limited number of 1661 binding entries. In order to prevent an attacker from overloading 1662 the resource of the SAVI device, binding entry limit is set on each 1663 attachment. The binding entry limit is the upper bound of binding 1664 number for each attachment with Validating attribute. No new binding 1665 should be set up after the limit has been reached. Besides, if a 1666 DHCP Reply assigns more addresses than the remaining binding entry 1667 quota of each client, the message will be discarded and no binding 1668 will be set up. 1670 12.7. Residual Threats 1672 As described in [savi-framework], this solution cannot strictly 1673 prevent spoofing. There are two scenarios in which spoofing can 1674 still happen: 1676 (1) The binding anchor is spoofable. If the binding anchor is 1677 spoofable, e.g., plain MAC address, an attacker can use forged 1678 binding anchor to send packet which will not be regarded as 1679 spoofing by SAVI device. Indeed, using binding anchor that can 1680 be easily spoofed is more serious than allowing IP spoofing 1681 traffic. For example, an attacker can use the binding anchor of 1682 another client to get a large number of addresses, and the SAVI 1683 device will refuse to set up new binding for the client whenever 1684 the binding number limitation has been reached. Thus, it is 1685 RECOMMENDED to use strong enough binding anchor, e.g., switch 1686 port, secure association in 802.11ae/af and 802.11i. 1688 (2) The binding anchor is shared by more than one clients. If the 1689 binding anchor is shared by more than one clients, the clients 1690 can spoof the addresses of each other. For example, if switch 1691 port is used as binding anchor a number of clients can attach to 1692 the same switch port of a SAVI device through a hub. The SAVI 1693 device cannot distinguish packets from different clients and 1694 thus the spoofing between them will not be detected. A number 1695 of the above security problems are caused by sharing binding 1696 anchor. Besides, if binding anchor is shared, TID spoofing 1697 based attack is possible. Thus, it is RECOMMENDED to use 1698 exclusive binding anchor. 1700 13. IANA Considerations 1702 This memo asks the IANA for no new parameters. 1704 Note to RFC Editor: This section will have served its purpose if it 1705 correctly tells IANA that no new assignments or registries are 1706 required, or if those assignments or registries are created during 1707 the RFC publication process. From the authors' perspective, it may 1708 therefore be removed upon publication as an RFC at the RFC Editor's 1709 discretion. 1711 14. Acknowledgment 1713 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 1714 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 1715 Davies, Barry Leiba, Ted Lemon, Ralph Droms and Alberto Garcia for 1716 careful review and valuation comments on the mechanism and text. 1718 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 1719 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi 1720 Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 1721 their valuable contributions. 1723 This document was generated using the xml2rfc tool. 1725 15. References 1727 15.1. Informative References 1729 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 1730 Internet draft (work in progress), November 2007. 1732 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 1733 Defeating Denial of Service Attacks which employ IP Source 1734 Address Spoofing", RFC 2827, BCP 38, May 2000. 1736 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1737 (DHCP) Service for IPv6", RFC 3736, April 2004. 1739 15.2. Normative References 1741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1742 Requirement Levels", RFC 2119, BCP 14, Match 1997. 1744 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1745 RFC 2131, March 1997. 1747 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1748 and M. Carney, "Dynamic Host Configuration Protocol for 1749 IPv6 (DHCPv6)", RFC 3315, July 2003. 1751 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1752 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1754 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1755 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1757 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1758 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1759 September 2007. 1761 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1762 Address Autoconfiguration", RFC 4862, September 2007. 1764 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1765 "DHCPv6 Leasequery", RFC 5007, September 2007. 1767 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1768 July 2008. 1770 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1771 Detecting Network Attachment in IPv6", RFC 6059, 1772 November 2010. 1774 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1775 converting network protocol addresses to 48.bit Ethernet 1776 address for transmission on Ethernet hardware", RFC 826, 1777 November 1982. 1779 [savi-fcfs] 1780 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1781 SAVI: First-Come First-Serve Source-Address Validation for 1782 Locally Assigned Addresses", RFC 6620, May 2012. 1784 [savi-framework] 1785 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1786 "Source Address Validation Improvement Framework", 1787 draft-ietf-savi-framework-06 (work in progress), 1788 December 2011. 1790 Appendix A. change log 1792 Main changes from 02 to 03: 1794 (1) Section 12, data trigger and counter trigger are combined to 1795 binding recovery process. The expression "one of MUST" is 1796 changed to "conditional MUST. Conditions related with the 1797 implementation are specified. Related constants are changed in 1798 section 26." 1800 Main changes from 03 to 04: 1802 (1) Section "Prefix configuration" is removed. 1804 (2) Section "Supplemental binding process" is modified in 1805 requirement level. 1807 (3) Sub-section 9.1 "Rationale" is added. 1809 (4) Section "Filtering during Detection" is removed. 1811 (5) Section "Handling layer 2 path change" is changed to 1812 "Consideration on Link layer routing complexity" 1814 (6) Section "Background and related protocols" is removed. 1816 Main changes from 04 to 05: 1818 (1) Trigger events are listed explicitly in section 8. 1820 (2) Detection and Live states are deleted, together with 1821 corresponding sections. 1823 Main change from 05 to 06: 1825 (1) Section 8.1: reference to section 20 is changed to section 15. 1827 Main changes from 06 to 07: 1829 (1) So many changes in this modification. We suggest to track 1830 http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht ml. 1831 Changes are made according to the comments. 1833 Main changes from 07 to 08,09: 1835 (1) The modifications are made according to the comments from Jean- 1836 Michel Combes. 1838 Main changes from 09 to 11: 1840 (1) DNA issues raised by Jari Arkko 1842 Main changes from 11 to 12: 1844 (1) The modifications are made according to the comments from Eric, 1845 http://www.ietf.org/mail-archive/web/savi/current/msg01778.html. 1847 Main changes from 12 to 13: 1849 (1) Main modifications are made based on comments from Elwyn Davies. 1850 http://www.ietf.org/mail-archive/web/gen-art/current/ 1851 msg07297.html. 1853 (2) Other modifications are made based on comments from Barry Leiba. 1855 Main changes from 13 to 14: 1857 (1) A symbol error is corrected. 1859 Main changes from 14 to 15: 1861 (1) In corresponding to "1. Does section 8 describe the mechanism 1862 that a SAVI device must perform if it has been unable to snoop 1863 the DHCP traffic between a host and a DHCP server? It appears 1864 that way in the document, but it would be good to explicitly 1865 state that early in the document when the discussion of 1866 topologies is being carried out. This becomes important when 1867 arbitrary topologies do not provide a means for the SAVI device 1868 to eavesdrop on the DHCP traffic." We specified in s7.1 p1 that 1869 arbitrary topologies may result in the regular process cannot 1870 set up correct bindings. This is also specified in the 1871 beginning of s8. 1873 (2) In corresponding to "2. Section 12 refers to the "tentative 1874 address multicast group". Do you really mean the Solicited Node 1875 Multicast address that is generated from the configured IPv6 1876 unicast address?" Yes. We have changed s12 to "the SAVI device 1877 MUST join the Solicited Node Multicast group of the source 1878 address of triggering IPv6 data packet whenever performing 1879 duplicate detection." 1881 (3) Other modifications are made according to the gen-art review. 1882 Refer to http://netarchlab.tsinghua.edu.cn/~yaog/review.txt. 1884 Main changes from 15 to 16: 1886 (1) Main modifications are made according to the second-round gen- 1887 art review. 1889 (2) Improve the quality of writing. 1891 Main changes from 16 to 17: 1893 (1) Main modifications are made according to the review from Ted 1894 Lemon. 1896 Main changes from 17 to 18: Main modifications are made according to 1897 the review from Ralph Droms and Ted Lemon. 1899 (1) Add the definitions of upstream/downstream device/link. 1901 (2) In Section 6.3.2, that message without triggering a valid event 1902 will be forwarded if it can pass Section 8.2 is clarified. 1904 (3) All_DHCP_Servers is used instead of All_DHCP_Relays_and_Servers 1905 in Leasequery. Besides, "A list of DHCP server addresses" is 1906 used instead of "a DHCP server address". 1908 Main changes from 18 to 19: Main modifications are made according to 1909 the second round review from Ted Lemon. 1911 (1) Add the definitions of CUT VERTEX. 1913 (2) Change "Besides, the movement of DHCP clients may make bindings 1914 are not set up on their new attachments." in section 6.2 to 1915 "Besides, when a DHCP client moves from one attachment to 1916 another attachment in the same network, it may not reinitialize 1917 its interface or send a Confirm message because of imcomplete 1918 protocol implementation." 1920 (3) Modify the events and state transitions in section 6. 1922 (4) Specify the DHCP relay/server placement and authentication 1923 problem in section Section 4.3.3. 1925 Authors' Addresses 1927 Jun Bi 1928 Tsinghua University 1929 Network Research Center, Tsinghua University 1930 Beijing 100084 1931 China 1933 Email: junbi@tsinghua.edu.cn 1935 Jianping Wu 1936 Tsinghua University 1937 Computer Science, Tsinghua University 1938 Beijing 100084 1939 China 1941 Email: jianping@cernet.edu.cn 1943 Guang Yao 1944 Tsinghua University 1945 Network Research Center, Tsinghua University 1946 Beijing 100084 1947 China 1949 Email: yaoguang@cernet.edu.cn 1951 Fred Baker 1952 Cisco Systems 1953 Santa Barbara, CA 93117 1954 United States 1956 Email: fred@cisco.com