From junbi at tsinghua.edu.cn Wed Aug 23 22:36:41 2006 From: junbi at tsinghua.edu.cn (Jun Bi) Date: Wed Aug 23 23:13:03 2006 Subject: [SAVA] Fw: Time to Post the Call to action for SAVA Message-ID: <00b701c6c6c1$8cbe3020$8018423b@junbipc> ----- Original Message ----- From: "Jun Bi" To: ; "Ross Callon" ; "Ronald Bonica" ; "RenGang" ; "Xing Li" ; ; "Lixia Zhang" Cc: "Eric Yu" ; "Qi Yang" Sent: Wednesday, August 23, 2006 10:36 PM Subject: Re: Time to Post the Call to action for SAVA > Hi Mark, > > The mailing list I have created is SAVA@nrc.tsinghua.edu.cn and the email archive is > http://www.nrc.tsinghua.edu.cn/pipermail/sava/. > > To subscribe the mailing list, please visit http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava. > > The public document server is http://narl.tsinghua.edu.cn/sava. The server is open for everyone > to review. > > Best Regards, > Jun Bi > > ----- Original Message ----- > From: "Mark Williams" > To: "Ross Callon" ; "Jun Bi" ; "Ronald Bonica" ; "RenGang" ; "Xing Li" ; ; "Lixia Zhang" > Cc: "Eric Yu" ; "Qi Yang" > Sent: Wednesday, August 23, 2006 7:28 PM > Subject: Re: Time to Post the Call to action for SAVA > > >> Hi All, >> >> attached please find the text problem statement for SAVA. The intention >> is that I'll post it (perhaps shorn of boilerplate) underneath the call >> to action message text in int-area, ipv6 and routing-discussion. If you >> think this format is inappropriate, please let me know. I mainly chose >> to try to teach myself XML. >> >> Please review and let me have your comments/corrections/additions ASAP. >> Or, of you have comments but don't have time to get them to me by >> tomorrow, please let me know that there will be comments so I can slow >> down. :-) >> >> Prof. Bi, can you please confirm to me: >> >> a) name and of the mailing list we want to use. (I know the server was >> changed, etc. I think I could work it out, but need to get this right!) >> b) instructions as to how to subscribe >> c) URL of the document archive and mailing list archive. >> >> In the meantime, I'll start going over the draft charter that I already >> have and update it so it can be posted to the SAVA mailing list and put >> in the archives at the same time as the call to action goes out. >> >> cheers, >> >> Mark >> >> Ross Callon wrote: >>> >>> I think that I would keep the draft charter discussions on the SAVA list, >>> but when sending the announcements to the other list, perhaps say >>> that the SAVA list will discuss a draft charter. My thinking is that the >>> draft charter discussions might cause quite a bit of email, and perhaps >>> it is better for this email to be on the list dedicated to this purpose. >>> >>> I agree that it is time to send to the three other lists a brief >>> description >>> of what SAVA intends to do, problem statement, and details of how to >>> subscribe to the SAVA list. >>> >>> Thanks, Ross >>> >>> At 05:08 PM 8/21/2006 +0800, Mark Williams wrote: >>> >Hi, Professor Bi, and Ron >>> > >>> >Time to get that post out. I think the consensus of discussions was that >>> >the post should go to int-area, IPv6 and routing-discussion mailing >>> lists, >>> >and that it should have attached: >>> > >>> >a) problem statement >>> >b) details of how to subscribe to the mailing list and get to the archive >>> >c) Maybe a draft charter (although maybe better to put that on the sava >>> >mailing list archive?) >>> > >>> >I think we have all of these, although maybe the draft charter still >>> needs >>> >a bit of work? >>> > >>> >Ron: what's the netiquette on the IETF mailing lists with respect to >>> >posting attachments? a no-no? >>> > >>> >If we can get the right versions of all of these, then I can craft a call >>> >to action email and post it - like to do it this week. >>> > >>> >cheers, >>> > >>> >Mark >>> > >>> >-- >>> >"Product roadmap and/or product discussion in this email set forth >>> >Juniper Networks' current intention and is subject to change at any >>> >time without notice. No purchases are contingent upon Juniper >>> >Networks delivering any feature or functionality expressed or implied >>> >in this roadmap or product discussion." >>> >----------------------------------------------------------------- >>> >Mark Williams Juniper Networks >>> >Liaison Beijing Office >>> >Academic Networking Sector Tel: +86 10 6528 8800 x16032 >>> >Asia Pacific FAX: +61 7 3251 0155 >>> >miw@juniper.net Cell: +86 1370-111-4749 >>> > >>> >> >> -- >> "Product roadmap and/or product discussion in this email set forth >> Juniper Networks' current intention and is subject to change at any >> time without notice. No purchases are contingent upon Juniper >> Networks delivering any feature or functionality expressed or implied >> in this roadmap or product discussion." >> ----------------------------------------------------------------- >> Mark Williams Juniper Networks >> Liaison Beijing Office >> Academic Networking Sector Tel: +86 10 6528 8800 x16032 >> Asia Pacific FAX: +61 7 3251 0155 >> miw@juniper.net Cell: +86 1370-111-4749 >> >> > > > -------------------------------------------------------------------------------- > > >> >> Network Working Group J. Wu >> Internet-Draft Tsinghua University >> Intended status: Experimental R. Bonica >> Expires: February 24, 2007 J. Bi >> Juniper Networks >> X. Li >> G. Ren >> Tsinghua University >> M I. Williams >> Juniper Networks >> August 23, 2006 >> >> >> Source Address Verification 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 24, 2007. >> >> Copyright Notice >> >> Copyright (C) The Internet Society (2006). >> >> Abstract >> >> This document outlines the problems for the Source Address >> Verification 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 >> 2. Current State of Affairs >> 3. Best Current Practices >> 4. Deficiencies of Ingress-Filter (BCP0038) and uRPF Approach >> 5. Why IPSEC is not the Solution to This Problem >> 6. Framework Requirements >> 6.1. Direct Benefit to Deployers >> 6.2. Solution Focus on IPv6 >> 6.3. Performance >> 6.4. Scaling >> 6.5. Multiple-Fence Solution >> 6.6. Incrementally Deployable >> 6.7. Loose Coupling >> 7. IANA Considerations >> 8. Security Considerations >> 9. Acknowledgements >> 10. References >> 10.1. Normative References >> 10.2. Informative References >> Authors' Addresses >> Intellectual Property and Copyright Statements >> >> >> 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, refered as "inter-AS AIAA problem", "intra-AS >> 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-AS SAVA problem" considers the >> source address spoofing involved with more than one ASes. The >> "inter-AS 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 current Internet addressing architecture does not verify >> the source address of the packets received and forwarded, has been >> formed for many years, it is difficult and not cost-effective to >> change from the current Internet infrastructure. The development of >> the IPv6 based next generation Internet will give us the opportunity >> to implement an authentic addressing architecture. 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 >> 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 >> >> >> 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. >> >> 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. IANA Considerations >> >> This document makes no request of IANA. >> >> Note to RFC Editor: this section may be removed on publication as an >> RFC. >> >> >> 8. 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. >> >> >> 9. Acknowledgements >> >> >> 10. References >> >> 10.1. Normative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> 10.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 >> >> >> Phone: >> Email: jianping@cernet.edu.cn >> URI: >> >> >> Ronald P. Bonica >> Juniper Networks >> 2251 Corporate Park Drive >> Herndon, VA 20171 >> USA >> >> >> Jun Bi >> Juniper Networks >> >> Email: junbi@tsinghua.edu.cn >> >> >> Xing Li >> Tsinghua University >> >> >> Email: xing@cernet.edu.cn >> >> >> Gang Ren >> Tsinghua University >> >> Email: rengang@csnet1.cs.tsinghua.edu.cn >> URI: >> >> >> 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 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). >> >>