Network Working Group Dai GuangMing Internet Draft Z. Ye Expires: March 2007 Huawei Technologies September 13, 2006 Specific Route uRPF (SRU) draft-dai-specific-route-urpf-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 March 13, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describes a mechanism to extend Unicast Reverse Path Forwarding(uRPF). By associating an uRPF flag with a specific route, uRPF can be controlled in a finer granularity than traditional one. It may be used to reduce the cost to network devices caused by uRPF. Dai Expires March 13, 2007 [Page 1] Internet-Draft Control Plane Security Capabilities September 2006 Conventions used in this document 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] Table of Contents 1. Introduction................................................2 1.1. Current Implements......................................3 1.2. Some Problems..........................................3 2. Specific route uRPF (SRU)....................................3 2.1. Mechanism..............................................4 2.2. Process................................................4 2.3. Deployment.............................................4 2.3.1. Deployment model 1.................................4 2.3.2. Deployment model 2.................................5 2.4. Benefit................................................7 2.5. Design Consideration....................................7 3. Security Considerations......................................7 4. Acknowledgements............................................8 5. References..................................................8 5.1. Normative References....................................8 5.2. Informative References..................................8 Author's Addresses.............................................8 Intellectual Property Statement.................................9 Disclaimer of Validity.........................................9 Copyright Statement...........................................10 Acknowledgment................................................10 1. Introduction As a countermeasure against forged source address attacks, uRPF has been deployed widely in operator's network. uRPF performs additional lookup operation on the routing table based on the source address of a packet to determine whether the packet is allowed to be received from an interface, i.e. whether the source address of the packet is a spoofed one. Dai Expires March 13, 2007 [Page 2] Internet-Draft Control Plane Security Capabilities September 2006 1.1. Current Implements [RFC3704] documents several types of PRF (Reverse Path Forwarding) implements: loose RPF, strict RPF and feasible RPF. The loose RPF only checks for the existence of a route; the strict RPF will further compare the consistency of the incoming interface with the outgoing interface of the route; the feasible RPF additionally takes all available outgoing interfaces into account. Some routers integrate uRPF with ACL (Access Control list). When uRPF check for a packet fails, the ACLs configured in advance for the route will be consulted to decide whether the packet should be dropped. It is conceptually identical to uRPF check for a specific packet stream defined by ACLs. 1.2. Some Problems Although uRPF benefits network security, it may also have a negative effect to performance of network devices. For an uRPF-enabled interface, performance of a network device is unavoidably affected because it must look up route table both for source and destination address. A device requires additional resource to perform the second lookup operation at the same time, or it would not reach the capacity of line-speed forwarding. To some routers, mentioned ACL-based uRPF may worsen the situation because it need to consult additional configured data, such as an ACL table and an action table which containing deny, allow and some other possible actions. All of above operations increase the processing expense for packet forwarding. In addition, no matter which type of uRFP is selected, each packet received from an uRPF-enabled interface must be checked. uRPF in a finer granularity is not available to reduce the expense. 2. Specific route uRPF (SRU) This draft documents a new type uPRF, specific route uRPF (SRU), which can be performed to check uRPF in a finer granularity. In some situations, ACL-based uRPF can achieve similar effect, but SRU is more efficient and more scalable. Dai Expires March 13, 2007 [Page 3] Internet-Draft Control Plane Security Capabilities September 2006 2.1. Mechanism Forwarding Information Base (FIB, [RFC1812]) is a core component of IP forwarding process. A FIB entry contains at least the output interface and next hop for a specific prefix. In this proposal, an additional uRPF flag is associated with each FIB entry. This flag indicates whether a packet destining the prefix should be check against uRPF. 2.2. Process After applying this mechanism, the forwarding process will seem as follows: -Firstly, a router processor consults FIB using the destination address of a received packet as usual. -Then, if an entry is found, its uRPF flag will be checked. If the flag is set, a subsequent uRPF check will be performed. Or else, uRPF check will not happen to the packet. -Finally, according to the result of the uRPF check, the route processor decides whether to drop the packet or not. 2.3. Deployment 2.3.1. Deployment model 1 uRPF-Enabled Interface+------+ BGP UPDATE +------+ -------->| AS1 |<------------| AS2 | +------+ +------+ ^ |BGP UPDATE | +------+ Dai Expires March 13, 2007 [Page 4] Internet-Draft Control Plane Security Capabilities September 2006 | AS3 | +------+ Figure 1: A deployment scenario Figure 1 illustrates a possible application scene. Suppose AS2 asks AS1 to perform an uRPF check before forwarding packets to it. However, AS3 has not such request. In order to meet the requirement, AS1 could design a following routing policy. -When receiving a BGP UPDATE, AS1 gets the former AS Number from its AS_PATH attribute. -If the former AS is AS2, before installing routes in the UPDATE into RIB, AS1 associate an uRPF flag with them. -Otherwise, the UPDATE will be treated as usual. -When a route in RIB is selected as a best route and is installed into FIB, its uRPF flag should be attached to corresponding FIB entry. -When a router processor selects a FIB entry, it will also check its uRPF flag to decide whether to perform an uRPF check. Through above measures, user requirement will be satisfied. It is impossible or at least difficult for current uRPF technologies, such as ACL-based uRPF, to meet the request. Moreover, only nodes in AS2 are requested to support SRU, no other network device and protocols need to be modified. 2.3.2. Deployment model 2 Since a SRU check is a check against each individual route, the uRPF operation may be treated as an extended attribute of a route. Thus, besides being deployed by manual configurations, it also can be propagated with routes by using dynamic routing protocols. Dai Expires March 13, 2007 [Page 5] Internet-Draft Control Plane Security Capabilities September 2006 +-------+ | ST | +-------+ | | iBGP UPDATE with a special V COMMUNITY attribute ------------------------------ | | | | V V +-----------------+ +----------------+ | RA (iBGP Router)| |RB (iBGP Router)| +-----------------+ +----------------+ Figure 2: Another deployment scenario Figure 2 illustrates a possible deployment scenario within a BGP Autonomous System(AS). ST is a station which maintains uRPF policies and is responsible to distribute them within an AS. The following steps could be taken to distribute policies. o Configuring BGP routers of an AS in advance For a BGP router which supports SRU, policies used to map route attributes to uRPF operations are pre-configured. For example, a special COMMUNITY attribute value may be selected to mean to enable uRPF to a prefix and another value means to disable. o Distribute uRPF policies When a ST decides to enable the uRPF operation of a specific route, it only needs to propagate a BGP UPDATE within the AS and attach the pre-defined COMMUNITY attribute on it. After receiving the UPDATE, a BGP router will apply the attached policies. Deployment and revocation of policies can be performed in the same way. Dai Expires March 13, 2007 [Page 6] Internet-Draft Control Plane Security Capabilities September 2006 The above deployment manner is similar to that of some black hole filtering which counters DDOS attacks. Certainly, we could also transmit uRPF policies in routing advertisements directly, such as using a new route attribute. Thus the first step could be omitted. 2.4. Benefit As a countermeasure towards DDOS, uRPF could only mitigate spoofed address attacks. It does not make sense, when not any attack occurs. Essentially, uRPF is similar to black hole filtering. The difference between them is the latter lacks of measure to decide whether a spoofed address attack has taken place. Thus, every received packet has to be checked. If a dedicated device, such as an IDR system, is available to detecting such attacks in time, SRU may be a better choose. Anyway, SRU provide a measure in a finer granularity and can be used to perform uRPF on demand in the future and reduces its performance impact on forwarding. 2.5. Design Consideration FIB can be assumed as a 'forward policies database' for each received packet, so an uRPF flag of a FIB entry will affect all the interfaces in a device. In order to provide flexibility and apply different uRPF policy to different interface, interface information should be introduced in a fib entry. The information consists of interfaces index in which received packets will be performed uRPF check. In this way, although a single FIB is used, policies can be difference in each individual interface. An interface, which does not enable route-base uRPF, can simply ignore the uRPF flag and interfaces information corresponding to the found FIB entry. Thus, received packets from the interface can be performed [RFC3704] uRPF check. In this way SRU may coexistence with [RFC3704] uRPF. 3. Security Considerations To be added. Dai Expires March 13, 2007 [Page 7] Internet-Draft Control Plane Security Capabilities September 2006 4. Acknowledgements To be added. 5. References 5.1. Normative References [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", RFC 1208, March 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate equirement Levels", BCP 14, RFC 2119, March 1997. [RFC1812] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000 [RFC4271] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 5.2. Informative References [RFC3704] F. Baker, P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. Author's Addresses Dai Guangming Huawei Technologies No.3, Xinxi Road, Shangdi Information Industry Base Haidian District, Beijing City 100085 Email: daigm@huawei.com Dai Expires March 13, 2007 [Page 8] Internet-Draft Control Plane Security Capabilities September 2006 Zhao Ye Huawei Technologies No.3, Xinxi Road, Shangdi Information Industry Base Haidian District, Beijing City 100085 Email: ye.zhao_ietf@hotmail.com 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. Dai Expires March 13, 2007 [Page 9] Internet-Draft Control Plane Security Capabilities September 2006 Copyright Statement Copyright (C) The Internet Society (2006). 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. Dai Expires March 13, 2007 [Page 10]