Processing of IPv6 "Atomic" Fragments
RFC 6946
Document | Type | RFC - Proposed Standard (May 2013; No errata) | |
---|---|---|---|
Author | Fernando Gont | ||
Last updated | 2020-07-29 | ||
Replaces | draft-gont-6man-ipv6-atomic-fragments | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Bob Hinden | ||
Shepherd write-up | Show (last changed 2012-12-07) | ||
IESG | IESG state | RFC 6946 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Brian Haberman | ||
Send notices to | (None) |
Internet Engineering Task Force (IETF) F. Gont Request for Comments: 6946 Huawei Technologies Updates: 2460, 5722 May 2013 Category: Standards Track ISSN: 2070-1721 Processing of IPv6 "Atomic" Fragments Abstract The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6946. Gont Standards Track [Page 1] RFC 6946 IPv6 Atomic Fragments May 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................4 3. Generation of IPv6 Atomic Fragments .............................4 4. Updating RFC 2460 and RFC 5722 ..................................5 5. Security Considerations .........................................6 6. Acknowledgements ................................................6 7. References ......................................................7 7.1. Normative References .......................................7 7.2. Informative References .....................................7 Appendix A. Survey of Processing of IPv6 Atomic Fragments by Different Operating Systems ............................8 1. Introduction [RFC2460] specifies the IPv6 fragmentation mechanism, which allows IPv6 packets to be fragmented into smaller pieces such that they fit in the Path-MTU to the intended destination(s). [RFC2460] allows fragments to overlap, thus leading to ambiguity in the result of the reassembly process, which could be leveraged by attackers to bypass firewall rules and/or evade Network Intrusion Detection Systems (NIDS) [RFC5722]. [RFC5722] forbids overlapping fragments, specifying that when overlapping fragments are detected, all the fragments corresponding to that packet must be silently discarded. As specified in Section 5 of [RFC2460], when a host receives an ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller than 1280 (the minimum IPv6 MTU), it is not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination. The resulting packets Gont Standards Track [Page 2] RFC 6946 IPv6 Atomic Fragments May 2013 will thus not actually be fragmented into several pieces but will just include a Fragment Header with both the "Fragment Offset" and the "M" flag set to 0 (we refer to these packets as "atomicShow full document text