Re: Packet number encryption

[Roberto Peon <[e-mail]>]

Note that the size of the CID is also not known to the network assuming we are encrypting and doing variable, implicit length CID for short headers (which is what I understand to be the proposal) chosen by the server.

The l7 may encode the length within the CID, which one could imagine might be common, however the network would have a higher bar to determining it.

Unless we prevent it, assuming the server can cause the client to use multiple CIDs, the length of the CID could vary even within the packets on a single flow/5-tuple.

-=R

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: "Brian Trammell (IETF)" <[e-mail]>
Date: 2/1/18 12:08 AM (GMT-08:00)
To: Jana Iyengar <[e-mail]>
Cc: Martin Thomson <[e-mail]>, Roberto Peon <[e-mail]>, Ted Hardie <[e-mail]>, Eric Rescorla <[e-mail]>, Mirja Kühlewind <[e-mail]>, Christian Huitema <[e-mail]>, QUIC WG <[e-mail]>
Subject: Re: Packet number encryption

hi Jana, all,

> On 1 Feb 2018, at 03:46, Jana Iyengar <[e-mail]> wrote:
>
> I like this proposal for the ossification reason that Roberto described, but I also like it because it really simplifies things from an implementation perspective.

There seems to be a largely unquestioned assumption that packet number encryption has utility for ossification prevention. I am not convinced of this.

Our experience with TLS greasing shows that placing random values in fields that would otherwise largely be static over the lifetime of the protocol improves the ability to use those fields later. Packet number encryption is greasing only by analogy. "Field X has value Y" is a fundamentally different observation than "The values of field X over time are governed by function F", and I'm not sure that intuition in the simpler case applies directly to the more complicated one.

Specifically, for packet number encryption, the assumption appears to be that in-network devices will deploy during the operational lifetime of QUIC v1 that will make use of the observation that packet numbers monotonically increase, in a way that will impair the deployment of QUIC vN > 1 that does not have packet numbers that monotonically increase, or packet numbers that appear at a different location in the header. In other words, these devices will fail on this new version of QUIC in such a way that it will impair service to endpoints using QUIC vN.

Analogies to the TCP sequence number here are a bit flawed. The most important difference is that the open nature of TCP's wire image means that usage of the sequence number isn't limited to observation: on-path devices can change it, and forge or delay ACKs based on it. The only thing an on-path device can do with a QUIC packet with a packet number it doesn't like is to drop it. This function might have some utility as part of an in-network QUIC garbage filter, as part of an anti-DDoS system, but any such device would need to track the version number as well (indeed, tracking version negotiation and handshaking would be a useful primitive here in its own right), and would therefore have enough information to not break on new versions it knows about.

(Note we specifically don't care about the case where devices making use of this observation stop working in a way that the end-to-end properties of QUIC vN are preserved: the invariants as of a given version are the public wire-image interface to the protocol, anything else is at-your-own-risk, no-user-servicable-parts-inside).

I suspect that similar arguments can be had about all but the simplest proposed applications of greasing to functions more complex than "the value of field X is always Y or Z". The example of packet number tracking points to an anti-ossification approach that I have much more confidence in, though:

The vigorous and meaningful exercise of the version negotiation and version coexistence systems built into QUIC would force agility on on-path devices. The earlier we do this, the more effective it would be. I've already said this in other contexts, but I'll explicitly suggest it here: let's do QUIC 2, and soon (say, July 2019?), and use version negotiation *itself* as a method to "grease" the version negotiation mechanism along with the rest of the header.

> We currently have packet number gaps to be used with new CIDs, but these are the same packet numbers on the wire as within the transport. So, when used with connection migration or after quiescence, the sender and receiver of ACKs has to deal with potentially large gaps... this is encodable on the wire, sure, but these gaps are unnecessary within the transport.
>
> Encrypting packet numbers reduces complexity in that you get a packet number gap on the wire without having to explicitly model it inside the transport. The transport machinery starts packet numbers at 0, increments it by 1 irrespective of migration or quiescence, and the ACK frames similarly carry the plaintext packet number. Separating what's used within the transport and what's visible on the wire allows you to do things like use multiple CIDs within the same 5-tuple.

This is a more convincing argument for packet number encryption -- it does seem hard to get this elegance in the transport while having a non-trivially-linkable wire image without it.

> I see it as a clean separation of concerns, with consequent simplification in implementation and an additional degree of freedom.
>
> I'm not convinced of the value of packet number in measuring reordering degree, since this can be trivially done by looking at the IP ID field for packets on the same 5-tuple.

For IPv4 packets, on implementations where IPID is not randomized, yes. I don't have numbers on how prevalent these are; in any case, where it isn't randomized, that's arguably a bug that should be fixed. Should the guidance in the manageability draft, then, be "use IPv4 if you care about loss and reordering detection"? I am not optimistic about the chances of that getting past the IESG. ;)

Cheers,

Brian

> On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson <[e-mail]> wrote:
> With some light editing for quoting purposes...
>
> On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <[e-mail]> wrote:
> >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the same
> >> communicating peers  Alice'sPhone and Bob'sBankServer93?
> >
> > The latter assuming we allow the server to specify it.
>
> I find "assuming we allow the server to specify *it*" to be strangely cryptic.
>
> To be clear, my operating assumption is while that servers can provide
> multiple connection IDs, those connection IDs need to be usable on any
> 5-tuple.  Are you suggesting that a server might need to signal where
> a connection is usable?  (I can see how that might make sense, but it
> isn't possible with the protocol as specified.)  Or are you suggesting
> that there might need to be some signal that allows clients to
> distinguish between connection IDs that are for concurrent use? That
> is, as opposed to what you might assume to be sequential use based on
> the current specification.
>
> FWIW, it should be possible to remove the sequencing field from
> NEW_CONNECTION_ID after making this change.  The only reason left for
> sequential connection ID use is to give the server the ability to know
> when certain connection IDs no longer need to be available.  A server
> might then be able to clean up associated state and even reuse them.
>
> Of course, that likely only makes sense if the server is creating
> explicit mappings for each, which - as discussed at the interim -
> isn't super practical in many deployments.  Right now, I think that
> the assumption is an assumption only, and that relying on strictly
> linear use of connection IDs would be unwise.
>
>