SAVI Threat Scope

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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.”

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This memo discusses threats enabled by IP source address spoofing and discusses a number of techniques aimed at mitigating those threats.

1. Overview
2. Glossary of Terms
3. Spoofed-based Attack Vectors
    3.1. Blind Attacks
        3.1.1. Single Packet Attacks
        3.1.2. Flood-Based DoS
        3.1.3. Poisoning Attacks
        3.1.4. Third Party Recon
        3.1.5. Spoof-based Worm/Malware Propagation
        3.1.6. Reflective Attacks
        3.1.7. Accounting Subversion
        3.1.8. Other Blind Spoofing Attacks
    3.2. Non-Blind Attacks
        3.2.1. Man in the Middle (MITM)
        3.2.2. Third Party Recon
4. Current Anti-Spoofing Solutions
    4.1. Host to link layer neighbor or switch
    4.2. Upstream routers
    4.3. ISP Edge PE Router
    4.4. ISP NNI Router to ISP NNI Router
    4.5. Spoofing In Local Area Network Segments
    4.6. Cable Modem Subscriber Access
    4.7. DSL Subscriber Access
    4.8. BCP 38
    4.9. Unicast RPF
    4.10. Port-based Address Binding
        4.10.1. Manual Binding
        4.10.2. Automated Binding
        4.10.3. IEEE 802.1X
    4.11. Cryptographic Techniques
    4.12. Residual Attacks
5. Topological Considerations
    5.1. Address Provisioning Mechanisms
    5.2. LAN devices with Multiple Addresses
        5.2.1. Routers
        5.2.2. NATs
        5.2.3. Multi-Instance hosts
        5.2.4. Multi-LAN Hosts
        5.2.5. Firewalls
        5.2.6. Mobile IP
        5.2.7. Other Topologies
    5.3. IPv6 Considerations
6. Applicability of Anti-Spoofing Solutions
    6.1. Analysis of Host Granularity Anti-Spoofing
7. Existing Techniques for IP Source Address Validation
8. Deployment Considerations
9. IANA Considerations
10. Security Considerations
11. Acknowledgements
12. References
    12.1. Normative References
    12.2. Informative References
§ Authors' Addresses

1. Overview

At the IP Network Layer, or Internet Layer, there is typically no required transactional state when communicating with other hosts on the network. Hosts generating packets for transmission have the opportunity to spoof (forge) the source address of packets which they transmit.

Source address verification is necessary in order to detect and reject spoofed packets and contribute to the overall security of IP networks. In particular, source address verification techniques enable detection and rejection of spoofed packets, and also implicitly provide some assurances that the source address in an IP packet is legitimately assigned to the system that generated the packet.

Solutions such as BCP 38 (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.) [RFC2827] provide guidelines for one such technique for network ingress filtering. However, if these techniques are not implemented at the ingress point of the IP network, then the validity of the source address can not be positively ascertained. Furthermore, BCP 38 only implies source address verification at the Internet Layer, and is most often implemented on IP subnetwork address boundaries. One of the difficulties in encouraging the deployment of BCP 38 is that there is relatively little benefit until it is very widely deployed, which is not yet the case. The local application of the principle of BCP 38 fortunately has local benefit, even before BCP 38 is fully deployed. It also helps get the Internet towards a state where BCP 38 is more widely followed.

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 those hosts may spoof the source addresses of other hosts within the local subnet. Understanding these threats and the relevant topologies in which they're introduced is critical when assessing the threats that exists with source address spoofing.

The aim of this document is to provide some additional details regarding spoofed-based threat vectors, and discuss implications of various network topologies.

2. Glossary of Terms

3. Spoofed-based Attack Vectors

Spoofing is employed on the Internet for a number of reasons, most of which are in some manner associated with malicious or otherwise nefarious activities. In general, two classes of spoofed-based attack vectors exists; blind attacks and non-blind attacks. The follow sections provide some information of blind and non-blind attacks.

3.1. Blind Attacks

