Network Working Group J. Wu Internet-Draft J. Bi Intended status: Informational G. Ren Expires: December 8, 2007 X. Li CERNET M. Williams R. Bonica Juniper Networks June 6, 2007 Source Address Validation Architecture (SAVA) Framework draft-wu-sava-framework-01.txt 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 December 8, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document presents the framework for SAVA (Source Address Validation Architecture). Wu, et al. Expires December 8, 2007 [Page 1] Internet-Draft SAVA Framework June 2007 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism Considerations and Definitions . . . . . . . . . . . 4 3.1. Forwarding vs. Control Plane Mechanism Components . . . . 4 3.2. Packet "SAVA Status" . . . . . . . . . . . . . . . . . . . 5 3.3. Implicit vs Explicit Communication . . . . . . . . . . . . 6 4. SAVA Framework Hierarchy . . . . . . . . . . . . . . . . . . . 6 4.1. First-Hop, Local Subnet Source Validation . . . . . . . . 7 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Discussion of Scenarios . . . . . . . . . . . . . . . 8 4.1.2.1. Enterprise Networks Connecting to Service Provider . . . . . . . . . . . . . . . . . . . . . 8 4.1.2.2. Multihomed Enterprise Network . . . . . . . . . . 8 4.1.2.3. Home Broadband Access . . . . . . . . . . . . . . 9 4.1.2.4. Access from a Wireless Mobile Device . . . . . . . 9 4.1.2.5. Other Mobility Scenarios . . . . . . . . . . . . . 9 4.2. Intra-AS Communication of SAVA Validation . . . . . . . . 9 4.2.1. Mechanism Requirements . . . . . . . . . . . . . . . . 9 4.3. Inter-AS Communication of SAVA Validation . . . . . . . . 11 4.3.1. Mechanism Requirements . . . . . . . . . . . . . . . . 11 4.3.1.1. Communication Between Adjacent SAVA-compliant Providers . . . . . . . . . . . . . . . . . . . . 12 4.3.1.2. Communication Between Non-Adjacent SAVA-Compliant Providers . . . . . . . . . . . . . 12 4.3.1.3. Communication between a SAVA-Compliant Provider and a SAVA-non-Compliant Provider . . . . 13 4.3.2. Design Considerations . . . . . . . . . . . . . . . . 13 4.4. End-End . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. SAVA Design Goals . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Economically Feasible . . . . . . . . . . . . . . . . . . 14 5.3. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Hierarchical Solution . . . . . . . . . . . . . . . . . . 14 5.5. Incrementally Deployable . . . . . . . . . . . . . . . . . 14 5.6. Incomplete Deployment Still Beneficial . . . . . . . . . . 14 5.7. Loose Component Coupling . . . . . . . . . . . . . . . . . 15 5.8. Solution for IPv6 and IPv4 . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Wu, et al. Expires December 8, 2007 [Page 2] Internet-Draft SAVA Framework June 2007 1. 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]. 2. Introduction The lack of source IP address checking makes it easier than it should be for the attackers to spoof source addresses in the Internet. [I-D.wu-sava-problem-statement]. A "Source Address Validation Architecture" is proposed as a framework within which to specify minimum required functionality and, where necessary, specify mechanisms and protocols to: o guarantee validity of source addresses in packets accepted for transmission; o communicate within and between administrative domains the degree of assurance that exists as to the validity of source addresses in each packet; and o communicate with authorized entities as to the validation status of packets emitted from administrative domains. For the purposes of SAVA, a packet is said to contain a valid source address if: o it has been injected into the network by an entity authorized to use that source address at that point of injection; o the source address has been appropriately allocated; o the route to that source address has been injected into the global routing tables by an entity authorized to do so; o except in cases where global uniqueness is specifically excluded, the source address is globally unique; and o the packet is traceable to its origin using the source address. (That is, information about the address's location and ownership is verifiable and correct.) This document deals with the requirements for establishing, enforcing and communicating the validity of IPv4 and IPv6 packets under the SAVA framework from an access connection, through an access network to a service provider, optionally across transit service providers Wu, et al. Expires December 8, 2007 [Page 3] Internet-Draft SAVA Framework June 2007 and ultimately across another access network to the packet's destination This doecument does not deal with specific mechanisms for the above but provides a framework within which mechanisms can be specified, developed and deployed. 3. Mechanism Considerations and Definitions This section, while it does not specify or mandate any mechanisms, defines some structures and defnitions for the classification and evaluation of mechanisms. 3.1. Forwarding vs. Control Plane Mechanism Components SAVA mechanism components can be categorised into forwarding-plane components and control-plane components. Mechanisms may contain one or both types of component. Forwarding components are those components which lie in the forwarding path and which are required to operate on every packet forwarded. Control components are this components that operate on data structures such as routing tables that are not in the forwarding path and are not related to packet-by- packet processing. Some examples of forwarding plane components: o uRPF - a reverse path forwarding check component. o Packet Filters o Signature Insertion - a network element inserts a signature into a departing packet o Signature Verification - another network element verifies a signature in an arriving packet. Some examples of comtrol plane components: o Generation and Distribution of Validation Rules - A component generates validation rules and distributes the rules to other control components. These rules might, for example, define valid incoming interfaces for packets with a given source prefix. o Generation and Distribution of Authentication Information - A component generates authentication information and distributes the information to other control components. Examples of authentication information could be signatures for insertion into Wu, et al. Expires December 8, 2007 [Page 4] Internet-Draft SAVA Framework June 2007 departing packets, credentials for control components to exchange in order to verify identity, etc. Control plane components in general have the advantage of being able to be implemented in software, either in the control planes of existing network forwarding elements or in servers external to existing network elements. As such, it is usually more feasible to implement control plane components in existing networks using multiple types of hardware. Forwarding plane components typically need to be implemented in hardware (or at least in microcode) on line cards. Unless they are very simple or only need to be deployed in a small number of places in the network, new forwarding plane components are likely only to be deployable in the long term. A number of potentially useful forwarding plane components already exist, however. 3.2. Packet "SAVA Status" At any given time, a packet will have one of four possible "SAVA statuses". It should be noted that the "SAVA status" of a packet may be explicit (e.g. through marking the packet in some way) or it may be implicit (e.g. through being able to infer the status of a packet from the fact that it is delivered or the manner of its delivery.) This framework document places no constraint on the mechanism of communication. o Strict-Validated: A packet is said to be SAVA "strict-validated" if it can be proven that the packet was sent with a valid source address and has not been altered in transit, and furthermore, the packet can be traced back to an individual host that is authorized to emit packets with that SA. A packet retains strict-validated status if it is forwarded from one network element to another and the upstream element explicitly or implicitly certifies that the packet is SAVA "strict-validated". o Loose-Validated: A packet is said to be SAVA "loose-validated" if it can be proven that the packet was sent with a valid source address and has not been altered in transit. In the "loose- validated" case, however, it can only be proven that the packet was emitted by a host under the control of an adminstrative authority authorized to emit packets with that source address. Whether or not the packet can be traced to an individual host is unknown. A packet retains loose-validated status if it is forwarded from one network element to another and the upstream element explicitly or implicitly certifies that the packet is SAVA "loose-validated". Wu, et al. Expires December 8, 2007 [Page 5] Internet-Draft SAVA Framework June 2007 o Unknown: A packet has "unknown" status if it is not explicitly or implicitly certified to be "SAVA validated" by the upstream network element, but the downstream element cannot or does not "prove" that the packet is spoofed. In the internet today, the vast majority of packets have "unknown" status. o Spoofed: A packet has "spoofed" status if a receiving network element can ascertain that it is impossible for a packet having the source address contained in the received packet to have been forwarded by the path it received the packet. SAVA-compliant nodes MUST discard packets with "spoofed" status. 3.3. Implicit vs Explicit Communication As will be seen from the following section, SAVA mechanisms will often be concerned with communicating the "SAVA Status" of a packet from one part of the network to another. Explicit communication will typically involve altering a packet in some way which will be recognised by downstream nodes. Setting the "evil bit" in packets with "unknown" SAVA status would be an example of explicit communication. Implicit communication will typically involve creating some boundary conditions such that a downstream node will be able to infer the SAVA status of a packet from the way in which a packet arrived. For example, if node A only passes "strict-validated" packets, and node B can establish that a particular packet pased through node A on its way to node B, then communication of "stict-validated" status has been achieved for that packet. In most cases, implicit communication, if feasible, is preferred. 4. SAVA Framework Hierarchy In the Internet at large, it is not to be expected that there will be a single mechanism applied at a single "level" (e.g. service provider access) that can solve the source address spoofing problem. Multiple mechanisms will need to coexist and interoperate. The problem is decomposed hierarchically into levels of granularity. At each level in the framework hierarchy, one or more mechanisms will be defined to address the problem of source address spoofing at that level. The following is the framework hierarchy chosen for SAVA. It is not asserted that this is the only hierarchy that could be chosen. This particular hierarchy is chosen as a balance between allowing as much Wu, et al. Expires December 8, 2007 [Page 6] Internet-Draft SAVA Framework June 2007 choice as possible for impementers and providers and keeping the framework as simple as possible. 4.1. First-Hop, Local Subnet Source Validation The goal of this level is to assure that a packet sent from the access network originates from a host which is authorized to emit packets containing the source address of the packet. The source address may be assigned to the host in a static way or a dynamic way. There are existing and proposed solutions at this level, based on creating a binding between a switch port and source IP address, or a binding between MAC address, source IP address and switch port. A Packet that passes First-Hop, Local Subnet Source Validation becomes "SAVA validated" and retains that status as long as it is passed along a wholly SAVA-compliant path. 4.1.1. Description A number of hosts may access the Internet via the same interface of a layer-3 gateway. The host acquires its IP address in a "legal" way, e.g., static assigned by the administrator, or dynamic assigned by a DHCP server. Suppose ingress filtering is deployed at this interface. If there is no special consideration, one host can still spoof source address by sending packet with the "legal" IP address of another host, or even with the IP address not owned by this access network. The goal of the access network SAVA mechanisms is to solve the source address spoofing problem in these two scenarios. "Access network" is a very widely used concept, and it has many different scenarios. We just use this phrase here to indicate the specific scenario we describe above. (preamble) +----+ | GW | +----+ | | e.g., a.b.c.0/16 +---------+--------------+ | | | | | | +----+ +----+ +----+ |Host| |Host| ... |Host| +----+ +----+ +----+ (postamble) The possilbe source address spoofing scenarios at access network Wu, et al. Expires December 8, 2007 [Page 7] Internet-Draft SAVA Framework June 2007 level are as follows: 1. A host sends packet with spoofed source address of another host in the same access network. This packet is sent to a destination not in the same access network. 2. A host sends packet with spoofed source address not valid for the access network. This packet is sent to a destination not in the same access network. 3. A host sends packet with spoofed source address of another host in the same access network. This packet is sent to a destination on the same access network. 4. A host sends packet with spoofed source address not valid for the access network. This packet is sent to a destination in the same access network. If the access network, including the gateway, can be shown to discard all packets of type 2, then all packets emitted from the subnet aresaid to have SAVA "loose-validated" status. If the access network, including the gateway, can be shown to discard all spoofed packets of type 1 and type 2, then all packets emitted from the subnet aresaid to have SAVA "strict-validated" status. SAVA is not concerned with spoofed packets of type 3 and type 4. 4.1.2. Discussion of Scenarios 4.1.2.1. Enterprise Networks Connecting to Service Provider An enterprise network for purposes of this discussion is a collection of access networks and interconnecting gateways under the control of a single management entity that has one or more gateways connected to one or more service providers. Within an enterprise network, packets may have "strict-validated" or "loose-validated" status. However, unless the service provider accepting traffic from the enterprise can be sure that packets emitted from the enterprise are in fact all "strict-validated", then packets can at best have "loose validated" status on entering the service provider's network. 4.1.2.2. Multihomed Enterprise Network Wu, et al. Expires December 8, 2007 [Page 8] Internet-Draft SAVA Framework June 2007 4.1.2.3. Home Broadband Access In home broadband access cases, an individual has a contract with a provider for Internet services. The IPv4 address or prefix or IPv6 prefix is allocated/delegated by the provider from its pool of addresses. In this case, even if the home broadband user is using a home gateway to share an IP address, the address or prefix can be said to be strictly delegated to that gateway, and all traffic is the responsibility of one individual. Assuming the provider applies measures to prevent spoofing, packets entering the provider network can be said to be "strict-validated". 4.1.2.4. Access from a Wireless Mobile Device 4.1.2.5. Other Mobility Scenarios 4.2. Intra-AS Communication of SAVA Validation Intra-AS communication of SAVA Validation establishes, enforces and maintains packets' validation status from entry into a service provider's network either from an access network (either a customer node or a customer network) or from another service provider (transit provider, transit customer or peer network) until it is either delivered to an access network or another provider. In other words, Intra-AS Communication of SAVA Status must: o Correctly establish and enforce SAVA status at the access links to the network from customer nodes or networks. o Propagate SAVA Validation status for each packet (strict- validated, loose-validated, unknown) from one network element to the next until the packet either arrives at an inter-AS boundary or is delivered to an access network o Detect and discard packets with "spoofed" status 4.2.1. Mechanism Requirements The possible source address spoofing scenarios at the intra-AS level are as follows: 1. A host sends packet with spoofed source address of another part of the same AS. This packet is sent to a destination not within the sending AS. 2. A host sends packet with spoofed source address of another part of AS. This packet is sent to a destination within the sending AS. Wu, et al. Expires December 8, 2007 [Page 9] Internet-Draft SAVA Framework June 2007 3. A host sends packet with spoofed source address from another AS. This packet is sent to a destination not within the sending AS. While this packet is transmitted inside the sending AS, it is an intra-AS problem; when the packet arrives at the border of the sending AS, or the packet is transmitted not in the sending AS, it is an inter-AS problem. 4. A host sends packet with spoofed source address of another AS. This packet is sent to a destination within the sending AS. In order for an AS to be "SAVA-compliant", an AS must achieve the following: 1. The AS must not accept for delivery packets sent from an access network that have Source Addresses not authorized to be used by that access network. 2. Where a packet is accepted from an access network, the AS may distinguish between "strict-validated" and "loose-validated" status for each packet and assign status accordingly. If no such distinction is made, then a packet accepted for delivery will have "loose-validated" status. 3. A packet accepted for delivery from an access network cannot have "unknown" status and packets with "spoofed" status must be discarded. 4. A packet that accepted for delivery from an access network must be delivered to a SAVA-compliant neighbor AS or to another access network with the same validation status as it received on entry to the network. 5. A packet received from a non-SAVA-compliant neighbour AS will usually be assigned either "unknown" or "spoofed" SAVA validation status. There may be specific cases where packets may be assigned "loose-validated" status. If status is "spoofed" then the packet must be discarded. This status is established by Inter-AS communication of SAVA validation. 6. A packet entering a SAVA-compliant AS with "unknown" validation status must exit the AS with "unknown" SAVA validation status. 7. A packet received from a SAVA-compliant neighbour AS will have "unknown", "loose-validated" or "strict validated" status. This status is received through Inter-AS Communication of SAVA Validation. Wu, et al. Expires December 8, 2007 [Page 10] Internet-Draft SAVA Framework June 2007 8. A packet must exit the AS to a neighbouring SAVA compliant AS with the same status with which it was received, except in the case where the AS does not support communication of "strict- validated" status, in which case both "strict-validated" and "loose-validated" packets must exit the AS with "loose-validated" status. 9. In the case where SAVA status is communicated explicitly (for example through packet marking) Intra-AS status communication marking may optionally be removed from the packet before it is either delivered to an access network or passed to a peer network. 4.3. Inter-AS Communication of SAVA Validation At this framework level, the goal is to provide assurance that a packet transmitted from one service provider to another was inserted into the network through a provider authorized to insert packets with that packet's SA prefix into the Internet. The transmitting service provider or AS indicates whether a packet is known to have a validated source address or not. The receiving provider/AS makes a policy decision as to the disposition of the packet. (e.g. forward, do not forward, forward at a lower/higher priority, etc.) If the packet transits the receiving provider/AS, and the packet arrives at the receiving provider not certified as having been validated, then the receiving provider/AS MUST NOT certify the packet as having been validated to its downstream provider. For the purposes of this architecture, a provider-provider or inter- provider relationship exists between two or more administrative domains comprising one or more autonomous systems (AS) and exchanging routing information via EBGP either directly or via intermediate EBGP speakers. There are some proposed methods for this level in the literature. SPM[SPM] is designed to work at this level. SAVE [SAVE]can also be modified to work at this level. 4.3.1. Mechanism Requirements Here we list the possible source address spoofing scenario at the inter-AS level: 1. The host in one AS sends packet with spoofed source address of another AS. This packet is sent to a destination not in the sending AS. Wu, et al. Expires December 8, 2007 [Page 11] Internet-Draft SAVA Framework June 2007 2. The provider-provider level of the SAVA architecture can, for solution purposes, be broken down into three sub-cases: 1. the case where the two SAVA-compliant providers exchanging traffic are directly connected; 2. the case where the two SAVA-compliant providers are separated by one or more intervening, SAVA-non-compliant providers; and 3. the case where a SAVA-compliant provider is exchanging traffic with a SAVA-non-compliant provider. 4.3.1.1. Communication Between Adjacent SAVA-compliant Providers In order for two or more SAVA-Compliant (from an intra-AS perspective) to achieve SAVA-Compliant inter-Domain Communication of SAVA Validation, the interconnection must have the following characteristics: 1. The two domains must establish a trust relationship such that information can be exchanged between the domains in a secure manner; that is, information should be able to be exchanged without insertion of spurious information, without information being lost, and such that credentials, keys, etc. are not revealed to third parties. Establishment of this trust reationship implies that both participants are "SAVA-Compliant" at the Intra-AS level. (This includes the enforcement of at least "loose-validated" status for all packets arriving via access links.) 2. Trust relationship is transitive. That is, if A trusts B and B trusts C, even if A and C do not have a direct trust relationship, A must be able to trust the SAVA validation status of packets arriving from C via B. 3. Only packets with "strict-validated", "loose-validated" or "unknown" may be transmitted between SAVA-compliant ASs. 4. SAVA validation status is preserved across the inter-provider boundary. 4.3.1.2. Communication Between Non-Adjacent SAVA-Compliant Providers The requirements for this case are the same as for the case were the SAVA-compliant domains are adjacent, with the added requirement that the receiving domain must be able to distinguish between packets that arrived via the SAVA-compliant domain and packets (perhaps with the same source addresses) that arrived by some other route. Wu, et al. Expires December 8, 2007 [Page 12] Internet-Draft SAVA Framework June 2007 4.3.1.3. Communication between a SAVA-Compliant Provider and a SAVA- non-Compliant Provider Since there is no explicit SAVA communication between the domains in this case, the assignment of SAVA status must take place solely using information available at the receiving boundary through non-SAVA mechanisms. (e.g. routing tables, BGP AS-PATH attributes, etc.) In general, packets arriving at a SAVA-compliant domain will be assigned at best "unknown" SAVA validation status at the boundary. In some cases it will be possible (e.g. using uRPF) to prove that the packet is spoofed, in which it must be assigned "spoofed" status and discarded. There may be other cases (e.g. where the SA matches a prefix which is wholly contained within the network of the adjacent sending domain) where the packet can be assigned "loose-validated" SAVA status. 4.3.2. Design Considerations Several important points should be kept in mind in the design of inter-AS SAVA mechanisms: 1. Asymmetric routing is not rare for the inter-AS routing, so SAVA methods should be robust in the face of assymetric routing. 2. Many ASs are created to support site multihoming. The inter-AS SAVA mechanisms must be robust in the presence of site multihoming. 4.4. End-End 4.5. Summary 5. SAVA Design Goals 5.1. Performance Any solutions designed under this framework should be no more taxing on routing and other infrastructure than the application of BCP038. That is, modern routing equipment should be able to maintain full line rate. It is permissable to propose solutions that are not fully achievable with current equipment "as-is" but would be implementable with current generation technology, as long as alternative solutions are Wu, et al. Expires December 8, 2007 [Page 13] Internet-Draft SAVA Framework June 2007 available for current equipment. 5.2. Economically Feasible The solution must provide benefit at least proportionate to its cost, both from the perspective of equipment capital cost and operational expense. A solution that doubles the cost of core routing elements, for example, is not acceptable. A solution that is operationally more expensive than ingress filtering must supply significantly more benefit than ingress filtering. The design goal is to create an overall solution that has an operational cost of similar magnitude to that of applying ingress filtering that does not increase the cost of routing elements, taking into account that technology will allow more to be achieved with the same or lower hardware cost in the future. 5.3. Scaling Solutions must be capable of scaling to the size of the global Internet. 5.4. Hierarchical Solution One of the reasons why BCP has not solved the problem is that it is a single granularity solution - it can only be applied in the access network, or at the boundary between a stub/access network and a transit network. A provider who applies BCP038 protects itself from its own clients, and the rest of the Internet from its clients but it does not protect itself from spoofed packets in the rest of the Internet in any way. A hierarchical solution will allow a network to assign levels of trust to the source addresses on packets sent from neighboring providers as well as from its own network and attached stub networks. 5.5. Incrementally Deployable The mechanism should show its benefit even if it is deployed only in part of the Internet. It is impossible to deploy some mechanism all over the Internet in one night. If there is no benefit for partial deployment, it is hard to start the deployment. 5.6. Incomplete Deployment Still Beneficial The mechanism should have direct benefit to the party who makes investment on the deployment of the mechanism. Otherwise there is not enough incentive for someone to spend money to deploy such Wu, et al. Expires December 8, 2007 [Page 14] Internet-Draft SAVA Framework June 2007 mechanism. This implies two things: first, there must be immediate benefit for incomplete deployment, and deploying the recommended solutions must provide some protection to the entity deploying the solutions. 5.7. Loose Component Coupling A solution that meets the above design goals will have components for each level of granularity. It is desired that a solution under this framework may have more than one solution at any given level of granularity. This allows for different providers to use different solutions, as well as allowing for evolution of new solutions as the capabilities of equipment improve or simply as new solutions are developed. This requires the coupling of components at different levels of granularity to be loose enough to allow component substitution. 5.8. Solution for IPv6 and IPv4 Mechanisms are to be developed for both IPv6 and IPv4. Where possible the same mechanisms should be used for both, but it is recognised that it will be possible to make more radical changes to IPv6 than it will be for IPv4. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations 8. Acknowledgements The authors would like to acknowledge the contributors who provided helpful inputs on earlier versions of this document. The authors would also like to acknowledge the participants in the SAVA meetings held in Sunnyvale, CA, USA (March 2006), Beijing, China (June 2006), Montreal, Canada (IETF67 July 2006), and San Diego, USA (Nov. 2006). 9. References Wu, et al. Expires December 8, 2007 [Page 15] Internet-Draft SAVA Framework June 2007 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [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. [SAVE] Jin, C. and H. Wang, ""Hop-count filtering: an effective defense against spoofed DDoS traffic", in Proc. the 10th ACM conference on Computer and Communication Security", 2002. [SPM] Bremler-Barr, A. and H. Levy, ""Spoofing Prevention Method", INFOCOMM 2005", 2005. Authors' Addresses Jianping Wu CERNET Network Center, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Jun Bi CERNET Network Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Wu, et al. Expires December 8, 2007 [Page 16] Internet-Draft SAVA Framework June 2007 Gang Ren CERNET Network Center, Tsinghua University Beijing 100084 China Email: rg03@mails.tsinghua.edu.cn Xing Li CERNET Network Center, Tsinghua University Beijing 100084 China Email: xing@cernet.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 Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA Email: rbonica@juniper.net Wu, et al. Expires December 8, 2007 [Page 17] Internet-Draft SAVA Framework June 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 December 8, 2007 [Page 18]