]> Mitigating DoS attacks in IPv6 by clarifying the number of occurrences of Extension Headers University of Liege
10, Allee de la decouverte (B28) 4000 Sart-Tilman Belgium justin.iurman@uliege.be
This document updates RFC 8200 by specifying normative requirements on the number of occurrences of IPv6 Extension Headers. Operational experience has demonstrated that permitting multiple occurrences of the same Extension Header can create parsing ambiguity, increase attack surface, and complicate packet processing in general. This is especially true for both the Hop-by-Hop Options Header and the Destination Options Header, which can contain a number of options. This document restricts IPv6 packets to carry at most one instance of each Extension Header, with the exception of the Destination Options Header, which is permitted to appear twice as specified in RFC 8200.
Section 4.1 of recommends, but does not normatively require, that each Extension Header appear at most once, with the exception of the Destination Options Header, which may appear at most twice, once before a Routing header and once before the upper-layer header. Operational experience has demonstrated that permitting multiple occurrences of the same Extension Header can create parsing ambiguity, increase attack surface, and complicate packet processing in general. This is especially true for both the Hop-by-Hop Options Header and the Destination Options Header, which can contain a number of options. This document updates , in particular Section 4.1, to enforce normative limits on the number of occurrences of Extension Headers and to remove any ambiguity in the text. This document addresses concerns related to DoS attacks on hosts as specified in , although new limits on the number of Hop-by-Hop and Destination Options could be specified in (i.e., smaller than 8).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
The following text replaces paragraph 2 of Section 4.1. OLD (RFC 8200):
Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header).
NEW:
Each extension header SHOULD occur at most once, except for the Destination Options header, which SHOULD occur at most twice (once before a Routing header and once before the upper-layer header).
[RFC Editor: please remove this note] An alternative would be to keep the above text as is, without normative language. The following text replaces paragraph 5 of Section 4.1. OLD (RFC 8200):
IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation.
NEW:
IPv6 nodes must accept and attempt to process extension headers in any order in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. IPv6 nodes MAY discard a packet exceeding the number of occurrences of extension headers.
[RFC Editor: please remove this note] "SHOULD" or even "MUST" would obviously be better, but "MAY" seems to be the only backward compatible solution.
This document does not introduce new security considerations. On the contrary, the change proposed in this document mitigates possible DoS attacks based on an abusive use of Extension Headers in IPv6 packets.
This document does not require any action from IANA.
TBD
&RFC2119; &RFC8174; &RFC8200; &I-D.ietf-6man-eh-limits; &I-D.ietf-6man-rfc8504-bis;