Subject: I-D Action: draft-ietf-6man-icmp-limits-02.txt

From: [email-masked]
Date: Thu, 23 May 2019 13:40:56 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : ICMPv6 errors for discarding packets due to processing limits
        Author          : Tom Herbert
	Filename        : draft-ietf-6man-icmp-limits-02.txt
	Pages           : 12
	Date            : 2019-05-23

Abstract:
   Network nodes may discard packets if they are unable to process
   protocol headers of packets due to processing constraints or limits.
   When such packets are dropped, the sender receives no indication so
   it cannot take action to address the cause of discarded packets. This
   document defines ICMPv6 errors that can be sent by a node that
   discards packets because it is unable to process the protocol
   headers. A node that receives such an ICMPv6 error may be able to
   modify what it sends in future packets to avoid subsequent packet
   discards.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-02
https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmp-limits-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-icmp-limits-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Herbert <[email-masked]>
Date: Fri, 24 May 2019 10:57:06 -0700

Hello,

This is an update to ICMPv6 errors for processing limits. The material
change is to add an "Option too big" Parameter Problem code. This is
used used if a HBH or DO option length exceeds a limit, or the length
consecutive padding in HBH or DO options list exceeds a limit. The
recommended priority for reporting errors was also update accordingly.

Thanks,
Tom

On Thu, May 23, 2019 at 1:42 PM <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 27 May 2019 20:58:51 +0100

Tom,

Overall this looks useful.

Minor nits:

>  options in Type-length-value (TLV) format. Each option includes a
>  length of the data field in octets, and the minimum size of an option
>  (non-pad type) is two bytes and the maximum length is 257 bytes.

rephrase as:

>  options in Type-length-value (TLV) format. Each option includes a
>  length of the data field in octets:  the minimum size of an option
>  (non-pad type) is two octets and the maximum length is 257 octets.

s/extensions headers/extension headers/

s/attack of extension headers-- many/attack of extension headers, many/

s/may be applied on the number/may be applied to the number/

s/hosts may institute limits on/hosts may implement limits for/

s/of a fixed sized/of a fixed size/

s/for Parameter Problem type/for Parameter Problem types/

s/chain exceeds it processing/chain exceeds its processing/

Can I suggest the following for the security consideration section?

--
5  Security Considerations

    The security considerations for ICMPv6 described in [RFC4443] apply
    to this document.

    A malicious actor could use crafted packets to trigger ICMPv6 error
    replies described in this document, thereby allowing them to
    discover configuration or hardware characteristics of an
    intermediate node.  If the intermediate node processes packets which
    trigger extension header limit ICMPv6 error replies by processing
    them in a slow path, then an attacker may be able to selectively
    flood the slow-path packet processor or the specific slow-path
    processing ingress queue, thereby affecting the packet processor's
    ability to handle legitimate ICMPv6 error replies.

--

Nick

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 May 2019 13:28:04 -0700

> Can I suggest the following for the security consideration section?
Hi Nick,

Thanks for the comments. For your proposed security considerations
text, is the problem of exposing hardware configuration specific to
only these type of ICMP errors? Do we need to provide so much detail
about the possible attack? Also I suspect that ICMP error processing
is in slow path processing anyway and there are other ways to generate
an ICMP flood, the bigger issue might be in divulging details about
hardware capabilities of intermediate nodes to third parties in the
ICMP error.

How about text like this:

"In some circumstances, the sending of ICMP errors could be exploited
for denial of service attack or as a means to covertly deduce
processing capabilities of nodes as a precursor to denial of service
attack. As such, an implementation MAY allow configurable policy to
rate limit or withhold sending of ICMP in environments where security
of ICMP errors is an issue."

Thanks,
Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 May 2019 08:28:01 +1000

On Tue, 28 May 2019 at 06:29, Tom Herbert <[email-masked]> wrote:
> rate limit

ICMPv6 is already to be rate limited, per RFC 4443, 2.4, f.

> or withhold sending of ICMP in environments where security

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 May 2019 21:33:11 +0100

Tom Herbert wrote on 27/05/2019 21:28:
> about the possible attack?

Not really, but I don't think it makes much difference whether the 
attack path is outlined or not.  That said, in future years, there may 
be other unforeseen consequences, so

> Also I suspect that ICMP error processing

yep, for sure.

> of ICMP errors is an issue."

As Mark pointed out, RFC4443 already specifies rate limiting, so this 
should not be duplicated here.  Also, given the security implications, a 
MUST would be a better idea for the config knob to disable sending icmp 
replies with these code, so what about the following modification of 
what you wrote?

> The mechanism described in this document for generating and sending
> ICMPv6 errors could be exploited to execute denial of service attacks
> or as a means to covertly deduce the processing capabilities of an 
> intermediate node.  As such, an implementation MUST provide a 
> configuration knob to control whether the node sends ICMPv6 errors 
> for the codes defined in this document.
Nick

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 14:08:41 -0700

> > for the codes defined in this document.

Nick,

I still prefer MAY for this. It's not clear to me that these ICMP
errors would be divulging information that couldn't be ascertained
though other means such as probing the network with various numbers
and sizes of EH to see what the limits are. RFC4890 also describes the
general problem of filtering ICMPv6 at firewalls which should be
applicable here.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 May 2019 23:07:49 +0100

Tom Herbert wrote on 28/05/2019 22:08:
> I still prefer MAY for this.

settle on SHOULD?

Nick

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 15:41:37 -0700

Nick,

That would imply the concern is generally ubiquitous, I think it's actually
quite narrow. For instance, if a host sends these errors it's likely that's
because a configurable limit for DOS mitigation has been exceeded like
those of RFC8504, not because of HW capabilities.  In this case, I don't
care if this information is divulged to a would be attacker, at best it's
just telling them that a DOS attack in this area is a waste of their time.

Tom