RE: Treatment of ICMP for PMTU

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

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) [[e-mail]]
Received: Thursday, 28 Jun 2018, 10:41AM
To: Mikkel Fahnøe Jørgensen [[e-mail]]
CC: Lucas Pardue [[e-mail]] IETF QUIC WG [[e-mail]] Martin Duke [[e-mail]] Lubashev, Igor [[e-mail]]
Subject: Re: Treatment of ICMP for PMTU



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

I think QUIC needs a tunnel extension frame.


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

Igor Lubashev wrote:

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

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


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