draft-ietf-savi-framework-00.txt   draft-ietf-savi-framework-01.txt 
Network Working Group Jianping Wu Network Working Group Jianping Wu
Internet-Draft Jun Bi Internet-Draft Jun Bi
Intended status: Informational CERNET Intended status: Informational CERNET
Expires: March 26, 2011 Marcelo Bagnulo Expires: April 28, 2011 Marcelo Bagnulo
UC3M UC3M
Fred Baker Fred Baker
Cisco Cisco
Christian Vogt, Ed. Christian Vogt, Ed.
Ericsson Ericsson
September 22, 2010 October 25, 2010
Source Address Validation Improvement Protocol Framework Source Address Validation Improvement Framework
draft-ietf-savi-framework-00 draft-ietf-savi-framework-01
Abstract Abstract
The Source Address Validation Improvement protocol 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 protocol. design of the SAVI method.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 26, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 5 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 5
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . . 6 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . . 6
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . . 8 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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
corporate procurement. corporate procurement.
The Source Address Validation Improvement protocol 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 protocol 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 protocol. SAVI method.
2. Protocol 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 protocol was designed to be purely network-based. A SAVI the SAVI method was designed to be purely network-based. A SAVI
protocol instance is located on the path of hosts' packets, enforcing instance is located on the path of hosts' packets, enforcing the
the hosts' use of legitimate IP source addresses according to the hosts' use of legitimate IP source addresses 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 a SAVI protocol instance to be located anywhere on This model allows a SAVI instance to be located anywhere on the link
the link to which the hosts attach, hence enabling different to which the hosts attach, hence enabling different locations for a
locations for a protocol instance. One way to locate a SAVI protocol SAVI instance. One way to locate a SAVI instance is in the hosts'
instance is in the hosts' default router. IP source addresses are default router. IP source addresses are then validated in packets
then validated in packets traversing the default router, yet the IP traversing the default router, yet the IP source addresses in packets
source addresses in packets exchanged locally on the link may bypass exchanged locally on the link may bypass validation. Another way to
validation. Another way to locate a SAVI protocol instance is in a locate a SAVI instance is in a switch between the hosts and their
switch between the hosts and their default router. Thus, packets may default router. Thus, packets may undergo IP source address
undergo IP source address validation even if exchanged locally on the validation even if exchanged locally on the link.
link.
The closer a SAVI protocol instance is located to the hosts, the more The closer a SAVI instance is located to the hosts, the more
effective the SAVI protocol is. This is because each of the three effective the SAVI method is. This is because each of the three
steps of the SAVI protocol model can best be accomplished in a steps of the SAVI model can best be accomplished in a position close
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 protocol instance, and hence cannot host's packets bypass a SAVI instance, and hence cannot be
be monitored, increases with the distance between the SAVI monitored, increases with the distance between the SAVI instance
protocol 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 attaching
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 protocol instance, and hence that the host's packets bypass a SAVI instance, and hence do not
do not undergo IP source address validation, increases with the undergo IP source address validation, increases with the distance
distance between the protocol instance and the host. between the SAVI instance and the host.
The preferred location of SAVI protocol instances is therefore close The preferred location of SAVI instances is therefore close to hosts,
to hosts, such as in switches that directly attach to the hosts whose such as in switches that directly attach to the hosts whose IP source
IP source addresses are being validated. addresses are being validated.
3. Deployment Options 3. Deployment Options
The model of the SAVI protocol, 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 protocol in networks of To facilitate the deployment of the SAVI method in networks of
various kinds, the SAVI protocol 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 sub-sections explain this impact, and describe how the
SAVI protocol accommodates this. SAVI method accommodates this.
3.1. IP Address Assignment Methods 3.1. IP Address Assignment Methods
Since the SAVI protocol 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 protocol 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 protocol 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, for links with
DHCP, for links with Secure Neighbor Discovery, and for links that DHCP, for links with Secure Neighbor Discovery, and for links that
use any combination of IP address assignment methods. use any combination of IP address assignment methods.
The reason to develop SAVI protocol variants for each single IP The reason to develop SAVI method variants for each single IP address
address configuration method, in addition to the variant that handles configuration method, in addition to the variant that handles all IP
all IP address assignment methods, is to minimize the complexity of address assignment methods, is to minimize the complexity of the
the common case: Many link deployments today either are constrained common case: Many link deployments today either are constrained to a
to a single IP address assignment methods or, equivalently from the single IP address assignment methods or, equivalently from the
perspective of the SAVI protocol, separate IP address assignment perspective of the SAVI method, separate IP address assignment
methods into different IP address prefixes. The SAVI protocol for methods into different IP address prefixes. The SAVI method for such
such links can be simpler than the SAVI protocol for links with links can be simpler than the SAVI method for links with multiple IP
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 protocol 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
skipping to change at page 7, line 45 skipping to change at page 7, line 45
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 in addition if available. ports in addition if available.
4. Scalability Optimizations 4. Scalability Optimizations
The preference to locate a SAVI protocol instance close to hosts The preference to locate a SAVI instance close to hosts implies that
implies that multiple SAVI protocol instances must be able to co- multiple SAVI instances must be able to co-exist in order to support
exist in order to support large links. Although the SAVI protocol large links. Although the model of the SAVI method is independent of
model is independent of the number of protocol instances per link, the number of SAVI instances per link, co-existence of multiple SAVI
co-existence of multiple protocol instances without further measures instances without further measures can lead to higher-than-necessary
can lead to higher-than-necessary memory requirements: Since a SAVI memory requirements: Since a SAVI instance creates bindings for the
protocol instance creates bindings for the IP source addresses of all IP source addresses of all hosts on a link, bindings are replicated
hosts on a link, bindings are replicated if multiple protocol if multiple SAVI instances co-exist on the link. High memory
instances co-exist on the link. High memory requirements, in turn, requirements, in turn, increase the cost of a SAVI instance. This is
increase the cost of a SAVI protocol instance. This is problematic problematic in particular for SAVI instances that are located on a
in particular for SAVI protocol 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 protocol instances that are To reduce memory requirements for SAVI instances that are located on
located on a switch, the SAVI protocol enables the suppression of a switch, the SAVI method enables the suppression of binding
binding replication on links with multiple protocol instances. This replication on links with multiple SAVI instances. This requires
requires manual disabling of IP source address validation on switch manual disabling of IP source address validation on switch ports that
ports that connect to other switches running a SAVI protocol connect to other switches running a SAVI instance. Each SAVI
instance. Each SAVI protocol instance is then responsible for instance is then responsible for validating IP source addresses only
validating IP source addresses only on those ports to which hosts on those ports to which hosts attach either directly, or via switches
attach either directly, or via switches without a SAVI protocol without a SAVI instance. On ports towards other switches running a
instance. On ports towards other switches running a SAVI protocol SAVI instance, IP source addresses are not validated. The switches
instance, IP source addresses are not validated. The switches running SAVI instances thus form a "protection perimeter". The IP
running SAVI protocol instances thus form a "protection perimeter". source addresses in packets passing the protection perimeter are
The IP source addresses in packets passing the protection perimeter validated by the ingress SAVI instance, but no further validation
are validated by the ingress SAVI protocol instance, but no further takes place as long as the packets remain within, or leave the
validation takes place as long as the packets remain within, or leave protection perimeter.
the protection perimeter.
.............. ..............
protection perimeter --> : +--------+ : protection perimeter --> : +--------+ :
+---+ +---+ : | SAVI | : +---+ +---+ : | SAVI | :
| A | | B | <-- hosts : | switch | : | A | | B | <-- hosts : | switch | :
+---+ +---+ : +--------+ : +---+ +---+ : +--------+ :
...|......|.............................: | : ...|......|.............................: | :
: +--------+ +--------+ +--------+ : : +--------+ +--------+ +--------+ :
: | SAVI |----------| legacy | | SAVI | : : | SAVI |----------| legacy | | SAVI | :
: | switch | | switch |----------| switch | : : | switch | | switch |----------| switch | :
skipping to change at page 9, line 7 skipping to change at page 9, line 4
: +--------+ : +--------+ : +--------+ : +--------+
:............: | | :............: | |
+---+ +---+ +---+ +---+
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 protocol instance. The protection perimeter switch", run a SAVI instance. The protection perimeter created by
created by the four SAVI protocol instances is shown as a dotted line the four SAVI instances is shown as a dotted line in the figure. IP
in the figure. IP source address validation is enabled on all switch source address validation is enabled on all switch ports on the
ports on the protection perimeter, and it is disabled on all other protection perimeter, and it is disabled on all other switch ports.
switch ports. Four hosts, denoted A through D in the figure, attach Four hosts, denoted A through D in the figure, attach to the
to the protection perimeter. protection perimeter.
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 protocol instances because every binding is requirements for the SAVI instances because every binding is kept
kept only once, namely, by the SAVI protocol instance that attaches only once, namely, by the SAVI instance that attaches to the host
to the host being validated. Excluding the legacy switch from the being validated. Excluding the legacy switch from the protection
protection perimeter would result in two smaller protection perimeter would result in two smaller protection perimeters to the
perimeters to the left and to the right of the depicted link left and to the right of the depicted link topology. The memory
topology. The memory requirements for the SAVI protocol instances requirements for the SAVI instances would then be higher: Since IP
would then be higher: Since IP source address validation would be source address validation would be activated on the two ports
activated on the two ports connecting to the legacy switch, the SAVI connecting to the legacy switch, the SAVI instances adjacent to the
protocol instances adjacent to the legacy switch would replicate all legacy switch would replicate all bindings from the respectively
bindings from the respectively other protection perimeter. The other protection perimeter. The reason why it is possible to include
reason why it is possible to include the legacy switch in the the legacy switch in the protection perimeter is because the depicted
protection perimeter is because the depicted link topology guarantees link topology guarantees that packets cannot enter the protection
that packets cannot enter the protection perimeter via this legacy perimeter via this legacy switch. Without this guarantee, the legacy
switch. Without this guarantee, the legacy switch would have to be switch would have to be excluded from the protection perimeter in
excluded from the protection perimeter in order to ensure that order to ensure that packets entering the protection perimeter
packets entering the protection perimeter undergo IP source address undergo IP source address validation.
validation.
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 protocol instance, are lost the creation of a binding in a SAVI instance, are lost before
before reaching the SAVI protocol instance. reaching the SAVI instance.
o A SAVI protocol instance loses a binding, for example, due to a o A SAVI instance loses a binding, for example, due to a restart.
restart.
o The link topology changes, resulting in hosts to communicate o The link topology changes, resulting in hosts to communicate
through SAVI protocol instances that do not have a binding for through SAVI instances that do not have a binding for those hosts'
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 protocol includes a mechanism for addresses can have, the SAVI method includes a mechanism for reactive
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
protocol instances recognizes excessive drops of regular packets instances recognizes excessive drops of regular packets originating
originating from the same IP address. The SAVI protocol instance from the same IP address. The SAVI instance then verifies whether
then verifies whether said IP address is unique on the link. How the said IP address is unique on the link. How the verification is
verification is carried out depends on the IP address configuration carried out depends on the IP address configuration method that the
method that the SAVI protocol instance supports: The SAVI protocol SAVI instance supports: The SAVI method variant for Stateless
variant for Stateless Address Autoconfiguration and for Secure Address Autoconfiguration and for Secure Neighbor Discovery verifies
Neighbor Discovery verifies an IP address through the Duplicate an IP address through the Duplicate Address Detection procedure. The
Address Detection procedure. The SAVI protocol variant for DHCP SAVI method variant for DHCP verifies an IP address through a DHCP
verifies an IP address through a DHCP Lease Query message exchange Lease Query message exchange with the DHCP server. If verification
with the DHCP server. If verification indicates that the IP address indicates that the IP address is unique on the link, the SAVI
is unique on the link, the SAVI protocol instance creates a binding instance creates a binding for the IP address. Otherwise, no binding
for the IP address. Otherwise, no binding is created, and packets is created, and packets sent from the IP address continue to be
sent from the IP address continue to be dropped. dropped.
6. Acknowledgment 6. 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
protocol, 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.
7. References 7. References
[BA2007] Fred, F., "Cisco IP Version 4 Source Guard", IETF Internet [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet
draft (work in progress), November 2007. 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
Address Spoofing", RFC 2827, BCP 38, May 2000. Address Spoofing", RFC 2827, BCP 38, May 2000.
Authors' Addresses Authors' Addresses
Jianping Wu Jianping Wu
CERNET CERNET
 End of changes. 36 change blocks. 
127 lines changed or deleted 122 lines changed or added

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