RE: Treatment of ICMP for PMTU

[Lucas Pardue <[e-mail]>]

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