Network Working Group J. Wu Internet-Draft J. Bi Intended status: Informational G. Ren Expires: August 11, 2007 X. Li CERNET R. Bonica M. Williams Juniper Networks February 7, 2007 Source Address Validation Architecture (SAVA) Framework draft-wu-sava-framework-00.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 August 11, 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 August 11, 2007 [Page 1] Internet-Draft SAVA Framework February 2007 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Forwarding Component . . . . . . . . . . . . . . . . . . . . . 3 4.1. uRPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 3 4.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 3 5. Control Component . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Generation and Distribution of Validation Rules . . . . . 3 5.2. Generation and Distribution of Authentication Information . . . . . . . . . . . . . . . . . . . . . . . 4 6. Framework Granularity . . . . . . . . . . . . . . . . . . . . 4 6.1. Provider-Provider . . . . . . . . . . . . . . . . . . . . 4 6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 4 6.1.2. Presentation of Prefix Ownership . . . . . . . . . . . 5 6.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 5 6.2. Sub-Provider-Sub-Provider . . . . . . . . . . . . . . . . 6 6.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6 6.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Inside Access Network . . . . . . . . . . . . . . . . . . 9 6.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9 6.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 11 6.4. Access Network - Provider . . . . . . . . . . . . . . . . 11 6.5. End-End . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Solution Focussed on IPv6 . . . . . . . . . . . . . . . . 12 7.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Multi-granularity ("Multi-Fence") solution . . . . . . . . 12 7.5. Incrementally Deployable . . . . . . . . . . . . . . . . . 13 7.6. Incomplete Deployment Still Beneficial . . . . . . . . . . 13 7.7. Loose Component Coupling . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Wu, et al. Expires August 11, 2007 [Page 2] Internet-Draft SAVA Framework February 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 the Internet easy for the attackers to spoof the source address [I-D.sava-problem-statement]. The proposed "Source Address Validation Architecture" is chartered to specify standardization of methods for building effective source-address validation to ensure that packets forwarded hold authentic source addresses. 3. Overview The SAVA framework consists of forwording components and control components. 4. Forwarding Component 4.1. uRPF A reverse path forwarding check component. 4.2. Signature A component inserts signature into the departing packet. 4.3. Verification A component checks the signature in the received packet 5. Control Component 5.1. Generation and Distribution of Validation Rules A component generates validation rules and distributes the rules to other control components. Wu, et al. Expires August 11, 2007 [Page 3] Internet-Draft SAVA Framework February 2007 5.2. Generation and Distribution of Authentication Information A component generates authentication information and distributes the information to other control components. 6. Framework Granularity We can't expect that single mechanism can solve the source address spoofing problem in the Internet. Multiple mechanisms should coexist and cooperate. Since the Internet is organized as a hierarchical architecture, it is natural to consider organizing the SAVA mechanisms in a hierarchical way, too. We suggest to organize the SAVA mechanisms in the following three levels: 6.1. Provider-Provider The goal of this level is to achieve that the packet transmitted in the Internet originates from the right AS that owns the source address of the packet. The granularity to check at this level is address prefix. SPM is designed to work at this level. SAVE can also be modified to work at this level. The inter-AS level is the most important for the SAVA architecture. The inter-AS source address spoofing is the most difficult to handle. 6.1.1. Description The Internet is a conglomeration of autonomous systems (AS) that define the administrative authority and the routing policies of different organizations[11]. From this viewpoint, Internet is a hierarchical architecture with two levels: the first level is the relationship between AS; the second level is the relationship inside one AS. For a given address prefix assigned already, there should be an AS that owns this prefix and be responsible for this prefix. At the inter-AS level, only the packet transmitted between different AS is considered. The packet only transmitted inside one AS is not considered. Here we list the possible source address spoofing scenario at the inter-AS level: Wu, et al. Expires August 11, 2007 [Page 4] Internet-Draft SAVA Framework February 2007 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. The goal of the inter-AS SAVA mechanisms is to achieve: 1. The packet transmitted in the Internet should originate from the right AS that owns the source address of the packet. 2. A packet should not originates from an AS that does not own the source address of the packet. 3. For a packet transmitted in the Internet, it should be able to find which AS is responsible for the packet from the source address of the packet. 6.1.2. Presentation of Prefix Ownership Here we discuss how to present the ownership of prefix for an AS. Since Longest Prefix Match is applied in the current forwarding lookup method, in the presentation of the prefix ownership we should also notice this property. For An AS (e.g., AS-1) that owns a large address block (e.g., a.b.0.0/16), it may assign part of its address (e.g., a.b.c.0/24) to another AS (e.g., AS-2). Both AS-1 and AS-2 have global AS number. In this case, this small address block (i.e., a.b.c.0/24) is not owned by AS-1, but owned by AS-2. So for an AS to express its own prefix, it should present not only the prefix blocksthat owned by this AS, but also those small prefix blocks that are not owned by this AS. The prefix ownership of an AS can be expressed in a table. The entry in the table can be organized as: o Prefix: prefix address. o Prefix length: length of the prefix. o Flag: whether the prefix is owned by this AS. If the prefix is owned by the AS, the flag is YES; if the prefix is not owned by the AS, the flag is NO. 6.1.3. Discussion Several important points should be kept in mind in the design of inter-AS SAVA mechanisms: 1. Asymmetric routing. Asymmetric routing is not rare for the inter-AS routing. So some methods (e.g., uRPF) by simply Wu, et al. Expires August 11, 2007 [Page 5] Internet-Draft SAVA Framework February 2007 reversing the forwarding table are not suitable. 2. Support for site multihoming. Many AS are created to support site multihoming. The inter-AS SAVA mechanisms should not break the usage of site multihoming. 3. High bandwidth. Usually the inter-AS bandwidth is high. The inter-AS SAVA mechanisms should be high performance. 4. Incremental deployment. It's hard to ask all ASes in the Internet to deploy some mechanism over one night, the inter-AS SAVA mechanisms should be effective even with partial deployment. 5. Deployemnt incentive. Since organizations behind each AS have their own different interest, the inter-AS SAVA mechanisms should provide enough incentive for the deployment. 6. By-passing traffic. Inside a transit AS, there are by- passing traffic and its own originated traffic. These two types of traffic should be discriminated. 6.2. Sub-Provider-Sub-Provider The goal of this level is to achieve that the packet in its sending AS originates from the right sub-part of this AS which owns the source address of the packet. The granularity to check at this level is address prefix. Ingress filtering and uRPF can be applied at this level. 6.2.1. Description At the Intra-AS, we only consider how to support SAVA in the sending AS of the packet. The packet may be sent to a destination in the sending AS, or to a destination out of the sending AS. To better manage the network, it is possible to further divide one AS to some parts in a sub level. Each sub part owns part of the AS address prefix, and be responsible for its own prefix. The possilbe source address spoofing scenarios at intra-AS level are as follows: 1. A host sends packet with spoofed source address of other part of AS. This packet is sent to a destination not in the sending AS. 2. A host sends packet with spoofed source address of other part of AS. This packet is sent to a destination in the sending AS. Wu, et al. Expires August 11, 2007 [Page 6] Internet-Draft SAVA Framework February 2007 3. A host sends packet with spoofed source address of other AS. This packet is sent to a destination not in 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 other AS. This packet is sent to a destination in the sending AS. The goal of the intra-AS SAVA mechanisms is to achieve: 1. In the sending AS of a packet, the packet should not have the source address that does not belong to the sending AS. 2. In the sending AS of a packet, if the source address of the packet belongs to the sending AS, the packet should originate from the right sub-part of this AS which owns the source address of the packet. 3. In the sending AS of a packet, if the source address of the packet belongs to the sending AS, a packet should not originates from the sub-part that does not own the source address of the packet. 4. In the sending AS of a packet, if the source address of the packet belongs to the sending AS, it should be able to find which sub-part of the AS is responsible for the packet from the source address of the packet. The by-passing traffic in the transit AS is not considered in the design of intra-AS SAVA mechanism. 6.2.2. Discussion There are several good points for designing the intra-AS SAVA mechanisms: 1. The unified control. Usually an AS is controlld by one organization. It is easy to make a unified consideration for the deployment of the intra-AS SAVA mechanism. 2. In the intra-AS level, SAVA mechanisms only check the source address in the granularity of address prefix. Checking in smaller granularity is left to do in the access network level. 3. Usually the provider assigns an address block to the customer network and provides a link to it. In this case, it is a very Wu, et al. Expires August 11, 2007 [Page 7] Internet-Draft SAVA Framework February 2007 effective way for the provider to apply ingress filtering at the provider side interface. (preamble) ---------- | Provider | | AS | |a.b.0.0/16| ---------- / | \ / | \ / | \ / | \ / | \ ---------- / ---------- \ ---------- | Customer | / | Customer | \ | Customer | | Network |--/ | Network | \--| Network | |a.b.c.0/24| |a.b.d.0/24| |a.b.e.0/24| ---------- ---------- ---------- (postamble) In some cases, a customer network may have more than one link to the provider to support site multihoming. Since the address block used by the customer network is only owner by one provider, it is still feasible to use ingress filtering here. (preamble) ---------- | Provider | | AS | |a.b.0.0/16| ---------- | | | | | | | | | | ---------- | Customer | | Network | |a.b.c.0/24| ---------- (postamble)If the customer network has links to more than one providers to support site multihoming, the customer network should have a global AS number. In this case, it is no longer an intra-AS SAVA problem, but an inter-AS SAVA problem. Wu, et al. Expires August 11, 2007 [Page 8] Internet-Draft SAVA Framework February 2007 (preamble) ---------- ---------- |Provider-1| |Provider-2| | AS | | AS | |a.b.0.0/16| |a.d.0.0/16| ---------- ---------- \ / \ / \ / \ / \ / ---------- | Customer | | Network | |a.b.c.0/24| ---------- (postamble) 6.3. Inside Access Network The goal of this level is to achieve that the packet sent from the access network originates from the right host which owns the source address of the packet. The source address may be assigned to the host in a static way or a dynamic way, in a "legal" way. Some products have provides solutions at this level, based on binding between port and source IP address, or binding between MAC address and source IP address. 6.3.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 other 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. Wu, et al. Expires August 11, 2007 [Page 9] Internet-Draft SAVA Framework February 2007 (preamble) +----+ | GW | +----+ | | e.g., a.b.c.0/16 +---------+--------------+ | | | | | | +----+ +----+ +----+ |Host| |Host| ... |Host| +----+ +----+ +----+ (postamble)The possilbe source address spoofing scenarios at access network level are as follows: 1. A host sends packet with spoofed source address of other 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 owned by the access network. This packet is sent to a destination not in the same access network. Before the packet passes through the interface of layer-3 gateway, it is a access network level problem. 3. A host sends packet with spoofed source address of other host in the same access network. This packet is sent to a destination in the same access network. 4. A host sends packet with spoofed source address not owned by the access network. This packet is sent to a destination in the same access network. We classify the goal of SAVA mechanisms at access network level into types: Loose Check scenario, and Strict Check scenario. In the Loose Check scenario, the SAVA mechanism should support: o The packet originating from the access network that can pass through the layer-3 gateway should originate from the right host that owns the source address of the packet. In the Strict Check scenario, in additional to the requirement in the Loose Check scenario, the SAVA mechanism should also support: o The packet originating from the access network that can be receive by other hosts in the same access network should originate from the right host that owns the source address of the packet. Wu, et al. Expires August 11, 2007 [Page 10] Internet-Draft SAVA Framework February 2007 6.3.2. Discussion Currently, a common way to support access network level SAVA is to allocate each host with seperate port at a layer-2 or layer-3 switch. (preamble) +----+ | GW | +----+ | | e.g., a.b.c.0/16 +--------+ +-------| L2/L3 | ---------+ | | switch | | | +--------+ | | | | +----+ +----+ +----+ |Host| |Host| ... |Host| +----+ +----+ +----+ (postamble)With layer-3 switch, the assigned IP address is binded with some specific port of the switch. Only the packet with the assigned source address can be sent through the port. It can meet the requirement of Strict Check scenario. With layer-2 switch, the assigned IP address is binded with the MAC address of the host, and this binding is checked by the layer-3 gateway. The layer-2 switch should support the binding between MAC address and the port of the layer-2 switch. Thus, it is achieved the binding between the assigned IP address and the port of the layer-2 switch. But it can only meet the requirement of Loose Check scenario. 6.4. Access Network - Provider 6.5. End-End 6.6. Summary Wu, et al. Expires August 11, 2007 [Page 11] Internet-Draft SAVA Framework February 2007 (preamble) +-------------------------------------------------------------------+ | |Scope |Granule |Possible Mechanisms | +-------------------------------------------------------------------+ |inter-AS |between ASes |prefix |SPM, SAVE-like | +-------------------------------------------------------------------+ |intra-AS |inside AS |prefix |ingress filtering, uRPF | +-------------------------------------------------------------------+ |access network |access network |host addr |port/mac - addr binding | +-------------------------------------------------------------------+ (postamble) 7. Design Goals 7.1. Solution Focussed on IPv6 Much if not all of the problem statement applies equally to IPv4 as to IPv6. However, the decision has been taken in this effort to focus on IPv6 only. This is because there are many changes that can still be made to IPv6 that cannot be made to IPv4. If a solution designed under this framework is also applicable to IPv4, or can be modified to work with IPv4, then that is considered to be good, but it is not a design goal. 7.2. 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 available for current equipment. (See Section 6.7). 7.3. Scaling Solutions must be capable of scaling to the size of the global Internet. 7.4. Multi-granularity ("Multi-Fence") 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 Wu, et al. Expires August 11, 2007 [Page 12] Internet-Draft SAVA Framework February 2007 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 multi-granularity 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. 7.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. 7.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 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. 7.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. 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Wu, et al. Expires August 11, 2007 [Page 13] Internet-Draft SAVA Framework February 2007 9. Security Considerations 10. 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). 11. References [I-D.sava-problem-statement] Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I. Williams, "Source Address Validation Architecture (SAVA) Problem Statemene", February 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 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 August 11, 2007 [Page 14] Internet-Draft SAVA Framework February 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 Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA Email: rbonica@juniper.net 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 11, 2007 [Page 15] Internet-Draft SAVA Framework 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 11, 2007 [Page 16]