Subject: [Last-Call] Tsvart last call review of draft-ietf-6man-icmp-limits-07

From: Bernard Aboba via Datatracker <[email-masked]>
Date: Tue, 18 Feb 2020 13:02:21 -0800

Reviewer: Bernard Aboba
Review result: Ready with Issues

TSV-ART Review of draft-ietf-6man-icmp-limits
Bernard Aboba

Result: Ready with Issues

This document specifies several new ICMPv6 errors that can be sent
when a node discards a packet due to it being unable to process the
necessary protocol headers because of processing constraints or
limits.  Reasons include:

      Code (pertinent to this specification)
         1 - Unrecognized Next Header type encountered
         TBA - Extension header too big
         TBA - Extension header chain too long
         TBA - Too many options in extension header
         TBA - Option too big

ICMP Reliability

Section 5.2 states: 

"  ICMP is fundamentally an unreliable protocol and in real deployment
   it may consistently fail over some paths. As with any other use of
   ICMP, it is assumed that the errors defined in this document are only
   best effort to be delivered. No protocol should be implemented that
   relies on reliable delivery of ICMP messages. If necessary,
   alternative or additional mechanisms may used to augment the
   processes used to to deduce the reason that packets are being
   discarded. Such alternative mechanisms are out of scope of this
   specification."

[BA] The last sentence is a bit vague. My assumption is that this is
referring to techniques such as are used in Path MTU discovery (e.g.
tweaking of packets so as to determine potential reasons why packets
are being discarded).  However, a reference might be helpful.

Security Concerns

Pointer field

In Section 3.1, the description of the Pointer field states: 

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

[BA] I worry about attackers using the Pointer field for
mischief, such as buffer overflows.  The draft currently
does not provide advice to implementers about validating
the Pointer field (e.g. checking it against the length of
the offending packet). Do we really need a 32-bit Pointer field? 

Use by attackers

Section 4.2 states: 

"  A host MAY modify its usage of protocol headers in subsequent packets
   to avoid repeated occurrences of the same error."

[BA] While this response is optional, I do worry about the potential for
spoofed ICMP packets to modify the host's security posture. Are there any
types of usage modifications that a host should be particularly wary
of?

Section 6 states: 

"  In some circumstances, the sending of ICMP errors might conceptually
   be exploited for denial of service attack or as a means to covertly
   deduce processing capabilities of nodes. As such, an implementation
   SHOULD allow configurable policy to withhold sending of the ICMP
   errors described in this specification in environments where security
   of ICMP errors is a concern."

[BA] This concern seems quite realistic to me, and as a result, it would
not surprise me if implementations either do not send these ICMP errors,
or withhold them by default. Do you have a position on that?

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 Feb 2020 11:34:03 -0800

> the offending packet). Do we really need a 32-bit Pointer field? 

Very reminiscent of heartbleed, even with the note that "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."

-Ben

> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Feb 2020 23:01:53 -0500

Hi Bernard/Ben,
  Thanks for your review. Just responding to one point below.

> On Feb 25, 2020, at 2:34 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Hmm. This is exactly how base ICMPv6 (RFC4443 and prior to that RFC2463 and RFC1885) defines and uses the Pointer field. And the intent is specifically to be able to point past the end of the packet since the “offending” packet may not be able to fit into the reporting packet. Is there something specific that you think is being enabled by this draft and needs to be addressed?

Regards
Suresh

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Feb 2020 20:27:03 -0800

Pointer is probably an unfortunate term. Would have been better if this was
originally described as an offset. In any case, the text is clear, the
offset of the byte in error (pointer) can be beyond the extent of the
packet, and the implementation needs to correctly deal with that.

Tom

On Tue, Feb 25, 2020, 8:02 PM Suresh Krishnan <[email-masked]>
wrote:

> Hmm. This is exactly how base ICMPv6 (RFC4443 and prior to that RFC2463
> and RFC1885) defines and uses the Pointer field. And the intent is
> specifically to be able to point past the end of the packet since the
> “offending” packet may not be able to fit into the reporting packet. Is
> there something specific that you think is being enabled by this draft and
> needs to be addressed?
>
> Regards
> Suresh
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Feb 2020 22:33:45 -0800

Hi Suresh,

> Hmm. This is exactly how base ICMPv6 (RFC4443 and prior to that RFC2463 and RFC1885) defines and uses the Pointer field. And the intent is specifically to be able to point past the end of the packe…

I don't want to steal Bernard's thunder, but I'd consider a note along the
lines of "in such cases the pointer cannot be dereferenced without the
original packet" (noting that the statement in quotation marks is not,
strictly speaking, true, so further edits would be needed).

-Ben