[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

SAVI                                                            F. Baker
Internet-Draft                                             Cisco Systems
Intended status: Informational                              May 10, 2010
Expires: November 11, 2010


        An implementation approach to Source Address Validation
            draft-baker-savi-one-implementation-approach-00

Abstract

   This note is intended to flesh out a comment made on a mailing list.
   It describes one of many possible implementation approaches to SAVI
   systems, and is intended as much as anything to be an existence proof
   that there is at least one that would work.

Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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 November 11, 2010.

Copyright Notice

   Copyright (c) 2010 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



Baker                   Expires November 11, 2010               [Page 1]


Internet-Draft              One way to do it                    May 2010


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  The purpose of SAVI  . . . . . . . . . . . . . . . . . . .  3
     1.2.  Conceptual SAVI Switch Model . . . . . . . . . . . . . . .  3
   2.  Solutions for identifying valid bindings . . . . . . . . . . .  5
     2.1.  An implementation proposal . . . . . . . . . . . . . . . .  6
     2.2.  Implementation in a DHCP configuration . . . . . . . . . .  6
     2.3.  Implementation using Secure Neighbor Discovery . . . . . .  7
     2.4.  Implementation using Neighbor Discovery  . . . . . . . . .  7
   3.  Extreme Cases  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11


























Baker                   Expires November 11, 2010               [Page 2]


Internet-Draft              One way to do it                    May 2010


1.  Introduction

   This note is intended to flesh out a comment made on a mailing list.
   It describes one of many possible implementation approaches to SAVI
   systems, and is intended as much as anything to be an existence proof
   that there is at least one that would work.  The comment was:

      Let me give you one potential implementation.  Consider a switch
      that for whatever reason is discarding datagrams from a given port
      because they use an IPv6 source address that is not in its tables.
      For various reasons, it very likely has a counter, on the switch
      or VLAN if not on the port itself.  It could also maintain a
      register or FIFO to capture the source IPv6 and MAC addresses this
      happened on.  Without putting the logic for generating the request
      into the data path, it becomes quite possible for a control plane
      process to monitor that register and initiate DHCP queries to
      verify the address and obtain the state from DHCP server.  This
      could be done at a controlled rate per port, to prevent what
      amounts to a DOS multiplier in which a source address "scan"
      results in a DHCP query assault on the server.

      In the event that a switch restarts, that logic obviously happens
      across the board.  It can result in a burst comparable in size to
      the number of ports on the switch in a short interval, but that is
      not a continuing behavior.

1.1.  The purpose of SAVI

   Any discussion of an algorithm must start from a statement of what
   problem it intends to solve.  The purpose of this algorithm is to
   ensure that, within the subnet in which it is implemented, any IPv6
   source address used by a given Ethernet client is valid.  It is valid
   if it has been allocated in accordance with the algorithms in use for
   the class of address on the subnet, and as a result is in use by
   exactly one system.  Ideally, the system also responds to it.

1.2.  Conceptual SAVI Switch Model

   As shown in Figure 1, a switch is a system with Ethernet ports and
   uses [IEEE.802-1D.1993] Ethernet switching among those ports.  Those
   ports may support individual Ethernet clients (which may themselves
   be hosts or IP routers, which require different handling by the
   switch, as routers originate Ethernet datagrams with many IPv6 source
   addresses while hosts use only their own), or may be trunks between
   switches; in the latter case, a protocol such as IEEE Spanning Tree
   is run to prevent bad things from happening.  "Trunks between
   switches" differ in scale.  It is common to have a small (four or
   eight) port switch on a desktop to facilitate wiring.  A virtual host



Baker                   Expires November 11, 2010               [Page 3]


