Subject: Treatment of ICMP for PMTU

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 27 Jun 2018 20:36:29 +0000

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:[email-masked]> 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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 Jun 2018 21:26:34 +0000

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 [[email-masked]] on behalf of Lubashev, Igor [ilubashe=[email-masked]]
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.

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.

  *   Igor

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 27 Jun 2018 23:09:59 +0000

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:[email-masked]]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <[email-masked]>; Martin Duke <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Treatment of ICMP for PMTU

Hi Igor,

Lucas
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=>).

  *   Igor

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 28 Jun 2018 01:22:32 +0000

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 [[email-masked]]
Sent: 28 June 2018 00:09
To: Lucas Pardue; Martin Duke; IETF QUIC WG
Subject: RE: Treatment of ICMP for PMTU

Hi Lucas,

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

Hi Igor,

Lucas

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

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 28 Jun 2018 01:28:18 -0400

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 ([email-masked]) 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.

Kind regards
Lucas

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:[email-masked]]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <[email-masked]>; Martin Duke <
[email-masked]>; IETF QUIC WG <[email-masked]>
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 [[email-masked]] on behalf of Lubashev, Igor [ilubashe=
[email-masked]]
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:
[email-masked]> 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.

* Igor

may contain personal views which are not the views of the BBC unless
specifically stated.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 28 Jun 2018 06:11:20 +0000

I think I see what you are talking about.

At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forward data streams, not packets.  Hence, MTU concept on a tunnel-stream is meaningless.  The text says it explicitly: "Note that the size and number of TCP segments is not guaranteed to map predictably to the size and number of HTTP DATA or QUIC STREAM frames."  From the client's perspective there is only one PMTU that is relevant -- the one to the proxy.  The proxy will keep tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP segments accordingly.

Trying to design a CONNECT-like method to proxy an entire QUIC connection over a single QUIC stream would create HOLB for QUIC packets to and from the proxy.  Some sort of a partially reliable QUIC stream could help here.

This proxying scheme would require an extension to CONNECT to open a UDP/IP tunnel instead of a TCP/IP tunnel.  That extension would also mandate that HTTP/QUIC DATA frame corresponds to a UDP frame.  I suspect that it would be a very good idea for such a proxy to add a new frame for providing ICMP-like explicit PMTU feedback to the sender (why leave the sender guessing and probing, if the PMTU is already known to the proxy?).

- Igor

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2018 9:23 PM
To: Lubashev, Igor <[email-masked]>; Martin Duke <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Treatment of ICMP for PMTU

Hi Igor,

Kind regards
Lucas

Hi Lucas,

  *   Igor

Hi Igor,

Lucas

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

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 28 Jun 2018 07:03:16 +0000

Hi,

On 2018-6-27, at 22:36, Lubashev, Igor <ilubashe=[email-masked]> wrote:
> 	• Is processing ICMP signals (and, especially, ICMP Packet Too Big signal) a MAY or a SHOULD?
> 

4821 is an extension of 1191/1981 in the sense that it provides similar functionality in an Internet where ICMP delivery is unreliable - i.e., the only Internet we have. Because 4821 works without any ICMP delivery (its convergence is improved by it, but that is an optimization), the two need not be at the same requirements level.

As an individual, I'd argue that 4821 must be a SHOULD (and actually should be a MUST, except that we probably want to allow for inefficient stacks that send fixed-sized small packets).

Given the current state of ICMP blockage, I don't really care what we say about 1191/1981. A MAY is fine; a SHOULD seems overkill given the unreliability of ICMP, but I could live with it.

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

Isn't this sufficiently covered in 4821?

Lars

PS: Chair hat off.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 28 Jun 2018 09:10:06 +0000

Hi Mikkel,

Thanks for highlighting that issue, I’d lost sight of it.

I’ll respond to the HOL blocking on Igor’s thread.

Lucas

From: Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
Sent: 28 June 2018 06:28
To: Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Duke <[email-masked]>; Lubashev, Igor <[email-masked]>
Subject: RE: Treatment of ICMP for PMTU

Wrt tunnelling, see also

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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 28 Jun 2018 09:25:17 +0000

Igor Lubashev wrote:

>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forward
>data streams, not packets.  Hence, MTU concept on a tunnel-stream is
>meaningless.  The text says it explicitly: "Note that the size and number of TCP
>segments is not guaranteed to map predictably to the size and number of
>HTTP DATA or QUIC STREAM frames."  From the client's perspective there is
>only one PMTU that is relevant -- the one to the proxy.  The proxy will keep
>tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP
>segments accordingly.

Right, that's how I was seeing it.

>Trying to design a CONNECT-like method to proxy an entire QUIC connection
>over a single QUIC stream would create HOLB for QUIC packets to and from
>the proxy.  Some sort of a partially reliable QUIC stream could help here.

Both you and Mikkel have identified HOL as something that needs more thought. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL is enough to make QUIC not QUIC". I've taken the view that it may be desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL avoidance as an optimisation rather than a requirement. Partial reliability (of streams, or of some new frame type) could help solve that puzzle. Now I think about it, a complimentary mitigation could be to reserve a set of tunnel-streams to provide some basic multiplexing. However, the complexity of that might not be worth it.

>This proxying scheme would require an extension to CONNECT to open a
>UDP/IP tunnel instead of a TCP/IP tunnel.  That extension would also mandate
>that HTTP/QUIC DATA frame corresponds to a UDP frame.  I suspect that it
>would be a very good idea for such a proxy to add a new frame for providing
>ICMP-like explicit PMTU feedback to the sender (why leave the sender
>guessing and probing, if the PMTU is already known to the proxy?).

This is good feedback. Thanks!

Kind regards
Lucas

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 28 Jun 2018 06:07:29 -0400

