One document matched: draft-baker-savi-one-implementation-approach-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 13:46:43 |