Network Working Group J. Wu Internet-Draft Tsinghua University Intended status: Informational R. Bonica Expires: February 2, 2007 Juniper Networks J. Bi M. Zhang X. Li G. Ren Tsinghua University M I. Williams Juniper Networks August 2006 Source Address Valadation Architecture Problem Statement draft-sava-problem-statement-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 February 2, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Wu, et al. Expires February 2, 2007 [Page 1] Internet-Draft SAVA Problem Statement August 2006 Abstract This document outlines the problems for the Source Address Validation Architecture (SAVA) initiative to solve. It examines the current state in the internet, looks at current best practices and discusses why the current approach is 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. Best Current Practices . . . . . . . . . . . . . . . . . . . . 4 4. Deficiencies of Ingress-Filter (BCP0038) and uRPF Approach . . 4 5. Why IPSEC is not the Solution to This Problem . . . . . . . . 5 6. Framework Requirements . . . . . . . . . . . . . . . . . . . . 5 6.1. Direct Benefit to Deployers . . . . . . . . . . . . . . . 5 6.2. Solution Focus on IPv6 . . . . . . . . . . . . . . . . . . 5 6.3. Performance . . . . . . . . . . . . . . . . . . . . . . . 5 6.4. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.5. Multiple-Fence Solution . . . . . . . . . . . . . . . . . 6 6.6. Incrementally Deployable . . . . . . . . . . . . . . . . . 6 6.7. Loose Coupling . . . . . . . . . . . . . . . . . . . . . . 6 7. Out of Scope Problems . . . . . . . . . . . . . . . . . . . . 6 7.1. End-End Validation for Endpoints and Applications . . . . 6 7.2. Source Address Validation for IPv4 Networks . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Wu, et al. Expires February 2, 2007 [Page 2] Internet-Draft SAVA Problem Statement August 2006 1. Introduction The Internet is a decentralized system which basically provides best effort, packet-based data forwarding service. In the forwarding process, the device (router, switch, gateway, etc.) forwards IP packets based on the destination IP address. In most cases, the source IP address is not checked. The lack of source IP address checking makes it easy for the attackers to spoof the source address. And it has facilitated many existing attacks in the Internet. In recent years, there have been some efforts in the research community to design mechanisms on fighting against source address spoofing. We think it is now a suitable time to summarize the progress and to standardize some results of research efforts to protocols, to enhance the authenticity of the source address. Providing authentic IP address is not only helpful to network security, but also helpful to some other aspects, e.g., network application, network management and accounting, etc. 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, referred as "inter-provider SAVA problem", "intra-provider SAVA problem" and "access network SAVA problem". The primary difference between these three problems is the different level and scope in network topology. The "inter-provider SAVA problem" considers the source address spoofing involved with more than one provider, how providers can share information about source address validation and trust models for the sharing of such information. The "intra-provider SAVA problem" considers the source address spoofing inside one AS. The "access network SAVA problem" considers the source address spoofing inside one access network. There may be multiple candidate solutions for each sub-problem. Because the source addresses of the packets received and forwarded are not, in general, validated in the Internet today and internet deployment is mature, many possible solutions may be infeasible to deploy under IPv4. The development of the IPv6 based next generation Internet will give us the opportunity to implement architecture supporting validated source addressing. In this memo, only the issues in IPv6 network are discussed. 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 Wu, et al. Expires February 2, 2007 [Page 3] Internet-Draft SAVA Problem Statement August 2006 suggested that a large portion of the Internet is vulnerable to spoofing and concerted attacks employing spoofing remain a serious concern. 3. Best Current Practices The current method of avoiding packets with spoofed source addresses entering and being propagated on the Internet relies on two methods: 1. Ingress Filtering as per BCP0038 [RFC2827]. This method requires ISPs and organisations at the edge to apply filters limiting the source addresses allowed on incoming packets to those specifically allowed in the stub networks. If BCP0038 were followed at all ingress points to the Internet, then there would be no spoofed packets on the Internet. 2. Unicast Reverse Path Forwarding (uRPF) filtering. This is a feature available on routers that can be used to block incoming packets if, in the case a packet were constructed with the incoming packet's source address as its destination address, the constructed packet would NOT be routed back along the ingress link for the incoming packet. Assuming random incidence of spoofed packets and symmetric routing, a router with n links and with uRPF configured would drop (n-1)/n of all incoming spoofed packets, greatly mitigating DoS attacks using spoofed packets, for example. (See [RFC3871]) 4. Deficiencies of Ingress-Filter (BCP0038) and uRPF Approach Ingress filtering is definitely to be recommended, and uRPF filtering certainly does have its uses, but, at least in the current state of the Internet, they are insufficient as a protection of the routing infrastructure. 1. Ingress filtering works, but it only works if all, or at least the vast majority of ingress points apply ingress filtering. As can be seen in the Internet today, even when 25% of the Internet is unsecured, those elements that want access to "spoofable" connections simply move their connection to unsecured attachment points. 2. uRPF does not work well in places where assymetric routing happens. This constitutes a large part of the Internet Wu, et al. Expires February 2, 2007 [Page 4] Internet-Draft SAVA Problem Statement August 2006 5. Why IPSEC is not the Solution to This Problem IPSEC is a solution to many problems, and it is not the intention of the authors to suggest that it should not be deployed. It is just not the solution to this particular problem. Whereas IPSEC solves end-end security problems and allows endpoints in a connection to verify the identity of connected endpoints, there is also a need for the infrastructure of the Internet to be able to protect itself. Many attacks employ spoofed IP addresses to either conceal the source of an infrastructure attack or to cause the network infrastructure to, in effect, attack itself. The network must be able to secure itself from poorly-secured endpoints. The goal of the solution to the problem must be to discard spoofed traffic as close to the source of the attack as possible. (i.e. within the infrastructure rather than at the other endpoint(s). 6. Framework Requirements Following is a list of key requirements for any solution/s to the problem described above. They will be more completely delineated in the proposed workgroup charter and the framework document. 6.1. Direct Benefit to Deployers One of the reasons for the less-than-adequate deployment of ingress filters is that, in deploying the filters, a network operator or attached private network is mostly protecting the rest of the Internet rather than itself. It should be a design goal for any solution to give those that deploy the solution some increased level of protection from spoofed attacks from outside of their own adminitrative domain. 6.2. Solution Focus on IPv6 While it is not the intent to develop solutions that cannot be deployed on an IPv4 network, the focus of the work should be on solutions for IPv6 networks. In other words, if a solution is feasible for IPv6 deployment, but infeasible for IPv4 deployment, that shall not be construed as a disadvantage for the solution. 6.3. Performance Deployment of SAVA solutions should not place unreasonable stress on network infrastructure components. Wu, et al. Expires February 2, 2007 [Page 5] Internet-Draft SAVA Problem Statement August 2006 6.4. Scaling SAVA solutions should be feasible for network sizes and no-default prefix tables many times the size experienced today. SAVA solutions should scale in a way that is at worst linear with the size of the Internet. 6.5. Multiple-Fence Solution Ingress filtering is a single fence solution, in that it is only applicable only at the access network or at the boundary between an attached private network and a network provider. Where the attached network is not a stub, it cannot be deployed effectively. It should be the goal of the SAVA working group to provide solutions that can be deployed at the boundaries between ISPs or on intra-ISP links as well. 6.6. Incrementally Deployable It must be possible to deploy SAVA solutions incrementally across the network. In other words, there can be no "flag day". 6.7. Loose Coupling Components of the overall solution should be able to be deployed in a "mix and match" fashion. this allows for multiple solutions for a given component of the overall solution. 7. Out of Scope Problems 7.1. End-End Validation for Endpoints and Applications End-End validation of endpoint addresses does not protect internet infrastructure and is already covered by IPSEC, where it belongs. 7.2. Source Address Validation for IPv4 Networks The maturity of the IPv4 network means that many potentially workable solutions may be not be feasibly deployable. Rather than limit the scope of the SAVA effort by requiring that solutions be deployable in IPv4 networks, the choice has been made to focus on IPv6 networks only. 8. IANA Considerations This document makes no request of IANA. Wu, et al. Expires February 2, 2007 [Page 6] Internet-Draft SAVA Problem Statement August 2006 Note to RFC Editor: this section may be removed on publication as an RFC. 9. 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. 10. Acknowledgements 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.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 Jianping Wu Tsinghua University Network Research Center, Tsinghua University Beijing, 100084 P.R. China Phone: Email: jianping@cernet.edu.cn URI: Wu, et al. Expires February 2, 2007 [Page 7] Internet-Draft SAVA Problem Statement August 2006 Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing, 100084 P.R. China Phone: Fax: Email: junbi@tsinghua.edu.cn URI: Miao Zhang Tsinghua University Network Research Center, Tsinghua University Beijing, 100084 P.R. China Phone: Fax: Email: zm@cernet.edu.cn URI: Xing Li Tsinghua University Network Research Center, Tsinghua University Beijing, 100084 P.R. China Email: xing@cernet.edu.cn Gang Ren Tsinghua University Network Research Center, Tsinghua University Beijing, 100084 Email: rengang@csnet1.cs.tsinghua.edu.cn URI: Wu, et al. Expires February 2, 2007 [Page 8] Internet-Draft SAVA Problem Statement August 2006 Mark I. Williams Juniper Networks Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave Dong Cheng District, Beijing 100738 P.R. China Email: miw@juniper.net Wu, et al. Expires February 2, 2007 [Page 9] Internet-Draft SAVA Problem Statement August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). Wu, et al. Expires February 2, 2007 [Page 10]