Internet DRAFT - draft-ribiere-savi-prefix-guard
draft-ribiere-savi-prefix-guard
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]
