Source Address Validation F. Baker
Architecture R. Droms
Internet-Draft Cisco Systems
Intended status: Best Current June 18, 2007
Practice
Expires: December 20, 2007
IPv4/IPv6 Source Address Verification
draft-baker-sava-operational-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 December 20, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This note proposes a practical solution to Internet Layer Source
Address Verification. The purpose of such verification is to prevent
attacks from using spoofed addresses and to facilitate the tracking
of attack datagrams to the computers that send them.
Baker & Droms Expires December 20, 2007 [Page 1]
Internet-Draft Source Address Verification June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. On attacks and attack management . . . . . . . . . . . . . 3
1.2. On Trust . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Eliminating spoofed addresses in the Internet . . . . . . . . 5
2.1. Host to link layer neighbor or switch . . . . . . . . . . 7
2.2. Upstream routers . . . . . . . . . . . . . . . . . . . . . 7
2.3. ISP edge PE Router . . . . . . . . . . . . . . . . . . . . 8
2.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . . . 8
3. Verification and Accountability . . . . . . . . . . . . . . . 8
4. Encouraging customer use of antispoofing procedures . . . . . 9
5. Accommodating incremental deployment . . . . . . . . . . . . . 9
5.1. ISP PE Router to CPE delivery point . . . . . . . . . . . 10
5.2. ISP filtering under attack . . . . . . . . . . . . . . . . 10
6. Identified Addresses in the Internet . . . . . . . . . . . . . 10
6.1. Identified addresses in edge networks . . . . . . . . . . 11
6.1.1. IEEE802.1X . . . . . . . . . . . . . . . . . . . . . . 11
6.1.2. IPv4 Address Resolution Protocol . . . . . . . . . . . 12
6.1.3. IPv6 Neighbor Discovery . . . . . . . . . . . . . . . 12
6.1.4. IPv4 and IPv6 Dynamic Host Configuration Protocol . . 13
6.1.5. Protocol for Carrying Authentication for Network
Access . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Identified addresses in a global domain . . . . . . . . . 13
6.3. On source addresses . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Baker & Droms Expires December 20, 2007 [Page 2]
Internet-Draft Source Address Verification June 2007
1. Introduction
This note proposes a practical solution to Internet Layer (which is
to say IPv4 [RFC0791] and IPv6 [RFC2460]) source address
verification. The purpose of such verification is to prevent attacks
from using spoofed addresses and to facilitate the tracking of attack
datagrams to the computers that send them. The source address
verification problem is proposed and motivated in other papers on
this topic [I-D.sava-problem-statement].
There are three contributions in this document. The first is a
compilation of mechanisms available for source address verification
at various points in the Internet, and an informal analysis of the
confidence in the verification for each of those mechanisms. The
second is the notion that source address verification can be
negotiated between Internet entities based on this confidence in the
source address verification mechanisms, and how source address
verification can be used to accomplish goals such as attack avoidance
and accountability for attacks. The third contribution is a way to
incorporate source address verification into the Internet without
requiring ubiquitous adoption of source address verification
mechanisms.
1.1. On attacks and attack management
The fundamental purpose of source address verification is the
management of attacks. Attacks come in many forms, from malicious
activities such as denial of service or service disruption, to more
subtle forms of theft, to limiting the provision of service to one's
customers or clients. Source address verification can be used in two
ways to manage attacks: to detect and reject IP datagrams with
incorrect ('spoofed') source addresses, which cannot guide a response
to a datagram to the system that sent it; and, to establish
accountability for attacks using IP datagrams with valid source
addresses.
The principal mode of attack in which a datagram with a spoofed
source address is used is a single datagram attack; it is possible to
spoof an address for the first exchange or a random exchange in a TCP
session (as is done in TCP SYN and RST attacks), but given that
nothing is known of how a peer replies to a datagram that was sent
from a spoofed address, the further into such a session one goes the
more difficult it is to maintain the illusion of coherence.
Therefore, the first requirement is that the first datagram in a
session have its address validated, and datagrams that fail this
verification are ignored or dropped.
IT administrations want to be able to track a datagram to its source.
Baker & Droms Expires December 20, 2007 [Page 3]
Internet-Draft Source Address Verification June 2007
Reasons include isolating the zombie sources of an attack, or
tracking malicious behavior to the user of a system. Removing IP
datagrams with spoofed source addresses ensures that the remaining
datagrams can be reliably traced back to their source.
This note will not go on to generalized attack management. Other
papers, notably [I-D.ietf-idr-bgp-prefix-orf], and [RFC4778] address
this; the matter will be left with them.
1.2. On Trust
Trust, in the Internet, is very much about relationships. Two
companies or two parties that do not know each other may provide
minimal services, such as access to a web page, but do not rely on
each other. However, if a satisfactory relationship can be
established, limited levels of trust are extended. For example, an
ISP that contracts with its customer or another ISP to exchange BGP
routing will open the session and advertise and accept routes. The
ISP will also limit the routes it accepts (and therefore the trust it
extends) to those specified in the agreement. Similarly, the group
that administers an enterprise network is often different from the
group that manages the company's end systems. The level of trust
between an enterprise network and the end systems it services is
often similarly limited; the end systems are viewed as liabilities as
much as they are clients.
This document is about the management of trust, and the level of
trust that can be extended to a system that originates IP datagrams
at the network layer. This trust differs from session trust, in
which a user logs in to a remote system or service, but the two can
be used together to accomplish useful things. Section 2.4 describes
a method through which parties in the Internet such as service
providers can negotiate the level of trust they are willing to assume
in their exchange of Internet traffic. This method provides a
practical way in which source address verification can be deployed
and used in the Internet.
1.3. Glossary
The following acronyms are used in this document:
BGP: The Border Gateway Protocol, used to manage routing policy
between large networks.
CPE Router: Customer Premises Equipment Router. The router on the
customer premises, whether owned by the customer or the provider.
Also called the Customer Endpoint, or CE, Router.
Baker & Droms Expires December 20, 2007 [Page 4]
Internet-Draft Source Address Verification June 2007
IP Address: An Internet Protocol Address, whether IPv4 or IPv6.
ISP: Internet Service Provider. Any person or company that delivers
Internet service to another.
MAC Address: An Ethernet Address.
NNI Router: Network to Network Interface Router. This router
interface faces a similar system operated by another ISP or other
large network.
PE Router: Provider Endpoint Router. This router faces a customer
of an ISP.
TCP: The Transmission Control Protocol, used on end systems to
manage data exchange.
uRPF: Unicast Reverse Path Forwarding. A procedure in which the
route table, which is usually used to look up destination
addresses and route towards them, is used to look up the source
address and ensure that one is routing away from it. When this
test fails, the event may be logged, and the traffic is commonly
dropped.
2. Eliminating spoofed addresses in the Internet
The first requirement is to eliminate datagrams with spoofed
addresses from the Internet. Identifying and dropping datagrams
whose source address is incompatible with the Internet topology at
sites where the relationship between the source address and topology
can be checked can eliminate such datagrams. For example, Internet
devices can confirm that:
o The IP source address is appropriate for the lower layer address
(they both identify the same system)
o The IP source address is appropriate for the device at the layer 2
switch port (the address was assigned to a, and perhaps the,
system that uses that port)
o The prefix to which the IP source address belongs is appropriate
for the part of the network topology from which the IP datagram
was received (while the individual system may be unknown, it is
reasonable to believe that the system is located in that part of
the network).
Filtering points farther away from the source of the datagram can
Baker & Droms Expires December 20, 2007 [Page 5]
Internet-Draft Source Address Verification June 2007
make decreasingly authoritative assertions about the validity of the
source address in the datagram. Nonetheless, there is value in
dropping traffic that is clearly inappropriate, and in maintaining
knowledge of the level of trust one can place in an address.
Edge Network 1 CPE-ISP _.------------.
_.----------------. Ingress/ ISP A `--.
,--'' `---. ,' `.
,' +----+ +------+ +------+ `. / +------+ +------+ \
( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | )
`. +----+ +------+ |Router| ,' \ |Router| |Router| /
`---. Host-neighbor +------+' `.+------+ +--+---+,'
`----------------'' '--. |_.-'
`------------'|
|
Edge Network 2 ISP-ISP Ingress |
_.----------------. _.----------.|
,--'' `---. ,-'' |--.
,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \
`. +----+ +------+ |Router| ,' ( |Router| |Router| )
`---. +------+' \ +------+ +------+ /
`----------------'' `. ,'
'--. ISP B _.-'
`----------''
Figure 1: Figure 1: Points where an address can be validated
Figure 1 illustrates five places where a source address can be
validated:
o Host to host or host to switch,
o Host to enterprise CPE Router,
o Enterprise CPE Router to ISP edge PE Router,
o ISP NNI Router to ISP NNI Router, and the
o ISP edge PE Router facing the destination CPE Router.
In general, datagrams with spoofed addresses can be detected and
discarded by devices that have an authoritative mapping between IP
addresses and the network topology. For example, a device that has
an authoritative table between layer 2 and IP addresses on a link can
discard any datagrams in which the IP address is not associated with
(and is therefore assumed to be spoofed) the layer 2 address in the
datagram. The degree of confidence in the source address depends on
Baker & Droms Expires December 20, 2007 [Page 6]
Internet-Draft Source Address Verification June 2007
where the spoofing detection is performed and the prefix aggregation
in place between the spoofing detection and the source of the
datagram. The means of building such an authoritative mapping is
discussed further in Section 6.1.
2.1. Host to link layer neighbor or switch
The first point at which a datagram with a spoofed address can be
detected is on the link to which the source of the datagram is
connected. At this point in the network, the source layer 2 and IP
addresses are both available, and can be verified against each other.
A datagram in which the IP source address does not match the
corresponding lower layer address can be discarded. Of course, the
trust in the filtering depends on the trust in the method through
which the mappings are developed. This mechanism can be applied by
neighboring hosts, or by the first hop router.
On a shared medium link, the best that can be done is to verify the
layer 2 and IP addresses against the mappings. When the link is not
shared, such as when the hosts are connected through a switch, the
source host can be identified precisely based on the port through
which the datagram is received or the MAC address if it is known to
the switch. Port identification precludes transmission of malicious
datagrams whose layer 2 and IP addresses are both spoofed to mimic
another host.
2.2. Upstream routers
After the first hop router, which can use the mechanism described in
Section 2.1 to filter datagrams, subsequent routers may additionally
filter traffic from downstream networks. Because these routers do
not have access to the layer 2 address of the device from which the
datagram was sent, they are limited to confirming that the source IP
address is within a prefix that is appropriate for downstream router
from which the datagram was received.
Options include the use of simple access lists or the use of unicast
reverse path filtering (uRPF). Access lists are generally
appropriate only for the simplest cases, as management can be
difficult. Unicast RPF accepts the source address on a datagram if
and only if it comes from a direction that would be rational to send
a datagram directed to the address, which means that the filter is
derived from routing. These filtering procedures are discussed in
more detail in [RFC3704].
Baker & Droms Expires December 20, 2007 [Page 7]
Internet-Draft Source Address Verification June 2007
2.3. ISP edge PE Router
An obvious special case of the discussion in Section 2.2 is an ISP PE
router, where it provides its customer with access. [RFC2827]
specifically encourages ISPs to use ingress filtering to limit the
incidence of spoofed addresses in the network.
The question that the ISP must answer for itself is the degree to
which it trusts its downstream network. Appropriate answers include
'not at all' and 'enough to only need to verify compliance'. A
contract might be written between an ISP and its customer requiring
that the customer apply the procedures of Section 2.1 the customer's
own network. ISPs might, for example, mark datagrams from customers
that do not sign such a contract or demonstrably do not behave in
accordance with it as 'untrusted'. Alternatively, the ISP might
place untrusted prefixes into a separate BGP community and use that
to advertise the level of trust to its BGP peers.
2.4. ISP NNI Router to ISP NNI Router
The considerations of Section 2.3, which are explicitly related to
customer networks, can also be applied to neighboring ISPs. A
contract might be written between the companies that the companies
will require the procedures of Section 2.1 of their customers and
apply them within their own network. ISPs might, for example, mark
datagrams from neighboring ISPs that do not sign such a contract or
demonstrably do not behave in accordance with it as 'untrusted'.
Alternatively, the ISP might place untrusted prefixes into a separate
BGP community and use that to advertise the level of trust to its BGP
peers.
In this case, uRPF is less effective as a verification tool, due to
asymmetric routing. However, when it can be shown that spoofed
addresses are present, the procedure can be applied.
3. Verification and Accountability
Assuming filtering as above has been implemented, the origin of
malicious IP datagrams can be determined. Within an organization or
administrative domain, the details of where and how filtering is
applied provide accountability and can be used to trace the origin of
malicious datagrams back to the ultimate source or some region of the
network. Between organizations or administrative domains, the
agreement in place between organizations allows an entity that
detects malicious traffic to assign responsibility for the origin of
that traffic.
Baker & Droms Expires December 20, 2007 [Page 8]
Internet-Draft Source Address Verification June 2007
The use of formal agreements between organizations is discussed in
more detail in Section 4
4. Encouraging customer use of antispoofing procedures
As discussed in Section 1.2, the only operational circumstance in
which an ISP can be said to trust its downstream is if it has an
understanding (usually formalized in a contract) with the downstream
regarding a matter. For example, an ISP that opens a BGP session
with a downstream trusts the routes that the downstream presents it.
The ISP may limit this trust, however, by verifying that the prefixes
advertised by the downstream are appropriate for it to advertise.
One might characterize this kind of relationship as 'trust but
verify'.
In the case of anti-spoofing procedures, an ISP might include in its
service contract a provision that the customer agrees to use the
procedures in Section 2.1, and where appropriate Section 2.2, to
eliminate address spoofing. In this example of a contractual
arrangement, the type of source address verification is specified in
the service contract, and the customer implements those source
address verification mechanisms. The ISP then verifies compliance
using uRPF or other audits, and applies a penalty when the procedure
results in the ISP dropping traffic. The penalty could be monetary,
operational, or both.
Peer ISPs can develop a somewhat different form of service contract,
in which each ISP guarantees that it will identify traffic or the
source prefixes of customers have not implemented source address
verification, and that the ISPs have implemented the appropriate
checks to confirm that verification.
5. Accommodating incremental deployment
In the Internet, new technologies are inevitably deployed
incrementally. Source address verification is no exception. This
incremental deployment is problematic in the case of source address
verification, in that aggregated traffic flows include both verified
and unverified traffic. But simply dropping unverified traffic is
unacceptable, as it prevents any form of incremental deployment.
What is needed is a way to aggregate and deliver verified and
unverified traffic, while retaining the ability to differentiate
between those two types of traffic.
Baker & Droms Expires December 20, 2007 [Page 9]
Internet-Draft Source Address Verification June 2007
5.1. ISP PE Router to CPE delivery point
A simple operational differentiation that can be applied to traffic
from untrusted downstream networks (those who have not signed a
contract such as described in Section 4, or who are demonstrably not
in compliance with it) is to mark traffic from them as 'untrusted'.
A simple approach would use a DSCP value [RFC2474] indicating that
the datagram is from an untrusted source and therefore potentially
contains a spoofed source address.
The ultimate use of the 'Untrusted' DSCP value is at choke points in
the infrastructure, usually at network egress. Denial of Service
attacks using spoofed addresses often target choke points. By
classifying untrusted traffic and running it through a queue of lower
priority or rate, one can preserve the services of trusted senders,
and squeeze out potentially-spoofed traffic.
Thus, the use of the 'Untrusted' DSCP value both denies the untrusted
user the enjoyment of network services end to end and permits
prejudicial classification to give them distinctly poor service when
they are potentially part of an attack. This, along with monetary
incentives, incents them both to become trusted and trustworthy
communication partners.
5.2. ISP filtering under attack
Another approach, if the prefixes of untrusted sources are advertised
between ISPs using an appropriate BGP community, would be for a
network under attack (or whose customers are under attack) to
temporarily block untrusted prefixes and then add them back
piecemeal. If the attack is sourced from an untrusted prefix,
dropping the traffic will protect against the attack, and upon
restoration of the prefix the attack should again be observable.
This obviously only works as described with continuous attacks, but
it can be helpful in isolating punctuated attacks as well.
6. Identified Addresses in the Internet
The document Internet Architectural Guidelines [RFC3439] focuses on a
number of principles that have been used to beneficial effect in the
design of the Internet. An important one is the Simplicity
Principle, which asserts that complexity is the primary factor that
limits the ability of a system to scale to large populations.
Another is the Coupling Principle, which is borrowed from Information
Theory and asserts that as systems get larger, they often exhibit
increased interdependence (coupling) between components.
Baker & Droms Expires December 20, 2007 [Page 10]
Internet-Draft Source Address Verification June 2007
The design principle that has fostered the economic vitality of the
Internet is the localization of information on a 'need to know'
basis, with a view to limiting unnecessary complexity and
interaction. In this context, making the Internet scale to large
numbers of users calls on us to limit knowledge of individual users
to the organizations they are part of, and to limit knowledge of
individual systems to the networks in which they reside. In other
networks within the Internet system, we scale the Internet by
carrying knowledge of the networks, or of important characteristics
of relationships such as whether a user or system is trusted or not.
As such, we divide the problem of address identification into two
parts: identification of a user within the network that provides him
service, whether that is an enterprise network, residential ISP, or
other network, and the identification of other networks.
6.1. Identified addresses in edge networks
A common IT requirement is for an enterprise or residential ISP to
restrict service to its authorized users or customers. Numerous
procedures have been used for this, such as DHCP Authentication and
the definition of names in carried in DHCP requests. While any
adequate user management system could be used by the enterprise, at
this point the state of the art appears to be the use of IEEE 802.1X
access control, which associates a user with a MAC address and can be
used with IPv4 or IPv6.
6.1.1. IEEE802.1X
IEEE 802.1X [IEEE802.1X] is an IEEE standard for port-based Network
Access Control; it is part of the IEEE 802 (802.1) group of
protocols. It provides authentication to devices attached to a LAN
port or wireless access point, establishing a point-to-point
connection or preventing access from that port if authentication
fails.
802.1X is available on network switches, and can be configured to
authenticate hosts that are equipped with supplicant software,
denying unauthorized access to the network at the data link layer.
On wireless access points, 802.1X can be used in certain situations
where an access point needs to be operated as a closed access point.
The authentication is usually done by a third-party entity, such as a
RADIUS server. This provides for client-only authentication, or more
appropriately, strong mutual authentication using protocols such as
EAP-TLS [RFC3748].
Upon detection of the new client (supplicant), the port on the switch
Baker & Droms Expires December 20, 2007 [Page 11]
Internet-Draft Source Address Verification June 2007
(authenticator) will be enabled and set to the 'unauthorized' state.
In this state, only 802.1X traffic will be allowed; other traffic,
such as DHCP and HTTP, will be blocked at the data link layer. The
authenticator sends the EAP-Request identity to the supplicant, to
which the supplicant replies using the EAP-Response datagram that the
authenticator will forward to the authenticating server. The
authenticating server can accept or reject the EAP-Request; if it
accepts the request, the authenticator will set the port to the
'authorized' state and normal traffic will be allowed. The
supplicant logs off by sending an EAP-Logoff message to the
authenticator. The authenticator will then set the port to the
'unauthorized' state, once again blocking all non-EAP traffic.
The effect of such mutual authentication is two-fold. First, the
network (wired or wireless) can determine whether a person that is
seeking attachment of his system is authorized to do so. Also, the
person's computer can determine whether the point of attachment is a
rogue access point or is in fact the network it intends to enter. As
a side-effect of such authentication and authorization, server logs
can be scanned at any time to determine what user was associated with
any given system or MAC address and what IP (version 4 or 6)
addresses are in use by those same MAC addresses, or such information
can be logged in a search database for forensic purposes.
6.1.2. IPv4 Address Resolution Protocol
ARP [RFC0826] carries mappings between layer 2 and IP addresses,
which can be used by nodes to construct a table of associations
between layer 2 and IP addresses for other nodes on the same link. A
switch can intercept and examine ARP traffic as well to determine the
layer 2 and IP addresses of nodes attached to its ports.
However, as ARP is not secured in any way, the associations learned
through ARP are not highly trustable. It is easy to construct ARP
messages that can alter the ARP tables in nodes so the source
addresses in a datagram appear to be valid.
6.1.3. IPv6 Neighbor Discovery
The Neighbor Discovery protocol [RFC2461] (ND), which is part of the
IPv6 protocol suite, provides address resolution functions and
supports address assignment. In much the same way as ARP can be used
to learn associations between layer 2 and IPv4 addresses, the
contents of ND messages can be used to learn associations between
layer 2 and IPv6 addresses.
SEcure Neighbor Discovery [RFC3971] (SEND) can be used to
authenticate the associations between layer 2 and IPv6 addresses.
Baker & Droms Expires December 20, 2007 [Page 12]
Internet-Draft Source Address Verification June 2007
6.1.4. IPv4 and IPv6 Dynamic Host Configuration Protocol
DHCP [RFC2131][RFC3315] can also be used to learn associations
between layer 2 and IPv4 or IPv6 addresses. In this method, network
elements that actively transmit DHCP messages ('DHCP relay agents';
typically a router) or forward DHCP messages (switches) between a
DHCP server and hosts examine the contents of the DHCP messages and
extract the associations between the layer 2 and IPv4 or IPv6 for
hosts. The layer 2 and IP addresses are contained in or can be
deduced from the forwarded DHCP messages. In many situations, the
network path between the router/switch and the DHCP server is secure,
so the information extracted from the DHCP messages is considered
more reliable than information taken from ARP or ND.
6.1.5. Protocol for Carrying Authentication for Network Access
PANA [I-D.ietf-pana-pana] is related to IEEE802.1X, in that it
authenticates the identity of a user and uses that authenticated
identity to authenticate the association between a layer 2 address
and an IP address. PANA differs from IEEE802.1X in that it is
carried as a layer 4 protocol, and can be used across intermediate
network elements to an authenticating device. As a side effect of
PANA authentication, the authenticating device can derive a layer 2
to IP address association for later use in detecting spoofed traffic.
6.2. Identified addresses in a global domain
In accordance with the design principles of the Internet, users in
one network are generally not visible to other network
administrations. Rather, the administration of one network will
refer questions of identity to the administration serving a user or
system.
That said, once source address spoofing has been eliminated, the
source address of a datagram can be used to identify the domain from
which it originated, and as a result what network administration must
be contacted if it appears to be misbehaving. This is the proper use
of WHOIS service; IANA and the relevant RIR, or in some cases the NIR
or LIR or local ISP, can identify the administration a prefix has
been assigned to and provide contact information.
6.3. On source addresses
It is seductive to think of this as providing the ability to use this
technology to trace a datagram to the person who originated it. For
several reasons, the technology can be used to derive circumstantial
evidence, but does not actually solve that problem.
Baker & Droms Expires December 20, 2007 [Page 13]
Internet-Draft Source Address Verification June 2007
In the network layer, the source address of a datagram is the address
of the system that originated it and to which any reply is expected
to come. But systems fall into several broad categories. Many are
single user systems, such as laptops and PDAs. Multi-user systems
are commonly used in industry, and a wide variety of middleware
systems and application servers have no user at all, but by design
relay messages or perform services on behalf of users of other
systems.
Two simple examples middleware relays are SMTP (Electronic Mail) and
peer-to-peer file sharing. In SMTP, an email sent by a user is
generally presented to a succession of intermediaries, which are
called Mail Transfer Agents or MTAs. While the email was originated
by a person, the network address used on each successive MTA-MTA
transfer is that of the MTA. BitTorrent File Sharing may determine
that a number of requests for a given file are coming from a given
topological region in the network and push the file to a system it
happens to know is located near there - without the knowledge of the
originator of the file, the user whose system it was pushed from, the
user whose system it was pushed to, or any potential future requester
of the file. In both cases, the network layer address has no
relationship to the application layer user, and in the latter case
the presence of the file on a given system does not imply that the
user of the system knows it is there or has any intent to use it.
Any association of an Internet address with a user is at best
circumstantial; it may identify a set of obvious suspects, but it
does not identify the user, and in many applications does not limit
the set of suspects to the obvious ones. Examples of personal
identifications in Internet messages may be found in DKIM
[I-D.ietf-dkim-base], SMIME [RFC1847], and Open PGP [RFC2440], among
others.
7. IANA Considerations
This memo adds no new IANA considerations. That said, one could
imagine a future specification requesting a common DSCP identifying
datagrams from untrusted sources based on an appropriate description
of the relevant PHB.
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.
Baker & Droms Expires December 20, 2007 [Page 14]
Internet-Draft Source Address Verification June 2007
8. Security Considerations
The security issues this document imposes are not worse than existing
security behavior. The use of ARP, and DHCP are not currently
secured, which may be an open attack vector. Neighbor Discovery is
similarly unsecured, but Secure Neighbor Discovery is usable in the
context. The mechanics of securing address assignment and
announcement is considered a separate issue from the subject matter
of this paper, but is material to its usefulness.
The security considerations of RFCs 2474 and 2475 apply, as this uses
the Differentiated Services Architecture.
In any discussion of identity, an important issue is the chain of
trust and the anchor of that chain. In this context, the chain of
trust is Internet routing, and the anchor of that chain is the system
that verifies the source address used by its downstream peer. As
such, the first step - the verification of the source address by the
immediate neighbor of an end system - is of paramount importance, and
any check after that point is of lower efficacy. That said, the
first system that can be said to be trusted by any administrative
entity is the ingress system under its control. As such, each
enterprise and ISP en route is responsible for its own security and
must implement a verification procedure to ensure its own compliance.
9. Acknowledgements
The discussion of contracts and DSCP markings was first proposed by
Steve Crocker in [Crocker].
The discussion of BGP Communities derives from discussions with Barry
Greene.
The description of IEEE 802.1X was adapted from the Wikipedia article
on the topic. Paul Gleichauf added comments on trust and trust
management. Pekka Savola performed a detailed review.
10. References
10.1. Normative References
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Baker & Droms Expires December 20, 2007 [Page 15]
Internet-Draft Source Address Verification June 2007
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
10.2. Informative References
[Crocker] Crocker, S., "Protecting the Internet from distributed
denial-of-service attacks: a proposal", Proceedings of the
IEEE Volume 92, Pages 1375-1381, September 2004.
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-10 (work in progress),
February 2007.
[I-D.ietf-idr-bgp-prefix-orf]
Chen, E. and S. Sangli, "Address Prefix Based Outbound
Route Filter for BGP-4", draft-ietf-idr-bgp-prefix-orf-04
(work in progress), July 2006.
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-15 (work in
progress), May 2007.
[I-D.sava-problem-statement]
Wu, J., "Source Address Verification Architecture Problem
Statement", draft-sava-problem-statement-00 (work in
progress), February 2007.
[IEEE802.1X]
Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X, September 2004.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
Baker & Droms Expires December 20, 2007 [Page 16]
Internet-Draft Source Address Verification June 2007
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[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.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778,
January 2007.
Authors' Addresses
Fred Baker
Cisco Systems
Email: fred@cisco.com
Ralph Droms
Cisco Systems
Email: rdroms@cisco.com
Baker & Droms Expires December 20, 2007 [Page 17]
Internet-Draft Source Address Verification June 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 & Droms Expires December 20, 2007 [Page 18]