Re: RFC6434bis open issue - IPv6 EH protection

[Brian E Carpenter <[e-mail]>]

On 08/11/2017 00:59, Tim Chown wrote:
> 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.

Right. And this text is getting close to BCP or even BIP (Best Implementation Practice).
But I think it's reasonable to include it.

    Brian

> — 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>