IETF BOF Proposal: Source Address Validation Architecture (SAVA) General Discussion: sava@nrc.tsinghua.edu.cn To Subscribe: http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava Mailing List Archive: http://www.nrc.tsinghua.edu.cn/pipermail/sava/ Document Repository: http://narl.tsinghua.edu.cn/sava Problem Description: Introduction In the MIT Spoofer Project, 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. Concerted attacks employing spoofing remain a serious concern. The current method of avoiding packets with spoofed source addresses entering and being propagated on the Internet relies on two methods: a) 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. b) 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. 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 for the routing infrastructure. a) 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. b) uRPF does not work well in places where asymmetric routing happens. This constitutes a large part of the Internet There are many proposed mechanisms related to the validation of source IP addresses, but few of them are widely deployed by the current Internet. While it is possibly too late to introduce adequate source address checking in the current IPv4-based Internet, the development of the next generation Internet using IPv6 gives us the opportunity to implement an architecture for effective source address checking. 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 other 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 either to 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). Proposed Charter The proposed ¡°Source Address Validation Architecture¡± Working Group is chartered to specify standardization of methods for building effective source-address validation to ensure that packets forwarded hold authentic source addresses. ¡°Authentic source address¡± in this case has two meanings: 1) First, the address must be authorized by Internet address authorization organization and not be forged. (i.e. the route to the address must have been injected into the routing tables by someone authorized to inject such a route, and the packet must have been injected into the network by an entity authorized to use that source address.) 2) Second, the address, except in cases where global uniqueness is specifically excluded, must be globally unique and traceable. That is, information about the address¡¯s location and ownership should be verifiable and correct. WG scope The SAVA WG scope includes: 1) Framework Architecture 2) Existing protocols and technologies may be extended, and 3) New mechanisms and protocols to support the architecture may be created. 4) The deployment policy and network transition mechanisms 5) Explicit trust models for the verification of source address authenticity. 6) Focus of the WG is the protection of infrastructure from unsecured and/or malicious endpoints. 7) The WG need not limit itself to a single architectural design or a single solution for any given part of the architecture, although where there are multiple proposed solutions for a given part of the architecture, they should address distinct use cases. (As per RFC1958, Section 3) With this in mind, the goals of the Proposed WG are to complete the following work items: 1) Document the problem statement for which the work of SAVA is a solution, and submit it to the IESG as an Informational Standard. 2) Design an architectural framework for SAVA and its component solutions, identifying the interactions between them, and submit it to the IESG for publication as a Proposed Standard. 3) Develop the protocol specifications to support SAVA and submit them to the IESG for publication as Proposed Standards. The WG Will NOT: 1) Work on end-end verification for applications and hosts, although hooks may be provided to allow applications to discover if the source address of a packet comes from a ¡°SAVA Compliant¡± Network. 2) Work on mechanisms to solve the problem in IPv4 networks, although it is recognized that some mechanisms and protocols may have application in IPv4 networks. Goals and Milestones: Nov 06 Hold BoF in San Diego, asking for this Charter to be approved Mar 07 Final version of Charter approved and WG created. July 07 Submit WG Draft-00 on Problem Statement for SAVA July 07 Submit WG Draft 00 on Architectural Framework for SAVA Nov 07 Submit WG Draft 00 for SAVA components (may happen in other WGs) 2008 and beyond: Submit Drafts to IESG as informational RFCs and Proposed Standards.