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

From: [email-masked]
Date: Thu, 02 May 2019 09:04:05 -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-01.txt
	Pages           : 11
	Date            : 2019-05-01

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-01
https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmp-limits-01

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

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: Nick Hilliard <[email-masked]>
Date: Thu, 2 May 2019 22:42:03 +0100

An aggregate header limit icmpv6 reply would emit interesting and 
probably private information about the hardware capabilities of the network.

The general case here is that it would be inadvisable to send icmp 
replies about exceeding limits unless those limits are what's defined in 
the RFCs.  Otherwise you're leaking information about your network, and 
you probably don't want to do that.

Nick

[email-masked] wrote on 02/05/2019 17:04:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 May 2019 15:12:55 -0700

> you probably don't want to do that.
Nick,

Like any other ICMP error they can be rate limited and policy can
otherwise be applied. In the case you mention I don't see how that's
particularly interesting as security threat. If a node is dropping
packets because of HW capabilities it can't pretend like that doesn't
affect communications. In lieu of getting the ICMP someone could do
probing to get the same information anyway.

Tom

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 2 May 2019 18:55:43 -0400

In reading this Draft it’s very similar to the ICMP Unreachable packet to Big type/code and gives a response back or the processing limit hit but to me does not seem like it reveals any private information about the network other very generic reply messages below:
ICMPv6 Fields: Type 4 (Parameter Problem type)        Code (pertinent to this specification) 1 - Unrecognized Next Header type encountered 4 - Extension header too big 5 - Extension header chain too long 6 - Too many options in extension header Pointer Identifies the octet offset within the invoking packet where the problem occurred. The pointer will point beyond the end of the ICMPv6 packet if the field having a problem is beyond what can fit in the maximum size of an ICMPv6 error message.

I support this RFC

Gyan

Sent from my iPhone

> On May 2, 2019, at 6:12 PM, Tom Herbert <[email-masked]> wrote:
>