One document matched: draft-baker-sava-implementation-00.txt
Network Working Group F. Baker
Internet-Draft Cisco Systems
Intended status: Best Current November 6, 2007
Practice
Expires: May 9, 2008
Source address validation in the local environment
draft-baker-sava-implementation-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This note describes how Source Address Validation might be applied in
an IPv6 environment. Local systems should be able to ensure that
their peers are using the IPv6 source addresses that the routing
system uses to deliver data to them. Remote systems should be able
to ensure that traffic they forward has reasonable source addresses.
Baker Expires May 9, 2008 [Page 1]
Internet-Draft Verifying host address usage November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Local Source Address Validation for IPv4 . . . . . . . . . 3
1.2. Local Source Address Validation for IPv6 . . . . . . . . . 4
1.3. Defense in depth . . . . . . . . . . . . . . . . . . . . . 4
2. Implementating Source Address Validation in the local
environment . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Trust anchors . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Host and Router validation of the addresses of
neighboring systems . . . . . . . . . . . . . . . . . . . 6
2.3. Validation of the addresses of neighboring systems by
a switch . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Implementating Source Address Validation for remote systems . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Summary of recommendations . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Baker Expires May 9, 2008 [Page 2]
Internet-Draft Verifying host address usage November 2007
1. Introduction
This note describes how Source Address Validation might be applied in
an IPv6 [RFC2460] environment by a an IP host or router, or lower
layer switch directly connected to the source system. Local systems,
the hosts and routers directly connected to a neighbor system, should
be able to ensure that their peers are using the IPv6 source
addresses that the routing system uses to deliver data to them.
Remote systems cannot ensure the exact matching of addresses, but can
determine whether the source address is reasonable. The
recommendations of this specification are based on experience with
such features that are currently available for IPv4 [RFC0791] from
multiple vendors.
This is in support of the requirements of [RFC2827], which recommends
that networks defend themselves from spoofed traffic by dropping
traffic that clearly has spoofed source addresses. The place this is
usually implemented, the ISP ingress router, is an excellent second
line of defense and very appropriate for defending the ISP. However,
the only system that can definitively stop traffic from errant hosts
is the systems they directly communicate with - their LAN switches,
hosts that they are the immediate neighbors of, and their first hop
routers. This note specifies that first line of defense.
The purpose of Source Address Validation is to ensure that a system
in the network sends only datagrams that can be replied to -
datagrams that the routing system will deliver to that host and which
the host will recognize as having been directed to it. This is the
first part is isolating a denial of service attack; the second step
is to identify systems sending attack traffic and remove their
traffic from the network.
1.1. Local Source Address Validation for IPv4
In IPv4, datagrams generally come from the address that has been
assigned to an interface, so it is sufficient to determine "the"
address and discard traffic that comes from other addresses. There
are some caveats: multi-LAN hosts may reply to a request using the
address of one interface but sending the datagram out another, and
routers forward traffic from a myriad of addresses. But such systems
can be treated as special cases and excluded from source address
validation.
As such, switch implementations of source address validation
technology observe DHCP [RFC2131] assignments of addresses to hosts
and drop host-originated datagrams using other source addresses.
Neighboring hosts or routers may similarly only store one associated
IP address for each MAC address, but this is more frequently a bug or
Baker Expires May 9, 2008 [Page 3]
Internet-Draft Verifying host address usage November 2007
side-effect of implementation than something well thought through,
and may not operate as well as one would like.
1.2. Local Source Address Validation for IPv6
In an IPv6 network, the problem is somewhat more complicated than it
is in an IPv4 network. As with IPv4, there are some caveats: multi-
LAN hosts may reply to a request using the address of one interface
but sending the datagram out another, and routers forward traffic
from a myriad of addresses. But such systems can be treated as
special cases and excluded from source address validation.
The issue that complicates IPv6 is that each interface potentially
has many addresses, and a single prefix may straddle multiple
physical interfaces. It will generally have at least two: its link-
local address and its address in the local prefix. There may,
however, be multiple local prefixes, and with privacy addressing
[RFC4941] there may be multiple legitimate addresses within the same
prefix. So the mapping is not one-to-one, but rather one-to-many.
The system verifying the address usage must carry the interface
identification, in whatever form it may hold that, as an attribute of
the IPv6 address, and verify that a datagram using a given IPv6
source address comes from the appropriate source.
1.3. Defense in depth
There is also a place for ingress filtering by prefix, usually
accomplished via Unicast Reverse Path Forwarding or via filters. In
general, this is performed between administrations - at the interface
between peer ISPs, an ISP and its customer, or between two networks
of another type. In concept, however, it could be applied on every
router in a network. This will be discussed in Section 3.
2. Implementating Source Address Validation in the local environment
This section will describe in general terms a common approach to
source address validation between two directly connected systems.
Addresses are allocated to systems in two ways in IPv6: DHCP
[RFC3315], Stateless Address Autoconfiguration [RFC4862]. These
addresses are exchanged with a system's neighbors using either
Neighbor Discovery [RFC4861], or for Cryptographically Generated
Addresses [RFC3972], SEcure Neighbor Discovery [RFC3971]. Each of
these will be looked at.
Baker Expires May 9, 2008 [Page 4]
Internet-Draft Verifying host address usage November 2007
2.1. Trust anchors
In short, the implementation approach requires neighboring devices to
associate a layer 3 entity addressed with an IPv6 address with a
layer 2 entity. The identification of the layer 2 entity may take a
number of forms:
o On a traditional Ethernet or for a host or router attached to a
switched Ethernet, the only real option is association with the
MAC Address.
o The switch, however, may be able to associate the IPv6 address
with a switch port if it knows that only one host is attached to
the port.
o In a wireless network, there are often layer 2 security
associations between neighboring devices, and the address can be
associated with that security association.
o In a Cable Modem network, the address may be associated with the
combination of a MAC address and a customer relationship.
o In a classical DSL network, it may be associated with an ATM
Virtual Channel, or a PPPoE or L2TP Session ID.
o In some cases, an IP/IP tunnel, an MPLS LSP, or similar tunneling
technology is taken to a single system. In such cases, local
address validation can be applied to the use of the tunnel.
The key is to have a solid understanding of
o what identifies a neighbor in the context: a MAC Address, a switch
port, an ATM VC, or whatever,
o what addresses one's neighbor is in fact using, and
o to limit what one accepts from the neighbor as so identified to
that which the neighbor is legitimately using.
One could argue that this runs counter to the Robustness Principle,
which is stated in RFC 793 as "be conservative in what you do, be
liberal in what you accept from others." In fact, it follows the
Robustness Principle, but adds the Russian proverb made famous in the
west by Ronald Reagan: "Trust, but verify".
Baker Expires May 9, 2008 [Page 5]
Internet-Draft Verifying host address usage November 2007
2.2. Host and Router validation of the addresses of neighboring systems
Since a peer's neighbors are intended to learn its address using
Neighbor Discovery or Secure Neighbor Discovery, they should look
there. If one system sends a datagram to a host or router on the
same LAN or otherwise directly connected and the receiving system
does not know the address to have been associated with the system
that sent it, both of these protocols ask the receiver to query the
sender using a Neighbor Solicit. Generally, this is done when
sending the reply - the Neighbor Solicit and responding Neighbor
Advertisement must be exchanged to send the application reply.
This specification recommends that, to protect hosts from attack
traffic and prevent routers from forwarding datagrams with spoofed
addresses, the NS/NA exchange SHOULD happen before the received
datagram is operated on.
There are two schools of thought on the holding of the datagram; one
holds that the host or router should hold the datagram in a short
queue and release it on receipt of the NA, and one holds that the
receiver may force the sender to retransmit it. As either approach
may be viewed as an attack (a sender spewing datagrams with spoofed
addresses may clog its neighbors with traffic, and an application
being forced to retransmit experiences a user-observable delay), this
specification takes no position on that matter. The receiver MAY
hold the datagram in a short queue to be operated on when the NA
arrives, and it MAY discard it.
Given this model, there is a potential front-running attack on
Stateless Address Autoconfiguration. When one system enters the
Duplicate Address Detection phase, another system could see the
address being verified and immediately send a message (perhaps an
ICMP Echo Request sent as a link layer multicast) claiming the
address. The systems that receive it would respond with a Neighbor
Solicit, it would reply with a Neighbor Advertisement, and the
original system would be denied the use of the address. As such,
systems observing an address that they have no association for being
verified using Duplicate Address Detection SHOULD NOT then grant it
to another system.
As noted, in IPv6 networks hosts and routers usually have multiple
addresses on any given interface. There is a potential attack in
this as well: especially with privacy addressing, one could imagine a
host using a new address for each TCP or SCTP session it opens, and
one could imagine an attack that simulates this but simply fills its
neighbor's tables with addresses. A host or router MAY (eg, is
authorized to) limit the number of addresses for a neighbor that it
will simultaneously hold, and the number of addresses considered
Baker Expires May 9, 2008 [Page 6]
Internet-Draft Verifying host address usage November 2007
reasonable is intentionally not specified. It SHOULD use memory
allocated to that function in a Least Recently Used fashion,
preserving recollection of addresses a neighbor is actually using and
reusing table entries that appear to be unused.
As noted in Section 1.2, caveats that make this difficult include any
system that might send a datagram from an address unknown in the
local environment. These include, but are not limited to, routers
and any middleware that behaves like a router, in that it forwards
datagrams originated by other systems using their source addresses,
and multi-LAN hosts. To simplify source address validation, this
specification declares that a host SHOULD send any datagram it
originates on an interface the source address is associated with.
Routers and router-like middleware such as firewalls must be exlcuded
from such analysis.
2.3. Validation of the addresses of neighboring systems by a switch
In this context, a "switch" refers to a system that switches messages
for any lower layer protocol. Examples include Ethernet, ATM, Cable
Modem, DSL, and so on.
As with IPv4, it is reasonable for a switch to simply observe the
Neighbor Advertisements issued by a host or router and note that the
host or router may be using them. There is a potential attack in
this, however, in that a host could simply spew Neighbor
Advertisements. For this reason, the protocol calls for a Neighbor
Advertisement to be in response to a Neighbor Solicit. Therefore, a
switch implementation that observes Neighbor Discovery or Secure
Neighbor Discovery SHOULD remember addresses from Neighbor
Advertisement only if it has seen a prior Neighbor Solicit.
A switch MAY observe DHCP assignments of addresses to hosts and drop
host-originated datagrams using other source addresses. If it does,
it SHOULD be prepared to accept multiple simultaneous assignments.
A switch or upstream router MAY also observe assignments of prefixes
to downstream routers using the DHCP Prefix Assignment Options
[RFC3633], and use that information to configure ingress prefix
filtering.
As with host implementations, a switch MAY limit the number of
addresses it will simultaneously store. If it does so, it SHOULD use
memory allocated to that function in a Least Recently Used fashion,
preserving recollection of addresses a neighbor is actually using and
reusing table entries that appear to be unused.
Baker Expires May 9, 2008 [Page 7]
Internet-Draft Verifying host address usage November 2007
3. Implementating Source Address Validation for remote systems
As mentioned, it is often in an administration's interest to protect
itself from other administrations, which may have inadequate anti-
spoofing measures in place. This is the original thrust of BCP 38
[RFC2827]. Unfortunately, one step removed from the source system,
there is no anchor to verify that the address is exactly correct;
rather, one can only verify that it is reasonable - it is within the
prefix.
It has been argued that this is nonsensical, as anti-spoofing
procedures impose additional router processing and only protect other
networks. This is incorrect, however, for two reasons. Modern
routers often implement filtering or Unicast Reverse Path Forwarding
procedures in hardware, minimizing the processing burden, although
the differentiated tables may consume memory. In any event, attacks
perpetrated from a downstream network (obscured in some cases by
address spoofing) attack both the administration's network and the
administration's customers. Dealing with that problem is generally
the first step in side-stepping an attack.
To implement, a router MAY be configured to discard traffic that
routing believes is coming from an inappropriate direction. This
does not depend on the router's choice of routes, however; it depends
on the routing calculated by a router's neighbors. As such, if
router A validly advertises to router B that it can route traffic to
a prefix, the router B SHOULD accept traffic from that prefix via
router A.
The determination of when a routing advertisement is valid is beyond
the scope of this specification.
4. IANA Considerations
This memo adds no new IANA considerations.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during
the RFC publication process. From the author's perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
5. Security Considerations
This note describes a set of security considerations for the IPv6
Baker Expires May 9, 2008 [Page 8]
Internet-Draft Verifying host address usage November 2007
Internet, specifically related to attack management in IPv6 [RFC2460]
and in the configuration and communication mechanisms of Stateless
Address Autoconfiguration [RFC4862], Neighbor Discovery [RFC4861],
and SEcure Neighbor Discovery [RFC3971]. It does not introduce new
attacks, but it identifies some existing ones and recommends
approaches to their mitigation.
6. Contributors
This document was developed in the SAVA context. Contributors
include the author, Christian Vogt, Gang Ren, Hannes Tschofenig, Jari
Arkko, Jianping Wu, Jun Bi, Ke Xu, and Pekka Savola.
7. References
7.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
Baker Expires May 9, 2008 [Page 9]
Internet-Draft Verifying host address usage November 2007
7.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
Appendix A. Summary of recommendations
1. The NS/NA exchange on a response to a received datagram SHOULD
happen before the received datagram is operated on.
2. The receiver MAY hold the triggering datagram in a short queue
to be operated on when the NA arrives, and it MAY discard it.
3. Systems observing an address that they have no association for
being verified using Duplicate Address Detection SHOULD NOT then
grant it to another system.
4. A host or router MAY (eg, is authorized to) limit the number of
addresses for a neighbor that it will simultaneously hold, and
the number of addresses considered.
5. It SHOULD use memory allocated to that function in a Least
Recently Used fashion, preserving recollection of addresses a
neighbor is actually using and reusing table entries that appear
to be unused.
6. To simplify source address validation, this specification
declares that a host SHOULD send any datagram it originates on
an interface the source address is associated with.
7. A switch that monitors Neighbor Discovery or Secure Neighbor
Discovery SHOULD remember addresses from Neighbor Advertisement
only if it has seen a prior Neighbor Solicit.
8. A switch MAY observe DHCP assignments of addresses to hosts and
drop host-originated datagrams using other source addresses.
9. If it does, it SHOULD be prepared to accept multiple
simultaneous assignments.
Baker Expires May 9, 2008 [Page 10]
Internet-Draft Verifying host address usage November 2007
10. A switch or upstream router MAY also observe assignments of
prefixes to downstream routers using the DHCP Prefix Assignment
Options [RFC3633], and use that information to configure ingress
prefix filtering.
11. A switch MAY limit the number of addresses it will
simultaneously store.
12. If it does so, it SHOULD use memory allocated to that function
in a Least Recently Used fashion, preserving recollection of
addresses a neighbor is actually using and reusing table entries
that appear to be unused.
13. A router MAY discard traffic that routing believes is coming
from an inappropriate direction.
14. If router A validly advertises to router B that it can route
traffic to a prefix, the router B SHOULD accept traffic from
that prefix via router A.
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Email: fred@cisco.com
Baker Expires May 9, 2008 [Page 11]
Internet-Draft Verifying host address usage November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Baker Expires May 9, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 13:29:35 |