Subject: Should we recommend ignoring ICMP PTB unless validated or not?

From: Igor Lubashev <[email-masked]>
Date: Wed, 12 Dec 2018 01:34:46 +0000 (UTC)

Currently, the Transport draft recommends (SHOULD) that all ICMP PTB messages to be dropped, if the implementation is not performing the validation for whatever reason.  Typical reasons include the lack of access to the necessary info on the platform, implementing a validation scheme for which 8 bytes of UDP header is insufficient, or the implementer just not feeling like implementing the validation.
We all certainly would love all QUIC implementation to include comprehensive validation checks (there are ways to work even with the first 8 bytes of UDP) and all platforms to allow access to what's needed to validate the PTB messages.  In reality we know that this is hard (and sometimes impossible), and many implementers are not well-informed and/or under time pressure.

I am worried that implementers who are not performing a validation (for any of the reasons above), will read this SHOULD, drop the packet, and not think too hard about it, because they are "just following the RFC recommendation".
Even though these ICMP messages could be spoofed, we already require ignoring ICMP messages that try to reduce PMTU to a value smaller than 1280. So the damage from spoofed ICMP messages is small, while ignoring them may cause problems from slow PMTU discovery to broken connections.

I think we should change that SHOULD to MAY (https://github.com/quicwg/base-drafts/pull/2109/files).
Thoughts?
- Igor

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 12 Dec 2018 09:19:50 +0000

On 12/12/2018, 01:34, Igor Lubashev wrote:
> Currently, the Transport draft recommends (SHOULD) that all ICMP PTB 
> messages to be dropped, if the implementation is not performing the 
> validation for whatever reason.
That, I think, is correct. The trust model for using ICMP has changed 
since ICMP was specified, and endpoints really need to not blindly 
follow messages that are received.

RFC 8201 states:

   "Nodes should appropriately validate the payload of ICMPv6 PTB
    messages to ensure these are received in response to transmitted
    traffic (i.e., a reported error condition that corresponds to an IPv6
    packet actually sent by the application) per [ICMPv6  <https://tools.ietf.org/html/rfc8201#ref-ICMPv6>]."

> Typical reasons include the lack of access to the necessary info on 
> the platform, implementing a validation scheme for which 8 bytes of 
> UDP header is insufficient, or the implementer just not feeling like 
> implementing the validation.
> We all certainly would love all QUIC implementation to include 
> comprehensive validation checks (there are ways to work even with the 
> first 8 bytes of UDP) and all platforms to allow access to what's 
> needed to validate the PTB messages.  In reality we know that this is 
> hard (and sometimes impossible),
Indeed, there are cases where an ICMP message can not even be associated 
with a socket. It's of course also only entirely possible that ICMP 
messages are not received at all. This mechanism is advisory.
> and many implementers are not well-informed and/or under time pressure.
I'm not keen on changing what is specified because of this sort of 
reason. That sounds to me lie trhe text needs more clarity.
>
> I am worried that implementers who are not performing a validation 
> (for any of the reasons above), will read this SHOULD, drop the 
> packet, and not think too hard about it, because they are "just 
> following the RFC recommendation".
>
I don't understand this comment. It's true one can implement more 
elaborate checks, and then packets can be dropped as a result of those 
checks - implementations can always do things. Howver, I maintainthe 
"SHOULD" is still appropriate here. The text defines validation in a way 
that does not exclusively depend upon having more than 8 bytes of 
payload to rely on.
> Even though these ICMP messages could be spoofed, we already require 
> ignoring ICMP messages that try to reduce PMTU to a value smaller than 
> 1280. So the damage from spoofed ICMP messages is small, while 
> ignoring them may cause problems from slow PMTU discovery to broken 
> connections.
>
I do not think this is true.
> I think we should change that SHOULD to MAY 
> (https://github..com/quicwg/base-drafts/pull/2109/files 
> <https://github.com/quicwg/base-drafts/pull/2109/files>).
>
> Thoughts?
>
I fail to see why the discussion in QUIC would propose a different path 
to RFC 8201. Section 3, requirement 4 currently describes the TSVWG work 
on DPLPMTUD.
> - Igor
Gorry

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 12 Dec 2018 18:11:31 +0000 (UTC)

Gory, yes, nodes SHOULD try to validate.  The question, however, is not what happens when the validation proves the packet invalid but what happens when nodes validation is not possible (due to platform or implementation limitations).
The cited RFC 8201 just says the above, as you quoted: "Nodes should appropriately validate the payload".  However, I could find nowhere where it states or implies that if nodes do not follow this "should" (because they do not / cannot validate), then the nodes should drop the PTB packet.  What it does say is that "After receiving a Packet Too Big message, [...] node must reduce the size of the packets it is sending along the path."  Finally, RFC 8201 is IPv6-specific.  It gives no guidance on IPv4 ICMP messages.

It is true that your DPLPMTUD draft cranks up the requirement for validating PTB messages (#3.4).  It makes validation a MUST (citing RFC 8201, where it is only a SHOULD), implying that is the validation cannot be performed, PTB MUST be dropped.  This can very well be so for implementation that implement DPLPMTUD. DPLPMTUD, however, is not a requirement for QUIC; yet the language in question applies to all QUIC implementations.

I am realizing that it is possible that the question is moot, since DPLPMTUD draft (#3.4) considers doing anything at all (like simply matching to an existing connection using IP addresses) is sufficient for validation (it says that doing more for validation is a SHOULD, implying that just matching IPs is still acceptable).  Doing anything less is impractical when processing PTB messages.  If so, I'd be happy with some text making it explicit that just matching on IPs and, maybe, UDP ports is sufficient to consider this validated.
- Igor

On Wednesday, December 12, 2018, 4:20:03 AM EST, Gorry Fairhurst <[email-masked]> wrote:

On 12/12/2018, 01:34, Igor Lubashev wrote:> Currently, the Transport draft recommends (SHOULD) that all ICMP PTB > messages to be dropped, if the implementation is not performing the > validation for whatever reason.That, I think, is correct. The trust model for using ICMP has changed since ICMP was specified, and endpoints really need to not blindly follow messages that are received.
RFC 8201 states:
  "Nodes should appropriately validate the payload of ICMPv6 PTB    messages to ensure these are received in response to transmitted    traffic (i.e., a reported error condition that corresponds to an IPv6    packet actually sent by the application) per [ICMPv6  <https://tools.ietf.org/html/rfc8201#ref-ICMPv6>]."

> Typical reasons include the lack of access to the necessary info on > the platform, implementing a validation scheme for which 8 bytes of > UDP header is insufficient, or the implementer just not feeling like > implementing the validation.> We all certainly would love all QUIC implementation to include > comprehensive validation checks (there are ways to work even with the > first 8 bytes of UDP) and all platforms to allow access to what's > needed to validate the PTB messages.  In reality we know that this is > hard (and sometimes impossible),Indeed, there are cases where an ICMP message can not even be associated with a socket. It's of course also only entirely possible that ICMP messages are not received at all. This mechanism is advisory.> and many implementers are not well-informed and/or under time pressure.I'm not keen on changing what is specified because of this sort of reason. That sounds to me lie trhe text needs more clarity.>> I am worried that implementers who are not performing a validation > (for any of the reasons above), will read this SHOULD, drop the > packet, and not think too hard about it, because they are "just > following the RFC recommendation".>I don't understand this comment. It's true one can implement more elaborate checks, and then packets can be dropped as a result of those checks - implementations can always do things. Howver, I maintainthe "SHOULD" is still appropriate here. The text defines validation in a way that does not exclusively depend upon having more than 8 bytes of payload to rely on.> Even though these ICMP messages could be spoofed, we already require > ignoring ICMP messages that try to reduce PMTU to a value smaller than > 1280. So the damage from spoofed ICMP messages is small, while > ignoring them may cause problems from slow PMTU discovery to broken > connections.>I do not think this is true.> I think we should change that SHOULD to MAY > (https://github..com/quicwg/base-drafts/pull/2109/files > <https://github.com/quicwg/base-drafts/pull/2109/files>).>> Thoughts?>I fail to see why the discussion in QUIC would propose a different path to RFC 8201. Section 3, requirement 4 currently describes the TSVWG work on DPLPMTUD.
> - Igor
Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 13 Dec 2018 09:29:36 +0000

On 12/12/2018, 18:11, Igor Lubashev wrote:
> Gory, yes, nodes SHOULD try to validate.  The question, however, is 
> not what happens when the validation proves the packet invalid but 
> what happens when nodes validation is not possible (due to platform or 
> implementation limitations).
>
Do you mean UDP-stack implementation or QUIC implementation?
> The cited RFC 8201 just says the above, as you quoted: "Nodes should 
> appropriately validate the payload".  However, I could find nowhere 
> where it states or implies that if nodes do not follow this "should" 
> (because they do not / cannot validate), then the nodes should drop 
> the PTB packet.  What it does say is that "After receiving a Packet 
> Too Big message, [...] node must reduce the size of the packets it is 
> sending along the path."  Finally, RFC 8201 is IPv6-specific.  It 
> gives no guidance on IPv4 ICMP messages.
I think it is clear that IPv6 nodes need to validate the payload or 
ignore the PTB signal. Section 5.1 of RFC 8085 is pretty clear that 
transports (IPv4 or IPv6) should protect from off path attacks - 
although it doesn't call out that signalling also needs to be valid.

I'm not seeing a clear use-case where the QUIC sender needs to send more 
than 1200 (or so) bytes and that it needs to be able to utilise ICMP 
messages to control the size. I suggest this is a bad design.

RFC 8085 guidance is to use a size that works, that could rely on 
network-layer PMTUD (and accept black-holing) or implement some form of 
PL PMTUD.

>
> It is true that your DPLPMTUD draft cranks up the requirement for 
> validating PTB messages (#3.4).  It makes validation a MUST
That is what the document currently says. If the transport or app does 
DPLPMTUD - then the PTB signal needs to be demuxed to the specific 
transport entity. Checking the ports correspond to the flow,  (providing 
one of the ports was a randomly-chosen ephmeral port) is at least some 
sort of check for on-path messages.
> (citing RFC 8201, where it is only a SHOULD),
Because that is at the network-layer.
> implying that is the validation cannot be performed, PTB MUST be dropped.
This can be made more explicit that the PTB signal MUST NOT be used by 
the DPLPMTUD method.
> This can very well be so for implementation that implement DPLPMTUD. 
> DPLPMTUD, however, is not a requirement for QUIC; yet the language in 
> question applies to all QUIC implementations.
>
RFC 8085 applies to all UDP applications, and that does include QUIC. If 
QUIC doesn't conform to RFC 8085 then I think it ought to explain why, 
but that applies to anything in QUIC.
>
> I am realizing that it is possible that the question is moot, since 
> DPLPMTUD draft (#3.4) considers doing anything at all (like simply 
> matching to an existing connection using IP addresses)
> is sufficient for validation (it says that doing more for validation 
> is a SHOULD, implying that just matching IPs is still acceptable).
No that's not the intention -

    The checks are
    intended to provide protection from packets that originate from a
    node that is not on the network path or a node that attempts to
    report a larger link MTU than the current probe size.

... we will clarify to explicitly say matching the address is not 
sufficient,
I think this needs to say that the "originate from the sending transport 
endpoint performing DPLPMTUD (i.e., at least needs to match the 
combination of the IP addresses, protocol, and the source and 
destination ports)".

I suggest there are ICMP messages that will be received that do not pass 
this test (by design these may not reach the application layer, but if 
they do, perhaps because the implementation provides a copy of every 
ICMP message, they really need to not be utilised). This is quite 
different to an app using UDP with PMTUD at the network layer, where 
implementations exist that do accept any PTB message that matches the IP 
address.

> Doing anything less is impractical when processing PTB messages.  If 
> so, I'd be happy with some text making it explicit that just matching 
> on IPs and, maybe, UDP ports is sufficient to consider this validated.
>
I argued above that matching only address is insufficient, but maybe the 
clarifications help answer your questions?

Gorry
>     packet actually sent by the application) per [ICMPv6 
> <https://tools.ietf.org/html/rfc8201#ref-ICMPv6>]."
>
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 13 Dec 2018 16:07:35 +0000

I think text that states explicitly that matching on IPs and UDP ports is sufficient (though doing more is recommended) would help resolve the ambiguity as to what constitutes "validation".

P.S.
  Note that we cannot expect an endpoint to know whether the other endpoint (or even its own OS or NAT) is picking UDP ports randomly or not.  As a practical matter, most OSen and NATs do not randomize ephemeral ports.

> -----Original Message-----
> From: Gorry Fairhurst <[email-masked]>
> Sent: Thursday, December 13, 2018 4:30 AM
> To: Igor Lubashev <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Should we recommend ignoring ICMP PTB unless validated or
> not?
> 
> I think it is clear that IPv6 nodes need to validate the payload or ignore the
> PTB signal. Section 5.1 of RFC 8085 is pretty clear that transports (IPv4 or IPv6)
> should protect from off path attacks - although it doesn't call out that
> signalling also needs to be valid.
> 
> than 1200 (or so) bytes and that it needs to be able to utilise ICMP messages
> to control the size. I suggest this is a bad design.
> 
> RFC 8085 guidance is to use a size that works, that could rely on network-
> layer PMTUD (and accept black-holing) or implement some form of PL
> PMTUD.
> 
> >
> .... we will clarify to explicitly say matching the address is not
> sufficient,

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 13 Dec 2018 21:45:11 +0000 (UTC)

I've updated the PR to clarify what ICMP PTB validation entails (and renamed it).  This text applies to all QUIC implementations.  Implementation that choose to implement DPLPMTUD will also have to follow additional DPLPMTUD's requirements. Gorry, could you take a look at the updated https://github.com/quicwg/base-drafts/pull/2109?

I've also opened an addition PR (https://github.com/quicwg/base-drafts/pull/2161) to ignore ICMP PTB that attempt to increase PMTU, unless this is in response to a PMTU probe (which was sent with a size larger than PMTU).
- Igor

    On Thursday, December 13, 2018, 11:10:57 AM EST, Lubashev, Igor <[email-masked]> wrote:  

P.S.