idnits 2.17.1 draft-ietf-6man-overlap-fragment-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 264. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2460, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- 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 22, 2008) is 5666 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) ** Downref: Normative reference to an Informational RFC: RFC 1858 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 4942 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Updates: 2460 (if approved) September 22, 2008 5 Intended status: Standards Track 6 Expires: March 26, 2009 8 Handling of overlapping IPv6 fragments 9 draft-ietf-6man-overlap-fragment-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 26, 2009. 36 Abstract 38 The fragmentation and reassembly algorithm specified in the base IPv6 39 specification allows fragments to overlap. This document 40 demonstrates the security issues with allowing overlapping fragments 41 and updates the IPv6 specification to explicitly forbid overlapping 42 fragments. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. Conventions used in this document . . . . . . . . . . . . . 3 48 2. Overlapping fragments . . . . . . . . . . . . . . . . . . . . . 3 49 3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 53 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Intellectual Property and Copyright Statements . . . . . . . . . . 7 57 1. Introduction 59 Fragmentation is used in IPv6 when the IPv6 packet will not fit 60 inside the path MTU to its destination. When fragmentation is 61 performed an IPv6 node uses a fragment header as specified in section 62 4.5 of the IPv6 base specification [RFC2460] to break down the 63 datagram into smaller fragments that will fit in the path MTU. The 64 destination node receives these fragments and reassembles them. The 65 algorithm specified for fragmentation in [RFC2460] does not prevent 66 the fragments from overlapping, and this can lead to some security 67 issues with firewalls [RFC4942]. This document explores the issues 68 that can be caused by overlapping fragments. 70 1.1. Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Overlapping fragments 78 Commonly used firewalls use the algorithm specified in [RFC1858] to 79 weed out malicious packets that try to overwrite parts of the 80 transport layer header to bypass inbound connection checks. 81 [RFC1858] prevents an overlapping fragment attack on an upper layer 82 protocol (in this case TCP) by recommending that packets with 83 fragment offset 1 be dropped. While this works well for IPv4 84 fragments, it will not work for IPv6 fragments. This is because the 85 fragmentable part of the IPv6 packet can contain extension headers 86 before the TCP header, making this check less effective. 88 3. The attack 90 This attack describes how a malicious node can bypass a firewall 91 using overlapping fragments. Consider a sufficiently large IPv6 92 packet that needs to be fragmented. 94 +------------------+--------------------//-----------------------+ 95 | Unfragmentable | Fragmentable | 96 | Part | Part | 97 +------------------+--------------------//-----------------------+ 99 Figure 1: Large IPv6 packet 101 This packet is split into several fragments by the sender so that the 102 packet can fit inside the path MTU. Let's say the packet is split 103 into two fragments. 105 +------------------+--------+--------------+ 106 | Unfragmentable |Fragment| first | 107 | Part | Header | fragment | 108 +------------------+--------+--------------+ 110 +------------------+--------+--------------+ 111 | Unfragmentable |Fragment| second | 112 | Part | Header | fragment | 113 +------------------+--------+--------------+ 115 Figure 2: Fragmented IPv6 packet 117 Consider the first fragment. Let's say it contains a destination 118 options header (DOH) 80 octets long and is followed by a TCP header. 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH 121 |NextHdr=DOH(60)| Reserved | FragmentOffset = 0 |Res|1| 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Identification=aaaabbbb | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==DOH 125 |NextHdr=TCP(6) | HdrExtLen = 9 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 127 | | 128 . . 129 . Options . 130 . . 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP 133 | Source Port | Destination Port | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Sequence Number | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Acknowledgment Number | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Offset| Reserved |U|A|P|R|S|F| Window | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 3: First Fragment 144 The TCP header has the following values of the flags S(YN)=0 and 145 A(CK)=1. This makes an inspecting stateful firewall think that it is 146 a response packet for a connection request initiated from the trusted 147 side of the firewall. Hence it will allow the fragment to pass. It 148 will also let the following fragments with the same Fragment 149 Identification value in the fragment header to pass through. 151 A malicious node can form a second fragment with a TCP header that 152 reverses the flags and sets S(YN)=1 and A(CK)=0. This would change 153 the packet on the receiving end to consider the packet as a 154 connection request instead of a response. By doing this the 155 malicious node has bypassed the firewall's access control to initiate 156 a connection request to a node protected by a firewall. 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH 159 |NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0| 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Identification=aaaabbbb | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP 163 | Source Port | Destination Port | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Sequence Number | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Acknowledgment Number | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Offset| Reserved |U|A|P|R|S|F| Window | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 4: Second Fragment 174 Note that this attack is much more serious in IPv6 than in IPv4. In 175 IPv4 the overlapping part of the TCP header did not include the 176 source and destination ports. In IPv6 the attack can easily work to 177 replace destination ports with an overlapping fragment. 179 4. Recommendation 181 IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT 182 create overlapping fragments. IPv6 nodes that receive a fragment 183 that overlaps with a previously received fragment MUST cease the 184 reassembly process and MUST ignore further fragments with the same 185 IPv6 Source Address, IPv6 Destination Address and Fragment 186 Identification. It MUST also discard the previously received 187 fragments with the same IPv6 Source Address, IPv6 Destination Address 188 and Fragment Identification. 190 5. Security Considerations 192 This document discusses an attack that can be used to bypass IPv6 193 firewalls using overlapping fragments. It recommends disallowing 194 overlapping fragments in order to prevent this attack. 196 6. IANA Considerations 198 This document does not require any action from the IANA. 200 7. Normative References 202 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 203 Considerations for IP Fragment Filtering", RFC 1858, 204 October 1995. 206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 207 Requirement Levels", BCP 14, RFC 2119, March 1997. 209 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 210 (IPv6) Specification", RFC 2460, December 1998. 212 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 213 Co-existence Security Considerations", RFC 4942, 214 September 2007. 216 Author's Address 218 Suresh Krishnan 219 Ericsson 220 8400 Blvd Decarie 221 Town of Mount Royal, Quebec 222 Canada 224 Email: suresh.krishnan@ericsson.com 226 Full Copyright Statement 228 Copyright (C) The IETF Trust (2008). 230 This document is subject to the rights, licenses and restrictions 231 contained in BCP 78, and except as set forth therein, the authors 232 retain all their rights. 234 This document and the information contained herein are provided on an 235 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 236 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 237 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 238 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 239 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 240 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 242 Intellectual Property 244 The IETF takes no position regarding the validity or scope of any 245 Intellectual Property Rights or other rights that might be claimed to 246 pertain to the implementation or use of the technology described in 247 this document or the extent to which any license under such rights 248 might or might not be available; nor does it represent that it has 249 made any independent effort to identify any such rights. Information 250 on the procedures with respect to rights in RFC documents can be 251 found in BCP 78 and BCP 79. 253 Copies of IPR disclosures made to the IETF Secretariat and any 254 assurances of licenses to be made available, or the result of an 255 attempt made to obtain a general license or permission for the use of 256 such proprietary rights by implementers or users of this 257 specification can be obtained from the IETF on-line IPR repository at 258 http://www.ietf.org/ipr. 260 The IETF invites any interested party to bring to its attention any 261 copyrights, patents or patent applications, or other proprietary 262 rights that may cover technology that may be required to implement 263 this standard. Please address the information to the IETF at 264 ietf-ipr@ietf.org.