RE: Using Long Header packets for PMTUD probes

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

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 [[e-mail]]
Received: Saturday, 30 Jun 2018, 2:09AM
To: [e-mail] [[e-mail]]; Lubashev, Igor [[e-mail]]; [e-mail] [[e-mail]]
CC: [e-mail] [[e-mail]]
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=[e-mail]<mailto:ilubashe=[e-mail]>) 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 [[e-mail]<mailto:[e-mail]>]
Received: Friday, 29 Jun 2018, 9:55PM
To: Christian Huitema [[e-mail]<mailto:[e-mail]>]
CC: Lubashev, Igor [[e-mail]<mailto:[e-mail]>]; IETF QUIC WG [[e-mail]<mailto:[e-mail]>]
Subject: Re: Using Long Header packets for PMTUD probes

2018-06-30 9:18 GMT+09:00 Christian Huitema <[e-mail]<mailto:[e-mail]>>:
> 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<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,
> load balancers that use server CID need that server CID to route ICMPv6
> packets back to the server doing PMTUD.
>
>
>
> @'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.
>
>
>
> 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.

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

> -- Christian Huitema
>
>
>



--
Kazuho Oku