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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 12, 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 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
    1.1.  The purpose of SAVI
    1.2.  Conceptual SAVI Switch Model
2.  Solutions for identifying valid bindings
    2.1.  An implementation proposal
    2.2.  Implementation in a DHCP configuration
    2.3.  Implementation using Secure Neighbor Discovery
    2.4.  Implementation using Neighbor Discovery
3.  Extreme Cases
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

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 (Ethernet Switch Data Plane), a switch is a system with Ethernet ports and uses [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,” July 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 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   ||
+-----+   |       +----------+|
          +-------------------+

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

1. Identify IPv6 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [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

• Statically configured,
• Derived from Stateless Address Autoconfiguration (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) [RFC4862][RFC4941] (Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” September 2007.), or
• Assigned via DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [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

• An external reference, such as a DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315] server, assigning valid bindings as specified in [I‑D.ietf‑savi‑dhcp] (Bi, J., Wu, J., Yao, G., and F. Baker, “SAVI Solution for DHCP,” April 2010.), or
• Individual clients using Stateless Address Autoconfiguration (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) [RFC4862][RFC4941] (Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” September 2007.) correctly, as specified in [I‑D.bi‑savi‑stateless] (Bi, J., Yao, G., Wu, J., and F. Baker, “SAVI Solution for Stateless Address,” April 2010.).

A simpler approach was suggested in [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,” October 2009.), 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.

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

As shown in Figure 2 (Switch Data and Control Planes), 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 (Conceptual SAVI Switch Model) 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 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [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 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 (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [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 (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) [RFC4861] and Address Autoconfiguration (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) [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 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] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) 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 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 (An implementation proposal) 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 (Solutions for identifying valid bindings), the data-plane-only approach suggested in [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,” October 2009.), 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 (Implementation using Neighbor Discovery) 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 (An implementation proposal) 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 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 (Extreme Cases) responds.

7.  References

7.1. Normative References

7.2. Informative References

Author's Address