draft-ietf-savi-framework-04.txt   draft-ietf-savi-framework-05.txt 
Network Working Group J. Wu Network Working Group J. Wu
Internet-Draft J. Bi Internet-Draft J. Bi
Intended status: Informational Tsinghua Univ. Intended status: Informational Tsinghua Univ.
Expires: September 29, 2011 M. Bagnulo Expires: January 26, 2012 M. Bagnulo
UC3M UC3M
F. Baker F. Baker
Cisco Cisco
C. Vogt, Ed. C. Vogt, Ed.
Ericsson Ericsson
March 28, 2011 July 25, 2011
Source Address Validation Improvement Framework Source Address Validation Improvement Framework
draft-ietf-savi-framework-04 draft-ietf-savi-framework-05
Abstract Abstract
The Source Address Validation Improvement method was developed to The Source Address Validation Improvement method was developed to
complement ingress filtering with finer-grained, standardized IP complement ingress filtering with finer-grained, standardized IP
source address validation. This document describes and motivates the source address validation. This document describes and motivates the
design of the SAVI method. design of the SAVI method.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2011. This Internet-Draft will expire on January 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10
6. Mix Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10
7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . . 11 7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Informative References . . . . . . . . . . . . . . . . . 12 11.1. Informative References . . . . . . . . . . . . . . . . . 12
11.2. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
skipping to change at page 4, line 30 skipping to change at page 4, line 30
Ingress filtering [BCP38], a widely deployed standard for IP source Ingress filtering [BCP38], a widely deployed standard for IP source
address validation, functions at the coarse granularity of networks. address validation, functions at the coarse granularity of networks.
It verifies that the prefix of an IP source address routes to the It verifies that the prefix of an IP source address routes to the
network from which the packet was received. An advantage of ingress network from which the packet was received. An advantage of ingress
filtering is simplicity: the decision of whether to accept or to filtering is simplicity: the decision of whether to accept or to
reject an IP source address can be made solely based on the 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 be helpful to enable IP-source- source address validation would ensure that source address
address-based authentication, authorization, and host localization, information is accurate, reduce the ability to launch denial-of-
as well as to efficiently identify misbehaving hosts. Partial service attacks, and help with localizing hosts and identify
solutions [BA2007] exist for finer-grained IP source address misbehaving hosts. Partial solutions [BA2007] exist for finer-
validation, but are proprietary and hence often unsuitable for grained IP source address validation, but are proprietary and hence
corporate procurement. often unsuitable for corporate procurement.
The Source Address Validation Improvement method was developed to The Source Address Validation Improvement method was developed to
complement ingress filtering with standardized IP source address 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.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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 a SAVI instance to be located anywhere on the link This model allows SAVI functionality (a SAVI instance) to be located
to which the hosts attach, hence enabling different locations for a anywhere on the link to which the hosts attach, hence enabling
SAVI instance. One way to locate a SAVI instance is in the hosts' different locations for a SAVI instance. One way to locate a SAVI
default router. IP source addresses are then validated in packets instance is in the hosts' default router. IP source addresses are
traversing the default router, yet the IP source addresses in packets then validated in packets traversing the default router, yet the IP
exchanged locally on the link may bypass validation. Another way to source addresses in packets exchanged locally on the link may bypass
locate a SAVI instance is in a switch between the hosts and their validation. Another way to locate a SAVI instance is in a switch
default router. Thus, packets may undergo IP source address between the hosts and their default router. Thus, packets may
validation even if exchanged locally on the link. undergo IP source address validation even if exchanged locally on the
link.
The closer a SAVI instance is located to the hosts, the more The closer a SAVI instance is located to the hosts, the more
effective the SAVI method is. This is because each of the three effective the SAVI method is. This is because each of the three
steps of the SAVI model can best be accomplished in a position close steps of the 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 packets bypass a SAVI instance, and hence cannot be host's packets bypass a SAVI instance, and hence cannot be
monitored, increases with the distance between the SAVI instance monitored, increases with the distance between the SAVI instance
skipping to change at page 6, line 6 skipping to change at page 6, line 7
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 distance
between the SAVI instance and the host. 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.
To make SAVI of better applicability, to handle the scenarios in Nevertheless, it is useful for SAVI mechanisms to be able to handle
which hosts are not directly attached is of value. For example, a situations where hosts are not directly attached to the SAVI-capable
SAVI instance is attached by a legacy switch which is attached by device. For instance, deployments with both SAVI-capable and legacy
hosts. However, to take such scenario into consideration requires switches could be supported. In general, a SAVI solution needs to
support in the bind-and-identify model. Considering two scenarios: specify how it deals with a number of deployment scenarios and
exceptional situations, including interaction with legacy devices,
o A legacy switch to which hosts are attaching uses two trunked hosts moving between wireless attachment points, network partitions,
ports to connect to SAVI switch. and so on.
o STP runs among switches, and a link failure happens.
Both scenarios require more specified design to build correct
binding. Thus, for each SAVI solution, the applicability must be
specified explicitly.
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:
skipping to change at page 7, line 13 skipping to change at page 7, line 4
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 co-exist
on a given link. The SAVI method hence comes in multiple variants: on a given link. The SAVI method hence comes in multiple variants:
for links with Stateless Address Autoconfiguration [rfc4862], for
links with DHCP [rfc2131][rfc3315], for links with Secure Neighbor for links with DHCP [rfc2131][rfc3315], Stateless Address
Discovery [rfc3971], for links with IKEv2 [rfc5996] [rfc5739] Autoconfiguration [rfc4862] with or without Secure Neighbor Discovery
[rfc5026] and for links that use any combination of IP address [rfc3971], IKEv2[rfc5996] [rfc5739] [rfc5026] and combinations
assignment methods. 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 methods or, equivalently from the
perspective of the SAVI method, separate IP address assignment perspective of the SAVI method, separate IP address assignment
methods into different IP address prefixes. The SAVI method for such methods into different IP address prefixes. The SAVI method for such
links can be simpler than the SAVI method for links with multiple IP links can be simpler than the SAVI method for links with multiple IP
address assignment methods per IP address prefix. address assignment methods per IP address prefix.
skipping to change at page 10, line 45 skipping to change at page 10, line 45
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.
6. Mix Scenario 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 mix scenario can handle the same as scenario with only one assignment
method. If different address assignment methods are used to assign method. If different address assignment methods are used to assign
addresses from the same prefix, additional considerations are needed addresses from the same prefix, additional considerations are needed
because one binding mechanism may create a binding violating an because one binding mechanism may create a binding violating an
existing binding from another binding mechanism, e.g., binding from existing binding from another binding mechanism, e.g., binding from
SAVI-FCFS [savi-fcfs] may violate binding from SAVI-DHCP [savi-dhcp]. SAVI-FCFS [savi-fcfs] may violate binding from SAVI-DHCP [savi-dhcp].
skipping to change at page 11, line 28 skipping to change at page 11, line 28
in some scenarios, default prioritization level may not be quite in some scenarios, default prioritization level may not be quite
suitable. Configurable prioritization level should be supported in a suitable. Configurable prioritization level should be supported in a
document of SAVI solution for the mix scenario. document of SAVI solution for the mix scenario.
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 set 3 prefix configuration mechanisms at SAVI device:
o Manually 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 SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually
at SAVI device. FE80::/64 is always a feasible prefix in IPv6. at 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 RA Snooping: The allowed prefix scope of
IPv6 static addresses and IPv6 addresses assigned by SLAAC can be IPv6 static addresses and IPv6 addresses assigned by SLAAC can be
set at SAVI device through snooping RA message at SAVI device. set at SAVI device through snooping RA message at SAVI device.
FE80::/64 is always a feasible prefix in IPv6.
o Prefix Configuration by DHCP-PD Snooping: The allowed prefix o Prefix Configuration by DHCP-PD Snooping: The allowed prefix
scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC,
and IPv6 addresses assigned by DHCPv6 can be set through snooping and IPv6 addresses assigned by DHCPv6 can be set through snooping
DHCP-PD message at SAVI device. FE80::/64 is always a feasible DHCP-PD message at SAVI device.
prefix in IPv6.
If some of the prefix scopes is set to have non prefix, it implies If some of the prefix scopes is set to have no prefix, it implies
corresponding address assignment method is not allowed in the corresponding address assignment method is not allowed in the
network. 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 premier check in binding set up.
8. Acknowledgment 8. Acknowledgment
The author 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. This document was generated using the xml2rfc tool.
9. IANA Considerations 9. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during required, or if those assignments or registries are created during
the RFC publication process. From the authors' perspective, it may the RFC publication process. From the authors' perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's therefore be removed upon publication as an RFC at the RFC Editor's
discretion. discretion.
10. Security Considerations 10. Security Considerations
This document only discusses the possible methods to mitigrate the This document only discusses the possible methods to mitigate the
usage of forged IP address, but doesn't propose a mechanism that usage of forged IP addresses. Some such methods may rely on
provides strong security for IP address. If binding anchor is not cryptographic methods, but not all do. As a result, it is generally
exclusive for each user, or is without strong security, addresses can not possible to prove address ownership in any strong sense. If
still be forged. Besides, the binding may not accord with the binding anchor is not exclusive for each user, or is without strong
address management requirement, which can be more specified for each security, addresses can still be forged. Besides, the binding may
client. However, given no new protocol is introduced, the not accord with the address management requirement, which can be more
improvements are still acceptable. If there is requirement the usage specified for each client. However, given no new protocol is
of IP address must be of strong security, the only way is using introduced, the improvements are still acceptable. If there is
cryptographic based authentication. requirement the usage of IP address must be of strong security, the
only way is using cryptographic based authentication.
11. References 11. References
11.1. Informative References 11.1. Informative References
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF
Internet draft (work in progress), November 2007. Internet draft (work in progress), November 2007.
[BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
 End of changes. 17 change blocks. 
57 lines changed or deleted 51 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/