Re: RFC6434bis open issue - IPv6 EH protection

[Fernando Gont <[e-mail]>]

On 11/07/2017 08:59 AM, 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.

I support the idea/text (in general).


> 
> 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?

If the text focuses solely on the number of EHs, I guess it could be
included to this document. But I would be fine with the other option, too.


> 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.

"may place" or "MAY place"?



>    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.

While I'm not against this paragraph, this one is more tricky. If the
information in an option is early "optional", then you should be fine
ignoring the option. At the end of the they, the high order two bits of
the option type give guidance regarding what to do.



>    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.

This seems fine. I assume you're tackling "unknown options". Otherwise
you could say something along the lines of "at most one instance of each
of the specified options for this EH type".




>    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. 

s/options of any length/extension headers of any length/ might be clearrer.



>    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.
A meta question here is whether one should silently drop, or respond
with an ICMPv6 error. For the long EH chains in RFC7112, we do the later.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492