Source Address Validation F. Baker Architecture Cisco Systems Internet-Draft March 19, 2007 Intended status: Informational Expires: September 20, 2007 Simple Source Address Validation draft-baker-sava-simple-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 September 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This note proposes a simple solution to Source Address Validation, assuming that the purpose of such validation is to prevent attacks from using spoofed addresses. Baker Expires September 20, 2007 [Page 1] Internet-Draft Local Unicast Reverse Path Forwarding March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Simple proposed solution . . . . . . . . . . . . . . . . . . . 3 2.1. The fundamental requirements: what is it that has to be solved? . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. What to do . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. How to do it . . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 6 Baker Expires September 20, 2007 [Page 2] Internet-Draft Local Unicast Reverse Path Forwarding March 2007 1. Introduction This note proposes a simple solution to Source Address Validation, assuming that the purpose of such validation is to prevent attacks from using spoofed addresses. The Source Address Validation problem is proposed in other papers on this topic. I won't try to replicate that discussion. That said, it seems to this author that 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 in a TCP session, 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. As such, it seems like the first requirement is that the first datagram in a session have its address validated. It also seems to this author that the network in which a datagram is originated is among the targets that a bot might attack; an infected host can attack the next host on the same wire or switch. As such, the value of such an architecture is non-zero for the source LAN, and only by derivation later. 2. Simple proposed solution So I have a simple proposal. 2.1. The fundamental requirements: what is it that has to be solved? If one buys the arguments that source address validation is of value in the network the datagram is originated on and that it must be applicable to the first datagram in any exchange, then it follows that o the place to implement source address validation is the set of hosts and routers that directly connect to a host; e.g., those on the same LAN, and o that those devices must learn of that address before it is used or as early as possible in its use. 2.2. What to do Any host running IPv4 or IPv6 has one or more IP addresses that it uses on any given interface. It also has some way of identifying itself to its neighbors at Link Layer. On a LAN (fixed or wireless), Baker Expires September 20, 2007 [Page 3] Internet-Draft Local Unicast Reverse Path Forwarding March 2007 it uses a MAC Address; in a GPRS/3GPP network, it establishes a circuit-like relationship with its router and is the only device at the end of that circuit, so the circuit identifies the association. If it is possible to associate addresses with hosts, it is possible to associate them the way host is identified at the link layer. We in fact do that, for the purpose of datagram delivery. Implement what amounts to Local Unicast Reverse Path Forwarding. Impose a policy that one IP system should accept IP datagrams from a directly-connected IP neighbor (host or router) if and only if the Source IP Address is among the equivalence class of IP addresses known to be associated with the neighboring device. If traffic is not accepted if that fails, this protects the devices each direct recipient from the problem. Since one of those direct recipients is the first hop router, by extension this protects the enterprise and the Internet. There are obvious exceptions to this, including routers and multihomed hosts whose addresses are from other LANs. It seems that these are eminently solvable: o a host can identify each router it is a neighbor of, as it sends Router Advertisements, o a router can identify a neighboring router by the fact that it enters into a routing protocol exchange, and o multihomed hosts can follow a policy of only sending datagrams on the LANs on which their source addresses are valid. So these cases may be handled as exceptions in the logic. 2.3. How to do it The way to accomplish this depends on the underlying Link Layer and the way it associates devices. The set of valid IP addresses to be used by the typical host may be established using ARP, by watching DHCP assignments, or by asking for a Neighbor Discovery [RFC2461] exchange to be accomplished per address the host will use. 3. IANA Considerations This memo adds no new IANA considerations. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during Baker Expires September 20, 2007 [Page 4] Internet-Draft Local Unicast Reverse Path Forwarding March 2007 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. 4. Security Considerations The security issues this document imposes are not worse than existing security behavior. The use of ARP, Neighbor Discovery, and DHCP are not currently secured, which may be an open attack vector. This is considered a separate issue that, if real, must be addressed separately. 5. Acknowledgements 6. References 6.1. Normative References [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 6.2. Informative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Author's Address Fred Baker Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com Baker Expires September 20, 2007 [Page 5] Internet-Draft Local Unicast Reverse Path Forwarding March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baker Expires September 20, 2007 [Page 6]