Subject: Re: Validation of Packet Too Big Payload using Echo Request

From: Shawn Zhang <[email-masked]>
Date: Tue, 28 Jul 2020 04:43:55 -0700

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

---

From: Timothy Winters <[email-masked]>
Date: Tue, 28 Jul 2020 07:59:28 -0400

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 [email-masked].

~Tim

On Tue, Jul 28, 2020 at 7:48 AM Shawn Zhang <yuanshan_zhang=
[email-masked]> wrote:

> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jul 2020 21:02:38 +0900

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 <[email-masked]> wrote:

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

---

From: Prabhakar Lakhera <[email-masked]>
Date: Wed, 29 Jul 2020 11:16:00 -0700

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 <[email-masked]> 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?
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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 [email-masked] <mailto:[email-masked]>.
> 
> ~Tim
> 
> On Tue, Jul 28, 2020 at 7:48 AM Shawn Zhang <yuanshan_zhang=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ole,
> 
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Timothy Winters <[email-masked]>
Date: Wed, 29 Jul 2020 16:15:33 -0400

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 <[email-masked]>
wrote:

> 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!
>
>> *"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 [email-masked].
>>
>> ~Tim
>>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 29 Jul 2020 21:41:31 +0000

Don't associate the PMTU with a socket.
Associate it with the destination IP.
That is, of course, a DOS vector, so apply the appropriate caching strategies.

For example, if two sockets from different apps go to the same destination IP,
then a PTB from that IP should apply to both sockets.

Regards,
Jakob.

From: ipv6 <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: Wednesday, July 29, 2020 5:03 AM
To: Timothy Winters <[email-masked]>
Cc: 6MAN <[email-masked]>; Shawn Zhang <yuanshan_zhang=[email-masked]>; Timothy Winters <[email-masked]>; [email-masked]
Subject: Re: Validation of Packet Too Big Payload using Echo Request

On Tue, Jul 28, 2020, 21:00 Timothy Winters <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shawn,

If you have other questions about IPv6 Ready please feel free to take this to the [email-masked]<mailto:[email-masked]>.

~Tim

On Tue, Jul 28, 2020 at 7:48 AM Shawn Zhang <yuanshan_zhang=[email-masked]<mailto:[email-masked]>> wrote:
Hi Ole,

Bests,
Shawn

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Prabhakar Lakhera <[email-masked]>
Date: Wed, 29 Jul 2020 17:25:59 -0700

> On Jul 29, 2020, at 1:15 PM, Timothy Winters <[email-masked]> wrote:
> 
> 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. 
> 
> 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.

Unlike v4 though, the minimum MTU for v6 is somewhat of a larger value if 1280. There are recommendations on not processing any lower values.
The cost caused therefore is somewhat minimized.

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

I am not sure what that language would look like. It would end up getting into specifics for each use-case (ICMPv6 vs UDP vs TCP).
For example, QUIC is like TCP for most purpose but one may not get the complete payload in the errors to be able to validate these errors thereby would have to limit itself to UDP level checks.

It is one of those things that I think should be left to implementations to decide, whether they do it or not. And if they do it, decide on the on validation method of their choice.

> ~Tim
> 
> On Wed, Jul 29, 2020 at 2:16 PM Prabhakar Lakhera <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 29, 2020, at 5:02 AM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
>>