idnits 2.17.1 draft-manral-6man-tiny-fragments-issues-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 12 has weird spacing: '...ragment heade...' == Line 13 has weird spacing: '... to its dest...' == Line 16 has weird spacing: '...s where fragm...' == Line 57 has weird spacing: '... small enoug...' == Line 58 has weird spacing: '... fields into ...' == (5 more instances...) -- The document date (February 2, 2012) is 4438 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) == Unused Reference: 'RFC1858' is defined on line 210, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V. Manral 2 Internet-Draft Hewlett Packard Co. 3 Intended status: Standards Track February 2, 2012 4 Expires: August 5, 2012 6 Tiny Fragments in IPv6 7 draft-manral-6man-tiny-fragments-issues-00 9 Abstract 11 IPv6 fragmentation allows fragments to be sent only by the source of 12 a packet. The Fragment header is used by an IPv6 source to send a 13 packet larger than would fit in the path MTU to its destination. 15 Firewalls generally use 5-tuples to filter out packets. However there 16 are cases where fragmentation can be used to disguise TCP packets 17 from IP filters used in routers and hosts. This document specifies 18 where tiny fragments can be issues. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 05, 2012. 37 Fragments in IPv6 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 With many IP implementations it is possible to impose a fragment 57 small enough to force some of a packet's Upper Layer e.g. TCP header 58 fields into the second fragment. 60 This can cause all middlebox's like firewall and NAT-PT which expect 61 the fields header information in the first fragment to not work properly. 63 Though the NAT Behave draft, states that NAT box should reassemble 64 the packets, a lot of new issues can result. Keeping state could result 65 in easy DoS attacks. Besides the jury is still out about how many NAT 66 boxes do reassembly. 68 All policy based devices where packets are forwarded or sent on a 69 tunnel based on some policy are also affected. 71 2. Issues with Firewalls 73 There are different types of firewalls and state can be created in 74 these firewalls through different methods. Independent of the 75 adopted method, firewalls typically look at five parameters of the 76 traffic arriving at the firewalls: 78 o Source IP address 80 o Destination IP address 82 o Protocol type 84 o Source port number 86 o Destination port number 88 Based on these parameters, firewalls usually decide whether to allow 89 the traffic or to drop the packets. 91 However in cases where the first fragment does not have the upper 92 layer header information, the firewall is not able to get the port 93 information and other upper layer information, thus allowing the 94 packets to be sent to the protected side. 96 This can lead to attacks to the network and the firewall not being 97 able to block such an attack. 99 3. Issues with NAT-PT 101 NAT-PT [RFC2766] assumes that for NAPT-PT operation the ports are 102 visible to the translator. However if the Upper Layer Header is not 103 there in the first fragment. This causes the visibility ot the port to 104 be lost. This can cause the translation process to fail. 106 When the translator gets a tiny IPv6 fragment which has to be 107 translated to an IPv4 packet. The translator will have to reassemble 108 the packets as the IPv4 non last fragment needs to have a datagram 109 size of 68 octets atleast. 111 STD 5, RFC 791 states: 113 Every internet module must be able to forward a datagram of 68 114 octets without further fragmentation. This is because an internet 115 header may be up to 60 octets, and the minimum fragment is 8 116 octets. 118 4. Issues with Policy Boxes 120 Tiny Fragments could cause issues to Policy boxes which look further 121 inside the packet, to make decisions. 123 For IPsec Security Policy Database (SPD) specifies what services are 124 to be offered to IP datagrams and in what fashion. The draft 125 [RFC2401bis] states: 127 "Non-initial" vs "Initial" Fragments 129 Throughout this document, the phrase "non-initial" fragments is 130 used to mean fragments that do not contain all of the selector 131 values that may be needed for access control. And the phrase 132 "initial" fragment is used to mean a fragment that contains all 133 the selector values needed for access control. 135 However, it should be noted that for IPv6, which fragment contains 136 the Next Layer Protocol and ports (or ICMP message type/code or 137 Mobility Header type) will depend on the kind and number of extension 138 headers present. 140 Having tiny fragments could mean that none of the fragments would 141 be the Initial Fragment. So any access control/ tunneling based on 142 that may not work unless reassembly is done, or extra state like next 143 Header and previous header length remaining are kept across 144 fragments. 146 5. Proposed solutions to the problem 148 a. Impose a minimum packet size for the non-last fragments. If a 149 fragment of a lesser size is received, the packet is treated as a 150 malformed packet and is discarded. 152 b. Reassemble all the fragments of the packet, translate the header 153 fields and, glean out relevent information and then pass the original 154 fragments ahead after modifying the relevent fields. 156 c. Reassemble all the fragments of the packet till we have the header 157 fields of the upper layer , glean out relevent information and then 158 pass the original fragments ahead after modifying the relevent fields. 160 d. If upper layer protocol present then the header must be there in 161 the first fragment. 163 The above is just a first summary and the proposals are expected to 164 change as the draft matures. 166 6. Issues with fragment size of Minimum MTU 168 The minimum fragment size of the non last fragment could be 169 specified to be 1280 octets, the minimum link MTU [RFC2460]. 171 However if the IPv6 packet has to be further tunnelled the packet 172 may have to be fragmented. To prevent such a case a minimum packet 173 size of the non-last fragment should be less then 1280. 175 7. IANA Considerations 177 This document makes no request of IANA. 179 Note to RFC Editor: this section may be removed on publication as an 180 RFC. 182 8. Security Considerations 184 This draft outlines security issues arising if "Tiny Fragments" are 185 sent. This draft raises no new security issues. 187 9. Acknowledgements 189 This draft borrows text heavily from 190 draft-ietf-mip6-firewalls-03.txt and RFC1858. Thanks to Brian 191 Carpenter, Pekka Savola, Stig Venaas,Fred Baker, Pyda 192 Srisuresh, Senthil Sivakumar and Radhakrishnan.S for the 193 helpful discussion. 195 10. References 197 10.1 Normative References 199 [RFC2460] Deering & Hinden, "Internet Protocol, Version 6 (IPv6) 200 Specification", RFC2460, December 1998 202 [RFC2766] Tsirtsis & Srisuresh, "Network Address Translation - 203 Protocol Translation (NAT-PT)", RFC2766, February 2000 205 [RFC2401bis] Kent & Seo, "Security Architecture for the Internet 206 Protocol", Work in Progress, September, 2005 208 10.2 Informative References 210 [RFC1858] Ziemba, Reed & Traina , "Security Considerations - IP 211 Fragment Filtering", RFC1858, October 1995 213 Authors' Addresses 215 Vishwas Manral 216 Hewlett Packard Co, 217 19111 Pruneridge Ave. 218 Cupertino, CA 95014 219 USA 221 Email: vishwas.manral@hp.com