Network Working Group Tsinghua University Internet-Draft July 2005 Expires: January 2, 2006 Source Address Verification Architecture Framework draft-sava-framework-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 January 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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]. Tsinghua University Expires January 2, 2006 [Page 1] Internet-Draft SAVA Framework July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Forwarding Component . . . . . . . . . . . . . . . . . . . . . 3 3.1. uRPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 3 4. Control Component . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Generation and Distribution of Validation Rules . . . . . 3 4.2. Generation and Distribution of Authentication Information . . . . . . . . . . . . . . . . . . . . . . . 3 5. Framework Granularity . . . . . . . . . . . . . . . . . . . . 3 5.1. Provider-Provider . . . . . . . . . . . . . . . . . . . . 3 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 3 5.1.2. Presentation of Prefix Ownership . . . . . . . . . . . 4 5.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Sub-Provider-Sub-Provider . . . . . . . . . . . . . . . . 5 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 5 5.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Inside Access Network . . . . . . . . . . . . . . . . . . 8 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9 5.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Access Network - Provider . . . . . . . . . . . . . . . . 11 5.5. End-End . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Solution Focussed on IPv6 . . . . . . . . . . . . . . . . 11 6.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. Multi-fence, Multi-granularity solution . . . . . . . . . 11 6.5. Incrementally Deployable . . . . . . . . . . . . . . . . . 11 6.6. Incomplete Deployment Still Beneficial . . . . . . . . . . 11 6.7. Loose Component Coupling . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Tsinghua University Expires January 2, 2006 [Page 2] Internet-Draft SAVA Framework July 2005 1. Introduction 2. Overview 3. Forwarding Component 3.1. uRPF 3.2. Signature 3.3. Verification 4. Control Component 4.1. Generation and Distribution of Validation Rules 4.2. Generation and Distribution of Authentication Information 5. 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: 5.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. 5.1.1. Description The Internet is a conglomeration of autonomous systems (AS) that define the administrative authority and the routing policies of Tsinghua University Expires January 2, 2006 [Page 3] Internet-Draft SAVA Framework July 2005 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: 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. 5.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: Tsinghua University Expires January 2, 2006 [Page 4] Internet-Draft SAVA Framework July 2005 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. 5.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 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. 5.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. 5.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 Tsinghua University Expires January 2, 2006 [Page 5] Internet-Draft SAVA Framework July 2005 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. 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. Tsinghua University Expires January 2, 2006 [Page 6] Internet-Draft SAVA Framework July 2005 5.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 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. Tsinghua University Expires January 2, 2006 [Page 7] Internet-Draft SAVA Framework July 2005 (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. (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) 5.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 Tsinghua University Expires January 2, 2006 [Page 8] Internet-Draft SAVA Framework July 2005 and source IP address. 5.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. (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. Tsinghua University Expires January 2, 2006 [Page 9] Internet-Draft SAVA Framework July 2005 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. 5.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 Tsinghua University Expires January 2, 2006 [Page 10] Internet-Draft SAVA Framework July 2005 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. 5.4. Access Network - Provider 5.5. End-End 5.6. Summary (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) 6. Design Goals 6.1. Solution Focussed on IPv6 6.2. Performance 6.3. Scaling 6.4. Multi-fence, Multi-granularity solution 6.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. 6.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. Tsinghua University Expires January 2, 2006 [Page 11] Internet-Draft SAVA Framework July 2005 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. 6.7. Loose Component Coupling 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 9. Acknowledgements 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Tsinghua University Expires January 2, 2006 [Page 12] Internet-Draft SAVA Framework July 2005 Author's Address Tsinghua University Tsinghua University Expires January 2, 2006 [Page 13] Internet-Draft SAVA Framework July 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Tsinghua University Expires January 2, 2006 [Page 14]