idnits 2.17.1 draft-dai-specific-route-urpf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 353. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 373), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2006) is 6434 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 49, but not defined == Unused Reference: 'RFC1208' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 316, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1208 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dai GuangMing 2 Internet Draft Z. Ye 3 Expires: March 2007 Huawei Technologies 4 September 13, 2006 6 Specific Route uRPF (SRU) 7 draft-dai-specific-route-urpf-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 13, 2007. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). All Rights Reserved. 37 Abstract 39 This document describes a mechanism to extend Unicast Reverse Path 40 Forwarding(uRPF). By associating an uRPF flag with a specific route, 41 uRPF can be controlled in a finer granularity than traditional one. 42 It may be used to reduce the cost to network devices caused by uRPF. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in [RFC-2119] 50 Table of Contents 52 1. Introduction................................................2 53 1.1. Current Implements......................................3 54 1.2. Some Problems..........................................3 55 2. Specific route uRPF (SRU)....................................3 56 2.1. Mechanism..............................................4 57 2.2. Process................................................4 58 2.3. Deployment.............................................4 59 2.3.1. Deployment model 1.................................4 60 2.3.2. Deployment model 2.................................5 61 2.4. Benefit................................................7 62 2.5. Design Consideration....................................7 63 3. Security Considerations......................................7 64 4. Acknowledgements............................................8 65 5. References..................................................8 66 5.1. Normative References....................................8 67 5.2. Informative References..................................8 68 Author's Addresses.............................................8 69 Intellectual Property Statement.................................9 70 Disclaimer of Validity.........................................9 71 Copyright Statement...........................................10 72 Acknowledgment................................................10 74 1. Introduction 76 As a countermeasure against forged source address attacks, uRPF has 77 been deployed widely in operator's network. uRPF performs additional 78 lookup operation on the routing table based on the source address of 79 a packet to determine whether the packet is allowed to be received 80 from an interface, i.e. whether the source address of the packet is a 81 spoofed one. 83 1.1. Current Implements 85 [RFC3704] documents several types of PRF (Reverse Path Forwarding) 86 implements: loose RPF, strict RPF and feasible RPF. The loose RPF 87 only checks for the existence of a route; the strict RPF will further 88 compare the consistency of the incoming interface with the outgoing 89 interface of the route; the feasible RPF additionally takes all 90 available outgoing interfaces into account. 92 Some routers integrate uRPF with ACL (Access Control list). When uRPF 93 check for a packet fails, the ACLs configured in advance for the 94 route will be consulted to decide whether the packet should be 95 dropped. It is conceptually identical to uRPF check for a specific 96 packet stream defined by ACLs. 98 1.2. Some Problems 100 Although uRPF benefits network security, it may also have a negative 101 effect to performance of network devices. 103 For an uRPF-enabled interface, performance of a network device is 104 unavoidably affected because it must look up route table both for 105 source and destination address. A device requires additional resource 106 to perform the second lookup operation at the same time, or it would 107 not reach the capacity of line-speed forwarding. 109 To some routers, mentioned ACL-based uRPF may worsen the situation 110 because it need to consult additional configured data, such as an ACL 111 table and an action table which containing deny, allow and some other 112 possible actions. All of above operations increase the processing 113 expense for packet forwarding. 115 In addition, no matter which type of uRFP is selected, each packet 116 received from an uRPF-enabled interface must be checked. uRPF in a 117 finer granularity is not available to reduce the expense. 119 2. Specific route uRPF (SRU) 121 This draft documents a new type uPRF, specific route uRPF (SRU), 122 which can be performed to check uRPF in a finer granularity. In some 123 situations, ACL-based uRPF can achieve similar effect, but SRU is 124 more efficient and more scalable. 126 2.1. Mechanism 128 Forwarding Information Base (FIB, [RFC1812]) is a core component of 129 IP forwarding process. A FIB entry contains at least the output 130 interface and next hop for a specific prefix. In this proposal, an 131 additional uRPF flag is associated with each FIB entry. This flag 132 indicates whether a packet destining the prefix should be check 133 against uRPF. 135 2.2. Process 137 After applying this mechanism, the forwarding process will seem as 138 follows: 140 -Firstly, a router processor consults FIB using the destination 141 address of a received packet as usual. 143 -Then, if an entry is found, its uRPF flag will be checked. If the 144 flag is set, a subsequent uRPF check will be performed. Or else, 145 uRPF check will not happen to the packet. 147 -Finally, according to the result of the uRPF check, the route 148 processor decides whether to drop the packet or not. 150 2.3. Deployment 152 2.3.1. Deployment model 1 154 uRPF-Enabled Interface+------+ BGP UPDATE +------+ 156 -------->| AS1 |<------------| AS2 | 158 +------+ +------+ 160 ^ 162 |BGP UPDATE 164 | 166 +------+ 167 | AS3 | 169 +------+ 171 Figure 1: A deployment scenario 173 Figure 1 illustrates a possible application scene. Suppose AS2 asks 174 AS1 to perform an uRPF check before forwarding packets to it. However, 175 AS3 has not such request. In order to meet the requirement, AS1 could 176 design a following routing policy. 178 -When receiving a BGP UPDATE, AS1 gets the former AS Number from 179 its AS_PATH attribute. 181 -If the former AS is AS2, before installing routes in the UPDATE 182 into RIB, AS1 associate an uRPF flag with them. 184 -Otherwise, the UPDATE will be treated as usual. 186 -When a route in RIB is selected as a best route and is installed 187 into FIB, its uRPF flag should be attached to corresponding FIB 188 entry. 190 -When a router processor selects a FIB entry, it will also check 191 its uRPF flag to decide whether to perform an uRPF check. 193 Through above measures, user requirement will be satisfied. It is 194 impossible or at least difficult for current uRPF technologies, such 195 as ACL-based uRPF, to meet the request. Moreover, only nodes in AS2 196 are requested to support SRU, no other network device and protocols 197 need to be modified. 199 2.3.2. Deployment model 2 201 Since a SRU check is a check against each individual route, the uRPF 202 operation may be treated as an extended attribute of a route. Thus, 203 besides being deployed by manual configurations, it also can be 204 propagated with routes by using dynamic routing protocols. 206 +-------+ 208 | ST | 210 +-------+ 212 | 214 | iBGP UPDATE with a special 216 V COMMUNITY attribute 218 ------------------------------ 220 | | 222 | | 224 V V 226 +-----------------+ +----------------+ 228 | RA (iBGP Router)| |RB (iBGP Router)| 230 +-----------------+ +----------------+ 232 Figure 2: Another deployment scenario 234 Figure 2 illustrates a possible deployment scenario within a BGP 235 Autonomous System(AS). ST is a station which maintains uRPF policies 236 and is responsible to distribute them within an AS. The following 237 steps could be taken to distribute policies. 239 o Configuring BGP routers of an AS in advance 241 For a BGP router which supports SRU, policies used to map route 242 attributes to uRPF operations are pre-configured. For example, a 243 special COMMUNITY attribute value may be selected to mean to enable 244 uRPF to a prefix and another value means to disable. 246 o Distribute uRPF policies 248 When a ST decides to enable the uRPF operation of a specific route, 249 it only needs to propagate a BGP UPDATE within the AS and attach the 250 pre-defined COMMUNITY attribute on it. After receiving the UPDATE, a 251 BGP router will apply the attached policies. Deployment and 252 revocation of policies can be performed in the same way. 254 The above deployment manner is similar to that of some black hole 255 filtering which counters DDOS attacks. Certainly, we could also 256 transmit uRPF policies in routing advertisements directly, such as 257 using a new route attribute. Thus the first step could be omitted. 259 2.4. Benefit 261 As a countermeasure towards DDOS, uRPF could only mitigate spoofed 262 address attacks. It does not make sense, when not any attack occurs. 263 Essentially, uRPF is similar to black hole filtering. The difference 264 between them is the latter lacks of measure to decide whether a 265 spoofed address attack has taken place. Thus, every received packet 266 has to be checked. If a dedicated device, such as an IDR system, is 267 available to detecting such attacks in time, SRU may be a better 268 choose. 270 Anyway, SRU provide a measure in a finer granularity and can be used 271 to perform uRPF on demand in the future and reduces its performance 272 impact on forwarding. 274 2.5. Design Consideration 276 FIB can be assumed as a 'forward policies database' for each received 277 packet, so an uRPF flag of a FIB entry will affect all the interfaces 278 in a device. In order to provide flexibility and apply different uRPF 279 policy to different interface, interface information should be 280 introduced in a fib entry. The information consists of interfaces 281 index in which received packets will be performed uRPF check. In this 282 way, although a single FIB is used, policies can be difference in 283 each individual interface. 285 An interface, which does not enable route-base uRPF, can simply 286 ignore the uRPF flag and interfaces information corresponding to the 287 found FIB entry. Thus, received packets from the interface can be 288 performed [RFC3704] uRPF check. In this way SRU may coexistence with 289 [RFC3704] uRPF. 291 3. Security Considerations 293 To be added. 295 4. Acknowledgements 297 To be added. 299 5. References 301 5.1. Normative References 303 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 304 RFC 1208, March 1991. 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 equirement Levels", BCP 14, RFC 2119, March 1997. 309 [RFC1812] Baker, F, "Requirements for IP Version 4 Routers", RFC 310 1812, June 1995. 312 [RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering: 313 Defeating Denial of Service Attacks which employ IP Source Address 314 Spoofing", BCP 38, RFC 2827, May 2000 316 [RFC4271] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4 317 (BGP-4)", RFC 4271, January 2006 319 5.2. Informative References 321 [RFC3704] F. Baker, P. Savola, "Ingress Filtering for Multihomed 322 Networks", BCP 84, RFC 3704, March 2004. 324 Author's Addresses 326 Dai Guangming 327 Huawei Technologies 328 No.3, Xinxi Road, Shangdi Information Industry Base 329 Haidian District, Beijing City 100085 330 Email: daigm@huawei.com 331 Zhao Ye 332 Huawei Technologies 333 No.3, Xinxi Road, Shangdi Information Industry Base 334 Haidian District, Beijing City 100085 335 Email: ye.zhao_ietf@hotmail.com 337 Intellectual Property Statement 339 The IETF takes no position regarding the validity or scope of any 340 Intellectual Property Rights or other rights that might be claimed to 341 pertain to the implementation or use of the technology described in 342 this document or the extent to which any license under such rights 343 might or might not be available; nor does it represent that it has 344 made any independent effort to identify any such rights. Information 345 on the procedures with respect to rights in RFC documents can be 346 found in BCP 78 and BCP 79. 348 Copies of IPR disclosures made to the IETF Secretariat and any 349 assurances of licenses to be made available, or the result of an 350 attempt made to obtain a general license or permission for the use of 351 such proprietary rights by implementers or users of this 352 specification can be obtained from the IETF on-line IPR repository at 353 http://www.ietf.org/ipr. 355 The IETF invites any interested party to bring to its attention any 356 copyrights, patents or patent applications, or other proprietary 357 rights that may cover technology that may be required to implement 358 this standard. Please address the information to the IETF at 359 ietf-ipr@ietf.org 361 Disclaimer of Validity 363 This document and the information contained herein are provided on an 364 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 365 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 366 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 367 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 368 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 369 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 371 Copyright Statement 373 Copyright (C) The Internet Society (2006). 375 This document is subject to the rights, licenses and restrictions 376 contained in BCP 78, and except as set forth therein, the authors 377 retain all their rights. 379 Acknowledgment 381 Funding for the RFC Editor function is currently provided by the 382 Internet Society.