Subject: RFC6434bis open issue - IPv6 EH protection

From: Tim Chown <[email-masked]>
Date: Tue, 7 Nov 2017 11:59:12 +0000

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Nov 2017 09:24:50 -0300

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

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

>    options it is willing to process.

"may place" or "MAY place"?

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

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

>    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 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Nov 2017 08:20:48 +1300

> 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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>