draft-ietf-savi-framework-05.txt   rfc7039.txt 
Network Working Group J. Wu Internet Engineering Task Force (IETF) J. Wu
Internet-Draft J. Bi Request for Comments: 7039 J. Bi
Intended status: Informational Tsinghua Univ. Category: Informational Tsinghua Univ.
Expires: January 26, 2012 M. Bagnulo ISSN: 2070-1721 M. Bagnulo
UC3M UC3M
F. Baker F. Baker
Cisco Cisco
C. Vogt, Ed. C. Vogt, Ed.
Ericsson October 2013
July 25, 2011
Source Address Validation Improvement Framework Source Address Validation Improvement (SAVI) Framework
draft-ietf-savi-framework-05
Abstract Abstract
The Source Address Validation Improvement method was developed to Source Address Validation Improvement (SAVI) methods were developed
complement ingress filtering with finer-grained, standardized IP to prevent nodes attached to the same IP link from spoofing each
source address validation. This document describes and motivates the other's IP addresses, so as to complement ingress filtering with
design of the SAVI method. finer-grained, standardized IP source address validation. This
document is a framework document that describes and motivates the
Status of this Memo design of the SAVI methods. Particular SAVI methods are described in
other documents.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 26, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7039.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . 5
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8 3.1. IP Address Assignment Methods . . . . . . . . . . . . . . 6
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10 3.2. Binding Anchors . . . . . . . . . . . . . . . . . . . . . 6
6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 7
7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . . 11 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 9
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11.1. Informative References . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Since IP source addresses are used by hosts and network entities to Since IP source addresses are used by hosts and network entities to
determine the origin of a packet and as a destination for return determine the origin of a packet and as a destination for return
data, spoofing of IP source addresses can enable impersonation, data, spoofing of IP source addresses can enable impersonation,
concealment, and malicious traffic redirection. Unfortunately, the concealment, and malicious traffic redirection. Unfortunately, the
Internet architecture does not prevent IP source address spoofing Internet architecture does not prevent IP source address spoofing
[draft-ietf-savi-threat-scope]. Since the IP source address of a [RFC6959]. Since the IP source address of a packet generally takes
packet generally takes no role in forwarding the packet, it can be no role in forwarding the packet, it can be selected arbitrarily by
selected arbitrarily by the sending host without jeopardizing packet the sending host without jeopardizing packet delivery. Extra methods
delivery. Extra methods are necessary for IP source address are necessary for IP source address validation to augment packet
validation, to augment packet forwarding with an explicit check of forwarding with an explicit check of whether a given packet's IP
whether a given packet's IP source address is legitimate. source address is legitimate.
IP source address validation can happen at different granularity: IP source address validation can happen at different granularity.
Ingress filtering [BCP38], a widely deployed standard for IP source Ingress filtering [BCP38] [BCP84], a widely deployed standard for IP
address validation, functions at the coarse granularity of networks. source address validation, functions at the coarse granularity of
It verifies that the prefix of an IP source address routes to the networks. It verifies that the prefix of an IP source address routes
network from which the packet was received. An advantage of ingress to the network from which the packet was received. An advantage of
filtering is simplicity: the decision of whether to accept or to ingress filtering is simplicity: the decision of whether to accept or
reject an IP source address can be made solely based on the to reject an IP source address can be made solely based on the
information available from routing protocols. However, the information available from routing protocols. However, the
simplicity comes at the cost of not being able to validate IP source simplicity comes at the cost of not being able to validate IP source
addresses at a finer granularity, due to the aggregated nature of the addresses at a finer granularity, due to the aggregated nature of the
information available from routing protocols. Finer-grained IP information available from routing protocols. Finer-grained IP
source address validation would ensure that source address source address validation would ensure that source address
information is accurate, reduce the ability to launch denial-of- information is accurate, reduce the ability to launch denial-of-
service attacks, and help with localizing hosts and identify service attacks, and help with localizing hosts and identifying
misbehaving hosts. Partial solutions [BA2007] exist for finer- misbehaving hosts. Partial solutions [BA2007] exist for finer-
grained IP source address validation, but are proprietary and hence grained IP source address validation but are proprietary and hence
often unsuitable for corporate procurement. often unsuitable for corporate procurement.
The Source Address Validation Improvement method was developed to The Source Address Validation Improvement (SAVI) method was developed
complement ingress filtering with standardized IP source address to complement ingress filtering with standardized IP source address
validation at the maximally fine granularity of individual IP validation at the maximally fine granularity of individual IP
addresses: It prevents hosts attached to the same link from spoofing addresses. It prevents hosts attached to the same link from spoofing
each other's IP addresses. To facilitate deployment in networks of each other's IP addresses. To facilitate deployment in networks of
various kinds, the SAVI method was designed to be modular and various kinds, the SAVI method was designed to be modular and
extensible. This document describes and motivates the design of the extensible. This document describes and motivates the design of the
SAVI method. SAVI method.
Note that SAVI raises a number of important privacy considerations
that are discussed more fully in [RFC6959]. SAVI implementers must
take those privacy considerations into account when designing
solutions that match this framework and follow the recommendations
given in [RFC6959].
2. Model 2. Model
To enable network operators to deploy fine-grained IP source address To enable network operators to deploy fine-grained IP source address
validation without a dependency on supportive functionality on hosts, validation without a dependency on supportive functionality on hosts,
the SAVI method was designed to be purely network-based. A SAVI the SAVI method was designed to be purely network based. A SAVI
instance is located on the path of hosts' packets, enforcing the instance enforces the hosts' use of legitimate IP source addresses
hosts' use of legitimate IP source addresses according to the according to the following three-step model:
following three-step model:
1. Identify which IP source addresses are legitimate for a host, 1. Identify which IP source addresses are legitimate for a host,
based on monitoring packets exchanged by the host. based on monitoring packets exchanged by the host.
2. Bind a legitimate IP address to a link layer property of the 2. Bind a legitimate IP address to a link-layer property of the
host's network attachment. This property, called a "binding host's network attachment. This property, called a "binding
anchor", must be verifiable in every packet that the host sends, anchor", must be verifiable in every packet that the host sends
and harder to spoof than the host's IP source address itself. and harder to spoof than the host's IP source address itself.
3. Enforce that the IP source addresses in packets match the binding 3. Enforce that the IP source addresses in packets match the binding
anchors to which they were bound. anchors to which they were bound.
This model allows SAVI functionality (a SAVI instance) to be located This model allows SAVI functionality (a SAVI instance) to be located
anywhere on the link to which the hosts attach, hence enabling anywhere on the link to which the hosts attach, hence enabling
different locations for a SAVI instance. One way to locate a SAVI different locations for a SAVI instance. One way to locate a SAVI
instance is in the hosts' default router. IP source addresses are instance is in the hosts' default router. IP source addresses are
then validated in packets traversing the default router, yet the IP then validated in packets traversing the default router, yet the IP
source addresses in packets exchanged locally on the link may bypass source addresses in packets exchanged locally on the link may bypass
validation. Another way to locate a SAVI instance is in a switch validation. Another way to locate a SAVI instance is in a switch
between the hosts and their default router. Thus, packets may between the hosts and their default router. Thus, packets may
undergo IP source address validation even if exchanged locally on the undergo IP source address validation even if exchanged locally on the
link. link.
The closer a SAVI instance is located to the hosts, the more The closer a SAVI instance is located to the host, the more effective
effective the SAVI method is. This is because each of the three the SAVI method is. This is because each of the three steps of the
steps of the SAVI model can best be accomplished in a position close SAVI model can best be accomplished in a position close to the host:
to the host:
o Identifying a host's legitimate IP source addresses is most o Identifying a host's legitimate IP source addresses is most
efficient close to the host, because the likelihood that the efficient close to the host because the likelihood that the host's
host's packets bypass a SAVI instance, and hence cannot be packets bypass a SAVI instance, and hence cannot be monitored,
monitored, increases with the distance between the SAVI instance increases with the topological distance between the SAVI instance
and the host. and the host.
o Selecting a binding anchor for a host's IP source address is o Selecting a binding anchor for a host's IP source address is
easiest close to the host, because many link layer properties are easiest close to the host because many link-layer properties are
unique for a given host only on a link segment directly attaching unique for a given host only on a link segment directly attached
to the host. to the host.
o Enforcing a host's use of a legitimate IP source address is most o Enforcing a host's use of a legitimate IP source address is most
reliable when pursued close to the host, because the likelihood reliable when pursued close to the host because the likelihood
that the host's packets bypass a SAVI instance, and hence do not that the host's packets bypass a SAVI instance, and hence do not
undergo IP source address validation, increases with the distance undergo IP source address validation, increases with the
between the SAVI instance and the host. topological distance between the SAVI instance and the host.
The preferred location of SAVI instances is therefore close to hosts, The preferred location of SAVI instances is therefore close to hosts,
such as in switches that directly attach to the hosts whose IP source such as in switches that directly attach to the hosts whose IP source
addresses are being validated. addresses are being validated.
Nevertheless, it is useful for SAVI mechanisms to be able to handle Nevertheless, it is useful for SAVI mechanisms to be able to handle
situations where hosts are not directly attached to the SAVI-capable situations where hosts are not directly attached to the SAVI-capable
device. For instance, deployments with both SAVI-capable and legacy device. For instance, deployments with both SAVI-capable and legacy
switches could be supported. In general, a SAVI solution needs to switches could be supported. In general, a SAVI solution needs to
specify how it deals with a number of deployment scenarios and specify how it deals with a number of deployment scenarios and
skipping to change at page 6, line 23 skipping to change at page 5, line 31
hosts moving between wireless attachment points, network partitions, hosts moving between wireless attachment points, network partitions,
and so on. and so on.
Besides, in the case of legacy switches, the security level is lower, Besides, in the case of legacy switches, the security level is lower,
as there is no full protection for the hosts connected to the legacy as there is no full protection for the hosts connected to the legacy
server. server.
3. Deployment Options 3. Deployment Options
The model of the SAVI method, as explained in Section 2, is The model of the SAVI method, as explained in Section 2, is
deployment-specific in two ways: deployment specific in two ways:
o The identification of legitimate IP source addresses is dependent o The identification of legitimate IP source addresses is dependent
on the IP address assignment method in use on a link, since it is 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 through assignment that a host becomes the legitimate user of an
IP source address. IP source address.
o Binding anchors are dependent on the technology used to build the o Binding anchors are dependent on the technology used to build the
link on which they are used, as binding anchors are link layer link on which they are used, as binding anchors are link-layer
properties of a host's network attachment. properties of a host's network attachment.
To facilitate the deployment of the SAVI method in networks of To facilitate the deployment of the SAVI method in networks of
various kinds, the SAVI method is designed to support different IP various kinds, the SAVI method is designed to support different IP
address assignment methods, and to function with different binding address assignment methods and to function with different binding
anchors. Naturally, both the IP address assignment methods in use on anchors. Naturally, both the IP address assignment methods in use on
a link and the available binding anchors have an impact on the a link and the available binding anchors have an impact on the
functioning and the strength of IP source address validation. The functioning and the strength of IP source address validation. The
following two sub-sections explain this impact, and describe how the following two subsections explain this impact and describe how the
SAVI method accommodates this. SAVI method accommodates this.
3.1. IP Address Assignment Methods 3.1. IP Address Assignment Methods
Since the SAVI method traces IP address assignment packets, it Since the SAVI method traces IP address assignment packets, it
necessarily needs to incorporate logic that is specific to particular necessarily needs to incorporate logic that is specific to particular
IP address assignment methods. However, developing SAVI method IP address assignment methods. However, developing SAVI method
variants for each IP address assignment method is alone not variants for each IP address assignment method is alone not
sufficient, since multiple IP address assignment methods may co-exist sufficient since multiple IP address assignment methods may coexist
on a given link. The SAVI method hence comes in multiple variants: on a given link. The SAVI method hence comes in multiple variants,
e.g., for links with DHCP [RFC2131] [RFC3315], Stateless Address
for links with DHCP [rfc2131][rfc3315], Stateless Address Autoconfiguration (SLAAC) [RFC4862] with or without Secure Neighbor
Autoconfiguration [rfc4862] with or without Secure Neighbor Discovery Discovery (SEND) [RFC3971], Internet Key Exchange Protocol Version 2
[rfc3971], IKEv2[rfc5996] [rfc5739] [rfc5026] and combinations (IKEv2) [RFC5996] [RFC5739] [RFC5026], and combinations thereof.
thereof.
The reason to develop SAVI method variants for each single IP address The reason to develop SAVI method variants for each single IP address
configuration method, in addition to the variant that handles all IP configuration method, in addition to the variant that handles all IP
address assignment methods, is to minimize the complexity of the address assignment methods, is to minimize the complexity of the
common case: many link deployments today either are constrained to a common case. Many link deployments today either are constrained to a
single IP address assignment methods or, equivalently from the single IP address assignment method or, equivalently from the
perspective of the SAVI method, separate IP address assignment perspective of the SAVI method, use different IP address assignment
methods into different IP address prefixes. The SAVI method for such methods within different IP address prefixes. The SAVI method for
links can be simpler than the SAVI method for links with multiple IP such links can be simpler than the SAVI method for links with
address assignment methods per IP address prefix. multiple IP address assignment methods per IP address prefix.
3.2. Binding Anchors 3.2. Binding Anchors
The SAVI method supports a range of binding anchors: The SAVI method supports a range of binding anchors:
o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's
interface. interface.
o The port on an Ethernet switch to which a host attaches. o The port on an Ethernet switch to which a host attaches.
o The security association between a host and the base station on o The security association between a host and the base station on
wireless links. wireless links.
o The combination of a host interface's link-layer address and a o The combination of a host interface's link-layer address and a
customer relationship in cable modem networks. customer relationship in cable modem networks.
o An ATM virtual channel, a PPPoE session identifier, or an L2TP o An ATM virtual channel, a PPP session identifier, or a Layer 2
session identifier in a DSL network. Tunneling Protocol (L2TP) session identifier in a DSL network.
o A tunnel that connects to a single host, such as an IP-in-IP o A tunnel that connects to a single host, such as an IP-in-IP
tunnel, a GRE tunnel, or an MPLS label-switched path. tunnel, a Generic Routing Encapsulation (GRE) tunnel, or an MPLS
label-switched path.
The various binding anchors differ significantly in the security they The various binding anchors differ significantly in the security they
provide. IEEE extended unique identifiers, for example, fail to provide. IEEE extended unique identifiers, for example, fail to
render a secure binding anchor because they can be spoofed with render a secure binding anchor because they can be spoofed with
little effort. And switch ports alone may be insufficient because little effort. Switch ports alone may be insufficient because they
they may connect to more than a single host, such as in the case of may connect to more than a single host, such as in the case of
concatenated switches. concatenated switches.
Given this diversity in the security provided, one could define a set Given this diversity in the security provided, one could define a set
of possible binding anchors, and leave it up to the administrator to of possible binding anchors and leave it up to the administrator to
choose one or more of them. Such a selection of binding anchors choose one or more of them. Such a selection of binding anchors
would, of course, have to be accompanied by an explanation of the would, of course, have to be accompanied by an explanation of the
pros and cons of the different binding anchors. In addition, SAVI pros and cons of the different binding anchors. In addition, SAVI
devices may have a default binding anchor depending on the lower devices may have a default binding anchor depending on the lower
layers. Such a default could be to use switch ports when available, layers. Such a default could be to use switch ports when available
and MAC addresses otherwise. Or to use MAC addresses, and switch and MAC addresses otherwise or to use MAC addresses and switch ports
ports in addition if available. in addition if available.
4. Scalability Optimizations 4. Scalability Optimizations
The preference to locate a SAVI instance close to hosts implies that The preference to locate a SAVI instance close to hosts implies that
multiple SAVI instances must be able to co-exist in order to support multiple SAVI instances must be able to coexist in order to support
large links. Although the model of the SAVI method is independent of large links. Although the model of the SAVI method is independent of
the number of SAVI instances per link, co-existence of multiple SAVI the number of SAVI instances per link, coexistence of multiple SAVI
instances without further measures can lead to higher-than-necessary instances without further measures can lead to higher-than-necessary
memory requirements: since a SAVI instance creates bindings for the memory requirements. Since a SAVI instance creates bindings for the
IP source addresses of all hosts on a link, bindings are replicated IP source addresses of all hosts on a link, bindings are replicated
if multiple SAVI instances co-exist on the link. High memory if multiple SAVI instances coexist on the link. High memory
requirements, in turn, increase the cost of a SAVI instance. This is requirements, in turn, increase the cost of a SAVI instance. This is
problematic in particular for SAVI instances that are located on a problematic in particular for SAVI instances that are located on a
switch, since it may significantly increase the cost of such a switch since it may significantly increase the cost of such a switch.
switch.
To reduce memory requirements for SAVI instances that are located on To reduce memory requirements for SAVI instances that are located on
a switch, the SAVI method enables the suppression of binding a switch, the SAVI method enables the suppression of binding
replication on links with multiple SAVI instances. This requires replication on links with multiple SAVI instances. This requires
manual disabling of IP source address validation on switch ports that manual disabling of IP source address validation on switch ports that
connect to other switches running a SAVI instance. Each SAVI connect to other switches running a SAVI instance. Each SAVI
instance is then responsible for validating IP source addresses only instance is then responsible for validating IP source addresses only
on those ports to which hosts attach either directly, or via switches on those ports to which hosts attach either directly or via switches
without a SAVI instance. On ports towards other switches running a without a SAVI instance. On ports towards other switches running a
SAVI instance, IP source addresses are not validated. The switches SAVI instance, IP source addresses are not validated. The switches
running SAVI instances thus form a "protection perimeter". The IP running SAVI instances thus form a "protection perimeter". The IP
source addresses in packets passing the protection perimeter are source addresses in packets passing the protection perimeter are
validated by the ingress SAVI instance, but no further validation validated by the ingress SAVI instance, but no further validation
takes place as long as the packets remain within, or leave the takes place as long as the packets remain within or leave the
protection perimeter. protection perimeter.
.............. ..............
protection perimeter --> : +--------+ : protection perimeter --> : +--------+ :
+---+ +---+ : | SAVI | : +---+ +---+ : | SAVI | :
| A | | B | <-- hosts : | switch | : | A | | B | <-- hosts : | switch | :
+---+ +---+ : +--------+ : +---+ +---+ : +--------+ :
...|......|.............................: | : ...|......|.............................: | :
: +--------+ +--------+ +--------+ : : +--------+ +--------+ +--------+ :
: | SAVI |----------| legacy | | SAVI | : : | SAVI |----------| legacy | | SAVI | :
skipping to change at page 9, line 25 skipping to change at page 8, line 25
: | ...............................|........: : | ...............................|........:
: +--------+ : +--------+ : +--------+ : +--------+
: | SAVI | : | legacy | : | SAVI | : | legacy |
: | switch | : | switch | : | switch | : | switch |
: +--------+ : +--------+ : +--------+ : +--------+
:............: | | :............: | |
+---+ +---+ +---+ +---+
hosts --> | C | | D | hosts --> | C | | D |
+---+ +---+ +---+ +---+
Figure 1: Protection perimeter concept Figure 1: Protection Perimeter Concept
Figure 1 illustrates the concept of the protection perimeter. The Figure 1 illustrates the concept of the protection perimeter. The
figure shows a link with six switches, of which four, denoted "SAVI figure shows a link with six switches, of which four, denoted "SAVI
switch", run a SAVI instance. The protection perimeter created by switch", run a SAVI instance. The protection perimeter created by
the four SAVI instances is shown as a dotted line in the figure. IP the four SAVI instances is shown as a dotted line in the figure. IP
source address validation is enabled on all switch ports on the source address validation is enabled on all switch ports on the
protection perimeter, and it is disabled on all other switch ports. protection perimeter, and it is disabled on all other switch ports.
Four hosts, denoted A through D in the figure, attach to the Four hosts, denoted A through D in the figure, attach to the
protection perimeter. protection perimeter.
In the example of figure Figure 1, the protection perimeter In the example in Figure 1, the protection perimeter encompasses one
encompasses one of the legacy switches, located in the middle of the of the legacy switches, located in the middle of the depicted link
depicted link topology. This enables a single, unpartitioned topology. This enables a single, unpartitioned protection perimeter.
protection perimeter. A single protection perimeter minimizes memory A single protection perimeter minimizes memory requirements for the
requirements for the SAVI instances because every binding is kept SAVI instances because every binding is kept only once, namely, by
only once, namely, by the SAVI instance that attaches to the host the SAVI instance that attaches to the host being validated.
being validated. Excluding the legacy switch from the protection Excluding the legacy switch from the protection perimeter would
perimeter would result in two smaller protection perimeters to the result in two smaller protection perimeters to the left and to the
left and to the right of the depicted link topology. The memory right of the depicted link topology. The memory requirements for the
requirements for the SAVI instances would then be higher: since IP SAVI instances would then be higher: since IP source address
source address validation would be activated on the two ports validation would be activated on the two ports connecting to the
connecting to the legacy switch, the SAVI instances adjacent to the legacy switch, the SAVI instances adjacent to the legacy switch would
legacy switch would replicate all bindings from the respectively replicate all bindings from the other protection perimeter,
other protection perimeter. The reason why it is possible to include respectively. The reason why it is possible to include the legacy
the legacy switch in the protection perimeter is because the depicted switch in the protection perimeter is because the depicted link
link topology guarantees that packets cannot enter the protection topology guarantees that packets cannot enter the protection
perimeter via this legacy switch. Without this guarantee, the legacy perimeter via this legacy switch. Without this guarantee, the legacy
switch would have to be excluded from the protection perimeter in switch would have to be excluded from the protection perimeter in
order to ensure that packets entering the protection perimeter order to ensure that packets entering the protection perimeter
undergo IP source address validation. undergo IP source address validation.
Note that if such configuration is used, care must be taken as any
hosts on subnets attached to non-enforcing ports will be able to use
spoofed source addresses.
5. Reliability Optimizations 5. Reliability Optimizations
The explicit storage of legitimate IP addresses in the form of The explicit storage of legitimate IP addresses in the form of
bindings implies that failure to create a binding, or the premature bindings implies that failure to create a binding, or the premature
removal of bindings, can lead to loss of legitimate packets. There removal of bindings, can lead to loss of legitimate packets. There
are three situations in which this can happen: are three situations in which this can happen:
o Legitimate IP address configuration packets, which should trigger o Legitimate IP address configuration packets, which should trigger
the creation of a binding in a SAVI instance, are lost before the creation of a binding in a SAVI instance, are lost before
reaching the SAVI instance. reaching the SAVI instance.
skipping to change at page 10, line 31 skipping to change at page 9, line 34
o The link topology changes, resulting in hosts to communicate o The link topology changes, resulting in hosts to communicate
through SAVI instances that do not have a binding for those hosts' through SAVI instances that do not have a binding for those hosts'
IP addresses. IP addresses.
To limit the disruption that missing bindings for legitimate IP To limit the disruption that missing bindings for legitimate IP
addresses can have, the SAVI method includes a mechanism for reactive addresses can have, the SAVI method includes a mechanism for reactive
binding creation based on regular packets. This mechanism binding creation based on regular packets. This mechanism
supplements the proactive binding creation based on IP address supplements the proactive binding creation based on IP address
configuration packets. Reactive binding creation occurs when a SAVI configuration packets. Reactive binding creation occurs when a SAVI
instances recognizes excessive drops of regular packets originating instance recognizes excessive drops of regular packets originating
from the same IP address. The SAVI instance then verifies whether from the same IP address. The SAVI instance then verifies whether
said IP address is unique on the link. How the verification is said IP address is unique on the link. How the verification is
carried out depends on the IP address configuration method that the carried out depends on the IP address configuration method that the
SAVI instance supports: the SAVI method variant for Stateless SAVI instance supports. The SAVI method variant for Stateless
Address Autoconfiguration and for Secure Neighbor Discovery verifies Address Autoconfiguration and for Secure Neighbor Discovery verifies
an IP address through the Duplicate Address Detection procedure. The an IP address through the Duplicate Address Detection procedure. The
SAVI method variant for DHCP verifies an IP address through a DHCP SAVI method variant for DHCP verifies an IP address through a DHCP
Lease Query message exchange with the DHCP server. If verification Lease Query message exchange with the DHCP server. If verification
indicates that the IP address is unique on the link, the SAVI indicates that the IP address is unique on the link, the SAVI
instance creates a binding for the IP address. Otherwise, no binding instance creates a binding for the IP address. Otherwise, no binding
is created, and packets sent from the IP address continue to be is created, and packets sent from the IP address continue to be
dropped. dropped. These reliability issues should be addressed in all the
SAVI protocols describing particular SAVI methods.
6. Scenario with Multiple Assignment Methods 6. Scenario with Multiple Assignment Methods
While multiple assignment methods can be used on the same link, the While multiple assignment methods can be used on the same link, the
SAVI device may have to deal with a mix of binding discovery methods. SAVI device may have to deal with a mix of binding discovery methods.
If the address prefix used for each assignment method is different, If the address prefix used for each assignment method is different,
mix scenario can handle the same as scenario with only one assignment the "mix scenario" behaves the same as with the scenario with only
method. If different address assignment methods are used to assign one assignment method. If different address assignment methods are
addresses from the same prefix, additional considerations are needed used to assign addresses from the same prefix, additional
because one binding mechanism may create a binding violating an considerations are needed because one binding mechanism may create a
existing binding from another binding mechanism, e.g., binding from binding violating an existing binding from another binding mechanism,
SAVI-FCFS [savi-fcfs] may violate binding from SAVI-DHCP [savi-dhcp]. e.g., binding from First-Come, First-Served (FCFS) SAVI [RFC6620] may
Thus, the collision between different SAVI mechanisms in mix scenario violate a binding from SAVI-DHCP [SAVI-DHCP]. Thus, the collision
must be handled in case more than one address assignment method is between different SAVI mechanisms in the mix scenario must be handled
used to assign addresses from the same prefix. in case more than one address assignment method is used to assign
addresses from the same prefix.
Prioritization relationship between different address assignment The prioritization of relationships between different address
methods is used as the basis to solve possible collisions. Current assignment methods is used as the basis to solve possible collisions.
standard documents of address assignment methods have implied the Current standard documents of address assignment methods (DHCP
prioritization relationship in general cases. However, considering [RFC2131], DHCPv6 [RFC3315], SLAAC [RFC4862], and SEND [RFC3971])
in some scenarios, default prioritization level may not be quite have implied the prioritization relationship in general cases.
suitable. Configurable prioritization level should be supported in a However, in some scenarios, the default prioritization level may not
document of SAVI solution for the mix scenario. be quite suitable. A configurable prioritization level should be
supported in the SAVI solution for the mix scenario [SAVI-MIX].
7. Prefix Configuration 7. Prefix Configuration
Before setting up a host-level granularity binding, it is important Before setting up a host-level granularity binding, it is important
to configure correct prefixes on the SAVI device. This document to configure correct prefixes on the SAVI device. This document
suggests set 3 prefix configuration mechanisms at SAVI device: suggests a set of 3 prefix configuration mechanisms at a SAVI device:
o Manual Prefix Configuration: The allowed prefix scope of IPv4 o Manual Prefix Configuration: The allowed prefix scope of IPv4
Addresses, IPv6 static addresses, IPv6 addresses assigned by addresses, IPv6 static addresses, IPv6 addresses assigned by
SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually Stateless Address Autoconfiguration (SLAAC), and IPv6 addresses
at SAVI device. FE80::/64 is always a feasible prefix in IPv6. assigned by DHCPv6 can be set manually at the SAVI device.
FE80::/64 is always a feasible prefix in IPv6.
o Prefix Configuration by RA Snooping: The allowed prefix scope of o Prefix Configuration by Router Advertisement (RA) Snooping: The
IPv6 static addresses and IPv6 addresses assigned by SLAAC can be allowed prefix scope of IPv6 static addresses and IPv6 addresses
set at SAVI device through snooping RA message at SAVI device. assigned by SLAAC can be set at the SAVI device through snooping
an RA message at the SAVI device.
o Prefix Configuration by DHCP-PD Snooping: The allowed prefix o Prefix Configuration by DHCP Prefix Delegation (DHCP-PD) Snooping:
scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, The allowed prefix scope of IPv6 static addresses, IPv6 addresses
and IPv6 addresses assigned by DHCPv6 can be set through snooping assigned by SLAAC, and IPv6 addresses assigned by DHCPv6 can be
DHCP-PD message at SAVI device. set through snooping a DHCP-PD message at the SAVI device.
If some of the prefix scopes is set to have no prefix, it implies If some of the prefix scopes are set to have no prefix, the
corresponding address assignment method is not allowed in the implication is that the corresponding address assignment method is
network. not allowed in the network.
There is no need to explicitly present these prefix scopes, but these There is no need to explicitly present these prefix scopes, but these
restrictions should be used as premier check in binding set up. restrictions should be used as the premier check in binding setup.
8. Acknowledgment When SAVI is partially deployed, binding may fail as RA messages and
DHCP-PD can be spoofed. So, it is recommended that Manual Prefix
Configuration be used unless SAVI gets fully deployed.
8. Acknowledgments
The authors would like to thank the SAVI working group for a thorough The authors would like to thank the SAVI working group for a thorough
technical discussion on the design and the framework of the SAVI technical discussion on the design and the framework of the SAVI
method, as captured in this document, in particular Erik Nordmark, method as captured in this document, in particular Erik Nordmark,
Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to
Torben Melsen for reviewing this document. Torben Melsen for reviewing this document.
This document was generated using the xml2rfc tool. 9. Security Considerations
9. 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 authors' perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
10. Security Considerations
This document only discusses the possible methods to mitigate the This document only discusses the possible methods to mitigate the
usage of forged IP addresses. Some such methods may rely on usage of forged IP addresses. Some such methods may rely on
cryptographic methods, but not all do. As a result, it is generally cryptographic methods, but not all do. As a result, it is generally
not possible to prove address ownership in any strong sense. If not possible to prove address ownership in any strong sense. If a
binding anchor is not exclusive for each user, or is without strong binding anchor is not exclusive for each IP address, or is without
security, addresses can still be forged. Besides, the binding may strong security, addresses can still be forged. Besides, the binding
not accord with the address management requirement, which can be more may not accord with the address management requirement, which can be
specified for each client. However, given no new protocol is more specified for each client. However, given no new protocol is
introduced, the improvements are still acceptable. If there is introduced, the improvements are still acceptable. If strong
requirement the usage of IP address must be of strong security, the security is required when using IP addresses, then cryptographic-
only way is using cryptographic based authentication. based authentication must be used as it is the only way to provide
strong security.
11. References Section 2 explains how the preferred location of SAVI instances is
close to hosts. However, in some cases, this makes the SAVI
instances themselves vulnerable and may defeat the purpose of
deploying a SAVI solution. For instance, deployments should not
place SAVI functionality in devices that are physically exposed.
Even if the device correctly monitors the source address usage of
hosts, an attacker could replace the device with one that does not
check or hook up to a trusted interface from the device to the rest
of the network. Similarly, deployments where SAVI instances are
distributed across administrative boundaries are not recommended.
For instance, in most cases, it would be undesirable to deploy a
distributed SAVI solution on both sides of a customer-provider
interface if the solution required trusting the correct operation of
the SAVI devices on the other side of the interface.
11.1. Informative References 10. References
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 10.1. Normative References
Internet draft (work in progress), November 2007.
[BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
Defeating Denial of Service Attacks which employ IP Source 2131, March 1997.
Address Spoofing", RFC 2827, BCP 38, May 2000.
11.2. Normative References [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.
[draft-ietf-savi-threat-scope] [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
McPherson, D., Baker, F., and J. Halpern, "SAVI Threat Neighbor Discovery (SEND)", RFC 3971, March 2005.
Scope", draft-ietf-savi-threat-scope-04 (work in
progress), March 2011.
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
RFC 2131, March 1997. Address Autoconfiguration", RFC 4862, September 2007.
[rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
and M. Carney, "Dynamic Host Configuration Protocol for Bootstrapping in Split Scenario", RFC 5026, October 2007.
IPv6 (DHCPv6)", RFC 3315, July 2003.
[rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6
Neighbor Discovery (SEND)", RFC 3971, March 2005. Configuration in Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 5739, February 2010.
[rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
Address Autoconfiguration", RFC 4862, September 2007. "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[rfc5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
Bootstrapping in Split Scenario", RFC 5026, October 2007. SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012.
[rfc5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Configuration in Internet Key Exchange Protocol Version 2 Validation Improvement (SAVI) Threat Scope", RFC 6959,
(IKEv2)", RFC 5739, February 2010. May 2013.
[rfc5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 10.2. Informative References
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[savi-dhcp] [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", Work in
Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for Progress, November 2007.
DHCP", draft-ietf-savi-dhcp-07 (work in progress),
November 2010.
[savi-fcfs] [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- Defeating Denial of Service Attacks which employ IP
SAVI: First-Come First-Serve Source-Address Validation for Source Address Spoofing", BCP 38, RFC 2827, May 2000.
Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work
in progress), October 2010. [BCP84] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
DHCP", Work in Progress, June 2013.
[SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI
for Mixed Address Assignment Methods Scenario", Work in Progress, May
2013.
Authors' Addresses Authors' Addresses
Jianping Wu Jianping Wu
Tsinghua University Tsinghua University
Computer Science, Tsinghua University Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
China China
Email: jianping@cernet.edu.cn EMail: jianping@cernet.edu.cn
Jun Bi Jun Bi
Tsinghua University Tsinghua University
Network Research Center, Tsinghua University Network Research Center, Tsinghua University
Beijing 100084 Beijing 100084
China China
Email: junbi@tsinghua.edu.cn EMail: junbi@tsinghua.edu.cn
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Avenida de la Universidad 30 Avenida de la Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Email: marcelo@it.uc3m.es EMail: marcelo@it.uc3m.es
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, CA 93117 Santa Barbara, CA 93117
United States United States
Email: fred@cisco.com EMail: fred@cisco.com
Christian Vogt (editor) Christian Vogt (editor)
Ericsson 3507 Palmilla Drive
200 Holger Way
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: christian.vogt@ericsson.com EMail: mail@christianvogt.net
 End of changes. 82 change blocks. 
230 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/