idnits 2.17.1 draft-ietf-savi-dhcp-07.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 are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC3315], [RFC2131], [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 == 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. == 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 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 (November 26, 2010) is 4897 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: 'SAVI-framework' is mentioned on line 65, but not defined == Missing Reference: 'RFC3736' is mentioned on line 145, but not defined ** Obsolete undefined reference: RFC 3736 (Obsoleted by RFC 8415) == Unused Reference: 'RFC4861' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'RFC3307' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC5227' is defined on line 866, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-00 ** 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) Summary: 5 errors (**), 0 flaws (~~), 11 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 University 3 Intended status: Standard Tracks F. Baker 4 Expires: May 2011 Cisco Systems 5 November 26, 2010 7 SAVI Solution for DHCP 8 draft-ietf-savi-dhcp-07.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 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 10, 19 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on May 26, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents carefully, 55 as they describe your rights and restrictions with respect to this 56 document. Code Components extracted from this document must include 57 Simplified BSD License text as described in Section 4.e of the Trust 58 Legal Provisions and are provided without warranty as described in 59 the Simplified BSD License. 61 Abstract 63 This document specifies the procedure for creating bindings between a 64 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a 65 binding anchor (refer to [SAVI-framework]) on SAVI (Source Address 66 Validation Improvements) device. The bindings can be used to filter 67 packets generated on the local link with forged source IP address. 69 Table of Contents 71 Copyright Notice ............................................... 2 72 Abstract ....................................................... 2 73 1. Introduction ................................................ 3 74 2. Conventions used in this document............................ 4 75 3. Terminology ................................................. 4 76 4. SAVI-DHCP Scenario .......................................... 4 77 5. Data Structures ............................................. 5 78 5.1. Control Plane Data Structure: Binding State Table (BST). 5 79 5.2. Data Plane Data Structure: Filtering Table (FT)......... 6 80 6. Binding Anchor Attributes.................................... 6 81 6.1. No Attribute ........................................... 7 82 6.2. SAVI-Validation Attribute............................... 7 83 6.3. SAVI-DHCP-Trust Attribute............................... 7 84 6.4. SAVI-SAVI Attribute..................................... 7 85 6.5. SAVI-BindRecovery Attribute............................. 7 86 7. Binding Set Up .............................................. 8 87 7.1. Rationale .............................................. 8 88 7.2. Binding States Description.............................. 8 89 7.3. Events ................................................. 8 90 7.3.1. Timer expiration event............................. 8 91 7.3.2. Control message arriving events ................... 8 93 7.4. Process of DHCP Packet Snooping ........................ 9 94 7.4.1. From NO_BIND to other states ...................... 9 95 7.4.1.1. Trigger Event................................. 9 96 7.4.1.2. Following Actions............................ 10 97 7.4.2. From INIT_BIND to other states ................... 11 98 7.4.2.1. Trigger Event................................ 11 99 7.4.2.2. Following Actions............................ 12 100 7.4.3. From BOUND to other states ....................... 12 101 7.4.3.1. Trigger Event................................ 12 102 7.4.3.2. Following Actions............................ 12 103 7.5. State Machine of DHCP Snooping ........................ 13 104 8. Supplemental Binding Process................................ 14 105 8.1. Binding Recovery Process............................... 14 106 9. Filtering Specification..................................... 15 107 9.1. Data Packet Filtering.................................. 16 108 9.2. Control Packet Filtering............................... 16 109 10. State Restoration ......................................... 16 110 11. Handle Binding Anchor Off-link Event ...................... 17 111 12. Constants ................................................. 17 112 13. Security Considerations.................................... 17 113 13.1. Binding Number Limitation............................. 17 114 13.2. Risk from Link Layer Routing Dynamic ................. 18 115 13.3. Duplicate Bindings of Same Address ................... 18 116 14. IANA Considerations........................................ 18 117 15. References ................................................ 19 118 15.1. Normative References.................................. 19 119 15.2. Informative References................................ 19 120 16. Acknowledgments ........................................... 20 121 17. Change Log ................................................ 21 123 1. Introduction 125 This document describes the procedure for creating bindings between 126 DHCP addresses and binding anchor on SAVI device (refer to [I-D.ietf- 127 savi-framework]). Other related details about this procedure are also 128 specified in this document. The definition and examples of binding 129 anchor are specified in [I-D.ietf-savi-framework]. 131 Bindings can be used to filter packets with forged IP address. 132 Section 9 suggests usage of these bindings for common practice. 133 [savi-framework] may specify different usages of binding, depending 134 on the environment and configuration. 136 The mechanism specified in this document is designed to provide a 137 binding anchor granularity validation, as a supplement to BCP38 138 [BCP38]. This mechanism is deployed on the access device (including 139 access switch, wireless access point/controller, etc), and performs 140 mainly DHCP snooping to set up bindings between IP addresses assigned 141 by DHCP and corresponding binding anchors. The binding process is 142 inspired by the work of IP Source Guard [IP Source Guard]. 144 This solution is designed for stateful DHCP scenario [RFC2131, 145 RFC3315]. In stateless DHCP scenarios [RFC3736], DHCP is used to 146 configure other parameters but rather IP address. The address of the 147 client SHOULD be bound based on other SAVI solutions, but rather this 148 solution. 150 This solution is primarily designed for a pure DHCP scenario in which 151 only DHCP address is legitimate global address. How to use this 152 mechanism in multiple address assignments scenario is discussed in 153 [draft-bi-savi-mixed]. 155 2. Conventions used in this document 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. Terminology 163 Lease time: Lease time in IPv4 [RFC2131] and valid lifetime in 164 IPv6 [RFC3315] 166 4. SAVI-DHCP Scenario 168 Figure 1 shows the main elements in a DHCP network. At least one DHCP 169 server must be deployed in the network, and DHCP relay may be used to 170 relay message between client and server. Multiple SAVI devices and 171 non-SAVI devices can co-exist on link. A SAVI device can be attached 172 by client, DHCP relay (even DHCP server), SAVI device and non-SAVI 173 device. 175 Other address assignment mechanisms may be also used in such network. 176 However, this solution is primarily designed for a pure DHCP scenario, 177 in which only DHCP servers can assign valid global address. 179 Note that in IPv6 environment, DHCP procedure cannot be performed on 180 an interface without a link-local or global address pre-assigned. 181 Thus, to make this solution work, a SAVI solution for link-local 182 address MUST be enabled. 184 /------------\ 185 +--------+ | | 186 | DHCP |-----| Router | 187 | Server | | | 188 +--------+ \------------/ 189 | 190 --------------|-----------------. 191 | | | 192 | | | 193 | | | 194 | | | 195 | | | 196 +-----\----+ +----'-----+ +---\'-----+ 197 | SAVI | | SAVI | | Non SAVI| 198 | Device | | Device | | Device | 199 +/---.-----+ +-.------.-+ +-----.----+ 200 | | | | | 201 /----| | | | | 202 | | | | | 203 +-------/--++----/-----+ +----\-+ +\-----+ +--\---+ 204 | SAVI || Non SAVI| |DHCP | |Client| |Client| 205 | Device || Device | |Relay | | | | | 206 +----------++----------+ +------+ +------+ +------+ 207 Figure 1 DHCP Scenario 209 5. Data Structures 211 This section describes the data structures used in this mechanism. 213 Two main data structures are used to record bindings and their states 214 respectively. There is redundancy between the two structures, for the 215 consideration of separation of data plane and control plane. 217 5.1. Control Plane Data Structure: Binding State Table (BST) 219 This table contains the state of binding between source address and 220 binding anchor. Entries are keyed on the binding anchor and source IP 221 address. Each entry has a lifetime field recording the remaining 222 lifetime of the entry, a state field recording the state of the 223 binding and a field recording other information. The lifetime field 224 is used to help remove expired bindings. The state field is used to 225 identify state. The other field is used to keep temporary information, 226 e.g., the transaction ID (TID, Refer to Section 2 in [RFC2131] and 227 Section 4.2 in [RFC3315]) in DHCP request. Before a binding is 228 finished, the lease time of the address is also kept in this field 229 because it is improper to keep it in the lifetime field which keeps 230 the lifetime of the binding entry but not the address. 232 +---------+----------+-------+-----------+-------+ 233 | Anchor | Address | State | Lifetime |Other | 234 +---------+----------+-------+-----------+-------+ 235 | A | IP_1 | Bound | 65535 | | 236 +---------+----------+-------+-----------+-------+ 237 | A | IP_2 | Bound | 10000 | | 238 +---------+----------+-------+-----------+-------+ 239 | B | IP_3 |_Start | 1 | | 240 +---------+----------+-------+-----------+-------+ 241 Figure 2 Instance of BST 243 5.2. Data Plane Data Structure: Filtering Table (FT) 245 This table contains the bindings between binding anchor and address, 246 keyed on binding anchor and address. This table doesn't contain any 247 state of the binding. This table is only used to filter packets. An 248 Access Control List can be regarded as a practical instance of this 249 table. 251 +---------+----------+ 252 | Anchor |Address | 253 +---------+----------+ 254 |A |IP_1 | 255 +---------+----------+ 256 |A |IP_2 | 257 +---------+----------+ 258 Figure 3 Instance of FT 260 6. Binding Anchor Attributes 262 This section specifies the binding anchor attributes used in this 263 mechanism. 265 Attribute of each binding anchor is configurable. By default, binding 266 anchor has no attribute. A binding anchor MAY be configured to have 267 one or more compatible attributes. However, a binding anchor MAY 268 always have no attribute. 270 6.1. No Attribute 272 By default, a binding anchor has no attribute. Server type DHCP 273 message from binding anchor with no attribute MUST be dropped. 274 However, other packets SHOULD NOT be dropped. 276 6.2. SAVI-Validation Attribute 278 SAVI-Validation attribute is used on binding anchor on which the 279 source address is to be validated. The filtering process on binding 280 anchor with such attribute is described in section 9. 282 6.3. SAVI-DHCP-Trust Attribute 284 SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a 285 trustable DHCP server/relay. 287 DHCP server/relay message coming from binding anchor with this 288 attribute will be forwarded. 290 6.4. SAVI-SAVI Attribute 292 This attribute is used on binding anchor from which the data traffic 293 is not to be checked. Binding will not be set up on binding anchor 294 with this attribute. Except for message from DHCP server, all packets 295 will not be let pass directly. 297 Through configuring this attribute on binding anchor that joins two 298 or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes 299 implement the security perimeter concept in [savi-framework]. Since 300 no binding entry is needed on such binding anchor, the binding entry 301 resource requirement can be reduced greatly. 303 This attribute can also be set on other binding anchors if the 304 administrator decides not to validate the traffic from the binding 305 anchor. 307 This attribute is mutually exclusive with SAVI-Validation. 309 6.5. SAVI-BindRecovery Attribute 311 This attribute is used on binding anchor that requires data-triggered 312 binding recovery described in section 8.1. 314 This attribute is mutually exclusive with SAVI-SAVI. 316 7. Binding Set Up 318 This section specifies the procedure of setting up bindings based on 319 DHCP message snooping. The binding procedure specified here is 320 exclusively designed for binding anchor with SAVI-Validation 321 attribute. 323 7.1. Rationale 325 The rationale of this mechanism is that if a node attached to a 326 binding anchor is legitimate to use a DHCP address, the DHCP 327 procedure which assigns the address to the node must has been 328 performed on the same binding anchor. This basis stands when the link 329 layer routing is stable. However, layer-2 mobility and unstable link 330 layer routing may result in that data packet is received from a 331 different binding anchor. Infrequent link layer path change can be 332 handled (but not perfectly) by the mechanism described in section 8. 333 Section 13.2 discusses the situation that link layer routing is 334 naturedly unstable. To handle this situation is above the scope of 335 this document. 337 7.2. Binding States Description 339 This section describes the binding states of this mechanism. 341 NO_BIND The state before a binding has been set up. 343 INIT_BIND A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 344 Solicitation with Rapid Commit option) has been received from host, 345 and it may trigger a new binding. 347 BOUND The address is authorized to the client. 349 7.3. Events 351 7.3.1. Timer expiration event 353 EVE_ENTRY_EXPIRE: The lifetime of an entry expires 355 7.3.2. Control message arriving events 357 Only if a control message can pass the check in section 9.2, the 358 corresponding event is a valid event. 360 EVE_DHCP_REQUEST: A DHCP Request message is received from a binding 361 anchor with SAVI-Validation attribute, and the binding entry limit 362 (discussed in "Security Considerations") on the binding anchor has 363 not been reached. 365 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received from a binding 366 anchor with SAVI-Validation attribute, and the binding entry limit on 367 the binding anchor has not been reached. 369 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 370 option is received from a binding anchor with SAVI-Validation 371 attribute, and the binding entry limit on the binding anchor has not 372 been reached. 374 EVE_DHCP_REPLY: A DHCPv4 Acknowledgement or DHCPv6 Reply message is 375 received from a binding anchor with SAVI-DHCP-Trust attribute, and 376 the message should be forwarded to a binding anchor with SAVI- 377 Validation attribute. 379 EVE_DHCP_REPLY_NULL: A DHCPv4 Acknowledgement or DHCPv6 Reply message 380 is received from a binding anchor with SAVI-DHCP-Trust attribute. 382 EVE_DHCP_DECLINE: A DHCP Decline message is received from a binding 383 anchor with SAVI-Validation attribute. 385 EVE_DHCP_RELEASE: A DHCP Release message is received from a binding 386 anchor with SAVI-Validation attribute. 388 EVE_LEASEQUERY_REPLY: A successful DHCP LEASEQUERY_REPLY is received 389 from a binding anchor with SAVI-DHCP-Trust attribute. 391 7.4. Process of DHCP Packet Snooping 393 7.4.1. From NO_BIND to other states 395 7.4.1.1. Trigger Event 397 EVE_DHCP_REQUEST, EVE_DHCP_CONFIRM, EVE_DHCP_OPTION_RC, 398 EVE_DHCP_REPLY_NULL. 400 Note that vulnerability may be caused by DHCP Reply triggered 401 initialization. The binding of assigned address and binding anchor 402 may be threatened if the binding mechanism between binding anchor and 403 link layer address is not secure. If one of the following conditions 404 is satisfied, the security can be ensured. 406 1. DHCP Option 82 is used to keep binding anchor in DHCP Request and 407 Reply, or 409 2. Unspoofable MAC is used as binding anchor(802.11i,802.1ae/af), or 411 3. The mapping table from MAC to binding anchor is secure. 413 It is NOT RECOMMENDED to initialize a binding based on DHCP Reply, 414 until the associated mechanism is also implemented. 416 7.4.1.2. Following Actions 418 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC: 420 The SAVI device MUST forward the message. 422 The SAVI device MUST generate an entry for the binding anchor in 423 the Binding State Table (BST) and set the state field to INIT_BIND. 424 The lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME. 425 The TID field of the request packet MUST be recorded in the entry, 426 except that the mapping from link layer address to binding anchor 427 is secure as specified in section 7.2.1.1. 429 +---------+-------+---------+-----------------------+-------+ 430 | Anchor |Address| State | Lifetime |Other | 431 +---------+-------+---------+-----------------------+-------+ 432 | A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 433 +---------+-------+---------+-----------------------+-------+ 434 Figure 4 Binding entry in BST on client triggered initialization 436 The TID is kept as a mediator of assigned address and the binding 437 anchor of requesting node, to assure that the assigned address can 438 be bound with binding anchor secure. 440 If the triggering event is EVE_DHCP_CONFIRM: 442 Other than forwarding the message and generating corresponding 443 entry, the address to be confirmed MUST be recorded in the entry. 444 Because no lease time will be contained in the REPLY from DHCP 445 server, the SAVI device MUST send a LEASEQUERY [RFC5007] message 446 querying by IP address to All_DHCP_Relay_Agents_and_Servers 447 multicast address [RFC3315] or a configured server address. 449 +---------+--------+---------+-----------------------+-------+ 450 | Anchor | Address| State | Lifetime |Other | 451 +---------+--------+---------+-----------------------+-------+ 452 | A | Addr |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 453 +---------+--------+---------+-----------------------+-------+ 454 Figure 5 Binding entry in BST on Confirm triggered initialization 456 If the triggering event is EVE_DHCP_REPLY_NULL: 458 The SAVI device MUST deliver the message to the destination. 460 The SAVI device MUST generate as many new entries in BST and FT as 461 the number of IADDR found in the message. The binding anchor in 462 entry is looked up based on the destination link layer address, 463 from mapping table from link layer address to binding anchor (e.g., 464 the MAC-Port mapping table in case that port is used as binding 465 anchor). The states of the corresponding entries are set to be 466 BOUND. The lifetime of the entries MUST be set to be the lease time. 468 The binding entry limit can be exceeded when setting up bindings 469 for all addresses in a REPLY message. If there is enough binding 470 entry resource, corresponding new entries MUST be generated even 471 the binding number limit is exceeded. In case that there is not 472 enough resource left, as many as possible entries SHOULD be set up. 474 +---------+----------+-------+------------------------+-------+ 475 | Anchor | Address | State | Lifetime |Other | 476 +---------+----------+-------+------------------------+-------+ 477 | A | Addr1 | BOUND | Lease time 1 | | 478 +---------+----------+-------+------------------------+-------+ 479 | A | Addr2 | BOUND | Lease time 2 | | 480 +---------+----------+-------+------------------------+-------+ 481 Binding entry in BST on Reply triggered initialization 483 +---------+----------+ 484 | Anchor |Address | 485 +---------+----------+ 486 |A |Addr1 | 487 +---------+----------+ 488 |A |Addr2 | 489 +---------+----------+ 491 Figure 6 Binding entry in FT on Reply triggered initialization 493 7.4.2. From INIT_BIND to other states 495 7.4.2.1. Trigger Event 497 EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE, EVE_LEASEQUERY_REPLY. 499 7.4.2.2. Following Actions 501 If the trigger event is EVE_DHCP_REPLY: 503 The SAVI device MUST deliver the message to the destination. 505 If the Address field is null, the lease time in Reply message MUST 506 be recorded in the entry with matched TID. The state of the entry 507 is changed to be BOUND. If more than one IADDR is found in the 508 message, if there is enough binding entry resource, corresponding 509 new entries MUST be generated even the binding number limit is 510 exceeded. In case that there is not enough resource left, as many 511 as possible entries SHOULD be set up. 513 If the Address field is not null, the Reply is in response to a 514 Confirm message. If the Reply message is of Status Code Success, 515 set the Lifetime of corresponding entry to be MAX_LEASEQUERY_DELAY. 516 The state of the entry is changed to be BOUND. 518 +---------+----------+-------+------------------------+-------+ 519 | Anchor | Address | State | Lifetime |Other | 520 +---------+----------+-------+------------------------+-------+ 521 | A | Addr | BOUND | Lease time | | 522 +---------+----------+-------+------------------------+-------+ 523 Figure 7 From INIT_BIND to BOUND 525 A corresponding entry MUST also be generated in FT. 527 If the trigger event is EVE_ENTRY_EXPIRE: 529 The entry MUST be deleted from BST. 531 If the trigger event is EVE_LEASEQUERY_REPLY: 533 The Lifetime field of entry with corresponding IP address MUST be 534 set to the lease time in the LEASEQUERY_REPLY. 536 7.4.3. From BOUND to other states 538 7.4.3.1. Trigger Event 540 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 541 EVE_DHCP_REPLY_RENEW. 543 7.4.3.2. Following Actions 545 If the trigger event is EVE_ENTRY_EXPIRE: 547 Remove the corresponding entry in BST and FT. 549 If the trigger event is EVE_DHCP_RELEASE or EVE_DHCP_DECLINE: 551 Remove the corresponding entry in BST and FT. The Release or 552 Decline message MUST be forwarded. 554 If the trigger event is EVE_DHCP_REPLY_RENEW: 556 Set the lifetime of the address to be the new lease time. 558 7.5. State Machine of DHCP Snooping 560 The main state transits are listed as follows. 562 State Event Action Next State 564 NO_BIND REQ/RC Generate entry INIT_BIND 566 NO_BIND CFM Generate entry and send Leasequery INIT_BIND 568 *NO_BIND RPL Generate entry with lease BOUND 570 INIT_BIND RPL Record lease time/set LQ_DLY BOUND 572 INIT_BIND Timeout Remove entry NO_BIND 574 BOUND LQR Record lease time BOUND 576 BOUND RLS/DCL Remove entry NO_BIND 578 BOUND Timeout Remove entry NO_BIND 580 BOUND RNW Set new lifetime BOUND 582 *: optional but NOT RECOMMENDED. 584 REQ: EVE_DHCP_REQUEST 586 CFM: EVE_DHCP_CONFIRM 588 RC: EVE_DHCP_OPTION_RC 590 RPL: EVE_DHCP REPLY 592 DCL: DHCP DECLINE 593 RLS: DHCP RELEASE 595 RNW: EVE_DHCP_RPL_RENEW 597 LQR: EVE_LEASEQUERY_REPLY 599 Timeout: EVE_ENTRY_EXPIRE 601 LQ_DLY: MAX_LEASEQUERY_DELAY 603 8. Supplemental Binding Process 605 Supplemental binding process is designed to cover conditions that 606 packet is sent by node without previous DHCP procedure sensed by the 607 SAVI device. A typical situation is that the link topology change 608 after the binding has been set up, and then the node will send packet 609 to a different port with the bound port. Another scenario is that a 610 node moves on the local link without re-configuration process. 612 Supplemental binding process is designed to avoid permanent 613 legitimate traffic blocking. It is not supposed to set up a binding 614 whenever a data packet with unbound source address is received. 615 Generally, longer time and more packets are needed to trigger 616 supplemental binding processes. 618 Binding Recovery Process is a conditional SHOULD. This function 619 SHOULD be implemented if the vendor has such ability, unless the 620 implementation is known to be directly attached to host. If the 621 mechanism is not implemented and managed nodes are not directly 622 attached, permanent legitimate traffic blocking can happen until the 623 node is reconfigured. 625 8.1. Binding Recovery Process 627 If a binding anchor is set to have SAVI-BindRecovery attribute, 628 packet without matched binding can trigger the SAVI device to check 629 if the source address can be used by corresponding node: 631 1. Check if the address has a local conflict through sending 2 DAD 632 NS/ARP on the address. If duplicate detection fails, the packet 633 MUST be discarded. Otherwise, go to the next step. 635 2. 637 IPv4 address: 639 Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all 640 DHCPv4 servers for IPv4 address or a configured server address. The 641 server addresses may be discovered through DHCPv4 Discovery. If no 642 DHCPLEASEACTIVE message is received, discard the packet; otherwise 643 generate a new binding entry for the address. 645 IPv6 address: 647 Send a LEASEQUERY [RFC5007] message querying by IP address to 648 All_DHCP_Relay_Agents_and_Servers multicast address or a configured 649 server address. If no successful LEASEQUERY-REPLY is received, 650 discard the packet; otherwise generate a new binding entry for the 651 address. The SAVI device may repeat this process if a LEASEQUERY- 652 REPLY with OPTION_CLIENT_LINK is received, in order to set up binding 653 entries for all the address of the client. 655 This process MUST be rate limited to avoid Denial of Services attack 656 against the SAVI device itself. A constant BIND_RECOVERY_INTERVAL is 657 used to control the frequency. Two data-triggered recovery processes 658 on one binding anchor MUST have a minimum interval time 659 BIND_RECOVERY_INTERVAL. This constant SHOULD be configured prudently 660 to avoid Denial of Service attacks. 662 This process is not strict secure. The node with SAVI-BindRecovery 663 binding anchor has the ability to use the address of an inactive node, 664 which doesn't reply to the detection probes. 666 In case that SAVI device is pure layer-2 device without IP address, 667 it is impossible to perform DHCP LEASEQUERY. It is SUGGESTED NOT to 668 perform this data-triggered process. If binding recovery is still 669 required, DHCP Confirm SHOULD be sent instead of DHCP LEASEQUERY. The 670 security degree will degrade for the address may not be assigned by 671 DHCP server. A default lifetime DEFAULT_LEASE SHOULD be set with the 672 entry. 674 This process may fail if any DHCP server doesn't support DHCP 675 LEASEQUERY. 677 9. Filtering Specification 679 This section specifies how to use bindings to filter packets. 681 Filtering policies are different for data packet and control packet. 682 DHCP and ND messages that may cause state transit are classified into 683 control packet. Neighbor Advertisement and ARP Response are also 684 included in control packet, because the Target Address of NA and ARP 685 Response should be checked to prevent spoofing. All other packets are 686 considered to be data packets. 688 9.1. Data Packet Filtering 690 Data packets with a binding anchor which has attribute SAVI- 691 Validation MUST be checked. 693 If the source of a packet associated with its binding anchor is in 694 the FT, this packet SHOULD be forwarded; or else the packet SHOULD be 695 discarded, or alternatively the SAVI SHOULD record this violation. 697 9.2. Control Packet Filtering 699 For binding anchors with SAVI-Validation attribute: 701 Discard/record DHCPv4 Discovery with non-all-zeros source IP address. 702 Discard/record DHCPv4 Request whose source IP address is neither all 703 zeros nor a bound address in FT. 705 Discard/record DHCPv6 Request whose source is not bound with the 706 corresponding binding anchor in FT. Discard/record DHCPv6 Confirm/ 707 Solicit whose source is not a link local address bound with the 708 corresponding binding anchor in FT. The link layer address may be 709 bound based on SAVI-SLAAC solution or other solutions. 711 Discard/record other types of DHCP messages whose source is not an 712 address bound with the corresponding binding anchor. 714 Discard/record IPv6 NS and IPv4 gratuitous ARP whose source is not an 715 address bound with the corresponding binding anchor. 717 Discard/record NA and ARP Replies messages whose target address and 718 source address are not bound with the corresponding binding anchor. 720 For other binding anchors: 722 Discard DHCP Reply/Ack messages not from binding anchor with the 723 SAVI-DHCP-Trust attribute or SAVI-SAVI attribute. 725 10. State Restoration 727 If a SAVI device reboots accidentally or designedly, the states kept 728 in volatile memory will get lost. This may cause hosts indirectly 729 attached to the SAVI device to be broken away from the network, 730 because they can't recover bindings on the SAVI device of themselves. 731 Purely using the Binding Recovery Process is of great cost and delay 732 to recover a large number of bindings. Thus, recovery from non- 733 volatile storage is designed. 735 Binding entries MUST be saved into non-volatile storage whenever a 736 new binding entry changes to BOUND state or a binding with state 737 BOUND is removed in condition that this function is supported by 738 hardware. Immediately after reboot, the SAVI device MUST restore 739 binding states from the non-volatile storage. The lifetime and the 740 system time of save process MUST be stored. Then the device MUST 741 check whether the saved entries are obsolete when rebooting. 743 11. Handle Binding Anchor Off-link Event 745 Port DOWN event MUST be handled if switch port is used as binding 746 anchor. In more general case, if a binding anchor turns off-link, 747 this event MUST be handled. 749 Whenever a binding anchor with attribute SAVI-Validation turns down, 750 set a timer with OFFLINK_DELAY. Until the timer becomes zero, the 751 bindings with the binding anchor SHOULD be kept. As an exception, to 752 handle movement, if receiving DAD Neighbor Solicitation/Gratuitous 753 ARP request targeting at the address during OFFLINK_DELAY, the entry 754 MAY be removed. 756 If the binding anchor turns on-link during OFFLINK_DELAY, turn off 757 the timer and keep corresponding bindings. 759 12. Constants 761 MAX_DHCP_RESPONSE_TIME 120s 763 BIND_RECOVERY_INTERVAL 60s and configurable 765 MAX_LEASEQUERY_DELAY 10s 767 DEFAULT_LEASE 2h 769 OFFLINK_DELAY 2s 771 13. Security Considerations 773 13.1. Binding Number Limitation 775 It is suggested to configure some mechanism in order to prevent a 776 single node from exhausting the binding table entries on the SAVI 777 device. Either of the following mechanism is sufficient to prevent 778 such attack. 780 1. Set the upper bound of binding number for each binding anchor with 781 SAVI-Validation. 783 2. Reserve a number of binding entries for each binding anchor with 784 SAVI-Validation attribute and all binding anchors share a pool of 785 the other binding entries. 787 3. Limit DHCP Request rate per binding anchor. 789 13.2. Risk from Link Layer Routing Dynamic 791 An implicit assumption of this solution is that data packet must 792 arrive at the same binding anchor with the binding anchor that the 793 control packets have arrived at. If this assumption is not valid, 794 this control packet based solution will fail or at least discard 795 legitimate packet. Unfortunately, the link layer routing between host 796 and SAVI device can be inconsistent from time to time. Time 797 consistency of link layer routing is not assured by link layer 798 routing protocol. For example, TRILL, a recent link layer routing 799 protocol, is flexible and multiple link layer paths are allowed. 801 To make the basic assumption stand, the best way is enforcing that 802 there should be only one topology path from downstream host to the 803 SAVI device. For example, SAVI device is directly attached by hosts. 805 If the assumption doesn't stand, a better solution is requiring 806 inter-operation between SAVI protocol and the link layer routing 807 protocol to make SAVI protocol sensitive to the link layer routing 808 change. This solution is above the scope of this document. 810 13.3. Duplicate Bindings of Same Address 812 The same address may be bound with multiple binding anchors, only if 813 the binding processes are finished on each binding anchor 814 successfully respectively. This mechanism is designed in 815 consideration that a node may move on the local ink, and a node may 816 have multiple binding anchors. However, the traceability of address 817 is reduced. 819 Note that the local link movement scenario is not handled perfectly. 820 The former binding may not be removed, unless the node is directly 821 attached to the SAVI device. The nodes sharing the same former 822 binding anchor of the moving node have the ability to use its address. 824 14. IANA Considerations 826 There is no IANA consideration currently. 828 15. References 830 15.1. Normative References 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [I-D.ietf-savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and 836 C. Vogt, "Source Address Validation Improvement Protocol Framework", 837 draft-ietf-savi-framework-00 (work in progress), September 2010. 839 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 840 March 1997. 842 [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6 843 (DHCPv6)", RFC3315, July 2003. 845 [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration 846 Protocol (DHCP) Leasequery", RFC4388, February 2006. 848 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 849 "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September 2007. 851 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 852 Autoconfiguration", RFC4862, September, 2007. 854 [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6 855 Leasequery", RFC5007, September 2007. 857 15.2. Informative References 859 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 860 Defeating Denial of Service Attacks which employ IP Source Address 861 Spoofing", BCP 38, RFC 2827, May 2000. 863 [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast 864 Addresses", RFC3307, August 2002. 866 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 867 July 2008. 869 [IP Source Guard] Cisco, "Network Security Technologies and 870 Solutions", chapter 7, Cisco Press, May 20, 2008. 872 [draft-bi-savi-mixed] Jun Bi, "Mixed scenario analysis and best 873 effort solution", draft-bi-savi-mixed-00. 875 16. Acknowledgments 877 Special thanks to Christian Vogt, Joel M. Halpern, Eric Levy-Abegnoli 878 and Alberto Garcia for careful review and valuation comments on the 879 state machine and text. 880 Thanks to Marcelo Bagnulo Braun, Mark Williams, Erik Nordmark, Mikael 881 Abrahamsson, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia 882 Zhang, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for 883 their valuable contributions. 885 Authors' Addresses 887 Jun Bi 888 Network Research Center, Tsinghua University 889 Beijing 100084 890 China 891 Email: junbi@cernet.edu.cn 893 Jianping Wu 894 Computer Science, Tsinghua University 895 Beijing 100084 896 China 897 Email: jianping@cernet.edu.cn 899 Guang Yao 900 Computer Science, Tsinghua University 901 Beijing 100084 902 China 903 Email: yaog@netarchlab.tsinghua.edu.cn 905 Fred Baker 906 Cisco Systems 907 Santa Barbara, California 93117 908 US 909 Email: fred@cisco.com 911 17. Change Log 913 From 02 to 03: 915 - Section 12, data trigger and counter trigger are combined to 916 binding recovery process. The expression "one of MUST" is 917 changed to "conditional MUST. Conditions related with the 918 implementation are specified. Related constants are changed 919 in section 26." 921 Main changes from 03 to 04: 923 - Section "Prefix configuration" is removed. 925 - Section "Supplemental binding process" is modified in 926 requirement level. 928 - Sub-section 9.1 "Rationale" is added. 930 - Section "Filtering during Detection" is removed. 932 - Section "Handling layer 2 path change" is changed to 933 "Consideration on Link layer routing complexity" 935 - Section "Background and related protocols" is removed. 937 Main changes from 04 to 05: 939 - Trigger events are listed explicitly in section 8. 941 - Detection and Live states are deleted, together with 942 corresponding sections. 944 Main change from 05 to 06: 946 - Section 8.1: reference to section 20 is changed to section 947 15. 949 Main changes from 06 to 07: 951 - So many changes in this modification. We suggest to track 952 http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht 953 ml. Changes are made according to the comments.