[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: New Version Notification for draft-herbert-6man-icmp-limits-02.txt
From:       "C. M. Heard" <heard () pobox ! com>
Date:       2018-01-16 3:20:21
Message-ID: CACL_3VHv301SBbZy=7m8P6xod6XRABgbZmN3opAoB7eDPXWswA () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jan 15, 2018 at 5:29 PM, Tom Herbert <tom@herbertland.com> wrote:
> 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.

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.

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

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]