| SAVI | J.K. Kaippallimalil |
| Internet-Draft | F.X. Xia |
| Intended status: Standards Track | Huawei USA |
| Expires: December 26, 2012 | J.B. Bi |
| CERNET | |
| V.R. Ribiere, Ed. | |
| Cisco Systems | |
| June 26, 2012 |
Source Prefix Validation
draft-ribiere-savi-prefix-guard-00
This document describes how SAVI concepts can be extended to provide Source Prefix Validation in enterprise and SP scenarios
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 26, 2012.
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 described in the Simplified BSD License.
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:
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":
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.
We foresee two deployment scenarios where Source Prefix Validation is useful:
The purpose of this document is to describe how Source Prefix Validation can be used in those scenarios.
More definitions are described in
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 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.
Customer Network Service Provider Network
+---+ +-------+
| H |------| CPE-1 |---
+---+ +-------+ \
\
+---+ +-------+ \+----------+ +---------+
| H |------| CPE-2 |------| SAVI |-----| DHCP |
+---+ +-------+ | Switch | | Server |
/+----------+ +---------+
+---+ +-------+ /
| H |------| CPE-3 |---/
+---+ +-------+
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 |------| Access |-----| SAVI |----| DHCP |
+---+ +-------+ | Switch | | 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.
Enterprise Network Internet
+------+
| Host |
+------+
\
\
+------+ +--------+ +-------------+
| Host |-----| Switch |--------| Router |----
+------+ /+--------+ +-------------+
/
+------+
| Host |
+------+
In this scenario, the source of the traffic is on-link, as shown in the figure below:
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.
+--------+--------+--------+-------+----------+--------+
| 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 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 |
+---------+--------+--------+
|A |IP_1 | 56 |
+---------+--------+--------+
|A |IP_2 | 56 |
+---------+--------+--------+
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.
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.
[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.
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.
Upon reboot the SAVI device COULD proactively generate a RS message on interfaces facing a router.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
Thanks to Eric Levy-Abegnoli for his valuable contributions.