Subject: QUIC_ERROR_PMTU_TOO_SMALL?

From: Martin Duke <[email-masked]>
Date: Thu, 27 Jun 2019 09:26:32 -0700

Sec 14.1:

If a QUIC endpoint determines that the PMTU between any pair of local
   and remote IP addresses has fallen below the size needed to support
   the smallest allowed maximum packet size, it MUST immediately cease
   sending QUIC packets, except for PMTU probe packets, on the affected
   path.  An endpoint MAY terminate the connection if an alternative
   path cannot be found.

If we tear down a connection because we don't have a path that supports
1280 bytes, show should we communicate that to the peer? There should
probably be an error code for this.

If there are no objections, I'll file an issue.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 27 Jun 2019 16:50:50 +0000

I expect most implementations would not be able to (or care to) tell a difference between PMTU shrinking below 1280 and the path to the peer becoming a black hole entirely.  I.e. most likely ICMP reporting PMTU below the acceptable value would be dropped on a suspicion of forgery (man-on-a-side attack), while PMTU probes smaller than 1280 would never be sent (the connection cannot continue regardless of whether they succeed or fail).

Of course, an implementation could try to make a guess and send that CONNECTION_CLOSE on a chance it will get through, and it would need an error code.  But sending such error code should be entirely optional (like in MAY).

  *   Igor

From: Martin Duke <[email-masked]>
Sent: Thursday, June 27, 2019 12:27 PM
To: IETF QUIC WG <[email-masked]>
Subject: QUIC_ERROR_PMTU_TOO_SMALL?

Sec 14.1:

   path cannot be found.

If we tear down a connection because we don't have a path that supports 1280 bytes, show should we communicate that to the peer? There should probably be an error code for this.

---

From: Martin Duke <[email-masked]>
Date: Thu, 27 Jun 2019 12:49:37 -0700

The scenario I have in mind is that the handshake completes because the
PMTU is between 1228 and 1280, but when the endpoint figures this out it
has to send a CONN_CLOSE (which would definitely make it through)

On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor <[email-masked]> wrote:

> I expect most implementations would not be able to (or care to) tell a
> difference between PMTU shrinking below 1280 and the path to the peer
> becoming a black hole entirely.  I.e. most likely ICMP reporting PMTU below
> the acceptable value would be dropped on a suspicion of forgery
> (man-on-a-side attack), while PMTU probes smaller than 1280 would never be
> sent (the connection cannot continue regardless of whether they succeed or
> fail).
>
>
>
> Of course, an implementation could try to make a guess and send that
> CONNECTION_CLOSE on a chance it will get through, and it would need an
> error code.  But sending such error code should be entirely optional (like
> in MAY).
>
>
>
>    - Igor
>
>
>
> *From:* Martin Duke <[email-masked]>
> *Sent:* Thursday, June 27, 2019 12:27 PM
> *To:* IETF QUIC WG <[email-masked]>
> *Subject:* QUIC_ERROR_PMTU_TOO_SMALL?
>
>
>
> Sec 14.1:
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 27 Jun 2019 20:32:26 +0000

I understand.  I was suggesting that most endpoints will not “figure this out”, as they would not be able to tell “PMTU is too low” from “a blackhole developed on the path to the peer”.

From: Martin Duke <[email-masked]>
Sent: Thursday, June 27, 2019 3:50 PM
To: Lubashev, Igor <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL?

The scenario I have in mind is that the handshake completes because the PMTU is between 1228 and 1280, but when the endpoint figures this out it has to send a CONN_CLOSE (which would definitely make it through)

On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:
I expect most implementations would not be able to (or care to) tell a difference between PMTU shrinking below 1280 and the path to the peer becoming a black hole entirely.  I.e. most likely ICMP reporting PMTU below the acceptable value would be dropped on a suspicion of forgery (man-on-a-side attack), while PMTU probes smaller than 1280 would never be sent (the connection cannot continue regardless of whether they succeed or fail).

  *   Igor

From: Martin Duke <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 27, 2019 12:27 PM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: QUIC_ERROR_PMTU_TOO_SMALL?

Sec 14.1:

   path cannot be found.

---

From: Martin Duke <[email-masked]>
Date: Fri, 28 Jun 2019 14:45:10 -0700

I don't think it's that hard. If most packets below a certain size are
acked, and above are not, it's fairly straightforward. As it is, I MUST
tear down the connection. so I'm sending CONNECTION_CLOSE with
INTERNAL_ERROR, I guess.

On Thu, Jun 27, 2019 at 1:32 PM Lubashev, Igor <[email-masked]> wrote:

> I understand.  I was suggesting that most endpoints will not “figure this
> out”, as they would not be able to tell “PMTU is too low” from “a blackhole
> developed on the path to the peer”.
>
>
>
> *Sent:* Thursday, June 27, 2019 3:50 PM
> *To:* Lubashev, Igor <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>
> *Subject:* Re: QUIC_ERROR_PMTU_TOO_SMALL?
>
>
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 28 Jun 2019 22:05:29 +0000

Actually, you are not allowed to send your CONNECTION_CLOSE with any error code per very rule you quoted.  I.e. cannot send any QUIC packets, except for PMTU probes, on the affected path.

But what I was trying to point out is that “most packets below a certain size are acked, and above are not” is not a situation you will likely encounter, if PMTU suddenly drops before 1280.  Once your PMTU estimate drops below 1280, there will be no more ACKs for small packets, because no small packets will be sent (per the rule you quoted).  The only packets that can be sent are PMTU probes, and those will need to be at least 1280 in length to be useful (i.e. if any of them gets ACKed, the connection can resume).

Sent: Friday, June 28, 2019 5:45 PM

I don't think it's that hard. If most packets below a certain size are acked, and above are not, it's fairly straightforward. As it is, I MUST tear down the connection. so I'm sending CONNECTION_CLOSE with INTERNAL_ERROR, I guess.

On Thu, Jun 27, 2019 at 1:32 PM Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:
I understand.  I was suggesting that most endpoints will not “figure this out”, as they would not be able to tell “PMTU is too low” from “a blackhole developed on the path to the peer”.

From: Martin Duke <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 27, 2019 3:50 PM
To: Lubashev, Igor <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL?

  *   Igor

Sec 14.1:

   path cannot be found.

---

From: Martin Duke <[email-masked]>
Date: Fri, 28 Jun 2019 15:38:14 -0700

Oof. You're right. That's a bad rule, but I guess that's what it says right
now.

On Fri, Jun 28, 2019 at 3:05 PM Lubashev, Igor <[email-masked]> wrote:

> Actually, you are not allowed to send your CONNECTION_CLOSE with any error
> code per very rule you quoted.  I.e. cannot send any QUIC packets, except
> for PMTU probes, on the affected path.
>
>
>
>
>
> But what I was trying to point out is that “most packets below a certain
> size are acked, and above are not” is not a situation you will likely
> encounter, if PMTU suddenly drops before 1280.  Once your PMTU estimate
> drops below 1280, there will be no more ACKs for small packets, because no
> small packets will be sent (per the rule you quoted).  The only packets
> that can be sent are PMTU probes, and those will need to be at least 1280
> in length to be useful (i.e. if any of them gets ACKed, the connection can
> resume).
>
>
>
>
>
> *Sent:* Friday, June 28, 2019 5:45 PM