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

From: "C. M. Heard" <[email-masked]>
Date: Mon, 15 Jan 2018 14:14:49 -0800

On Mon, Jan 15, 2018 at 9:47 AM, Tom Herbert <[email-masked]> wrote:
> On Sun, Jan 14, 2018 at 12:47 PM, C. M. Heard <[email-masked]> wrote:
>> 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:
>>
>> 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.
>
> 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.

True, and in ICMPv4 we also had a code for protocol unreachable in the
Destination Unreachable message. In ICMPv6 this situation is dealt with by
Parameter Problem / unrecognized Next Header. So there is some mixing
up of these things in v6.

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

Yes, but if I read the intent of RFC 7045 correctly, that must still be the
result of a a configurable policy. If a firewall lacks the capacity to parse a
header chain as long as the MTU, then in order to comply with RFC 7045,
it must be possible to configure whether packets with long header chains
are dropped or passed. In other words, if the packet is dropped, it has to
be because of an administrative decision, not just because the firewall
lacked the capacity to figure out whether the packet was legitimate.

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

I find that reasoning unconvincing.

A header chain too long to process sure seems to me to be a problem
in processing the extension headers. True, it is not attributable to
any particular field in the header chain, but we dropped that rule in
RFC 7112, wherein Parameter Problem with Code 3 was mandated
for a header chain that does not fit in the first packet fragment.

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

That is probably true, and RFC 7112 there is explicitly no distinction
as to whether the sending node is an intermediate system or a host.
If the objective is to keep things simple, then it seems to me that the
most straightforward course would be to report all these conditions
with Parameter Problem, as was done in the -01 version of this draft.
However, it would probably be wise to add a proviso that intermediate
systems may (or should) have a switch that allows the sending of the
ICMP messages to be turned off.

Mike Heard

P.S. If you retain the Destination Unreachaable message for the
aggregate limit, then you need to modify the figure in Section 3.1 so
that the Length is in the place mandated by RFC 4884 Section 4.4.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Jan 2018 17:29:37 -0800

> lacked the capacity to figure out whether the packet was legitimate.
Mike,

The intent of RFC7045 is correct, however I have to wonder how this
would be implemented in practice. It seems like a firewall that
applies rules to the transport layer would pretty much have drop any
packets with an unknown nexthdr since it can't risk that the nexthdr
might be an extension header that receiving host does understand.
Maybe a firewall expert can comment on this?

> for a header chain that does not fit in the first packet fragment.
I agree, if there is a problem in processing an IP header or an EH
then parameter problem should be used. The destination unreachable
code is used in situations where the aggregate of protocol headers to
be parsed  is too big (not just IP and EH). The use case might be a
node that is attempting to parse some number of nested IP/IP
encapsulations. As I mentioned, the definition of parameter problem
does not allow it to be used problems not related to IP hdr or EH,
this is why we changed that codes to be destination unreachable.

> that the Length is in the place mandated by RFC 4884 Section 4.4.

Yes, thanks for pointing that out.

Tom

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 15 Jan 2018 19:20:21 -0800

> might be an extension header that receiving host does understand.

What RFC 7045 says is that a firewall MUST have an option that allows
packets with extension headers that it does not understand to be passed
through. The default MAY be to discard such stuff, but the option to do
otherwise MUST exist. It is understood that these requirements are at this
time somewhat aspirational.

> Maybe a firewall expert can comment on this?

Yes, that would be welcome.

> this is why we changed that codes to be destination unreachable.

Precedent: RFC 7112 specifies only that all EHs and the _first_ ULP
header need to reside within the initial fragment. In the case of IP-in-IP
the first ULP is the (first) inner IP header. A firewall should expect to be
able to parse to that point; if the precedent is correct, there is no valid
use case for going beyond. To me, failure to get to that point is definitely
a problem with the combined length of IP and EHs. Parameter Problem fits.

To avoid circling I'm going to stop arguing here, as we've both made our
positions and reasoning amply clear.

--cmh