Re: Space for Packet Metadata

[Mikkel Fahnøe Jørgensen <[e-mail]>]

> 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:

https://www.vox.com/world/2017/6/13/15791744/russia-election-39-states-hack-putin-trump-sessions

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.