< draft-ietf-6man-icmp-limits-02.txt   draft-ietf-6man-icmp-limits-03.txt >
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Standard Quantonium Intended Status: Standard Quantonium
Expires: November 2019 Expires: November 2019
May 23, 2019 May 29, 2019
ICMPv6 errors for discarding packets due to processing limits ICMPv6 errors for discarding packets due to processing limits
draft-ietf-6man-icmp-limits-02 draft-ietf-6man-icmp-limits-03
Abstract Abstract
Network nodes may discard packets if they are unable to process Network nodes may discard packets if they are unable to process
protocol headers of packets due to processing constraints or limits. protocol headers of packets due to processing constraints or limits.
When such packets are dropped, the sender receives no indication so When such packets are dropped, the sender receives no indication so
it cannot take action to address the cause of discarded packets. This it cannot take action to address the cause of discarded packets. This
document defines ICMPv6 errors that can be sent by a node that document defines ICMPv6 errors that can be sent by a node that
discards packets because it is unable to process the protocol discards packets because it is unable to process the protocol
headers. A node that receives such an ICMPv6 error may be able to headers. A node that receives such an ICMPv6 error may be able to
skipping to change at page 3, line 25 skipping to change at page 3, line 25
1.1 Extension header limits 1.1 Extension header limits
In IPv6, optional internet-layer information is carried in one or In IPv6, optional internet-layer information is carried in one or
more IPv6 Extension Headers [RFC8200]. Extension Headers are placed more IPv6 Extension Headers [RFC8200]. Extension Headers are placed
between the IPv6 header and the Upper-Layer Header in a packet. The between the IPv6 header and the Upper-Layer Header in a packet. The
term "Header Chain" refers collectively to the IPv6 header, Extension term "Header Chain" refers collectively to the IPv6 header, Extension
Headers, and Upper-Layer Headers occurring in a packet. Individual Headers, and Upper-Layer Headers occurring in a packet. Individual
extension headers may have a length of 2048 octets and must fit into extension headers may have a length of 2048 octets and must fit into
one MTU. Destination Options and Hop-by-Hop Options contain a list of one MTU. Destination Options and Hop-by-Hop Options contain a list of
options in Type-length-value (TLV) format. Each option includes a options in Type-length-value (TLV) format. Each option includes a
length of the data field in octets, and the minimum size of an option length of the data field in octets: the minimum size of an option
(non-pad type) is two bytes and the maximum length is 257 bytes. The (non-pad type) is two octets and the maximum size is 257 octets. The
number of options in an extension header is only limited by the number of options in an extension header is only limited by the
length of the extension header and MTU. Options may also be skipped length of the extension header and MTU. Options may also be skipped
over by a receiver if they are unknown and the Option Type indicates over by a receiver if they are unknown and the Option Type indicates
to skip (first two high order bits are 00). to skip (first two high order bits are 00).
Per [RFC8200], except for Hop by Hop options, extension headers are Per [RFC8200], except for Hop by Hop options, extension headers are
not examined or processed by intermediate nodes. Many intermediate not examined or processed by intermediate nodes. Many intermediate
nodes, however, do examine extension header for various purposes. For nodes, however, do examine extension header for various purposes. For
instance, a node may examine all extension headers to locate the instance, a node may examine all extension headers to locate the
transport header of a packet in order to implement transport layer transport header of a packet in order to implement transport layer
filtering or to track connections to implement a stateful firewall. filtering or to track connections to implement a stateful firewall.
Destination hosts are expected to process all extensions headers and Destination hosts are expected to process all extension headers and
options in Hop-by-Hop and Destination Options. options in Hop-by-Hop and Destination Options.
Due to the variable lengths, high maximum lengths, or potential for Due to the variable lengths, high maximum lengths, or potential for
Denial of Service attack of extension headers-- many devices impose Denial of Service attack of extension headers, many devices impose
operational limits on extension headers in packets they process. operational limits on extension headers in packets they process.
[RFC7045] discusses the requirements of intermediate nodes that [RFC7045] discusses the requirements of intermediate nodes that
discard packets because of unrecognized extension headers. [RFC8504] discard packets because of unrecognized extension headers. [RFC8504]
discusses limits that may be applied on the number of options in Hop- discusses limits that may be applied to the number of options in Hop-
by-Hop or Destination Options extension headers. When a limit is by-Hop or Destination Options extension headers. When a limit is
exceeded, the typical behavior is to silently discard a packet. Both exceeded, the typical behavior is to silently discard a packet. Both
intermediate nodes and end hosts may institute limits on extension intermediate nodes and end hosts may implement limits to extension
header processing. header processing.
This document defines four Parameter Problem codes and extends the This document defines four Parameter Problem codes and extends the
applicably of an existing code that may be sent by a node that applicably of an existing code that may be sent by a node that
discards a packet due to processing limits of extension headers being discards a packet due to processing limits of extension headers being
exceeded. A source host that receives an ICMPv6 error can modify its exceeded. A source host that receives an ICMPv6 error can modify its
use of extension headers in subsequent packets sent to the use of extension headers in subsequent packets sent to the
destination in order to avoid further occurrences of packets being destination in order to avoid further occurrences of packets being
discarded. discarded.
1.2 Aggregate header limits 1.2 Aggregate header limits
Many hardware devices implement a parsing buffer of a fixed sized to Many hardware devices implement a parsing buffer of a fixed size to
process packets. The parsing buffer is expected to contain all the process packets. The parsing buffer is expected to contain all the
headers (often up to a transport layer header for filtering) that a headers (often up to a transport layer header for filtering) that a
device needs to examine. Parsing buffers have been implemented with device needs to examine. Parsing buffers have been implemented with
various sizes (512 bytes is common, although some devices have various sizes (512 bytes is common, although some devices have
smaller sizes). If the aggregate length of headers in a packet smaller sizes). If the aggregate length of headers in a packet
exceeds the size of the parsing buffer, a device will either discard exceeds the size of the parsing buffer, a device will either discard
the packet or defer processing to a software slow path. In any case, the packet or defer processing to a software slow path. In any case,
no indication of a problem is sent back to the sender. no indication of a problem is sent back to the sender.
This document defines one code for ICMPv6 Destination Unreachable This document defines one code for ICMPv6 Destination Unreachable
that is sent by a node that is unable to process the headers of a that is sent by a node that is unable to process the headers of a
packet due to the aggregate size of the packet headers exceeding a packet due to the aggregate size of the packet headers exceeding a
processing limit. A source host that receives an ICMPv6 error can processing limit. A source host that receives an ICMPv6 error can
modify the headers used in subsequent packets to try to avoid further modify the headers used in subsequent packets to try to avoid further
occurrences of packets being discarded or relegated to a slow path. occurrences of packets being discarded or relegated to a slow path.
2 ICMPv6 errors for extension header limits 2 ICMPv6 errors for extension header limits
Three new codes are defined for Parameter Problem type and Four new codes are defined for Parameter Problem types and
applicability of one existing code is extended for ICMPv6 errors for applicability of one existing code is extended for ICMPv6 errors for
extension header limits. extension header limits.
2.1 Format 2.1 Format
The format of the ICMPv6 message for an extension header limit The format of the ICMPv6 message for an extension header limit
exceeded error is: exceeded error is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 6, line 12 skipping to change at page 6, line 12
An ICMPv6 Parameter Problem with code for "extension header too big" An ICMPv6 Parameter Problem with code for "extension header too big"
SHOULD be sent when a node discards a packet because the size of an SHOULD be sent when a node discards a packet because the size of an
extension header exceeds its processing limit. The ICMPv6 Pointer extension header exceeds its processing limit. The ICMPv6 Pointer
field is set to the offset of the first octet in the extension header field is set to the offset of the first octet in the extension header
that exceeds the limit. that exceeds the limit.
2.4 Extension header chain too long (code 5) 2.4 Extension header chain too long (code 5)
An ICMPv6 Parameter Problem with code for "extension header chain too An ICMPv6 Parameter Problem with code for "extension header chain too
long" SHOULD be sent when a node discards a packet with an extension long" SHOULD be sent when a node discards a packet with an extension
header chain because an extension header chain exceeds it processing header chain because an extension header chain exceeds its processing
limit. limit.
There are two different limits that might be applied: a limit on the There are two different limits that might be applied: a limit on the
total size in octets of the header chain, and a limit on the number total size in octets of the header chain, and a limit on the number
of extension headers in the chain. This error code is used in both of extension headers in the chain. This error code is used in both
cases. In the case that the size limit is exceeded, the ICMPv6 cases. In the case that the size limit is exceeded, the ICMPv6
Pointer is set to first octet beyond the limit. In the case that the Pointer is set to first octet beyond the limit. In the case that the
number of extension headers is exceeded, the ICMPv6 Pointer is set to number of extension headers is exceeded, the ICMPv6 Pointer is set to
the offset of first octet of the first extension header that is the offset of first octet of the first extension header that is
beyond the limit. beyond the limit.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
* A host system SHOULD take appropriate action if it is * A host system SHOULD take appropriate action if it is
automatically inserting extension headers into packets on behalf automatically inserting extension headers into packets on behalf
of the application. If the offending extension header is not of the application. If the offending extension header is not
required for communication, the host MAY either stop sending it required for communication, the host MAY either stop sending it
or otherwise modify its use in subsequent packets sent to the or otherwise modify its use in subsequent packets sent to the
destination indicated in the ICMPv6 error. destination indicated in the ICMPv6 error.
5 Security Considerations 5 Security Considerations
This document does not introduce any new security concerns for use of The security considerations for ICMPv6 described in [RFC4443] are
ICMPv6 errors. The security considerations for ICMPv6 described in applicable. The ICMP errors described in this document MAY be
[RFC4443] are applicable. filtered by firewalls in accordance with [RFC4890].
In some circumstances, the sending of ICMP errors might conceptually
be exploited for denial of service attack or as a means to covertly
deduce processing capabilities of nodes as a precursor to denial of
service attack. As such, an implementation SHOULD allow configurable
policy to withhold sending of the ICMP errors described in this
specification in environments where security of ICMP errors is a
concern.
6 IANA Considerations 6 IANA Considerations
6.1 Parameter Problem codes 6.1 Parameter Problem codes
IANA is requested to assign the following codes for ICMPv6 type 4 IANA is requested to assign the following codes for ICMPv6 type 4
"Parameter Problem": "Parameter Problem":
4 - Extension header too big 4 - Extension header too big
skipping to change at page 11, line 29 skipping to change at page 11, line 29
6.2 Destination Unreachable codes 6.2 Destination Unreachable codes
IANA is requested to assign the following codes for ICMPv6 type 1 IANA is requested to assign the following codes for ICMPv6 type 1
"Destination Unreachable": "Destination Unreachable":
8 - Headers too long 8 - Headers too long
7 Acknowledgments 7 Acknowledgments
The author would like to thank Ron Bonica and Bob Hinden for their The author would like to thank Ron Bonica, Bob Hinden, and Nick
comments and suggestions that improved this document. Hilliard for their comments and suggestions that improved this
document.
8 References 8 References
8.1 Normative References 8.1 Normative References
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Protocol Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, DOI Version 6 (IPv6) Specification", RFC 4443, DOI
10.17487/RFC4443, March 2006, <http://www.rfc- 10.17487/RFC4443, March 2006, <http://www.rfc-
editor.org/info/rfc4443>. editor.org/info/rfc4443>.
skipping to change at page 12, line 10 skipping to change at page 12, line 13
December 2013, <http://www.rfc-editor.org/info/rfc7045>. December 2013, <http://www.rfc-editor.org/info/rfc7045>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884, "Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007, <https://www.rfc- DOI 10.17487/RFC4884, April 2007, <https://www.rfc-
editor.org/info/rfc4884>. editor.org/info/rfc4884>.
8.2 Informative References 8.2 Informative References
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
<https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, DOI
10.17487/RFC4890, May 2007, <https://www.rfc-
editor.org/info/rfc4890>.
Author's Address Author's Address
Tom Herbert Tom Herbert
Quantonium Quantonium
Santa Clara, CA Santa Clara, CA
USA USA
Email: tom@quantonium.net Email: tom@quantonium.net
 End of changes. 13 change blocks. 
18 lines changed or deleted 32 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/