One document matched: draft-baker-savi-one-implementation-approach-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-savi-one-implementation-approach-00"
ipr="trust200902">
<front>
<title abbrev="One way to do it">An implementation approach to Source
Address Validation</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2010" />
<area>Internet Engineering Task Force</area>
<workgroup>SAVI</workgroup>
<abstract>
<t>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.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<note title="Requirements">
<t>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 <xref
target="RFC2119"></xref>.</t>
</note>
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>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: <list
style="empty">
<t>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.</t>
<t>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.</t>
</list></t>
<section title="The purpose of SAVI">
<t>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.</t>
</section>
<section anchor="model" title="Conceptual SAVI Switch Model">
<t>As shown in <xref target="switch"></xref>, a switch is a system
with Ethernet ports and uses <xref target="IEEE.802-1D.1993"></xref>
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.</t>
<t>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.</t>
<t>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.</t>
<figure anchor="switch" title="Ethernet Switch Data Plane">
<artwork align="center"><![CDATA[
+-------------------+
| Switch |
| |
| +------+ |
+----+ +----+ | Port | |
|Host|----|Port|----|Filter| |
+----+ +----+ +------+ |
| | |
+-----+ +----+ +----------+|
|Else-|---|Port|--|Forwarding||
|Where| +----+ | Logic ||
+-----+ | +----------+|
+-------------------+
]]></artwork>
</figure>
<t>The Port Filter is primarily in view in the SAVI model. A SAVI
implementation configures the Port Filter to <list style="numbers">
<t>Identify <xref target="RFC2460">IPv6</xref> datagrams,</t>
<t>Isolate their binding values, which are generally some subset
of their port, MAC Address, and IPv6 Source Address,</t>
<t>Accept IPv6 datagrams matching one of a list of specified
bindings, and</t>
<t>Discard all other IPv6 datagrams.</t>
</list></t>
<t>The discussion in SAVI has primarily related to the binding
relationships among interfaces and addresses that are <list
style="symbols">
<t>Statically configured,</t>
<t>Derived from <xref target="RFC4862"> Stateless Address
Autoconfiguration</xref><xref target="RFC4941"></xref>, or</t>
<t>Assigned via <xref target="RFC3315">DHCPv6</xref>.</t>
</list></t>
</section>
</section>
<section anchor="approach"
title="Solutions for identifying valid bindings">
<t>Several proposals have been put forward as means to identify valid
switch bindings. The major ones depend on either <list style="symbols">
<t>An external reference, such as a <xref
target="RFC3315">DHCPv6</xref> server, assigning valid bindings as
specified in <xref target="I-D.ietf-savi-dhcp"></xref>, or</t>
<t>Individual clients using <xref target="RFC4862"> Stateless
Address Autoconfiguration</xref><xref target="RFC4941"></xref>
correctly, as specified in <xref
target="I-D.bi-savi-stateless"></xref>.</t>
</list></t>
<t>A simpler approach was suggested in <xref
target="I-D.ietf-savi-fcfs"></xref>, 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.</t>
<t>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.</t>
<section anchor="proposal" title="An implementation proposal">
<t>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.</t>
<figure anchor="interface" title="Switch Data and Control Planes">
<artwork align="center"><![CDATA[
+-----------------------------------+
| Switch |
| |
| +------+ +----------+|
+----+ +----+ | Port | | Table ||
|Host|----|Port|----|Filter|--||--|Management||
+----+ +----+ +------+ | Process ||
| | +----------+|
+-----+ +----+ +----------+ |
|Else-|---|Port|--|Forwarding| |
|Where| +----+ | Logic | |
+-----+ | +----------+ |
+-----------------------------------+
]]></artwork>
</figure>
<t>As shown in <xref target="interface"></xref>, 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 <xref target="model"></xref>
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.</t>
</section>
<section anchor="DHCP" title="Implementation in a DHCP configuration">
<t>In a network using <xref target="RFC3315">DHCPv6</xref>, we have
the luxury of an authoritative information source. Correct
implementation depends only on deriving information from it. This
requires two components: <list style="numbers">
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
</section>
<section anchor="send"
title="Implementation using Secure Neighbor Discovery">
<t>In a network using <xref target="RFC3971">SEcure Neighbor
Discovery</xref>, we have the luxury of an authoritative exchange.
Correct implementation depends on deriving information from it. This
requires two components: <list style="numbers">
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
</section>
<section anchor="nd" title="Implementation using Neighbor Discovery">
<t>In a network in which there is no authoritative information source,
correct implementation depends on observing the correct implementation
of <xref target="RFC4861">Neighbor Discovery</xref> and <xref
target="RFC4862">Address Autoconfiguration</xref>.</t>
<t>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: <list style="numbers">
<t>There will be no Neighbor Advertisement in response,</t>
<t>There will be one or more Neighbor Advertisement responses, at
least one of which is from some other client, or</t>
<t>There will be exactly one Neighbor Advertisement response, from
the indicated client.</t>
</list></t>
<t>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 <xref
target="RFC4861"></xref> 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.</t>
<t>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.</t>
</section>
</section>
<section anchor="extreme" title="Extreme Cases">
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="proposal"></xref> 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.</t>
<t>Since non-volatile memory has a cost and is unnecessary, storage of
ephemeral information in non-volatile memory is ill-advised.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Several comments about security have been made in this document, but
it has not been subjected to a thorough security analysis.</t>
<t>As noted in <xref target="approach"></xref>, the data-plane-only
approach suggested in <xref target="I-D.ietf-savi-fcfs"></xref>, 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.</t>
<t>The Neighbor Discovery model discussed in <xref target="nd"></xref>
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.</t>
<t>The approach suggested in <xref target="proposal"></xref> 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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note was requested by the working group chairs. It has been
reviewed by Joel Halpern, to whom <xref target="extreme"></xref>
responds.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.3971" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.IEEE.802-1D.1993"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.bi-savi-stateless" ?>
<?rfc include="reference.I-D.ietf-savi-dhcp" ?>
<?rfc include="reference.I-D.ietf-savi-fcfs" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:35:01 |