idnits 2.17.1 draft-ietf-savi-dhcp-12.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([RFC3315], [RFC2131], [I-D.ietf-savi-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended status: Standard Tracks', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (February 8, 2012) is 4462 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: 'RFC4436' is mentioned on line 964, but not defined == Unused Reference: 'RFC4426' is defined on line 1049, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-savi-framework (ref. 'I-D.ietf-savi-framework') ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi, J. Wu, G. Yao 2 Internet Draft Tsinghua Univ. 3 Intended status: Standard Tracks F. Baker 4 Expires: August 2012 Cisco Systems 5 February 8, 2012 7 SAVI Solution for DHCP 8 draft-ietf-savi-dhcp-12.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to publish it 15 as an RFC and to translate it into languages other than English. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on August 3, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document specifies the procedure for creating bindings between a 52 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a 53 binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address 54 Validation Improvements) device. The bindings can be used to filter 55 packets generated on the local link with forged source IP address. 57 Table of Contents 59 Copyright Notice ............................................... 1 60 Abstract ....................................................... 2 61 1. Introduction ................................................ 3 62 2. Conventions used in this document............................ 4 63 3. Terminology ................................................. 4 64 4. SAVI-DHCP Scenario .......................................... 4 65 5. Data Structures ............................................. 5 66 5.1. Control Plane Data Structure: Binding State Table (BST). 5 67 5.2. Data Plane Data Structure: Filtering Table (FT)......... 6 68 5.3. Mapping Table from Link Layer Address to Binding Anchor. 6 69 6. Binding Anchor Attributes.................................... 7 70 6.1. No Attribute ........................................... 7 71 6.2. SAVI-Validation Attribute............................... 7 72 6.3. SAVI-DHCP-Trust Attribute............................... 7 73 6.4. SAVI-SAVI Attribute..................................... 8 74 6.5. SAVI-BindRecovery Attribute............................. 8 75 7. Binding Set Up .............................................. 8 76 7.1. Rationale .............................................. 9 77 7.2. Binding States Description.............................. 9 78 7.3. Events ................................................. 9 79 7.3.1. Timer Expiration Event............................. 9 80 7.3.2. Control Message Arriving Events ................... 9 81 7.4. Process of DHCP Packet Snooping ....................... 10 82 7.4.1. From NO_BIND to Other States ..................... 10 83 7.4.1.1. Trigger Event................................ 10 84 7.4.1.2. Following Actions............................ 10 85 7.4.2. From INIT_BIND to Other States ................... 12 86 7.4.2.1. Trigger Event................................ 12 87 7.4.2.2. Following Actions............................ 12 88 7.4.3. From BOUND to Other States ....................... 13 89 7.4.3.1. Trigger Event................................ 13 90 7.4.3.2. Following Actions............................ 13 91 7.5. State Machine of DHCP Snooping ........................ 14 93 8. Supplemental Binding Process................................ 15 94 8.1. Binding Recovery Process............................... 15 95 9. Filtering Specification..................................... 16 96 9.1. Data Packet Filtering.................................. 17 97 9.2. Control Packet Filtering............................... 17 98 10. State Restoration ......................................... 18 99 11. Handle Binding Anchor Off-link Event ...................... 18 100 12. Constants ................................................. 18 101 13. Security Considerations.................................... 19 102 13.1. Security Problem about Binding Triggered by 103 EVE_DHCP_REPLY_NULL ........................................ 19 104 13.2. Binding Number Limitation............................. 20 105 13.3. Risk from Link Layer Routing Dynamic ................. 20 106 13.4. Duplicate Bindings of Same Address ................... 20 107 13.5. Security Problems about Binding Recovery Process...... 21 108 13.6. Compatibility with DNA (Detecting Network Attachment). 21 109 13.7. Residual Threats...................................... 22 110 14. IANA Considerations........................................ 22 111 15. References ................................................ 23 112 15.1. Normative References.................................. 23 113 15.2. Informative References................................ 24 114 16. Acknowledgments ........................................... 24 115 17. Change Log ................................................ 25 117 1. Introduction 119 This document describes the procedure for creating binding between 120 DHCP address and binding anchor on SAVI device [I-D.ietf-savi- 121 framework]. The removal and restoration of the bindings are also 122 specified in this document. 124 Bindings can be used to filter or identify packets with forged source 125 IP address. Section 9 suggests usage of these bindings for common 126 practice. 128 The mechanism specified in this document is designed to provide a 129 binding anchor granularity validation, as a supplement to BCP38 130 [BCP38]. This mechanism is deployed on the access device (including 131 access switch, wireless access point/controller, etc), and performs 132 mainly DHCP snooping to set up bindings between IP addresses assigned 133 by DHCP and corresponding binding anchors. The binding process is 134 inspired by the work of IP Source Guard [IP Source Guard]. 136 This solution is designed for stateful DHCP scenario [RFC2131], 137 [RFC3315]. In stateless DHCP scenarios [RFC3736], a node must have 138 obtained its IPv6 addresses through some other mechanisms and so the 139 address of the client SHOULD be bound based on other SAVI solutions 140 This solution is primarily designed for a pure DHCP scenario in which 141 only DHCP address is legitimate global address. How to use this 142 mechanism in multiple address assignments scenario is discussed in 143 [I-D.ietf-savi-mix]. 145 2. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 [RFC2119]. 152 3. Terminology 154 Lease time: Lease time in IPv4 [RFC2131] and valid lifetime in 155 IPv6 [RFC3315] 157 4. SAVI-DHCP Scenario 159 Figure 1 shows the main elements in a DHCP network. At least one DHCP 160 server must be deployed in the network, and DHCP relay may be used to 161 relay message between client and server. Multiple SAVI devices and 162 non-SAVI devices can co-exist on link. A SAVI device can be connected 163 to DHCP client, DHCP relay (even DHCP server), SAVI device and non- 164 SAVI device. 166 Other address assignment mechanisms may be also used in such a 167 network. However, this solution is primarily designed for a pure DHCP 168 scenario, in which only DHCP servers can assign valid global address. 170 Note that in IPv6 environment, every interface has a link-local 171 address, which is not assigned by DHCP. This solution will not 172 validate link-local address. It is SUGGESTED to enable a SAVI 173 solution for link-local addresses, e.g. [I-D.ietf-savi-fcfs]. 175 /------------\ 176 +--------+ | | 177 | DHCP |-----| Router A | 178 | Server | | | 179 +--------+ \------------/ 180 ......................|.......... 181 . | . 182 . Protection | . 183 . Perimeter | . 184 . | . 185 . | . 186 . | . 187 . +----------+ +----'-----+ . +----------+ 188 . | SAVI | | SAVI | . | Non SAVI| 189 . | Device A|----| Device B|------| Device | 190 . +/---.-----+ +-.------.-+ . +-----.----+ 191 ................................. | 192 | | | | 193 | | | | 194 +----/-----+ +----\-+ +\-----+ +--\---+ 195 | Router B | |DHCP | |Client| |Client| 196 | | |Relay | | A | | B | 197 +----------+ +------+ +------+ +------+ 198 Figure 1 DHCP Scenario 200 5. Data Structures 202 This section describes the data structures used in this mechanism. 204 Two main data structures are used to record bindings and their states 205 respectively. There is redundancy between the two structures, for the 206 consideration of separation of data plane and control plane. 208 Besides the two main data structures, a mapping table from link layer 209 address to binding anchor may be required, as described in section 210 7.4.1. 212 5.1. Control Plane Data Structure: Binding State Table (BST) 214 This table contains the state of binding between source address and 215 binding anchor. Entries are keyed on the binding anchor and source IP 216 address. Each entry has a lifetime field recording the remaining 217 lifetime of the entry, a state field recording the state of the 218 binding and a TID field recording transaction ID of DHCP message. The 219 lifetime field is used to help remove expired bindings. The state 220 field is used to identify state. The TID field is used to keep the 221 Transaction ID (TID) [RFC2131][RFC3315] in DHCP request. The TID 222 field can be cleared after the state is changed to BOUND. 224 +---------+----------+----------+-----------+-------+ 225 | Anchor | Address | State | Lifetime |TID | 226 +---------+----------+----------+-----------+-------+ 227 | A | IP_1 | BOUND | 65535 |TID 1 | 228 +---------+----------+----------+-----------+-------+ 229 | A | IP_2 | BOUND | 10000 |TID 2 | 230 +---------+----------+----------+-----------+-------+ 231 | B | IP_3 |INIT_BIND | 1 |TID_3 | 232 +---------+----------+----------+-----------+-------+ 233 Figure 2 Instance of BST 235 5.2. Data Plane Data Structure: Filtering Table (FT) 237 This table contains the bindings between binding anchor and address, 238 keyed on binding anchor and address. This table doesn't contain any 239 state of the binding. This table is only used to filter packets. An 240 Access Control List can be regarded as a practical instance of this 241 table. This table SHOULD be updated by other SAVI mechanisms [I- 242 D.ietf-savi-mix] when DHCP SAVI is deployed in IPv6 environment, as 243 explained in section 4. 245 +---------+----------+ 246 | Anchor |Address | 247 +---------+----------+ 248 |A |IP_1 | 249 +---------+----------+ 250 |A |IP_2 | 251 +---------+----------+ 252 Figure 3 Instance of FT 254 5.3. Mapping Table from Link Layer Address to Binding Anchor 256 As described in section 7.4.1, whenever binding anchor must be 257 recovered from DCHP Reply, such a mapping table is required. This 258 table maps link layer address to binding anchor, so as that the SAVI 259 device can determine on which binding anchor to set up a binding only 260 based on a DHCP Reply message. 262 Such a table can already exist on SAVI device. For example, if the 263 binding anchor is switch port, the mapping table from MAC address to 264 switch port is required on switch for switching frames. We don't 265 require SAVI device to set up a different mapping table from the 266 existing one. Instead, SAVI device MUST only use the existing one. If 267 there is not such a mapping table yet, SAVI device MUST NOT set up 268 binding based on EVE_DHCP_REPLY_NULL (cf. 7.4.1). 270 The set up and update of this table is out of the scope of this 271 document. 273 6. Binding Anchor Attributes 275 This section specifies the binding anchor attributes used in this 276 mechanism. 278 Attribute of each binding anchor is configurable. By default, binding 279 anchor has no attribute. A binding anchor MAY be configured to have 280 one or more compatible attributes. 282 6.1. No Attribute 284 Before configuration, by default, a binding anchor has no attribute. 285 To filter bogus DHCP server message by default, server type DHCP 286 message from binding anchor with no attribute MUST be dropped. 287 However, to avoid discarding legitimate traffic, other packets SHOULD 288 NOT be dropped before any binding is setup on such binding anchor. 289 Generally, each binding anchor is configured to have one or more 290 attributes after configuration. However, a binding anchor MAY always 291 have no attribute if it is connected to another link. For example, in 292 Figure 1, on the binding anchor of SAVI Device A connected to Router 293 B, it is unreasonable either to set up bindings for host behind 294 Router B, or filter out traffic from Router B, or allow bogus DHCP 295 message from Router B. Thus, no attribute should be configured on 296 this binding anchor. 298 6.2. SAVI-Validation Attribute 300 SAVI-Validation attribute is used on binding anchor on which the 301 source address of data packet and DHCP message is to be validated. 302 The filtering process on binding anchor with such attribute is 303 described in section 9. In Figure 1, the binding anchor between SAVI 304 Device B and Client A, and the binding anchor between SAVI Device B 305 and Non SAVI Device should be configured to have this attribute. 307 6.3. SAVI-DHCP-Trust Attribute 309 SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a 310 trustable DHCP server/relay. DHCP server/relay message coming from 311 binding anchor with this attribute will be forwarded. In Figure 1, 312 the binding anchor between SAVI Device B and DHCP Relay, and the 313 binding anchor between SAVI Device B and Router A, should be 314 configured to have this attribute. 316 6.4. SAVI-SAVI Attribute 318 This attribute is used on binding anchor from which the data traffic 319 is not to be checked. Binding will not be set up on binding anchor 320 with this attribute. All data packets will be allowed directly. In 321 Figure 1, the binding anchor between SAVI Device A and SAVI Device B 322 should be configured with this attribute. 324 Through configuring this attribute on binding anchor that joins two 325 or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes 326 implement the security perimeter concept in [I-D.ietf-savi- 327 framework]. Since no binding entry is needed on such binding anchor, 328 the resource requirement can be reduced greatly. 330 Though there is no factual difference in packet process between a 331 binding anchor with no attribute and a binding anchor only with SAVI- 332 SAVI attribute, their connotations are different. SAVI-SAVI attribute 333 is configured on binding anchor between SAVI devices on the same link 334 inside the protection perimeter. But only when a binding anchor is on 335 the protection perimeter and connected to another link, it can have 336 no attribute after configuration. 338 This attribute is mutually exclusive with SAVI-Validation. 340 6.5. SAVI-BindRecovery Attribute 342 This attribute is used on binding anchor that requires data-triggered 343 binding recovery described in section 8.1. It can be configured on 344 any binding anchor with SAVI-Validation attribute, especially, the 345 binding anchor 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 This attribute is mutually exclusive with SAVI-SAVI. 351 7. Binding Set Up 353 This section specifies the procedure of setting up bindings based on 354 DHCP message snooping. The binding procedure specified here is 355 exclusively designed for binding anchor with SAVI-Validation 356 attribute. 358 7.1. Rationale 360 The rationale of this mechanism is that if a node attached to a 361 binding anchor is legitimate to use a DHCP address, the DHCP 362 procedure which assigns the address to the node must have been 363 performed on the same binding anchor. This basis stands when the link 364 layer routing is stable. However, layer-2 mobility and unstable link 365 layer routing may result in that data packet is received from a 366 different binding anchor. Infrequent link layer path change can be 367 handled (but not perfectly) by the mechanism described in section 8. 368 Section 13.3 discusses the situation that link layer routing is 369 naturedly unstable. A solution for this issue is outside the scope of 370 this document. 372 7.2. Binding States Description 374 This section describes the binding states of this mechanism. 376 NO_BIND The state before a binding has been set up. 378 INIT_BIND A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 379 Solicitation with Rapid Commit option) has been received from host, 380 and it may trigger a new binding. 382 BOUND The address is authorized to the client. 384 7.3. Events 386 7.3.1. Timer Expiration Event 388 EVE_ENTRY_EXPIRE: The lifetime of an entry expires 390 7.3.2. Control Message Arriving Events 392 Only if a control message can pass the check in section 9.2, the 393 corresponding event is a valid event. 395 EVE_DHCP_REQUEST: A DHCP Request message is received from a binding 396 anchor with SAVI-Validation attribute, and the binding entry limit 397 (cf. section 13.2) on the binding anchor has not been reached. 399 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received from a binding 400 anchor with SAVI-Validation attribute, and the binding entry limit on 401 the binding anchor has not been reached. 403 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 404 option is received from a binding anchor with SAVI-Validation 405 attribute, and the binding entry limit on the binding anchor has not 406 been reached. 408 EVE_DHCP_REPLY: A DHCPv4 Acknowledgement or DHCPv6 Reply message is 409 received from a binding anchor with SAVI-DHCP-Trust attribute, and 410 the message should be forwarded to a binding anchor with SAVI- 411 Validation attribute. 413 EVE_DHCP_REPLY_NULL: A DHCPv4 Acknowledgement or DHCPv6 Reply message 414 is received from a binding anchor with SAVI-DHCP-Trust attribute, and 415 there is no entry in state INIT_BIND contains the same TID as the 416 message. 418 EVE_DHCP_DECLINE: A DHCP Decline message is received from a binding 419 anchor with SAVI-Validation attribute. 421 EVE_DHCP_RELEASE: A DHCP Release message is received from a binding 422 anchor with SAVI-Validation attribute. 424 EVE_LEASEQUERY_REPLY: A successful DHCP LEASEQUERY_REPLY is received 425 from a binding anchor with SAVI-DHCP-Trust attribute. 427 7.4. Process of DHCP Packet Snooping 429 7.4.1. From NO_BIND to Other States 431 7.4.1.1. Trigger Event 433 EVE_DHCP_REQUEST, EVE_DHCP_CONFIRM, EVE_DHCP_OPTION_RC, 434 EVE_DHCP_REPLY_NULL. 436 7.4.1.2. Following Actions 438 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC: 440 The SAVI device MUST forward the message. 442 The SAVI device MUST generate an entry for the binding anchor in 443 the Binding State Table (BST) and set the state field to INIT_BIND. 444 The lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME. 445 The TID field of the request packet MUST be recorded in the entry. 447 +---------+-------+---------+-----------------------+-------+ 448 | Anchor |Address| State | Lifetime |TID | 449 +---------+-------+---------+-----------------------+-------+ 450 | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 451 +---------+-------+---------+-----------------------+-------+ 452 Figure 4 Binding entry in BST on client triggered initialization 454 The TID is stored because it will be used in a future step (cf. 455 section 7.4.2.2) to correctly associate the assigned address to the 456 binding anchor. 458 If the triggering event is EVE_DHCP_CONFIRM: 460 Besides forwarding the message and generating corresponding entry, 461 the address to be confirmed MUST be recorded in the entry. Because 462 no lease time will be contained in the REPLY from DHCP server, the 463 SAVI device MUST lookup in BST to determine whether there is an 464 entry with the same address. If there is such an entry, it can be a 465 local movement and the lifetime can be recovered from the entry. If 466 there is not, the SAVI device MUST send a LEASEQUERY [RFC5007] 467 message querying by IP address to All_DHCP_Relay_Agents_and_Servers 468 multicast address [RFC3315] or a configured server address. 470 +---------+--------+---------+-----------------------+-------+ 471 | Anchor | Address| State | Lifetime |TID | 472 +---------+--------+---------+-----------------------+-------+ 473 | A | Addr |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 474 +---------+--------+---------+-----------------------+-------+ 475 Figure 5 Binding entry in BST on Confirm triggered initialization 477 If the triggering event is EVE_DHCP_REPLY_NULL: 479 If the binding anchor is not link layer address and there is not a 480 mapping table from link layer address to binding anchor, the 481 message SHOULD be discarded. 483 Else: 485 The SAVI device MUST deliver the message to the destination. 487 The SAVI device MUST generate as many new entries in BST and FT as 488 the number of IADDR found in the message. If the binding anchor 489 type inside the BST is not link layer address, the binding anchor 490 for an entry is recovered from the mapping table from link layer 491 address to binding anchor (cf. section 5.3) based on the 492 destination link layer address inside the DHCP message. 494 The states of the corresponding entries are set to be BOUND. The 495 lifetime of the entries MUST be set to be the lease time. 497 The binding entry limit can be exceeded when setting up bindings 498 for all addresses in a REPLY message. If there is enough binding 499 entry resources, corresponding new entries MUST be generated even 500 the binding number limit is exceeded. In case that there is not 501 enough resource left, as many as possible entries SHOULD be set up. 503 If the binding anchor is a switch port, there can be vulnerability 504 in this process which is discussed in section 13.1. Similar problem 505 can happen with other binding anchors. 507 +---------+----------+-------+------------------------+-------+ 508 | Anchor | Address | State | Lifetime |TID | 509 +---------+----------+-------+------------------------+-------+ 510 | A | Addr1 | BOUND | Lease time 1 |TID | 511 +---------+----------+-------+------------------------+-------+ 512 | A | Addr2 | BOUND | Lease time 2 |TID | 513 +---------+----------+-------+------------------------+-------+ 514 Figure 6 Binding entry in BST on Reply triggered initialization 516 +---------+----------+ 517 | Anchor |Address | 518 +---------+----------+ 519 |A |Addr1 | 520 +---------+----------+ 521 |A |Addr2 | 522 +---------+----------+ 524 Figure 7 Binding entry in FT on Reply triggered initialization 526 7.4.2. From INIT_BIND to Other States 528 7.4.2.1. Trigger Event 530 EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE, EVE_LEASEQUERY_REPLY. 532 7.4.2.2. Following Actions 534 If the trigger event is EVE_DHCP_REPLY: 536 The SAVI device MUST deliver the message to the destination. 538 If the Address field is null, the lease time in Reply message MUST 539 be recorded in the entry with matched TID. The state of the entry 540 is changed to be BOUND. If more than one IADDR is found in the 541 message, if there is enough binding entry resource, corresponding 542 new entries MUST be generated even the binding number limit is 543 exceeded. In case that there is not enough resource left, as many 544 as possible entries SHOULD be set up. 546 If the Address field is not null, the Reply is in response to a 547 Confirm message. If the Reply message is of Status Code Success, 548 and there is an entry with the same address, set the Lifetime to 549 be the remaining Lifetime of the existing entry, and remove the 550 existing entry. If there is no entry with the same address, set 551 the Lifetime of corresponding entry to MAX_LEASEQUERY_DELAY. The 552 state of the entry is changed to be BOUND. 554 +---------+----------+-------+------------------------+-------+ 555 | Anchor | Address | State | Lifetime |TID | 556 +---------+----------+-------+------------------------+-------+ 557 | A | Addr | BOUND | Lease time |TID | 558 +---------+----------+-------+------------------------+-------+ 559 Figure 8 From INIT_BIND to BOUND 561 A corresponding entry MUST also be generated in FT. 563 If the trigger event is EVE_ENTRY_EXPIRE: 565 The entry MUST be deleted from BST. 567 If the trigger event is EVE_LEASEQUERY_REPLY: 569 The Lifetime field of entry with corresponding IP address MUST be 570 set to the lease time in the LEASEQUERY_REPLY. The state of the entry 571 is changed to BOUND. 573 7.4.3. From BOUND to Other States 575 7.4.3.1. Trigger Event 577 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 578 EVE_DHCP_REPLY_RENEW. 580 7.4.3.2. Following Actions 582 If the trigger event is EVE_ENTRY_EXPIRE: 584 Remove the corresponding entry in BST and FT. 586 If the trigger event is EVE_DHCP_RELEASE or EVE_DHCP_DECLINE: 588 Remove the corresponding entry in BST and FT. The Release or 589 Decline message MUST be forwarded. 591 If the trigger event is EVE_DHCP_REPLY_RENEW: 593 Set the lifetime of the address to be the new lease time. 595 7.5. State Machine of DHCP Snooping 597 The main state transits are listed as follows. 599 State Event Action Next State 601 NO_BIND REQ/RC Generate entry INIT_BIND 603 NO_BIND CFM Generate entry and send Leasequery INIT_BIND 605 *NO_BIND RPL_NULL Generate entry with lease BOUND 607 INIT_BIND RPL Record lease time/set LQ_DLY BOUND 609 INIT_BIND Timeout Remove entry NO_BIND 611 INIT_BIND LQR Record lease time BOUND 613 BOUND RLS/DCL Remove entry NO_BIND 615 BOUND Timeout Remove entry NO_BIND 617 BOUND RNW Set new lifetime BOUND 619 *: optional but NOT RECOMMENDED. 621 REQ: EVE_DHCP_REQUEST 623 CFM: EVE_DHCP_CONFIRM 625 RC: EVE_DHCP_OPTION_RC 627 RPL: EVE_DHCP REPLY 629 RPL_NULL: EVE_DHCP REPLY_NULL 631 DCL: DHCP DECLINE 633 RLS: DHCP RELEASE 634 RNW: EVE_DHCP_RPL_RENEW 636 LQR: EVE_LEASEQUERY_REPLY 638 Timeout: EVE_ENTRY_EXPIRE 640 LQ_DLY: MAX_LEASEQUERY_DELAY 642 8. Supplemental Binding Process 644 Supplemental binding process is designed to cover scenarios where a 645 packet is sent by node but no previous DHCP exchanges have occurred 646 to update correctly the SAVI device's BST. A typical situation is 647 when the link topology changes after the binding has been set up, and 648 then the node will send packet through a different port than the 649 bound port. Another scenario is that a node moves on the local link 650 without re-configuration process. 652 Supplemental binding process is designed to avoid blocking 653 permanently legitimate traffic. It is not supposed to set up a 654 binding whenever a data packet with unbound source address is 655 received. Generally, longer time and more packets are needed to 656 trigger supplemental binding processes, as explained in the following 657 section. 659 Binding Recovery Process is a conditional SHOULD. This function 660 SHOULD be implemented if the vendor has such ability, unless the 661 implementation is known to be directly attached to host. If an 662 implementation is directly attached to host, change in link topology 663 will not affect the bindings, and host will always start re- 664 configuration process after interface is re-connected. Thus, there is 665 no need to use additional process to recovery bindings. If the 666 mechanism is not implemented and managed hosts are not directly 667 attached, permanent legitimate traffic blocking can happen until the 668 node is reconfigured. 670 8.1. Binding Recovery Process 672 If a binding anchor is set to have SAVI-BindRecovery attribute, 673 packet without matched binding can trigger the SAVI device to check 674 if the source address can be used by corresponding node: 676 1. Check if the address has a local conflict through: 678 IPv4 address: performing Address Resolution Protocol (ARP) 679 [RFC826] or Address Conflict Detection [RFC5227] twice on the 680 address; 681 IPv6 address: performing Duplicate Address Detection (DAD) 682 [RFC4862] twice on the address. 684 If duplicate detection fails, the packet MUST be discarded. 685 Otherwise, go to the next step. 687 2. 689 IPv4 address: 691 Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to 692 all DHCPv4 servers with IP Address Lease Time option (option 51). 693 The server addresses can be found through DHCPv4 Discovery or from 694 configuration. If no DHCPLEASEACTIVE message with IP Address Lease 695 Time option is received, discard the packet; otherwise generate a 696 new binding entry for the address, with the life time set to the 697 value encoded in IP Address Lease Time option of the 698 DHCPLEASEACTIVE message. 700 IPv6 address: 702 Send a LEASEQUERY [RFC5007] message querying by IP address to 703 All_DHCP_Relay_Agents_and_Servers multicast address or a configured 704 server address. If no successful LEASEQUERY-REPLY is received, 705 discard the packet; otherwise generate a new binding entry for the 706 address, with the lifetime set to the valid lifetime extracted from 707 OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message. The SAVI 708 device MAY repeat this process if a LEASEQUERY-REPLY with 709 OPTION_CLIENT_LINK is received, in order to set up binding entries 710 for all the address of the client. 712 In case that SAVI device is pure layer-2 device without IP address, 713 it is impossible to perform DHCP LEASEQUERY. Besides, this process 714 may fail if any DHCP server doesn't support DHCP LEASEQUERY. 716 The security issues about this process is discussed is section 13.5. 718 9. Filtering Specification 720 This section specifies how to use bindings to filter packets. 722 Filtering policies are different for data packet and control packet. 723 DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] messages that 724 may cause state transit are classified into control packet. Neighbor 725 Advertisement (NA) and ARP Response are also included in control 726 packet, because the Target Address of NA and ARP Response should be 727 checked to prevent spoofing. All other packets are considered to be 728 data packets. 730 9.1. Data Packet Filtering 732 Data packets with a binding anchor which has attribute SAVI- 733 Validation MUST be checked. 735 Packet whose source IP address is link-local address SHOULD be 736 forwarded. 738 If the source IP address of a packet is not a link-local address, but 739 the address is not bound with the corresponding binding anchor, this 740 packet MUST be discarded. 742 The SAVI device SHOULD record any violation. 744 9.2. Control Packet Filtering 746 For binding anchors with SAVI-Validation attribute: 748 Discard DHCPv4 REQUEST message whose source IP address is neither 749 all zeros nor a bound address in FT. 751 Discard DHCPv6 Request message whose source is neither link-local 752 address nor bound with the corresponding binding anchor in FT. 754 Discard NDP messages whose source address is neither link-local 755 address nor bound with the corresponding binding anchor. In 756 addition, discard NA message whose target address is neither link- 757 local address nor bound with the corresponding binding anchor. 759 Discard ARP messages whose protocol is IP and sender protocol 760 address is neither link-local address nor bound with the 761 corresponding binding anchor. In addition, discard ARP Reply 762 messages whose target address is neither link-local address nor 763 bound with the corresponding binding anchor. 765 For other binding anchors: 767 Discard DHCP Reply/ACK messages not from binding anchor with the 768 SAVI-DHCP-Trust attribute or SAVI-SAVI attribute. 770 The SAVI device SHOULD record any violation of the previous rules. 772 10. State Restoration 774 If a SAVI device reboots accidentally or designedly, the states kept 775 in volatile memory will get lost. This may cause legitimate traffic 776 from hosts indirectly attached to the SAVI device to be blocked until 777 a binding recovery. Purely using the Binding Recovery Process is 778 expansive and results delay to recover a large number of bindings. 779 Thus, recovery from non-volatile storage, as specified below, is 780 recommended. 782 If this function is supported by hardware, binding entries MUST be 783 saved into non-volatile storage whenever a new binding entry changes 784 to BOUND state or a binding with BOUND state is removed. 786 Immediately after reboot, the SAVI device MUST restore binding states 787 from the non-volatile storage. The system time of save process MUST 788 be stored. After rebooting, the SAVI device MUST check whether each 789 entry has been obsolete through comparing the saved lifetime and the 790 difference between current system time and saved system time. 792 11. Handle Binding Anchor Off-link Event 794 Port DOWN event MUST be handled if switch port is used as binding 795 anchor. In more general case, if a binding anchor turns off-link, 796 this event MUST be handled. 798 Whenever a binding anchor with attribute SAVI-Validation turns down, 799 set a timer with OFFLINK_DELAY. Until the timer becomes zero, the 800 bindings with the binding anchor SHOULD be kept. As an exception, to 801 handle node movement, if receiving DAD Neighbor 802 Solicitation/Gratuitous ARP request targeting at the address during 803 OFFLINK_DELAY, the entry MAY be removed. 805 If the binding anchor turns on-link during OFFLINK_DELAY, turn off 806 the timer and keep corresponding bindings. 808 12. Constants 810 MAX_DHCP_RESPONSE_TIME 120s 812 BIND_RECOVERY_INTERVAL 60s and configurable 814 MAX_LEASEQUERY_DELAY 10s 816 OFFLINK_DELAY 30s 818 13. Security Considerations 820 13.1. Security Problem about Binding Triggered by 821 EVE_DHCP_REPLY_NULL 823 When the binding anchor is switch port, binding based on 824 EVE_DHCP_REPLY_NULL can result in security threats. The assigned 825 address could be bound to a wrong switch port if an attack can 826 poison the table mapping a link layer address to switch port (cf. 827 section 5.3). 829 For example, host A requests address from port 1. When SAVI switch 830 receives a DHCP REPLY with assigned address IP_A and destination 831 link layer address MAC_A, it will check its MAC/port table to find 832 the right binding port. But MAC/port table might be polluted by an 833 attacker host B attached to port 2. Then SAVI switch will find the 834 MAC_A is at port 2 from the polluted MAC/port table and it will 835 result in a wrong binding which binds IP_A and port 2. 837 If one of the following conditions is satisfied, the security can be 838 ensured. 840 1. DHCP Option 82 is used to keep binding anchor in DHCP Request and 841 Reply. 843 DHCP Option 82 can be used to keep the circuit information of the 844 client and returned by the DHCP server. Thus the binding anchor 845 can be determined from the circuit information in the Option. It 846 can be used whenever an implementation doesn't want to create an 847 entry on the DHCP Request message. 849 2. Unspoofable MAC is used as binding anchor (802.11i, 802.1ae/af). 851 3. The mapping table from MAC to binding anchor is secure. 853 If the binding anchor is a link layer address, or there are 854 mechanisms preventing the corruption of the table mapping the 855 link layer to a switch port, mapping link layer address to 856 binding anchor may be considered as secure. 858 It is NOT RECOMMENDED to initialize a binding based on DHCP Reply, 859 unless a mechanism protecting the mapping table from corruption is 860 also implemented. 862 Similar problem may happen with binding anchors not based on link 863 layer addresses. 865 13.2. Binding Number Limitation 867 It is suggested to configure some mechanism in order to prevent a 868 single node from exhausting the binding table entries on the SAVI 869 device. Either of the following mechanism is sufficient to prevent 870 such attack. 872 1. Set the upper bound of binding number for each binding anchor with 873 SAVI-Validation. 875 2. Reserve a number of binding entries for each binding anchor with 876 SAVI-Validation attribute and all binding anchors share a pool of 877 the other binding entries. 879 3. Limit DHCP Request rate per binding anchor. 881 13.3. Risk from Link Layer Routing Dynamic 883 An implicit assumption of this solution is that data packet must 884 arrive at the same binding anchor with the binding anchor that the 885 control packets have arrived at. If this assumption is not valid, 886 this control packet based solution will fail or at least discard 887 legitimate packet. Unfortunately, the link layer routing between host 888 and SAVI device can be inconsistent from time to time. Time 889 consistency of link layer routing is not assured by link layer 890 routing protocol. For example, TRILL, a recent link layer routing 891 protocol, is flexible and multiple link layer paths are allowed. 893 To make the basic assumption stand, the best way is enforcing that 894 there should be only one topology path from downstream host to the 895 SAVI device. For example, SAVI device is directly attached by hosts. 897 If the assumption doesn't stand, a better solution is requiring 898 inter-operation between SAVI protocol and the link layer routing 899 protocol to make SAVI protocol sensitive to the link layer routing 900 change. This solution is above the scope of this document. 902 13.4. Duplicate Bindings of Same Address 904 The same address may be bound with multiple binding anchors, only if 905 the binding processes are finished on each binding anchor 906 successfully respectively. This mechanism is designed in 907 consideration that a node may move on the local ink, and a node may 908 have multiple binding anchors. However, the traceability of address 909 is reduced. 911 Note that the local link movement scenario is not handled perfectly. 912 The former binding may not be removed, unless the node is directly 913 attached to SAVI device. The nodes sharing the same former binding 914 anchor of the moving node have the ability to use its address. 916 13.5. Security Problems about Binding Recovery Process 918 The Binding Recovery Process (cf. section 8.1) MUST be rate limited 919 to avoid Denial of Services attack against the SAVI device itself. A 920 constant BIND_RECOVERY_INTERVAL is used to control the frequency. Two 921 data-triggered recovery processes on one binding anchor MUST have a 922 minimum interval time BIND_RECOVERY_INTERVAL. This constant SHOULD be 923 configured prudently to avoid Denial of Service attacks. 925 This process is not strict secure. The node with SAVI-BindRecovery 926 binding anchor has the ability to use the address of an inactive 927 node, which doesn't reply to the detection probes. 929 13.6. Compatibility with DNA (Detecting Network Attachment) 931 DNA [RFC4436] [RFC6059] is designed to decrease the handover latency 932 after re-attachment to the same network. DNA mainly relies on 933 performing reachability test through sending unicast Neighbor 934 Solicitation/Router Solicitation/ARP Request message to determine 935 whether a previously configured address is still valid. Though DNA 936 provides an optimization for host, it doesn't provide sufficient 937 information for this mechanism to migrate or establish a binding. If 938 a binding is set up only through snooping the reachability test 939 message, the binding can be invalid. For example, an attacker can 940 perform reachability test with address bound to another host. If 941 binding is migrated to the attacker, the attacker can successful 942 obtain the binding from the victim. Because this mechanism wouldn't 943 set up a binding based on snooping the DNA procedure, it cannot 944 achieve perfect compatibility with DNA. However, it only means the 945 re-configuration of interface is slowed but not prevented. Details 946 are discussed as follows. 948 In Simple DNAv6 [RFC6059], the probe is sent with source address set 949 to link-local address, and such messages will not be filtered by the 950 policy specified in section 9.2. If an interface is re-attached to a 951 previous network, the detection will be complete and the address will 952 be regarded as valid by host. The candidate address is not contained 953 in the probe. Thus, the binding cannot be recovered through snooping 954 the probe. The binding can only be recovered from the DHCP snooping 955 procedure. The DHCP REQUEST messages wouldn't be filtered by this 956 solution as their source address is link-local address. Before the 957 DHCP procedure is completed, packets will be filtered by SAVI device. 959 In another word, in SAVI scenarios, Simple DNAv6 will not help reduce 960 the handover latency. If SAVI-BindRecovery attribute is configured on 961 the new binding anchor, data triggered procedure may reduce the 962 latency. 964 In DNAv4 [RFC4436], the ARP probe will be filtered because unbound 965 address is used as sender protocol address. As a result, the 966 detection will not complete and false negative is caused. The DHCP 967 REQUEST message sent by the node will not be filtered, because the 968 source IP address field should be all zero as required by [RFC2131]. 969 Thus, if the address is still valid, the binding will be recovered 970 from the DHCP snooping procedure. 972 13.7. Residual Threats 974 As described in [I-D.ietf-savi-framework], this solution cannot 975 strictly prevent spoofing. There are two scenarios in which spoofing 976 can still happen: 978 1. The binding anchor is spoofable 980 If the binding anchor is spoofable, e.g., plain MAC address, an 981 attacker can use forged binding anchor to send packet which will not 982 be regarded as spoofing by SAVI device. 984 Indeed, using binding anchor that can be easily spoofed is dangerous. 985 An attacker can use the binding anchor of another host to perform a 986 lot of DHCP procedures, and the SAVI device will refuse to set up new 987 binding for the host whenever the binding number limitation has been 988 reached. Thus, it is RECOMMENDED to use strong enough binding anchor, 989 e.g., switch port, secure association in 802.11ae/af and 802.11i. 991 2. The binding anchor is shared by more than one host 993 If the binding anchor is shared by more than one host, they can spoof 994 the addresses of each other. For example, a number of hosts can 995 attach to the same switch port of a SAVI device through a hub. The 996 SAVI device cannot distinguish packets from different hosts and thus 997 the spoofing between them will not be detected. This problem can be 998 solved through not sharing binding anchor between hosts. 1000 14. IANA Considerations 1002 This document has no IANA actions. 1004 [RFC Editor: please remove this section prior to publication.] 1006 15. References 1008 15.1. Normative References 1010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1011 Requirement Levels", BCP 14, RFC 2119, March 1997. 1013 [I-D.ietf-savi-framework] 1015 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1016 "Source Address Validation Improvement Framework", draft- 1017 ietf-savi-framework-04 (work in progress), March 2011. 1019 [I-D.ietf-savi-fcfs] 1021 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 1022 SAVI: First-Come First-Serve Source-Address Validation for 1023 Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-09 1024 (work in progress), April 2011. 1026 [I-D.ietf-savi-mix] 1028 Jun Bi, Guang Yao, J. Halpern and E. Levy-Abegnoli, "SAVI 1029 for Mixed Address Assignment Methods Scenario", draft-ietf- 1030 savi-mix-00 (work in progress), March 2011. 1032 [RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol: Or 1033 converting network protocol addresses to 48.bit Ethernet 1034 address for transmission on Ethernet hardware", STD 37, RFC 1035 826, November 1982. 1037 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 1038 March 1997. 1040 [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6 1041 (DHCPv6)", RFC3315, July 2003. 1043 [RFC3736] R. Droms, "Stateless Dynamic Host Configuration Protocol 1044 (DHCP) Service for IPv6", RFC 3736, April 2004. 1046 [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration 1047 Protocol (DHCP) Leasequery", RFC4388, February 2006. 1049 [RFC4426] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network 1050 Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1052 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 1053 "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, 1054 September 2007. 1056 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 1057 Autoconfiguration", RFC4862, September, 2007. 1059 [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6 1060 Leasequery", RFC5007, September 2007. 1062 [RFC6059] S. Krishnan, G. Daley, "Simple Procedures for Detecting 1063 Network Attachment in IPv6", RFC6059, November 2010. 1065 15.2. Informative References 1067 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1068 Defeating Denial of Service Attacks which employ IP Source 1069 Address Spoofing", BCP 38, RFC 2827, May 2000. 1071 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 1072 July 2008. 1074 [IP Source Guard] 1076 Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet 1077 draft (work in progress), November 2007. 1079 16. Acknowledgments 1081 Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. Halpern, 1082 Eric Levy-Abegnoli and Alberto Garcia for careful review and valuation 1083 comments on the state machine and text. 1084 Thanks to Marcelo Bagnulo Braun, Mark Williams, Erik Nordmark, Mikael 1085 Abrahamsson, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia 1086 Zhang, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 1087 their valuable contributions. 1089 Authors' Addresses 1091 Jun Bi 1092 Tsinghua University 1093 Network Research Center, Tsinghua University 1094 Beijing 100084 1095 China 1096 Email: junbi@tsinghua.edu.cn 1098 Jianping Wu 1099 Tsinghua University 1100 Computer Science, Tsinghua University 1101 Beijing 100084 1102 China 1103 Email: jianping@cernet.edu.cn 1105 Guang Yao 1106 Tsinghua University 1107 Computer Science, Tsinghua University 1108 Beijing 100084 1109 China 1110 Email: yaog@netarchlab.tsinghua.edu.cn 1112 Fred Baker 1113 Cisco Systems 1114 Santa Barbara, CA 93117 1115 United States 1116 Email: fred@cisco.com 1118 17. Change Log 1120 From 02 to 03: 1122 - Section 12, data trigger and counter trigger are combined to 1123 binding recovery process. The expression "one of MUST" is 1124 changed to "conditional MUST. Conditions related with the 1125 implementation are specified. Related constants are changed 1126 in section 26." 1128 Main changes from 03 to 04: 1130 - Section "Prefix configuration" is removed. 1132 - Section "Supplemental binding process" is modified in 1133 requirement level. 1135 - Sub-section 9.1 "Rationale" is added. 1137 - Section "Filtering during Detection" is removed. 1139 - Section "Handling layer 2 path change" is changed to 1140 "Consideration on Link layer routing complexity" 1142 - Section "Background and related protocols" is removed. 1144 Main changes from 04 to 05: 1146 - Trigger events are listed explicitly in section 8. 1148 - Detection and Live states are deleted, together with 1149 corresponding sections. 1151 Main change from 05 to 06: 1153 - Section 8.1: reference to section 20 is changed to section 1154 15. 1156 Main changes from 06 to 07: 1158 - So many changes in this modification. We suggest to track 1159 http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht 1160 ml. Changes are made according to the comments. 1162 Main changes from 07 to 08,09: 1164 - The modifications are made according to the comments from 1165 Jean-Michel Combes. 1167 Main changes from 09 to 11: 1169 - DNA issues