Huawei USA

1700 Alma Dr. Suite 500 Plano, TX 75075 USA john.kaippallimalil@huawei.com

Huawei USA

1700 Alma Dr. Suite 500 Plano, TX 75075 USA xiayangsong@huawei.com

CERNET

Network Research Center, Tsinghua University Beijing, 100084 China junbi@cernet.edu.cn

Cisco Systems

Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410 France ribiere@cisco.com

Internet Area SAVI Draft This document describes how SAVI concepts can be extended to provide Source Prefix Validation in enterprise and SP scenarios

There are currently several documents 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: 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. 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": Snoop prefixes in Router Advertisements Snoop prefixes in DHCP prefix delegation 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 can be used as an alternative to Source Prefix Validation but not in all scenarios. RPF operates on a router or a switch with routing capabilities whereas Source Prefix validation can be done on a plain layer2 switch. 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. We foresee two deployment scenarios where Source Prefix Validation is useful: Service Provider scenarios where prefixes are assigned through DHCP-PD 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.

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 .

This scenario was described originally in . Prefixes are "allocated" to CPEs, typically using DHCP prefix delegation (as described in ) , 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 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.

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 |---/ +---+ +-------+

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.

Customer Network Service Provider Network +---+ +-------+ | H |------| CPE-1 |--- +---+ +-------+ \ \ +---+ +-------+ \+----------+ +---------+ +---------+ | H |------| CPE-2 |------| Access |-----| SAVI |----| DHCP | +---+ +-------+ | Switch | | Switch | | Server | /+----------+ +---------+ +---------+ +---+ +-------+ / | H |------| CPE-3 |---/ +---+ +-------+

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 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.

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.

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 | | +--------+--------+--------+-------+----------+--------+

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.

+---------+--------+--------+ |Anchor |Prefix | Length | +---------+--------+--------+ |A |IP_1 | 56 | +---------+--------+--------+ |A |IP_2 | 56 | +---------+--------+--------+

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.

This section specifies the anchor attributes involved in this mechanism.

The SAVI-Validation attribute should be set if and only if source prefix validation must be performed on traffic from this anchor.

The SAVI-DHCP Trust attribute must be set if and only if an anchor is associated with a trustable DHCP server relay.

and 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.

The preferred mechanism is a proactive DHCPv6 Bulk Leasequery as described in . 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 . 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.

Upon reboot the SAVI device COULD proactively generate a RS message on interfaces facing a router.

Thanks to Eric Levy-Abegnoli for his valuable contributions.