Internet-Draft              One way to do it                    May 2010


   may appear to be a small virtual switch with some number virtual
   clients attached to it.  Large switches are often deployed in tandem
   to manage failure rates, and may connect hundreds to thousands of
   clients.  The connection between two switches is always a trunk.  In
   smaller cases it is rational to have the larger switch bind
   associations to the combination of a port and a MAC address, while in
   larger switches must depend on each other for source address
   validation services for scalability.

   There are two general kinds of filters in a typical switch: the "Port
   Filter" and the "Forwarding Logic".  A Port Filter applies policy to
   the datagrams received on a port, usually to discard or only permit
   selected datagrams.  The Forwarding Logic identifies the set of ports
   to which an Ethernet Frame from a given port will be forwarded.  In
   the forwarding logic, the specified set of ports may be null, a
   single port, a larger set of ports, or all of them except the port
   the datagram was received on.  Background processes in a switch may
   be attached to a virtual port, so that traffic to or from the CPU is
   not a special case in its algorithms.

   Any given implementation will of course vary in its internal
   structure and characteristics.  The port filter might literally use a
   separate memory system per port, or might be the same database used
   for forwarding applied in a different way, or might use some other
   solution.  The intention here is not to attempt to specify the
   implementation, but to identify a conceptual framework in which
   varying implementations can be described.

                                +-------------------+
                                |     Switch        |
                                |                   |
                                |         +------+  |
                      +----+    +----+    | Port |  |
                      |Host|----|Port|----|Filter|  |
                      +----+    +----+    +------+  |
                                |            |      |
                      +-----+   +----+  +----------+|
                      |Else-|---|Port|--|Forwarding||
                      |Where|   +----+  |  Logic   ||
                      +-----+   |       +----------+|
                                +-------------------+

                   Figure 1: Ethernet Switch Data Plane

   The Port Filter is primarily in view in the SAVI model.  A SAVI
   implementation configures the Port Filter to





Baker                   Expires November 11, 2010               [Page 4]


Internet-Draft              One way to do it                    May 2010


   1.  Identify IPv6 [RFC2460] datagrams,

   2.  Isolate their binding values, which are generally some subset of
       their port, MAC Address, and IPv6 Source Address,

   3.  Accept IPv6 datagrams matching one of a list of specified
       bindings, and

   4.  Discard all other IPv6 datagrams.

   The discussion in SAVI has primarily related to the binding
   relationships among interfaces and addresses that are

   o  Statically configured,

   o  Derived from Stateless Address Autoconfiguration
      [RFC4862][RFC4941], or

   o  Assigned via DHCPv6 [RFC3315].


2.  Solutions for identifying valid bindings

   Several proposals have been put forward as means to identify valid
   switch bindings.  The major ones depend on either

   o  An external reference, such as a DHCPv6 [RFC3315] server,
      assigning valid bindings as specified in [I-D.ietf-savi-dhcp], or

   o  Individual clients using Stateless Address Autoconfiguration
      [RFC4862][RFC4941] correctly, as specified in
      [I-D.bi-savi-stateless].

   A simpler approach was suggested in [I-D.ietf-savi-fcfs], in which
   the first user of an address is deemed to be its "owner" for the
   foreseeable future.  This suffers two security defects: the use of an
   address does not imply that the address has been allocated by any
   given algorithm (it may indeed have been statically assigned or be
   generated at a high rate during an attack), and does not imply that
   there are no others that validly lay claim to it.

   We in short come down to the relative merits of using either the
   control plane to detect and make inferences from control plane (DHCP
   or SLAAC DAD) behavior and behavior in the data plane that simply
   learns addresses as their are used, comparable to their learning and
   use in IEEE 802.1D.





Baker                   Expires November 11, 2010               [Page 5]


Internet-Draft              One way to do it                    May 2010


2.1.  An implementation proposal

   It is reasonable to expect that the forwarding logic, which is often
   implemented in hardware or microcode, does not attempt to manage its
   tables in real time.  Instead, it has some defined interface -
   perhaps a register or queue - to a control plane process.  In normal
   operation, the forwarding and filtering tables require no
   modification; the port filter and forwarding logic refer to them, and
   the datagram is handled accordingly.  However, in exception cases,
   the datagram or relevant information from it is queued to the control
   plane for further analysis.

                        +-----------------------------------+
                        |     Switch                        |
                        |                                   |
                        |         +------+      +----------+|
              +----+    +----+    | Port |      |  Table   ||
              |Host|----|Port|----|Filter|--||--|Management||
              +----+    +----+    +------+      |  Process ||
                        |            |          +----------+|
              +-----+   +----+  +----------+                |
              |Else-|---|Port|--|Forwarding|                |
              |Where|   +----+  |  Logic   |                |
              +-----+   |       +----------+                |
                        +-----------------------------------+

                 Figure 2: Switch Data and Control Planes

   As shown in Figure 2, I suggest that this might be extended to
   include information about failures of SAVI-relevant port filter
   entries.  If the SAVI Port Filter terms all fail to match (e.g., the
   logic in Section 1.2 determines that case 4 applies), the datagram is
   discarded, but a request is queued to the Table Management Process to
   determine whether a new SAVI term needs to be added to the relevant
   Port Filter.  The process executes an appropriate procedure, and in
   the event of an affirmative outcome updates the Port Filter to accept
   the new binding.  When the client retransmits the datagram, it passes
   through.

