INTERNET-DRAFT Danny McPherson Arbor Networks Fred Baker Cisco Systems Expires: September 2008 March 13, 2008 Intended Status: Informational SAVI Threat Scope 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The IETF Trust (2008). McPherson, Baker [Page 1] INTERNET-DRAFT Expires: September 2008 March 2008 Abstract This memo discusses threats enabled by IP source address spoofing and discusses a number of techniques aimed at mitigating those threats. McPherson, Baker [Page 2] INTERNET-DRAFT Expires: September 2008 March 2008 Table of Contents 1. Specification of Requirements. . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Glossary of Terms. . . . . . . . . . . . . . . . . . . . . . . 6 4. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 7 4.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Single Packet DoS. . . . . . . . . . . . . . . . . . . . 7 4.1.2. Flood-Based DoS. . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Poisoning Attacks. . . . . . . . . . . . . . . . . . . . 8 4.1.4. Third Party Recon. . . . . . . . . . . . . . . . . . . . 9 4.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . . 9 4.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . . 9 4.1.7. Accounting Subversion. . . . . . . . . . . . . . . . . . 10 4.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . . 10 4.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . . 10 4.2.2. Third Party Recon. . . . . . . . . . . . . . . . . . . . 11 5. Current Anti-Spoofing Solutions. . . . . . . . . . . . . . . . 11 5.1. Host to link layer neighbor or switch . . . . . . . . . . . 13 5.2. Upstream routers. . . . . . . . . . . . . . . . . . . . . . 13 5.3. ISP edge PE Router. . . . . . . . . . . . . . . . . . . . . 14 5.4. ISP NNI Router to ISP NNI Router. . . . . . . . . . . . . . 14 5.5. Spoofing In Local Area Network Segments . . . . . . . . . . 14 5.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . . 15 5.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . . 15 5.8. BCP 38. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . . 15 5.10. Port-based Address Binding . . . . . . . . . . . . . . . . 15 5.10.1. Manual Binding. . . . . . . . . . . . . . . . . . . . . 16 5.10.2. Automated Binding . . . . . . . . . . . . . . . . . . . 16 5.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . 16 5.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 16 5.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 17 6. Topological Considerations . . . . . . . . . . . . . . . . . . 17 6.1. Address Provisioning Mechanisms . . . . . . . . . . . . . . 17 6.2. LAN devices with Multiple Addresses . . . . . . . . . . . . 17 6.2.1. Routers. . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . . 18 6.2.4. Multi-LAN Hosts. . . . . . . . . . . . . . . . . . . . . 18 6.2.5. Firewalls. . . . . . . . . . . . . . . . . . . . . . . . 19 6.2.6. Mobile IP. . . . . . . . . . . . . . . . . . . . . . . . 19 6.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . . 19 7. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 19 7.1. Analysis of Host Granularity Anti-Spoofing. . . . . . . . . 19 McPherson, Baker [Page 3] INTERNET-DRAFT Expires: September 2008 March 2008 8. Deployment Considerations. . . . . . . . . . . . . . . . . . . 20 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 24 McPherson, Baker [Page 4] INTERNET-DRAFT Expires: September 2008 March 2008 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 2. Overview The Internet Protocol, specifically IPv4 [RFC 791] and IPv6 [RFC 2460], employ a connectionless hop-by-hop packet forwarding paradigm. A host connected to an IP network that wishes to communicate with another host on the network generates an IP packet with source and destination IP addressing information, among other options. 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 [RFC 2827] provide guidelines for one such technique for network ingress filtering. However, if these techniques are not implemented on 32-bit prefix boundaries at the ultimate 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. There is a possibility that in an LAN environment where multiple hosts share a single IP port on a switch or router, one of those hosts may source address 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 McPherson, Baker Section 2. [Page 5] INTERNET-DRAFT Expires: September 2008 March 2008 regarding spoofed-based threat vectors, and discuss implications of various network topologies. 3. Glossary of Terms The following acronyms and terms are used throughout this memo. 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. 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. Spoofing: The act of forging datagram header contents at the Link or Network Layer 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. McPherson, Baker Section 3. [Page 6] INTERNET-DRAFT Expires: September 2008 March 2008 4. 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. 4.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. 4.1.1. Single Packet DoS 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. McPherson, Baker Section 4.1.1. [Page 7] INTERNET-DRAFT Expires: September 2008 March 2008 4.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. 4.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. McPherson, Baker Section 4.1.3. [Page 8] INTERNET-DRAFT Expires: September 2008 March 2008 4.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. 4.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. 4.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 illicts 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. McPherson, Baker Section 4.1.6. [Page 9] INTERNET-DRAFT Expires: September 2008 March 2008 4.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. 4.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. 4.2. Non-Blind Attacks Non-blind attacks often involve mechansisms 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. 4.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 [ARP] 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 McPherson, Baker Section 4.2.1. [Page 10] INTERNET-DRAFT Expires: September 2008 March 2008 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. 4.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. 5. 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: 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 make decreasingly authoritative assertions about the validity of the source address in the datagram. Nonetheless, there is value in McPherson, Baker Section 5. [Page 11] INTERNET-DRAFT Expires: September 2008 March 2008 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: 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 McPherson, Baker Section 5. [Page 12] INTERNET-DRAFT Expires: September 2008 March 2008 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. 5.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. 5.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 McPherson, Baker Section 5.2. [Page 13] INTERNET-DRAFT Expires: September 2008 March 2008 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]. 5.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. 5.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. 5.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 McPherson, Baker Section 5.5. [Page 14] INTERNET-DRAFT Expires: September 2008 March 2008 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. 5.6. Cable Modem Subscriber Access Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access Control (MAC) domains, which are similar to Ethernet LAN environments. 5.7. DSL Subscriber Access Something about DSLAMs here.. 5.8. BCP 38 If BCP 38 is implemented in LAN segments, it is typically done so on subnetwork boundaries and traditionally relates only to Network Layer ingress filtering policies. The result is that hosts within the segment cannot spoof packets from address space outside of the local segment itself, however, they may still spoof packets using sources addresses that exist within the local network segment. 5.9. Unicast RPF Unicast RPF is a crude mechanism to automate definition of BCP 38 style filters based on routing table information. It's applicability parallels that of BCP 38, although deployment caveats exists, as outlined in [BCP 84]. 5.10. Port-based Address Binding Much of the work SAVI appears to be initially targeting is aimed at McPherson, Baker Section 5.10. [Page 15] INTERNET-DRAFT Expires: September 2008 March 2008 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. 5.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. 5.10.2. Automated Binding DHCP, RADIUS, Other solutions, Cisco IP Source Guard, etc.. 5.10.3. IEEE 802.1X 5.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 McPherson, Baker Section 5.11. [Page 16] INTERNET-DRAFT Expires: September 2008 March 2008 are still vulnerable to replay, cache poisoning and MITM attacks. 5.12. Residual Attacks Stuff which these solutions don't address Stuff which no one will use the existing solutions for 6. 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. 6.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. 6.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. McPherson, Baker Section 6.2. [Page 17] INTERNET-DRAFT Expires: September 2008 March 2008 6.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. 6.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. 6.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. 6.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 McPherson, Baker Section 6.2.4. [Page 18] INTERNET-DRAFT Expires: September 2008 March 2008 priori knowledge on address assignment and topology is required. 6.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. 6.2.6. Mobile IP Need to say something here, I think... Mobile IP 6.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. 7. Applicability of Anti-Spoofing Solutions What works where, what's needed? Ingress filtering is useful, even with botnets using real addresses Ingress filtering on the admin border is not sufficient, and more fine-grained filtering from savi is necessary. 7.1. Analysis of Host Granularity Anti-Spoofing Most IP spoofing validation can be provided with standard IP-based policies such as those defined in BCP 38. However, at the ultimate McPherson, Baker Section 7.1. [Page 19] INTERNET-DRAFT Expires: September 2008 March 2008 network ingress, the ability to perform a binding for port-MAC-IP provides considerable benefits over vanilla prefix-based source address validation. While it is true that a large array of topologies and address allocation schemas will introduce complexities with automation of port-MAC-IP binding specifications, application of source address validation for static and common dynamic addressed allocation environments (e.g., DHCP) would significantly raise the bar for effectively launching spoof-based attacks. 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. 9. 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. McPherson, Baker Section 9. [Page 20] INTERNET-DRAFT Expires: September 2008 March 2008 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. 10. IANA Considerations This document introduces no IANA considerations. McPherson, Baker Section 10. [Page 21] INTERNET-DRAFT Expires: September 2008 March 2008 11. Acknowledgments Your name could be here.... A portion of the primer text in this document came directly from [savi-operational], authored by Fred Back and Ralph Droms. McPherson, Baker Section 11. [Page 22] INTERNET-DRAFT Expires: September 2008 March 2008 12. References 12.1. Normative References [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 12.2. Informative References http://tools.ietf.org/html/draft-baker-sava-cisco-ip-source-guard "Cisco IP Version 4 Source Guard", Fred Baker, 7-Nov-07, http://tools.ietf.org/html/draft-baker-sava-implementation "Source address validation in the local environment", Fred Baker, 8-Nov-07, http://tools.ietf.org/html/draft-baker-sava-operational "IPv4/IPv6 Source Address Verification", Fred Baker, Ralph Droms, 19-Jun-07, http://tools.ietf.org/html/draft-baker-6man-multiprefix-default-route "Multiprefix IPv6 Routing for Ingress Filters", Fred Baker, 7-Nov-07, [IEEE802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2004. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or McPherson, Baker Section 12.2. [Page 23] INTERNET-DRAFT Expires: September 2008 March 2008 converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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: 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. [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. 13. Authors' Addresses McPherson, Baker Section 13. [Page 24] INTERNET-DRAFT Expires: September 2008 March 2008 Danny McPherson Arbor Networks, Inc. Email: danny@arbor.net Fred Baker Cisco Systems Email: fred@cisco.com Intellectual Property Statement 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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 McPherson, Baker Section 13. [Page 25] INTERNET-DRAFT Expires: September 2008 March 2008 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). McPherson, Baker Section 13. [Page 26]