Re: [ippm] QUIC concerns relating to draft-ietf-ippm-explicit-flow-measurements

Christian Huitema <> Thu, 11 May 2023 07:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DC84C151097 for <>; Thu, 11 May 2023 00:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L4bCYGJlfI-b for <>; Thu, 11 May 2023 00:38:34 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 620E7C151099 for <>; Thu, 11 May 2023 00:38:34 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1px0sg-0001MJ-SZ for; Thu, 11 May 2023 09:38:32 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4QH3f32rB5z5Rp for <>; Thu, 11 May 2023 00:38:03 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1px0sF-0005j8-96 for; Thu, 11 May 2023 00:38:03 -0700
Received: (qmail 12627 invoked from network); 11 May 2023 07:37:59 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 11 May 2023 07:37:59 -0000
Message-ID: <>
Date: Thu, 11 May 2023 00:37:55 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1
Content-Language: en-US
To: Lucas Pardue <>, Tommy Pauly <>
References: <> <> <>
From: Christian Huitema <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.23)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/iKwnF4dBjToJD/qtLFme+PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wTQJcK6O716WIVCzU1uqysKj/EwzSHE5FGYwwjsNRPCJJ6 clFo4AvlZiy6wwUBeZHmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaXBOAXLHDkxHWzDmPcqL2NRQ6V51u76v35b1wNe/MvdKZlHtr fFmLbdTp+b3T+7/82+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEEIgtEXyXj6S3SDvReMcV 8TXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7iff8pZ9ure3k2YtJj4Q8Z7SSCLBRD49hM4/gncGGy3ElPUJzCyuIGk7swdifG/JmK9 7Y4aftuGP4HDW4sDo4cZoYYpy78/ZfTpWFqEVNffsiyZvdx3ZJDsPzrvEdt+b8mxX4OQOI/UQ6jn FfMBgzwOSHunMg5j/UO+IMRndiIcrrlMcQttnESfnq3iTrojilbZcpPgEJKLbDyaC/LdLvvYXvl1 yp8i2IyY3OBoxahio/pVB9v9zY0h8asEYmbGGsJD9ySC20IzFkBtfP+lFUR4Wisys3n/AgIfZuqp iaZDvL13qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
Archived-At: <>
Subject: Re: [ippm] QUIC concerns relating to draft-ietf-ippm-explicit-flow-measurements
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 May 2023 07:38:35 -0000

On 5/10/2023 7:35 PM, Lucas Pardue wrote:
> Hey Tommy,
> On Thu, May 11, 2023 at 3:00 AM Tommy Pauly<>  wrote:
>> The document is describing how bits*could*  be used, not actually
>> suggesting reserving specific ones at this point.
>> This same feedback did come up in IESG review, and I believe that there
>> will be an update to remove details that refer to specific bit ranges to
>> avoid this danger.
>> I’ll let the authors chime in more =)
> To summarize the issue, there's only 7 bits that any QUIC version
> compatible with the Invariants can ever use. Unless client, server and
> observers all agree what those bits might mean, there's no way to actually
> use them assuredly. The draft doesn't pay enough attention to highlighting
> this deployment problem, so there's a risk that the work done to define the
> bits in the abstract is for nought because the next steps of trying this
> out for real are unclear. Relying on some private agreements of what the
> bits might mean isn't safe for several reasons.

I addition to Lucas' concerns, let me express my own concern with the 
mention of the "UDP surplus space". This is the same concern that I have 
with the proposal to define "UDP options". These options would define an 
unencrypted trailer of QUIC packet. The idea is that the IP packet 
length is longer than UDP header length plus UDP payload length, leaving 
bits at the end that are not covered by the QUIC encryption. These bits 
create a clear text "side channel", which can be easily used to 
compromise the security of QUIC. I think this a serious security hole, 
which should be blocked.

One way to block it is to immediately drop any QUIC packet for which IP 
length and UDP length don't match. Many firewalls do that already. Doing 
that will penalize any attempt to add a side channel to QUIC -- any 
application that used such a channel would cause packets to be dropped, 
making this kind of channels very unattractive.

-- Christian Huitema