SAVI J. Bi Internet Draft CERNET Intended status: Standard Tracks G. Yao Expires: October 2010 Tsinghua Univ. J. Wu CERNET Fred Baker CISCO April 18, 2010 SAVI Solution for Stateless Address draft-bi-savi-stateless-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt Bi Expires October 18, 2010 [Page 1] Internet-Draft savi-stateless April 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 18, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document specifies the procedure for creating bindings between a stateless address (including Stateless Autoconfiguration Address, manually configured non-static address, etc) and an anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged IP addresses. Different from other proposed solution for stateless address (e.g., SAVI-FCFS), this solution follows RFC4862 to arbitrate the ownership of address. Supplemental binding processes are also specified to cover conditions that cannot be handled by control packet snooping. Table of Contents Copyright Notice ............................................... 2 Abstract ....................................................... 2 1. Introduction ................................................ 4 2. Conventions used in this document............................ 4 3. Mechanism Overview .......................................... 4 4. Basic Principle of Address Ownership Arbitration............. 4 5. Background and Related Protocols............................. 5 6. Terminology ................................................. 6 7. Conceptual Data Structures................................... 6 7.1. Binding State Table (BST)............................... 6 7.2. Filtering Table (FT).................................... 7 Bi Expires October 18, 2010 [Page 2] Internet-Draft savi-stateless April 2010 8. Binding States Description................................... 7 9. Stateless Scenario .......................................... 7 10. Anchor Attributes .......................................... 8 10.1. SAVI-Validation Attribute.............................. 8 10.2. SAVI-RA-Trust Attribute................................ 8 10.3. SAVI-SAVI Attribute.................................... 9 11. Prefix Configuration........................................ 9 12. Binding Set Up ............................................ 10 12.1. Process of Control Packet Snooping.................... 10 12.1.1. Initialization................................... 10 12.1.1.1. Trigger Event............................... 10 12.1.1.2. Event Validation............................ 10 12.1.1.3. Following Actions........................... 10 12.1.2. State Transit from DETECTION..................... 10 12.1.2.1. Trigger Event............................... 10 12.1.2.2. Following Actions........................... 11 12.1.3. After BOUND...................................... 11 12.2. State Machine of DAD Snooping......................... 11 13. Supplemental Binding Processes............................. 12 13.1. Rate-limited Data Triggered Binding Process........... 12 13.2. Counter Triggered Process............................. 13 13.3. External Control Packet Snooping Process.............. 14 13.3.1. SAVI-ExtSnooping Attribute....................... 14 13.3.2. Extended Control Packet Snooping................. 14 14. Filtering Specification.................................... 15 14.1. Data Packet Filtering................................. 15 14.2. Control Packet Filtering.............................. 15 15. Format and Delivery of Probe Messages...................... 15 15.1. Duplicate detection................................... 16 16. Binding Remove ............................................ 16 17. Handle Anchor Off-link event............................... 16 18. About Collision in Detection............................... 17 18.1. The Result of Detection without Host Aware............ 17 19. Filtering during Detection................................. 17 20. Binding Number Limitation.................................. 17 21. MLD Consideration ......................................... 18 22. Link Layer Address Binding Toleration...................... 18 23. Handle Layer 2 Path Change................................. 18 24. State Restoration ......................................... 18 25. Constants ................................................. 19 26. Security Considerations.................................... 19 27. IANA Considerations........................................ 19 28. References ................................................ 19 28.1. Normative References.................................. 19 28.2. Informative References................................ 19 29. Acknowledgments ........................................... 20 Bi Expires October 18, 2010 [Page 3] Internet-Draft savi-stateless April 2010 1. Introduction This document describes the procedure for creating bindings between stateless address and anchor (refer to [savi-framework]). Other related details about this procedure are also specified in this document. These bindings can be used to filter packets with forged IP addresses. How to use these bindings is specified in [savi-framework], depending on the environment and configuration. The definition and examples of anchor is also specified in [savi-framework]. The binding process is partially inspired by the work of SAVI-FCFS. Different from a data trigger based procedure in SAVI-FCFS, this specification mainly focuses on control panel triggered process. Supplement binding processes are designed to cover deficiency of control packet snooping. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Mechanism Overview The mechanism specified in this document is designed to provide a host level source IP address validation granularity, as a supplement to BCP38 [BCP38]. This mechanism is deployed on the access device (including access switch, wireless access point/controller, etc), and performs mainly NDP/ARP snooping to set up bindings between stateless IP addresses and corresponding anchors. The bindings can be used to validate the source address in the packets. 4. Basic Principle of Address Ownership Arbitration In stateless scenario, nodes can "assign" address to themselves, and perform unreliable duplicate detection to check whether the address is being used. For IPv6 address, collision happens with very little probability because of large address space, thus the unreliable nature of DAD is not serious in reality. However, the unreliability of DAD troubles source address validation. It is very hard, if not impossible, for a SAVI device to determine which node can use one address when conflict happens. A wise principle, "First Come First Served" is currently used by SAVI-FCFS to determine ownership of address. This principle is Bi Expires October 18, 2010 [Page 4] Internet-Draft savi-stateless April 2010 correct, however, the problem is, how to determine which node is the first to use an address. Because the unreliable nature of DAD, the first one assigned itself an address, may not be the one first using the address to send traffic sniffed by the SAVI device. SAVI-FCFS requires device to send detection probes to determine whether an address is being used by another node. However, this effort may be vain, because malicious node can reply any probe, and the probe is still unreliable to reach the possible target node. After a long time attempt, we finally find that because of the unreliability of DAD and ND, there is no perfect arbitration policy. In another word, if a arbitration policy is perfect, it must rely on a reliable DAD. We can prove this through a simple deduction: Perfect arbitrate=> The one having assigned itself an address first gets the ownership of the address=> The one having performed DAD first gets the address=> The arbitrator must know who is the first to perform DAD=> The DAD must be reliable to be sniffed by the SAVI device. And the deduction can be reversed. In the end, we found we were building tower on the quick sand. It concerns nothing about whether choosing data trigger or control packet trigger. Unless stateless assignment changes to be reliable, no solution can be secure. In this document, we decide to follow RFC4862, which is the only stand track on stateless address assignment. This means, if a node finishes a successful DAD, including the DAD is performed by SAVI device in case of data trigger, the address MUST be bound with it. Then the ownership conflict is actually handled through allowing one address to be bound with multiple anchors. The bindings are only removed when the lifetime expires, which equals prefix life time learned from RA. Then we achieve a simple solution, whose security is based on the reliability of RFC4862. 5. Background and Related Protocols This mechanism is an instance of a SAVI [savi-framework] solution, specialized for stateless addresses, including IPv6 Stateless Bi Expires October 18, 2010 [Page 5] Internet-Draft savi-stateless April 2010 Autoconfiguration address, manually configured non-static IPv6 and IPv4 address. In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is a widely deployed address assignment mechanism. A node can generate an address autonomously, and use Duplicate Address Detection described in [RFC4862] to auto-configure this address. [RFC4862] clearly requires that duplicated address detection must be performed on any IPv6 address, including DHCPv6 address. This is the basis of this control packet snooping based SAVI solution. [RFC4861] specifies the Neighbor Discovery protocol, which is an essential part of IPv6 address assignment. IPv4 doesn't have stateless auto-configuration mechanism, because of the high collision probability of auto-generated address. However, in some scenarios, interfaces are allowed to be configured addresses with a specified prefix, instead of assigning each interface a static address. In such scenarios, the address assignment method is regarded as stateless in this document. [RFC5227] specifies the procedure to detect IPv4 address collision. It is not required currently. However, this feature is useful to determine the uniqueness of an IPv4 address on the link. Considering not all the operating systems support [RFC5227], this solution is designed to be compatible with operating systems not complying with [RFC5227]. 6. Terminology Main terms used in this document are described in [savi-framework], [RFC4862], [RFC826] and [RFC5227]. 7. Conceptual Data Structures This section describes the possible conceptual data structures used in this mechanism. Two main data structures are used to record bindings and their states respectively. There is redundancy between the two structures, for the consideration of separation of data plane and control plane. 7.1. Binding State Table (BST) This table contains the state of binding between source address and anchor. Entries are keyed on the anchor and source IP address. Each Bi Expires October 18, 2010 [Page 6] Internet-Draft savi-stateless April 2010 entry has a lifetime field recording the remaining lifetime of the entry, and a state field recording the state of the binding. +---------+----------+-------+-----------+ | Anchor | Address | State | Lifetime | +---------+----------+-------+-----------+ | A | IP_1 | Bound | 65535 | +---------+----------+-------+-----------+ | A | IP_2 | Bound | 10000 | +---------+----------+-------+-----------+ | B | IP_1 |_Bound | 1 | +---------+----------+-------+-----------+ Figure 1 Instance of BST 7.2. Filtering Table (FT) This table contains the bindings between anchor and address, keyed on anchor. This table doesn't contain any state of the binding. This table is only used to filter packets. An Access Control List can be regarded as a practical instance of this table. +---------+----------+ |Anchor |Address | +---------+----------+ |A |IP_1 | +---------+----------+ |A |IP_2 | +---------+----------+ Figure 2 Instance of FT 8. Binding States Description This section describes the binding states of this mechanism. DETECTION A gratuitous ARP or Duplicate Address Detection Neighbor Solicitation has been sent by the host (or the SAVI device). BOUND The address has passed duplicate detection and it is bound with the anchor. 9. Stateless Scenario Figure 3 shows the main elements in a stateless address allowed network. Nodes generate address themselves without the assistance of Bi Expires October 18, 2010 [Page 7] Internet-Draft savi-stateless April 2010 any other server. Other address assignment mechanisms may be also used in such network. +----------+ | SAVI | | Device | +-/------/-+ | | +----\-+ +\-----+ |Node 1| |Node 2| | | | | +------+ +------+ Figure 3 Stateless Scenario 10. Anchor Attributes This section specifies the anchor attributes involved in this mechanism. Anchor is defined in the [savi-framework]. Attribute of each anchor is configurable. In default, anchor has no attribute. An anchor MAY be configured to have one or more compatible attributes. However, an anchor MAY have no attribute. If an anchor has no attribute, in this solution, Router Advertisement message from this anchor MUST be dropped. However, other packets SHOULD NOT be dropped. 10.1. SAVI-Validation Attribute If and only if source address validation must be performed on the traffic from an anchor, this anchor MUST be set to have SAVI- Validation attribute. The filtering process on anchor with such attribute is described in section 12. 10.2. SAVI-RA-Trust Attribute If and only if an anchor is associated with a trustable router, it SHOULD be set to have this attribute. On a SAVI device enabled this solution, there may be no anchor with this attribute. This implies only link-local address is allowed, or prefix validation is not enabled, or only manually configured prefix is allowed. Router Advertisement message not coming from such anchors MUST be dropped. Bi Expires October 18, 2010 [Page 8] Internet-Draft savi-stateless April 2010 10.3. SAVI-SAVI Attribute If and only if an anchor is associated with another SAVI device, it SHOULD be set to have this attribute. All traffic from anchor with this attribute will be forwarded without check. This attribute can also be set on other anchors if the administrator decides not to validate the traffic from the anchor. Note that DHCP server message and Router Advertisement will also be trusted. This attribute is mutually exclusive with SAVI-Validation. 11. Prefix Configuration Because Duplicate Address Detection doesn't have the function of checking the validity of the prefix of address, in this solution, it is SUGGESTED that correct address prefix SHOULD be configured. If the correct prefix is not configured, the SAVI device may bind anchors with addresses using bogus prefixes. Although a prefix level filtering mechanism, e.g., ingress filtering may be deployed on the layer 3 device of the network, it cannot prevent spoofing in the local link. This document suggests set 3 prefix scopes: IPv4 Prefix: The allowed scope of any kind of IPv4 addresses. It can be set manually. IPv6 Prefixes: The allowed scope of SLAAC and manually configured IPv6 addresses. It can be set through snooping RA message from port with SAVI-RA-Trust attribute, DHCP-PD or manual configuration. FE80::/64 MUST be set to a feasible prefix. There is no need to explicitly present these prefix scopes. But these restrictions SHOULD be used as premier check in binding set up. Refer to security consideration for other discussions. Bi Expires October 18, 2010 [Page 9] Internet-Draft savi-stateless April 2010 12. Binding Set Up This section specifies the procedure of setting up bindings based on control packet snooping. The binding procedure specified here is exclusively designed for anchor with SAVI-Validation attribute. 12.1. Process of Control Packet Snooping 12.1.1. Initialization 12.1.1.1. Trigger Event A gratuitous ARP Request or Duplicate Address Detection Neighbor Solicitation is received from anchor. 12.1.1.2. Event Validation The SAVI device checks the BST as follows: 1. Whether binding number limitation will be exceeded if a new binding entry is set up. 12.1.1.3. Following Actions If the check is passed: The packet MUST be forwarded. An new entry MUST be generated, with state set to be DETECTION, and lifetime set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively. +---------+----------+-----------+-----------------+ | Anchor | Address | State | Lifetime | +---------+----------+-----------+-----------------+ | A | Addr | DETECTION |MAX_ARP_DELAY | | | | |MAX_DAD_DELAY | +---------+----------+-----------+-----------------+ Figure 4 Binding entry in BST on detection A new entry MUST be inserted into the FT. 12.1.2. State Transit from DETECTION 12.1.2.1. Trigger Event A timeout event of an entry with state DETECTION occurs or an ARP Response or NA for an address in BST with state DETECTION is received. Bi Expires October 18, 2010 [Page 10] Internet-Draft savi-stateless April 2010 12.1.2.2. Following Actions If a timeout event of an entry with state DETECTION occurs, set the state of the entry to be BOUND. The lifetime of the entry is set to be the lifetime of corresponding prefix, which is learn from RA. If the address is link local address, the lifetime of the binding SHOULD be set to INFINITE. +---------+----------+-----------+------------------------+ | Anchor | Address | State | Lifetime | +---------+----------+-----------+------------------------+ | A | Addr | BOUND | prefix lifetime | +---------+----------+-----------+------------------------+ Figure 5 Binding entry in BST on finalization If an ARP Response or NA for an address in BST with state DETECTION is received, remove the corresponding entry in BST and FT. The ARP Response or NA MUST be delivered to the client. 12.1.3. After BOUND Once a binding entry is set up for an anchor, the binding will be used to filter packet with the anchor, as specified in section 13. The state of the binding entry will not be affected by any message. If the lifetime of an entry with state BOUND expires, delete the entry in BST and Filter Table. Switch port down event (or more general, anchor turns off-link) will change the corresponding entry, as described in section 15. 12.2. State Machine of DAD Snooping The main state transits are listed as follows. Note that the anchor migration of binding entry is not included. State Message/Event Action Next State - Gra ARP/DAD NS Generate entry DETECTION DETECTION ARP RES/DAD NA Remove entry - DETECTION Timeout Finish binding BOUND BOUND Timeout Remove entry - Gra ARP REQ: Gratuitous ARP REQUEST Bi Expires October 18, 2010 [Page 11] Internet-Draft savi-stateless April 2010 ARP RES: ARP RESPONSE DAD NS: Duplicate Address Detection Neighbor Solicitation DAD NA: Neighbor Advertisement targeting at a tentative address 13. Supplemental Binding Processes Supplemental binding processes are designed to cover situations that no DAD procedure can be sensed by SAVI device. The typical situations include: DAD NS loss, layer-2 path change and movement on local link without triggering DAD procedure. This process is designed to avoid permanent blocking. It is not supposed that binding can be trigger whenever a data packet with unbound address is received. Generally a number of packets and more time are needed to trigger a binding. At least one of the following techniques MUST be implemented in SAVI device which deploys this solution: 1. Rate-limited Data Triggered Binding Process 2. Counter Triggered Process 3. Extended Control Packet Snooping Process Other techniques may be prudently chosen as alternative if found to have equivalent or even better function to avoid permanently blocking after discussion, implementation and deployment. 13.1. Rate-limited Data Triggered Binding Process 13.1.1. SAVI-DataTrigger Attribute If data trigger binding process is implemented as the supplemental binding process, an additional anchor attribute, named SAVI- DataTrigger, MUST be implemented. This attribute is mutually exclusive with SAVI-SAVI. Data triggered binding process will be performed on the anchor with such attribute. 13.1.2. Data Triggered Binding Process Bi Expires October 18, 2010 [Page 12] Internet-Draft savi-stateless April 2010 If an anchor is set to have SAVI-DataTrigger attribute, data packet whose source address is not bound with the anchor, may not be filtered directly; instead, the SAVI device will check whether the address can be used by the client on the local link with limited rate: 1. If the address has a local conflict, meaning the DAD on the address fails, the packet MUST be discarded. The DAD procedure is performed by the SAVI device, through sending two or more DAD NS probes. The format and delivery of the DAD NS is specified in section 15. If the DAD is successful, the address MUST be bound with the anchor, with a lifetime equal to lifetime of corresponding prefix. The data triggered process MUST be rate limited to avoid Denial of Services attack against the SAVI device itself. A constant DATA_TRIGGER_INTERVAL is used to control the frequency. Two data trigger processes on one anchor must have a minimum interval time DATA_TRIGGER_INTERVAL. This constant SHOULD be configured prudently to avoid Denial of Services. Data triggered process is not strict secure. The node with data- trigger anchor has the ability to use the address of an inactive node, which doesn't reply to the DAD probe. 13.2. Counter Triggered Process 13.2.1. SAVI-CounterTrigger Attribute If counter triggered binding process is implemented as the supplemental binding process, an additional anchor attribute, named SAVI-CounterTrigger, MUST be implemented. This attribute is mutually exclusive with SAVI-SAVI. Counter triggered binding process will be performed on the anchor with such attribute. 13.2.2. Counter Triggered Process In this process, a counter is used to record the number of filtered packets by this solution or all the enabled SAVI solutions on anchor with SAVI-CounterTrigger attribute. A constant TRIGGER_COUNT is set with the counter. Whenever the counter reaches TRIGGER_COUNT, this event MUST be handled by the SAVI device. The SAVI device performs following steps: Bi Expires October 18, 2010 [Page 13] Internet-Draft savi-stateless April 2010 1. Set the counter to 0; 2. Perform DAD process on the source address of the packet triggering this event, through sending two or more DAD NS probe as specified in section 15. If the DAD fails, the packet MUST be discarded. If the DAD is successful, a binding MUST be set up on the anchor. 3. This event MUST be announced to network administrator. For example, a SNMP trap may be triggered; or an alert on console interface may be generated. The constant TRIGGER_COUNT MUST be prudently configured to fit the specified deployment scenario. In extreme situation, it can be set to 1. 13.3. External Control Packet Snooping Process 13.3.1. SAVI-ExtSnooping Attribute If extended control packet snooping is implemented as the supplemental binding process, an additional anchor attribute, named SAVI-ExSnooping, MUST be implemented. This attribute is mutually exclusive with SAVI-SAVI. Extended control packet snooping process will be performed on the anchor with such attribute. 13.3.2. Extended Control Packet Snooping In this snooping process, other than DAD messages, other types of control packets processed by processor of SAVI device, if the source address is not bound, may trigger the device to perform binding process. The control messages that MUST be processed include: (1) address resolution Neighbor Solicitation; (2) Neighbor Advertisement; (3) neighbor unreachability detection; (4) Multicast Listener Discovery; (5) Address Resolution Protocol. Other ICMP messages that may be processed by intermediate device may also trigger the binding process. The SAVI device MUST perform DAD to check if the address has a local conflict. The format and delivery of DAD probe is specified in section 15. A minimum time interval EXT_SNOOPING_INTERVAL MUST be set to limit the rate of such triggering process. Bi Expires October 18, 2010 [Page 14] Internet-Draft savi-stateless April 2010 Note that this process may not be able to avoid permanent block, in case that only data packets are sent by node. Generally, this mechanism is still practical, because data packet sending without control plane communication is rare and suspicious in reality. Normal traffic will contain control plane communication packets to help traffic setup and fault diagnosis. 14. Filtering Specification This section specifies how to use bindings to filter packets. Because the Filtering Table is an allow-table, packet with source address not in the table will be filtered. Filtering policies are different for data packet and control packet. ND messages that may cause state transit are classified into control packet. Neighbor Advertisement and ARP Response are also included in control packet, because the Target Address of NA and ARP Response should be checked to prevent spoofing. All other packets are considered to be data packets. 14.1. Data Packet Filtering Data packets with an anchor which has attribute SAVI-Validation MUST be checked. If the source of a packet associated with its anchor is in the FT, this packet SHOULD be forwarded; or else the packet MUST be discarded. 14.2. Control Packet Filtering For anchors with SAVI-Validation attribute: The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the check on FT. The target address and source address in all the Neighbor Advertisement packets and ARP replies MUST also pass the checks on FT. For other anchors: All RA packets MUST be from anchor with the SAVI-RA-Trust attribute. 15. Format and Delivery of Probe Messages The SAVI device MAY send detection probes on behavior of node to determine whether the assigned address is duplicated in case of data Bi Expires October 18, 2010 [Page 15] Internet-Draft savi-stateless April 2010 trigger is enabled. Currently no other probes are designed in this solution. 15.1. Duplicate detection Message Type: DAD NS, Gratuitous ARP Request Format: Link layer source - link layer address of host; Link layer destination - For IPv6, use multicast address specified in [RFC3307]; For IPv4, use broadcast address; IP source - Unspecified address for IPv6; The tentative address for IPv4; IP destination - For IPv6, multicast address specified in section 5.4.2 of [RFC4861]; For IPv4, the tentative address; Delivery: MUST not be delivered to the host which the SAVI device is performing DAD on behavior of. 16. Binding Remove If the lifetime of an entry with state BOUND expires, the entry MUST be removed. 17. Handle Anchor Off-link event Port DOWN event MUST be handled if switch port is used as anchor. In more general case, if an anchor turns off-link, this event MUST be handled. Whenever an anchor with attribute SAVI-Validation turns down, the bindings with the anchor MUST be kept for a short time. To handle movement, if receiving DAD NS/Gra ARP request targeting at the address during the period, remove the entry. If the anchor turns on-link during the period, recover bindings. It may result in some security problem, e.g., a malicious node immediately associates with the anchor got off by a previous node, then it can use the address assigned to the previous node. However, Bi Expires October 18, 2010 [Page 16] Internet-Draft savi-stateless April 2010 this situation is very rare in reality. Authors decide not to handle this situation. 18. About Collision in Detection The SAVI device may receive a response in detection. Some related details are specified here. 18.1. The Result of Detection without Host Aware In case the SAVI device send detection packet instead of the host, the host will not be aware of the detection result. If the detection succeeds, there is no problem. However, if the detection fails, the packets from the host with the assigned address will be filtered out. This result can be regarded as a reasonable punishment for not performing duplicate detection and using a collision address. The SAVI device MAY choose to notice the client that the assigned address has been used, through a NA message. This mechanism is not required in this solution. 19. Filtering during Detection In this mechanism, whenever a DAD NSOL is received, this address will be allowed immediately even before duplicate detection is completed. This design is in consideration of a host may start to send packets straightway without detection. Also this design is to be compatible with optimistic DAD [RFC4429]. However, this feature may allow an attacker to send quantities of packets with source addresses already assigned to other nodes. 20. Binding Number Limitation It is suggested to configure some mechanism in order to prevent a single node from exhausting the binding table entries on the SAVI device. Either of the following mechanism is sufficient to prevent such attack. 1. Set the upper bound of binding number for each anchor with SAVI- Validation. 2. Reserve a number of binding entries for each anchor with SAVI- Validation attribute and all anchors share a pool of the other binding entries. 3. Limit DAD NSOL rate per anchor, using the bound entry number of each anchor as reverse indicator. Bi Expires October 18, 2010 [Page 17] Internet-Draft savi-stateless April 2010 21. MLD Consideration The SAVI device MUST join the tentative address multicast group whenever perform duplicate detection on behavior of host. 22. Link Layer Address Binding Toleration As packet is possible to get lost on the link, and the first packet, which is generally DAD for link layer address, has higher lost probability because of the link initialization or authentication mechanism, a more tolerable mechanism for link local address MUST be used to avoid false positive. Whenever a control message with link local source address is processed by this solution (ND, NA), if the address is not bound, the SAVI device MUST perform DAD to check the uniqueness of the address. If no collision is found, a binding entry for the link local address MUST be inserted into the binding table. Other layer 3 control messages, including MLD, MAY also be used to trigger this process. 23. Handle Layer 2 Path Change Layer 2 path change is an important challenge on this control plane based solution. The SAVI device MUST be sensitive to any layer 2 path change. Whenever a layer 2 control protocol frame, including STP, RSTP, TRILL, is received from some anchor, which announces a layer 2 incoming path is changed to the anchor, data packet trigger process MUST be enabled on the anchor for a period. Although generally such events can be handled through pre-configuration of data-trigger attribute, the future layer 2 protocol may be flexible and hard to handle through manual configuration. 24. State Restoration If a SAVI device reboots accidentally or designedly, the states kept in volatile memory will get lost. This may cause hosts indirectly attached to the SAVI device to be broken away from the network, because they can't recover bindings on the SAVI device of themselves. Thus, binding entries SHOULD be saved into non-volatile storage whenever a new binding entry changes to BOUND state or a binding with state BOUND is removed, unless other alternatives specified here is implemented. If binding is saved into non-volatile memory, immediately after reboot, the SAVI device MUST restore binding states from the non- Bi Expires October 18, 2010 [Page 18] Internet-Draft savi-stateless April 2010 volatile storage. The lifetime and the system time of save process MUST be stored. Then the device MUST check whether the saved entries are obsolete when rebooting. The possible alternative is: If the network enables 802.1ag, the bindings can be recovered with the help of the first hop routers through snooping unicast Neighbor Solicitations sent by routers based on the Neighbor Table. 25. Constants MAX_ARP_DELAY Default 1s but configurable MAX_DAD_DELAY Default 1s but configurable DATA_TRIGGER_INTERVAL Device capacity depended and configurable TRIGGER_COUNT Device capacity depended and configurable 26. Security Considerations For prefix level granularity filtering is the basis of host level granularity filtering, to learn and configure correct prefix is of great importance to this mechanism. Thus, it's important to keep RA and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a mechanism to improve the security of RA message. 27. IANA Considerations There is no IANA consideration currently. 28. References 28.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 28.2. Informative References [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast Addresses", RFC3307, August 2002. [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September 2007. Bi Expires October 18, 2010 [Page 19] Internet-Draft savi-stateless April 2010 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, July 2008. 29. Acknowledgments Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg Daley, Joel M. Halpern, Mikael Abrahamsson, John Kaippallimalil and Tao Lin for their valuable contributions. Bi Expires October 18, 2010 [Page 20] Internet-Draft savi-stateless April 2010 Authors' Addresses Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: yaog@netarchlab.tsinghua.edu.cn Jianping Wu CERNET Computer Science, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Bi Expires October 18, 2010 [Page 21]