idnits 2.17.1 draft-ietf-savi-dhcp-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2012) is 4311 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) == Missing Reference: 'RFC5007' is mentioned on line 633, but not defined == Missing Reference: 'RFC3315' is mentioned on line 634, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Missing Reference: 'I-D.ietf-savi-framework' is mentioned on line 1214, but not defined Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Bi 3 Internet-Draft J. Wu 4 Intended status: Standards Track G. Yao 5 Expires: January 8, 2013 Tsinghua Univ. 6 F. Baker 7 Cisco 8 July 7, 2012 10 SAVI Solution for DHCP 11 draft-ietf-savi-dhcp-14 13 Abstract 15 This document specifies the procedure for creating bindings between a 16 DHCPv4/DHCPv6 assigned source IP address and a binding anchor on SAVI 17 (Source Address Validation Improvements) device. The bindings can be 18 used to filter packets generated on the local link with forged source 19 IP address in DHCP scenario. This mechanism is proposed as a 20 complement of ingress filtering to provide finer granularity source 21 IP 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 January 8, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. SAVI-DHCP Scenario . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Binding Anchor Attributes . . . . . . . . . . . . . . . . . . 7 74 5.1. No Attribute . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.2. SAVI-Validation Attribute . . . . . . . . . . . . . . . . 8 76 5.3. SAVI-DHCP-Trust Attribute . . . . . . . . . . . . . . . . 8 77 5.4. SAVI-SAVI Attribute . . . . . . . . . . . . . . . . . . . 8 78 5.5. SAVI-BindRecovery Attribute . . . . . . . . . . . . . . . 9 79 5.6. Table of Mutual Exclusions . . . . . . . . . . . . . . . . 9 80 6. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 10 81 6.1. Binding State Table (BST) . . . . . . . . . . . . . . . . 10 82 6.2. Mapping Table from Link Layer Address to Binding Anchor . 11 83 7. Procedure of Regular Binding Set Up . . . . . . . . . . . . . 11 84 7.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 11 85 7.2. Binding States Description . . . . . . . . . . . . . . . . 12 86 7.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 7.3.1. Timer Expiration Event . . . . . . . . . . . . . . . . 12 88 7.3.2. Control Message Arriving Events . . . . . . . . . . . 12 89 7.4. State Machine of DHCP Packet Snooping . . . . . . . . . . 13 90 7.4.1. From NO_BIND to Other States . . . . . . . . . . . . . 13 91 7.4.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 13 92 7.4.1.2. Following Actions . . . . . . . . . . . . . . . . 13 93 7.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 15 94 7.4.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 15 95 7.4.2.2. Following Actions . . . . . . . . . . . . . . . . 15 96 7.4.3. From BOUND to Other States . . . . . . . . . . . . . . 16 97 7.4.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 16 98 7.4.3.2. Following Actions . . . . . . . . . . . . . . . . 17 99 7.5. Table of State Machine . . . . . . . . . . . . . . . . . . 17 100 8. Supplemental Binding Process . . . . . . . . . . . . . . . . . 18 101 8.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 19 102 8.2. Additional Binding States Description . . . . . . . . . . 19 103 8.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 8.4. State Machine of Binding Recovery Process . . . . . . . . 19 105 8.4.1. From NO_BIND to Other States . . . . . . . . . . . . . 19 106 8.4.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 20 107 8.4.1.2. Following Action . . . . . . . . . . . . . . . . . 20 108 8.4.2. From DETECTION to Other States . . . . . . . . . . . . 21 109 8.4.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 21 110 8.4.2.2. Following Action . . . . . . . . . . . . . . . . . 21 111 8.4.3. From RECOVERY to Other States . . . . . . . . . . . . 21 112 8.4.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 21 113 8.4.3.2. Following Action . . . . . . . . . . . . . . . . . 21 114 8.4.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 22 115 8.4.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 22 116 8.4.4.2. Following Action . . . . . . . . . . . . . . . . . 22 117 9. Filtering Specification . . . . . . . . . . . . . . . . . . . 22 118 9.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 22 119 9.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 23 120 10. State Restoration . . . . . . . . . . . . . . . . . . . . . . 23 121 10.1. Binding Anchor Attribute Restoration . . . . . . . . . . . 23 122 10.2. Binding State Restoration . . . . . . . . . . . . . . . . 24 123 11. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 24 124 12. MLD Considerations . . . . . . . . . . . . . . . . . . . . . . 24 125 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 126 13.1. Security Problem about Binding Triggered by 127 EVE_DHCP_REPLY_NULL . . . . . . . . . . . . . . . . . . . 25 128 13.2. Binding Number Limitation . . . . . . . . . . . . . . . . 25 129 13.3. Risk from Link Layer Routing Dynamic . . . . . . . . . . . 26 130 13.4. Duplicate Bindings of Same Address . . . . . . . . . . . . 26 131 13.5. Security Problems about Binding Recovery Process . . . . . 27 132 13.6. Compatibility with DNA (Detecting Network Attachment) . . 27 133 13.7. Bogus DHCP Server Threat . . . . . . . . . . . . . . . . . 28 134 13.8. Handle Binding Anchor Off-link Event . . . . . . . . . . . 28 135 13.9. Residual Threats . . . . . . . . . . . . . . . . . . . . . 29 136 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 137 15. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 29 138 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 139 16.1. Informative References . . . . . . . . . . . . . . . . . . 30 140 16.2. Normative References . . . . . . . . . . . . . . . . . . . 30 141 Appendix A. change log . . . . . . . . . . . . . . . . . . . . . 31 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 144 1. Introduction 146 This document describes the procedure for creating a binding between 147 an address allocated to a network attachment point by DHCP and a 148 suitable binding anchor on a SAVI device. Binding anchor is defined 149 to be a link layer property of network attachment in 150 [savi-framework]. A list of proper binding anchors can be found in 151 the Section 3.2 of [savi-framework]. The bindings can be used to 152 filter or identify packets with forged source IP address. Section 9 153 suggests usage of these bindings to filter spoofing traffic in common 154 practice. 156 The mechanism specified in this document is designed to provide a 157 finer granularity source IP address validation, as a supplement to 158 [BCP38]. This mechanism mainly performs DHCP snooping to set up 159 bindings between IP addresses assigned by DHCP and corresponding 160 binding anchors. The binding process is inspired by the work of 161 [BA2007]. This mechanism covers DHCPv6 and binding recovery 162 procedure, which are not discussed in [BA2007]. 164 This solution is primarily designed for a pure DHCP scenario in which 165 only DHCP addresses are legitimate global addresses. And it is 166 designed for stateful DHCP scenario [rfc2131], [rfc3315]. In 167 stateless DHCP scenarios [rfc3736], a node must have obtained its 168 IPv6 addresses through some other mechanisms and so the address of 169 the client SHOULD be bound based on other SAVI solutions. 171 2. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [rfc2119]. 177 3. Terminology 179 SAVI-DHCP: The name of this SAVI instance for address assigned 180 through DHCP 182 SAVI device: A network device which enables this SAVI instance 184 Non-SAVI device: A network device without this SAVI instance 186 DHCP server/relay type message: Messages that can only originate from 187 DHCP server or relay. The list of such messages contains DHCPv4 ACK, 188 DHCPv4 NAK, DHCPv4 OFFER, DHCPv6 Reply, DHCPv6 Advertise, DHCPv6 189 Reconfiguration, DHCPv6 Relay-forward and DHCPv6 Relay-reply 190 Lease time: Lease time in IPv4 [rfc2131] and valid lifetime in IPv6 191 [rfc3315] 193 4. SAVI-DHCP Scenario 195 Figure 1 shows the main elements in a network where this mechanism is 196 deployed. One or more DHCP servers mediate the allocation and 197 distribution of IP addresses to hosts requesting them using the DHCP 198 protocol. DHCP relay may be used to relay message between client and 199 server. Multiple SAVI devices and non-SAVI devices can co-exist on 200 link. A SAVI device can be connected to DHCP client, DHCP relay 201 (even DHCP server), SAVI device and non-SAVI device. The attribute 202 of a binding anchor is determined by the role to which it is 203 connected, as specified in Section 5. 205 Protection perimeter (refer to Section 4 in [savi-framework]) is 206 formed by SAVI Device A and SAVI Device B for scalability. There is 207 no need to setup a binding for client A on SAVI device B, or to setup 208 a binding for client B on SAVI device A. 210 Other address assignment mechanisms may be also used in such a 211 network. However, this solution is primarily designed for a pure 212 DHCP scenario, in which only the DHCP servers can assign a valid 213 global address. 215 Note that in an IPv6 environment, every interface has a link-local 216 address, which is not assigned by DHCP. This solution will not 217 validate the link-local address. It is RECOMMENDED to enable a SAVI 218 solution for link-local addresses, e.g. [savi-fcfs]. 220 /------------\ 221 +--------+ | | +--------+ 222 |DHCP |-----| Router A | | Client | 223 |Server A| | | | C | 224 +--------+ \------------/ +--------+ 225 ......................|.......... | 226 . | . | 227 . Protection | . +--------+ 228 . Perimeter | . |Non-SAVI| 229 . | . |Device | 230 . | . +--------+ 231 . | . | 232 . +----------+ +---'------+ . | 233 . | SAVI | | SAVI |--.--------- 234 -----.-| Device A|----| Device B|--.--------- 235 | . +----|-----+ +-|------|-+ . | 236 | ................................. | 237 | | | | | 238 /----------\ | | | | 239 | | +-------+ +------+ +------+ +--------+ 240 | Router B | | Client| |DHCP | |Client| |DHCP | 241 | | | A | |Relay | |B | |Server B| 242 \----------/ +-------+ +------+ +------+ +--------+ 244 Figure 1: SAVI-DHCP Scenario 246 5. Binding Anchor Attributes 248 This section specifies the binding anchor attributes used by this 249 mechanism. Attributes are used to distinguish different types of 250 binding anchors. The procedure performed on each binding anchor is 251 determined by the attributes set on the binding anchor. 253 By default, a binding anchor has no attribute. A binding anchor MAY 254 be configured to have one or more compatible attributes. The 255 attribute of each binding anchor should be manually configured before 256 enabling this SAVI-DHCP function. 258 5.1. No Attribute 260 Before configuration, by default, a binding anchor has no attribute. 261 Generally, each binding anchor is configured to have one or more 262 attributes after configuration. 264 Considering the trivial of configuration, it is expected SAVI-DHCP 265 function will not cause a break of the network even though an 266 attribute is not configured. Thus, data packet filtering will not be 267 performed on binding anchor with no attribute. Note that if a 268 binding anchor has no attribute, it means SAVI-DHCP-Trust is not 269 configured on the binding anchor; thus, server type DHCP messages 270 from the binding anchor with no attribute will be discarded. 272 However, a binding anchor MAY have no attribute after configuration. 273 For example, in Figure 1, on the binding anchor of SAVI Device A 274 connected to Router B, it is unreasonable to set up bindings for the 275 host behind Router B, or filter out traffic from Router B, or allow 276 forged DHCP message from Router B. Thus, no attribute should be 277 configured on this binding anchor. 279 5.2. SAVI-Validation Attribute 281 SAVI-Validation attribute is used on a binding anchor on which the 282 source address of data packet and DHCP message is to be validated. 283 The filtering process on the binding anchor with such attribute is 284 described in section 9. In Figure 1, the binding anchor between SAVI 285 Device B and Client A, and the binding anchor between SAVI Device B 286 and Non SAVI Device should be configured to have this attribute. 288 5.3. SAVI-DHCP-Trust Attribute 290 SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a 291 trustable DHCP server/relay. DHCP server/relay type message coming 292 from binding anchor with this attribute will be forwarded. In 293 Figure 1, the binding anchor between SAVI Device B and DHCP Relay, 294 the binding anchor between SAVI Device B and DHCP Server B, and the 295 binding anchor between SAVI Device B and Router A should be 296 configured to have this attribute. 298 Note that if the binding anchor is not exclusive for the valid DHCP 299 server, messages from a valid DHCP server and a bogus DHCP server may 300 arrive with the same binding anchor with this attribute. Thus, only 301 relying on configuring this attribute may not protect the network 302 from bogus DHCP servers. In deployment, it is RECOMMENDED the 303 binding anchor for any DHCP server should be exclusive to the DHCP 304 server on the protection perimeter. The security problem related 305 with the bogus DHCP server and deployment options are discussed in 306 section 14.7. 308 5.4. SAVI-SAVI Attribute 310 This attribute is used on the binding anchor from which the data 311 traffic is not to be checked. Binding will not be set up on binding 312 anchor with this attribute. All data packets will be allowed 313 directly. In Figure 1, the binding anchor between SAVI Device A and 314 SAVI Device B should be configured with this attribute. DHCP server/ 315 relay type messages from a binding anchor with this attribute but 316 without SAVI-DHCP-Trust attribute will be filtered out. 318 Through configuring this attribute on binding anchor that joins two 319 or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes 320 implement the security perimeter concept in [savi-framework]. Since 321 no binding entry is needed on such binding anchors, the resource 322 requirement can be reduced significantly. 324 Though there is no factual difference in packet process between a 325 binding anchor with no attribute and a binding anchor only with SAVI- 326 SAVI attribute, their connotations are different. SAVI-SAVI 327 attribute is configured on binding anchor between SAVI devices on the 328 same link inside the protection perimeter. However only when a 329 binding anchor is on the protection perimeter and connected to 330 another link, then it can have no attribute after configuration. 332 5.5. SAVI-BindRecovery Attribute 334 If SAVI-Validation attribute is configured on a binding anchor, the 335 binding on this attribute is set up primarily based on DHCP message 336 snooping described in Section 7. However, in some scenarios, a DHCP 337 address may be used without previous DHCP exchange procedure 338 performed on the binding anchor, as discussed in Section 8. In such 339 scenarios, data-triggered binding procedure, which is described in 340 Section 8, is required to be performed. 342 This attribute is used on the binding anchor that requires data- 343 triggered binding recovery. It can be configured on any binding 344 anchor with SAVI-Validation attribute, especially when the binding 345 anchor is not directly attached by client. In Figure 1, it is 346 suggested to configure this attribute on binding anchor between SAVI 347 Device B and Non SAVI Device. 349 5.6. Table of Mutual Exclusions 351 Mutually exclusive attributes MUST NOT be set on the same binding 352 anchor. The compatibility of different attributes is listed in 353 Figure 2. 355 +-----------+------------+------------+------------+------------+ 356 | | SAVI- | SAVI- | SAVI- |SAVI- | 357 | | Validation | DHCP-Trust | SAVI |BindRecovery| 358 +-----------+------------+------------+------------+------------+ 359 |SAVI- | | | mutually | | 360 |Validation | - | compatible | exclusive | compatible | 361 +-----------+------------+------------+------------+------------+ 362 |SAVI- | | | | | 363 |DHCP-Trust | compatible | - | compatible | compatible | 364 +-----------+------------+------------+------------+------------+ 365 |SAVI- | mutually | | | mutually | 366 |SAVI | exclusive | compatible | - | exclusive | 367 +-----------+------------+------------+------------+------------+ 368 |SAVI- | | | | | 369 |Bind | | | mutually | | 370 |Recovery | compatible | compatible | exclusive | - | 371 +-----------+------------+------------+------------+------------+ 373 Figure 2: Table of Mutual Exclusions 375 6. Data Structures 377 This section describes the data structures used in this mechanism. 378 The main data structure, named Binding State Table, is used to record 379 bindings and their states. A mapping table from the link layer 380 address to the binding anchor may be required, as described in 381 Section 13.7 383 6.1. Binding State Table (BST) 385 This table contains the state of a binding between a source address 386 and a binding anchor. Entries are keyed on the binding anchor and 387 source IP address. Each entry has a lifetime field recording the 388 remaining lifetime of the entry, a state field recording the state of 389 the binding and a TID field recording Transaction ID (TID) [rfc2131] 390 [rfc3315] of DHCP message. The lifetime field is used to help remove 391 expired bindings. The state field changes over time to identify the 392 current state of the binding. States of bindings are specified in 393 Section 7.2 and Section 8.2. The TID field is used to keep the TID 394 in DHCP request. The TID field can be cleared after the state is 395 changed to BOUND. An instance of this table is shown in Figure 3. 397 +---------+----------+----------+-----------+-------+ 398 | Anchor | Address | State | Lifetime |TID | 399 +---------+----------+----------+-----------+-------+ 400 | A | IP_1 | BOUND | 65535 |TID_1 | 401 +---------+----------+----------+-----------+-------+ 402 | A | IP_2 | BOUND | 10000 |TID_2 | 403 +---------+----------+----------+-----------+-------+ 404 | B | IP_3 |INIT_BIND | 1 |TID_3 | 405 +---------+----------+----------+-----------+-------+ 407 Figure 3: Instance of BST 409 6.2. Mapping Table from Link Layer Address to Binding Anchor 411 As described in Section 7.4.2.2, whenever binding anchors must be 412 recovered from DCHP Reply, such a mapping table is required. This 413 table maps link layer address to binding anchor, so that the SAVI 414 device can determine on which binding anchor to set up a binding only 415 based on a DHCP Reply message. 417 Such a table can already exist on SAVI devices. For example, if the 418 binding anchor is a switch port, the mapping table from MAC address 419 to switch port is required for switching frames. We don't require 420 SAVI devices to set up a different mapping table from the existing 421 ones. Instead, the SAVI device MUST only use the existing one. 423 The set up and update of this table is out of the scope of this 424 document. 426 7. Procedure of Regular Binding Set Up 428 This section specifies the procedure of setting up bindings based on 429 DHCP message snooping. The binding procedure specified here is 430 exclusively designed for binding anchor with SAVI-Validation 431 attribute. 433 7.1. Rationale 435 The rationale of this mechanism is that if a node associated with a 436 binding anchor is legitimate to use a DHCP address, the DHCP 437 procedure which assigns the address to the node must have been 438 performed on the same binding anchor. This basis stands when the 439 link layer routing is stable. However, layer-2 mobility and unstable 440 link layer routing may result in that data packet is received from a 441 different binding anchor. Infrequent link layer path change can be 442 handled (but not perfectly) by the mechanism described in Section 8. 443 Section 13.3 discusses the situation that the link layer routing is 444 naturally unstable. A solution for this issue is outside the scope 445 of this document. 447 7.2. Binding States Description 449 This section describes the binding states of this mechanism. 451 NO_BIND: The state before a binding has been set up. 453 INIT_BIND: A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 454 Solicitation with Rapid Commit option) has been received from client, 455 and it may trigger a new binding. 457 BOUND: The address is authorized to the client. 459 7.3. Events 461 7.3.1. Timer Expiration Event 463 EVE_ENTRY_EXPIRE: The lifetime of an entry expires. 465 7.3.2. Control Message Arriving Events 467 Only if a control message can pass the check in Section 9.2, the 468 corresponding event is a valid event. For any message that may 469 trigger a new binding, the binding entry limit (cf. Section 13.2) on 470 the corresponding binding anchor MUST NOT have not been reached. 472 EVE_DHCP_REQUEST: A DHCP Request message is received from a binding 473 anchor with SAVI-Validation attribute. 475 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received from a binding 476 anchor with SAVI-Validation attribute. 478 EVE_DHCP_REBIND: A DHCPv6 Rebind message is received from a binding 479 anchor with SAVI-Validation attribute. 481 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 482 option is received from a binding anchor with SAVI-Validation 483 attribute. 485 EVE_DHCP_REPLY_LEASE: A DHCPv4 Acknowledgement or DHCPv6 Reply 486 message is received, and there is an entry with matched TID in the 487 BST, and lease time is contained in the message. 489 EVE_DHCP_REPLY_NOLEASE: A DHCPv4 Acknowledgement or DHCPv6 Reply 490 message is received, and there is an entry with matched TID in the 491 BST, and no lease time is contained in the message. 493 EVE_DHCP_REPLY_NULL: A DHCPv4 Acknowledgement or DHCPv6 Reply message 494 is received, and there is no entry in the BST contains the same TID 495 as the message. 497 EVE_DHCP_DECLINE: A DHCP Decline message is received from a binding 498 anchor with SAVI-Validation attribute. 500 EVE_DHCP_RELEASE: A DHCP Release message is received from a binding 501 anchor with SAVI-Validation attribute. 503 EVE_LEASEQUERY_REPLY: A successful DHCP LEASEQUERY_REPLY is received 504 from a binding anchor with SAVI-DHCP-Trust attribute. 506 7.4. State Machine of DHCP Packet Snooping 508 7.4.1. From NO_BIND to Other States 510 7.4.1.1. Trigger Event 512 EVE_DHCP_REQUEST, EVE_DHCP_OPTION_RC, EVE_DHCP_CONFIRM, 513 EVE_DHCP_REBIND, EVE_DHCP_REPLY_NULL. 515 7.4.1.2. Following Actions 517 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC: 519 The SAVI device MUST forward the message. 521 As illustrated in Figure 4, the SAVI device MUST generate an entry 522 for the binding anchor in the Binding State Table (BST) and set the 523 state field to INIT_BIND. The lifetime of this entry is set to be 524 MAX_DHCP_RESPONSE_TIME. The TID field of the triggering message MUST 525 be recorded in the entry. 527 The TID is stored because it will be used to correctly associate 528 message from the DHCP server with target binding anchor. 530 +---------+-------+---------+-----------------------+-------+ 531 | Anchor |Address| State | Lifetime |TID | 532 +---------+-------+---------+-----------------------+-------+ 533 | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 534 +---------+-------+---------+-----------------------+-------+ 535 Figure 4: Binding entry in BST on Request/Rapid Commit triggered 536 initialization 538 If the triggering event is EVE_DHCP_CONFIRM/EVE_DHCP_REBIND: 540 Besides forwarding the message and generating corresponding entry, 541 the address to confirm/rebind MUST be recorded in the entry, as 542 illustrated in Figure 5. The Lifetime field is set to 543 MAX_DHCP_RESPONSE_TIME. 545 +---------+--------+---------+-----------------------+-------+ 546 | Anchor | Address| State | Lifetime |TID | 547 +---------+--------+---------+-----------------------+-------+ 548 | A | Addr |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 549 +---------+--------+---------+-----------------------+-------+ 551 Figure 5: Binding entry in BST on Confirm/Rebind triggered 552 initialization 554 If the triggering event is EVE_DHCP_REPLY_NULL: 556 If the binding anchor is not a link layer address and there is not a 557 mapping table from the link layer address to the binding anchor, the 558 message SHOULD be discarded. 560 Else: 562 The SAVI device MUST generate as many new entries in BST as the 563 number of IADDR found in the message. If the binding anchor type 564 inside the BST is not a link layer address, the binding anchor for an 565 entry is recovered from the mapping table from the link layer address 566 to the binding anchor (cf. Section 6.2) based on the destination link 567 layer address inside the DHCP message. 569 As illustrated in Figure 6, the states of the corresponding entries 570 are set to be BOUND. The lifetimes of the entries are set to be the 571 lease time in the message. 573 The binding entry limit can be exceeded when setting up bindings for 574 all addresses in a REPLY message. If there is enough binding entry 575 resources, corresponding new entries MUST be generated even when the 576 binding number limit is exceeded. In case that there is not enough 577 resources left, the message MUST be discarded. 579 If the binding anchor is a switch port, there can be a vulnerability 580 in this process which is discussed in Section 13.1. Similar problems 581 can happen with other binding anchors. 583 +---------+----------+-------+------------------------+-------+ 584 | Anchor | Address | State | Lifetime |TID | 585 +---------+----------+-------+------------------------+-------+ 586 | A | Addr1 | BOUND | Lease time 1 |TID | 587 +---------+----------+-------+------------------------+-------+ 588 | A | Addr2 | BOUND | Lease time 2 |TID | 589 +---------+----------+-------+------------------------+-------+ 591 Figure 6: Binding entry in BST on Reply triggered initialization 593 7.4.2. From INIT_BIND to Other States 595 7.4.2.1. Trigger Event 597 EVE_DHCP_REPLY_LEASE, EVE_LEASEQUERY_REPLY, EVE_ENTRY_EXPIRE. 599 7.4.2.2. Following Actions 601 If the trigger event is EVE_DHCP_REPLY_LEASE: 603 As illustrated in Figure 7, If the Address field is null, the 604 lifetime field of the entry with matched TID is set to the sum of the 605 lease time in Reply message and MAX_DHCP_RESPONSE_TIME. The state of 606 the entry is changed to be BOUND. If more than one IADDR is found in 607 the message and there is enough binding entry resources, 608 corresponding new entries MUST be generated even when the binding 609 number limit is exceeded. If there is not enough resources left, the 610 message MUST be discarded. 612 +---------+----------+-------+------------------------+-------+ 613 | Anchor | Address | State | Lifetime |TID | 614 +---------+----------+-------+------------------------+-------+ 615 | A | Addr | BOUND |Lease time+ |TID | 616 | | | |MAX_DHCP_RESPONSE_TIME | | 617 +---------+----------+-------+------------------------+-------+ 618 Figure 7: From INIT_BIND to BOUND with Lease Time 620 If the trigger event is EVE_DHCP_REPLY_NOLEASE: 622 The triggering message is in response to a Confirm message. If the 623 message doesn't contain Status Code Success, discard the message. If 624 the message is of Status Code Success, the state of the entry is 625 changed to be BOUND. Because no lease time will be contained in the 626 REPLY from DHCP server, the SAVI device MUST lookup in BST to 627 determine whether there is an entry with the same address and TID. 628 If there is such an entry and the corresponding binding anchor is 629 off-link, it can be a local movement and the lifetime can be 630 recovered from the entry. In this case, set the Lifetime to be the 631 remaining value of Lifetime field of the existing entry, and remove 632 the existing entry. If there is no such an entry, the SAVI device 633 MUST send a LEASEQUERY [RFC5007] message querying by IP address to 634 All_DHCP_Relay_Agents_and_Servers multicast address [RFC3315] or a 635 configured server address. In this case, set the Lifetime of 636 corresponding entry to MAX_LEASEQUERY_DELAY, as illustrated in 637 Figure 8. 639 +---------+----------+-------+------------------------+-------+ 640 | Anchor | Address | State | Lifetime |TID | 641 +---------+----------+-------+------------------------+-------+ 642 | A | Addr | BOUND | MAX_LEASEQUERY_DELAY |TID | 643 +---------+----------+-------+------------------------+-------+ 645 Figure 8: From INIT_BIND to BOUND without Lease Time 647 If the trigger event is EVE_ENTRY_EXPIRE: 649 The entry MUST be deleted from BST. 651 7.4.3. From BOUND to Other States 653 7.4.3.1. Trigger Event 655 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 656 EVE_DHCP_REPLY_LEASE, EVE_LEASEQUERY_REPLY. 658 7.4.3.2. Following Actions 660 If the trigger event is EVE_ENTRY_EXPIRE: 662 Remove the corresponding entry in BST. 664 If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE: 666 Remove the corresponding entry in BST. The Release or Decline 667 message MUST be forwarded. 669 If the trigger event is EVE_DHCP_REPLY_LEASE: 671 Set the lifetime of the entry with the corresponding address and TID 672 to be the sum of the new lease time and MAX_DHCP_RESPONSE_TIME. 674 If the trigger event is EVE_LEASEQUERY_REPLY: 676 The Lifetime field of entry with corresponding IP address MUST be set 677 to the sum of the lease time in the LEASEQUERY_REPLY and 678 MAX_DHCP_RESPONSE_TIME. 680 7.5. Table of State Machine 682 The main state transits are listed as follows. 684 State Event Action Next State 685 NO_BIND REQ/RC/RB/CFM Generate entry INIT_BIND 686 *NO_BIND RPL_NULL Generate entry with lease BOUND 687 INIT_BIND RPLL Record lease time BOUND 688 INIT_BIND RPLN Send Leasequery/set LQ_DLY BOUND 689 INIT_BIND Timeout Remove entry NO_BIND 690 BOUND RLS/DCL Remove entry NO_BIND 691 BOUND Timeout Remove entry NO_BIND 692 BOUND RPLL Set new lifetime BOUND 693 BOUND LQR Record lease time BOUND 695 Figure 9: Table of Transit 697 *: optional but NOT RECOMMENDED. 699 REQ: EVE_DHCP_REQUEST 700 CFM: EVE_DHCP_CONFIRM 702 RC: EVE_DHCP_OPTION_RC 704 RB: EVE_DHCP_REBIND 706 RPLL: EVE_DHCP REPLY_LEASE 708 RPLN: EVE_DHCP REPLY_NOLEASE 710 RPL_NULL: EVE_DHCP REPLY_NULL 712 DCL: DHCP DECLINE 714 RLS: DHCP RELEASE 716 LQR: EVE_LEASEQUERY_REPLY 718 Timeout: EVE_ENTRY_EXPIRE 720 LQ_DLY: MAX_LEASEQUERY_DELAY 722 8. Supplemental Binding Process 724 Supplemental binding process is designed to cover scenarios where a 725 packet is sent by a node but no previous DHCP exchanges have occurred 726 to correctly update the SAVI device's BST. A typical situation is 727 when the link topology changes after the binding has been set up, and 728 then the node will send packets through a different port rather than 729 the bound port. Another scenario is that a node moves on the local 730 link without performing re-configuration process. 732 The binding recovery process is designed to avoid permanently 733 blocking legitimate traffic. This process is performed on binding 734 anchor with both SAVI-Validation and SAVI-BindRecovery attributes. 735 It is not supposed to set up a binding whenever a data packet with an 736 unbound source address is received. Generally, longer time and more 737 packets are needed to trigger supplemental binding processes. 739 Considering the overhead of this procedure, the implementation of 740 binding recovery process is a conditional SHOULD. This function 741 SHOULD be implemented unless the implementation is known to be 742 directly attached to the host. If an implementation is directly 743 attached to host, change in link topology will not affect the 744 bindings, and host will always start the re-configuration process 745 after the interface is re-connected. Thus, there is no need to use 746 additional processes to recovery bindings. If the mechanism is not 747 implemented and managed hosts are not directly attached, legitimate 748 traffic will be blocked until the node is reconfigured. 750 The security issues about this process is discussed is Section 13.5. 752 8.1. Rationale 754 If a DHCP address is allocated on the link, and the address is not 755 used by another node in the network, the address can be bound with 756 the binding anchor on which a message is received. 758 8.2. Additional Binding States Description 760 In addition to Section 7.2, new states used in this process are 761 required here: 763 DETECTION The address is under local detection. 765 RECOVERY The address is in binding recovery process. 767 8.3. Events 769 Additional events in this process are described here. Also, if an 770 event will trigger to set up a new binding entry, the binding entry 771 limit on the binding anchor MUST NOT have not been reached. 773 EVE_BR_UNMATCH A data packet without matched binding of BOUND state 774 in BST is received on a binding anchor with both SAVI-Validation and 775 SAVI-BindRecovery attributes. 777 EVE_BR_CONFLICT Response against an address in DETECTION state is 778 received. 780 EVE_BR_LEASEQUERY IPv4: a DHCPLEASEACTIVE message with IP Address 781 Lease Time option is received from a binding anchor with SAVI-DHCP- 782 Trust attribute; IPv6: a successful LEASEQUERY-REPLY is received. 784 8.4. State Machine of Binding Recovery Process 786 Through using additional states, the state machine of this process 787 doesn't conflict the regular process described in Section 7. Thus, 788 it can be implemented separately without changing the state machine 789 in Section 7. 791 8.4.1. From NO_BIND to Other States 792 8.4.1.1. Trigger Event 794 EVE_BR_UNMATCH. 796 8.4.1.2. Following Action 798 Determine whether to process this event with a probability. The 799 probability can be configured or calculated based on the state of the 800 SAVI device. This probability should be low enough to mitigate the 801 damage from DoS attack against this process. How to generate this 802 probability is out of the scope of this document. 804 If there is a corresponding binding in BST on another binding anchor 805 with the same source address, and the binding anchor is not off-link, 806 the packet SHOULD be dropped, and no further actions will not be 807 taken. 809 Check if the time since the last EVE_BR_UNMATCH on the same binding 810 anchor is larger than BIND_RECOVERY_INTERVAL. No further actions 811 will be taken if the last EVE_BR_UNMATCH on the same binding anchor 812 in the last BIND_RECOVERY_INTERVAL. 814 Create a new entry in the BST. Set the Binding Anchor field to the 815 corresponding binding anchor. Set the Address field to be source 816 address of the packet. Set the state field to DETECTION. Set the 817 lifetime of the created entry to 2*DAD_TIMEOUT. 819 Check if the address has a local conflict (it violates an address 820 being used by another node) through: 822 (1) IPv4 address: sending two Address Resolution Protocol (ARP) 823 Requests [rfc826]or two ARP probes [rfc5227] on the address; 825 (2) IPv6 address: performing Duplicate Address Detection (DAD) 826 [rfc4862] twice on the address. 828 The delay between the two messages is DAD_TIMEOUT. The detection is 829 performed twice to reduce the probability that the detection doesn't 830 reach targeting node in case of packet loss. 832 The messages MUST NOT be sent to the link with the binding anchor of 833 the triggering packet. 835 The packet which triggers this event SHOULD be discarded. 837 8.4.2. From DETECTION to Other States 839 8.4.2.1. Trigger Event 841 EVE_ENTRY_EXPIRE, EVE_BR_CONFLICT. 843 8.4.2.2. Following Action 845 If the trigger event is EVE_ENTRY_EXPIRE: 847 (1) IPv4 address: Send a DHCPLEASEQUERY [rfc4388] message querying 848 by IP address to all DHCPv4 servers with IP Address Lease Time 849 option (option 51). The server addresses can be found through 850 DHCPv4 Discovery or from configuration. Change the state of the 851 corresponding entry to RECOVERY. Change the lifetime of the 852 entry to be MAX_LEASEQUERY_DELAY. 854 (2) IPv6 address: Send a LEASEQUERY [rfc5007] message querying by IP 855 address to All_DHCP_Relay_Agents_and_Servers multicast address 856 or a configured server address. 858 Change the state of the corresponding entry to RECOVERY. Change the 859 lifetime of the entry to be MAX_LEASEQUERY_DELAY. 861 If the trigger event is EVE_BR_CONFLICT: 863 Remove the entry. 865 8.4.3. From RECOVERY to Other States 867 8.4.3.1. Trigger Event 869 EVE_ENTRY_EXPIRE, EVE_BR_LEASEQUERY. 871 8.4.3.2. Following Action 873 If the trigger event is EVE_BR_LEASEQUERY: 875 (1) IPv4 address: Change the state of the corresponding binding to 876 BOUND. Set life time to the sum of the value encoded in IP 877 Address Lease Time option of the DHCPLEASEACTIVE message and 878 MAX_DHCP_RESPONSE_TIME. 880 (2) IPv6 address: Change the state of the corresponding binding to 881 BOUND. Set the lifetime to the sum of the valid lifetime 882 extracted from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY 883 message and MAX_DHCP_RESPONSE_TIME. 885 If multiple addresses are specified in the LEASEQUERY-REPLY message, 886 new entries MUST also be created correspondingly on the same binding 887 anchor. 889 If the trigger event is EVE_ENTRY_EXPIRE: 891 Remove the entry. 893 8.4.4. After BOUND 895 Note that the TID field contains no value after the binding state 896 changes to BOUND. Because TID is used to associate entry with 897 message from server, attaching node will be prevented from renewing 898 the bound address. Thus, the TID field is recovered from snooping 899 DHCP Renew message. 901 8.4.4.1. Trigger Event 903 EVE_DHCP_RENEW. 905 8.4.4.2. Following Action 907 Set the TID field of the corresponding entry to the TID in the 908 trigger message. 910 9. Filtering Specification 912 This section specifies how to use bindings to filter packets. 914 Filtering policies are different for data packet and control packet. 915 DHCP and NDP (Neighbor Discovery Protocol) [rfc4861] messages that 916 may cause state transit are classified into control packet. Neighbor 917 Advertisement (NA) and ARP Response are also included in control 918 packet, because the Target Address of NA and ARP Response should be 919 checked to prevent spoofing. All other packets are considered to be 920 data packets. 922 9.1. Data Packet Filtering 924 Data packets with a binding anchor which has attribute SAVI- 925 Validation MUST be checked. 927 Packet whose source IP address is a link-local address SHOULD be 928 forwarded. 930 If the source IP address of a packet is not a link-local address, but 931 the address is not bound with the corresponding binding anchor, this 932 packet MUST be discarded. 934 The SAVI device MAY record any violation. 936 9.2. Control Packet Filtering 938 For binding anchors with SAVI-Validation attribute: 940 Discard DHCPv4 REQUEST message whose source IP address is neither all 941 zeros nor a bound address in BST. 943 Discard DHCPv6 Request message whose source is neither a link-local 944 address nor bound with the corresponding binding anchor in BST. 946 Discard NDP messages whose source address is neither a link-local 947 address nor bound with the corresponding binding anchor. In 948 addition, discard NA message whose target address is neither a link- 949 local address nor bound with the corresponding binding anchor. 951 Discard ARP messages whose protocol is IP and sender protocol address 952 is neither all zeros address nor bound with the corresponding binding 953 anchor. In addition, discard ARP Reply messages whose target address 954 is not bound with the corresponding binding anchor. 956 For other binding anchors: 958 Discard DHCP server/relay type message not from binding anchor with 959 the SAVI-DHCP-Trust attribute or SAVI-SAVI attribute. 961 The SAVI device SHOULD record any violation of the previous rules. 963 10. State Restoration 965 If a SAVI device reboots accidentally or designedly, the information 966 kept in volatile memory will be lost. This section specifies the 967 restoration of binding anchor attribute and binding state. 969 10.1. Binding Anchor Attribute Restoration 971 The configuration of binding anchor attribute is critical to this 972 mechanism. If this configuration is lost, DHCPv4 Acknowledgement/ 973 DHCPv6 Reply will be filtered. Though legitimate packet will not be 974 discarded, host will be prevented from getting new DHCP address or 975 renewing existing address. 977 To avoid the loss of binding anchor attribute configuration, the 978 configuration MUST be able to be stored in non-volatile storage. 980 After the reboot of SAVI device, if the configuration of binding 981 anchor attribute can be found in non-volatile storage, the 982 configuration MUST be used. 984 10.2. Binding State Restoration 986 The loss of binding state will cause legitimate traffic from host 987 indirectly attached to the SAVI device to be blocked until binding 988 recovery. Purely using the Binding Recovery Process to recover a 989 large number of bindings is of heavy overhead and results 990 considerable delay. Thus, recovery from non-volatile storage, as 991 specified below, is RECOMMENDED. 993 If this function is supported by hardware, binding entries MAY be 994 saved into non-volatile storage whenever a new binding entry changes 995 to BOUND state. If a binding with BOUND state is removed, the saved 996 entry MUST be removed correspondingly. 998 Immediately after reboot, the SAVI device SHOULD restore binding 999 states from the non-volatile storage. The system time of save 1000 process MUST be stored. After rebooting, the SAVI device MUST check 1001 whether each entry has been obsolete through comparing the saved 1002 lifetime and the difference between the current system time and saved 1003 system time. 1005 11. Constants 1007 MAX_DHCP_RESPONSE_TIME 120s 1009 BIND_RECOVERY_INTERVAL 60s and configurable 1011 MAX_LEASEQUERY_DELAY 10s 1013 OFFLINK_DELAY 30s 1015 DAD_TIMEOUT 0.5s 1017 12. MLD Considerations 1019 To perform the binding recovery procedure in Section 8, the SAVI 1020 device MUST join the tentative address multicast group whenever 1021 performing duplicate detection. 1023 13. Security Considerations 1025 13.1. Security Problem about Binding Triggered by EVE_DHCP_REPLY_NULL 1027 When the binding anchor is a switch port, binding based on 1028 EVE_DHCP_REPLY_NULL can result in security threats. The assigned 1029 address could be bound to a wrong switch port if an attacker can 1030 maliciously pollute the table mapping a link layer address to switch 1031 port (cf. Section 6.2). 1033 For example, host A requests address from port 1. When a SAVI switch 1034 receives a DHCP REPLY with assigned address IP_A and destination link 1035 layer address MAC_A, it will check its MAC/port table to find the 1036 right binding port. But MAC/port table might be polluted by an 1037 attacker host B attached to port 2. Then the SAVI switch will find 1038 the MAC_A is at port 2 from the polluted MAC/port table and it will 1039 result in a wrong binding which binds IP_A and port 2. 1041 Protection from this attack can be ensured by making sure that one of 1042 the following conditions is satisfied: 1044 (1) DHCP Option 82 is used to keep binding anchor in DHCP Request 1045 and Reply. DHCP Option 82 can be used to keep the circuit 1046 information of the client and returned by the DHCP server. Thus 1047 the binding anchor can be determined from the circuit 1048 information in the Option. It can be used whenever an 1049 implementation doesn't want to create an entry on the DHCP 1050 Request message. 1052 (2) Unspoofable MAC is used as binding anchor (802.11i, 802.1ae/af). 1054 (3) The mapping table from MAC to binding anchor is secure. 1056 If the binding anchor is a link layer address, or there are 1057 mechanisms preventing the corruption of the table mapping the link 1058 layer to a switch port, mapping link layer address to binding anchor 1059 may be considered as secure. 1061 It is NOT RECOMMENDED to initialize a binding based on DHCP Reply, 1062 unless a mechanism protecting the mapping table from corruption is 1063 also implemented. Similar problem may happen with binding anchors 1064 not based on link layer addresses. 1066 13.2. Binding Number Limitation 1068 It is suggested to configure some mechanism in order to prevent a 1069 single node from overloading the binding table entries on the SAVI 1070 device. Either of the following mechanism is sufficient to prevent 1071 such attack. 1073 (1) Set the upper bound of binding number for each binding anchor 1074 with SAVI-Validation. 1076 (2) Reserve a number of binding entries for each binding anchor with 1077 SAVI-Validation attribute and all binding anchors share a pool 1078 of the other binding entries. 1080 (3) Limit DHCP Request rate per binding anchor. 1082 13.3. Risk from Link Layer Routing Dynamic 1084 An implicit assumption of this solution is that data packet must 1085 arrive at the same binding anchor with the binding anchor that the 1086 control packets have arrived at. If this assumption is not valid, 1087 this control packet based solution will fail or at least discard a 1088 number of legitimate packets. Unfortunately, the link layer routing 1089 between host and SAVI device can be inconsistent from time to time. 1090 Time consistency of the link layer routing is not assured by the link 1091 layer routing protocol. For example, TRILL, a recent link layer 1092 routing protocol, is flexible and multiple link layer paths are 1093 allowed. 1095 To make the basic assumption stand, the best way is enforcing that 1096 there should be only one topology path from downstream host to the 1097 SAVI device. For example, SAVI device is directly attached by hosts. 1099 If the assumption doesn't stand, a better solution is requiring 1100 inter-operation between SAVI protocol and the link layer routing 1101 protocol to make SAVI protocol sensitive to the link layer routing 1102 change. This solution is above the scope of this document. 1104 13.4. Duplicate Bindings of Same Address 1106 The same address may be bound with multiple binding anchors, only if 1107 the binding processes are finished on each binding anchor 1108 successfully. This mechanism is designed in consideration that a 1109 node may move on the local link, and a node may have multiple binding 1110 anchors. However, the traceability of address is reduced. 1112 Note that the local link movement scenario is not handled perfectly. 1113 The former binding may not be removed, unless the node is directly 1114 attached to SAVI device. The nodes sharing the same former binding 1115 anchor of the moving node have the ability to use its address. 1117 13.5. Security Problems about Binding Recovery Process 1119 The Binding Recovery Process (cf. Section 8) MUST be rate limited to 1120 avoid Denial of Services attack against the SAVI device itself. A 1121 constant BIND_RECOVERY_INTERVAL is used to control the frequency. 1122 Two data-triggered recovery processes on one binding anchor MUST have 1123 a minimum interval time BIND_RECOVERY_INTERVAL. This constant SHOULD 1124 be configured prudently to avoid Denial of Service attacks. 1126 This process is not strictly secure. The node attached with a SAVI- 1127 BindRecovery binding anchor has the ability to use the address of an 1128 inactive node, which doesn't reply to the detection probes. 1130 13.6. Compatibility with DNA (Detecting Network Attachment) 1132 DNA [rfc4436] [rfc6059] is designed to decrease the handover latency 1133 after re-attachment to the same network. DNA mainly relies on 1134 performing reachability test through sending unicast Neighbor 1135 Solicitation/Router Solicitation/ARP Request message to determine 1136 whether a previously configured address is still valid. Though DNA 1137 provides optimization for host, it doesn't provide sufficient 1138 information for this mechanism to migrate or establish a binding. If 1139 a binding is set up only through snooping the reachability test 1140 message, the binding can be invalid. For example, an attacker can 1141 perform reachability test with address bound to another host. If 1142 binding is migrated to the attacker, the attacker can successful 1143 obtain the binding from the victim. Because this mechanism wouldn't 1144 set up a binding based on snooping the DNA procedure, it cannot 1145 achieve perfect compatibility with DNA. However, it only means the 1146 re-configuration of the interface is slowed but not prevented. 1147 Details are discussed as follows. 1149 In Simple DNAv6 [rfc6059], the probe is sent with source address set 1150 to link-local address, and such messages will not be filtered by the 1151 policy specified in section Section 9.2. If an interface is re- 1152 attached to a previous network, the detection will be complete and 1153 the address will be regarded as valid by host. The candidate address 1154 is not contained in the probe. Thus, the binding cannot be recovered 1155 through snooping the probe. The binding can only be recovered from 1156 the DHCP snooping procedure. The DHCP REQUEST messages wouldn't be 1157 filtered by this solution as their source address is link-local 1158 address. Before the DHCP procedure is completed, packets will be 1159 filtered by SAVI device. In another word, in SAVI scenarios, Simple 1160 DNAv6 will not help reduce the handover latency. If SAVI- 1161 BindRecovery attribute is configured on the new binding anchor, data 1162 triggered procedure may reduce the latency. 1164 In DNAv4 [rfc4436], the ARP probe will be filtered because unbound 1165 address is used as sender protocol address. As a result, the 1166 detection will not complete and false negative is caused. The DHCP 1167 REQUEST message sent by the node will not be filtered, because the 1168 source IP address field should be all zero as required by [rfc2131]. 1169 Thus, if the address is still valid, the binding will be recovered 1170 from the DHCP snooping procedure. 1172 13.7. Bogus DHCP Server Threat 1174 SAVI-DHCP-Trust attribute is designed to prevent attacks from bogus 1175 DHCP server. However, the security is not strict because messages 1176 from valid DHCP server and bogus DHCP server may arrive at the SAVI 1177 device with the same binding anchor. As a result, the SAVI device 1178 cannot recognize valid messages from bogus messages. Because the 1179 bindings are set up primarily based on DHCP message from DHCP server, 1180 the results can be quite serious. For example, invalid addresses are 1181 assigned to hosts and bindings of the addresses are set up. There 1182 can be a lot of other attacks in such a scenario. 1184 Considering the restraint that no new protocol can be introduced, the 1185 countermeasure is quite limited. If placing the DHCP server inside 1186 the protection perimeter, or making the path from each valid DHCP 1187 servers to the SAVI perimeter exclusive for DHCP servers, or 1188 filtering out DHCP server/relay type messages that may get into the 1189 path from each DHCP server to the protection perimeter, messages from 1190 bogus DHCP server cannot share the same binding anchor with messages 1191 from valid DHCP server, and such attack can be prevented. If none of 1192 the above deployment requirements can be satisfied, the network 1193 administrator should be aware of the above limitation and deploy this 1194 mechanism prudently. 1196 13.8. Handle Binding Anchor Off-link Event 1198 Port DOWN event MUST be handled if the switch port is used as the 1199 binding anchor. In a more general case, if a binding anchor turns 1200 off-link, this event MUST be handled. 1202 Whenever a binding anchor with attribute SAVI-Validation turns down, 1203 a timer of OFFLINK_DELAY is set. Until the timer becomes zero, the 1204 bindings with the binding anchor SHOULD be kept. As an exception to 1205 handle node movements, if receiving DAD Neighbor Solicitation/ 1206 Gratuitous ARP request targeting at the address during OFFLINK_DELAY, 1207 the entry MAY be removed. 1209 If the binding anchor turns on-link during OFFLINK_DELAY, turn off 1210 the timer and keep corresponding bindings. 1212 13.9. Residual Threats 1214 As described in [I-D.ietf-savi-framework], this solution cannot 1215 strictly prevent spoofing. There are two scenarios in which spoofing 1216 can still happen: 1218 (1) The binding anchor is spoofable. If the binding anchor is 1219 spoofable, e.g., plain MAC address, an attacker can use forged 1220 binding anchor to send packet which will not be regarded as 1221 spoofing by SAVI device. Indeed, using binding anchor that can 1222 be easily spoofed is dangerous. An attacker can use the binding 1223 anchor of another host to perform a lot of DHCP procedures, and 1224 the SAVI device will refuse to set up new binding for the host 1225 whenever the binding number limitation has been reached. Thus, 1226 it is RECOMMENDED to use strong enough binding anchor, e.g., 1227 switch port, secure association in 802.11ae/af and 802.11i. 1229 (2) The binding anchor is shared by more than one host. If the 1230 binding anchor is shared by more than one host, they can spoof 1231 the addresses of each other. For example, a number of hosts can 1232 attach to the same switch port of a SAVI device through a hub. 1233 The SAVI device cannot distinguish packets from different hosts 1234 and thus the spoofing between them will not be detected. This 1235 problem can be solved by not sharing binding anchor between 1236 hosts. 1238 14. IANA Considerations 1240 This memo asks the IANA for no new parameters. 1242 Note to RFC Editor: This section will have served its purpose if it 1243 correctly tells IANA that no new assignments or registries are 1244 required, or if those assignments or registries are created during 1245 the RFC publication process. From the authors' perspective, it may 1246 therefore be removed upon publication as an RFC at the RFC Editor's 1247 discretion. 1249 15. Acknowledgment 1251 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. 1252 Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn 1253 Davies, Barry Leiba and Alberto Garcia for careful review and 1254 valuation comments on the state machine and text. 1256 Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David 1257 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg 1258 Daley, John Kaippallimalil and Tao Lin for their valuable 1259 contributions. 1261 This document was generated using the xml2rfc tool. 1263 16. References 1265 16.1. Informative References 1267 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 1268 Internet draft (work in progress), November 2007. 1270 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 1271 Defeating Denial of Service Attacks which employ IP Source 1272 Address Spoofing", RFC 2827, BCP 38, May 2000. 1274 [rfc3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1275 (DHCP) Service for IPv6", RFC 3736, April 2004. 1277 16.2. Normative References 1279 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 1280 Requirement Levels", RFC 2119, BCP 14, Match 1997. 1282 [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", 1283 RFC 2131, March 1997. 1285 [rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1286 and M. Carney, "Dynamic Host Configuration Protocol for 1287 IPv6 (DHCPv6)", RFC 3315, July 2003. 1289 [rfc4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1290 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1292 [rfc4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1293 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1295 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1296 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1297 September 2007. 1299 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1300 Address Autoconfiguration", RFC 4862, September 2007. 1302 [rfc5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1303 "DHCPv6 Leasequery", RFC 5007, September 2007. 1305 [rfc5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1306 July 2008. 1308 [rfc6059] Krishnan, S. and G. Daley, "Simple Procedures for 1309 Detecting Network Attachment in IPv6", RFC 6059, 1310 November 2010. 1312 [rfc826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1313 converting network protocol addresses to 48.bit Ethernet 1314 address for transmission on Ethernet hardware", RFC 826, 1315 November 1982. 1317 [savi-fcfs] 1318 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1319 SAVI: First-Come First-Serve Source-Address Validation for 1320 Locally Assigned Addresses", RFC 6620, May 2012. 1322 [savi-framework] 1323 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1324 "Source Address Validation Improvement Framework", 1325 draft-ietf-savi-framework-06 (work in progress), 1326 December 2011. 1328 Appendix A. change log 1330 Main changes from 02 to 03: 1332 (1) Section 12, data trigger and counter trigger are combined to 1333 binding recovery process. The expression "one of MUST" is 1334 changed to "conditional MUST. Conditions related with the 1335 implementation are specified. Related constants are changed in 1336 section 26." 1338 Main changes from 03 to 04: 1340 (1) Section "Prefix configuration" is removed. 1342 (2) Section "Supplemental binding process" is modified in 1343 requirement level. 1345 (3) Sub-section 9.1 "Rationale" is added. 1347 (4) Section "Filtering during Detection" is removed. 1349 (5) Section "Handling layer 2 path change" is changed to 1350 "Consideration on Link layer routing complexity" 1352 (6) Section "Background and related protocols" is removed. 1354 Main changes from 04 to 05: 1356 (1) Trigger events are listed explicitly in section 8. 1358 (2) Detection and Live states are deleted, together with 1359 corresponding sections. 1361 Main change from 05 to 06: 1363 (1) Section 8.1: reference to section 20 is changed to section 15. 1365 Main changes from 06 to 07: 1367 (1) So many changes in this modification. We suggest to track 1368 http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht ml. 1369 Changes are made according to the comments. 1371 Main changes from 07 to 08,09: 1373 (1) The modifications are made according to the comments from Jean- 1374 Michel Combes. 1376 Main changes from 09 to 11: 1378 (1) DNA issues raised by Jari Arkko 1380 Main changes from 11 to 12: 1382 (1) The modifications are made according to the comments from Eric, 1383 http://www.ietf.org/mail-archive/web/savi/current/msg01778.html. 1385 Main changes from 12 to 13: 1387 (1) Main modifications are made based on comments from Elwyn Davies. 1388 http://www.ietf.org/mail-archive/web/gen-art/current/ 1389 msg07297.html. 1391 (2) Other modifications are made based on comments from Barry Leiba. 1393 Main changes from 13 to 14: 1395 (1) A symbol error is corrected. 1397 Authors' Addresses 1399 Jun Bi 1400 Tsinghua University 1401 Network Research Center, Tsinghua University 1402 Beijing 100084 1403 China 1405 Email: junbi@tsinghua.edu.cn 1407 Jianping Wu 1408 Tsinghua University 1409 Computer Science, Tsinghua University 1410 Beijing 100084 1411 China 1413 Email: jianping@cernet.edu.cn 1415 Guang Yao 1416 Tsinghua University 1417 Network Research Center, Tsinghua University 1418 Beijing 100084 1419 China 1421 Email: yaoguang@cernet.edu.cn 1423 Fred Baker 1424 Cisco Systems 1425 Santa Barbara, CA 93117 1426 United States 1428 Email: fred@cisco.com