RE: Treatment of ICMP for PMTU

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Wrt tunnelling, see also

https://github.com/quicwg/base-drafts/issues/1209

which was unceremoniously shut down on the argument that a path below 1280
is not a QUIC path.

I see a concrete use case for smaller PMTU’s: a high performance
coordination node forwards packets to peer nodes for consensus. The
consensus requires adding a signature on forwarding, but repackaging the
packet is too slow and might go against the proof being made. Here PNE is
also annoying.

On tunneling QUIC in QUIC in QUIC streams: that would add HOL, enough to
not make it QUIC.

Mikkel

On 28 June 2018 at 03.22.54, Lucas Pardue ([e-mail]) wrote:

Hi Igor,

The difference as I see it is, if we were to follow a model similar to how
CONNECT is defined in the HTTP/QUIC mapping, then QUIC tunnels are assigned
to different streams (tunnel-streams) within a single connection. Remaining
streams are used for client-proxy communications (control streams,
request/response etc)

On such a tunnel-stream, if we follow the CONNECT model of encapsulation,
the client sends/receives only QUIC packets. It is the proxy's job to
read/write IP.

This leads me to thinking that a proxy cannot return ICMP on the
tunnel-stream, and any ICMP cannot be disambiguated.

Or, perhaps I'm missing something here?

Kind regards
Lucas
________________________________________
From: Lubashev, Igor [[e-mail]]
Sent: 28 June 2018 00:09
To: Lucas Pardue; Martin Duke; IETF QUIC WG
Subject: RE: Treatment of ICMP for PMTU

Hi Lucas,

How is this different from PMTUD in IP-in-IP case? The endpoint computes
and caches PMTU per endpoint. PMTU for connections to proxy is kept
separately from PMTUs for connections to endpoints that go via the proxy.

The proxy itself can learn PMTU between itself and the endpoints, subtract
the overhead, and send ICMP to the sender of the proxied QUIC flow.

I see the common case of QUIC implementation not being able to make use of
ICMP is when QUIC is implemented in userspace on a platform that does not
expose ICMP to the application. QUIC’s desire to receive ICMP will likely
cause vendors of such platforms to add the missing functionality.


* Igor


From: Lucas Pardue [mailto:[e-mail]]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <[e-mail]>; Martin Duke <
[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: RE: Treatment of ICMP for PMTU

Hi Igor,

If we consider tunnelling of QUIC within QUIC by means of a proxy (not
currently specced anywhere but feasible), the tunnelled (end-to-end) path
MTU is likely to be smaller than the hop-by-hop path MTUs. It may not be
possible for the proxies to pass on ICMP in a way that the the tunnelled
QUIC implementation can access it. (D)PLPMTUD seems to fit this case nicely
as there can be two or more PLPMTUD contexts/values (one for the connection
to the proxy, one for each tunnel within this connection).

Lucas
________________________________
From: QUIC [[e-mail]] on behalf of Lubashev, Igor [ilubashe=
[e-mail]]
Sent: 27 June 2018 21:36
To: Martin Duke; IETF QUIC WG
Subject: Treatment of ICMP for PMTU
I have a PR for treatment of ICMP for PMTU (
https://github.com/quicwg/base-drafts/pull/1412<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_pull_1412&d=DwMFIw&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=Z8Jztem09Whn8ur3u4CIXydQ2bFcxT7J8RP_5EIqqN0&s=GfFHhZ-IsLfWzrc3Dd83k__I6Golxxd3W2LduTHYc_I&e=>)

Many thanks to those who gave me ample feedback (both substantive and
editorial). I’ve tried to incorporate it all.

There are two technical issues that @Martin Duke<mailto:
[e-mail]> and I believe deserve a broader discussion with
the group.


1. Is processing ICMP signals (and, especially, ICMP Packet Too Big signal)
a MAY or a SHOULD?

In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD
(RFC4821) is a SHOULD.
However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD
process. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP
itself is a SHOULD.
QUIC implementations w/o access to ICMP would not be able to implement the
ICMP part, and this is ok albeit unfortunate; and this also points to
SHOULD (skipping on MAY is not "unfortunate").



1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU
reduction (after handshake)?

There are three main options: ignore it, reduce your PMTU estimate, do not
reduce but send PLPMTUD probes. Since this is very likely a valid signal, I
do not like to ignore in the common case.

Hence, the proposal is to allow an immediate PMTU reduction to up to some
M, where 1280 ≤ M ≤ 1500. Once the reduction takes place, the endpoint can
use PLPMTUD recommendations to see if it can probe a larger PMTU. If this
sounds reasonable, then the question is picking M. I picked 1392 rather
arbitrarily (GRE over IPsec + a few MPLS labels). If the requested
reduction is 1280 ≤ X < M, then the recommendation is not to reduce but
send PLPMTUD probes. Does this make sense, or should we have M=1280 and
simplify things?

Note: for ICMP w/ on-path proof, I think it makes sense to allow a
reduction in PMTU up to 1280. It is hard to forge these, and the benefit of
the effort for the attacker is minimal (slightly lower efficiency of the
transport). So it is less likely that we’ll see forged ICMP w/ on-path
proof.


Any feedback is very welcome.


* Igor



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless
specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------