idnits 2.17.1 draft-taylor-v6ops-fragdrop-00.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 (October 16, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6man-ipv6-atomic-fragments' is defined on line 219, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-6man-ipv6-atomic-fragments-01 == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: April 19, 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 October 16, 2012 15 Why Operators Filter Fragments and What It Implies 16 draft-taylor-v6ops-fragdrop-00 18 Abstract 20 This memo is written to make application developers and network 21 operators aware of the significant probability that IPv6 packets 22 containing fragmentation extension headers will fail to reach their 23 destination. Some assumptions about the ability to use TCP or UDP 24 datagrams larger than a single packet may accordingly need 25 adjustment. This memo provides observational evidence for the 26 dropping of IPv6 fragments along a significant number of paths, 27 explores the operational impact of fragmentation and the reasons why 28 dropping occurs, and considers the effect of fragment dropping on 29 applications particularly including DNS. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 19, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Observations and Rationale . . . . . . . . . . . . . . . . . . 3 66 2.1. Possible Causes . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Impact on Applications . . . . . . . . . . . . . . . . . . 5 68 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 71 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 Measurements of whether internet service providers and edge networks 77 deliver IPv6 fragments to their destination reveal that for IPv6 in 78 particular, fragments are being dropped along a substantial number of 79 paths. IPv6 datagrams with fragmentation headers are a non-issue in 80 the core of the internet, where fragments are routed just like any 81 other IPv6 datagram. However, fragmentation creates operational 82 issues at the edge of the network that may lead to administratively 83 imposed filtering or inadvertent failure to deliver the fragment to 84 the application. 86 Section 2 begins with some observations on how often IPv6 fragment 87 loss occurs in practice. We go on to look at the operational reasons 88 for filtering fragments, a key aspect of which is the threats they 89 pose to security policy and appliances. Section 2.2 then looks at 90 the impact on key applications, particularly DNS. 92 In the longer run, as network operators gain a better understanding 93 of the risks and non-risks of fragmentation and as middlebox, 94 customer premise equipment (CPE), and host implementations improve, 95 we believe that some incidences of fragment dropping will diminish. 96 However, some of the justifications for filtering will persist in the 97 longer term, and application developers must remain aware of the 98 implications. 100 This document deliberately refrains from discussing possible 101 responses to the problem posed by the dropping of IPv6 fragments. 102 Such a discussion will quickly turn up a number of possibilities, 103 application-specific or more general; but the amount of time needed 104 to specify and deploy a given resolution will be a major constraint 105 in choosing amongst them. In any event, that discussion is likely to 106 proceed in multiple directions and is therefore considered beyond the 107 scope of this memo. 109 2. Observations and Rationale 111 [Blackhole] is a good public reference for the incidence of IPv6 112 fragment filtering. It describes experiments run to determine the 113 incidence and location of ICMP Packet Too Big and fragment filtering. 114 The authors used fragmented DNS packets to determine the latter and 115 found for IPv6 that filtering appeared to be occurring on some 10% of 116 the tested paths. The filtering appeared to be located at the edge 117 (enterprise and customer networks) rather than in the core. 119 [Co-authors, more to contribute?] 121 2.1. Possible Causes 123 Why does such filtering happen? One cause is non-conforming 124 implementations in CPE and low-end routers. Along with that, some 125 network managers filter fragments on principle, without taking 126 account of the specific risks involved, just as they may filter ICMP 127 Packet Too Big. Both implementations and management should improve 128 over time, reducing the problem somewhat. 130 Some filtering and dropping of fragments is done for hardware, 131 performance, or topological considerations. Stateful inspection 132 devices or destination hosts can experience resource exhaustion if 133 they are flooded with fragments not followed by the remaining 134 fragments of the unfragmented packet. Stateless ACLs may be 135 difficult to apply to fragments other than the one in which the upper 136 layer header is present. As [Attacks] demonstrates, inconsistencies 137 in reassembly logic between middleboxes or CPEs and hosts can cause 138 fragments to be wrongfully discarded, or can allow exploits to pass 139 undetected through middleboxes. Stateless Load balancing schemes may 140 hash fragmented datagrams from the same flow to different paths 141 because the 5-tuple may available on only the initial fragment. 143 Leaving aside these incentives towards fragment dropping, other 144 considerations may weigh on the operator's mind. One example cited 145 on the NANOG list was that of a router where fragment processing was 146 done by the control plane processor rather than in the forwarding 147 plane hardware, with a consequent hit on performance. Another 148 incentive toward dropping of fragments is the disproportionate number 149 of software errors still being encountered in fragment processing. 150 Since this code is exercised less frequently than the rest of the 151 stack, bugs remain longer in the code before they are detected. Some 152 of these software errors can introduce vulnerabilities subject to 153 exploitation. It is common practice [RFC6192] to recommend that 154 control-plane ACLs protecting routers and network devices be 155 configured to drop all fragments. 157 Operators weigh the risks associated with each of the considerations 158 just enumerated, and come up with the most suitable policy for their 159 circumstances. It is likely that at least some operators will find 160 it desirable to drop fragments in at least some cases. 162 The IETF can help this effort by identifying specific classes of 163 fragments that do not represent legitimate use cases and hence should 164 always be dropped. Examples of this work are given by 165 [draft-6man-atomic] and [I-D.ietf-6man-oversized-header-chain]. The 166 problem of inconsistent implementations may also be mitigated by 167 providing further advice on the more difficult points. However, some 168 cases will remain where legitimate fragments are discarded for 169 legitimate reasons. The potential problems these cases pose for 170 applications is our next topic. 172 2.2. Impact on Applications 174 Some applications can live without fragmentation, some cannot. DNS 175 is one application that may be vulnerable when fragment dropping 176 occurs. EDNS0 extensions [RFC2761] allow for responses in UDP PDU 177 greater than 512 bytes. Particularly with DNSSEC, responses may be 178 larger than the MTU and fragmentation at the sending host in order to 179 respond using UDP is desirable and legal. The current choices open 180 to the operators of DNS servers in this situation are to defer 181 deployment of DNSSEC, fragment responses, or use TCP if there are 182 cases where the rrset would be expected to exceed the MTU. The use 183 of fallback to TCP will impose a major resource and performance hit 184 and increases vulnerability to denial of service attacks. 186 Other applications, such as Network File System, NFS, are also known 187 to fragment their large UDP packets but this is most often kept 188 within a single organization network and should not be impacted by 189 fragment dropping at the Internet core or edges. 191 3. Acknowledgements 193 TBD. 195 4. IANA Considerations 197 This memo includes no request to IANA. 199 5. Security Considerations 201 [Obviously a few things to say here, or we can find a few good 202 references.] 204 6. Informative References 206 [Attacks] Atlasis, A., "Attacking IPv6 Implementation Using 207 Fragmentation", March 2012. 209 http://media.blackhat.com/bh-eu-12/Atlasis/ 210 bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf 212 [Blackhole] 213 de Boer, M. and J. Bosma, "Discovering Path MTU black 214 holes on the Internet using RIPE Atlas", July 2012. 216 http://www.nlnetlabs.nl/downloads/publications/ 217 pmtu-black-holes-msc-thesis.pdf 219 [I-D.ietf-6man-ipv6-atomic-fragments] 220 Gont, F., "Processing of IPv6 "atomic" fragments", 221 draft-ietf-6man-ipv6-atomic-fragments-01 (work in 222 progress), August 2012. 224 [I-D.ietf-6man-oversized-header-chain] 225 Gont, F. and V. Manral, "Security and Interoperability 226 Implications of Oversized IPv6 Header Chains", 227 draft-ietf-6man-oversized-header-chain-01 (work in 228 progress), July 2012. 230 [RFC2761] Dunn, J. and C. Martin, "Terminology for ATM 231 Benchmarking", RFC 2761, February 2000. 233 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 234 Router Control Plane", RFC 6192, March 2011. 236 [draft-6man-atomic] 237 Gont, F., "Processing of IPv6 "atomic" fragments (Work in 238 progress)", August 2012. 240 Authors' Addresses 242 Joel Jaeggli 243 Zynga 244 924 Mouton Circle 245 East Palo Alto, CA 94303 246 USA 248 Email: jjaeggli@zynga.com 250 Lorenzo Colitti 251 Google 253 Phone: 254 Email: lorenzo@google.com 255 Warren Kumari 256 Google 257 1600 Amphitheatre Parkway 258 Mountain View, CA 94043 259 USA 261 Phone: 262 Email: warren@kumari.net 264 Eric Vyncke 265 Cisco 266 De Kleetlaan 6A 267 Diegem, 1831 268 Belgium 270 Phone: 271 Email: evyncke@cisco.com 273 Merike Kaeo 274 Double Shot Security 276 Phone: 277 Email: merike@doubleshotsecurity.com 279 Tom Taylor (editor) 280 Huawei Technologies 281 Ottawa, Ontario 282 Canada 284 Phone: 285 Email: tom.taylor.stds@gmail.com