Source Address Verification and Authentication (SAVA) Co-chairs TBD Internet Area Directors: Jari Arkko Mark Townsley Internet Area Advisor: TBD Routing Area Advisor: TBD Security Area Advisor: TBD Technical Advisors: TBD Mailing Lists: General Discussion: sava@nrc.tsinghua.edu.cn To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document Repository: http://narl.tsinghua.edu.cn/sava Description of Working Group/s: The proposed "Source Address Validation Architecture" Working Group is chartered to specify standardization of methods for building an IP (both IPv4 and IPv6) addressing architecture to ensure that every packet received and forwarded holds an authentic source address. "Valid source address" in this case has two meanings: i) First, the address must have been appropriately allocated 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.) ii) Second, the address except in cases where global uniqueness is specifically excluded, must be globally unique and traceable to its origin. That is, information about the address's location and ownership must be verifiable and correct. The current Internet addressing architecture does not verify the source address of the packets received and forwarded, although RFC 1812 has mentioned that a router SHOULD implement the ability to validate source IP addresses. In the current Internet addressing architecture using IPv4, it is difficult to ensure the authenticity of the source IP address of every packet forwarded in the network. This leads to many security, management, and accounting problems. There are many mechanisms related to the validation of source IP addresses, (see the appendix,) but few of them are widely deployed by the current Internet addressing architecture. Because the current Internet addressing architecture using IPv4, which does not verify the source address of the packets received and forwarded, has been in operation for many years, it is not feasible or cost-effective to change from the current Internet infrastructure. The main purpose of the SAVA WG is to propose a source address validation architecture. The first step will be a detailed categorization and description of the problem and sub-problems that ...(problem statement document) The framework for design and possibilities for the implementation of the architecture will be discussed and outlined in a separate framework document. Existing protocols and technologies may be extended, and new mechanisms and protocols to support the architecture may be created. The deployment policy and network transition mechanism also need to be taken into account. The WG should not limit itself to a single architectural design or a single solution for any given part of the architecture, although there should be an over-arching framework to which all designs, mechanisms, operational practices and other solutions must adhere. The thirds step is to..(solutions) Important characteristics of any solutions produced by the SAVA WG include: 1. Operators should receive a significant benefit from deploying the architectural mechanisms in their own network, even if many parts of the Internet have not deployed. This is required to give operators an incentive to adopt the architecture as early as possible. 2. The architecture should support incremental deployment, so that there is tangible benefit to be gained from partial deployment on the Internet. 3. The architecture must not have any significant negative impact on throughput or latency. 4. The relation between different components of the architecture should be loosely-coupled. That is, where there are multiple mechanisms to address a particular problem or function within the architecture, it should be possible for network operators to choose the mechanism they find most suitable. 5. The architecture should support multi-fence solutions to provide different granularities of authenticity. That is, there should be mechanisms to deal with address authenticity at the local network level, at the provider edge, at intra-provider router connections and at inter-provider boundaries. 6. The solutions should focus both on IPv4 and IPv6, but solutions suitable for IPv6 should not be excluded simply because they are not suitable for IPv4. Within this in mind, the goals of the WG are to complete the following work items . Document the problem statement for which the work of SAVA is a solution, and submit it to the IESG as an Informational Standard. . 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. . Develop [individual solutions for each component for the framework architecture] to support SAVA and submit them to the IESG for publication as Proposed Standards. The WG Will NOT: . 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. . Mechanisms to implement SAVA functionality where exact mechanisms are better left to individual vendors to implement. Goals and Milestones: Jun-07 Submit -01 versions of problem statement, framework document and test-bed experience. Jul 07 Hold BoF in Chicago, asking for this Charter to be approved Aug 07 Final version of Charter approved and WG created. Aug 07 Submit draft-00 of SAVA first-hop validation draft. Oct 07 Submit WG Draft-00 on Problem Statement for SAVA Oct 07 Submit WG Draft 00 on Architectural Framework for SAVA Feb 08 Submit WG draft 00 SAVA first-hop validation solution Feb-08 Collect non-WG drafts for intra- and inter- AS validation solutions. Mar 08 Final Drafts of problem statement and framework document for submission to IESG Jun-08 Submit WG draft 00 for intra and inter-AS validation solutions Aug 08 Submit final draft of SAVA first-hop validation draft to IESG for approval. Dec 08 Submit final drafts for intra- and inter- AS validation solutions to IESG