Subject: Using Long Header packets for PMTUD probes

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

We talked briefly in Kista about the possibility of using Long Header packets for PMTUD probes.  See Issue 1243 (https://github.com/quicwg/base-drafts/issues/1243) for context.  Briefly, load balancers that use server CID need that server CID to route ICMPv6 packets back to the server doing PMTUD.

@'Kazuho Oku'<mailto:[email-masked]> suggested using the new packet coalescing functionality by sending an invalid long-header packet and coalescing it with a valid short-header packet.  This would have to work, if one follows the current spec strictly.  This is definitely a hack, however.

I would like to come up with something that is not a hack, does not require sending deliberately invalid packets, but also not to complicate the design with the need to care about key phase and whatever else one wants to put in the short-header in the future.

What do people think about a new "0x7B - PMTU Probe" long header packet type?
A packet of that type would just be a bare minimum long header packet per Invariants (nothing after source CID), and its only purpose would be to be coalesced with other QUIC packets.

- Igor

---

From: Christian Huitema <[email-masked]>
Date: Fri, 29 Jun 2018 14:18:45 -1000

On 6/29/2018 2:00 PM, Lubashev, Igor wrote:

> We talked briefly in Kista about the possibility of using Long Header
> packets for PMTUD probes.  See Issue 1243
> (https://github.com/quicwg/base-drafts/issues/1243) for context. 
> Briefly, load balancers that use server CID need that server CID to
> route ICMPv6 packets back to the server doing PMTUD.
>
>  
>
> @'Kazuho Oku' <mailto:[email-masked]> suggested using the new
> packet coalescing functionality by sending an invalid long-header
> packet and coalescing it with a valid short-header packet.  This would
> have to work, if one follows the current spec strictly.  This is
> definitely a hack, however.
>
>  
>
> I would like to come up with something that is not a hack, does not
> require sending deliberately invalid packets, but also not to
> complicate the design with the need to care about key phase and
> whatever else one wants to put in the short-header in the future.
>
>  
>
> What do people think about a new “0x7B – PMTU Probe” long header
> packet type?
>
> A packet of that type would just be a bare minimum long header packet
> per Invariants (nothing after source CID), and its only purpose would
> be to be coalesced with other QUIC packets.
>

My personal inclination is to just ignore ICMP, and thus not have to
deal with related attacks. My limited experience so far is that active
PMTU discovery succeeds after just a couple of probes.

In any case, I would rather not have a specific "PMTU Probe" long header
-- I would rather not disclose to middleboxes that the node is engaged
in PMTUD. But I could see the point of a generic "1-RTT" long header. It
could help make stateless reset work. And it could be sent proactively,
say every few RTT, as a form of greasing.

-- Christian Huitema

---

From: Ian Swett <[email-masked]>
Date: Fri, 29 Jun 2018 20:32:29 -0400

I suggest using a RETRY packet with a 0 byte token length and DCIL.  Which
is basically an invariant header and nothing else.  Technically it's also a
hack, but at least you don't have to send anything extra, and it doesn't
need to be encrypted.

On Fri, Jun 29, 2018 at 8:19 PM Christian Huitema <[email-masked]>
wrote:

> packets for PMTUD probes.  See Issue 1243 (
> https://github.com/quicwg/base-drafts/issues/1243) for context.  Briefly,
> load balancers that use server CID need that server CID to route ICMPv6
> packets back to the server doing PMTUD.
>
>
>
> @'Kazuho Oku' <[email-masked]> suggested using the new packet
> coalescing functionality by sending an invalid long-header packet and
> coalescing it with a valid short-header packet.  This would have to work,
> if one follows the current spec strictly.  This is definitely a hack,
> however.
>
>
>
> require sending deliberately invalid packets, but also not to complicate
> the design with the need to care about key phase and whatever else one
> wants to put in the short-header in the future.
>
>
>
> What do people think about a new “0x7B – PMTU Probe” long header packet
> type?
>
> A packet of that type would just be a bare minimum long header packet per
> Invariants (nothing after source CID), and its only purpose would be to be
> coalesced with other QUIC packets.
>
>
> My personal inclination is to just ignore ICMP, and thus not have to deal
> with related attacks. My limited experience so far is that active PMTU
> discovery succeeds after just a couple of probes.
>
> -- I would rather not disclose to middleboxes that the node is engaged in
> PMTUD. But I could see the point of a generic "1-RTT" long header. It could
> help make stateless reset work. And it could be sent proactively, say every
> few RTT, as a form of greasing.
>
> -- Christian Huitema
>
>
>
>

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 30 Jun 2018 10:55:30 +0900

2018-06-30 9:18 GMT+09:00 Christian Huitema <[email-masked]>:
> (https://github.com/quicwg/base-drafts/issues/1243) for context.  Briefly,
> @'Kazuho Oku' suggested using the new packet coalescing functionality by
> sending an invalid long-header packet and coalescing it with a valid
> short-header packet.  This would have to work, if one follows the current
> spec strictly.  This is definitely a hack, however.
>
>
>
> I would like to come up with something that is not a hack, does not require
> sending deliberately invalid packets, but also not to complicate the design
> with the need to care about key phase and whatever else one wants to put in
> the short-header in the future.
>
>
>
> In any case, I would rather not have a specific "PMTU Probe" long header --
> I would rather not disclose to middleboxes that the node is engaged in

+1

Use of an invalid long header packet is a form of greasing. There is
no point in explicitly disclosing the fact that an endpoint is engaged
in a PMTUD.

Hence I continue to believe that using an invalid long header packet
for the purpose would be fine.

It *could* be a Retry packet as Ian suggests, but it can be anything
else. And even if it is not a Retry packet, it does not need to be
encrypted or carry the AEAD tag, because nobody is going to decrypt it
(for example a Handshake packet with a zero-length payload is just an
ordinary form of an invalid packet).

-- 
Kazuho Oku

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 30 Jun 2018 04:21:58 +0000

I like the idea of greasing. I also like the idea of using 1-rtt headers to make stateless reset work.

I would prefer not to use known packet types, especially "INITIAL" and "0-RTT", because that will confuse stateless load balancers (these packet types are expected to carry random destination CID). But RETRY and HANDSHAKE seem fine. A special "Generic 0-rtt" type would work, too.

- Igor

-----Original Message-----
From: Kazuho Oku [[email-masked]]
Received: Friday, 29 Jun 2018, 9:55PM
To: Christian Huitema [[email-masked]]
CC: Lubashev, Igor [[email-masked]]; IETF QUIC WG [[email-masked]]
Subject: Re: Using Long Header packets for PMTUD probes

+1

--
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 30 Jun 2018 02:09:40 -0400

Sending explicit invalid headers would pollute logs and make it more
difficult to track down problems.

I’d assume probes are infrequent, but otherwise they might also tie up
resources and prevent (by the nature of greasing) dropping packets in DDoS
scenario, or black listing addresses with bad content for a while.

Mikkel

On 30 June 2018 at 06.22.36, Lubashev, Igor (
ilubashe=[email-masked]) wrote:

I like the idea of greasing. I also like the idea of using 1-rtt headers to
make stateless reset work.

I would prefer not to use known packet types, especially "INITIAL" and
"0-RTT", because that will confuse stateless load balancers (these packet
types are expected to carry random destination CID). But RETRY and
HANDSHAKE seem fine. A special "Generic 0-rtt" type would work, too.

- Igor

-----Original Message-----
*From:* Kazuho Oku [[email-masked]]
*Received:* Friday, 29 Jun 2018, 9:55PM
*To:* Christian Huitema [[email-masked]]
*CC:* Lubashev, Igor [[email-masked]]; IETF QUIC WG [[email-masked]]
*Subject:* Re: Using Long Header packets for PMTUD probes

> I would like to come up with something that is not a hack, does not
require
--

+1

--
Kazuho Oku

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 30 Jun 2018 13:01:41 +0000

I can see the log pollution argument. When a packet is dropped, people often want to be able to say why. At the minimum, it would pollute the meaning of some counter -- it would increment for both intentionally invalid and unintentionally invalid long header packets, making it impossible to tell the two apart. Hence, a specific "Generic 1-rtt long header" type feels preferable.

I would not worry about DDoS with such packets. They still require a valid CID. It is simpler and more effective to DDoS with something that tries to elicit a reply and not just a drop (and does not contain a valid CID).

-----Original Message-----
From: Mikkel Fahnøe Jørgensen [[email-masked]]
Received: Saturday, 30 Jun 2018, 2:09AM
To: [email-masked] [[email-masked]]; Lubashev, Igor [[email-masked]]; [email-masked] [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: RE: Using Long Header packets for PMTUD probes

Sending explicit invalid headers would pollute logs and make it more difficult to track down problems.

I'd assume probes are infrequent, but otherwise they might also tie up resources and prevent (by the nature of greasing) dropping packets in DDoS scenario, or black listing addresses with bad content for a while.

Mikkel

On 30 June 2018 at 06.22.36, Lubashev, Igor (ilubashe=[email-masked]<mailto:ilubashe=[email-masked]>) wrote:

- Igor

-----Original Message-----
From: Kazuho Oku [[email-masked]<mailto:[email-masked]>]
Received: Friday, 29 Jun 2018, 9:55PM
To: Christian Huitema [[email-masked]<mailto:[email-masked]>]
CC: Lubashev, Igor [[email-masked]<mailto:[email-masked]>]; IETF QUIC WG [[email-masked]<mailto:[email-masked]>]
Subject: Re: Using Long Header packets for PMTUD probes

2018-06-30 9:18 GMT+09:00 Christian Huitema <[email-masked]<mailto:[email-masked]>>:
> (https://github.com/quicwg/base-drafts/issues/1243<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_1243&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=X-NJO04I-P6QgduCa5-jWI7QC_mILlYpjmLP5p-T-X0&s=v9GHLI2TXgBuQxsk21bjDeWPYewcHxL0nEgn_HtMsXk&e=>) for context.  Briefly,

+1

--
Kazuho Oku