2.2.  Implementation in a DHCP configuration

   In a network using DHCPv6 [RFC3315], we have the luxury of an
   authoritative information source.  Correct implementation depends
   only on deriving information from it.  This requires two components:

   1.  The forwarding logic MUST be configured to identify DHCP
       datagrams and send copies to the Table Management Process.  If
       the switch observes a datagram from the DHCP server authorizing a



Baker                   Expires November 11, 2010               [Page 6]


Internet-Draft              One way to do it                    May 2010


       binding between a port, a MAC Address, and an IPv6 Source
       Address, the binding is stored in the Port Filter for the
       relevant port.

   2.  When a client is observed using an IPv6 source address that fails
       the binding test, the Table Management Process MAY construct a
       DHCPv6 Request that appears to be from the client enquiring about
       the address.  The DHCP server will likely respond to the
       datagram; if it responds in the affirmative, the action in bullet
       1 will record the authorization.

   The switch MAY also apply a policy to detect and mitigate attacks,
   such as rate limiting the number of new source addresses used on a
   port per unit time.

2.3.  Implementation using Secure Neighbor Discovery

   In a network using SEcure Neighbor Discovery [RFC3971], we have the
   luxury of an authoritative exchange.  Correct implementation depends
   on deriving information from it.  This requires two components:

   1.  The forwarding logic MUST be configured to identify SeND messages
       and send copies to the Table Management Process.  If the switch
       observes a SeND Response demonstrating the necessary credentials
       to authorize a binding between a port, a MAC Address, and an IPv6
       Source Address, the binding is stored in the Port Filter for the
       relevant port.

   2.  When a client is observed using an IPv6 source address that fails
       the binding test, the Table Management Process MAY construct a
       Secure Neighbor Solicitation for the address.  The relevant
       client will likely respond to the datagram; the action in bullet
       1 will record the authorization.

   The switch MAY also apply a policy to detect and mitigate attacks,
   such as rate limiting the number of new source addresses used on a
   port per unit time.

2.4.  Implementation using Neighbor Discovery

   In a network in which there is no authoritative information source,
   correct implementation depends on observing the correct
   implementation of Neighbor Discovery [RFC4861] and Address
   Autoconfiguration [RFC4862].

   When a client is observed using an IPv6 source address that fails the
   binding test, the Table Management Process SHOULD initiate a
   multicast Neighbor Solicitation to find the client using its source



Baker                   Expires November 11, 2010               [Page 7]


Internet-Draft              One way to do it                    May 2010


   address.  One of three things will happen:

   1.  There will be no Neighbor Advertisement in response,

   2.  There will be one or more Neighbor Advertisement responses, at
       least one of which is from some other client, or

   3.  There will be exactly one Neighbor Advertisement response, from
       the indicated client.

   The first case is characteristic of some attack scenarios (the source
   is simply generating addresses and using them), and of the Duplicate
   Address Detection phase of Address Autoconfiguration.  It is an
   address that should not be seen at this point as a source address.
   The second case is also characteristic of some attack scenarios; a
   program is directly spoofing the address of another system.  In these
   cases, the Table Manager MUST NOT configure the binding into the Port
   Filter authorizing the use by this client.  The third case, on the
   other hand, is exactly what any client correctly implementing
   [RFC4861] would expect to see in Neighbor Discovery.  The switch
   stores the binding indicated by the response - which may be from the
   indicated client or a different one.

   The switch MAY also apply a policy that would detect and mitigate
   other attacks, such as rate limiting the number of new source
   addresses validated on a port per unit time.