I think QUIC needs a tunnel extension frame.

On 28 June 2018 at 11.25.20, Lucas Pardue ([email-masked]) wrote:

>the proxy. Some sort of a partially reliable QUIC stream could help here.

Both you and Mikkel have identified HOL as something that needs more
thought. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL
is enough to make QUIC not QUIC". I've taken the view that it may be
desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so
I view HOL avoidance as an optimisation rather than a requirement. Partial
reliability (of streams, or of some new frame type) could help solve that
puzzle. Now I think about it, a complimentary mitigation could be to
reserve a set of tunnel-streams to provide some basic multiplexing.
However, the complexity of that might not be worth it.

Kind regards
Lucas

---

From: "Gorry (erg)" <[email-masked]>
Date: Thu, 28 Jun 2018 16:40:27 +0200

> On 28 Jun 2018, at 12:07, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 

And when you say:
“
for ICMP w/ on-path proof, I think it makes sense to allow a reduction in PMTU up to 1280.”  
- I agree the values could be trusted.
- what then also happens when PTB message indicated less than 1280, does the sender close the connection? Or ignore the message and wait to see if there is a timeout?

Gorry

---

From: joel jaeggli <[email-masked]>
Date: Thu, 28 Jun 2018 09:51:03 -0700

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:[email-masked]]
> *Sent:* Wednesday, June 27, 2018 5:27 PM
> *To:* Lubashev, Igor <[email-masked]>; Martin Duke
> <[email-masked]>; IETF QUIC WG <[email-masked]>
> *Subject:* RE: Treatment of ICMP for PMTU
>
>  
>
> Hi Igor,
>
>  
>
> 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 [[email-masked]] on behalf of Lubashev, Igor
> [ilubashe=[email-masked]]
> *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=>).
>
> There are two technical issues that @Martin Duke
> <mailto:[email-masked]> and I believe deserve a broader
> discussion with the group.
>
>  
>
> 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
> 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?
>
>  
>
> 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.
>
>  
>
>  
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 28 Jun 2018 18:31:31 +0000

In the PR, I say to ignore the signal, if it comes after the handshake. I do not want an effective way for a man-on-a-side to DoS connections in progress.

When this happens during handshake, there is a much more nuanced decision. Basically, sever ignores such signals. However, client abandons this server or QUIC entirely, if it has an alternative server IP to try or protocol to fall over to. This is because a man-on-a-side attacker interested in disputing QUIC handshake could already do it via spoofed version negotiation packets.

- Igor

-----Original Message-----
From: Gorry (erg) [[email-masked]]
Received: Thursday, 28 Jun 2018, 10:41AM
To: Mikkel Fahnøe Jørgensen [[email-masked]]
CC: Lucas Pardue [[email-masked]]; IETF QUIC WG [[email-masked]]; Martin Duke [[email-masked]]; Lubashev, Igor [[email-masked]]
Subject: Re: Treatment of ICMP for PMTU

On 28 Jun 2018, at 12:07, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:

On 28 June 2018 at 11.25.20, Lucas Pardue ([email-masked]<mailto:[email-masked]>) wrote:

Kind regards
Lucas

And when you say:
"
for ICMP w/ on-path proof, I think it makes sense to allow a reduction in PMTU up to 1280."
- I agree the values could be trusted.
- what then also happens when PTB message indicated less than 1280, does the sender close the connection? Or ignore the message and wait to see if there is a timeout?

Gorry

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 28 Jun 2018 18:49:58 +0000

> 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 [[email-masked]]
Received: Thursday, 28 Jun 2018, 12:51PM
To: Lubashev, Igor [[email-masked]]; Lucas Pardue [[email-masked]]; Martin Duke [[email-masked]]; IETF QUIC WG [[email-masked]]
Subject: Re: Treatment of ICMP for PMTU

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:[email-masked]]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <[email-masked]><mailto:[email-masked]>; Martin Duke <[email-masked]><mailto:[email-masked]>; IETF QUIC WG <[email-masked]><mailto:[email-masked]>
Subject: RE: Treatment of ICMP for PMTU

Hi Igor,

Lucas
From: QUIC [[email-masked]<mailto:[email-masked]>] on behalf of Lubashev, Igor [ilubashe=[email-masked]<mailto:ilubashe=[email-masked]>]

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?

  *   Igor

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 29 Jun 2018 00:30:57 +0000

Thanks, Lars!

RFC4821 claims that "It is most efficient when used in conjunction with the ICMP-based Path MTU Discovery mechanism as specified in RFC 1191 and RFC 1981, [..]".  Since we very highly recommend implementing 4821, we should also recommend implementing 4821 efficiently.  (RFC4821 then continues to say that it resolves a problem of ICMP blockage, since it does not require ICMP for working.)

> Isn't this sufficiently covered in 4821?

Not really.  Or, at least I could not find anything more useful there then: "If an ICMP PTB message is received matching the probe packet, then search_high and eff_pmtu MAY be set from the MTU value indicated in the message."  So 4821 seems silent on what to do if ICMP is received for a non-probe packet, and it seems silent on how one could decide whether to set search_high and eff_pmtu from the MTU in ICMP or not (saying "MAY" does not really help here).  These questions are what I am trying to address for QUIC.

4821 uses MAY in the sentence above, since it does not really give any better indication.  This PR draws a distinction between ICMP w/ and w/o on-path proof and in some specific cases, it recommends a SHOULD.

- Igor

-----Original Message-----
From: Eggert, Lars [mailto:[email-masked]] 
Sent: Thursday, June 28, 2018 3:03 AM
To: Lubashev, Igor <[email-masked]>
Cc: Martin Duke <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Treatment of ICMP for PMTU

Hi,

Lars

PS: Chair hat off.