Blind attacks typically occur when an attacker isn't on the same local area network as a source or target, or when an attacker has no access to the datapath between the attack source(s) and the target systems. The result is that they have no access to legitimate source and target systems.

3.1.1. Single Packet Attacks

One type of blind attacks, which we'll refer to here as "single packet DoS attacks", involves an attacking system injecting spoofed information into the network which results in either a complete crash of the target system, or in some manner poisons some network configuration or other information on a target system such to impact network or other services.

An example of an attack that can cause a receiving system to crash is a LAND attack. A LAND attack packet would consist of an attacking system forwarding a packet (e.g., TCP SYN) to a target system that contains both a source and destination address of that target system. The target system would "lock up" when creating connection state associated with the packet, or would get stuck in a state where it continuously replies to itself.

Another example of a single packet DoS attack involves that of a system poisoning network or DNS cache information, perhaps in order to simply break a given hosts connection, enable MITM or other attacks. Network level attacks that could involve single packet DoS include ARP cache poisoning and ICMP redirects.

3.1.2. Flood-Based DoS

Flooding-based DoS attack vectors are particularly effective attacks on the Internet today. They usually entail flooding a large number of packets towards a target system, with the hopes of either exhausting connection state on the target system, consuming all packet processing capabilities of the target or intermediate systems, or consuming a great deal of bandwidth available to the target system such that they are essentially inaccessible.

Because these attacks require no reply from the target system and require no legitimate transaction state, attackers often attempt to obfuscate the identity of the systems that are generating the attack traffic by spoofing the source IP address of the attacking traffic flows. Because ingress filtering isn't applied ubiquitously on the Internet today, spoof-based flooding attack vectors are typically very difficult to traceback. In particular, there may be one or more attacking sources beyond your network border, and the attacking sources may or may not be legitimate sources, it's difficult to discriminate if the sources are not directly connected to the local routing system.

Common flood-based DoS attack vectors today include SYN floods, ICMP floods, and IP fragmentation attacks. Attackers may use a single legitimate or spoofed fixed attacking source addresses, although frequently they cycle through large swaths of address space. As a result, mitigating these attacks on the receiving end with source- based policies is extremely difficult.

Furthermore, the motivator for spoof-based DoS attacks may actually be to encourage the target to filter explicitly on a given set of source addresses, or order to disrupt the legitimate owner(s) access to the target system.

3.1.3. Poisoning Attacks

As discussed in single-packet DoS above, there are several other attack mechanisms that employ source address spoofing. The more common of these attack vectors include DNS cache poisoning, ARP cache poisoning, and ICMP redirects. While these attacks can be used for disrupting services, they're often used to redirect traffic to network elements where attack intends to carry out additional malicious activities.

3.1.4. Third Party Recon

Third party reconnaissance attacks may be either blind or non-blind attacks. An example of third party reconnaissance is when an attacker wishes to fingerprint a remote operating system type, perhaps in order to initiate some TCP session hijacking, and in order to do so must be able to identify the TCP sequence and algorithm employed by the target system. Initiating a determined number of connections with the target system may assist with this.

3.1.5. Spoof-based Worm/Malware Propagation

Self-propagating malware has been observed that spoofs it's source address when attempting to propagate to other systems. Presumably, this was done to obfuscate the actual source address of the infected system.

3.1.6. Reflective Attacks

DNS reflective amplification attacks are a particularly potent DoS attack vector on the Internet today. Like other amplification attacks, an attack source generates a packet with a source-spoofed address mapping to that of the target system. The packet, upon receipt by the victim or some intermediate node, typically elicits a large reply message, which is directed to the target of the attack. The amplification factor observed for attacks targeting DNS root and other top level domain name infrastructure in early 2006 was on the order of 76:1. The result is that just 15 attacking sources with 512k of upstream attack bandwidth could generate one Gbps of response attack traffic towards a target system.