3.  Extreme Cases

   Discussion on the list has suggested a variety of solutions to
   extreme cases, notably saving tables in nonvolatile memory to handle
   extreme failures.  In my opinion, this is ill-advised and
   unnecessary.

   DHCP-assigned addresses, which have a lifetime, and SLAAC-assigned
   addresses (especially private ones, but also addresses derived from
   the MAC Address), which are flushed when an interface is
   disconnected, are examples of ephemeral information in a network.
   The storage of ephemeral information in permanent storage, such as
   nonvolatile memory, has the effect of making a switch that has
   rebooted attempt to enforce rules that may no longer apply; if they
   do still apply, their validity derives from the assent of the
   authority.  Verification with the authority is therefore always
   sufficient to validate an address.

   Such actions are also unnecessary.  In the event of the reboot of a
   switch in a large Ethernet, all of its clients will follow SLAAC



Baker                   Expires November 11, 2010               [Page 8]


Internet-Draft              One way to do it                    May 2010


   procedures or issue DHCP requests to obtain their addresses, or the
   port failure will be masked from them by desktop switches and they
   will continue using preexisting addresses.  For a short interval,
   both client address management and switch address validation as
   described in Section 2.1 can result in a high rate of control plane
   traffic.  However, it is limited in two ways: it is only carried out
   on behalf of the clients of the switch, which are a finite number,
   and each such transaction requires at most a limited interval.  When
   the reboot has completed and the initial burst passed, matters will
   return to their normal state.

   Since non-volatile memory has a cost and is unnecessary, storage of
   ephemeral information in non-volatile memory is ill-advised.


4.  IANA Considerations

   This memo asks the IANA for no new parameters.

   Note to RFC Editor: This section will have served its purpose if it
   correctly tells IANA that no new assignments or registries are
   required, or if those assignments or registries are created during
   the RFC publication process.  From the author"s perspective, it may
   therefore be removed upon publication as an RFC at the RFC Editor"s
   discretion.


5.  Security Considerations

   Several comments about security have been made in this document, but
   it has not been subjected to a thorough security analysis.

   As noted in Section 2, the data-plane-only approach suggested in
   [I-D.ietf-savi-fcfs], in which the first user of an address is deemed
   to be its "owner" for the foreseeable future, suffers two security
   defects: the use of an address does not imply that the address has
   been allocated in accordance with SLAAC, and does not imply that
   there are no others that validly lay claim to it.

   The Neighbor Discovery model discussed in Section 2.4 is not secure.
   That is why SeND exists.  However, it can detect cases in which an
   address has no active users or multiple users, which serves the
   present purpose.

   The approach suggested in Section 2.1 is based on the supposition
   that the client has followed whatever rules apply in the network for
   allocating addresses.  The fact cannot, however, be proven; the only
   thing that can be proven is that the result is consistent with it



Baker                   Expires November 11, 2010               [Page 9]


Internet-Draft              One way to do it                    May 2010


   having done so.


6.  Acknowledgements

   This note was requested by the working group chairs.  It has been
   reviewed by Joel Halpern, to whom Section 3 responds.


7.  References

7.1.  Normative References

   [IEEE.802-1D.1993]
              Institute of Electrical and Electronics Engineers,
              "Information technology - Telecommunications and
              information exchange between systems - Local area networks
              - Media access control (MAC) bridges", IEEE Standard
              802.1D, July 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, 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.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

7.2.  Informative References

   [I-D.bi-savi-stateless]
              Bi, J., Yao, G., Wu, J., and F. Baker, "SAVI Solution for



Baker                   Expires November 11, 2010              [Page 10]


Internet-Draft              One way to do it                    May 2010


              Stateless Address", draft-bi-savi-stateless-00 (work in
              progress), April 2010.

   [I-D.ietf-savi-dhcp]
              Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
              DHCP", draft-ietf-savi-dhcp-02 (work in progress),
              April 2010.

   [I-D.ietf-savi-fcfs]
              Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS-
              SAVI: First-Come First-Serve Source-Address Validation for
              Locally Assigned Addresses", draft-ietf-savi-fcfs-02 (work
              in progress), October 2009.


Author's Address

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com




























Baker                   Expires November 11, 2010              [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/