From miw at juniper.net Thu Feb 15 15:11:25 2007 From: miw at juniper.net (Mark Williams) Date: Thu Feb 15 15:12:13 2007 Subject: [SAVA] Further Call for Interest and Participation: Source Address Validation Architecture (SAVA) Message-ID: <45D4079D.7080801@juniper.net> All, We are again calling for interest and participation in a project to devise a framework architecture and solutions to the problem of validation of source addresses in IPv6 networks in order to protect network infrastructure from address spoofing attacks. This will be the topic of a BoF session at IETF 67 in Prague. (Also, if you will be in Bali for the Apricot 2007 see invitation for an open interim meeting below.) Attached, please find the draft problem statement: draft-wu-sava-problem-statement-00.txt Further drafts proposing a possible framework and a strawman solution design can be found on the ID Website: http://www.ietf.org/internet-drafts/draft-wu-sava-framework-00.txt http://www.ietf.org/internet-drafts/draft-wu-sava-solution-e2e-ipv6-00.txt The effort is based on the current situation that it would seem that, at least as things currently stand, it is unlikely that spoofed source addresses will be able to be excluded from the Internet backbones unless some further solutions and practices are put into place. The SAVA effort has roots in research and development to that end for IPv6 networks currently being undertaken at Tsinghua University in Beijing. A number of papers have been published and code has been written, which is currently under test on the CERNET-II backbone. We seek the participation and assistance of the wider Internet community in order to create a framework of practices and solutions which will be deployable on a much wider basis. A document repository for drafts and other documents is available at: http://narl.tsinghua.edu.cn/sava/ An interim mailing list sava@nrc.tsinghua.edu.cn has been created and can be joined by going to: http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava an archive is also available at the same address. In addition, for those who may be attending the APRICOT 2007 conference in Bali, there will be an OPEN INTERIM MEETING for all interested parties held in Bali just before the main conference track starts. DATE: 27-Feb-2007 Time: 0900-1200 (i.e. before conference proper starts) Venue: Sheraton Laguna Resort, Nusa Dua, Bali (hotel right next to the conference hotel) Please email me if you think you might attend and I'll make sure you are kept up to date with any changes and documents, etc. cheers, Mark ----------------------------------------------------------------- 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 -------------- next part -------------- Network Working Group J. Wu Internet-Draft CERNET Intended status: Experimental R. Bonica Expires: August 18, 2007 Juniper Networks J. Bi X. Li G. Ren CERNET M I. Williams Juniper Networks February 14, 2007 Source Address Validation 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 August 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document outlines the problems for the Source Address Wu, et al. Expires August 18, 2007 [Page 1] Internet-Draft SAVA Problem Statement February 2007 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Wu, et al. Expires August 18, 2007 [Page 2] Internet-Draft SAVA Problem Statement February 2007 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 Wu, et al. Expires August 18, 2007 [Page 3] Internet-Draft SAVA Problem Statement February 2007 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 August 18, 2007 [Page 4] Internet-Draft SAVA Problem Statement February 2007 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 August 18, 2007 [Page 5] Internet-Draft SAVA Problem Statement February 2007 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 Wu, et al. Expires August 18, 2007 [Page 6] Internet-Draft SAVA Problem Statement February 2007 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", 2007. [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 CERNET Network Center, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA Jun Bi CERNET Network Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Wu, et al. Expires August 18, 2007 [Page 7] Internet-Draft SAVA Problem Statement February 2007 Xing Li CERNET Network Center, Tsinghua University Beijing 100084 China Email: xing@cernet.edu.cn Gang Ren CERNET Network Center, Tsinghua University Beijing 100084 China Email: rg03@mails.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 Wu, et al. Expires August 18, 2007 [Page 8] Internet-Draft SAVA Problem Statement February 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). Wu, et al. Expires August 18, 2007 [Page 9] From miw at juniper.net Fri Feb 16 18:16:11 2007 From: miw at juniper.net (Mark Williams) Date: Fri Feb 16 18:18:55 2007 Subject: [SAVA] Re: Further Call for Interest and Participation: Source Address Validation Architecture (SAVA) In-Reply-To: <45D4079D.7080801@juniper.net> References: <45D4079D.7080801@juniper.net> Message-ID: <45D5846B.5090102@juniper.net> All, in response to some concerns about the clash between the meeting in Bali with the APRICOT future of Routing Workshop, we have changed the time for the Bali Interim meeting. I am assured the 2 locations are within 5 minutes of each other. New Details: DATE: 27-Feb-2007 Time: 1245-1545 (working lunch will be supplied.) Venue: Sheraton Laguna Resort, Nusa Dua, Bali (hotel right next to the conference hotel) Please email me if you think you might attend and I'll make sure you are kept up to date with any changes and documents, etc. cheers, Mark Mark Williams wrote: > > All, > > We are again calling for interest and participation in a project to > devise a > framework architecture and solutions to the problem of validation of > source addresses in IPv6 networks in order to protect network > infrastructure from address spoofing attacks. > > This will be the topic of a BoF session at IETF 67 in Prague. > > (Also, if you will be in Bali for the Apricot 2007 see invitation for an > open interim meeting below.) > > Attached, please find the draft problem statement: > draft-wu-sava-problem-statement-00.txt > > Further drafts proposing a possible framework and a strawman solution > design can be found on the ID Website: > http://www.ietf.org/internet-drafts/draft-wu-sava-framework-00.txt > http://www.ietf.org/internet-drafts/draft-wu-sava-solution-e2e-ipv6-00.txt > > The effort is based on the current situation that it would seem that, at > least as things currently stand, it is unlikely that spoofed source > addresses will be able to be excluded from the Internet backbones unless > some further solutions and practices are put into place. > > The SAVA effort has roots in research and development to that end for > IPv6 networks currently being undertaken at Tsinghua University in > Beijing. A number of papers have been published and code has been > written, which is currently under test on the CERNET-II backbone. > We seek the participation and assistance of the wider Internet > community in > order to create a framework of practices and solutions which will be > deployable on a much wider basis. > > A document repository for drafts and other documents is available at: > http://narl.tsinghua.edu.cn/sava/ > > An interim mailing list > sava@nrc.tsinghua.edu.cn > has been created and can be joined by going to: > http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava > an archive is also available at the same address. > > In addition, for those who may be attending the APRICOT 2007 conference > in Bali, there will be an OPEN INTERIM MEETING for all interested > parties held in Bali just before the main conference track starts. > DATE: 27-Feb-2007 > Time: 0900-1200 (i.e. before conference proper starts) > Venue: Sheraton Laguna Resort, Nusa Dua, Bali (hotel right next to the > conference hotel) > Please email me if you think you might attend and I'll make sure you are > kept up to date with > any changes and documents, etc. > > cheers, > > Mark > > ----------------------------------------------------------------- > 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 CERNET > Intended status: Experimental R. Bonica > Expires: August 18, 2007 Juniper Networks > J. Bi > X. Li > G. Ren > CERNET > M I. Williams > Juniper Networks > February 14, 2007 > > > Source Address Validation 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 August 18, 2007. > > Copyright Notice > > Copyright (C) The IETF Trust (2007). > > Abstract > > This document outlines the problems for the Source Address > > > > Wu, et al. Expires August 18, 2007 [Page 1] > > Internet-Draft SAVA Problem Statement February 2007 > > > 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 > 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 > 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 > Intellectual Property and Copyright Statements . . . . . . . . . . 9 > > > > > > > > > > > > > > > > Wu, et al. Expires August 18, 2007 [Page 2] > > Internet-Draft SAVA Problem Statement February 2007 > > > 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 > > > > Wu, et al. Expires August 18, 2007 [Page 3] > > Internet-Draft SAVA Problem Statement February 2007 > > > 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 August 18, 2007 [Page 4] > > Internet-Draft SAVA Problem Statement February 2007 > > > 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 August 18, 2007 [Page 5] > > Internet-Draft SAVA Problem Statement February 2007 > > > 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 > > > > Wu, et al. Expires August 18, 2007 [Page 6] > > Internet-Draft SAVA Problem Statement February 2007 > > > 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", 2007. > > [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 > CERNET > Network Center, Tsinghua University > Beijing 100084 > China > > Email: jianping@cernet.edu.cn > > > Ronald P. Bonica > Juniper Networks > 2251 Corporate Park Drive > Herndon, VA 20171 > USA > > > Jun Bi > CERNET > Network Center, Tsinghua University > Beijing 100084 > China > > Email: junbi@cernet.edu.cn > > > > > > > Wu, et al. Expires August 18, 2007 [Page 7] > > Internet-Draft SAVA Problem Statement February 2007 > > > Xing Li > CERNET > Network Center, Tsinghua University > Beijing 100084 > China > > Email: xing@cernet.edu.cn > > > Gang Ren > CERNET > Network Center, Tsinghua University > Beijing 100084 > China > > Email: rg03@mails.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 > > > > > > > > > > > > > > > > > > > > > > > > > > > Wu, et al. Expires August 18, 2007 [Page 8] > > Internet-Draft SAVA Problem Statement February 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). > > > > > > Wu, et al. Expires August 18, 2007 [Page 9] > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- "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 From junbi at cernet.edu.cn Sat Feb 17 13:36:44 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Sat Feb 17 13:37:05 2007 Subject: [SAVA] test Message-ID: <038001c75255$9c35fc70$3818423b@junbipc> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070217/23caee2e/attachment.htm From junbi at cernet.edu.cn Sun Feb 18 01:52:58 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Sun Feb 18 01:53:16 2007 Subject: [SAVA] Test message Message-ID: <048f01c752bc$7c4870c0$3818423b@junbipc> Hello! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070218/1902c8d9/attachment.htm From junbi at tsinghua.edu.cn Sun Feb 18 01:52:26 2007 From: junbi at tsinghua.edu.cn (Jun Bi) Date: Sun Feb 18 02:32:57 2007 Subject: [SAVA] Test message Message-ID: <047c01c752bc$62f4d410$3818423b@junbipc> Test message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070218/8093a0cb/attachment.htm From junbi at tsinghua.edu.cn Sun Feb 18 02:31:26 2007 From: junbi at tsinghua.edu.cn (Jun Bi) Date: Sun Feb 18 02:32:57 2007 Subject: [SAVA] Fw: Test message Message-ID: <04ce01c752c1$d80bb480$3818423b@junbipc> ----- Original Message ----- From: Jun Bi To: sava@nrc.tsinghua.edu.cn Sent: Sunday, February 18, 2007 1:52 AM Subject: Test message Hello! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070218/84b2cb7f/attachment.htm From junbi at tsinghua.edu.cn Sun Feb 18 02:35:21 2007 From: junbi at tsinghua.edu.cn (Jun Bi) Date: Sun Feb 18 02:35:33 2007 Subject: [SAVA] test Message-ID: <050301c752c2$61c08b10$3818423b@junbipc> test -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070218/c2d3d358/attachment.htm From junbi at tsinghua.edu.cn Sun Feb 18 02:38:01 2007 From: junbi at tsinghua.edu.cn (Jun Bi) Date: Sun Feb 18 02:38:13 2007 Subject: [SAVA] test Message-ID: <052701c752c2$c0ad89c0$3818423b@junbipc> test -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070218/ba82b400/attachment.htm From miw at juniper.net Mon Feb 26 22:01:45 2007 From: miw at juniper.net (Mark Williams) Date: Mon Feb 26 22:07:02 2007 Subject: [SAVA] draft-wu-sava-testbed-experience.txt Message-ID: <45E2E849.70206@juniper.net> All, please find attached a new draft describing the CERNET-II sava testbed and three prototype solutions that have been tested on it. 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 -------------- next part -------------- Network Working Group J. Wu Internet-Draft J. Bi Intended status: Experimental Tsinghua University Expires: August 29, 2007 M. Williams Juniper Networks Feb 25, 2007 SAVA Testbed and Experiences to Date draft-wu-sava-testbed-experience-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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This draft describes the testbed installed at Tsinghua University and other Universities in China attached to the CERNET-II IPv6 backbone, some SAVA testing that has been carried out on that network and some preliminary results of that testing. Wu, et al. Expires August 29, 2007 [Page 1] Internet-Draft SAVA Testbed Feb 2007 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. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. CERNET2 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. SAVA Testbed on CERNET2 Infrastructure . . . . . . . . . . 3 3. SAVA Solutions Tested and Experiences . . . . . . . . . . . . 5 3.1. Inter-ISP Case (Neighbouring AS) . . . . . . . . . . . . . 5 3.2. Inter-ISP Case (Intervening AS) . . . . . . . . . . . . . 8 3.3. Intra-ISP (Access Network) Case . . . . . . . . . . . . . 9 4. Test Experience . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Wu, et al. Expires August 29, 2007 [Page 2] Internet-Draft SAVA Testbed Feb 2007 1. Introduction The problem addressed in the Source Address Validation Architecture activity is outlined in [I-D.wu-sava-problem-statement] and a proposed solution framework for discussion is outlined in [I-D.wu-sava-framework]. Some potential procedures that could be used as solution elements in the framework have been devised and one is introduced and discussed in [I-D.wu-sava-solution-e2e-ipv6]. It should be stressed that at this early stage, the solutions proposed in the solution document are not intended to pre-empt work carried out by the IETF in the solution space. Indeed, consensus must be reached on a framework before solution work can be fully undertaken. The shape of the "holes" needs to be established before the "pegs" can be carved. Furthermore, it is envisaged that more than one solution could be devised and deployed for each of the proposed solution elements required under the framework, in keeping with the requirement for a loosely-coupled architecture and, as far as possible, a plug-and-play framework. The intention of the solutions documents is to provide some solution ideas which can be implemented on the testbed described in this document. This document describes the testbed and the solutions implemented and tested on it to date. 2. SAVA Testbed 2.1. CERNET2 CERNET2 is one of the China Next Generation Internet (CNGI) backbones. CERNET2 connects 25 core nodes distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The CERNET2 backbone is an IPv6- only network. 2.2. SAVA Testbed on CERNET2 Infrastructure It is intended that eventually the SAVA testbed will be implemented directly on the CERNET2 backbone, but in the early stages the testbed has been implemented as an overlay structure on top of CERNET2. This is because first, some of the algorithms need to be implemented in the testbed routers themselves and to date they have not been implemented on any of the commercial routers forming the CERNET2 backbone. Second, since CERNET2 is a production backbone, any new protocols and networking techniques need to be tested in a non- disruptive way. Wu, et al. Expires August 29, 2007 [Page 3] Internet-Draft SAVA Testbed Feb 2007 --------------- | Transit AS | --------------- | | ------ ------ |ASBR| |ASBR| ------ ------ | | | | Inter-ISP | | layer ........|...........|................. ------ ------ |ASBR| |ASBR| ------ ------ | | ----- ----- |AS1| |AS2| ----- ----- | | Intra-ISP | | layer ........|...........|................. | | ----- ----- |ASw| |ASw| Access ----- ----- layer | | ---------- ---------- | access | | access | | net | | net | ---------- ---------- | | ----- ----- | H1| |H2 | ----- ----- Figure 1: SAVA Framework Layers Notwithstanding the aforementioned restrictions on the early testbed, the testbed is fully capable of functional testing of solutions for all parts of the SAVA solution framework. Namely, it is possible to test procedures for ensuring the validity of IPv6 source addresses in the access network and in packets sent from the access network to an IPv6 service provider, packets sent within one service provider's network, packets sent between neighboring service providers and packets sent between service providers separated by an intervening transit network. The testbed is distributed across 7 universities connected to Wu, et al. Expires August 29, 2007 [Page 4] Internet-Draft SAVA Testbed Feb 2007 CERNET2, namely Tsinghua University, Beijing University, Beijing University of Post and Telecommunications, Shanghai Jiaotong University, Wuhan Polytechnic University, Southeast University in Nanjing, and South China Polytechnic University in Guangzhou. Each of the university installations is connected to the CERNET2 backbone through a set of inter-ISP filtering and monitoring equipment. (Inter-ISP Layer). Of the installations, the installation at Tsinghua University is the most fully-featured, with inter-ISP, Intra-ISP and access layer validation all able to be tested. In addition, a suite of applications that could be subject to spoofing attacks or which can be subverted to carry out spoofing attacks are installed on a variety of servers. The Tsingua testbed consists of three separate Autonomous systems joined by MBGP speakers. to be added Figure 2: CERNET2 Overlay SAVA Test Environment to be added Figure 3: Tsinghua University Trustable Internet Test Network to be added Figure 4: Tsinghua University Network AS100 detail to be added Figure 5: Tsinghua University Test Network AS200 Detail to be added Figure 6: Tsinghua University Test Network AS300 Detail 3. SAVA Solutions Tested and Experiences 3.1. Inter-ISP Case (Neighbouring AS) Wu, et al. Expires August 29, 2007 [Page 5] Internet-Draft SAVA Testbed Feb 2007 --------- | AIMS | ------|- | -------------- -----------|----- | AS-4 |----- ------| AS-1 | |----- | |ASBR |----->|ASBR | ------|- |ASBR |---> Global IPv6 | |----- ------| | VRGE | |----- Network --------------- | -------- | ----- ----------------- |ASBR| |ASBR| ------ ------ / | / | / | / | ---------- ----- |ASBR, VE| |ASBR| --------------- ------------- | AS-2 | | AS-3 | | | | | | | | | | | | | --------------- ------------- Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule Generating Engine, VE == Validating Engine Figure 7: Inter-ISP (Neighboring AS) Setup In the solution implemented on the testbed, the solution for the validation of IPv6 prefixes is separated into three functional modules: The Validation Rule Generating Engine (VRGE), the Validation Engine (VE) and the the AS-IPv6 prefix Mapping Server. (AIMS). Validation rules (VR) that are generated by the VRGE are expressed as IPv6 address prefixes. The VRGE generates validation rules, and each AS has one. In the testbed, these are implemented on a LINUX server. The VE loads validation rules generated by VRGE to filter packets passed between ASs (In the case of Figure 7, from neighbouring ASs into AS-1. In the SAVA testbed, the VE is implemented as a simulated L2 device on a Linux-based machine inserted into the data path just outside each ASBR interface that faces a neigbouring AS, but in a real-world implementation it would probably be implemented as a packet filter set on the ASBR. The AS-IPv6 prefix mapping server is also implemented on a Linux machine and derives a mapping between IPv6 Wu, et al. Expires August 29, 2007 [Page 6] Internet-Draft SAVA Testbed Feb 2007 prefix and the AS of that prefix's "entry" into the region of validated IPv6 prefixed by processing AS-Path information. The rules are derived according to the table below, as described in [Gao]. --------------------------------------------------------------------------- | \Export| Own | Customer's| Sibling's | Providor's | Peer's | |To \ | Address | Address | Address | Address | Address | |-----\-------------------------------------------------------------------| | Providor | Y | Y | Y | | | |-------------------------------------------------------------------------| | Customer | Y | Y | Y | Y | Y | |-------------------------------------------------------------------------| | Peer | Y | Y | Y | | | |-------------------------------------------------------------------------| | Sibling | Y | Y | Y | Y | Y | --------------------------------------------------------------------------- Figure 8: AS-Relation Based Inter-AS Filtering Different ASes exchange and transmit VR information using the AS- relation-based export rules in the VR generation server. As per Figure 8, an AS exports the address prefixes of its own , its customers, its providers, it siblings and its peers to its customers and siblings as valid prefixes, while it only exports the address prefixes of its own, its customers and its siblings to its providers and peers as valid prefixes. With the support of AS Number to IPv6 Address Mapping service, only AS numbers of valid address prefixes are transferred between ASes and the AS number is mapped to address prefixes at the VRGE. Only changes of AS relation and changes of IP address prefixes belonging to an AS require the generation of VR updates. The procedure's principle steps are as folows (as seen by AS-1 in Figure 7): 1. When the VRG has initialised, it reads the AS neighbour table and establishes TCP connections to all the VEs in its own AS. 2. The VRGE initiates a VR renewal. According to its export table, it sends its own originated IPv6 prefixes to neighbouring ASs VRGEs. Rules are expressed as AS numbers. 3. When a VRGE receives the new rules from its neighbour, it then uses its own export table to decide whether it should accept the rules and, if it accepts a rule, whether or not it should re- export the rule to other neighbouring ASs. Wu, et al. Expires August 29, 2007 [Page 7] Internet-Draft SAVA Testbed Feb 2007 4. If the VRGE accepts a rule, it used the AIMS to transform AS- expressed rules into IPv6 refix-expressed rules. 5. The VRGE then pushes the thus-generated rules to all the VEs in its AS. The VEs then use these prefix-based rules to filter incoming packets. 3.2. Inter-ISP Case (Intervening AS) In the case where two ASs do not exchange packets directly, it s not possibe to deploy a solution like that in the previous section. However, it is highly desirable for non-neighbouring ISPs to be able to form a trust alliance such that packets leaving one AS will be recognised by the other and inherit the validation status they possessed on leaving the first AS. There is more than one way to do this. For the SAVA experiments to date, the signature method detailed in [I-D.wu-sava-solution-e2e-ipv6] has been used. This particular method uses a weak signature. +-----+ | REG | +-----+ ,-------------- ,-------------- ,' ` `. ,' ` `. / \ / \ / \ / \ ; +-----+ +----+ +----+ +-----+ ; | | ASC | |AER | |AER | | ASC | | : +-----+ +----+` +----+ +-----+ : \ / \ / \ / \ / `. ,' `. ,' '-------------' '-------------' AS-1 AS-2 KEY: REG == Registration Server, ASC == AS Control Server, AER == AS Edge Router. Figure 9: Validation Setup Between non-Neighbouring ASs There are three major components in the system: the Registration Server(REG), the AS Control Server(ASC), and the AS Edge Router(AER). The Registration Server is the "center" of the trust alliance (TA) . It maintains a member list for the TA. It performs two major functions: Wu, et al. Expires August 29, 2007 [Page 8] Internet-Draft SAVA Testbed Feb 2007 o Processes requests from the AS Control Server, to get the member list for the TA. o When the member list is changed, notifiy each AS Control Server. Each AS deploying the method should have an AS Control Server. The AS Control Server has three major functions: o Communicate with the Registration Server, to get the up-to-date member list of TA. o Communicate with the AS Control Server in other member AS in the TA, to exchange updates of prefix ownership information, and to exchange signatures. o Communicate with all edge routers of the local AS, to configure the processing component on the edge routers. The AS Edge Router does the work of adding signature to the packet at the sending AS, and the work of verifying and removing the signature at the destination AS. In the design of this system, in order to decrease the burden on the REG, most of the control traffic happens between ASCs. 3.3. Intra-ISP (Access Network) Case Assuming an ISP has implemented source address validation on its connection to peers and transit providers, the intra-ISP case reverts to access validation. There are many options for access validation, including BCP38 filtering, depending on the strength of validation required. The solution tested in the SAVA testbed takes the strongest requirement for validation in the access network. That is, any IPv6 address should have a unique association with an entity that is specifically authorised to use that IPv6 address. (BCP38 filtering, on the other hand typically only requires that the source address of a packet entering the provider network belong to a prefix that is allocated to or has transit through the attached access network.) An Extended Access Control Protocol is used in order to distribute authorised IPv6 addreses to end-users and to ensure a record of the authorised user and the corresponding IPv6 address and MAC address for each port of the access switch. As a result it is possible for the access switch to filter any packets sent by the user (or sokmeone pretending to be the user) that do not carry the authorised IPv6 source address and the corresponding MAC address. The SAVA extendes access control used for this proof of concept follows the following 4 Wu, et al. Expires August 29, 2007 [Page 9] Internet-Draft SAVA Testbed Feb 2007 steps: 1. End user sends an identity verification supplication, and the access switch sends a RADIUS request to the SAVA access validation server. 2. On successful establishment of identity, the SAVA access validation server issues an authorised IPv6 address for the user. 3. The access switch, on receiving the RADIUS authentication success message combines the embedded IPv6 address, the end-user identity, end-user MAC address and the switch port number into a binding relationship. In addition, it sends the issued address to the end-user host. 4. The access switch begins to filter packets sent from the end-user host. Packets which do not conform to an authorised (MAC SA, IPv6 SA, Switch Port) tuple are discarded. 4. Test Experience The solutions outlined above have been implemented on the testbed described above. Successful testing of all solutions has been carried out. A more detailed discussion will be forthcoming in the next version of this draft. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wu, et al. Expires August 29, 2007 [Page 10] Internet-Draft SAVA Testbed Feb 2007 8.2. Informative References [Gao] Gao, L., "On Inferring Autonomous System Relationships in the Internet", Infocom 2001, December 2001. [I-D.wu-sava-framework] Wu, J., "Source Address Validation Architecture (SAVA) Framework", draft-wu-sava-framework-00 (work in progress), February 2007. [I-D.wu-sava-problem-statement] Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I. Williams, "Source Address Validation Architecture (SAVA) Problem Statement", February 2007. [I-D.wu-sava-solution-e2e-ipv6] Wu, J., "An End-to-end Source Address Validation Solution for IPv6", draft-wu-sava-solution-e2e-ipv6-00 (work in progress), February 2007. Authors' Addresses Jianping Wu Tsinghua University Phone: Fax: Email: jianping@cernet.edu.cn URI: Jun Bi Tsinghua University Phone: Fax: Email: junbi@tsinghua.edu.cn URI: Wu, et al. Expires August 29, 2007 [Page 11] Internet-Draft SAVA Testbed Feb 2007 Mark Williams Juniper Networks Phone: Fax: Email: miw@juniper.net URI: Wu, et al. Expires August 29, 2007 [Page 12] Internet-Draft SAVA Testbed Feb 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). Wu, et al. Expires August 29, 2007 [Page 13] From miw at juniper.net Mon Feb 26 22:10:49 2007 From: miw at juniper.net (Mark Williams) Date: Mon Feb 26 22:14:05 2007 Subject: [SAVA] draft-wu-sava-testbed-experience.txt Message-ID: <45E2EA69.9020200@juniper.net> All, please find attached a new draft describing the CERNET-II sava testbed and three prototype solutions that have been tested on it. Because the network access here is so bad, and because cutoff was 9am ET on 26th rather than 5pm which I had assumed, I think the posting missed the cutoff by 3 minutes. (but the SMTP connection was opened before the cutoff. :-)) 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 -------------- next part -------------- Network Working Group J. Wu Internet-Draft J. Bi Intended status: Experimental Tsinghua University Expires: August 29, 2007 M. Williams Juniper Networks Feb 25, 2007 SAVA Testbed and Experiences to Date draft-wu-sava-testbed-experience-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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This draft describes the testbed installed at Tsinghua University and other Universities in China attached to the CERNET-II IPv6 backbone, some SAVA testing that has been carried out on that network and some preliminary results of that testing. Wu, et al. Expires August 29, 2007 [Page 1] Internet-Draft SAVA Testbed Feb 2007 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. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. CERNET2 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. SAVA Testbed on CERNET2 Infrastructure . . . . . . . . . . 3 3. SAVA Solutions Tested and Experiences . . . . . . . . . . . . 5 3.1. Inter-ISP Case (Neighbouring AS) . . . . . . . . . . . . . 5 3.2. Inter-ISP Case (Intervening AS) . . . . . . . . . . . . . 8 3.3. Intra-ISP (Access Network) Case . . . . . . . . . . . . . 9 4. Test Experience . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Wu, et al. Expires August 29, 2007 [Page 2] Internet-Draft SAVA Testbed Feb 2007 1. Introduction The problem addressed in the Source Address Validation Architecture activity is outlined in [I-D.wu-sava-problem-statement] and a proposed solution framework for discussion is outlined in [I-D.wu-sava-framework]. Some potential procedures that could be used as solution elements in the framework have been devised and one is introduced and discussed in [I-D.wu-sava-solution-e2e-ipv6]. It should be stressed that at this early stage, the solutions proposed in the solution document are not intended to pre-empt work carried out by the IETF in the solution space. Indeed, consensus must be reached on a framework before solution work can be fully undertaken. The shape of the "holes" needs to be established before the "pegs" can be carved. Furthermore, it is envisaged that more than one solution could be devised and deployed for each of the proposed solution elements required under the framework, in keeping with the requirement for a loosely-coupled architecture and, as far as possible, a plug-and-play framework. The intention of the solutions documents is to provide some solution ideas which can be implemented on the testbed described in this document. This document describes the testbed and the solutions implemented and tested on it to date. 2. SAVA Testbed 2.1. CERNET2 CERNET2 is one of the China Next Generation Internet (CNGI) backbones. CERNET2 connects 25 core nodes distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The CERNET2 backbone is an IPv6- only network. 2.2. SAVA Testbed on CERNET2 Infrastructure It is intended that eventually the SAVA testbed will be implemented directly on the CERNET2 backbone, but in the early stages the testbed has been implemented as an overlay structure on top of CERNET2. This is because first, some of the algorithms need to be implemented in the testbed routers themselves and to date they have not been implemented on any of the commercial routers forming the CERNET2 backbone. Second, since CERNET2 is a production backbone, any new protocols and networking techniques need to be tested in a non- disruptive way. Wu, et al. Expires August 29, 2007 [Page 3] Internet-Draft SAVA Testbed Feb 2007 --------------- | Transit AS | --------------- | | ------ ------ |ASBR| |ASBR| ------ ------ | | | | Inter-ISP | | layer ........|...........|................. ------ ------ |ASBR| |ASBR| ------ ------ | | ----- ----- |AS1| |AS2| ----- ----- | | Intra-ISP | | layer ........|...........|................. | | ----- ----- |ASw| |ASw| Access ----- ----- layer | | ---------- ---------- | access | | access | | net | | net | ---------- ---------- | | ----- ----- | H1| |H2 | ----- ----- Figure 1: SAVA Framework Layers Notwithstanding the aforementioned restrictions on the early testbed, the testbed is fully capable of functional testing of solutions for all parts of the SAVA solution framework. Namely, it is possible to test procedures for ensuring the validity of IPv6 source addresses in the access network and in packets sent from the access network to an IPv6 service provider, packets sent within one service provider's network, packets sent between neighboring service providers and packets sent between service providers separated by an intervening transit network. The testbed is distributed across 7 universities connected to Wu, et al. Expires August 29, 2007 [Page 4] Internet-Draft SAVA Testbed Feb 2007 CERNET2, namely Tsinghua University, Beijing University, Beijing University of Post and Telecommunications, Shanghai Jiaotong University, Wuhan Polytechnic University, Southeast University in Nanjing, and South China Polytechnic University in Guangzhou. Each of the university installations is connected to the CERNET2 backbone through a set of inter-ISP filtering and monitoring equipment. (Inter-ISP Layer). Of the installations, the installation at Tsinghua University is the most fully-featured, with inter-ISP, Intra-ISP and access layer validation all able to be tested. In addition, a suite of applications that could be subject to spoofing attacks or which can be subverted to carry out spoofing attacks are installed on a variety of servers. The Tsingua testbed consists of three separate Autonomous systems joined by MBGP speakers. to be added Figure 2: CERNET2 Overlay SAVA Test Environment to be added Figure 3: Tsinghua University Trustable Internet Test Network to be added Figure 4: Tsinghua University Network AS100 detail to be added Figure 5: Tsinghua University Test Network AS200 Detail to be added Figure 6: Tsinghua University Test Network AS300 Detail 3. SAVA Solutions Tested and Experiences 3.1. Inter-ISP Case (Neighbouring AS) Wu, et al. Expires August 29, 2007 [Page 5] Internet-Draft SAVA Testbed Feb 2007 --------- | AIMS | ------|- | -------------- -----------|----- | AS-4 |----- ------| AS-1 | |----- | |ASBR |----->|ASBR | ------|- |ASBR |---> Global IPv6 | |----- ------| | VRGE | |----- Network --------------- | -------- | ----- ----------------- |ASBR| |ASBR| ------ ------ / | / | / | / | ---------- ----- |ASBR, VE| |ASBR| --------------- ------------- | AS-2 | | AS-3 | | | | | | | | | | | | | --------------- ------------- Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule Generating Engine, VE == Validating Engine Figure 7: Inter-ISP (Neighboring AS) Setup In the solution implemented on the testbed, the solution for the validation of IPv6 prefixes is separated into three functional modules: The Validation Rule Generating Engine (VRGE), the Validation Engine (VE) and the the AS-IPv6 prefix Mapping Server. (AIMS). Validation rules (VR) that are generated by the VRGE are expressed as IPv6 address prefixes. The VRGE generates validation rules, and each AS has one. In the testbed, these are implemented on a LINUX server. The VE loads validation rules generated by VRGE to filter packets passed between ASs (In the case of Figure 7, from neighbouring ASs into AS-1. In the SAVA testbed, the VE is implemented as a simulated L2 device on a Linux-based machine inserted into the data path just outside each ASBR interface that faces a neigbouring AS, but in a real-world implementation it would probably be implemented as a packet filter set on the ASBR. The AS-IPv6 prefix mapping server is also implemented on a Linux machine and derives a mapping between IPv6 Wu, et al. Expires August 29, 2007 [Page 6] Internet-Draft SAVA Testbed Feb 2007 prefix and the AS of that prefix's "entry" into the region of validated IPv6 prefixed by processing AS-Path information. The rules are derived according to the table below, as described in [Gao]. --------------------------------------------------------------------------- | \Export| Own | Customer's| Sibling's | Providor's | Peer's | |To \ | Address | Address | Address | Address | Address | |-----\-------------------------------------------------------------------| | Providor | Y | Y | Y | | | |-------------------------------------------------------------------------| | Customer | Y | Y | Y | Y | Y | |-------------------------------------------------------------------------| | Peer | Y | Y | Y | | | |-------------------------------------------------------------------------| | Sibling | Y | Y | Y | Y | Y | --------------------------------------------------------------------------- Figure 8: AS-Relation Based Inter-AS Filtering Different ASes exchange and transmit VR information using the AS- relation-based export rules in the VR generation server. As per Figure 8, an AS exports the address prefixes of its own , its customers, its providers, it siblings and its peers to its customers and siblings as valid prefixes, while it only exports the address prefixes of its own, its customers and its siblings to its providers and peers as valid prefixes. With the support of AS Number to IPv6 Address Mapping service, only AS numbers of valid address prefixes are transferred between ASes and the AS number is mapped to address prefixes at the VRGE. Only changes of AS relation and changes of IP address prefixes belonging to an AS require the generation of VR updates. The procedure's principle steps are as folows (as seen by AS-1 in Figure 7): 1. When the VRG has initialised, it reads the AS neighbour table and establishes TCP connections to all the VEs in its own AS. 2. The VRGE initiates a VR renewal. According to its export table, it sends its own originated IPv6 prefixes to neighbouring ASs VRGEs. Rules are expressed as AS numbers. 3. When a VRGE receives the new rules from its neighbour, it then uses its own export table to decide whether it should accept the rules and, if it accepts a rule, whether or not it should re- export the rule to other neighbouring ASs. Wu, et al. Expires August 29, 2007 [Page 7] Internet-Draft SAVA Testbed Feb 2007 4. If the VRGE accepts a rule, it used the AIMS to transform AS- expressed rules into IPv6 refix-expressed rules. 5. The VRGE then pushes the thus-generated rules to all the VEs in its AS. The VEs then use these prefix-based rules to filter incoming packets. 3.2. Inter-ISP Case (Intervening AS) In the case where two ASs do not exchange packets directly, it s not possibe to deploy a solution like that in the previous section. However, it is highly desirable for non-neighbouring ISPs to be able to form a trust alliance such that packets leaving one AS will be recognised by the other and inherit the validation status they possessed on leaving the first AS. There is more than one way to do this. For the SAVA experiments to date, the signature method detailed in [I-D.wu-sava-solution-e2e-ipv6] has been used. This particular method uses a weak signature. +-----+ | REG | +-----+ ,-------------- ,-------------- ,' ` `. ,' ` `. / \ / \ / \ / \ ; +-----+ +----+ +----+ +-----+ ; | | ASC | |AER | |AER | | ASC | | : +-----+ +----+` +----+ +-----+ : \ / \ / \ / \ / `. ,' `. ,' '-------------' '-------------' AS-1 AS-2 KEY: REG == Registration Server, ASC == AS Control Server, AER == AS Edge Router. Figure 9: Validation Setup Between non-Neighbouring ASs There are three major components in the system: the Registration Server(REG), the AS Control Server(ASC), and the AS Edge Router(AER). The Registration Server is the "center" of the trust alliance (TA) . It maintains a member list for the TA. It performs two major functions: Wu, et al. Expires August 29, 2007 [Page 8] Internet-Draft SAVA Testbed Feb 2007 o Processes requests from the AS Control Server, to get the member list for the TA. o When the member list is changed, notifiy each AS Control Server. Each AS deploying the method should have an AS Control Server. The AS Control Server has three major functions: o Communicate with the Registration Server, to get the up-to-date member list of TA. o Communicate with the AS Control Server in other member AS in the TA, to exchange updates of prefix ownership information, and to exchange signatures. o Communicate with all edge routers of the local AS, to configure the processing component on the edge routers. The AS Edge Router does the work of adding signature to the packet at the sending AS, and the work of verifying and removing the signature at the destination AS. In the design of this system, in order to decrease the burden on the REG, most of the control traffic happens between ASCs. 3.3. Intra-ISP (Access Network) Case Assuming an ISP has implemented source address validation on its connection to peers and transit providers, the intra-ISP case reverts to access validation. There are many options for access validation, including BCP38 filtering, depending on the strength of validation required. The solution tested in the SAVA testbed takes the strongest requirement for validation in the access network. That is, any IPv6 address should have a unique association with an entity that is specifically authorised to use that IPv6 address. (BCP38 filtering, on the other hand typically only requires that the source address of a packet entering the provider network belong to a prefix that is allocated to or has transit through the attached access network.) An Extended Access Control Protocol is used in order to distribute authorised IPv6 addreses to end-users and to ensure a record of the authorised user and the corresponding IPv6 address and MAC address for each port of the access switch. As a result it is possible for the access switch to filter any packets sent by the user (or sokmeone pretending to be the user) that do not carry the authorised IPv6 source address and the corresponding MAC address. The SAVA extendes access control used for this proof of concept follows the following 4 Wu, et al. Expires August 29, 2007 [Page 9] Internet-Draft SAVA Testbed Feb 2007 steps: 1. End user sends an identity verification supplication, and the access switch sends a RADIUS request to the SAVA access validation server. 2. On successful establishment of identity, the SAVA access validation server issues an authorised IPv6 address for the user. 3. The access switch, on receiving the RADIUS authentication success message combines the embedded IPv6 address, the end-user identity, end-user MAC address and the switch port number into a binding relationship. In addition, it sends the issued address to the end-user host. 4. The access switch begins to filter packets sent from the end-user host. Packets which do not conform to an authorised (MAC SA, IPv6 SA, Switch Port) tuple are discarded. 4. Test Experience The solutions outlined above have been implemented on the testbed described above. Successful testing of all solutions has been carried out. A more detailed discussion will be forthcoming in the next version of this draft. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wu, et al. Expires August 29, 2007 [Page 10] Internet-Draft SAVA Testbed Feb 2007 8.2. Informative References [Gao] Gao, L., "On Inferring Autonomous System Relationships in the Internet", Infocom 2001, December 2001. [I-D.wu-sava-framework] Wu, J., "Source Address Validation Architecture (SAVA) Framework", draft-wu-sava-framework-00 (work in progress), February 2007. [I-D.wu-sava-problem-statement] Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I. Williams, "Source Address Validation Architecture (SAVA) Problem Statement", February 2007. [I-D.wu-sava-solution-e2e-ipv6] Wu, J., "An End-to-end Source Address Validation Solution for IPv6", draft-wu-sava-solution-e2e-ipv6-00 (work in progress), February 2007. Authors' Addresses Jianping Wu Tsinghua University Phone: Fax: Email: jianping@cernet.edu.cn URI: Jun Bi Tsinghua University Phone: Fax: Email: junbi@tsinghua.edu.cn URI: Wu, et al. Expires August 29, 2007 [Page 11] Internet-Draft SAVA Testbed Feb 2007 Mark Williams Juniper Networks Phone: Fax: Email: miw@juniper.net URI: Wu, et al. Expires August 29, 2007 [Page 12] Internet-Draft SAVA Testbed Feb 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). Wu, et al. Expires August 29, 2007 [Page 13] From miw at juniper.net Mon Feb 26 22:16:52 2007 From: miw at juniper.net (Mark Williams) Date: Mon Feb 26 22:17:25 2007 Subject: [SAVA] draft-wu-sava-testbed-experience.txt Message-ID: <45E2EBD4.9060304@juniper.net> All, please find attached a new draft describing the CERNET-II sava testbed and three prototype solutions that have been tested on it. Because the network access here is so bad, and because cutoff was 9am ET on 26th rather than 5pm which I had assumed, I think the posting missed the cutoff by 3 minutes. (but the SMTP connection was opened before the cutoff. :-)) 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 -------------- next part -------------- Network Working Group J. Wu Internet-Draft J. Bi Intended status: Experimental Tsinghua University Expires: August 29, 2007 M. Williams Juniper Networks Feb 25, 2007 SAVA Testbed and Experiences to Date draft-wu-sava-testbed-experience-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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This draft describes the testbed installed at Tsinghua University and other Universities in China attached to the CERNET-II IPv6 backbone, some SAVA testing that has been carried out on that network and some preliminary results of that testing. Wu, et al. Expires August 29, 2007 [Page 1] Internet-Draft SAVA Testbed Feb 2007 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. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. CERNET2 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. SAVA Testbed on CERNET2 Infrastructure . . . . . . . . . . 3 3. SAVA Solutions Tested and Experiences . . . . . . . . . . . . 5 3.1. Inter-ISP Case (Neighbouring AS) . . . . . . . . . . . . . 5 3.2. Inter-ISP Case (Intervening AS) . . . . . . . . . . . . . 8 3.3. Intra-ISP (Access Network) Case . . . . . . . . . . . . . 9 4. Test Experience . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Wu, et al. Expires August 29, 2007 [Page 2] Internet-Draft SAVA Testbed Feb 2007 1. Introduction The problem addressed in the Source Address Validation Architecture activity is outlined in [I-D.wu-sava-problem-statement] and a proposed solution framework for discussion is outlined in [I-D.wu-sava-framework]. Some potential procedures that could be used as solution elements in the framework have been devised and one is introduced and discussed in [I-D.wu-sava-solution-e2e-ipv6]. It should be stressed that at this early stage, the solutions proposed in the solution document are not intended to pre-empt work carried out by the IETF in the solution space. Indeed, consensus must be reached on a framework before solution work can be fully undertaken. The shape of the "holes" needs to be established before the "pegs" can be carved. Furthermore, it is envisaged that more than one solution could be devised and deployed for each of the proposed solution elements required under the framework, in keeping with the requirement for a loosely-coupled architecture and, as far as possible, a plug-and-play framework. The intention of the solutions documents is to provide some solution ideas which can be implemented on the testbed described in this document. This document describes the testbed and the solutions implemented and tested on it to date. 2. SAVA Testbed 2.1. CERNET2 CERNET2 is one of the China Next Generation Internet (CNGI) backbones. CERNET2 connects 25 core nodes distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The CERNET2 backbone is an IPv6- only network. 2.2. SAVA Testbed on CERNET2 Infrastructure It is intended that eventually the SAVA testbed will be implemented directly on the CERNET2 backbone, but in the early stages the testbed has been implemented as an overlay structure on top of CERNET2. This is because first, some of the algorithms need to be implemented in the testbed routers themselves and to date they have not been implemented on any of the commercial routers forming the CERNET2 backbone. Second, since CERNET2 is a production backbone, any new protocols and networking techniques need to be tested in a non- disruptive way. Wu, et al. Expires August 29, 2007 [Page 3] Internet-Draft SAVA Testbed Feb 2007 --------------- | Transit AS | --------------- | | ------ ------ |ASBR| |ASBR| ------ ------ | | | | Inter-ISP | | layer ........|...........|................. ------ ------ |ASBR| |ASBR| ------ ------ | | ----- ----- |AS1| |AS2| ----- ----- | | Intra-ISP | | layer ........|...........|................. | | ----- ----- |ASw| |ASw| Access ----- ----- layer | | ---------- ---------- | access | | access | | net | | net | ---------- ---------- | | ----- ----- | H1| |H2 | ----- ----- Figure 1: SAVA Framework Layers Notwithstanding the aforementioned restrictions on the early testbed, the testbed is fully capable of functional testing of solutions for all parts of the SAVA solution framework. Namely, it is possible to test procedures for ensuring the validity of IPv6 source addresses in the access network and in packets sent from the access network to an IPv6 service provider, packets sent within one service provider's network, packets sent between neighboring service providers and packets sent between service providers separated by an intervening transit network. The testbed is distributed across 7 universities connected to Wu, et al. Expires August 29, 2007 [Page 4] Internet-Draft SAVA Testbed Feb 2007 CERNET2, namely Tsinghua University, Beijing University, Beijing University of Post and Telecommunications, Shanghai Jiaotong University, Wuhan Polytechnic University, Southeast University in Nanjing, and South China Polytechnic University in Guangzhou. Each of the university installations is connected to the CERNET2 backbone through a set of inter-ISP filtering and monitoring equipment. (Inter-ISP Layer). Of the installations, the installation at Tsinghua University is the most fully-featured, with inter-ISP, Intra-ISP and access layer validation all able to be tested. In addition, a suite of applications that could be subject to spoofing attacks or which can be subverted to carry out spoofing attacks are installed on a variety of servers. The Tsingua testbed consists of three separate Autonomous systems joined by MBGP speakers. to be added Figure 2: CERNET2 Overlay SAVA Test Environment to be added Figure 3: Tsinghua University Trustable Internet Test Network to be added Figure 4: Tsinghua University Network AS100 detail to be added Figure 5: Tsinghua University Test Network AS200 Detail to be added Figure 6: Tsinghua University Test Network AS300 Detail 3. SAVA Solutions Tested and Experiences 3.1. Inter-ISP Case (Neighbouring AS) Wu, et al. Expires August 29, 2007 [Page 5] Internet-Draft SAVA Testbed Feb 2007 --------- | AIMS | ------|- | -------------- -----------|----- | AS-4 |----- ------| AS-1 | |----- | |ASBR |----->|ASBR | ------|- |ASBR |---> Global IPv6 | |----- ------| | VRGE | |----- Network --------------- | -------- | ----- ----------------- |ASBR| |ASBR| ------ ------ / | / | / | / | ---------- ----- |ASBR, VE| |ASBR| --------------- ------------- | AS-2 | | AS-3 | | | | | | | | | | | | | --------------- ------------- Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule Generating Engine, VE == Validating Engine Figure 7: Inter-ISP (Neighboring AS) Setup In the solution implemented on the testbed, the solution for the validation of IPv6 prefixes is separated into three functional modules: The Validation Rule Generating Engine (VRGE), the Validation Engine (VE) and the the AS-IPv6 prefix Mapping Server. (AIMS). Validation rules (VR) that are generated by the VRGE are expressed as IPv6 address prefixes. The VRGE generates validation rules, and each AS has one. In the testbed, these are implemented on a LINUX server. The VE loads validation rules generated by VRGE to filter packets passed between ASs (In the case of Figure 7, from neighbouring ASs into AS-1. In the SAVA testbed, the VE is implemented as a simulated L2 device on a Linux-based machine inserted into the data path just outside each ASBR interface that faces a neigbouring AS, but in a real-world implementation it would probably be implemented as a packet filter set on the ASBR. The AS-IPv6 prefix mapping server is also implemented on a Linux machine and derives a mapping between IPv6 Wu, et al. Expires August 29, 2007 [Page 6] Internet-Draft SAVA Testbed Feb 2007 prefix and the AS of that prefix's "entry" into the region of validated IPv6 prefixed by processing AS-Path information. The rules are derived according to the table below, as described in [Gao]. --------------------------------------------------------------------------- | \Export| Own | Customer's| Sibling's | Providor's | Peer's | |To \ | Address | Address | Address | Address | Address | |-----\-------------------------------------------------------------------| | Providor | Y | Y | Y | | | |-------------------------------------------------------------------------| | Customer | Y | Y | Y | Y | Y | |-------------------------------------------------------------------------| | Peer | Y | Y | Y | | | |-------------------------------------------------------------------------| | Sibling | Y | Y | Y | Y | Y | --------------------------------------------------------------------------- Figure 8: AS-Relation Based Inter-AS Filtering Different ASes exchange and transmit VR information using the AS- relation-based export rules in the VR generation server. As per Figure 8, an AS exports the address prefixes of its own , its customers, its providers, it siblings and its peers to its customers and siblings as valid prefixes, while it only exports the address prefixes of its own, its customers and its siblings to its providers and peers as valid prefixes. With the support of AS Number to IPv6 Address Mapping service, only AS numbers of valid address prefixes are transferred between ASes and the AS number is mapped to address prefixes at the VRGE. Only changes of AS relation and changes of IP address prefixes belonging to an AS require the generation of VR updates. The procedure's principle steps are as folows (as seen by AS-1 in Figure 7): 1. When the VRG has initialised, it reads the AS neighbour table and establishes TCP connections to all the VEs in its own AS. 2. The VRGE initiates a VR renewal. According to its export table, it sends its own originated IPv6 prefixes to neighbouring ASs VRGEs. Rules are expressed as AS numbers. 3. When a VRGE receives the new rules from its neighbour, it then uses its own export table to decide whether it should accept the rules and, if it accepts a rule, whether or not it should re- export the rule to other neighbouring ASs. Wu, et al. Expires August 29, 2007 [Page 7] Internet-Draft SAVA Testbed Feb 2007 4. If the VRGE accepts a rule, it used the AIMS to transform AS- expressed rules into IPv6 refix-expressed rules. 5. The VRGE then pushes the thus-generated rules to all the VEs in its AS. The VEs then use these prefix-based rules to filter incoming packets. 3.2. Inter-ISP Case (Intervening AS) In the case where two ASs do not exchange packets directly, it s not possibe to deploy a solution like that in the previous section. However, it is highly desirable for non-neighbouring ISPs to be able to form a trust alliance such that packets leaving one AS will be recognised by the other and inherit the validation status they possessed on leaving the first AS. There is more than one way to do this. For the SAVA experiments to date, the signature method detailed in [I-D.wu-sava-solution-e2e-ipv6] has been used. This particular method uses a weak signature. +-----+ | REG | +-----+ ,-------------- ,-------------- ,' ` `. ,' ` `. / \ / \ / \ / \ ; +-----+ +----+ +----+ +-----+ ; | | ASC | |AER | |AER | | ASC | | : +-----+ +----+` +----+ +-----+ : \ / \ / \ / \ / `. ,' `. ,' '-------------' '-------------' AS-1 AS-2 KEY: REG == Registration Server, ASC == AS Control Server, AER == AS Edge Router. Figure 9: Validation Setup Between non-Neighbouring ASs There are three major components in the system: the Registration Server(REG), the AS Control Server(ASC), and the AS Edge Router(AER). The Registration Server is the "center" of the trust alliance (TA) . It maintains a member list for the TA. It performs two major functions: Wu, et al. Expires August 29, 2007 [Page 8] Internet-Draft SAVA Testbed Feb 2007 o Processes requests from the AS Control Server, to get the member list for the TA. o When the member list is changed, notifiy each AS Control Server. Each AS deploying the method should have an AS Control Server. The AS Control Server has three major functions: o Communicate with the Registration Server, to get the up-to-date member list of TA. o Communicate with the AS Control Server in other member AS in the TA, to exchange updates of prefix ownership information, and to exchange signatures. o Communicate with all edge routers of the local AS, to configure the processing component on the edge routers. The AS Edge Router does the work of adding signature to the packet at the sending AS, and the work of verifying and removing the signature at the destination AS. In the design of this system, in order to decrease the burden on the REG, most of the control traffic happens between ASCs. 3.3. Intra-ISP (Access Network) Case Assuming an ISP has implemented source address validation on its connection to peers and transit providers, the intra-ISP case reverts to access validation. There are many options for access validation, including BCP38 filtering, depending on the strength of validation required. The solution tested in the SAVA testbed takes the strongest requirement for validation in the access network. That is, any IPv6 address should have a unique association with an entity that is specifically authorised to use that IPv6 address. (BCP38 filtering, on the other hand typically only requires that the source address of a packet entering the provider network belong to a prefix that is allocated to or has transit through the attached access network.) An Extended Access Control Protocol is used in order to distribute authorised IPv6 addreses to end-users and to ensure a record of the authorised user and the corresponding IPv6 address and MAC address for each port of the access switch. As a result it is possible for the access switch to filter any packets sent by the user (or sokmeone pretending to be the user) that do not carry the authorised IPv6 source address and the corresponding MAC address. The SAVA extendes access control used for this proof of concept follows the following 4 Wu, et al. Expires August 29, 2007 [Page 9] Internet-Draft SAVA Testbed Feb 2007 steps: 1. End user sends an identity verification supplication, and the access switch sends a RADIUS request to the SAVA access validation server. 2. On successful establishment of identity, the SAVA access validation server issues an authorised IPv6 address for the user. 3. The access switch, on receiving the RADIUS authentication success message combines the embedded IPv6 address, the end-user identity, end-user MAC address and the switch port number into a binding relationship. In addition, it sends the issued address to the end-user host. 4. The access switch begins to filter packets sent from the end-user host. Packets which do not conform to an authorised (MAC SA, IPv6 SA, Switch Port) tuple are discarded. 4. Test Experience The solutions outlined above have been implemented on the testbed described above. Successful testing of all solutions has been carried out. A more detailed discussion will be forthcoming in the next version of this draft. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wu, et al. Expires August 29, 2007 [Page 10] Internet-Draft SAVA Testbed Feb 2007 8.2. Informative References [Gao] Gao, L., "On Inferring Autonomous System Relationships in the Internet", Infocom 2001, December 2001. [I-D.wu-sava-framework] Wu, J., "Source Address Validation Architecture (SAVA) Framework", draft-wu-sava-framework-00 (work in progress), February 2007. [I-D.wu-sava-problem-statement] Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I. Williams, "Source Address Validation Architecture (SAVA) Problem Statement", February 2007. [I-D.wu-sava-solution-e2e-ipv6] Wu, J., "An End-to-end Source Address Validation Solution for IPv6", draft-wu-sava-solution-e2e-ipv6-00 (work in progress), February 2007. Authors' Addresses Jianping Wu Tsinghua University Phone: Fax: Email: jianping@cernet.edu.cn URI: Jun Bi Tsinghua University Phone: Fax: Email: junbi@tsinghua.edu.cn URI: Wu, et al. Expires August 29, 2007 [Page 11] Internet-Draft SAVA Testbed Feb 2007 Mark Williams Juniper Networks Phone: Fax: Email: miw@juniper.net URI: Wu, et al. Expires August 29, 2007 [Page 12] Internet-Draft SAVA Testbed Feb 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). Wu, et al. Expires August 29, 2007 [Page 13]