SAVI J. Bi, J. Wu, G. Yao Internet Draft CERNET Intended status: Standard Tracks F. Baker Expires: December 2009 Cisco July 29, 2009 Control Packet Snooping Based Binding draft-bi-savi-cps-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Bi Expires December 29,2009 [Page 1] Internet-Draft Control Packet Snooping Based Binding July 2009 This document specifies the Control Packet Snooping (CPS) mechanism for IP version 4 and IP version 6. This mechanism is used to set up binding between "authorized" source IP address of host and corresponding anchor on the access network device, including switch and wireless access point. The bindings are used to perform source address validation on packets sent by host. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Terminology ................................................. 3 4. Mechanism Overview .......................................... 4 5. Related Protocols ........................................... 4 6. Definition of Anchor......................................... 5 7. Conceptual Data Structures................................... 5 8. Scenarios ................................................... 7 8.1. Switch scenario......................................... 7 8.1.1. Port Attributes.................................... 7 8.1.1.1. SAVI-Host Attribute........................... 8 8.1.1.2. SAVI-DHCP-Trust Attribute .................... 8 8.1.1.3. SAVI-RA-Trust Attribute ...................... 8 8.1.1.4. SAVI-Trunk-Default Attribute ................. 9 8.1.1.5. SAVI-Trunk-Snooping Attribute ................ 9 8.2. Wireless Scenario....................................... 9 9. Prefix Configuration......................................... 9 10. Binding Set Up ............................................ 10 10.1. DHCPv4 Snooping....................................... 10 10.1.1. Process of DHCPv4 Snooping ...................... 10 10.1.2. State Machine of DHCPv4 Snooping ................ 11 10.2. DHCPv6 Snooping....................................... 11 10.2.1. Process of DHCPv6 Snooping ...................... 11 10.2.2. State Machine of DHCPv6 Snooping ................ 12 10.3. ND Snooping .......................................... 13 10.3.1. Process of ND Snooping........................... 13 10.3.2. State Machine of ND Snooping .................... 13 10.4. ARP Snooping ......................................... 14 10.4.1. Process of ARP Snooping.......................... 14 10.4.2. State Machine of ARP Snooping ................... 14 10.5. Manually Binding...................................... 15 11. Clear Binding ............................................. 15 12. Filtering Specification.................................... 15 12.1. Filter Data Packet.................................... 15 12.2. Filter Control Packet................................. 16 13. Solution for Special Situations............................ 16 13.1. Multiple Interfaces................................... 17 Bi Expires January 29, 2010 [Page 2] Internet-Draft Control Packet Snooping Based Binding July 2009 13.2. Port Movement ........................................ 17 14. Considerations on Security Risks........................... 18 14.1. Operating system support.............................. 18 14.2. Malicious replier..................................... 19 14.3. Inactive node ........................................ 19 15. About Risk of Dropping Legal Packets ...................... 19 16. Compatible Mode ........................................... 21 17. Binding State Lost Problem................................. 22 18. Incremental Deployment Suggestion.......................... 22 19. Constants ................................................. 22 20. Security Considerations.................................... 23 21. IANA Considerations........................................ 23 22. References ................................................ 23 22.1. Normative References.................................. 23 22.2. Informative References................................ 23 23. Acknowledgments ........................................... 23 Appendix A. Operating System Support Situation ................ 25 Authors' Addresses ............................................ 26 1. Introduction This specification defines the Control Packet Snooping (CPS) mechanism for Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). Access devices (including access switches, and wireless access point/controller, etc) can use this mechanism to set up bindings between source IP addresses of hosts and corresponding anchors, in accordance with the appointed address assignment method. These bindings can be used to validate the source IP address in the packets received from directly attached hosts. 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. Terminology Anchor - The entity to bind source IP address with. SAVI switch - A switch deployed this mechanism. Non-SAVI switch - A switch not deployed any SAVI mechanism. Bi Expires January 29, 2010 [Page 3] Internet-Draft Control Packet Snooping Based Binding July 2009 4. Mechanism Overview This mechanism is designed to provide a host level source IP address validation granularity, as a supplement of BCP38. This mechanism is deployed on the access device (including access switch, wireless access point/controller, etc), and performs control packet snooping to set up bindings between "authorized" source IP address and corresponding anchors. It also allows manually configured binding. The bindings are then used to check the source address in the packets from the directly attached hosts. This mechanism requires no change on host, and no new protocol is designed. The deployed device can work with non-deployed device to support incrementally deployment (named non-SAVI device). Only the deployed area is protected. This mechanism can work with all the standard address allocation methods, including DHCP (RFC2131), DHCPv6 (RFC3315), SLAAC (RFC4862), and manual configuration for both IPv4 and IPv6. The binding entries generally are not permanent. Each binding has a lifetime, and some event may trigger the binding deletion. When their lifetime expires, or the event happens, this mechanism will delete the corresponding entry, or perform some process. The binding process based on DHCPv4 is inspired by the work of IP source guard. Our work is different from IP source guard on the requirement of collision detection, which is quite useful in a multiple address assignment methods environment. 5. Related Protocols All the protocols related with the IP address assignment are the in the scope of this mechanism, including: Dynamic Host Configuration Protocol version 4 (DHCPv4) - A host may use this protocol to get an IPv4 address. Dynamic Host Configuration Protocol version 6 (DHCPv6) - A host may use this protocol to get an IPv6 address. Neighbor Discovery Protocol (NDP) - Whenever a host wants to assign an IPv6 address to its interface, it must perform Duplicate Address Detection first, which is composed of NDP packets. The NDP is also used to detect whether a host is still reachable. Such NDP packets can be used to determine whether to delete a binding or not. Other kinds of NDP packets will be used in Compatible Mode to trigger bindings. Bi Expires January 29, 2010 [Page 4] Internet-Draft Control Packet Snooping Based Binding July 2009 Address Resolution Protocol (ARP) - Whenever a host wants assign an IPv4 address to its interface, it will send a gratuitous ARP to make sure this address is not being used. However, this function may not be supported by all the operating systems. ARP is also used to determine whether a host is still reachable. Such ARP packets can be used to determine whether to delete a binding or not. Other kinds of ARP packets will be used in Compatible Mode to trigger bindings. Secure Neighbor Discovery Protocol (SeND) - SeND is a special case of NDP. If a ND packet is also a SeND packet, the validity of the source address must be checked first before this packet is taken into the process of this mechanism. There is no other difference for the mechanism to process plain ND packet and SeND packet. 6. Definition of Anchor Anchor is an important concept for this mechanism. In this document, anchor is the entity to bind source address with. To make the binding secure, the anchor itself must be unspoofable. Generally, following entities can be used as anchor: Exclusive switch port - When a switch port is exclusive for a host, this port is unspoofable for other hosts. MAC address in 802.1ae/af and 802.11i - 802.1ae/af and 802.11i protect the security of MAC address. When such technology is deployed in the network, MAC address can be used as anchor. However, when strict secure anchor is not achievable in the network, loose secure anchor can be used. Generally, shared switch port and MAC address are loose secure anchors. Loose secure anchor may cause false negative, thus it is not recommended to use such anchors. This document doesn't specify which entities can be used as anchor, and how secure these anchors. 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 are redundancy between the two structures, for the consideration of separation of data plane and control plane. Binding State Table (BST) Bi Expires January 29, 2010 [Page 5] Internet-Draft Control Packet Snooping Based Binding July 2009 - This table contains this state of binding between source address and anchor. Entries are keyed on the anchor and source IP address. Each entry has a lifetime item which records the remaining lifetime of this entry, an item which records the state of this binding and an item record other information. Whenever the lifetime expires, the entry should be deleted, except for the entries with DHCPv4_DETECTION/ DHCPv4_DETECTION/SAC_START/MANUALv4_START state. 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 used to filter packet. Access Control List can be regarded as an instance of this table. The states of binding in Binding State Table are as follows: DHCPv4_START A DHCPv4 request is received from host, and it may trigger a new binding. DHCPv4_LIVE The DHCPv4 address is acknowledged by DHCP server. DHCPv4_DETECTION A gratuitous ARP has been sent by the host and it is waiting for the reply. DHCPv4_BOUND The address has passed duplicate detection and it is bound with the anchor. DHCPv6_START A DHCPv6 request or confirm is received from host. DHCPv6_LIVE A DCHPv6 reply is received from server, and an address is suggested. DHCPv6_DETECTION A Duplicate Address Detection (DAD) Neighbor Solicitation has been sent by the host, and it is waiting for the reply. DHCPv6_BOUND The address has passed DAD and it is bound with the anchor. SAC_START A DAD NS has been sent by the host. The target address is neither got from DHCP nor static. Bi Expires January 29, 2010 [Page 6] Internet-Draft Control Packet Snooping Based Binding July 2009 SAC_BOUND The address has passed DAD and it is bound with anchor. SAC_QUERY The bound address is being queried by another node. If there is no response in a time constant, the binding should be deleted. MANUALv4_START A gratuitous ARP has been sent by the host. The target address is neither got from DHCP nor static. MANUALv4_BOUND The address has passed DAD and it is bound with anchor. MANUALv4_QUERY The bound address is being queried by another node. If there is no response in a time constant, the binding should be deleted. STATIC The address is static and the binding should not be change. 8. Scenarios This section specifies the deployment scenarios. Two basic scenarios are discussed here: switch scenario and wireless scenario. 8.1. Switch scenario Switch scenario means a switched network composed by a number of switches. This mechanism is deployed on one or more of them. In a switch scenario, always port is used as anchor. This section specifies the attributes of switch port, and the process on each kind. The method of distinguishing each kind of port in management is through manual configuration. The port attribute is just conceptual. 8.1.1. Port Attributes The attribute of port depends on the role of the port. A port on a SAVI switch can be set to have none or more of all the attributes. If a port has an attribute, the corresponding snooping and filtering policy will be used on this port. If a port has Bi Expires January 29, 2010 [Page 7] Internet-Draft Control Packet Snooping Based Binding July 2009 multiple attributes, all the corresponding policies will be used. Conflict attributes MUST not be set to the same port. 8.1.1.1. SAVI-Host Attribute If and only if a port is directly connected with a host, this port can be set to have SAVI-Host attribute. Trunk port cannot be set to have this attribute. If a port has SAVI-Host attribute, control packet snooping MUST be performed on this port to set up bindings, and then the data packets from this port MUST be verified based on these bindings. 8.1.1.2. SAVI-DHCP-Trust Attribute If and only if a port is directly connected with a trustable DHCP server, or is a trunk port from which the DHCP reply should arrive, it can be set to have this attribute. When a port is configured to have SAVI-DHCP-Trust attribute, the switch trusts the DHCP reply messages from this port to establish bindings. If DHCP is used to assign address in the network, there should be at least one port has this attribute. DHCP reply message not from such ports MUST be dropped. In the situation DHCP-PD is used to configure prefix of the network, the switch also trust the Prefix Delegation message from port with this attribute. 8.1.1.3. SAVI-RA-Trust Attribute If and only if a port is directly connected with a trustable router, or is a trunk port from which the Router Advertisement should arrive, it can be set to have this attribute. When a port is configured to have a SAVI-RA-Trust attribute, the switch trusts the Router Advertisement messages from this port to learn the prefixes used on the link. There may be no SAVI-RA-Trust port in the network, even if only SLAAC is used to configure address. Router Advertisement received not from SAVI-RA-Trust port MUST be discarded. Bi Expires January 29, 2010 [Page 8] Internet-Draft Control Packet Snooping Based Binding July 2009 8.1.1.4. SAVI-Trunk-Default Attribute If and only if a port is a trunk port, it can be set to have this attribute. This attribute is a conflict attribute of SAVI-Host attribute and SAVI-Trunk-Snooping attribute. No packet snooping will be performed on port with this attribute. Packet from port with such attribute will be forwarded if its source address doesn't conflict existing local bindings. 8.1.1.5. SAVI-Trunk-Snooping Attribute If and only if a port is a trunk port, it can be set to have this attribute. This attribute is a conflict attribute of SAVI-Host attribute and SAVI-Trunk-Default attribute. Control packet snooping MUST be performed on port with this attribute. The filtering policy on port with such attribute is based on "default-forwarding" principle, which means packets from this port can be forwarded if its source address doesn't conflict local bindings. It is not SUGGESTED to set a trunk port to have this attribute, unless it is found that only to set a port to have this attribute will achieve the spoofing mitigation goal. Setting a port to have this attribute will possibly result in forwarding performance problem. 8.2. Wireless Scenario In a wireless scenario, usually MAC address is used as anchor. Currently there is nothing to specify in wireless scenario. 9. Prefix Configuration Before setting up a host-level granularity binding table, it is important to configure correct prefixes on the SAVI device. At least two prefix scopes must be set: the IPv4 prefix and IPv6 prefixes. This document suggests set 3 prefix scopes: IPv4 Prefix: The allowed scope of any kind of IPv4 addresses. It can be set manually. IPv6 SLAAC Prefixes: Bi Expires January 29, 2010 [Page 9] Internet-Draft Control Packet Snooping Based Binding July 2009 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, or manual configuration. FE80::/64 MUST be set to a feasible prefix. IPv6 DHCPv6 Prefixes: The allowed scope of DHCPv6 addresses. It can be set through DHCP-PD protocol, or manual configuration. If some of the prefix scope is set to have non prefix, it implies corresponding address assignment method is not allowed in the network. There is no need to explicitly present these prefix scopes. But these restrictions MUST be used as premier check in binding set up. 10. Binding Set Up This section specifies how to set up bindings based on control packet snooping. Control packet snooping is only performed on the ports with SAVI-Host attribute or SAVI-Trunk-Snooping attribute. 10.1. DHCPv4 Snooping 10.1.1. Process of DHCPv4 Snooping This process is designed for DHCPv4 assigned address. Whenever a DHCPv4 request is received from attaching host, and the requested IP address does not exist in the binding table, the device will generate an entry in the Binding State Table (BST), set the state field to be DHCPv4_START. The lifetime of this entry is set to be MAX_DHCP_RESPONSE_TIME. The TID field of the request packet is also recorded in the entry. If an entry is already in the BST and the state of the entry is DHCPv4_START, set the lifetime field to be MAX_DHCP_RESPONSE_TIME. Whenever a DHCPv4 acknowledgement is received from the DHCP server, if the TID is in BST, and the state of the entry is DHCPv4_START, set the state of the entry to be DHCPv4_LIVE. The lifetime of the entry is set to be MAX_ARP_PREPARE_DELAY. The lease time is also recorded in the entry. Whenever a gratuitous ARP request is received from the host, if the state of the entry is DHCPv4_LIVE, set the state of the entry to be Bi Expires January 29, 2010 [Page 10] Internet-Draft Control Packet Snooping Based Binding July 2009 DHCPv4_DETECTION. The lifetime of the entry is set to be MAX_ARP _DELAY. If an ARP response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be DHCPv4_BOUND. The lifetime of this entry is set to the lease time of the entry. An entry is added into the Filter Table. Whenever a DHCPv4 decline is received from the host, if the state of the entry is DHCPv4_LIVE, delete the entry in BST. Whenever a DHCPv4 release is received from the host, if the state of the entry is DHCPv4_BOUND, delete the entry in BST and Filter Table. If a DHCPv4 acknowledgement with renew/rebind sign is received from the server, set lifetime of the entry in BST to be the new lease time. If the lifetime of an entry with state DHCPv4_BOUND expires, delete the entry in BST and Filter Table. 10.1.2. State Machine of DHCPv4 Snooping State Packet/Event Action Next State Start DHCPv4 REQ Set up new entry DHCPv4_START DHCPv4_START DHCPv4 ACK Record lease time DHCPv4_LIVE DHCPv4_LIVE Gra ARP REQ - DHCPv4_DETECTION DHCPv4_LIVE DHCPv4 DEC Remove entry Start DHCPv4_DETECTION Timeout Insert into FT DHCPv4_BOUND DHCPv4_DETECTION Gra ARP RPL Remove entry Start DHCPv4_DETECTION DHCPv4 DEC Remove entry Start DHCPv4_BOUND DHCPv4 REL Remove entry Start DHCPv4_BOUND DHCPv4 REN/REB Set new lifetime DHCPv4_BOUND 10.2. DHCPv6 Snooping 10.2.1. Process of DHCPv6 Snooping This process is designed for DHCPv6 assigned address. Bi Expires January 29, 2010 [Page 11] Internet-Draft Control Packet Snooping Based Binding July 2009 Whenever a DHCPv6 request or confirm is received from attaching host, and the requested IP address does not exist in the binding table, the device will generate an entry in the BST, set the state field to be DHCPv6_START. The lifetime of this entry is set to be MAX_DHCP_RESPONSE_TIME. The source address of the request packet is also recorded in the entry. If an entry is already in the BST and the state of the entry is DHCPv6_START, set the lifetime field to be MAX_DHCP_RESPONSE_TIME. Whenever a DHCPv6 reply is received from the DHCP server, if the TID is in BST, and the state of the entry is DHCPv6_START, set the state of the entry to be DHCPv6_LIVE. The lifetime of the entry is set to be MAX_DAD_PREPARE_DELAY. The lease time is also recorded in the entry. Whenever a DAD NS is received from the host, if the state of the entry is DHCPv6_LIVE, set the state of the entry to be DHCPv6_DETECTION. The lifetime of the entry is set to be MAX_DAD _DELAY. If an NA response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be DHCPv6_BOUND. The lifetime of this entry is set to the lease time of the entry. An entry is added into the Filter Table. Whenever a DHCPv6 decline is received from the host, if the state of the entry is DHCPv6_LIVE, delete the entry in BST. Whenever a DHCPv6 release is received from the host, if the state of the entry is DHCPv6_BOUND, delete the entry in BST and Filter Table. If a DHCPv6 reply with renew/rebind sign is received from the server, set lifetime of the entry in BST to be the new lease time. If the lifetime of an entry with state DHCPv6_BOUND expires, delete the entry in BST and Filter Table. 10.2.2. State Machine of DHCPv6 Snooping State Packet/Event Action Next State Start DHCPv6 REQ/CON Set up new entry DHCPv6_START DHCPv6_START DHCPv6 RLY Record lease time DHCPv6_LIVE DHCPv6_LIVE DAD NS - DHCPv6_DETECTION DHCPv6_DETECTION Timeout Insert into FT DHCPv6_BOUND Bi Expires January 29, 2010 [Page 12] Internet-Draft Control Packet Snooping Based Binding July 2009 DHCPv6_DETECTION DAD NA RLY Remove entry Start DHCPv6_LIVE DHCPv6 DEC Remove entry Start DHCPv6_BOUND DHCPv6 REL Remove entry Start DHCPv6_BOUND DHCPv4 REN/REB Set new lifetime DHCPv6_BOUND 10.3. ND Snooping 10.3.1. Process of ND Snooping This process is designed for stateless auto-configuration assigned IPv6 address and manually configured IPv6 address. Whenever a DAD NS is received from the host, if the address is not in BST and has a permitted prefix, generate a new entry in BST and set the state of the entry to be SAC_START. The lifetime of the entry is set to be MAX_DAD _DELAY. If an NA response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be SAC_BOUND. The lifetime of this entry is set to MAX_SAC_LIFETIME. An entry is added into the Filter Table. If the lifetime of an entry with state SAC_BOUND expires, set the lifetime to be MAX_DAD_PREPARE_DELAY and send a NS for the address. If there is no response before the lifetime expires, delete the entry in BST and Filter Table. Else set the lifetime to be MAX_SAC_LIFETIME. Whenever a NS with target address set to one of the addresses with state SAC_BOUND, the state of the entry is set to SAC_QUERY, and the lifetime is set to MAX_DAD_PREPARE_DELAY. If there is no response from the host before the lifetime expires, delete the entry in BST and Filter Table. If a response is received from the host, set the lifetime of the corresponding entry to be MAX_SAC_LIFETIME. 10.3.2. State Machine of ND Snooping State Packet/Event Action Next State Start DAD NS Set up new entry SAC_START SAC_START Timeout Insert into FT SAC_BOUND SAC_START DAD NA RLY Remove entry Start Bi Expires January 29, 2010 [Page 13] Internet-Draft Control Packet Snooping Based Binding July 2009 *SAC_BOUND NS for bound addr - SAC_QUERY *SAC_QUERY NA Set lifetime to maximum SAC_BOUND *SAC_QUERY Timeout Remove binding Start (* denotes optional process.) 10.4. ARP Snooping 10.4.1. Process of ARP Snooping This process is designed for manually configured IPv4 address. Whenever a gratuitous ARP is received from the host, if the address is not in BST and has a permitted prefix, generate a new entry in BST and set the state of the entry to be MANUALv4_START. The lifetime of the entry is set to be MAX_ARP_DELAY. If an ARP response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be MANUALv4_BOUND. The lifetime of this entry is set to MAX_MANUAL_LIFETIME. An entry is added into the Filter Table. If the lifetime of an entry with state MANUALv4_BOUND expires, set the lifetime to be MAX_ARP_PREPARE_DELAY and send an ARP request for the address. If there is no response before the lifetime expires, delete the entry in BST and Filter Table. Else set the lifetime to be MAX_MANUAL_LIFETIME. Whenever an ARP response with target address set to one of the addresses with state ARP_BOUND, the state of the entry is set to MANUALv4_QUERY, and the lifetime is set to MAX_ARP_PREPARE_DELAY. If there is no response from the host before the lifetime expires, delete the entry in BST and Filter Table. If a response is received from the host, set the lifetime of the corresponding entry to be MAX_MANUAL_LIFETIME. 10.4.2. State Machine of ARP Snooping State Packet/Event Action Next State Start Gra ARP REQ Set up new entry MANUALv4_START MANUALv4_START Timeout Insert into FT MANUALv4_BOUND MANUALv4_START Gra ARP RLY Remove entry Start Bi Expires January 29, 2010 [Page 14] Internet-Draft Control Packet Snooping Based Binding July 2009 *MANUALv4_BOUND ARP for bound addr MANUALv4_QUERY *MANUALv4_QUERY ARP RLY Set lifetime to maximum MANUALv4_BOUND *MANUALv4_QUERY Timeout Remove binding Start (* denotes optional process.) 10.5. Manually Binding To be compatible with manually configured static address, the BST is allowed to be configured manually. The configured binding has state STATIC and has an infinite lifetime. 11. Clear Binding Whenever the lifetime of DHCP assigned entry in the BST expires, it MUST be removed from the BST. If this binding has been inserted in to Filtering Table, this binding also MUST be removed. Whenever the lifetime of an address not assigned by DHCP expires, the switch MUST send a NS or NUD or ARP request to detect whether this address is still in use. If there is no response from the corresponding node, this binding MUST be deleted; or else, set to lifetime of this entry to be the corresponding maximum value. Whenever a node is disconnected at link layer, the corresponding bindings in BST and Filtering Table MUST be removed unless the state of the entry is STATIC. 12. Filtering Specification This section specifies how to use bindings to filtering packets. 12.1. Filter Data Packet In a switch scenario, data packets are filtered only on port with SAVI-Host attribute, SAVI-Trunk-Default attribute, or SAVI-Trunk- Snooping attribute. There can be port with none of these attributes. Filtering on port with SAVI-Host attribute strictly complies with the Filtering Table set up on the port. If the source of the packet is in the binding table of the port, this packet will be forwarded; or else the packet MUST be discarded. Filtering on port with SAVI-Trunk-Default attribute is based on checking whether the source is in the Filtering Table. If it is not Bi Expires January 29, 2010 [Page 15] Internet-Draft Control Packet Snooping Based Binding July 2009 in the filtering table, the packet can be forwarded; or else, the packet MUST be discarded. Filtering on port with SAVI-Trunk-Snooping attribute is based on checking whether the source is bound on this port or conflicted with bindings on the other ports. If the address has been bound with the port, the packet can be forwarded; if the address is not bound with the port, but neither bound with any other port, the packet can be forwarded; if the address is bound with another port, the packet MUST be discarded. In a wireless scenario, all the filtering MUST be strictly complying with Filtering Table. 12.2. Filter Control Packet The source address of the control packet is always all zero (DHCPv4, IPv6 Stateless auto-configuration for link-local address) or unbound address (gratuitous ARP). Such packets don't have to pass the check on Filter Table. However, the source address of DHCPv6 request and IPv6 DAD NS for global address must pass the check on Filter Table, for always a unique link-local address is used. All Router Advertisement packets MUST be from port with SAVI-RA- Trust attribute. All DHCP Reply packets MUST be from port with SAVI- DHCP-Trust attribute. The target address in all the Neighbor Advertisement packets and the sender's address in all ARP relies should also pass the checks on Filter Table. The Target address in Neighbor Advertisement packet and DHCP Reply packet MUST be in the corresponding prefix scope. For control packet from port with SAVI-Trunk-Default attribute, the field in the packet is checked whether there is a local conflict. For control packet from port with SAVI-Trunk-Snooping attribute, checking whether the source is bound on this port or conflicted with bindings on the other ports. 13. Solution for Special Situations Two situations described in the charter of SAVI working group may cause this mechanism filter packets improperly: multiple interfaces and port movement. The following is the proper solution for each situation. Bi Expires January 29, 2010 [Page 16] Internet-Draft Control Packet Snooping Based Binding July 2009 13.1. Multiple Interfaces If a host has multiple interfaces to the same LAN, generally this situation can be treated as multiple hosts with single interface because each interface will only use the address assigned to itself as source IP address. However, a host may configure the same address on multiple interfaces for the purpose of load balance. In this situation, the SAVI device may find an address bound with an anchor appears with another anchor, just as spoofing. This is the only multiple interfaces situation that troubles this mechanism. When this situation happens, the corresponding binding is seldom changed. Thus, manual configuration is enough for this situation. All the anchors with the host can be configured to be used by the same host and share the same entries in BST and Filtering Table. Other mechanisms can also be used to handle this situation, such as [SAVI-SeND] and [SAVI-HIP]. These mechanisms can be used to test whether two anchors are belonging to the same host and thus distinguish multiple interfaces from spoofing. However, all the mentioned mechanisms bring overhead to data packet process, and are not recommended. Currently, the only recommended mechanism is manual configuration. However, for the consideration that in the future, a host with multiple interfaces to the same network may become very common (for example, a host has a wired network interface and a wireless network interface attached to the same network, and they are configured to use the same address), an extension mechanism is still needed. The design of such mechanism is temporarily out of the scope of this document. 13.2. Port Movement DHCP assigned address and stateless address don't have the problem of port movement. If an address is assigned through DHCP, the address must be confirmed by DHCP server after port movement, and the control packets will used to set up new binding. For a stateless address, a duplicate detection must be performed when the interface is re-initialized, just as the process of address assignment. However, if an interface configured a static address changes port, because the corresponding is manually configured, this movement will conflict previous binding. The situation that a host with static address changes from one port to another can be handled through one of the following ways: Bi Expires January 29, 2010 [Page 17] Internet-Draft Control Packet Snooping Based Binding July 2009 - Manual configuration. If the host configured with static address seldom changes its port, the administrator can manually change the binding after each movement. - Changing anchor. If the anchor is not switch port, port movement will not cause any trouble. Thus an alternate way is choosing another entity as anchor, for example, the secure MAC address. - Access control mechanisms based on user account. Static address is always associated with specified user, thus the access control mechanism based on user account can be used to handle frequent port movements. 802.1x, PPPoE, and Portal are optional mechanisms. Whenever the user account is authenticated by there mechanisms, the corresponding address can be bound on the switch. The related protocol must be extended to enable such function. - Host identifier related mechanisms. [SAVI-SeND] and [SAVI-HIP] have a secure host identifier associated with the host, and this identifier can be used to handle port movement. The problem of such solutions is that they are based on immature techniques. 14. Considerations on Security Risks This mechanism has some potential risks. Some operating systems assign an address to interface without any duplicate detection. Other risks are due to the sync problem between host and SAVI device. 14.1. Operating system support The duplicate detection for IPv4 address has been prescribed in [RFC5227], but currently not all the operating systems perform duplicate detection on IPv4 address. Because the number of available IPv4 addresses in a LAN is small, a simplest solution is that whenever a new IPv4 address appears, the deployed device can perform duplicate detection instead of the host. However, this function will take data packet into control panel and would bring additional cost. A suggestion for the network administrator is IPv4 address should be assigned through DHCP or static. The supported operating systems are listed in Appendix A. For the operating system that cannot be updated, it is suggested to only use static address and set up binding manually, or only DHCPv4 is allowed to assign address. The duplicate detection for IPv6 address has been prescribed in [RFC4862]. However, some operating systems not supporting IPv6 well will not perform DAD when assigning IPv6 address. Bi Expires January 29, 2010 [Page 18] Internet-Draft Control Packet Snooping Based Binding July 2009 It is suggested that the operating systems should be able to update to support [RFC5227] and [RFC4862]. For the operating system that cannot be updated, it is suggested to only use static address and set up binding manually, or only DHCPv6 is allowed to assign address. An optional mode, named Compatible Mode, is designed to handle these situations. 14.2. Malicious replier Another risk is that the detection packet can be replied by a malicious attacker, and the host will be prevented from getting a proper address. This problem cannot be easily handled for it is caused by non-deployed nodes. The deployed device must filter Neighbor Advertisement packets, not only by source address, but also by target address. The sender's address in ARP replies should also be checked. A practical solution for this problem is as follows: 1. Divide the address space of SAVI nodes and non-SAVI nodes; 2. Partition SAVI nodes and non-SAVI nodes to different VLANs. Then the SAVI nodes don't have to ask the non-SAVI nodes whether an address has been used by some of them. 14.3. Inactive node The false negative may be caused by the situation that the detection packet is not replied by the assigned node. This is a troublesome situation. It is reasonable for a node to get such address because it is in accordance with the standard, unless the address is a static address. A simple process is removing the previous binding and setting up new binding for the requesting node. A more tolerant process is the SAVI device can perform ARP/ND proxy for the inactive node, and reduce the lifetime of binding to 1/4. 15. About Risk of Dropping Legal Packets If an address is used without binding set up on the switch, the packets with that address will be discarded by the switch. There are two situations when this happens: 1. No DAD is ever performed. Bi Expires January 29, 2010 [Page 19] Internet-Draft Control Packet Snooping Based Binding July 2009 In this situation, the packet cannot be regarded as "legal packet", because without previous DAD, neither the host nor the switch has the ability to determine whether it is a duplicated address. The conflict of this solution and some other solutions is whether to discard the packets without previous DAD, or forward them. Forwarding the packets has some secure problems. In case the address has been used by another host, the behavior of using duplicated address will harm the legitimate user and forwarding such packet is spoiling spoofing. Actually, it is very suspect that a host may use addresses without previous DAD to launch some kind of DoS attack. Discarding the suspect packets will possibly block a suspect host from the network, however, will never block a host whose behaviors comply with the standards. A mechanism should be designed on existing standards, and give benefit to those who comply with standards. The auxiliary mechanism that let the switch perform DAD instead of the host is a feasible solution but not suggested. This mechanism is more complex and with heavy overhead. 2. DAD is performed, but the DAD NS packet is lost before it is received by the switch. The DAD NS message may get lost before snooped by the switch because of link error. When this happens, there will be a sync problem between the host and the switch. The host will configure that address because it doesn't receive a NA for the tentative address. However, the switch would set up a binding for that address. As a result, the packets with the address will be discarded by the switch. Although today the link quality has been quite good, the packet lost problem still exists. The best solution is to configure the re-transmit time of DAD NS to be more than 1. 3 is a reasonable number. An optional mode, named Compatible Mode, is designed to handle these situations. Bi Expires January 29, 2010 [Page 20] Internet-Draft Control Packet Snooping Based Binding July 2009 16. Compatible Mode This mode is designed to let this mechanism be more tolerant to possible duplication detection packet lost, and non-standard- compliance operating system. This is an optional mode. When this mode is enabled, the switch will set up bindings based on NDP or ARP packets other than DAD packets and Gratuitous ARP packets. This section specifies how to use other kinds of control packets to set up bindings. If the address in these packets are not bound with other anchor and are in allowed prefix scope, the switch will perform duplicate detection instead of the sender of the packet to make sure the source address in the packet is unique in the local link. If the address is found to be not duplicated, it will be added into the Binding State Table and Filtering Table. If duplicate is found, the address SHOULD not be added into the Binding State Table and Filtering Table. Following packets will trigger the switch to set up bindings: ARP request: Source IPv4 address; ARP reply: Source IPv4 address; NA: Source address and target address; NS: Source address. The prefix of all the address MUST be in the scope of IPv4 Prefix or IPv6 SLAAC Prefixes. This mode can reduce the risk of dropping legitimate packets, because host will always use NDP or ARP to find other nodes on the link before sending any data traffic. The cost of the mode is still reasonable, because only control packets are used to trigger bindings. The data packets are still filtered based on Filtering Table. If duplicate is found after detection, the host would still send packet using the duplicated address because of sync problem. In this case, it is reasonable to filter the traffic from the host. This mode may be disturbed by a malicious node in non-SAVI area which sends NA on each DAD NS. Currently the best solution is dividing the non-SAVI area to different VLANs. Bi Expires January 29, 2010 [Page 21] Internet-Draft Control Packet Snooping Based Binding July 2009 17. DHCP-only Mode If only DHCP is used to assign address, the duplicate detection phase in binding set up can be omitted. However, if this mode is enabled, there must be confidence that the DHCP server wouldn't lose state. Or else, the duplicate detection phase still cannot be omitted. 18. Binding State Lost Problem When the SAVI switch reboots, the bindings on the switch will get lost for generally they are kept in volatile memory. Whenever the switch reboots, the interfaces of all the directly connected hosts will also be re-initialized. Then, if an address is assigned through DHCPv6, a CONFIRM message will be sent to the DHCP server. This message can be used to trigger re-binding of the previous address. For SLAAC address, the DAD procedure will be performed again, and a new binding will be set up. The bindings set up on port with SAVI-Trunk-Snooping attribute, cannot be recovered immediately. However, because "default- forwarding" policy is used on such ports, there is no risk of dropping legitimate traffic. The bindings on such ports can be recovered through snooping NDP and ARP packets using Compatible Mode. 19. Incremental Deployment Suggestion Because by default this mechanism doesn't set up bindings on trunk port, it may happen that a host connected to a downstream non-SAVI device can forge an address bound in SAVI area. To avoid this situation, it is suggested to separate SAVI area and non-SAVI areas into different VLANs, and assign different prefixes in these VLANs. Then the spoofing from non-SAVI area can be blocked through prefix check. And another way is to set the trunk ports to have SAVI-TRUNK- Snooping attribute. Then bindings can be set up on trunk port, and the bindings can be used to prevent spoofing from another trunk port. Because of the cost of this solution, it's better to carefully choose the trunk ports to be set this attribute. 20. Constants MAX_DHCP_RESPONSE_TIME 10s Bi Expires January 29, 2010 [Page 22] Internet-Draft Control Packet Snooping Based Binding July 2009 MAX_ARP_PREPARE_DELAY 1s MAX_ARP_DELAY 1s MAX_DAD_PREPARE_DELAY 1s MAX_DAD_DELAY 1s MAX_SAC_LIFETIME 2h MAX_MANUAL_LIFETIME 4h 21. Security Considerations There are no security considerations currently. 22. IANA Considerations There is no IANA consideration currently. 23. References 23.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, July 2008. [SAVI-SeND] M. Bagnulo, draft-ietf-savi-send-00.txt. [SAVI-HIP] D. Kuptsov, A. Gurtov and J. Bi, draft-kuptsov-sava-hip- 01.txt. 23.2. Informative References 24. Acknowledgments Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg Daley, Joel M. Halpern and Tao Lin for their valuable contributions. In particular the usage of unsolicited NA and NS prior to sending data packets to create binding table (in addtional Bi Expires January 29, 2010 [Page 23] Internet-Draft Control Packet Snooping Based Binding July 2009 to DAD packet) was suggested by Eric Levy-Abegnoli in response to an attack described by Marcelo Bagnulo Braun. Bi Expires January 29, 2010 [Page 24] Internet-Draft Control Packet Snooping Based Binding July 2009 Appendix A. Operating System Support Situation Supported systems: Windows XP SP2, Windows XP SP3, Windows Vista, Windows 7, Sun Solaris. Not supported systems: Ubuntu 8.10, Fedora 10. Bi Expires January 29, 2010 [Page 25] Internet-Draft Control Packet Snooping Based Binding July 2009 Authors' Addresses Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Jianping Wu CERNET Computer Science, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: yaog@netarchlab.tsinghua.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Bi Expires January 29, 2010 [Page 26]