Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-02.txt

From: "C. M. Heard" <[email-masked]>
Date: Sun, 14 Jan 2018 12:47:40 -0800

After reading this draft (and its predecessor) and reviewing the
corresponding mailing list traffic, I support the work in principle, but
have the following comments on the details:

   1. Since an end system can have processing limit issues, all of the
   processing limit conditions discussed in the draft -- extension header too
   big, extension header chain too long, too many options in extension header,
   and headers too long -- should have codes that allow them to be reported
   via the Parameter Problem message (as in the -01 version of the draft). Use
   of the Destination Unreachable ICMPv6 message to report these things is
   inappropriate for end systems because, after all, the packet did reach its
   destination. It also seems appropriate for intermediate systems that detect
   any of these conditions in the course of acting upon a Hop-by-Hop Options
   Header to send a Parameter Problem message; after all, existing standards
   (RFC 8200 / RFC 4443) mandate this behavior for other problems (e.g.,
   unrecognized IPv6 option) encountered when acting upon a Hop-by-Hop Options
   Header.
   2. Per RFC 7045, if an intermediate system discards a packet containing
   a standard IPv6 extension header, it MUST be the result of a configurable
   policy and not just the result of a failure to recognize such a header, and
   the discard policy for each standard type of extension header MUST be
   individually configurable. Experimental extension headers SHOULD be treated
   in the same way, and intermediate systems that examine extension headers
   MUST have a configuration option that allows forwarding of packets
with unrecognized
   extension headers. To me, this says that it is not appropriate for such
   systems to send a Parameter Problem message with code 1 (unrecognized
   Next Header type encountered); it would be more appropriate to send a
   Destination Unreachable message with a new code signifying Next Header
   type administratively prohibited. A counterpart to RFC 7045 for IPv6
   options was never published, but it would be consistent to send a
   Destination Unreachable message with a new code signifying IPv6 option
   administratively prohibited for packets that are filtered because of
   unwanted options. Note that security issues that may arise in connection
   with such ICMPv6 messages are addressed by RFC 4443's
recommendation that implementations
   SHOULD allow sending of ICMP destination unreachable messages to be
   disabled.
   3. By analogy with the conclusions in the previous paragraph, it would
   be consistent for an intermediate system that encounters any of the
   processing limit conditions discussed in this draft (other than in the
   course of acting upon a Hop-by-Hop Options header) to send a Destination
   Unreachable message with a new code indicating the condition that it
   encountered. It is true (as the draft notes) that sending a Parameter
   Problem message with one of the new processing limit codes could work,
   since the source address in the ICMPv6 packet would allow an end system to
   determine that the message was not sent by the destination host, but to me
   at least this seems to be an undesirable complication for the end system.

Thanks & regards,

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Jan 2018 09:47:41 -0800

Hi Mike,

Thanks for the analysis. Some comments in line.

On Sun, Jan 14, 2018 at 12:47 PM, C. M. Heard <[email-masked]> wrote:
> Since an end system can have processing limit issues, all of the processing
> limit conditions discussed in the draft -- extension header too big,
> extension header chain too long, too many options in extension header, and
> headers too long -- should have codes that allow them to be reported via the
> Parameter Problem message (as in the -01 version of the draft). Use of the
> Destination Unreachable ICMPv6 message to report these things is

Note that an end host can send a destination unreachable for port
unreachable. In that case the packet did reach its network layer
destination, but not actually delivered to the end application.

> Per RFC 7045, if an intermediate system discards a packet containing a
> standard IPv6 extension header, it MUST be the result of a configurable
> MUST have a configuration option that allows forwarding of packets with
> unrecognized extension headers. To me, this says that it is not appropriate
> for such systems to send a Parameter Problem message with code 1
> (unrecognized Next Header type encountered); it would be more appropriate to
> send a Destination Unreachable message with a new code signifying Next
> Header type administratively prohibited. A counterpart to RFC 7045 for IPv6
> with such ICMPv6 messages are addressed by RFC 4443's recommendation that
> implementations SHOULD allow sending of ICMP destination unreachable
> messages to be disabled.

I think there is a subtlety here. An intermediate node might drop a
packet with an unknown next header because it's unable to parse past
the header, not necessarily because of an administrative decision that
it doesn't trust the unknown header. For instance, if a firewall is
filtering TCP packets then it would have to drop packets with an
unknown nexthdr lest they miss an encapsulated TCP packet allowing an
attacker to circumvent the firewall.

> By analogy with the conclusions in the previous paragraph, it would be
> consistent for an intermediate system that encounters any of the processing
> limit conditions discussed in this draft (other than in the course of acting
> upon a Hop-by-Hop Options header) to send a Destination Unreachable message
> with a new code indicating the condition that it encountered. It is true (as
> the draft notes) that sending a Parameter Problem message with one of the
> new processing limit codes could work, since the source address in the
> ICMPv6 packet would allow an end system to determine that the message was
> not sent by the destination host, but to me at least this seems to be an
> undesirable complication for the end system.
>
The text in RFC4443 describing Parameter Problem seems relevant:

"If an IPv6 node processing a packet finds a problem with a field in
the IPv6 header or extension headers such that it cannot complete
processing the packet, it MUST discard the packet and SHOULD originate
an ICMPv6 Parameter Problem message"

This doesn't distinguish between a host and intermediate node, neither
does it restrict the sending of Parameter Problem to only protocol
errors encountered. "cannot complete processing" seems apropos to a
node that is unable to process a packet because of a processing limit.

The text does limit parameter problem to only apply to IPv6 header and
EH, so using Destination Unreachable for the generic headers too big
seems better.

For the host receiving the ICMP error, I doubt there is much value is
in distinguishing whether its the destination host or an intermediate
host that is reporting the problem. In either case, the conclusion
that the host would make it that it's sending something that's causing
drops somewhere in the path to the destination. I suppose it's
possible that a host might someday be able to source route around the
problem if its at an intermediate node, but in the near future the
simplest fallback would be to not use the features causing drops.

Tom