draft-ietf-savi-framework-02.txt   draft-ietf-savi-framework-03.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: August 15, 2011 M. Bagnulo Expires: September 13, 2011 M. Bagnulo
UC3M UC3M
F. Baker F. Baker
Cisco Cisco
C. Vogt, Ed. C. Vogt, Ed.
Ericsson Ericsson
February 11, 2011 March 12, 2011
Source Address Validation Improvement Framework Source Address Validation Improvement Framework
draft-ietf-savi-framework-02 draft-ietf-savi-framework-03
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 August 15, 2011. This Internet-Draft will expire on September 13, 2011.
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 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 7 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 9 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10
6. Mix Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Mix Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Informative References . . . . . . . . . . . . . . . . . 12
10.2. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
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
Since the IP source address of a packet generally takes no role in [draft-ietf-savi-threat-scope]. Since the IP source address of a
forwarding the packet, it can be selected arbitrarily by the sending packet generally takes no role in forwarding the packet, it can be
host without jeopardizing packet delivery. Extra methods are selected arbitrarily by the sending host without jeopardizing packet
necessary for IP source address validation, to augment packet delivery. Extra methods are necessary for IP source address
forwarding with an explicit check of whether a given packet's IP validation, to augment packet forwarding with an explicit check of
source address is legitimate. whether a given packet's IP 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], 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 be helpful to enable IP-source-
address-based authentication, authorization, and host localization, address-based authentication, authorization, and host localization,
as well as to efficiently identify misbehaving hosts. Partial as well as to efficiently identify misbehaving hosts. Partial
solutions [BA2007] exist for finer-grained IP source address solutions [BA2007] exist for finer-grained IP source address
validation, but are proprietary and hence often unsuitable for validation, but are proprietary and hence often unsuitable for
skipping to change at page 6, line 6 skipping to change at page 6, line 6
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
which hosts are not directly attached is of value. For example, a
SAVI instance is attached by a legacy switch which is attached by
hosts. However, to take such scenario into consideration requires
support in the bind-and-identify model. Considering two scenarios:
o A legacy switch to which hosts are attaching uses two trunked
ports to connect to SAVI switch.
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,
as there is no full protection for the hosts connected to the legacy
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.
skipping to change at page 6, line 37 skipping to change at page 7, line 13
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, for links with for links with Stateless Address Autoconfiguration [rfc4862], for
DHCP, for links with Secure Neighbor Discovery, and for links that links with DHCP [rfc2131][rfc3315], for links with Secure Neighbor
use any combination of IP address assignment methods. Discovery [rfc3971], for links with IKEv2 [rfc5996] [rfc5739]
[rfc5026] and for links that use any combination of IP address
assignment methods.
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.
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:
skipping to change at page 7, line 50 skipping to change at page 8, line 25
and MAC addresses otherwise. Or to use MAC addresses, and switch and MAC addresses otherwise. Or to use MAC addresses, and switch
ports in addition if available. ports 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 co-exist 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, co-existence 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 co-exist 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
skipping to change at page 9, line 20 skipping to change at page 9, line 45
In the example of figure Figure 1, the protection perimeter In the example of figure Figure 1, the protection perimeter
encompasses one of the legacy switches, located in the middle of the encompasses one of the legacy switches, located in the middle of the
depicted link topology. This enables a single, unpartitioned depicted link topology. This enables a single, unpartitioned
protection perimeter. A single protection perimeter minimizes memory protection perimeter. A single protection perimeter minimizes memory
requirements for the SAVI instances because every binding is kept requirements for the SAVI instances because every binding is kept
only once, namely, by the SAVI instance that attaches to the host only once, namely, by the SAVI instance that attaches to the host
being validated. Excluding the legacy switch from the protection being validated. Excluding the legacy switch from the protection
perimeter would result in two smaller protection perimeters to the perimeter would result in two smaller protection perimeters to the
left and to the right of the depicted link topology. The memory left and to the right of the depicted link topology. The memory
requirements for the SAVI instances would then be higher: Since IP requirements for the SAVI instances would then be higher: since IP
source address validation would be activated on the two ports source address validation would be activated on the two ports
connecting to the legacy switch, the SAVI instances adjacent to the connecting to the legacy switch, the SAVI instances adjacent to the
legacy switch would replicate all bindings from the respectively legacy switch would replicate all bindings from the respectively
other protection perimeter. The reason why it is possible to include other protection perimeter. The reason why it is possible to include
the legacy switch in the protection perimeter is because the depicted the legacy switch in the protection perimeter is because the depicted
link topology guarantees that packets cannot enter the protection link 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.
skipping to change at page 10, line 11 skipping to change at page 10, line 35
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 instances 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.
6. Mix Scenario 6. Mix Scenario
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 may violate binding from SAVI-DHCP. Thus, the collision SAVI-FCFS [savi-fcfs] may violate binding from SAVI-DHCP [savi-dhcp].
between different SAVI mechanisms in mix scenario must be handled in Thus, the collision between different SAVI mechanisms in mix scenario
case more than one address assignment method is used to assign must be handled in case more than one address assignment method is
addresses from the same prefix. used to assign addresses from the same prefix.
Prioritization relationship between different address assignment Prioritization relationship between different address assignment
methods is used as the basis to solve possible collisions. Current methods is used as the basis to solve possible collisions. Current
standard documents of address assignment methods have implied the standard documents of address assignment methods have implied the
prioritization relationship in general cases. However, considering prioritization relationship in general cases. However, considering
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. Acknowledgment 7. Acknowledgment
The author would like to thank the SAVI working group for a thorough The author 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.
8. References 8. IANA Considerations
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet This memo asks the IANA for no new parameters.
draft (work in progress), November 2007.
[BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: Note to RFC Editor: This section will have served its purpose if it
Defeating Denial of Service Attacks which employ IP Source correctly tells IANA that no new assignments or registries are
Address Spoofing", RFC 2827, BCP 38, May 2000. 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.
9. Security Considerations
This document only discusses the possible methods to mitigrate the
usage of forged IP address, but doesn't propose a mechanism that
provides strong security for IP address. If binding anchor is not
exclusive for each user, or is without strong security, addresses can
still be forged. Besides, the binding may not accord with the
address management requirement, which can be more specified for each
client. However, given no new protocol is introduced, the
improvements are still acceptable. If there is requirement the usage
of IP address must be of strong security, the only way is using
cryptographic based authentication.
10. References
10.1. Informative References
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF
Internet draft (work in progress), November 2007.
[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.
10.2. Normative References
[draft-ietf-savi-threat-scope]
McPherson, D., Baker, F., and J. Halpern, "SAVI Threat
Scope", draft-ietf-savi-threat-scope-04 (work in
progress), March 2011.
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[rfc5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
[rfc5739] Eronen, P., Laganier, J., and C. Madson, "IPv6
Configuration in Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 5739, February 2010.
[rfc5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[savi-dhcp]
Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
DHCP", draft-ietf-savi-dhcp-07 (work in progress),
November 2010.
[savi-fcfs]
Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS-
SAVI: First-Come First-Serve Source-Address Validation for
Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work
in progress), October 2010.
Authors' Addresses Authors' Addresses
Jianping Wu Jianping Wu
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
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
 End of changes. 21 change blocks. 
35 lines changed or deleted 130 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/