Smurf attacks employ a similar reflective amplification attack vector, exploiting traditional default IP subnet directed broadcast address behaviors that would result in all the active hosts on a given subnet responding to (spoofed) ICMP echo request from an attacker, and generating a large amount of ICMP echo response traffic directed towards a target system. They were particularly effective in large campus LAN environments where 50k or more hosts might reside on a single subnet.

3.1.7. Accounting Subversion

If an attacker wishes to distribute content or other material in a manner that employs protocols that require only uni-directional flooding and generate no end-end transactional state, they may desire to spoof the source IP address of that content in order to avoid detection or accounting functions enabled at the IP layer.

3.1.8. Other Blind Spoofing Attacks

Other Blind spoofing attacks might include spoofing in order to exploit source routing or other policy based routing implemented in a network. It may also be possible in some environments to use spoofing techniques to perform blind or non-blind attacks on the routers in a site or in the Internet. There are many techniques to mitigate these attacks, but it is well known that there are vulnerabilities in this area.

3.2. Non-Blind Attacks

Non-blind attacks often involve mechanisms such as eavesdropping on connection, resetting state so that new connections may be hijacking, and an array of other attack vectors. Perhaps the most common of these attack vectors is known as man in the middle attacks.

3.2.1. Man in the Middle (MITM)

Connection Hijacking is one of the more common man in the middle attack vectors. In order to hijack a connection an attacker usually needs to be in the forwarding path and often times employs TCP RST or other attacks in order to reset a transaction. The attacker may have already compromised a system that's in the forwarding path, or they may which to insert themselves in the forwarding path.

For example, an attacker with access to a host on LAN segment may wish to redirect all the traffic on the local segment destined for a default gateway address (or all addresses) to itself in order to perform man-in-the-middle attacks. In order to accomplish this the attacker might transmit gratuitous ARP [RFC0826] (Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware,” November 1982.) messages or ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, notifying all the hosts on the segment that the IP address(es) of the target(s) now map to it's own MAC address. If the port to which the attacker is connected were to implement policy that binds a single Link Layer and IP address tuple to that port upon initial provisioning, spoofed packets, at the Link Layer and/or Network Layer, would be discarded on ingress.

3.2.2. Third Party Recon

Another example of third party reconnaissance that falls into both the blind and non-blind attack class involves spoofing packets towards a given target system and observing either target or intermediate system responses. For example, if an attacker were to source spoof TCP SYN packets towards a target system from a large set of source addresses, and observe responses from that target system or some intermediate firewall or other middle box, they would be able to identify what IP layer filtering policies may be in place to protect that system.

4. Current Anti-Spoofing Solutions

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:

Filtering points farther away from the source of the datagram can 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     _.-'
                                             `----------''

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 Link Layer and IP addresses on a link can discard any datagrams in which the IP address is not associated with the Link Layer address in the datagram. The degree of confidence in the source address depends on where the spoofing detection is performed and the prefix aggregation in place between the spoofing detection and the source of the datagram.

4.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 Link Layer 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 Link 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, such as Ethernet, the best that can be done is to verify the Link Layer 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 prevents transmission of malicious datagrams whose Link Layer and IP addresses are both spoofed to mimic another host.

4.2. Upstream routers

Beyond the first hop router, subsequent routers may additionally filter traffic from downstream networks. Because these routers do 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 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. Strict 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 information. These filtering procedures are discussed in more detail in [RFC3704] (Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” March 2004.).

4.3. ISP Edge PE Router

An obvious special case of the discussion is with an ISP PE router, where it provides its customer with access. BCP 38 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. A contract might be written between an ISP and its customer requiring that the customer apply the procedures of network ingress filtering to the customer's own network, although there's no way upstream networks would be able to verify this.

4.4. ISP NNI Router to ISP NNI Router

The considerations explicitly related to customer networks can also be applied to neighboring ISPs. An interconnection agreement might be written between two companies requiring network ingress filtering policy be implemented on all customers connections. 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.

4.5. Spoofing In Local Area Network Segments

On Link Layer segments where multiple hosts reside, or a single MAC address can be associated with a port or interface, if a binding between a hardware address (e.g., MAC address) and corresponding IP address(es) are not provisioned via some means (either manual or dynamic mechanisms), then an attacker may exploit attack vectors that enable MITM or other spoof-based attacks.

4.6. Cable Modem Subscriber Access

Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access Control (MAC) domains, which are similar to Ethernet LAN environments.

4.7. DSL Subscriber Access

4.8. BCP 38

4.9. Unicast RPF

4.10. Port-based Address Binding

Much of the work SAVI appears to be initially targeting is aimed at minimizing source address spoofing in the LAN. In particular, if mechanisms can be defined to accommodate configuration of port binding information for IP and MAC layer addresses in LAN environments, a large portion of the spoofing threat space in the LAN can be marginalized.

However, establishing these binding is not trivial, and varying across both topologies type and address allocation mechanisms.

4.10.1. Manual Binding

Binding of a single Link Layer and Network Layer address to a port may initially seem trivial. However, two primary areas exist that can complicate such techniques. In particular, these area involves topologies where more than a single IP layer address may be associated with a MAC address on a given port, or where multiple hosts are connected to a single IP port. Furthermore, if one or more dynamic address allocation mechanisms such as DHCP are employed, then some mechanism must exist to associate those IP layer addresses with the appropriate Link layer ports, as addresses are allocated or reclaimed.

4.10.2. Automated Binding

4.10.3. IEEE 802.1X

IEEE 802.1x is an authentication protocol that permits a network to determine the identity of a system seeking to join it and apply authorization rules to permit or deny the action.

4.11. Cryptographic Techniques

Needless to say, MITM and replay attacks can typically be mitigated with cryptographic techniques. However, many of the applications today either don't or can't employ cryptographic authentication and protection mechanisms. ARP and DNS are two examples. DNSSEC does propose to assist, but until it's deployed ubiquitously, from clients, to resolvers, to authoritative roots, clients and resolvers are still vulnerable to replay, cache poisoning and MITM attacks.

4.12. Residual Attacks

5. Topological Considerations

As noted previously, topological components and address allocation mechanisms have significant implications on what is feasible with regard to Link layer address and IP address port bindings. The following sections discuss some of the various topologies and address allocation mechanisms that proposed SAVI solutions should attempt to address.

5.1. Address Provisioning Mechanisms

In a strictly static environment configuration management for access filters that map Link Layer and Network Layer addresses on a specific switch port might be a viable option. However, most networks, certainly, those that accommodate actual human users, are much more dynamic in nature. As such, mechanisms that provide port-MAC-IP bindings need to accommodate dynamic address allocation schemes enabled by protocols such as DHCP.

5.2. LAN devices with Multiple Addresses

From a topology considerations perspective, when attempting port-MAC-IP bindings, host connected to switch ports that may have one or more IP addresses, or certainly, devices that forward packets from other network segments, are problematic.

5.2.1. Routers

The most obvious example of devices that are problematic when attempting to implement port-MAC-IP bindings is that of routers. Routers not only originate packets themselves and often have multiple interfaces, but also forward packets from other network segments. As 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 subnets should be associated with the port-MAC in question.

5.2.2. NATs

Prefix-based and multi-address NATs also become problematic, for the same reasons as routers. Because they may forward traffic from an array of address, a priori knowledge must exist providing what IPs should be associated with a given port-MAC pair.

5.2.3. Multi-Instance hosts

Another example that introduces complexities is that of multi-instance hosts attached to a switch port. Multi clients, with the same or different MACs, may be attached to the port and may either have static IP addresses assigned, or may receive one or more dynamically via DHCP or similar means. Accommodating multi-instance hosts, or even blade-server type devices dynamic is feasible, buy may introduces complexities if the solution in question does not accommodate unique considerations introduced in these environments.

5.2.4. Multi-LAN Hosts

Multi-interface hosts, in particular those that are multi-homed and 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 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 and forward through in interface for which the port-MAC-IP binding doesn't map, the traffic may be discarded. Static configuration of port-MAC-IP bindings may accommodate this scenario, although some a priori knowledge on address assignment and topology is required.

5.2.5. Firewalls

Firewalls that forward packets from other network segments, or serve as a source for locally originated packets, suffer from the same issues as routers.

5.2.6. Mobile IP

Mobile IP hosts in both IPv4 and IPv6 as proper members of the site where they are currently located. Their care-of-address is a properly assigned address that is on the link they are using. And their packets are sent and received using that address. (There was at one time consideration of allowing mobile hosts to use their home address when away from home. This was not done, precisely to ensure that mobile hosts comply with source address validity requirements.) Mobile Hosts with multiple physical interfaces fall into the cases above.

Mobile IP home agents are somewhat more interesting. Although they are (typically) fixed devices, they are required to send and receive packets addressed from or to any currently properly registered mobile node. From an analysis point of view, even though the packets that a Home Agent handles are actually addressed to or from the link the HA is on, it is probably best to think of them as routers, with a virtual interface to the actual hosts they are serving.

5.2.7. Other Topologies

Any topology that results in the possibility that a device connected to a switch port may forward packets with more than a single source address for packet which it originated may be problematic. Additionally, address allocation schemas introduce additional considerations when examining a given SAVI solutions space.

5.3. IPv6 Considerations

IPv6 introduces additional capabilities which indirectly complicate the spoofing analysis. IPv6 introduces and recommends the use of stateless address autoconfiguration (often referred to as SLAAC). This allows hosts to determine their IP prefix, select an ID, and then start communicating. While there are many advantages to this, the absence of control interactions complicates the process of behavioral enforcement.

An additional complication is the very large ID space. Again, this 64 bit ID space provided by IPv6 has many advantages. It provides the opportunity for many useful behaviors. However, it also means that in the absence of controls, hosts can mint anonymous addresses as often as they like, modulo the idosyncrasies of the duplicate address procedure. Like many behaviors, this is a feature for some purposes, and a problem for others. But it does have implications for switch cost; the switch needs to store more addresses and so needs more memory.

6. Applicability of Anti-Spoofing Solutions

The above sections covered a number of security threats. Not all these threats can be prevented by anti-spoofing techniques. However, all of these threats can be ameliorated to some degree. We can look at three categories of effect we can achieve:

For example, sites which deploy BCP 38 can not be the source of attacks which rely on spoofing the source site from which an attack was launched. Wide deployment of BCP 38 would also simplify the task of tracking attacks back to their actual origin.

6.1. Analysis of Host Granularity Anti-Spoofing

Applying anti-spoofing techniques at the host level enables a site to achieve several valuable objectives. While it is likely the case that for many site topologies and policies, full source spoofing protection is not possible, it is also true that for many sites there are steps that can be taken that provide benefit.

One important class of benefit is masquerade prevention. Security threats involving one machine masquerading as another, for example in order to hijack an apparently secure session, can occur within a site with significant impact. Having mechanisms such that host facing devices prevent this is a significant intra-site security improvement. Given that security experts report that most security breaches are internal, this can be valuable. One example of this is that such techniques should mitigate internal attacks on the site routing system.

A second class of benefit is related to the traceability described above. When a security incident is detect, either within a site, or externally (and traced to the site, it can be critical to determine what the actual source of the incident was. If address usage can be tied to the kinds of anchors described earlier, then it is possible to respond to security incidents.

In addition to these local observable benefits, there can be more global benefits. For example, if address usage is tied to anchors, it may be possible to prevent or control the use of large numbers of anonymous IPv6 addresses for attacks, or at least to track even those attacks back to their source.

7. Existing Techniques for IP Source Address Validation

Existing techniques for IP source address validation are insufficient. While each technique has its own shortcomings, the following list of general categories of reasons include some of the deficiencies of all existing technique:

Ingress filtering may yield false negatives in a deterministic manner. Packets with a legitimate IP source address prefix, but a spoofed interface identifier, pass ingress filtering checks. Also, packets with an illegitimate IP source address prefix pass the checks as long as the prefix is from the list of prefixes considered legitimate, if more than one prefix is considered as legitimate on the ingress interface..

Ingress filtering implementations that require manual establishment of the list of legitimate prefixes cause considerable configuration overhead. Unicast Reverse Path Forwarding (uRPF) mitigates this issue by automatically deriving the list of legitimate prefixes from a router's forwarding table: A to-be-forwarded packet's IP source address prefix is considered legitimate if the packet is coming through an interface via which return traffic would be routed. On the other hand, Unicast Reverse Path Forwarding may yield false positives, in particular for hosts and networks with multiple, topologically separate Internet attachments [RFC3704] (Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” March 2004.).

Consequently, there is a need for an IP source address validation technique that avoids false negatives and false positives, that can be set up with no or only trivial configuration, and that has been standardized. The development of such a technique is the goal of the proposed Source Address Validation Improvements (SAVI) working group in the Internet Engineering Task Force.

8. Deployment Considerations

From a global Internet perspective, deployment of anti- spoofing techniques tends to suffer from a "tragedy of the commons" situation. That is, there is a general consensus that everyone should implement anti-spoofing measures, yet individual organizations don't want to bear the cost of deployment themselves, often because demonstrating direct tangible return on investment is not possible. Upon analysis, it often seems apparent that local implementation of anti-spoofing measures is of more benefit to the "greater Internet" than the local network domain itself. A similar situation occurs with de-aggregation of Internet routing information for multi-homing and traffic engineering purposes, as well as the lack of explicit inter-domain routing prefix filters on the Internet.

Until network operators begin to accept that their local design choices have global implications, and act upon this responsibility, the problem is not going to go away.

Ideally, with additional work in the areas of SAVI to ease deployment and management burdens, the deployment cost to operators will decrease and more wide-scale deployment will continue. Furthermore, application of SAVI-like techniques provides more obvious benefits to network administrators that are concerned with MITM and similar attacks.

As mentioned earlier, there are local security benefits to the deployment of SAVI security mechanisms. This may help motivate the deployment of tools with widespread benefit.

9. 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.

10. Security Considerations

This document provides limited discussion of some security threats source address validation improvements will help to mitigate. It is not meant to be all-inclusive, either from a threat analysis perspective, or from the source address verification application side.

It is seductive to think of SAVI solutions as providing the ability to use this technology to trace a datagram to the person, or at least end system, that originated it. For several reasons, the technology can be used to derive circumstantial evidence, but does not actually solve that problem.

In the Internet Layer, the source address of a datagram should be 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 (e.g., SMTP and peer-to-peer file sharing).

Until every Internet-connected network implements source address validation at the ultimate network ingress, and assurances exist that intermediate devices are to never modify datagram source addresses, source addresses must not be used as an authentication mechanism. The only technique to unquestionably verify source addresses of a received datagram are cryptographic authentication mechanisms such as IPSEC.

[RFC0791]	Postel, J., “Internet Protocol,” STD 5, RFC 791, September 1981 (TXT).
[RFC2460]	Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML).

[I-D.baker-sava-operational]	Baker, F. and R. Droms, “IPv4/IPv6 Source Address Verification,” draft-baker-sava-operational-00 (work in progress), June 2007 (TXT).
[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 (TXT).
[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 (TXT).
[RFC3704]	Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” BCP 84, RFC 3704, March 2004 (TXT).

	Danny McPherson
	Arbor Networks

Email:	danny@arbor.net

	Fred Baker
	Cisco Systems

Email:	fred@cisco.com

	Joel M. Halpern
	Ericsson

Email:	jhalpern@redback.com

SAVI Threat Scopedraft-ietf-savi-threat-scope-01

Status of this Memo

Copyright Notice