idnits 2.17.1 draft-savola-bcp84-urpf-experiences-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 12, 2006) is 6526 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-reflectors-are-evil-00 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Opsec WG P. Savola 3 Internet-Draft CSC/FUNET 4 Intended status: Informational June 12, 2006 5 Expires: December 14, 2006 7 Experiences from Using Unicast RPF 8 draft-savola-bcp84-urpf-experiences-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 14, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 RFC 3704 (BCP 84) published in March 2004 provided an ingress 42 filtering technique update to RFC 2827 (BCP 38). This memo tries to 43 document operational experiences learned practising ingress filtering 44 techniques, in particular ingress filtering for multihomed networks. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Common uRPF Failures . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Unused Address Space Ping-Pong . . . . . . . . . . . . . . 4 51 2.2. Private Address Leak . . . . . . . . . . . . . . . . . . . 4 52 2.3. Wrong IP Address . . . . . . . . . . . . . . . . . . . . . 5 53 3. Multihoming uRPF Failures . . . . . . . . . . . . . . . . . . 5 54 3.1. Incorrect Source Address Selection . . . . . . . . . . . . 5 55 3.2. Point-to-Point Interface Routes . . . . . . . . . . . . . 6 56 3.3. Multiple Routers on a LAN use LAN for Transit . . . . . . 6 57 4. Special uRPF Failures Cases . . . . . . . . . . . . . . . . . 7 58 4.1. PMTUD and Private/Non-routed Addresses . . . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Introduction 70 RFC 3704 [RFC3704] (BCP 84) published in March 2004 provided an 71 ingress filtering technique update to RFC 2827 [RFC2827] (BCP 38). 72 This memo tries to document operational experiences learned 73 practising ingress filtering techniques, in particular ingress 74 filtering for multihomed networks. 76 Specifically, this version describes the lessons learned in author's 77 network where strict unicast RPF (uRPF) ingress filtering, using 78 "feasible paths" variant [RFC3704] has been used for all the customer 79 interfaces (whether single- or multihomed) for over two years. In 80 feasible paths strict uRPF, only an accepted equal length prefix 81 (even if not preferred) is considered feasible. While in some cases, 82 a more specific or even a less specific might be acceptable, such 83 condition would not necessarily be correct in general. 85 We use the typical "customer" and "ISP" terms to refer to the subject 86 of strict uRPF filtering and the party doing filtering. The same 87 considerations also apply for other business relationships (e.g., 88 "internal customers" inside an ISP). 90 According to a study, there is substantial ingress filtering 91 deployment, even 75% of addresses were not spoofable [SPOOFER]. 93 We note explicitly that Loose mode RPF is NOT a sufficient solution 94 in any way to ingress filtering as it creates a false sense of 95 protection. Even its use as a "contract validation" [RFC3704] is 96 tenuous at best. 98 NOTE IN DRAFT: comments should be directed to the author or the OPSEC 99 mailing list (opsec@ops.ietf.org). However, it is not clear what 100 should be the next steps wrt. these experiences. Update to the 101 ingress filtering RFCs? Publish separately? Keep as a standing 102 document for now? Integrate with OPSEC document work? In any case, 103 feedback on other experiences is encouraged. 105 In the second section, we'll first look at the most common types of 106 uRPF failures and their mitigation techniques. In the third section, 107 we'll look at a few special cases observed on multihoming or multi- 108 connecting scenarios. More special filtering failures are discussed 109 in the fourth section. 111 2. Common uRPF Failures 113 We'll describe the most common uRPF failures which apply to both 114 single- and multi-homed network, and respective fixes. 116 2.1. Unused Address Space Ping-Pong 118 By far, the most common cause for uRPF failures seems to be the case 119 where a prefix P is routed to the customer (e.g., using a static 120 route), but the customer doesn't use all of P, and an attacker A is 121 port-scanning the unused address space. 123 In that case, typically packets destined to the unused part of "P" 124 lack a more specific route, and are routed back to the ISP through a 125 default route. The ISP's router sees these as sourced from attacker 126 A (an IP address in the Internet), destined to the customer's prefix 127 P. This fails uRPF check and is dropped. 129 Note: if uRPF is not employed, the scan may may cause ping-pong 130 effect up to the remaining hop count/TTL of the packet, consuming 131 even 250 times the bandwidth and packet processing. This has been 132 briefly described in [I-D.ietf-ipngwg-p2p-pingpong]. 134 The ping-pong effect has also been used in Internet Exchanges to game 135 peer selection or traffic balance data. 137 Therefore, the customer should install static discard aggregate 138 routes (or equivalent) for all of its address space upon assignment, 139 so that if no better route exists, such probe packets are discarded. 140 An alternative is applying a similar filtering in egress interface 141 towards the ISP. There isn't much an ISP can do to prevent this 142 unless it wants to create customer-specific uRPF access-lists. 144 2.2. Private Address Leak 146 Very often, packes from all kinds of private addresses also leak to 147 the ISP, which are obviously dropped by uRPF. This is probably a 148 result of misconfigured NATs or inadequate firewall rules. Even 149 (constant) rates of hundreds of packets per second have been 150 observed, which makes one wonder which kinds of users' communications 151 must be failing or otherwise working in a non-optimal fashion due to 152 this kind of misconfiguration... 154 This is actually one of the most convincing reasons from the users' 155 perspective why (they or the ISP) using uRPF could give benefits: it 156 allows them to notice and fix network misconfiguration and 157 malfunction "at the source" and as a result, communication should 158 work more reliably and new issues would be easier to notice. 160 The obvious fix is to ensure that the customer is filtering out (and 161 logging) these packets, and based on that, figures out what is 162 causing such address leaks and fixes the misconfiguration or other 163 problem(s). 165 2.3. Wrong IP Address 167 It's also not atypical to see other kinds of wrong source addresses. 168 These can be classified in three main categories: a) nomadic laptops 169 trying their old IP from a previous network attachment point, b) 170 spoofed/misconfigured/typoed public, routable IP address, or c) an 171 unroutable ("bogon") IP address. (It should be noted that Loose uRPF 172 would only spot the last category.) 174 Many spoofed attacks are usually a result of a worm or a botnet (DoS) 175 attack. A recent case was using recursive DNS servers for reflection 176 [I-D.ietf-dnsop-reflectors-are-evil], but a lot of different usages 177 have been observed. 179 The same considerations as for leaking private addresses apply here, 180 except that these wouldn't typically get this far if the customer had 181 been using unicast RPF at its LAN interfaces (i.e., uRPF can and 182 should be applied recursively [RFC3704]). 184 3. Multihoming uRPF Failures 186 We'll describe a few uRPF failure modes which only occur in scenarios 187 with a multihomed/multi-connected network or host. 189 We note that a customer can multihome and even perform traffic 190 engineering with feasible paths uRPF provided that the consistency 191 requirement is fulfilled. In other words, AS-path prepending, 192 setting communities to lower local-preference, etc. are all valid 193 mechanisms to ensure the prefix is advertised to every provider, but 194 actually may not ever end up being used. 196 3.1. Incorrect Source Address Selection 198 Hosts attaching to multiple LANs with different IP address need to be 199 careful with their source address selection. The same applies to 200 networks with multiple prefixes as explored in 201 [I-D.huitema-shim6-ingress-filtering]. 203 For example, assume the host has a default route through interface 1 204 with address A1 from prefix P1, and only a more specific route 205 through interface 2 with address A2 from prefix P2. When a host in 206 P1 sends a packet to A2, the response may go out through interface 1; 207 similarly, when a host in P2 sends a packet to A1, the response may 208 go out through interface 2. 210 This problem can be fixed by the customers by setting up source-based 211 routing so packets go through the right route, or by making an 212 exclusion in the uRPF filter list to allow sourcing from the other 213 prefix. The latter is typically not a good solution, especially if 214 the ISP doesn't control both the prefixes, because an ISP originating 215 these excluded packets would be indistinguishable from IP address 216 spoofing. 218 3.2. Point-to-Point Interface Routes 220 Feasible path strict uRPF works well, but assumes that the routes in 221 all the directions are consistent (i.e., exist). This principle is 222 often violated with the interface routes between the ISP and the 223 customer (ie., point-to-point links). 225 In some cases, the point-to-point link may be unnumbered but this has 226 other issues (e.g., eBGP is more complicated). If the links have 227 addresses, the address blocks usually need to be separate. The 228 addresses might be more specifics of the customer's aggregate(s) or 229 from the ISP's address space. In either case, the similar source 230 address selection issue as described in the previous section applies 231 for communication (e.g., pinging the CPE's p2p address) to the 232 customer's point-to-point addresses. 234 The easiest fix is to add dummy static routes with a higher 235 preference/distance on all the border routers, so that every router 236 facing the customer knows all the point-to-point address blocks used 237 on other routers; using a higher preference implies that the route is 238 actually never used, but is still valid from uRPF perspective. 239 Another possibility, if the addresses come from the customer's 240 aggregate, is to not propagate the point-to-point addresses in iBGP 241 or IGP at all so that there are no more specifics to mess up the uRPF 242 feasible path consistency, but this may have manageability concerns 243 if the aggregate goes down (i.e., can't ping the point-to-point 244 address except on the router connecting the customer). As already 245 mentioned, using unnumbered interfaces is also possible in some cases 246 but may have manageability or configuration concerns. 248 3.3. Multiple Routers on a LAN use LAN for Transit 250 When multiple routers attach to the same network subnet (typically 251 when e.g., VRRP is used), packets destined to router 2 (R2)'s 252 interface addresses towards the LAN transiting router 1 use the LAN 253 interface to reach R2. (In most cases, the primary path between 254 routers should go via dedicated link(s), not via a LAN.) These 255 packets fail uRPF check at R2 (and vice versa at R1). 257 There are two obvious fixes: have R2 advertise such LAN addresses in 258 iBGP or IGP (or set up static routes), resulting a more specific so 259 the LAN interface is not used, or make an exception to uRPF 260 configuration to allow such "transit LAN" usage. However, the latter 261 allows an attacker in the LAN to spoof an address to the LAN router's 262 interface address(es) (for example, circumventing remote login access 263 lists), which usually makes it a suboptimal solution. 265 4. Special uRPF Failures Cases 267 4.1. PMTUD and Private/Non-routed Addresses 269 A disturbing issue is that some large operators seem to think it's 270 perfectly legitimate to send private-source addressed packets ICMP 271 messages (e.g., from PMTUD) across AS boundaries [PRIVIP]. While the 272 reasoning is different, the result is similar for non-routed, but 273 uniquely assigned address space. 275 Private IP addresses for infrastructure are a bad idea. But even 276 worse than that is deploying links in such infrastructure which have 277 lower MTU than the egress link, i.e., are guaranteed to send ICMP 278 fragmentation needed messages under certain circumstances. Deploying 279 such networks that require PMTUD to work while happily originating 280 RFC1918 traffic (and translating it at the edge) seems like very bad 281 design from network hygiene perspective. 283 5. IANA Considerations 285 This memo makes no request to IANA. 287 6. Acknowledgements 289 Danny McPherson and Matsuzaki Yoshinobu provided comments on the 290 first revision of this document. 292 7. Security Considerations 294 This document describes uRPF experiences. The most important 295 security impact comes from applying particular fixes to uRPF issues 296 noted, i.e., what kind of spoofing window or other unintended usage 297 that would allow. 299 As already stated, in invalid source address selection scenario, 300 making an exception to allow prefixes which you don't control is 301 typically a big mistake, as then you become indistinguishable from 302 someone spoofing that address. Also as already stated, in the case 303 of transit LAN, making an exception might allow one to spoof an 304 address destined to the LAN router's interface address(es) which 305 usually has a security impact. 307 8. References 309 8.1. Normative References 311 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 312 Defeating Denial of Service Attacks which employ IP Source 313 Address Spoofing", BCP 38, RFC 2827, May 2000. 315 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 316 Networks", BCP 84, RFC 3704, March 2004. 318 8.2. Informative References 320 [I-D.huitema-shim6-ingress-filtering] 321 Huitema, C., "Ingress filtering compatibility for IPv6 322 multihomed sites", 323 draft-huitema-shim6-ingress-filtering-00 (work in 324 progress), September 2005. 326 [I-D.ietf-dnsop-reflectors-are-evil] 327 Damas, J. and F. Neves, "Preventing Use of Nameservers in 328 Reflector Attacks", 329 draft-ietf-dnsop-reflectors-are-evil-00 (work in 330 progress), May 2006. 332 [I-D.ietf-ipngwg-p2p-pingpong] 333 Hagino, J., JINMEI, T., and B. Zill, "Avoiding ping-pong 334 packets on point-to-point links", 335 draft-ietf-ipngwg-p2p-pingpong-00 (work in progress), 336 July 2001. 338 [PRIVIP] NANOG mailing-list thread, "private IP addresses from 339 ISP", May 2006, 340 . 342 [SPOOFER] MIT ANA, "Spoofer Project", 343 . 345 Author's Address 347 Pekka Savola 348 CSC/FUNET 349 Espoo 350 Finland 352 Email: psavola@funet.fi 354 Full Copyright Statement 356 Copyright (C) The Internet Society (2006). 358 This document is subject to the rights, licenses and restrictions 359 contained in BCP 78, and except as set forth therein, the authors 360 retain all their rights. 362 This document and the information contained herein are provided on an 363 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 364 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 365 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 366 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 367 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 368 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 370 Intellectual Property 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at 392 ietf-ipr@ietf.org. 394 Acknowledgment 396 Funding for the RFC Editor function is provided by the IETF 397 Administrative Support Activity (IASA).