Network Working Group Christian Vogt
Internet-Draft Ericsson
Intended status: Informational October 19, 2009
Expires: April 22, 2010
Source Address Validation Improvement Protocol Framework
draft-vogt-savi-framework-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 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
Vogt Expires April 22, 2010 [Page 1]
Internet-Draft SAVI Protocol Framework October 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The Source Address Validation Improvement protocol was developed to
complement ingress filtering with finer-grained IP source address
validation. To enable the deployment of the SAVI protocol in
networks of various kinds, the protocol was designed to be modular
and extensible. This document describes and motivates this design,
explains how protocol components fit into this framework, and
compares the properties of existing protocol components.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 5
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Vogt Expires April 22, 2010 [Page 2]
Internet-Draft SAVI Protocol Framework October 2009
1. Introduction
While ingress filtering [BCP38] provides a way to validate IP source
addresses at an aggregated level, there is not yet a standardized
mechanism for IP source address validation at a finer granularity.
Having a finer granularity would be helpful in a number of
situations, including filtering traffic from customer interfaces
implemented as ports in an IP-aware switch or a router, or general
improvements in filtering accuracy in enterprise networks. Depending
on the situation, there may be a requirement for blocking spoofed
packets or merely logging packets that appear to be spoofed.
Partial solutions exist to prevent hosts from spoofing the IP source
address of another host in the same IP link (e.g., the "IP source
guard"), but are proprietary. The purpose of the IETF working group
on Source Address Validation Improvements, SAVI, is to standardize a
protocol, henceforth called the "SAVI protocol", that prevent hosts
attached to the same IP link from spoofing each other's IP addresses.
These methods are to complement ingress filtering with finer-grained
protection.
To enable the deployment of the SAVI protocol in networks of various
kinds, the protocol was designed to be modular and extensible. This
document describes and motivates this design, explains how protocol
components fit into this framework, and compares the properties of
existing protocol components.
2. Protocol Model
Since the IP source address of a packet generally takes no role in
forwarding and can therefore be selected arbitrarily at the time of
packet transmission without jeopardizing packet delivery, methods for
IP source address validation must augment packet forwarding with an
explicit check on whether a given packet's IP source address is
legitimate. Such check can happen at different granularity: The
classic standard for IP source address validation, ingress filtering
[BCP38], functions at the granularity of networks. It achieves this
by verifying that the prefix of an IP source address routes to the
network from which the packet was received. An advantage of ingress
filtering is simplicity, because the decision of whether to accept or
to reject an IP source address can be made solely based on the
information available from routing protocols. A disadvantage of
ingress filtering is that it is insufficient for finer-grained IP
source address validation, due to the aggregated nature of the
information available from routing protocols. The SAVI protocol was
designed to overcome this disadvantage, by providing IP source
address validation at the granularity of individual IP addresses.
Vogt Expires April 22, 2010 [Page 3]
Internet-Draft SAVI Protocol Framework October 2009
This happens in three steps:
1. Identifying which IP source addresses are legitimate for a host,
based on monitoring packets exchanged by the host.
2. Binding a legitimate IP address to a physical-layer or link-layer
property of the host's network attachment. This property, called
a "binding anchor", must be verifiable in every packet that the
host sends, and harder to spoof than the host's IP source address
itself.
3. Enforcing that the IP source addresses in packets match the
binding anchors to which they were bound.
The functioning of the SAVI protocol allows for multiple forms of
deployment, since a SAVI protocol instance may be located anywhere on
the IP link to which the hosts attach. One way to locate a SAVI
protocol instance is in the hosts' default router. Thus, IP source
addresses are validated in packets traversing the default router, yet
the IP source addresses in packets exchanged locally on the IP link
may bypass validation. Another way to locate a SAVI protocol
instance is in a switch between the hosts and their default router.
Thus, packets may undergo IP source address validation even if
exchanged locally on the link.
The closer a SAVI protocol instance is located to the hosts, the more
effective the SAVI protocol is. This is because each of the three
steps in which the SAVI protocol validates IP source addresses can
best be accomplished in a position close to the host:
1. Identifying a host's legitimate IP source addresses is most
efficient close to the host, because the likelihood that the
host's packets bypass a SAVI protocol instance, and hence cannot
be monitored, increases with the distance between the protocol
instance and the host.
2. Selecting a binding anchor for a host's IP source address is
easiest close to the host, because the properties of an IP link's
physical layer and link layer are unique for a given host only on
the link segment directly attaching to the host.
3. Enforcing a host's use of an legitimate IP source address is most
reliable when pursued close to the host, because the likelihood
that the host's packets bypass a SAVI protocol instance, and
hence do not undergo IP source address validation, increases with
the distance between the protocol instance and the host.
The preferred location of SAVI protocol instances is therefore close
Vogt Expires April 22, 2010 [Page 4]
Internet-Draft SAVI Protocol Framework October 2009
to hosts, such as in switches that directly attach to the hosts whose
IP source addresses are being validated.
3. Deployment Options
The functioning of the SAVI protocol, as summarized by the three
steps listed in Section 2, is deployment-specific in two ways:
1. The identification of legitimate IP source addresses is dependent
on the IP address assignment method in use on a link, since it is
through assignment that a host becomes the legitimate user of an
IP source address.
2. Binding anchors are dependent on the technology used to build the
link on which they are used, as binding anchors are link layer
properties of a host's network attachment.
To facilitate the deployment of the SAVI protocol in networks of
various types, the SAVI protocol is designed in a modular and
extensible manner, so as to support different IP address
configuration methods and to function with various binding anchors.
Naturally, both the permitted IP address assignment methods and the
selection of a type of binding anchor have an impact on the strength
of IP source address validation. This impact is explained in the
first sub-section below. The impact on strength further motivates a
priority to resolve situations where a single IP source address is
attempted to be bound to different binding anchors through different
IP address assignment methods. This prioritization is explained in
the second sub-section below.
3.1. IP Address Assignment Methods
Enumeration and prioritization of IP address assignment methods to be
added.
3.2. Binding Anchors
Enumeration of binding anchors to be added, along with a discussion
of the security properties of those.
4. Scalability Optimizations
The preference to locate SAVI protocol instances close to hosts
implies that multiple SAVI protocol instances must be able to co-
exist in order to support large IP links. Although the SAVI protocol
functions independently of the number of protocol instances per IP
Vogt Expires April 22, 2010 [Page 5]
Internet-Draft SAVI Protocol Framework October 2009
link, co-existence of multiple protocol instances without further
measures can lead to high memory requirements: Since each SAVI
protocol instance creates bindings for the IP source addresses of all
hosts on the IP link, bindings are replicated across multiple
protocol instances. High memory requirements, in turn, increase the
cost of a SAVI protocol instance. This is problematic in particular
for SAVI protocol instances that run on a switch, since it may
significantly increase the cost of such a switch.
To reduce the memory requirements for SAVI protocol instances on IP
links with multiple protocol instances, the SAVI protocol enables the
storage of bindings without replication. This requires manual
disabling of IP source address validation on switch ports that
connect to other switches running a SAVI protocol instance. Each
SAVI protocol instance is then responsible for validating IP source
addresses only on those ports to which hosts either attach directly,
or through other switches without a SAVI protocol instance. On ports
towards other switches running a SAVI protocol instance, IP source
addresses are not validated. The switches running SAVI protocol
instances thus form a "protection perimeter". The IP source
addresses in packets passing the protection perimeter are validated
by the ingress SAVI protocol instance, but no further validation
takes place as long as the packets remain within, or leave the
protection perimeter.
Figure Figure 1 illustrates the concept of the protection perimeter.
The figure shows an IP link with six switches, of which four, denoted
"SAVI switch", run a SAVI protocol instance. The protection
perimeter created by the four SAVI protocol instances is shown as a
dotted line in the figure. IP source address validation is enabled
on all switch ports on the protection perimeter, and it is disabled
on all other switch ports. Four hosts, denoted A through D in the
figure, attach to the protection perimeter.
In the example of figure Figure 1, the protection perimeter includes
one of the legacy switches, located in the middle of the depicted IP
link topology. This is useful because it enables a single,
unpartitioned protection perimeter. A single protection perimeter
minimizes memory requirements for the SAVI protocol instances,
because every binding is kept only once, namely, by the SAVI protocol
instance that attaches to the host being validated. Excluding the
legacy switch from the protection perimeter would result in two
smaller protection perimeters to the left and to the right of the
depicted IP link topology. The memory requirements for the SAVI
protocol instances would then be higher: Since IP source address
validation would be activated on the two ports connecting to the
legacy switch, the SAVI protocol instances adjacent to the legacy
switch would replicate all bindings from the respective other
Vogt Expires April 22, 2010 [Page 6]
Internet-Draft SAVI Protocol Framework October 2009
protection perimeter. The reason why it is possible to include the
legacy switch in the protection perimeter is because the depicted IP
link topology guarantees that packets cannot enter the protection
perimeter via this legacy switch. Without this guarantee, the legacy
switch would have to be excluded from the protection perimeter in
order to ensure that packets entering the protection perimeter
undergo IP source address validation.
..............
protection perimeter --> : +--------+ :
+---+ +---+ : | SAVI | :
| A | | B | <-- hosts : | switch | :
+---+ +---+ : +--------+ :
...|......|.............................: | :
: +--------+ +--------+ +--------+ :
: | SAVI |----------| legacy | | SAVI | :
: | switch | | switch |----------| switch | :
: +--------+ +--------+ +--------+ :
: | ...............................|........:
: +--------+ : +--------+
: | SAVI | : | legacy |
: | switch | : | switch |
: +--------+ : +--------+
:............: | |
+---+ +---+
hosts --> | C | | D |
+---+ +---+
Figure 1: Protection perimeter concept
5. Acknowledgment
The author would like to thank the SAVI working group for a thorough
technical discussion on the design and the framework of the SAVI
protocol, as captured in this document.
This document was generated using the xml2rfc tool.
6. References
[BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", RFC 2827, BCP 38, May 2000.
Vogt Expires April 22, 2010 [Page 7]
Internet-Draft SAVI Protocol Framework October 2009
Author's Address
Christian Vogt
Ericsson
200 Holger Way
San Jose, CA 95134
United States
Email: christian.vogt@ericsson.com
Vogt Expires April 22, 2010 [Page 8]