RE: Treatment of ICMP for PMTU

["Lubashev, Igor" <[e-mail]>]

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

You are 100% right about cases when CID is used for routing, such as load balancing. (I do want to point out that 4821 and ICMP are not alternatives. They are complimentary.)

Once we land this "how to use ICMP signals", I will do a PR on "how to implement 4821 to elicit useful ICMP for cases that require server CID for routing".

- Igor

-----Original Message-----
From: joel jaeggli [[e-mail]]
Received: Thursday, 28 Jun 2018, 12:51PM
To: Lubashev, Igor [[e-mail]] Lucas Pardue [[e-mail]] Martin Duke [[e-mail]] IETF QUIC WG [[e-mail]]
Subject: Re: Treatment of ICMP for PMTU



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]><mailto:[e-mail]>; Martin Duke <[e-mail]><mailto:[e-mail]>; IETF QUIC WG <[e-mail]><mailto:[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]<mailto:[e-mail]>] on behalf of Lubashev, Igor [ilubashe=[e-mail]<mailto: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