idnits 2.17.1 draft-ietf-savi-dhcp-06.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 12 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 == 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 (September 8, 2010) is 4979 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 66, but not defined == Missing Reference: 'RFC3736' is mentioned on line 143, but not defined ** Obsolete undefined reference: RFC 3736 (Obsoleted by RFC 8415) == Missing Reference: 'BCP38' is mentioned on line 158, but not defined == Missing Reference: 'RFC5460' is mentioned on line 798, but not defined == Unused Reference: 'RFC3307' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'RFC5227' is defined on line 898, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi, J. Wu 2 Internet Draft CERNET 3 Intended status: Standard Tracks G. Yao 4 Expires: March 2011 Tsinghua Univ. 5 F. Baker 6 Cisco 7 September 8, 2010 9 SAVI Solution for DHCP 10 draft-ietf-savi-dhcp-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may not be modified, 16 and derivative works of it may not be created, except to publish it 17 as an RFC and to translate it into languages other than English. 19 This document may contain material from IETF Documents or IETF 20 Contributions published or made publicly available before November 10, 21 2008. The person(s) controlling the copyright in some of this 22 material may not have granted the IETF Trust the right to allow 23 modifications of such material outside the IETF Standards Process. 24 Without obtaining an adequate license from the person(s) controlling 25 the copyright in such materials, this document may not be modified 26 outside the IETF Standards Process, and derivative works of it may 27 not be created outside the IETF Standards Process, except to format 28 it for publication as an RFC or to translate it into languages other 29 than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on January 8, 2010. 47 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents carefully, 56 as they describe your rights and restrictions with respect to this 57 document. Code Components extracted from this document must include 58 Simplified BSD License text as described in Section 4.e of the Trust 59 Legal Provisions and are provided without warranty as described in 60 the Simplified BSD License. 62 Abstract 64 This document specifies the procedure for creating bindings between a 65 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a 66 binding anchor (refer to [SAVI-framework]) on SAVI (Source Address 67 Validation Improvements) device. The bindings can be used to filter 68 packets generated on the local link with forged source IP address. 70 Table of Contents 72 Copyright Notice ............................................... 2 73 Abstract ....................................................... 2 74 1. Introduction ................................................ 3 75 2. Conventions used in this document............................ 4 76 3. Mechanism Overview .......................................... 4 77 4. Terminology ................................................. 4 78 5. Conceptual Data Structures................................... 4 79 5.1. Control Plane Data Structure: Binding State Table(BST).. 4 80 5.2. Data Plane Data Structure: Filtering Table(FT).......... 5 81 6. DHCP Scenario ............................................... 5 82 7. Binding Anchor Attributes.................................... 6 83 7.1. No Attribute ........................................... 6 84 7.2. SAVI-Validation Attribute............................... 6 85 7.3. SAVI-DHCP-Trust Attribute............................... 7 86 7.4. SAVI-SAVI Attribute..................................... 7 87 7.5. SAVI-BindRecovery Attribute............................. 7 88 7.6. SAVI-ExtSnooping Attribute.............................. 7 89 8. Binding Set Up .............................................. 7 90 8.1. Rationale .............................................. 8 91 8.2. Binding States Description.............................. 8 92 8.3. Events ................................................. 8 93 8.3.1. Timer expiration event............................. 8 94 8.3.2. Control message arriving event..................... 8 95 8.4. Process of Control Packet Snooping...................... 9 96 8.4.1. From INIT to other states.......................... 9 97 8.4.1.1. Trigger Event................................. 9 98 8.4.1.2. Following Actions............................ 10 99 8.4.2. From START to other states........................ 11 100 8.4.2.1. Trigger Event................................ 11 101 8.4.2.2. Following Actions............................ 11 102 8.4.3. From BOUND to other states........................ 12 103 8.4.3.1. Trigger Event................................ 12 104 8.4.3.2. Following Actions............................ 12 105 8.5. State Machine of DHCP Snooping......................... 12 106 9. Supplemental Binding Process: Handling Link Topology Change. 13 107 9.1. Binding Recovery Process............................... 14 108 9.2. Extended Control Packet Snooping Process............... 15 109 10. Filtering Specification.................................... 16 110 10.1. Data Packet Filtering................................. 16 111 10.2. Control Packet Filtering.............................. 16 112 11. Handle Binding Anchor Off-link Event....................... 17 113 12. Binding Number Limitation.................................. 17 114 13. State Restoration ......................................... 17 115 14. Confirm Triggered Binding.................................. 18 116 15. Consideration on Link Layer Routing Complexity............. 18 117 16. Duplicate Bindings of Same Address......................... 19 118 17. Constants ................................................. 19 119 18. Security Considerations.................................... 19 120 19. IANA Considerations........................................ 19 121 20. References ................................................ 19 122 20.1. Normative References.................................. 19 123 20.2. Informative References................................ 19 124 21. Acknowledgments ........................................... 20 125 22. Change Log ................................................ 21 127 1. Introduction 129 This document describes the procedure for creating bindings between 130 DHCP assigned addresses and a binding anchor (refer to [savi- 131 framework]). Other related details about this procedure are also 132 specified in this document. 134 These bindings can be used to filter packets with forged IP address. 135 Section 12 suggests usage of these bindings for common practice. 136 [savi-framework] may specify different usages of binding, depending 137 on the environment and configuration. The definition and examples of 138 binding anchor is specified in [savi-framework]. 140 The binding process is inspired by the work of IP Source Guard [IP 141 Source Guard]. 143 In a stateless DHCP scenario [RFC3736], DHCP is used to configure 144 other parameters but rather IP address. The address of the client 145 SHOULD be bound based on other SAVI solutions, but rather this 146 solution designed for stateful DHCP. 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. Mechanism Overview 156 The mechanism specified in this document is designed to provide an 157 address level source IP address validation granularity, as a 158 supplement to BCP38 [BCP38]. This mechanism is deployed on the access 159 device (including access switch, wireless access point/controller, 160 etc), and performs mainly DHCP snooping to set up bindings between 161 DHCP assigned IP addresses and corresponding binding anchors. The 162 bindings can be used to validate the source address in the packets. 164 4. Terminology 166 Main terms used in this document are described in [savi-framework], 167 [RFC2131] and [RFC3315]. 169 5. Conceptual Data Structures 171 This section describes the possible conceptual data structures used 172 in this mechanism. 174 Two main data structures are used to record bindings and their states 175 respectively. There is redundancy between the two structures, for the 176 consideration of separation of data plane and control plane. 178 5.1. Control Plane Data Structure: Binding State Table (BST) 180 This table contains the state of binding between source address and 181 binding anchor. Entries are keyed on the binding anchor and source IP 182 address. Each entry has a lifetime field recording the remaining 183 lifetime of the entry, a state field recording the state of the 184 binding and a field recording other information. The lifetime field 185 is used to help remove expired bindings. The state field is used to 186 identify state. The other field is used to keep temporary information, 187 e.g., the transaction ID in DHCP request. Before a binding is 188 finished, the lease time of the address is also kept in this field 189 because it is improper to keep it in the lifetime field which keeps 190 the lifetime of the binding entry but not the address. 192 +---------+----------+-------+-----------+-------+ 193 | Anchor | Address | State | Lifetime |Other | 194 +---------+----------+-------+-----------+-------+ 195 | A | IP_1 | Bound | 65535 | | 196 +---------+----------+-------+-----------+-------+ 197 | A | IP_2 | Bound | 10000 | | 198 +---------+----------+-------+-----------+-------+ 199 | B | IP_3 |_Start | 1 | | 200 +---------+----------+-------+-----------+-------+ 201 Figure 1 Instance of BST 203 5.2. Data Plane Data Structure: Filtering Table (FT) 205 This table contains the bindings between binding anchor and address, 206 keyed on binding anchor and address. This table doesn't contain any 207 state of the binding. This table is only used to filter packets. An 208 Access Control List can be regarded as a practical instance of this 209 table. 211 +---------+----------+ 212 | Anchor |Address | 213 +---------+----------+ 214 |A |IP_1 | 215 +---------+----------+ 216 |A |IP_2 | 217 +---------+----------+ 218 Figure 2 Instance of FT 220 6. DHCP Scenario 222 Figure 3 shows the main elements in a DHCP enabled network. At least 223 one DHCP server must be deployed in the network, and DHCP relay may 224 be used to relay message between client and server. 226 Other address assignment mechanisms may be also used in such network. 227 However, this solution is primarily designed for a pure DHCP scenario, 228 in which only DHCP servers can assign valid global address. In a 229 mixed address assignment scenario where multiple address assignment 230 methods such as DHCPv6 and SLAAC, or DHCPv4 and manually 231 configured assign addresses that share the common prefix, the SAVI 232 device may need additional state in the state machine to detect and 233 avoid address conflict. The SAVI solution for mixed environment 234 is proposed in a separate document [draft-bi-savi-mixed]. 236 +--------+ 237 | DHCP | 238 | Server | 239 +--------+ 240 | 241 | 242 | 243 +----'-----+ 244 | SAVI | 245 | Device | 246 +-/------/-+ 247 | | 248 +----\-+ +\-----+ 249 |DHCP | |Client| 250 |Relay | | | 251 +------+ +------+ 252 Figure 3 DHCP Scenario 254 7. Binding Anchor Attributes 256 This section specifies the binding anchor attributes involved in this 257 mechanism. 259 Binding anchor is defined in the [savi-framework]. Attribute of each 260 binding anchor is configurable. In default, binding anchor has no 261 attribute. A binding anchor MAY be configured to have one or more 262 compatible attributes. However, a binding anchor MAY have no 263 attribute. 265 7.1. No Attribute 267 By default, a binding anchor has no attribute. Server type DHCP 268 message from binding anchor with no attribute MUST be dropped. 269 However, other packets SHOULD NOT be dropped. 271 7.2. SAVI-Validation Attribute 273 SAVI-Validation attribute is used on binding anchor on which the 274 source addresses are to be validated. The filtering process on 275 binding anchor with such attribute is described in section 13. 277 7.3. SAVI-DHCP-Trust Attribute 279 SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a 280 trustable DHCP server/relay. 282 DHCP server/relay message coming from binding anchor with this 283 attribute will be forwarded. 285 7.4. SAVI-SAVI Attribute 287 This attribute is used on binding anchor from which the traffic is 288 not to be checked. All traffic from binding anchor with this 289 attribute will be forwarded without check. Note that DHCP server 290 message and router message will also be trusted. 292 Through configuring this attribute on binding anchor that joins two 293 or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes 294 implement the security perimeter concept in [savi-framework]. Since 295 no binding entry is needed on such binding anchor, the binding entry 296 resource requirement can be reduced greatly. 298 This attribute can also be set on other binding anchors if the 299 administrator decides not to validate the traffic from the binding 300 anchor. 302 This attribute is mutually exclusive with SAVI-Validation. 304 7.5. SAVI-BindRecovery Attribute 306 This attribute is used on binding anchor that requires binding 307 recovery described in section 10.1. 309 This attribute is mutually exclusive with SAVI-SAVI. 311 7.6. SAVI-ExtSnooping Attribute 313 This attribute is used on binding anchor that requires extended 314 control packet snooping described in section 10.2. 316 This attribute is mutually exclusive with SAVI-SAVI. 318 8. Binding Set Up 320 This section specifies the procedure of setting up bindings based on 321 control packet snooping. The binding procedure specified here is 322 exclusively designed for binding anchor with SAVI-Validation 323 attribute. 325 8.1. Rationale 327 The rationale of this mechanism is that if a node attached to a 328 binding anchor intends to use a valid DHCP address, the DHCP 329 procedure which assigns the address to the node goes first on the 330 same binding anchor. This basis stands when the link layer routing is 331 stable. However, unstable link layer routing may result in that data 332 packet is received from a different binding anchor with the DHCP 333 messages. Infrequent link layer path change can be handled (but not 334 perfectly) by the mechanism described in section 10. Section 15 335 discusses the situation that link layer routing is naturedly unstable. 336 To handle this situation is above the scope of this document. 338 8.2. Binding States Description 340 This section describes the binding states of this mechanism. 342 INIT The state before a binding has been set up. 344 START A DHCP request (or a DHCPv6 Confirm, or a DHCPv6 345 Solicitation with Rapid Commit option) has been received from host, 346 and it may trigger a new binding. 348 BOUND The address is authorized to the client. 350 8.3. Events 352 8.3.1. Timer expiration event 354 EVE_ENTRY_EXPIRE: The lifetime of an entry expires 356 8.3.2. Control message arriving events 358 EVE_DHCP_REQUEST: A DHCP Request message is received from a binding 359 anchor with SAVI-Validation attribute, and the binding entry limit on 360 the binding anchor has not been reached. 362 EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received from a binding 363 anchor with SAVI-Validation attribute, and the binding entry limit on 364 the binding anchor has not been reached. 366 EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit 367 option is received from a binding anchor with SAVI-Validation 368 attribute, and the binding entry limit on the binding anchor has not 369 been reached. 371 EVE_DHCP_REPLY: A DHCPv4 Acknowledgement or DHCPv6 Reply message is 372 received from a binding anchor with SAVI-DHCP-Trust attribute, and 373 the message should be forwarded to a binding anchor with SAVI- 374 Validation attribute, which has an entry in the state of START. The 375 TID field in the entry matches the TID in the message. 377 EVE_DHCP_REPLY_NULL: A DHCPv4 Acknowledgement or DHCPv6 Reply message 378 is received from a binding anchor with SAVI-DHCP-Trust attribute, and 379 the message should be forwarded to a binding anchor with SAVI- 380 Validation attribute, which has no entry in the state of START or 381 matches the TID field. 383 EVE_DHCP_DECLINE: A DHCP Decline message is received from a binding 384 anchor with SAVI-Validation attribute. The message declines an 385 address bound with the binding anchor in state of LIVE or DETECTION 386 or BOUND. 388 EVE_DHCP_RELEASE: A DHCP Release message is received from a binding 389 anchor with SAVI-Validation attribute. The message releases an 390 address bound with the binding anchor in state of LIVE or DETECTION 391 or BOUND. 393 EVE_DHCP_REPLY_RENEW: A DHCPv4 Acknowledgement or DHCPv6 Reply 394 message is received, which suggests a new lease time of address in 395 state of BOUND. 397 8.4. Process of Control Packet Snooping 399 8.4.1. From INIT to other states 401 8.4.1.1. Trigger Event 403 EVE_DHCP_REQUEST, EVE_DHCP_CONFIRM, EVE_DHCP_OPTION_RC, 404 EVE_DHCP_REPLY_NULL. 406 Note that vulnerability may be caused by DHCP Reply triggered 407 initialization. The binding of assigned address and binding anchor 408 may be threatened if the binding mechanism between binding anchor and 409 link layer address is not secure. If one of the following conditions 410 is satisfied, the security can be ensured. 412 1. Option 82 is used to keep binding anchor in DHCP Request and Reply, 413 or 415 2. Unspoofable MAC is used as binding anchor(802.11i,802.1ae/af), or 417 3. The mapping table from MAC to binding anchor is secure. 419 It is SUGGESTED not to initialize a binding based on DHCP Reply, 420 until the associated mechanism is also implemented. 422 8.4.1.2. Following Actions 424 If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC: 426 The SAVI device MUST forward the message. 428 The SAVI device MUST generate an entry for the binding anchor in 429 the Binding State Table (BST) and set the state field to START. The 430 lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The 431 Transaction ID (Refer to Section 2 in [RFC2131] and Section 4.2 in 432 [RFC3315]) field of the request packet MUST be recorded in the 433 entry, except that the mapping from link layer address to binding 434 anchor is secure as specified in section 9.2.1.1. 436 +---------+----------+-------+-----------------------+-------+ 437 | Anchor | Address | State | Lifetime |Other | 438 +---------+----------+-------+-----------------------+-------+ 439 | A | | START |MAX_DHCP_RESPONSE_TIME | TID | 440 +---------+----------+-------+-----------------------+-------+ 441 Figure 4 Binding entry in BST on client triggered initialization 443 The TID is kept as a mediator of assigned address and the binding 444 anchor of requesting node, to assure that the assigned address can 445 be bound with binding anchor secure. 447 If the triggering event is EVE_DHCP_CONFIRM: 449 Other than the actions above, the address to be confirmed MUST be 450 recorded in the entry. 452 +---------+----------+-------+-----------------------+-------+ 453 | Anchor | Address | State | Lifetime |Other | 454 +---------+----------+-------+-----------------------+-------+ 455 | A | Addr | START |MAX_DHCP_RESPONSE_TIME | TID | 456 +---------+----------+-------+-----------------------+-------+ 457 Figure 5 Binding entry in BST on Confirm triggered initialization 459 If the triggering event is EVE_DHCP_REPLY_NULL: 461 The SAVI device MUST deliver the message to the destination. 463 The SAVI device MUST generate a new entry in BST and FT. The 464 binding anchor in entry is looked up based on the destination link 465 layer address, from mapping table from link layer address to 466 binding anchor (e.g., the MAC-Port mapping table in case that port 467 is used as binding anchor). The state of the corresponding entry is 468 set to be BOUND. The lifetime of the entry MUST be set to be the 469 lease time. 471 +---------+----------+-------+------------------------+-------+ 472 | Anchor | Address | State | Lifetime |Other | 473 +---------+----------+-------+------------------------+-------+ 474 | A | Addr | BOUND | Lease time | | 475 +---------+----------+-------+------------------------+-------+ 476 Figure 6 Binding entry in BST on Reply triggered initialization 478 +---------+----------+ 479 | Anchor |Address | 480 +---------+----------+ 481 |A |Addr | 482 +---------+----------+ 483 Figure 7 Binding entry in FT on Reply triggered initialization 485 8.4.2. From START to other states 487 8.4.2.1. Trigger Event 489 EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE. 491 8.4.2.2. Following Actions 493 If the trigger event is EVE_DHCP_REPLY: 495 The SAVI device MUST deliver the message to the destination. 497 The state of the corresponding entry is changed to be BOUND. 499 If the Address field is null, the lease time in Reply message MUST 500 be recorded in the entry. 502 If the Address field is not null, the Reply is in response to a 503 Confirm message. If the Reply message is of Status Code Success, 504 perform the procedure in section 19 to fetch the lease time. 505 Otherwise, delete the entry. 507 +---------+----------+-------+------------------------+-------+ 508 | Anchor | Address | State | Lifetime |Other | 509 +---------+----------+-------+------------------------+-------+ 510 | A | Addr | BOUND | Lease time | | 511 +---------+----------+-------+------------------------+-------+ 512 Figure 8 From START to BOUND 514 A corresponding entry MUST also be generated in FT. 516 If the trigger event is EVE_ENTRY_EXPIRE: 518 The entry MUST be deleted from BST. 520 8.4.3. From BOUND to other states 522 8.4.3.1. Trigger Event 524 EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 525 EVE_DHCP_REPLY_RENEW. 527 8.4.3.2. Following Actions 529 If the trigger event is EVE_ENTRY_EXPIRE: 531 Remove the corresponding entry in BST and FT. 533 If the trigger event is EVE_DHCP_RELEASE or EVE_DHCP_DECLINE: 535 Remove the corresponding entry in BST and FT. The Release or 536 Decline message MUST be forwarded. 538 If the trigger event is EVE_DHCP_REPLY_RENEW: 540 Set the lifetime of the address to be the new lease time. 542 8.5. State Machine of DHCP Snooping 544 The main state transits are listed as follows. 546 State Event Action Next State 548 INIT REQ/CFM/RC Generate entry START 550 *INIT RPL Generate entry with lease BOUND 552 START RPL Record lease time BOUND 553 START Timeout Remove entry INIT 555 BOUND RELEASE/DECLINE Remove entry INIT 557 BOUND Timeout Remove entry INIT 559 BOUND RPL_RENEW Set new lifetime BOUND 561 *: optional but NOT SUGGESTED. 563 REQ: EVE_DHCP_REQUEST 565 CFM: EVE_DHCP_CONFIRM 567 RC: EVE_DHCP_OPTION_RC 569 RPL: EVE_DHCP REPLY 571 DECLINE: DHCP DECLINE 573 RELEASE: DHCP RELEASE 575 RPL_RENEW: EVE_DHCP_RPL_RENEW 577 Timeout: EVE_ENTRY_EXPIRE 579 9. Supplemental Binding Process: Handling Link Topology Change 581 Supplemental binding process is designed to cover conditions that 582 packet is sent by node without previous DHCP procedure sensed by the 583 SAVI device. A typical situation is that the link topology change 584 after the binding has been set up, and then the node will send packet 585 to a different port with the bound port. Another scenario is that a 586 node moves on the local link without re-configuration process, which 587 can be regarded as a special case of link topology change. In DHCP 588 scenario, till this document is finished, link topology change is the 589 only two events that must be handled through this supplemental 590 binding process. 592 Supplemental binding process is designed to avoid permanent 593 legitimate traffic blocking. It is not supposed to set up a binding 594 whenever a data packet with unbound source address is received. 595 Generally, longer time and more packets are needed to trigger 596 supplemental binding processes. 598 For implementations that will face the above problem: 600 1. Binding Recovery Process is a conditional SHOULD. This function 601 SHOULD be implemented if the vendor has such ability, unless the 602 implementation is known to be directly attached to host. If the 603 mechanism is not implemented and managed nodes are not directly 604 attached, permanent blocking will happen until the node is re- 605 configured. 607 2. Extended Control Packet Snooping Process is a MUST. 609 Other techniques may be prudently chosen as alternative if found to 610 have equivalent or even better function to avoid permanently blocking 611 after discussion, implementation and deployment. 613 9.1. Binding Recovery Process 615 Refer to [draft-baker-savi-one-implementation-approach] for a 616 detailed implementation suggestion. The process specified here can 617 only be enabled in condition that implementation can meet the 618 specified hardware requirements described in [draft-baker-savi-one- 619 implementation-approach]. 621 If a binding anchor is set to have SAVI-BindRecovery attribute, a 622 FIFO queue or register MUST be used to save recently filtered packets. 623 The SAVI device will fetch packet from the queue/register to check 624 the source address can be used by corresponding client on the local 625 link with limited rate: 627 1. If the address has a local conflict, meaning the DAD on the 628 address fails, the packet MUST be discarded. If the address is not 629 being used, go to the next step. 631 2. 633 IPv4 address: 635 Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all 636 DHCPv4 servers for IPv4 address or a configured server address. The 637 server addresses may be discovered through DHCPv4 Discovery. If no 638 DHCPLEASEACTIVE message is received, discard the packet; otherwise 639 generate a new binding entry for the address. 641 IPv6 address: 643 Send a LEASEQUERY [RFC5007] message querying by IP address to 644 All_DHCP_Relay_Agents_and_Servers multicast address or a configured 645 server address. If no successful LEASEQUERY-REPLY is received, 646 discard the packet; otherwise generate a new binding entry for the 647 address. The SAVI device may repeat this process if a LEASEQUERY- 648 REPLY with OPTION_CLIENT_LINK is received, in order to set up binding 649 entries for all the address of the client. 651 This process MUST be rate limited to avoid Denial of Services attack 652 against the SAVI device itself. A constant BIND_RECOVERY_INTERVAL is 653 used to control the frequency. Two data based processes on one 654 binding anchor must have a minimum interval time 655 BIND_RECOVERY_INTERVAL. This constant SHOULD be configured prudently 656 to avoid Denial of Services. 658 This process is not strict secure. The node with SAVI-BindRecovery 659 binding anchor has the ability to use the address of an inactive node, 660 which doesn't reply to the DAD probe. 662 In case that the SAVI device is a pure layer-2 device, DHCP Confirm 663 MAY be used to replace the DHCP LEASEQUERY. The security degree may 664 degrade for the address may not be assigned by DHCP server. 666 This process may fail if any DHCP server doesn't support LEASEQUERY. 668 9.2. Extended Control Packet Snooping Process 670 In this snooping process, other than DHCP initialization messages, 671 other types of control packets processed by processor of SAVI device, 672 if the source address is not bound, may trigger the device to perform 673 binding process. 675 The control messages that MUST be processed include: (1) address 676 resolution Neighbor Solicitation; (2) Neighbor Advertisement; (3) 677 neighbor unreachability detection; (4) Multicast Listener Discovery; 678 (5) Address Resolution Protocol; (6) DHCP Renew/Rebind. Other ICMP 679 messages that may be processed by intermediate device may also 680 trigger the binding process. 682 The SAVI device MUST first perform DAD to check if the address has a 683 local conflict, and then send DHCP LEASEQUERY or Confirm to recover 684 binding based on DHCP server message. 686 A minimum time interval EXT_SNOOPING_INTERVAL MUST be set to limit 687 the rate of such triggering process. 689 Note that this process may not be able to avoid permanent block, in 690 case that only data packets are sent by node. Generally, this 691 mechanism is still practical, because data packet sending without 692 control plane communication is rare and suspicious in reality. Normal 693 traffic will contain control plane communication packets to help 694 traffic setup and fault diagnosis. 696 10. Filtering Specification 698 This section specifies how to use bindings to filter packets. 700 Filtering policies are different for data packet and control packet. 701 DHCP and ND messages that may cause state transit are classified into 702 control packet. Neighbor Advertisement and ARP Response are also 703 included in control packet, because the Target Address of NA and ARP 704 Response should be checked to prevent spoofing. All other packets are 705 considered to be data packets. 707 10.1. Data Packet Filtering 709 Data packets with a binding anchor which has attribute SAVI- 710 Validation MUST be checked. 712 If the source of a packet associated with its binding anchor is in 713 the FT, this packet SHOULD be forwarded; or else the packet SHOULD be 714 discarded, or alternatively the SAVI SHOULD record this violation. 716 10.2. Control Packet Filtering 718 For binding anchors with SAVI-Validation attribute: 720 Discard/record DHCPv4 Discovery with non-all-zeros source IP address. 721 Discard/record DHCPv4 Request whose source IP address is neither all 722 zeros nor a bound address in FT. 724 Discard/record DHCPv6 Request whose source is not bound with the 725 corresponding binding anchor in FT. Discard/record DHCPv6 Confirm/ 726 Solicit whose source is not a link local address bound with the 727 corresponding binding anchor in FT. The link layer address may be 728 bound based on SAVI-SLAAC solution or other solutions. 730 Discard/record other types of DHCP messages whose source is not an 731 address bound with the corresponding binding anchor. 733 Discard/record IPv6 NS and IPv4 gratuitous ARP whose source is not an 734 address bound with the corresponding binding anchor. 736 Discard/record NA and ARP Replies messages whose target address and 737 source address are not bound with the corresponding binding anchor. 739 For other binding anchors: 741 Discard DHCP Reply/Ack messages not from binding anchor with the 742 SAVI-DHCP-Trust attribute or SAVI-SAVI attribute. 744 11. Handle Binding Anchor Off-link Event 746 Port DOWN event MUST be handled if switch port is used as binding 747 anchor. In more general case, if a binding anchor turns off-link, 748 this event MUST be handled. 750 Whenever a binding anchor with attribute SAVI-Validation turns down, 751 the bindings with the binding anchor MUST be kept for a short time. 753 To handle movement, if receiving DAD NS/Gra ARP request targeting at 754 the address during the period, the entry MAY be removed. 756 If the binding anchor turns on-link during the period, recover 757 bindings. It may result in some security problem, e.g., a malicious 758 node immediately associates with the binding anchor got off by a 759 previous node, and then it can use the address assigned to the 760 previous node. However, this situation is very rare in reality. 761 Authors decide not to handle this situation. 763 12. Binding Number Limitation 765 It is suggested to configure some mechanism in order to prevent a 766 single node from exhausting the binding table entries on the SAVI 767 device. Either of the following mechanism is sufficient to prevent 768 such attack. 770 1. Set the upper bound of binding number for each binding anchor with 771 SAVI-Validation. 773 2. Reserve a number of binding entries for each binding anchor with 774 SAVI-Validation attribute and all binding anchors share a pool of 775 the other binding entries. 777 3. Limit DHCP Request rate per binding anchor, using the bound entry 778 number of each binding anchor as reverse indicator. 780 13. State Restoration 782 If a SAVI device reboots accidentally or designedly, the states kept 783 in volatile memory will get lost. This may cause hosts indirectly 784 attached to the SAVI device to be broken away from the network, 785 because they can't recover bindings on the SAVI device of themselves. 786 Thus, binding entries MUST be saved into non-volatile storage 787 whenever a new binding entry changes to BOUND state or a binding with 788 state BOUND is removed in condition that this function is supported 789 by hardware. Immediately after reboot, the SAVI device MUST restore 790 binding states from the non-volatile storage. The lifetime and the 791 system time of save process MUST be stored. Then the device MUST 792 check whether the saved entries are obsolete when rebooting. 794 The possible alternatives proposed but not suitable for general cases 795 are: 797 If the SAVI device is also the DHCP relay, an alternative mechanism 798 is fetching the bindings through bulk DHCP LEASEQUERY [RFC5460]. 800 If the network enables 802.1ag, the bindings can be recovered with 801 the help of the first hop routers through snooping unicast Neighbor 802 Solicitations sent by routers based on the Neighbor Table. 804 14. Confirm Triggered Binding 806 If a binding entry is triggered by a CONFIRM message from the client, 807 no lease time will be contained in the REPLY from DHCP server. The 808 SAVI device MUST send LEASEQUERY message to get the lease time of the 809 address to complete the binding entry. If no successful LEASEQUERY- 810 REPLY is received, the binding entry SHOULD be removed. In this 811 scenario, the address is not regarded as assigned by DHCP, and it MAY 812 be bound through other SAVI solution. 814 If the confirmed address has local conflict, the Client-ID field of 815 Confirm and LEASEQUERY-REPLY MUST be compared. If they are not match, 816 the new binding entry MUST be deleted. 818 15. Consideration on Link Layer Routing Complexity 820 An implicit assumption of this solution is that data packet must 821 arrive at the same binding anchor with the binding anchor that the 822 control packets have arrived at. If this assumption is not valid, 823 this control packet based solution will fail or at least discard 824 legitimate packet. Unfortunately, if the link layer routing between 825 host and SAVI device is inconsistent from time to time, this 826 assumption doesn't stand. Time consistency of link layer routing is 827 not assured by link layer routing protocol. For example, TRILL, a 828 recent link layer routing protocol, is flexible and multiple link 829 layer paths are allowed. 831 To make the basic assumption stand, the best way is enforcing that 832 there should be only one topology path from downstream host to the 833 SAVI device. For example, SAVI device is directly attached by hosts. 835 If the assumption doesn't stand, a better solution is requiring 836 inter-operation between SAVI protocol and the link layer routing 837 protocol to make SAVI protocol sensitive to the link layer routing 838 change. This solution is above the scope of this document. 840 16. Duplicate Bindings of Same Address 842 Note that the same address may be bound with multiple binding anchors, 843 only if the binding processes are finished on each binding anchor 844 successfully respectively. 846 This mechanism is designed in consideration that a node may move on 847 the local ink, and a node may have multiple binding anchors. 849 Note that the local link movement scenario is not handled perfectly. 850 The former binding may not be removed, unless the node is directly 851 attached to the SAVI device. The nodes sharing the same former 852 binding anchor of the moving node have the ability to use its address. 854 17. Constants 856 MAX_DHCP_RESPONSE_TIME 120s 858 BIND_RECOVERY_INTERVAL Device capacity depended and configurable 860 18. Security Considerations 862 There is no security consideration currently. 864 19. IANA Considerations 866 There is no IANA consideration currently. 868 20. References 870 20.1. Normative References 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, March 1997. 875 20.2. Informative References 877 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 878 March 1997. 880 [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast 881 Addresses", RFC3307, August 2002. 883 [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6 884 (DHCPv6)", RFC3315, July 2003. 886 [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration 887 Protocol (DHCP) Leasequery", RFC4388, February 2006. 889 [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, 890 "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September 2007. 892 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 893 Autoconfiguration", RFC4862, September, 2007. 895 [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6 896 Leasequery", RFC5007, September 2007. 898 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 899 July 2008. 901 [IP Source Guard] Cisco, "Network Security Technologies and 902 Solutions", chapter 7, Cisco Press, May 20, 2008. 904 [draft-baker-savi-one-implementation-approach] F. Baker, "An 905 implementation approach to Source Address Validation", 906 draft-baker-savi-one-implementation-approach-00. 908 [draft-bi-savi-mixed] Jun Bi, "Mixed scenario analysis and best 909 effort solution", draft-bi-savi-mixed-00. 911 21. Acknowledgments 913 Special thanks to Christian Vogt and Joel M. Halpern for careful review 914 and valuation comments on the state machine and text. 915 Thanks to Marcelo Bagnulo Braun, Eric Levy-Abegnoli, Mark Williams, 916 Erik Nordmark, Mikael Abrahamsson, Alberto Garcia, Jari Arkko, David 917 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg 918 Daley, John Kaippallimalil and Tao Lin for their valuable contributions. 920 Authors' Addresses 922 Jun Bi 923 CERNET 924 Beijing, China 925 Email: junbi@cernet.edu.cn 927 Jianping Wu 928 CERNET 929 Beijing, China 930 Email: jianping@cernet.edu.cn 932 Guang Yao 933 Network Research Center, Tsinghua University 934 Beijing 100084, China 935 Email: yaog@netarchlab.tsinghua.edu.cn 937 Fred Baker 938 Cisco Systems 939 Email: fred@cisco.com 941 22. Change Log 943 From 02 to 03: Section 12, data trigger and counter trigger are 944 combined to binding recovery process. The expression "one of MUST" is 945 changed to "conditional MUST. Conditions related with the 946 implementation are specified. Related constants are changed in 947 section 26." 949 Main changes from 03 to 04: 951 - Section "Prefix configuration" is removed. 953 - Section "Supplemental binding process" is modified in 954 requirement level. 956 - Sub-section 9.1 "Rationale" is added. 958 - Section "Filtering during Detection" is removed. 960 - Section "Handling layer 2 path change" is changed to 961 "Consideration on Link layer routing complexity" 963 - Section "Background and related protocols" is removed. 965 Main changes from 04 to 05: 967 - Trigger events are listed explicitly in section 8. 969 - Dection and Live states are deleted, together with 970 corresponding sections. 972 Main change from 05 to 06: 974 - Section 8.1: reference section 20 is changed to section 15.