idnits 2.17.1 draft-taylor-v6ops-fragdrop-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (June 05, 2013) is 3971 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-02 -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Jaeggli 3 Internet-Draft Zynga 4 Intended status: Informational L. Colitti 5 Expires: December 07, 2013 W. Kumari 6 Google 7 E. Vyncke 8 Cisco 9 M. Kaeo 10 Double Shot Security 11 T. Taylor, Ed. 12 Huawei Technologies 13 June 05, 2013 15 Why Operators Filter Fragments and What It Implies 16 draft-taylor-v6ops-fragdrop-01 18 Abstract 20 This memo was written to make application developers and network 21 operators aware of the significant possibility that IPv6 packets 22 containing fragmentation extension headers may fail to reach their 23 destination. Some protocol or application assumptions about the 24 ability to use messages larger than a single packet may accordingly 25 not be supportable in all networks or circumstances. 27 This memo provides observational evidence for the dropping of IPv6 28 fragments along a significant number of paths, explores the 29 operational impact of fragmentation and the reasons and scenarios 30 where drops occur, and considers the effect of fragment drops on 31 applications where fragmentation is known to occur, particularly 32 including DNS. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 07, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Observations and Rationale . . . . . . . . . . . . . . . . . 3 69 2.1. Possible Causes . . . . . . . . . . . . . . . . . . . . . 3 70 2.1.1. Stateful inspection . . . . . . . . . . . . . . . . . 4 71 2.1.2. Stateless ACLs . . . . . . . . . . . . . . . . . . . 4 72 2.1.3. Performance considerations . . . . . . . . . . . . . 4 73 2.1.4. Other considerations . . . . . . . . . . . . . . . . 4 74 2.1.5. Conclusions . . . . . . . . . . . . . . . . . . . . . 5 75 2.2. Impact on Applications . . . . . . . . . . . . . . . . . 5 76 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 6. Informative References . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Measurements of whether Internet Service Providers and edge networks 85 deliver IPv6 fragments to their destination reveal that for IPv6 in 86 particular, fragments are being dropped along a substantial number of 87 paths. The filtering of IPv6 datagrams with fragmentation headers is 88 presumed to be a non-issue in the core of the Internet, where 89 fragments are routed just like any other IPv6 datagram. However, 90 fragmentation can creates operational issues at the edges of the 91 Internet that may lead to administratively imposed filtering or 92 inadvertent failure to deliver the fragment to the end-system or 93 application. 95 Section 2 begins with some observations on how often IPv6 fragment 96 loss occurs in practice. We go on to look at the operational reasons 97 for filtering fragments, a key aspect of which is the limitations 98 they expose in the application of security policy, at resource 99 bottlenecks and in forwarding decisions. Section 2.2 then looks at 100 the impact on key applications, particularly DNS. 102 In the longer run, as network operators gain a better understanding 103 of the risks and non-risks of fragmentation and as middlebox, 104 customer premise equipment (CPE), and host implementations improve, 105 we believe that some incidence of fragment dropping currently 106 required will diminish. Some of the justifications for filtering 107 will persist in the long-term, and application developers and network 108 operators must remain aware of the implications. 110 This document deliberately refrains from discussing possible 111 responses to the problem posed by the dropping of IPv6 fragments. 112 Such a discussion will quickly turn up a number of possibilities, 113 application-specific or more general; but the amount of time needed 114 to specify and deploy a given resolution will be a major constraint 115 in choosing amongst them. In any event, that discussion is likely to 116 proceed in multiple directions, occur in different areas and is 117 therefore considered beyond the scope of this memo. 119 2. Observations and Rationale 121 [Blackhole] is a good public reference for some empirical data on 122 IPv6 fragment filtering. It describes experiments run to determine 123 the incidence and location of ICMP Packet Too Big and fragment 124 filtering. The authors used fragmented DNS packets to determine the 125 latter, setting the servers to an IPv6 minimum of 1280 bytes to avoid 126 any PMTU issues. The tests found for IPv6 that filtering appeared to 127 be occurring on some 10% of the tested paths. The filtering appeared 128 to be located at the edge (enterprise and customer networks) rather 129 than in the core. 131 2.1. Possible Causes 133 Why does such filtering happen? One cause is non-conforming 134 implementations in CPE and low-end routers. Some network managers 135 filter fragments on principle, thinking this is an easier way to 136 deter realizable attacks utilizing IPv6 fragments without thinking of 137 other network impacts, similar to the practice of filtering ICMP 138 Packet Too Big. Both implementations and management should improve 139 over time, reducing the problem somewhat. 141 Some filtering and dropping of fragments is known to be done for 142 hardware, performance, or topological considerations. 144 2.1.1. Stateful inspection 146 Stateful inspection devices or destination hosts can readily 147 experience resource exhaustion if they are flooded with fragments 148 that are not followed in a timely manner by the remaining fragments 149 of the original datagram. Holding fragments for reassembly even on 150 end-system firewalls can readily result in an effective denial of 151 service by memory and CPU exhaustion even if techniques, such as 152 virtual re-assambly exist. 154 2.1.2. Stateless ACLs 156 Stateless ACLs at layer 4 and up may be difficult to apply to 157 fragments other than the first one in which enough of the upper layer 158 header is present. As [Attacks] demonstrates, inconsistencies in 159 reassembly logic between middleboxes or CPEs and hosts can cause 160 fragments to be wrongfully discarded, or can allow exploits to pass 161 undetected through middleboxes. Stateless load balancing schemes may 162 hash fragmented datagrams from the same flow to different paths 163 because the 5-tuple may be available on only the initial fragment. 164 While rehashing has the possibility of reordering packets in ISP 165 cores it is not disastrous. However, in front of a stateful 166 inspection device, load balancer tier, or anycast service instance, 167 where headers other than the L3 header -- for example, the L4 header, 168 interface index (for traffic already rehashed onto different paths), 169 DS fields -- are considered as part of the hash, rehashing may result 170 in the fragments being delivered to different end-systems 172 2.1.3. Performance considerations 174 Leaving aside these incentives towards fragment dropping, other 175 considerations may weigh on the operator's mind. One example cited 176 on the NANOG list was that of a router where fragment processing was 177 done by the control plane processor rather than in the forwarding 178 plane hardware, with a consequent hit on performance. 180 2.1.4. Other considerations 182 Another incentive toward dropping of fragments is the 183 disproportionate number of software errors still being encountered in 184 fragment processing. Since this code is exercised less frequently 185 than the rest of the stack, bugs remain longer in the code before 186 they are detected. Some of these software errors can introduce 187 vulnerabilities subject to exploitation. It is common practice 188 [RFC6192] to recommend that control-plane ACLs protecting routers and 189 network devices be configured to drop all fragments. 191 2.1.5. Conclusions 193 Operators weigh the risks associated with each of the considerations 194 just enumerated, and come up with the most suitable policy for their 195 circumstances. It is likely that at least some operators will find 196 it desirable to drop fragments in at least some cases. 198 The IETF and operators can help this effort by identifying specific 199 classes of fragments that do not represent legitimate use cases and 200 hence should always be dropped. Examples of this work are given by 201 [RFC6946] and [I-D.ietf-6man-oversized-header-chain]. The problem of 202 inconsistent implementations may also be mitigated by providing 203 further advice on the more difficult points. However, some cases 204 will remain where legitimate fragments are discarded for legitimate 205 reasons. The potential problems these cases pose for applications is 206 our next topic. 208 2.2. Impact on Applications 210 Some applications can live without fragmentation, some cannot. UDP 211 DNS is one application that has the potential to be impacted when 212 fragment dropping occurs. EDNS0 extensions [RFC2671] allow for 213 responses in UDP PDUs that are greater than 512 bytes. Particularly 214 with DNSSEC [RFC4033], responses may be larger than the link MTU and 215 fragmentation would therefore occur at the sending host in order to 216 respond using UDP. The current choices open to the operators of DNS 217 servers in this situation are to defer deployment of DNSSEC, fragment 218 responses, or use TCP if there are cases where the rrset would be 219 expected to exceed the MTU. The use of fallback to TCP will impose a 220 major resource and performance hit and increases vulnerability to 221 denial of service attacks. 223 Other applications, such as the Network File System, NFS, are also 224 known to fragment large UDP packets for datagrams larger than the 225 MTU. NFS is most often restricted to the internal networks of 226 organizations. In general, managing NFS connectivity should not be 227 impacted by decisions mananging fragment drops at network borders or 228 end-systems. 230 3. Acknowledgements 232 The authors of this document would like to thank the RIPE Atlas 233 project and NLNetlabs whose conclusions ignited this document. 235 4. IANA Considerations 237 This memo includes no request to IANA. 239 5. Security Considerations 241 The potential for denial of service attacks, as well as limitations 242 inherent in upper-layer filtering when dealing with non-initial 243 fragments are significant issues under consideration by operators and 244 end-users filtering fragments. This document does not offer 245 alternative solutions to that problem, it does describe the impact of 246 those filtering practices. 248 6. Informative References 250 [Attacks] Atlasis, A., "Attacking IPv6 Implementation Using 251 Fragmentation", March 2012. 253 http://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12 254 -Atlasis-Attacking_IPv6-WP.pdf 256 [Blackhole] 257 de Boer, M. and J. Bosma, "Discovering Path MTU black 258 holes on the Internet using RIPE Atlas", July 2012. 260 http://www.nlnetlabs.nl/downloads/publications/pmtu-black- 261 holes-msc-thesis.pdf 263 [I-D.ietf-6man-oversized-header-chain] 264 Gont, F. and V. Manral, "Security and Interoperability 265 Implications of Oversized IPv6 Header Chains", draft-ietf- 266 6man-oversized-header-chain-02 (work in progress), 267 November 2012. 269 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 270 2671, August 1999. 272 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 273 Rose, "DNS Security Introduction and Requirements", RFC 274 4033, March 2005. 276 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 277 Router Control Plane", RFC 6192, March 2011. 279 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 280 6946, May 2013. 282 Authors' Addresses 284 Joel Jaeggli 285 Zynga 286 630 taylor ct #10 287 Mountain View, CA 94043 288 USA 290 Email: jjaeggli@zynga.com 292 Lorenzo Colitti 293 Google 295 Email: lorenzo@google.com 297 Warren Kumari 298 Google 299 1600 Amphitheatre Parkway 300 Mountain View, CA 94043 301 USA 303 Email: warren@kumari.net 305 Eric Vyncke 306 Cisco 307 De Kleetlaan 6A 308 Diegem 1831 309 Belgium 311 Email: evyncke@cisco.com 313 Merike Kaeo 314 Double Shot Security 316 Email: merike@doubleshotsecurity.com 318 Tom Taylor (editor) 319 Huawei Technologies 320 Ottawa, Ontario 321 Canada 323 Email: tom.taylor.stds@gmail.com