Network Working Group V. Manral Internet-Draft IP Infusion Expires: December 25, 2007 June 26, 2007 IPv6 Fragments and treatment of Tiny fragments draft-manral-ipv6-fragments-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract [RFC2460] defines an IPv6 header called "Fragment Header", which is identified by a Next Header value of 44 in the immediately preceding header. This document clarifies the definition of an IPv6 fragment Manral, et al. Expires December 25, 2007 [Page 1] Internet-Draft IPv6 Fragments June 2007 as well as defines the treatment of what consititues a tiny IPv6 Fragment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 2. IPv6 Fragment . . . . . . . . . . . . . . . . . . . . . . . 3 3. Tiny Fragments and issues . . . . . . . . . . . . . . . . . 4 4. Additional checks required . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Normative References . . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Manral, et al. Expires December 25, 2007 [Page 2] Internet-Draft IPv6 Fragments June 2007 1. Problem Statement The definition of Fragments is slightly vague in the IPv6 specification. This has resulted in different specification using different ways for identifying fragments. The SIIT [RFC2765] specification uses a fragment header to signal the ability of a node to fragment an IPv6 packet, the ESP [RFC4303] and AH [RFC4302] assume the existence of an IPV6 Fragment header identifies an IPv6 Fragment. As different policies are applied for fragments and non-fragments in middle boxes, such ambiguity in the specification can lead to issues. Middleboxes generally use 5-tuples to filter out packets. However there are cases where fragmentation can be used to disguise TCP packets from IP filters and other middleboxes [Tiny-Fragment] used in routers and hosts. This document also specifies ways to identify tiny fragments and the subsequent action that needs to be taken, once such a fragment is identified. 2. IPv6 Fragment The IPv6 specification [RFC2460] defines a fragment header as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the initial header type of the Fragmentable Part of the original packet (defined below). Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.]. Reserved 8-bit reserved field. Initialized to zero for transmission; ignored on reception. Fragment Offset 13-bit unsigned integer. The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part of the original packet. Res 2-bit reserved field. Initialized to zero for transmission; ignored on reception. M flag 1 = more fragments; 0 = last fragment. Identification 32 bits is used for facilitating each fragment is correctly reassembled at the receiver. An IPv6 fragment is defined to be an IPv6 packet, which contains the IPv6 Fragment header as described above, having either the More flag or the Fragment Offset set to have a non 0 value. Manral, et al. Expires December 25, 2007 [Page 3] Internet-Draft IPv6 Fragments June 2007 In turn if an IPv6 packet contains a fragment header, with both the More flag as well as the Fragment Offset fields set to, it is treated exactly like an IPv6 packet without the Fragment header. 3. Tiny Fragments and issues An IPv6 Tiny Fragment is defined as a non-last fragment which has a payload length of less than 1200 octets. A lot of middleboxes (firewalls/ IDS and IPS devices) idenfity sessions based on a 5-tuple of Source IP address, Destination IP Address, Upper Layer protocol, and the souce and destination ports of the protocol. Such information is available in the first Fragment (Fragment Offset 0 and M flag as 1). However in order to bypass checks in middleboxes, smaller first fragments can be sent. This document specifies the behavior of any router on encountering a Tiny Fragment. A Tiny Fragment should be treated to have malicious intent and SHOULD be silently dropped. Manral, et al. Expires December 25, 2007 [Page 4] Internet-Draft IPv6 Fragments June 2007 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Manral, et al. Expires December 25, 2007 [Page 5] Internet-Draft IPv6 Fragments June 2007 5. Security Considerations This draft outlines security issues arising from the use of tiny fragments. It further clarifies the definition of a Fragment Header. This draft enhances the security of IPv6 network and helps prevent attacks caused by tiny fragments or spec ambiguity. No new security requirements result from such proposals. Manral, et al. Expires December 25, 2007 [Page 6] Internet-Draft IPv6 Fragments June 2007 6. Acknowledgements The subject of this draft has been discussed in detail in the IPv6 mailing list. Elwyn Davies, Suresh Krishnan specially contributed ideas to this draft. Manral, et al. Expires December 25, 2007 [Page 7] Internet-Draft IPv6 Fragments June 2007 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC1700] Reynolds J. and J. Postel, "Assigned Numbers", RFC1700, October 1994 7.2 Informative References [I-D.manral-v6ops-tiny-fragments-issues-02] Manral V., "Operational issues with Tiny Fragments in IPv6", (work in progress), July 2006. [RFC2765] Nordmark E., "Stateless IP/ICMP Translation Algorithm (SIIT)", February 2000 [RFC4302] Kent S., "IP Authentication Header (AH)", RFC4302, December 2005 [RFC4303] Kent S., "IP Encapsulating Security Payload (ESP)", RFC4303, December 2005 Manral, et al. Expires December 25, 2007 [Page 8] Internet-Draft IPv6 Fragments June 2007 Contributors Address Authors' Addresses Vishwas Manral IP Infusion Almora, Uttarakhand India Phone: Fax: Email: vishwas@ipinfusion.com Manral, et al. Expires December 25, 2007 [Page 9] Internet-Draft IPv6 Fragments June 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Manral, et al. Expires December 25, 2007 [Page 10] Internet-Draft IPv6 Fragments June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Manral, et al. Expires December 25, 2007 [Page 11]