Re: Validation of Packet Too Big Payload using Echo Request

I think we are discussing two different things here. One is about IPv6
Ready Logo SHOULD position and another about the RFC clause in question.

As a reminder SHOULD is defined in RFC 2119 as:

"This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course "

IPv6 Ready Logo has been required SHOULD/MUST based on this definition for
the last 15 years.  The reason for this is we want devices to support these
interoperable standards, if they have a good reason for not implementing
it, they can state it.  We've had several companies with security reasons
not implement a SHOULD.  Also we allow for Advanced features, for things
such a ping since not all devices have a method for initiating a ping.

For this clause in particular, it's also a security risk to accept all
Packet Too Big messages without checking if the offending packet was
valid.   Currently the line applies to all traffic, maybe we can all work
on a draft to update this language to not apply to traffic but something
more realistic?

~Tim

On Wed, Jul 29, 2020 at 2:16 PM Prabhakar Lakhera <plakhera@apple.com>
wrote:

> Specially, given the proposed test expects node to be stateful with ICMPv6
> Echo Replies.
> That just opens up another window of exploit.
>
> It is also not great that one can only provide “best effort” checks. That
> is do one thing for ICMPv6, check for tuple for UDP, additionally check for
>  sequence numbers for TCP.
>
> Given the MTU has lower bound of 1280, the requirement should *not* be
> part of IPv6 ready logo as a must. The spec says it is a should, and that’s
> how it needs to be read.
>
> Thanks!
>
> On Jul 29, 2020, at 5:02 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> I'm not sure that the desired behaviour is reasonably implementable.
> Wouldn't it require the sending node to keep state on all packets it had
> ever sent? For how long?
>
> The implementation can relatively easily check if a PTB matches an
> *existing* socket. But what if the following happens?
>
> 1. App opens UDP socket, sends packet.
> 2. App closes socket.
> 3. PTB arrives for packet in step #1.
> 4. App opens socket on same port again, sends identical packet again.
>
> If the stack rejects the packet in #3, arguably it makes things worse. But
> accepting it is difficult without keeping state on sockets after they are
> closed, which is both ill-defined (how long do you need to keep the state?)
> and potentially expensive / exposing a DoS vector.
>
> On Tue, Jul 28, 2020, 21:00 Timothy Winters <tim@qacafe.com> wrote:
>
>> Hi Shawn,
>>
>> If you are referring to the IPv6 Ready Logo Core Test Specification for
>> this, we have a possible problem for this validation test case for devices
>> that don't track ICMPv6 connections.
>>
>> *"Possible Problems: * If the device under test does not support
>> tracking connections for ICMPv6 this test case may be omitted."
>>
>> If you have other questions about IPv6 Ready please feel free to take
>> this to the info@ipv6ready.org.
>>
>> ~Tim
>>
>> On Tue, Jul 28, 2020 at 7:48 AM Shawn Zhang <yuanshan_zhang=
>> 40apple.com@dmarc.ietf.org> wrote:
>>
>>> Hi Ole,
>>>
>>> I am reviving this thread.
>>>
>>> >> Frankly, I think for compliance this should be treated as a *SHOULD*
>>> and not as a MUST.
>>>
>>> > Yes, I think that's a correct interpretation.
>>> > That's what 8201 says too. "Nodes should appropriately validate..."
>>>
>>> Since RFC8201 says “SHOULD” instead of “MUST”, should this test be
>>> removed from the compliance test as it is not a mandatory behavior?
>>>
>>> IMHO, since the smallest packet size is capped at 1280, it won't cause
>>> too much risk  even if we don't verify it using Echo Request here.
>>>
>>> Bests,
>>> Shawn
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>