Network Working Group Paul Ferguson Internet-Draft Trend Micro, Inc. Intended status: Experimental J. Wu Expires: December 31, 2007 J. Bi X. Li G. Ren Tsinghua University M I. Williams Juniper Networks 31 June 2007 Source Address Verification Architecture Problem Statement draft-sava-problem-statement-01 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 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document outlines the problems that the Source Address Verification Architecture (SAVA) initiative plans to solve. It examines the current state in the internet, looks at current best practices, and discusses why the current approaches are unlikely to ever solve the problem of IP address spoofing. It also discusses some of the problems that SAVA should NOT attempt to solve. Requirements Language 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current State of Affairs . . . . . . . . . . . . . . . . . . . 3 3. Shortcomings of Best Current Practices . . . . . . . . . . . . 4 4. Framework Requiremenmts/Discussion . . . . . . . . . . . . . . 4 5. Scaling & Methodlogy . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 1. Introduction As we all know, the Internet is a decentralized system which basically provides best effort, packet-based data forwarding service. In the forwarding process, intermediate devices (routers, switches, other gateway devices, etc.) forwards IP packets based on the destination IP address. This is how the Internet was designed to operate, and these are the principle contraints that we must acknowledge in the approach that SAVA attempts to address. In virtaully all cases of processing traffic in the Internet, the source IP address is generally not validated as being genuine. It is accepted as being som simply because that it is written into the IP header datagram. This is no longer acceptable as method of assuring the validity of the geneuine source of traffic, since it is trivial for any host in the Internet to re-write this value, or simply misrepresent itself as the originator of traffic. This lack of source IP address validation makes it easy for anyone to spoof the originating IP host address, and has facilitated many existing historical (and current) instances of maliciousness (e.g. hiding behind spoofed IP source addresses, et al.). In recent years, there have been some efforts in the research community to design mechanisms to expose efforts to which employ IP source address spoofing -- plenty of instances of this are readily available. The motivation of this document is to clarify the problem in solving the spoofing of source address. The general problem of supporting authenticity of source address in the Internet is divided into three seperated sub-problems, refered as "First-hop, local subnet source validation", "Intra-AS Communication of SAVA validation", and "Inter-AS Communication of SAVA validation." The primary difference between these three topological applications details each issue and implementation is unique to the place where it is actually enabled. This problem statement attempts to illustrate why these problems are uniquely different, and why the SAVA framework, and subsequent soutions, must be implemented in such a fashion as to take into account the placement of each function into the heierachy of the Internet itself. 2. Current State of Affairs In the MIT Spoofer Project [Bev05], the authors found that approximately one-quarter of the observed addresses, netblocks and autonomous systems (AS) permit full or partial spoofing. And they also suggested that a large portion of the Internet is vulnerable to spoofing and concerted attacks employing spoofing remain a serious concern. While this is by no means an authoritative measurement of the scope of the problem, it does, however, illustrate the difficulty in measuring how deep this rabbit-hole actually goes -- and how the ability to spoof the source address of a packet can contribute to malicious activity or attacks in The Internet. Commentary: There is much heated discussion, in various forums, on the relative threat of spoofed IP host source addresses. Some of it is valid, some invalid. The purpose of this draft is to illustrate the ability to spoof IP source addresses, and some of the corresponding and resulting problems in allowing it to occur, not to debate the trends in this regard. One thing is for sure, however, and is still held true -- spoofed IP host source address traffic still exists, for one reason or another, and still poses a conundrum insofar as validating the source of maliciousness. 3. Shortcomings of Best Current Practices While there are several BCPs in this area, the wide-spead adoption of them remains elusive. There is one Best Current Practice (BCP) published in the IETF that specifically deals with this issue, and there can be any number of discussions on why it is not widely delpoyed (but that is a topic for any number of other discussions): Ingress Filtering, as described in BCP38 [RFC2827], descibes a simple methodology for ISPs and any other Internet-facing organisation to apply filters (or other mechanisms) which limit to a specific parameter, the source addresses that can be allowed to be "source" packets into the Internet from a select and predetermined set of prefixes. If BCP38 were followed at all ingress points to the Internet, then there would be no spoofed packets on the Internet. This particular issue is not further discussed in this draft, however, the resulting work items that can formulated with a SAVA framework buikds on the initial purpose of BCP38 -- to prohibit traffic with spoofed source addresses to be sent into The Internet. One of the problem with BCP38 is that there is no measuareable or incremental method to determine it's success -- either it is deployed globally, or else there is no way to determine it's effectiveness. What we attempt to do with a SAVA framework, is to bring incremental benefit to incremetal deployment of BCP38 implementation, as well as a way to meaure it's global deployment and benefit. 4. Framework Requirements SAVA Architecural and WG framework disucssions will be more completely defined and addressed in the proposed workgroup charter and the framework document. 5. Scaling & Methodology SAVA functionality solutions will be feasible for all network sizes due to the manner in which we plan to dissect the framework -- each of the desired SAVA functionalities will be defined in individual documents that approximate their ability to perfoerm a specific function relative to their placement and function in the network heiracrhy: - First-hop, local-subnet source-address validation (and enforcement); - Intra-AS communication of SAVA validation; - Inter-AS communication of SAVA validation. Additionally, within the SAVA framework documentation process, we would like to define methods to determine how to measure and observe "SAVA validation" -- or rather, define ways in which it can be definitively determined that source address validation has been performed on traffic -- at each point in the Internet heirarchy (e.g. first-hop/local subnet, at each hop in the same AS, and at any arbitrary point in the end-to-end AS path from source to destination.) 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations For this document, no specific security considerations. Many of the solution elements will need to be examined carefully for robustness and to see if they do not in themselves introduce security problems. 8. Acknowledgements [blah] 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [Bev05] Beverley, S. and S. Bauer, ""The spoofer project: inferring the extent of source address filtering on the Internet", USENIX SRUTI 2005", 2005. [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. [RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. Authors' Addresses Paul Ferguson Trend Micro, Inc. San Jose, California USA Email: Paul_Ferguson@trendmicro.com +1.408.625.1068 Jianping Wu Tsinghua University Email: jianping@cernet.edu.cn Jun Bi Tsinghua University Email: junbi@cernet.edu.cn Xing Li Tsinghua University Email: xing@cernet.edu.cn Gang Ren Tsinghua University Email: rengang@csnet1.cs.tsinghua.edu.cn Mark I. Williams Juniper Networks Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave Dong Cheng District, Beijing 100738 China Email: miw@juniper.net 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).