draft-ietf-intarea-frag-fragile-11.txt   draft-ietf-intarea-frag-fragile-12.txt 
Internet Area WG R. Bonica Internet Area WG R. Bonica
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Best Current Practice F. Baker Intended status: Best Current Practice F. Baker
Expires: December 16, 2019 Unaffiliated Expires: December 21, 2019 Unaffiliated
G. Huston G. Huston
APNIC APNIC
R. Hinden R. Hinden
Check Point Software Check Point Software
O. Troan O. Troan
Cisco Cisco
F. Gont F. Gont
SI6 Networks SI6 Networks
June 14, 2019 June 19, 2019
IP Fragmentation Considered Fragile IP Fragmentation Considered Fragile
draft-ietf-intarea-frag-fragile-11 draft-ietf-intarea-frag-fragile-12
Abstract Abstract
This document describes IP fragmentation and explains how it This document describes IP fragmentation and explains how it
introduces fragility to Internet communication. introduces fragility to Internet communication.
This document also proposes alternatives to IP fragmentation and This document also proposes alternatives to IP fragmentation and
provides recommendations for developers and network operators. provides recommendations for developers and network operators.
Status of This Memo Status of This Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 16, 2019. This Internet-Draft will expire on December 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
1. Introduction 1. Introduction
Operational experience [Kent] [Huston] [RFC7872] reveals that IP Operational experience [Kent] [Huston] [RFC7872] reveals that IP
fragmentation introduces fragility to Internet communication. This fragmentation introduces fragility to Internet communication. This
document describes IP fragmentation and explains the fragility it document describes IP fragmentation and explains the fragility it
introduces. It also proposes alternatives to IP fragmentation and introduces. It also proposes alternatives to IP fragmentation and
provides recommendations for developers and network operators. provides recommendations for developers and network operators.
While this document identifies issues associated with IP While this document identifies issues associated with IP
fragmentation, it does not recommend deprecation. Legacy protocols fragmentation, it does not recommend deprecation. Legacy protocols
that depend upon IP fragmentation SHOULD be updated to break that that depend upon IP fragmentation SHOULD be updated to remove that
dependency. However, some applications and environments (see dependency. However, some applications and environments (see
Section 6) require IP fragmentation. In these cases, the protocol Section 6) require IP fragmentation. In these cases, the protocol
will continue to rely on IP fragmentation, but the designer should to will continue to rely on IP fragmentation, but the designer should to
be aware that fragmented packets may result in blackholes; a design be aware that fragmented packets may result in blackholes; a design
should include appropriate safeguards (e.g. PLPMTU). should include appropriate safeguards (e.g. PLPMTU).
Rather than deprecating IP Fragmentation, this document recommends Rather than deprecating IP Fragmentation, this document recommends
that upper-layer protocols address the problem of fragmentation at that upper-layer protocols address the problem of fragmentation at
their layer, reducing their reliance on IP fragmentation to the their layer, reducing their reliance on IP fragmentation to the
greatest degree possible. greatest degree possible.
skipping to change at page 11, line 16 skipping to change at page 11, line 16
the IPv6 identification field is 32 bits long. the IPv6 identification field is 32 bits long.
4.6. Security Vulnerabilities 4.6. Security Vulnerabilities
Security researchers have documented several attacks that exploit IP Security researchers have documented several attacks that exploit IP
fragmentation. The following are examples: fragmentation. The following are examples:
o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722] o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722]
o Resource exhaustion attacks (such as the Rose Attack, 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) http://www.digital.net/~gandalf/Rose_Frag_Attack_Explained.htm)
o Attacks based on predictable fragment identification values o Attacks based on predictable fragment identification values
[RFC7739] [RFC7739]
o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998] o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998]
In the overlapping fragment attack, an attacker constructs a series In the overlapping fragment attack, an attacker constructs a series
of packet fragments. The first fragment contains an IP header, a of packet fragments. The first fragment contains an IP header, a
transport-layer header, and some transport-layer payload. This transport-layer header, and some transport-layer payload. This
skipping to change at page 16, line 20 skipping to change at page 16, line 20
PMTU. For example, if routing changes and as a result the PMTU PMTU. For example, if routing changes and as a result the PMTU
becomes smaller, TCP will not know until the ICMP PTB message becomes smaller, TCP will not know until the ICMP PTB message
arrives. If this occurs, the packet is dropped, the PMTU estimate is arrives. If this occurs, the packet is dropped, the PMTU estimate is
updated, the segment is divided into smaller segments and each updated, the segment is divided into smaller segments and each
smaller segment is submitted to the underlying IP module. smaller segment is submitted to the underlying IP module.
The Datagram Congestion Control Protocol (DCCP) [RFC4340] and the The Datagram Congestion Control Protocol (DCCP) [RFC4340] and the
Stream Control Transport Protocol (SCTP) [RFC4960] also can be Stream Control Transport Protocol (SCTP) [RFC4960] also can be
operated in a mode that does not require IP fragmentation. They both operated in a mode that does not require IP fragmentation. They both
accept data from an application and divide that data into segments, accept data from an application and divide that data into segments,
with no segment exceeding a maximum size. </t><t> DCCP offers manual with no segment exceeding a maximum size.
configuration, PMTUD, and PLPMTUD as mechanisms for managing that
maximum size. Datagram protocols can also implement PLPMTUD to DCCP offers manual configuration, PMTUD, and PLPMTUD as mechanisms
estimate the PMTU via[I-D.ietf-tsvwg-datagram-plpmtud]. This for managing that maximum size. Datagram protocols can also
proposes procedures for performing PLPMTUD with UDP, UDP-Options, implement PLPMTUD to estimate the PMTU
SCTP, QUIC and other datagram protocols. via[I-D.ietf-tsvwg-datagram-plpmtud]. This proposes procedures for
performing PLPMTUD with UDP, UDP-Options, SCTP, QUIC and other
datagram protocols.
Currently, User Data Protocol (UDP) [RFC0768] lacks a fragmentation Currently, User Data Protocol (UDP) [RFC0768] lacks a fragmentation
mechanism of its own and relies on IP fragmentation. However, mechanism of its own and relies on IP fragmentation. However,
[I-D.ietf-tsvwg-udp-options] proposes a fragmentation mechanism for [I-D.ietf-tsvwg-udp-options] proposes a fragmentation mechanism for
UDP. UDP.
5.2. Application Layer Solutions 5.2. Application Layer Solutions
[RFC8085] recognizes that IP fragmentation reduces the reliability of [RFC8085] recognizes that IP fragmentation reduces the reliability of
Internet communication. It also recognizes that UDP lacks a Internet communication. It also recognizes that UDP lacks a
skipping to change at page 20, line 14 skipping to change at page 20, line 17
boxes may perform sub-optimally, process IP fragments in a manner boxes may perform sub-optimally, process IP fragments in a manner
that is not compliant with RFC 791 or RFC 8200, or even discard IP that is not compliant with RFC 791 or RFC 8200, or even discard IP
fragments completely. Such behaviors are NOT RECOMMENDED. If a fragments completely. Such behaviors are NOT RECOMMENDED. If a
middleboxes implements non-standard behavior with respect to IP middleboxes implements non-standard behavior with respect to IP
fragmentation, then that behavior MUST be clearly documented. fragmentation, then that behavior MUST be clearly documented.
7.4. For ECMP, LAG and Load-Balancer Developers And Operators 7.4. For ECMP, LAG and Load-Balancer Developers And Operators
In their default configuration, when the IPv6 Flow Label is not equal In their default configuration, when the IPv6 Flow Label is not equal
to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP) to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP)
Routing as described in <xref target="RFC2328">OSPF</xref> and other Routing as described in OSPF [RFC2328] and other routing protocols,
routing protocols, <xref target="RFC7424">Link Aggregation Grouping Link Aggregation Grouping (LAG) [RFC7424], or other load-balancing
(LAG)</xref>, or other load-balancing technologies SHOULD accept only technologies SHOULD accept only the following fields as input to
the following fields as input to their hash algorithm:</t> their hash algorithm:
o IP Source Address. o IP Source Address.
o IP Destination Address. o IP Destination Address.
o Flow Label. o Flow Label.
<t>Operators SHOULD deploy these devices in their default Operators SHOULD deploy these devices in their default configuration.
configuration.
These recommendations are similar to those presented in [RFC6438] and These recommendations are similar to those presented in [RFC6438] and
[RFC7098]. They differ in that they specify a default configuration. [RFC7098]. They differ in that they specify a default configuration.
7.5. For Network Operators 7.5. For Network Operators
Operators MUST ensure proper PMTUD operation in their network, Operators MUST ensure proper PMTUD operation in their network,
including making sure the network generates PTB packets when dropping including making sure the network generates PTB packets when dropping
packets too large compared to outgoing interface MTU. However, packets too large compared to outgoing interface MTU. However,
implementations MAY rate limit ICMP messages as per [RFC1812] and implementations MAY rate limit ICMP messages as per [RFC1812] and
skipping to change at page 25, line 32 skipping to change at page 25, line 32
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>. April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
Flow Label for Load Balancing in Server Farms", RFC 7098, Flow Label for Load Balancing in Server Farms", RFC 7098,
DOI 10.17487/RFC7098, January 2014, DOI 10.17487/RFC7098, January 2014,
<https://www.rfc-editor.org/info/rfc7098>. <https://www.rfc-editor.org/info/rfc7098>.
[RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B.
Khasnabish, "Mechanisms for Optimizing Link Aggregation
Group (LAG) and Equal-Cost Multipath (ECMP) Component Link
Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424,
January 2015, <https://www.rfc-editor.org/info/rfc7424>.
[RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely
Deployed Solution to the Generic Routing Encapsulation Deployed Solution to the Generic Routing Encapsulation
(GRE) Fragmentation Problem", RFC 7588, (GRE) Fragmentation Problem", RFC 7588,
DOI 10.17487/RFC7588, July 2015, DOI 10.17487/RFC7588, July 2015,
<https://www.rfc-editor.org/info/rfc7588>. <https://www.rfc-editor.org/info/rfc7588>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>. <https://www.rfc-editor.org/info/rfc7676>.
 End of changes. 10 change blocks. 
17 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/