Re: Treatment of ICMP for PMTU

[joel jaeggli <[e-mail]>]

On 6/27/18 4:09 PM, Lubashev, Igor wrote:
>
> 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.
>
It's quite hard to insure that icmp emitted by on path devices to the
same anycast or load balanced destination. you're far better off with
the inband 4821 style signal.
>
>  
>
>   * 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").
>
>  
>
>  
>
>  2. 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
>
>  
>