SAVI J. Kaippallimalil Internet-Draft F. Xia Intended status: Standards Track Huawei USA Expires: December 28, 2012 J. Bi CERNET V. Ribiere, Ed. Cisco Systems June 26, 2012 Source Prefix Validation draft-ribiere-savi-prefix-guard-00 Abstract This document describes how SAVI concepts can be extended to provide Source Prefix Validation in enterprise and SP scenarios Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 28, 2012. Copyright Notice Copyright (c) 2012 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 Kaippallimalil, et al. Expires December 28, 2012 [Page 1] Internet-Draft SAVI prefix guard June 2012 described in the Simplified BSD License. Table of Contents 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture context . . . . . . . . . . . . . . . . . . . . . 4 3.1. Service Provider Scenarios . . . . . . . . . . . . . . . . 4 3.1.1. SAVI switch is Access Switch . . . . . . . . . . . . . 5 3.1.2. SAVI switch is not the Access Switch . . . . . . . . . 5 3.2. Enterprise Scenario . . . . . . . . . . . . . . . . . . . 6 4. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 7 4.1. Binding State Table (BST) . . . . . . . . . . . . . . . . 7 4.2. Filtering Table (FT) . . . . . . . . . . . . . . . . . . . 7 4.3. Binding State Description . . . . . . . . . . . . . . . . 8 5. Anchor Attributes . . . . . . . . . . . . . . . . . . . . . . 8 5.1. SAVI-Validation Attribute . . . . . . . . . . . . . . . . 8 5.2. SAVI-DHCP Trust Attribute . . . . . . . . . . . . . . . . 8 6. Recovery scenarios . . . . . . . . . . . . . . . . . . . . . . 8 6.1. DHCP-PD assigned prefixes . . . . . . . . . . . . . . . . 9 6.2. Router assigned prefixes . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Contributors and Acknowledgments . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Kaippallimalil, et al. Expires December 28, 2012 [Page 2] Internet-Draft SAVI prefix guard June 2012 1. Problem statement There are currently several documents [I-D.ietf-savi-framework] that describe the different methods by which a switch can discover and record bindings between a node's layer3 address and a binding anchor and use that binding to perform Source Address Validation. However SAVI existing solutions can not work when addresses can not be learned on the link. This is the case for example in Service Provider environments when prefixes are allocated to CPEs typically using DHCP prefix delegation. In this case the switch is connected to the home router not to home nodes and the source of the traffic is off-link. Even when addresses can be learned on the link and Savi existing solutions can be used there are limitations: o When the deployment model allows hosts to auto-configure any address the Savi device will be learning the addresses without validating them against the prefixes assigned by the router. o HW resources are limited. In that case it is very unefficient to have one filter for each host on the link when a single prefix range can be used. Source Prefix validation (or "Prefix Guard") can be used to overcome the above SAVI limitations. It finds out authorized prefixes and blocks any traffic that would be sourced with an address outside this range. In order to determine which prefixes should be allowed (and which ones that should be blocked) the switch has several "tools": 1. Snoop prefixes in Router Advertisements 2. Snoop prefixes in DHCP prefix delegation 3. Manual configuration Whenever a prefix is to be allowed, it will be downloaded to the hardware Filtering Table (FT). Whenever a packet is switched, the hardware will best match the source of the packet against this table and drop the packet if no match is found. This functionality is very close to Source Address Validation as far as filtering out data traffic as well as for discovering prefixes in control traffic. Reverse Path Forwarding as described in [RFC3704] can be used as an alternative to Source Prefix Validation but not in all scenarios. o RPF operates on a router or a switch with routing capabilities whereas Source Prefix validation can be done on a plain layer2 switch. o In a shared VLAN model where the Savi switch is not the access switch all CPEs are "seen" on the same interface: RPF will not be able to detect attacks where CPE1 is sourcing traffic from an address stolen from CPE2 allocated prefix range. Kaippallimalil, et al. Expires December 28, 2012 [Page 3] Internet-Draft SAVI prefix guard June 2012 We foresee two deployment scenarios where Source Prefix Validation is useful: o Service Provider scenarios where prefixes are assigned through DHCP-PD o Enterprise scenarios where prefixes are assigned by the local Router though Router Advertisements The purpose of this document is to describe how Source Prefix Validation can be used in those scenarios. 2. Terminology Host: A network device that connects to the service provider network through a residential gateway. User: An entity that attaches to the network using one or more hosts. The user is usually the subscriber that owns the CPE- Router. CPE-Router: Customer Premise Equipment Router. Gateway device located at the edge of the customer network and is an IP router. For a user within the customer network, the CPE-R is a gateway to the service provider network. Home Router: Same as CPE-Router network, the CPE-R is a gateway to the service provider network. DHCP: Dynamic Host Configuration Protocol MAC: Medium Access Control RPF: Reverse Path Forwarding. Ingress Filtering Technique where the source address is looked up in the Forwarding Information Base (FIB) - and if the packet is received on the interface which would be used to forward the traffic to the source of the packet, it passes the check. SAVI: Source Address Validation Improvements TID: Transaction Identity More definitions are described in [I-D.ietf-savi-framework]. 3. Architecture context 3.1. Service Provider Scenarios This scenario was described originally in [I-D.kaippallimalil-savi-dhcp-pd]. Prefixes are "allocated" to CPEs, typically using DHCP prefix delegation (as described in [RFC3633]) , but can also be manually provisioned. The SAVI switch is connected to the CPEs not to home nodes; hence Source Address Validation operating at the address level has very limited value. It knows the router addresses, but the nodes that source most of the traffic are the hosts behind the CPEs, and their addresses are assigned using Kaippallimalil, et al. Expires December 28, 2012 [Page 4] Internet-Draft SAVI prefix guard June 2012 Stateless Address Autoconfiguration. However, the switch can know (by snooping DHCP prefix delegation traffic or by provisioning) which prefixes were assigned to the CPEs and can bind the prefixes to the anchor. It is key to identify the deployment model in order to determine the right binding anchor to be bound with the snooped prefixes. 3.1.1. SAVI switch is Access Switch In this scenario the anchor is the port facing the CPE since the SAVI switch is able to associate each CPE with a different port and installing a [prefix, port] filter in the filtering table is sufficient. Customer Network Service Provider Network +---+ +-------+ | H |------| CPE-1 |--- +---+ +-------+ \ \ +---+ +-------+ \+----------+ +---------+ | H |------| CPE-2 |------| SAVI |-----| DHCP | +---+ +-------+ | Switch | | Server | /+----------+ +---------+ +---+ +-------+ / | H |------| CPE-3 |---/ +---+ +-------+ Service Provider Network 3.1.2. SAVI switch is not the Access Switch In this scenario the port can not be the anchor because there is a layer 2 device (switch, DSLAM) between the CPE and the layer 3 switch and all data traffic is coming from this port. If each CPE is behind a dedicated vlan then the vlan can be used as the anchor and installing a [prefix, vlan, port] filter is sufficient. However most commonly all CPEs are within the same vlan (shared VLAN model). In this case the MAC address of the CPEs has to be used as an anchor and installing a [prefix, vlan, port, mac] filter in the filtering table is required. Kaippallimalil, et al. Expires December 28, 2012 [Page 5] Internet-Draft SAVI prefix guard June 2012 Customer Network Service Provider Network +---+ +-------+ | H |------| CPE-1 |--- +---+ +-------+ \ \ +---+ +-------+ \+----------+ +---------+ +---------+ | H |------| CPE-2 |------| Access |-----| SAVI |----| DHCP | +---+ +-------+ | Switch | | Switch | | Server | /+----------+ +---------+ +---------+ +---+ +-------+ / | H |------| CPE-3 |---/ +---+ +-------+ 3.2. Enterprise Scenario In this scenario, the source of the traffic is on-link, as shown in the figure below: Enterprise Network Internet +------+ | Host | +------+ \ \ +------+ +--------+ +-------------+ | Host |-----| Switch |--------| Router |---- +------+ /+--------+ +-------------+ / +------+ | Host | +------+ The goal is to block traffic sourced from an address within an unknown prefix. There are two situations where this might be useful: The deployment setup makes no or limited usage of DHCP, and in particular allow hosts to auto configure and use global addresses. In this model, a node could allocate itself any address, including non-topologically correct, using a forged prefix. Classical Source Address Validation will learn these addresses via Neighbor Discovery "snooping", install them into the Hardware Filtering Table and won't be able to block traffic sourced from these addresses at the switch. The router might be able to do so using Reverse Path Forwarding check, but at the higher cost than the switch. Note that in this Kaippallimalil, et al. Expires December 28, 2012 [Page 6] Internet-Draft SAVI prefix guard June 2012 scenario a [prefix, vlan] filter is sufficient. The other scenario where the prefix-guard feature may be useful in an enterprise deployment is when the switch is running out of filtering entries to filter out individual addresses. In that case filtering at the prefix level, while less efficient, has some value. 4. Conceptual Data Structures This section describes a set of conceptual data structures that are necessary for this mechanism. Two key data structures are used to record bindings and their states. The Binding State Table (BST) contains enties populated based on snooping the RFC3633 or RFC4861 protocol. The Filtering Table (FT) contains bindings used to filter data plane traffic. 4.1. Binding State Table (BST) This table contains the state of bindings between source IPv6 prefix and anchor. Entries are keyed on anchor and source IPv6 prefix. Each entry has length of prefix, lifetime field containing the lifetime of the entry, a field recording the state of the binding, the default Router interface MAC address and a field for other information. +--------+--------+--------+-------+----------+--------+ | Anchor | Prefix | Length | State | Lifetime | Other | +--------+--------+--------+-------+----------+--------+ | A | IP_1 | 56 | Bound | 65535 | | +--------+--------+--------+-------+----------+--------+ | A | IP_2 | 56 | Bound | 10000 | | +--------+--------+--------+-------+----------+--------+ | B | IP_3 | 60 |_Start | 1 | | +--------+--------+--------+-------+----------+--------+ Instance of BST 4.2. Filtering Table (FT) This table contains the bindings between anchor and prefix/length, keyed on anchor. This table does not contain any state of the binding. It is used to filter packet. Kaippallimalil, et al. Expires December 28, 2012 [Page 7] Internet-Draft SAVI prefix guard June 2012 +---------+--------+--------+ |Anchor |Prefix | Length | +---------+--------+--------+ |A |IP_1 | 56 | +---------+--------+--------+ |A |IP_2 | 56 | +---------+--------+--------+ Instance of FT 4.3. Binding State Description This section describes the binding states of this mechanism. START A DHCPv6 request with IA_PD is received from customer router. BOUND The prefix is assigned to the customer and bound to the anchor. Note that states are only needed if the binding is created. The specific procedures to set binding state to BOUND is internal to a switch and is not specified further. 5. Anchor Attributes This section specifies the anchor attributes involved in this mechanism. 5.1. SAVI-Validation Attribute The SAVI-Validation attribute should be set if and only if source prefix validation must be performed on traffic from this anchor. 5.2. SAVI-DHCP Trust Attribute The SAVI-DHCP Trust attribute must be set if and only if an anchor is associated with a trustable DHCP server relay. 6. Recovery scenarios [RFC6620] and [I-D.ietf-savi-dhcp] describe scenarios where the SAVI device may not have a node binding and provide mechanisms to recover upon receiving a data packet from an unknown source. It may also happen that the switch looses the prefix information - the most simple example being if the switch reboots. This will result in data packets being dropped. Kaippallimalil, et al. Expires December 28, 2012 [Page 8] Internet-Draft SAVI prefix guard June 2012 6.1. DHCP-PD assigned prefixes The preferred mechanism is a proactive DHCPv6 Bulk Leasequery as described in [RFC5460]. In the event of a reboot the SAVI device SHOULD query the DHCP server with a LEASEQUERY message. In return DHCP server will provide the prefix(es) information along with the CPE(s) MAC and port. Alternatively the same mechanism used for individually assigned DHCPv6 addresses COULD be used for assigned prefixes as described in [RFC5007]. Upon receiving a data packet for which no filter in FT matches a LEASEQUERY message is sent to All_DHCP_Relay_Agents_and_Servers multicast address. A query by IPv6 address allows the DHCP server to return the matching prefix information along with the CPE MAC and port. 6.2. Router assigned prefixes Upon reboot the SAVI device COULD proactively generate a RS message on interfaces facing a router. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-savi-dhcp] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for DHCP", draft-ietf-savi-dhcp-12 (work in progress), February 2012. [I-D.ietf-savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement Framework", draft-ietf-savi-framework-06 (work in progress), January 2012. [I-D.kaippallimalil-savi-dhcp-pd] Kaippallimalil, J., Xia, F., and J. Bi, "SAVI Solution for Delegated IPv6 Prefixes", draft-kaippallimalil-savi-dhcp-pd-01 (work in progress), February 2010. Kaippallimalil, et al. Expires December 28, 2012 [Page 9] Internet-Draft SAVI prefix guard June 2012 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007. [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009. [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012. Appendix A. Contributors and Acknowledgments Thanks to Eric Levy-Abegnoli for his valuable contributions. Kaippallimalil, et al. Expires December 28, 2012 [Page 10] Internet-Draft SAVI prefix guard June 2012 Authors' Addresses John Kaippallimalil Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA Email: john.kaippallimalil@huawei.com Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA Email: xiayangsong@huawei.com Jun bi CERNET Network Research Center, Tsinghua University Beijing, 100084 China Email: junbi@cernet.edu.cn Vincent Ribiere (editor) Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410 France Email: ribiere@cisco.com Kaippallimalil, et al. Expires December 28, 2012 [Page 11]