draft-ietf-savi-threat-scope-06.txt   draft-ietf-savi-threat-scope-07.txt 
SAVI D. McPherson SAVI D. McPherson
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Informational F. Baker Intended status: Informational F.J. Baker
Expires: August 27, 2013 Cisco Systems Expires: October 05, 2013 Cisco Systems
J. Halpern J.M. Halpern
Ericsson Ericsson
February 23, 2013 April 03, 2013
SAVI Threat Scope SAVI Threat Scope
draft-ietf-savi-threat-scope-06 draft-ietf-savi-threat-scope-07
Abstract Abstract
Source Address Validation Improvement (SAVI) effort aims to Source Address Validation Improvement (SAVI) effort aims to
complement ingress filtering with finer-grained, standardized IP complement ingress filtering with finer-grained, standardized IP
source address validation. This document describes threats enabled source address validation. This document describes threats enabled
by IP source address spoofing both in the global and finer-grained by IP source address spoofing both in the global and finer-grained
context, describes currently available solutions and challenges, and context, describes currently available solutions and challenges, and
provides a starting point analysis for finer-grained (host provides a starting point analysis for finer-grained (host
granularity) anti-spoofing work. granularity) anti-spoofing work.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 27, 2013. This Internet-Draft will expire on October 05, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . 5
3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 7 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6
3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 7 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6
3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 8 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7
3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . . 9 3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . 8
3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . . 9 3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . 8
3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 9 3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 8
3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . . 10 3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . 9
3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 10 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 10 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . 9
3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10
3.2.3. Other Non-Blind Spoofing Attacks . . . . . . . . . . . 11 3.2.3. Other Non-Blind Spoofing Attacks . . . . . . . . . . 10
4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 11 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 10
4.1. Topological Locations for Enforcement . . . . . . . . . . 12 4.1. Topological Locations for Enforcement . . . . . . . . . . 12
4.1.1. Host to link layer neighbor via switch . . . . . . . . 13 4.1.1. Host to link layer neighbor via switch . . . . . . . 12
4.1.2. Upstream Switches . . . . . . . . . . . . . . . . . . 13 4.1.2. Upstream Switches . . . . . . . . . . . . . . . . . . 12
4.1.3. Upstream Routers . . . . . . . . . . . . . . . . . . . 13 4.1.3. Upstream Routers . . . . . . . . . . . . . . . . . . 13
4.1.4. ISP Edge PE Router . . . . . . . . . . . . . . . . . . 14 4.1.4. ISP Edge PE Router . . . . . . . . . . . . . . . . . 13
4.1.5. ISP NNI Router to ISP NNI Router . . . . . . . . . . . 14 4.1.5. ISP NNI Router to ISP NNI Router . . . . . . . . . . 13
4.1.6. Cable Modem Subscriber Access . . . . . . . . . . . . 15 4.1.6. Cable Modem Subscriber Access . . . . . . . . . . . . 14
4.1.7. DSL Subscriber Access . . . . . . . . . . . . . . . . 15 4.1.7. DSL Subscriber Access . . . . . . . . . . . . . . . . 14
4.2. Currently Available Tools . . . . . . . . . . . . . . . . 15 4.2. Currently Available Tools . . . . . . . . . . . . . . . . 15
4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Port-based Address Binding . . . . . . . . . . . . . . 16 4.2.3. Port-based Address Binding . . . . . . . . . . . . . 15
4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . . 17 4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . 16
4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . . 17 4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . 17
5. Topological Challenges Facing SAVI . . . . . . . . . . . . . . 18 5. Topological Challenges Facing SAVI . . . . . . . . . . . . . 17
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 18 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 17
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 18 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 17
5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . 19 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . 18
5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 19 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 18
5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 20 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 20 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 19
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 20 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . 19
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 20
6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . . 21 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Overview 1. Overview
The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6
[RFC2460], employ a connectionless hop-by-hop packet forwarding [RFC2460], employ a connectionless hop-by-hop packet forwarding
paradigm. A host connected to an IP network that wishes to paradigm. A host connected to an IP network that wishes to
communicate with another host on the network generates an IP packet communicate with another host on the network generates an IP packet
with source and destination IP addressing information, among other with source and destination IP addressing information, among other
options. options.
skipping to change at page 5, line 16 skipping to change at page 4, line 27
with better traceability. This allows the enterprise to be a better with better traceability. This allows the enterprise to be a better
Internet participant, and to quickly detect and remedy problems when Internet participant, and to quickly detect and remedy problems when
they occur. For example, when an enterprise receives a report of an they occur. For example, when an enterprise receives a report of an
attack originating within that enterprise, the operational staff attack originating within that enterprise, the operational staff
desires to be able to track from the IP address sourcing the attack desires to be able to track from the IP address sourcing the attack
to the particular machine within the enterprise that is the source. to the particular machine within the enterprise that is the source.
This is typically simpler and more reliable than other techniques, This is typically simpler and more reliable than other techniques,
such as trying to find the attack in ongoing outbound traffic To do such as trying to find the attack in ongoing outbound traffic To do
this, the enterprise needs both that the address assignment and usage this, the enterprise needs both that the address assignment and usage
information be usable (logging), and that the information be information be usable (logging), and that the information be
accurate, i.e. that no other machine could have been using that accurate, i.e. that no other machine could have been using that
address. address.
Also, there is a possibility that in a LAN environment where multiple Also, there is a possibility that in a LAN environment where multiple
hosts share a single LAN or IP port on a switch or router, one of hosts share a single LAN or IP port on a switch or router, one of
those hosts may spoof the source addresses of other hosts within the those hosts may spoof the source addresses of other hosts within the
local subnet. Understanding these threats and the relevant local subnet. Understanding these threats and the relevant
topologies in which they're introduced is critical when assessing the topologies in which they're introduced is critical when assessing the
threats that exist with source address spoofing. threats that exist with source address spoofing.
This document provides additional details regarding spoofed-based This document provides additional details regarding spoofed-based
skipping to change at page 12, line 5 skipping to change at page 11, line 8
was received (while the individual system may be unknown, it is was received (while the individual system may be unknown, it is
reasonable to believe that the system is located in that part of reasonable to believe that the system is located in that part of
the network). the network).
Filtering points farther away from the source of the datagram can Filtering points farther away from the source of the datagram can
make decreasingly authoritative assertions about the validity of the make decreasingly authoritative assertions about the validity of the
source address in the datagram. Nonetheless, there is value in source address in the datagram. Nonetheless, there is value in
dropping traffic that is clearly inappropriate, and in maintaining dropping traffic that is clearly inappropriate, and in maintaining
knowledge of the level of trust one can place in an address. knowledge of the level of trust one can place in an address.
Edge Network 1 CPE-ISP _.------------. Edge Network 1 CPE-ISP _.------------.
_.----------------. Ingress/ ISP A `--. _.----------------. Ingress/ ISP A `--.
,--'' `---. ,' `. ,--'' `---. ,' `.
,' +----+ +------+ +------+ `. / +------+ +------+ \\ ,' +----+ +------+ +------+ `. / +------+ +------+ \\
( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | ) ( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | )
`. +----+ +------+ |Router| ,' \\ |Router| |Router| / `. +----+ +------+ |Router| ,' \\ |Router| |Router| /
`---. Host-neighbor +------+' `.+------+ +--+---+,' `---. Host-neighbor +------+' `.+------+ +--+---+,'
`----------------'' '--. |_.-' `----------------'' '--. |_.-'
`------------'| `------------'|
| |
Edge Network 2 ISP-ISP Ingress | Edge Network 2 ISP-ISP Ingress |
_.----------------. _.----------.| _.----------------. _.----------.|
,--'' `---. ,-'' |--. ,--'' `---. ,-'' |--.
,' +----+ +------+ +------+ `. ,+------+ +--+---+. ,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\ ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\
`. +----+ +------+ |Router| ,' ( |Router| |Router| ) `. +----+ +------+ |Router| ,' ( |Router| |Router| )
`---. +------+' \\ +------+ +------+ / `---. +------+' \\ +------+ +------+ /
`----------------'' `. ,' `----------------'' `. ,'
'--. ISP B _.-' '--. ISP B _.-'
`----------'' `----------''
Figure 1: Points where an address can be validated Figure 1: Points where an address can be validated
Figure 1 illustrates five related paths where a source address can be Figure 1 illustrates five related paths where a source address can be
validated: validated:
o host to switch, including host to host via the switch o host to switch, including host to host via the switch
o Host to enterprise CPE Router o Host to enterprise CPE Router
skipping to change at page 13, line 43 skipping to change at page 12, line 48
Other kinds of links may fall at different places in this spectrum, Other kinds of links may fall at different places in this spectrum,
with some wireless links having easier ways of identifying individual with some wireless links having easier ways of identifying individual
devices than others, for example. devices than others, for example.
4.1.2. Upstream Switches 4.1.2. Upstream Switches
In many topologies, there can be additional switches between the host In many topologies, there can be additional switches between the host
attached switch and the first router in the network. In these cases, attached switch and the first router in the network. In these cases,
additional issues can arise which affect SAVI operations. If the additional issues can arise which affect SAVI operations. If the
bridging topologies which connects the switches changes, or if LACP bridging topologies which connects the switches changes, or if LACP
[IEEE802.3ad] changes which links are used to deliver traffic, the [IEEE802.3ad], VRRP, or link management operations, change which
switch may need to move the SAVI state to a different port, are the links are used to deliver traffic, the switch may need to move the
state may need to be moved or reestablished on a different switch. SAVI state to a different port, or the state may need to be moved or
reestablished on a different switch.
4.1.3. Upstream Routers 4.1.3. Upstream Routers
Beyond the first hop router, subsequent routers may additionally Beyond the first hop router, subsequent routers may additionally
filter traffic from downstream networks. Because these routers do filter traffic from downstream networks. Because these routers do
not have access to the Link Layer address of the device from which not have access to the Link Layer address of the device from which
the datagram was sent, they are limited to confirming that the source the datagram was sent, they are limited to confirming that the source
IP address is within a prefix that is appropriate for downstream IP address is within a prefix that is appropriate for downstream
router from which the datagram was received. router from which the datagram was received.
skipping to change at page 18, line 28 skipping to change at page 17, line 35
filters that map Link Layer and Network Layer addresses on a specific filters that map Link Layer and Network Layer addresses on a specific
switch port might be a viable option. However, most networks, switch port might be a viable option. However, most networks,
certainly those that accommodate actual human users, are much more certainly those that accommodate actual human users, are much more
dynamic in nature. As such, mechanisms that provide port-MAC-IP dynamic in nature. As such, mechanisms that provide port-MAC-IP
bindings need to accommodate dynamic address allocation schemes bindings need to accommodate dynamic address allocation schemes
enabled by protocols such as DHCP, DHCPv6 for address allocation, and enabled by protocols such as DHCP, DHCPv6 for address allocation, and
IPv6 Stateless Address Autoconfiguration. IPv6 Stateless Address Autoconfiguration.
5.2. LAN devices with Multiple Addresses 5.2. LAN devices with Multiple Addresses
From a topology considerations perspective, when attempting From a topology considerations perspective, when attempting port-MAC-
port-MAC-IP bindings, hosts connected to switch ports that may have IP bindings, hosts connected to switch ports that may have one or
one or more IP addresses, or certainly, devices that forward packets more IP addresses, or certainly, devices that forward packets from
from other network segments, present traffic that is much harder to other network segments, present traffic that is much harder to make
make subject to such bindings and enforcement. subject to such bindings and enforcement.
5.2.1. Routers 5.2.1. Routers
The most obvious example of devices that are problematic when The most obvious example of devices that are problematic when
attempting to implement port-MAC-IP bindings is that of routers. attempting to implement port-MAC-IP bindings is that of routers.
Routers not only originate packets themselves and often have multiple Routers not only originate packets themselves and often have multiple
interfaces, but also forward packets from other network segments. As interfaces, but also forward packets from other network segments. As
a result, it's difficult for port-MAC-IP binding rules to be a result, it's difficult for port-MAC-IP binding rules to be
established a priori, because it's likely that many addresses and IP established a priori, because it's likely that many addresses and IP
subnets should be associated with the port-MAC in question. subnets should be associated with the port-MAC in question.
skipping to change at page 19, line 10 skipping to change at page 18, line 15
becomes problematic, for the same reasons as routers. Because they becomes problematic, for the same reasons as routers. Because they
may forward traffic from an array of address, a priori knowledge must may forward traffic from an array of address, a priori knowledge must
exist providing what IPs should be associated with a given port-MAC exist providing what IPs should be associated with a given port-MAC
pair. pair.
5.2.3. Multi-Instance Hosts 5.2.3. Multi-Instance Hosts
Another example that introduces complexities is that of multi- Another example that introduces complexities is that of multi-
instance hosts attached to a switch port. These are single physical instance hosts attached to a switch port. These are single physical
devices, which internally run multiple physical or logical hosts. devices, which internally run multiple physical or logical hosts.
When the device is a blade server, e.g. with internal blades each When the device is a blade server, e.g. with internal blades each
hosting a physical machine, there is essentially a physical switch hosting a physical machine, there is essentially a physical switch
inside the blade server. While tractable, this creates some inside the blade server. While tractable, this creates some
complexity for determining where enforcement logic can or should complexity for determining where enforcement logic can or should
live. live.
Logically distinct hosts such as are provided by many varieties of Logically distinct hosts such as are provided by many varieties of
virtualization logic result in a single physical host, connect to a virtualization logic result in a single physical host, connect to a
single port on the Ethernet switch in the topology, actually having single port on the Ethernet switch in the topology, actually having
multiple internal virtual machines, each with IP and MAC addresses, multiple internal virtual machines, each with IP and MAC addresses,
and what is essentially (or sometimes literally) an internal LAN and what is essentially (or sometimes literally) an internal LAN
skipping to change at page 19, line 33 skipping to change at page 18, line 38
other parts of the network, such enforcement cannot be counted on at other parts of the network, such enforcement cannot be counted on at
this time. this time.
A further complication with multi-instance hosts is that in many A further complication with multi-instance hosts is that in many
environments these hosts may move while retaining their IP addresses. environments these hosts may move while retaining their IP addresses.
This can be an actual relocation of the running software, or a backup This can be an actual relocation of the running software, or a backup
instance taking over the functions of the software. In both cases, instance taking over the functions of the software. In both cases,
the IP address will appear at a new topological location. Depending the IP address will appear at a new topological location. Depending
upon the protocols used, it may have the same MAC address or upon the protocols used, it may have the same MAC address or
different one, and the system may or may not issue a gratuitous ARP different one, and the system may or may not issue a gratuitous ARP
request after relocation. request after relocation. When such a move is done without changing
the MAC address, the SAVI switches will need to update their state.
While the ARP may be helpful, traffic detection, switch based
neighbor solicitation, interaction with orchestration system, or
other means may be used.
5.2.4. Multi-LAN Hosts 5.2.4. Multi-LAN Hosts
Multi-interface hosts, in particular those that are multi-homed and Multi-interface hosts, in particular those that are multi-homed and
may forward packets from any of a number of source addresses, can be may forward packets from any of a number of source addresses, can be
problematic as well. In particular, if a port-MAC-IP binding is made problematic as well. In particular, if a port-MAC-IP binding is made
on each of the interfaces, and then either a loopback IP or the on each of the interfaces, and then either a loopback IP or the
address of third interface is used as the source address of a packet address of third interface is used as the source address of a packet
forwarded through an interface for which the port-MAC-IP binding forwarded through an interface for which the port-MAC-IP binding
doesn't map, the traffic may be discarded. Static configuration of doesn't map, the traffic may be discarded. Static configuration of
skipping to change at page 23, line 40 skipping to change at page 23, line 4
of attribution also needs to allow for such cases. of attribution also needs to allow for such cases.
9. Acknowledgments 9. Acknowledgments
A portion of the primer text in this document came directly from A portion of the primer text in this document came directly from
[I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms. [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms.
Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola
for contributing text and a careful review of this document. for contributing text and a careful review of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
September 1981. 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
(IPv6) Specification", RFC 2460, December 1998. 6 (IPv6) Specification", RFC 2460, December 1998.
10.2. Informative References 10.2. Informative References
[I-D.baker-sava-operational] [I-D.baker-sava-operational]
Baker, F. and R. Droms, "IPv4/IPv6 Source Address Baker, F. and R. Droms, "IPv4/IPv6 Source Address
Verification", draft-baker-sava-operational-00 (work in Verification", draft-baker-sava-operational-00 (work in
progress), June 2007. progress), June 2007.
[IEEE802.3ad] [IEEE802.3ad]
Standards Association, IEEE., "IEEE 801.1AX-2008, IEEE Standards Association, IEEE., "IEEE 801.1AX-2008, IEEE
Standard for Local and Metropolitan Area Networks - Link Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2008. Aggregation", 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, 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", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
 End of changes. 17 change blocks. 
96 lines changed or deleted 101 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/