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]