RFC6434bis open issue - IPv6 EH protection

[Tim Chown <[e-mail]>]

Hi,

Here is a second open issue in the draft for which the authors would like comments.

In response to previous discussions, Tom Herbert kindly supplied some text on how nodes may protect themselves from excessive EH options.

There are two issues here.
1. Does the text look reasonable?
2. The text is quite long, and is not published elsewhere; is a separate draft more appropriate with just briefer text in 6434bis?

In general, we have minimised new text in 6434bis, and pointed at material published in RFCs elsewhere.

— snip —

5.3.  Protecting a node from excessive EH options

   Per RFC 8200, end hosts are expected to process all extension
   headers, destination options, and hop-by-hop options in a packet.
   Given that the only limit on the number and size of extension headers
   is the MTU, the processing of received packets could be considerable.
   It is also conceivable that a long chain of extension headers might
   be used as a form of denial-of-service attack.  Accordingly, a host
   may place limits on the number and sizes of extension headers and
   options it is willing to process.

   A host MAY limit the number of consecutive PAD1 options in
   destination options or hop-by-hop options to seven.  In this case, if
   the more than seven consecutive PAD1 options are present the the
   packet should be silently discarded.  The rationale is that if
   padding of eight or more bytes is required than the PADN option
   should be used.

   A host MAY limit number of bytes in a PADN option to be less than
   eight.  In such a case, if a PADN option is present that has a length
   greater than seven then the packet should be silently discarded.  The
   rationale for this guideline is that the purpose of padding is for
   alignment and eight bytes is the maximum alignment used in IPv6.

   A host MAY disallow unknown options in destination options or hob-by-
   hop options.  This should be configurable where the default is to
   accept unknown options and process them per RFC2460.  If a packet
   with unknown options is received and the host is configured to
   disallow them, then the packet should be silently discarded.

   A host MAY impose a limit on the maximum number of non-padding
   options allowed in a destination options and hop-by-hop extension
   headers.  If this feature is supported the maximum number should be
   configurable and the default value SHOULD be set to eight.  The
   limits for destination options and hop-by-hop options may be
   separately configurable.  If a packet is received and the number of
   destination or hop-by-hop optines exceeds the limit, then the packet
   should be silently discarded.

   A host MAY impose a limit on the maximum length of destination
   options or hop-by-hop options extension header.  This value should be
   configurable and the default is to accept options of any length.  If
   a packet is received and the length of destination or hop-by-hop
   options extension header exceeds the length limit, then the packet
   should be silently discarded.

— snip —

For the full document, see
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-5.3

Tim