Re: Space for Packet Metadata

Mikkel Fahnøe Jørgensen <> Wed, 28 February 2018 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB9EA12D7E8 for <>; Wed, 28 Feb 2018 06:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h9k0RbX7XZv7 for <>; Wed, 28 Feb 2018 06:34:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE6C9129C5D for <>; Wed, 28 Feb 2018 06:34:19 -0800 (PST)
Received: by with SMTP id k135so3699655ite.2 for <>; Wed, 28 Feb 2018 06:34:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ooOqQT4riOBG5Pe8SCWrFMlw0nIjmDcZs76KVvqQa34=; b=n/DHUuR7kKNleeb5BxLjCo+cR6qEl1kAGFLK3XxT0qMFEJCusLQoVNAJyyrlbjQgrz fJ+2CtkcHsOaU0Iz/6W6XAOkxWddyR/VMYiLNaNV22sUV2Mt67tMnL8eOh8Fb8NtF5YI H7ZU3c5x+5o3TdMMZIKBFV22W4bgGjnlObLohMFijTIUhAiEETojyDMRUhypmz3d3RNZ OMGuIJAo9vHhO5ohBukPLiowOJa8rDFF9v35NS9DHh4AhT2iLRHViP3KB3YX1cpTeVuV Xw2+S//GlD1KOrBVJgePH/XwAzRQ3eOkoWmV4NH3C3tVD4a9c+Y5OgDqgjOZkXDV01CA VLkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ooOqQT4riOBG5Pe8SCWrFMlw0nIjmDcZs76KVvqQa34=; b=JZ+dPXJObYbz8qAwf+BfclkjZmhpABDlGg/jexKM681Rc+7F6woxo4znx84PsDIWaz guBWgy1tMw2MtCS68UBasiMnkJa9p5+cawc+1y6Vkw2Ytp968zmeo400nLHnXlHvxsmb qpdcCDQdG86C7fomCV66jj3W/6BiA1fXpLk1KhmtllGok/gcmS626uKpKfSmtU3S9DaJ XPUESSUR6A356oXSJoj+db03KzYH04ZZKoM9RwbJJmzmmRJdBxSsyExp4Vg3NZSLUUJS fFXzLqqpahNU9edbiVn8rmGdqU0YPciGcd0kuokzI2GCc+mkbrpphqUJ/+G3AWgh2+AJ ZQwQ==
X-Gm-Message-State: APf1xPCyn6SSv2R6+WZm9rnx/Tu/pDoXUNWPtoyiyisFXGuenu5+zzn2 dJ5MRHAuHfOF+8ZIIzDxt9U6BE72QfklOLwPanI=
X-Google-Smtp-Source: AG47ELsZ425Ygp2qPkfJVEw/cQm83tbl8QXftRJjChxwz4KkdAqB6j5NjUn0V53l3V4zV6m2TIkR4gcaK5D07EJZTA4=
X-Received: by with SMTP id v203mr1978613ita.150.1519828459213; Wed, 28 Feb 2018 06:34:19 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 28 Feb 2018 06:34:18 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 28 Feb 2018 06:34:18 -0800
Message-ID: <>
Subject: Re: Space for Packet Metadata
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="001a1143b9b06e562a056646a3d2"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Feb 2018 14:34:22 -0000

> This could simplify tunnelling and monitoring, and also other cases where
> multiple servers cooperate on handling a single connection.

How do you imagine those servers would use this space?

One example is forming a consensus across servers handling connections from
multiple clients concurrently. A current leader receives the packet and
either just signs it, or verifies the content first, then forwards the
packet to n - 1 other servers in different datacenters (depending on
protocol). Once enough signatures have been collected, the packet is
accepted and processed, adding an ordering across all connections. If a
server is compromised, it can’t do something with the packet the other
server haven’t already authorised. In some protocols each additional server
would add to the previous signature thus requiring quite a few signatures
to ensure consensus. It is of great value to have these signatures in a
single packet because it provides atomic read guarantees. This can easily
consume 80 or more bytes.

Obviously there is a lot more to it than that, and it can be done after
unwrapping QUIC and via secure point to point communication, but that would
be less efficient and you might have difficulty proving the content
originated from a given client without even more signatures, and the client
might have to be involved in the protocol.

It only works, it you keep enough servers safe, or course:

This is just one example, but any time a backend needs to coordinate, extra
space might be useful. Another example could be a virtual routing token
added at the end of the packet.