idnits 2.17.1 draft-krishnan-6man-overlap-fragment-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, updated by RFC 4748 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 262. 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 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). -- 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 (July 13, 2008) is 5764 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 (==), 7 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 Intended status: Standards Track July 13, 2008 5 Expires: January 14, 2009 7 Issues with overlapping IPv6 fragments 8 draft-krishnan-6man-overlap-fragment-01 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 January 14, 2009. 35 Abstract 37 The fragmentation and reassembly algorithm specified in the base IPv6 38 specification allows fragments to overlap. This document 39 demonstrates the security issues with allowing overlapping fragments 40 and updates the IPv6 specification to explicitly forbid overlapping 41 fragments. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1. Conventions used in this document . . . . . . . . . . . . . 3 47 2. Overlapping fragments . . . . . . . . . . . . . . . . . . . . . 3 48 3. The attack . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5 50 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 51 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 52 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 Intellectual Property and Copyright Statements . . . . . . . . . . 7 56 1. Introduction 58 Fragmentation is used in IPv6 when the IPv6 packet will not fit 59 inside the path MTU to its destination. When fragmentation is 60 performed an IPv6 node uses a fragment header as specified in section 61 4.5 of the IPv6 base specification [RFC2460] to break down the 62 datagram into smaller fragments that will fit in the path MTU. The 63 destination node receives these fragments and reassembles them. The 64 algorithm specified for fragmentation in [RFC2460] does not prevent 65 the fragments from overlapping, and this can lead to some security 66 issues with firewalls [RFC4942]. This document explores the issues 67 that can be caused by overlapping fragments. 69 1.1. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Overlapping fragments 77 Commonly used firewalls use the algorithm specified in [RFC1858] to 78 weed out malicious packets that try to overwrite parts of the 79 transport layer header to bypass inbound connection checks. 80 [RFC1858] prevents an overlapping fragment attack on an upper layer 81 protocol (in this case TCP) by recommending that packets with 82 fragment offset 1 be dropped. While this works well for IPv4 83 fragments, it will not work for IPv6 fragments. This is because the 84 fragmentable part of the IPv6 packet can contain extension headers 85 before the TCP header, making this check less effective. 87 3. The attack 89 This attack describes how a malicious node can bypass a firewall 90 using overlapping fragments. Consider a sufficiently large IPv6 91 packet that needs to be fragmented. 93 +------------------+--------------------//-----------------------+ 94 | Unfragmentable | Fragmentable | 95 | Part | Part | 96 +------------------+--------------------//-----------------------+ 98 Figure 1: Large IPv6 packet 100 This packet is split into several fragments by the sender so that the 101 packet can fit inside the path MTU. Let's say the packet is split 102 into two fragments. 104 +------------------+--------+--------------+ 105 | Unfragmentable |Fragment| first | 106 | Part | Header | fragment | 107 +------------------+--------+--------------+ 109 +------------------+--------+--------------+ 110 | Unfragmentable |Fragment| second | 111 | Part | Header | fragment | 112 +------------------+--------+--------------+ 114 Figure 2: Fragmented IPv6 packet 116 Consider the first fragment. Let's say it contains a destination 117 options header (DOH) 80 octets long and is followed by a TCP header. 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH 120 |NextHdr=DOH(60)| Reserved | FragmentOffset = 0 |Res|1| 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Identification=aaaabbbb | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==DOH 124 |NextHdr=TCP(6) | HdrExtLen = 9 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 126 | | 127 . . 128 . Options . 129 . . 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP 132 | Source Port | Destination Port | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Sequence Number | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Acknowledgment Number | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Offset| Reserved |U|A|P|R|S|F| Window | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Figure 3: First Fragment 143 The TCP header has the following values of the flags S(YN)=0 and 144 A(CK)=1. This makes an inspecting stateful firewall think that it is 145 a response packet for a connection request initiated from the trusted 146 side of the firewall. Hence it will allow the fragment to pass. It 147 will also let the following fragments with the same Fragment 148 Identification value in the fragment header to pass through. 150 A malicious node can form a second fragment with a TCP header that 151 reverses the flags and sets S(YN)=1 and A(CK)=0. This would change 152 the packet on the receiving end to consider the packet as a 153 connection request instead of a response. By doing this the 154 malicious node has bypassed the firewall's access control to initiate 155 a connection request to a node protected by a firewall. 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH 158 |NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0| 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Identification=aaaabbbb | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP 162 | Source Port | Destination Port | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Sequence Number | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Acknowledgment Number | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Offset| Reserved |U|A|P|R|S|F| Window | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 4: Second Fragment 173 Note that this attack is much more serious in IPv6 than in IPv4. In 174 IPv4 the overlapping part of the TCP header did not include the 175 source and destination ports. In IPv6 the attack can easily work to 176 replace destination ports with an overlapping fragment. 178 4. Recommendation 180 IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT 181 create overlapping fragments. IPv6 nodes that receive a fragment 182 that overlaps with a previously received fragment MUST cease the 183 reassembly process and MUST ignore further fragments with the same 184 IPv6 Source Address, IPv6 Destination Address and Fragment 185 Identification. It MUST also discard the previously received 186 fragments with the same previously specified identifiers. 188 5. Security Considerations 190 This document discusses an attack that can be used to bypass IPv6 191 firewalls using overlapping fragments. It recommends disallowing 192 overlapping fragments in order to prevent this attack. 194 6. IANA Considerations 196 This document does not require any action from the IANA. 198 7. Normative References 200 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 201 Considerations for IP Fragment Filtering", RFC 1858, 202 October 1995. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 208 (IPv6) Specification", RFC 2460, December 1998. 210 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 211 Co-existence Security Considerations", RFC 4942, 212 September 2007. 214 Author's Address 216 Suresh Krishnan 217 Ericsson 218 8400 Blvd Decarie 219 Town of Mount Royal, Quebec 220 Canada 222 Email: suresh.krishnan@ericsson.com 224 Full Copyright Statement 226 Copyright (C) The IETF Trust (2008). 228 This document is subject to the rights, licenses and restrictions 229 contained in BCP 78, and except as set forth therein, the authors 230 retain all their rights. 232 This document and the information contained herein are provided on an 233 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 234 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 235 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 236 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 237 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 238 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 240 Intellectual Property 242 The IETF takes no position regarding the validity or scope of any 243 Intellectual Property Rights or other rights that might be claimed to 244 pertain to the implementation or use of the technology described in 245 this document or the extent to which any license under such rights 246 might or might not be available; nor does it represent that it has 247 made any independent effort to identify any such rights. Information 248 on the procedures with respect to rights in RFC documents can be 249 found in BCP 78 and BCP 79. 251 Copies of IPR disclosures made to the IETF Secretariat and any 252 assurances of licenses to be made available, or the result of an 253 attempt made to obtain a general license or permission for the use of 254 such proprietary rights by implementers or users of this 255 specification can be obtained from the IETF on-line IPR repository at 256 http://www.ietf.org/ipr. 258 The IETF invites any interested party to bring to its attention any 259 copyrights, patents or patent applications, or other proprietary 260 rights that may cover technology that may be required to implement 261 this standard. Please address the information to the IETF at 262 ietf-ipr@ietf.org.