--- 1/draft-ietf-intarea-frag-fragile-12.txt 2019-06-24 23:13:09.642435961 -0700 +++ 2/draft-ietf-intarea-frag-fragile-13.txt 2019-06-24 23:13:09.698437370 -0700 @@ -1,27 +1,27 @@ Internet Area WG R. Bonica Internet-Draft Juniper Networks Intended status: Best Current Practice F. Baker -Expires: December 21, 2019 Unaffiliated +Expires: December 26, 2019 Unaffiliated G. Huston APNIC R. Hinden Check Point Software O. Troan Cisco F. Gont SI6 Networks - June 19, 2019 + June 24, 2019 IP Fragmentation Considered Fragile - draft-ietf-intarea-frag-fragile-12 + draft-ietf-intarea-frag-fragile-13 Abstract This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. Status of This Memo @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on December 21, 2019. + This Internet-Draft will expire on December 26, 2019. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -110,21 +110,21 @@ introduces. It also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. While this document identifies issues associated with IP fragmentation, it does not recommend deprecation. Legacy protocols that depend upon IP fragmentation SHOULD be updated to remove that dependency. However, some applications and environments (see Section 6) require IP fragmentation. In these cases, the protocol will continue to rely on IP fragmentation, but the designer should to be aware that fragmented packets may result in blackholes; a design - should include appropriate safeguards (e.g. PLPMTU). + should include appropriate safeguards. Rather than deprecating IP Fragmentation, this document recommends that upper-layer protocols address the problem of fragmentation at their layer, reducing their reliance on IP fragmentation to the greatest degree possible. 1.1. IP-in-IP Tunnels This document acknowledges that in some cases, packets must be fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels]. @@ -480,23 +480,21 @@ These reassembly issues are not easily reproducible in IPv6 because the IPv6 identification field is 32 bits long. 4.6. Security Vulnerabilities Security researchers have documented several attacks that exploit IP fragmentation. The following are examples: o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722] - o Resource exhaustion attacks (such as the Rose Attack, - https://web.archive.org/web/20110723091910/ - http://www.digital.net/~gandalf/Rose_Frag_Attack_Explained.htm) + o Resource exhaustion attacks o Attacks based on predictable fragment identification values [RFC7739] o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998] In the overlapping fragment attack, an attacker constructs a series of packet fragments. The first fragment contains an IP header, a transport-layer header, and some transport-layer payload. This fragment complies with local security policy and is allowed to pass