Subject: Packet number encryption

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Jan 2018 12:59:17 +1100

Here's a PR:

https://github.com/quicwg/base-drafts/pull/1079

In short, this builds on Kazuho's excellent suggestion to use ECB-mode
to protect the packet number.  It does this only slightly differently,
using suggestions from ekr and others to allow for cryptographic
agility and use of primitives that match the negotiated AEAD.

In short, it takes some of the ciphertext of the packet payload, and
uses that to encipher the packet number.  My intuition is that this is
pretty solid, but I want to check if the working group is happy that
this is generally OK before seeking cryptographic review.

For instance, the requirement for side-channel resistance is already
controversial: https://github.com/quicwg/base-drafts/pull/1079/files#r164588705

For the record, I doubt that this can be proven to be secure without
both breaking new ground and adding some constraints to the AEADs that
we use.  And that's before we get into actual breaks on the technique
that I'm too thick-headed to think of.  In any case, we're relying on
this to protect against linkability, so I'd like to ensure that we're
not completely crazy in doing so.

In case people were wondering, and because it already came up: I
intend to separately propose a change to the short header packet that
would remove the type field and move the packet number length under
encryption.  See my response to Ian's question on the PR for an
explanation of how this will likely work.

---

From: Ian Swett <[email-masked]>
Date: Tue, 30 Jan 2018 09:43:46 -0500

Thanks for writing this up Martin.  I'm definitely supportive of something
like this, and I'd like to see it land in time we can try to interop with
it in London.

My intuition favors simplicity over crypto agility in this case, since
we're already forcing implementations to support AES-GCM for the handshake
packets, but I'm happy with whatever the group prefers.

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Tue, 30 Jan 2018 14:53:18 +0000

hi Martin,

Thanks for the PR.

> On 30 Jan 2018, at 01:59, Martin Thomson <[email-masked]> wrote:
> 
> Here's a PR:
> 

I'm not sure this isn't completely crazy.

Our model for linkage attacks seems a little too fuzzy to me to be useful for evaluating whether this proposal is an improvement on the status quo. Of course, there's an inherent tension among the identifiability of flows by 5-tuple, the explicit identifiability of flows by CID (which we'll work to remedy at the same time as we stick more bits in the CID, apparently), and the desire for two independent 5-tuple flows to remain unlinkable. So this is inherently hard, because we don't have internally consistent set of requirements for linkability support and avoidance.

Beyond this, though, we need to have a coherent idea of what we're trying to prevent. From discussions to date, I think these are the two cases we care about:

(1) An unprivileged on-path device that sees a packet from a flow that is migrated on purpose by an endpoint (i.e., due to connection migration or multipath) should not be able to associate that packet to the prior flow.

(2) An unprivileged on-path device that sees a packet from a flow that is unintentionally migrated (i.e., one of its globally routable addresses changes without the associated endpoint's knowledge) should not be able to associate that packet to the prior flow.

In the presence of any connection ID that has enough entropy to be used for load balancing, linkability avoidance in case 2 is impossible. Indeed, the CID exists in part to *allow* linkability in case 2. Any packet number encryption approach is necessarily useless for linkability avoidance in this case, unless the CID is also protected with a secret known only to the endpoints and the load-balancer. We'll see where the CID DT lands here.

When the connection ID is absent or protected, and the packet number is encrypted, case 2 is still problematic. In an unintentional migration, only two values in the five-tuple change, and it's impossible to make the first packet sent from the migrated endpoint to the non-migrated endpoint look like a handshake packet. So to find an unintentional migration, an observer only needs to look for all flows toward a 3-tuple without being preceded by a valid handshake that started within 30 seconds of another one ending on the same 3-tuple. Even for very large load balancers, this is not a giant anonymity set.

If you believe that greasing functions over packet numbers is necessary -- I'm not sure I do, but that's a different, future message -- then this proposal might be useful for that, but if linkability prevention is the goal, I'm not convinced it's fit for purpose.

This proposal also opens a trivial class of wasted-work attacks against QUIC servers by malicious clients, which can now craft packets which will require the server to partially decrypt them before realizing they're not useful. Obviously bad packet numbers can be avoided with simple heuristics. Less-obvious attacks might be crafted to incur significant nonproductive cost on the server side. This seems to be an unavoidable property of any approach to packet number encryption that would actually work, though, so that's not an observation about this specific proposal. I also haven't done the analysis to see if this is all that bad.

Note as well that this proposal comes with a manageability cost. On-path measurement of upstream loss and reordering would become impossible, and the fidelity of the spin bit under loss and reordering would be reduced.

> explanation of how this will likely work.

Yep, this makes sense. We'll need to consider these changes closely in concert with any change to the CID. As above, avoiding linkability with PN encryption while aiding it with a CID is hard, and a varlen CID plus a varint encrypted PN will make parsing fiddlier than it already is.

As Christian noted, using the short header type field to provide a sort of subsequence number or other packet-number independent explicit signal would mitigate the damage packet number encryption would to do loss and reordering observability, but not completely address them.

Cheers,

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jan 2018 12:31:59 -0800

On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell <[email-masked]> wrote:

> Our model for linkage attacks seems a little too fuzzy to me to be useful
> for evaluating whether this proposal is an improvement on the status quo.
> Of course, there's an inherent tension among the identifiability of flows
> by 5-tuple, the explicit identifiability of flows by CID (which we'll work
> to remedy at the same time as we stick more bits in the CID, apparently),
> and the desire for two independent 5-tuple flows to remain unlinkable. So
> this is inherently hard, because we don't have internally consistent set of
> requirements for linkability support and avoidance.
>
> Beyond this, though, we need to have a coherent idea of what we're trying
> to prevent. From discussions to date, I think these are the two cases we
> care about:
>
> (1) An unprivileged on-path device that sees a packet from a flow that is
> migrated on purpose by an endpoint (i.e., due to connection migration or
> multipath) should not be able to associate that packet to the prior flow.
>
> (2) An unprivileged on-path device that sees a packet from a flow that is
> unintentionally migrated (i.e., one of its globally routable addresses
> changes without the associated endpoint's knowledge) should not be able to
> associate that packet to the prior flow.
>
> In the presence of any connection ID that has enough entropy to be used
> for load balancing, linkability avoidance in case 2 is impossible. Indeed,
> the CID exists in part to *allow* linkability in case 2. Any packet number
> encryption approach is necessarily useless for linkability avoidance in
> this case, unless the CID is also protected with a secret known only to the
> endpoints and the load-balancer. We'll see where the CID DT lands here.
>
> When the connection ID is absent or protected, and the packet number is
> encrypted, case 2 is still problematic. In an unintentional migration, only
> two values in the five-tuple change, and it's impossible to make the first
> packet sent from the migrated endpoint to the non-migrated endpoint look
> like a handshake packet. So to find an unintentional migration, an observer
> only needs to look for all flows toward a 3-tuple without being preceded by
> a valid handshake that started within 30 seconds of another one ending on
> the same 3-tuple. Even for very large load balancers, this is not a giant
> anonymity set.
>
> If you believe that greasing functions over packet numbers is necessary --
> I'm not sure I do, but that's a different, future message -- then this
> proposal might be useful for that, but if linkability prevention is the
> goal, I'm not convinced it's fit for purpose.
>
> This proposal also opens a trivial class of wasted-work attacks against
> QUIC servers by malicious clients, which can now craft packets which will
> require the server to partially decrypt them before realizing they're not
> useful. Obviously bad packet numbers can be avoided with simple heuristics.
> Less-obvious attacks might be crafted to incur significant nonproductive
> cost on the server side. This seems to be an unavoidable property of any
> approach to packet number encryption that would actually work, though, so
> that's not an observation about this specific proposal. I also haven't done
> the analysis to see if this is all that bad.
>

Why isn't this already the case? I just take a valid packet, change a bit
in the MAC, and resend it a bunch of times.

-Ekr

> Note as well that this proposal comes with a manageability cost. On-path
> measurement of upstream loss and reordering would become impossible, and
> the fidelity of the spin bit under loss and reordering would be reduced.
>
> Yep, this makes sense. We'll need to consider these changes closely in
> concert with any change to the CID. As above, avoiding linkability with PN
> encryption while aiding it with a CID is hard, and a varlen CID plus a
> varint encrypted PN will make parsing fiddlier than it already is.
>
> As Christian noted, using the short header type field to provide a sort of
> subsequence number or other packet-number independent explicit signal would
> mitigate the damage packet number encryption would to do loss and
> reordering observability, but not completely address them.
>
> Cheers,
>
> Brian
>
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Jan 2018 11:00:54 -1000

On 1/30/2018 10:31 AM, Eric Rescorla wrote:
>
>
> On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     hi Martin,
>     ...

I think this beats the alternatives, either complex-but-fragile
obfuscation schemes, or separate per-path encryption contexts. Also, I
like that this is somewhat future-proof -- it allows building future
multipath extension at an almost minimal cost.

>     ...
>     Beyond this, though, we need to have a coherent idea of what we're
>     trying to prevent. From discussions to date, I think these are the
>     two cases we care about:
>
>     (1) An unprivileged on-path device that sees a packet from a flow
>     that is migrated on purpose by an endpoint (i.e., due to
>     connection migration or multipath) should not be able to associate
>     that packet to the prior flow.
>

Yes.

>
>     (2) An unprivileged on-path device that sees a packet from a flow
>     that is unintentionally migrated (i.e., one of its globally
>     routable addresses changes without the associated endpoint's
>     knowledge) should not be able to associate that packet to the
>     prior flow.
>

No. That one can only be solved through a voluntary action from the
sender. If the client is in the middle of sending a stream, correlation
is trivial whatever we do. There are however two plausible improvements:

a) Explicit migration after signalling by the NAT box. We would need
some new protocol to do that, maybe ICMP based. It could work in the
"mobile router" case.

b) Opportunistic migration out of quiescence. NAT rebinding typically
happen after a period of silence. Clients that just start sending after
a long silence may decide to "simulate a migration", to break the
correlation.

Both of these improvements will benefit from packet number encryption.

> ...
>
>     As Christian noted, using the short header type field to provide a
>     sort of subsequence number or other packet-number independent
>     explicit signal would mitigate the damage packet number encryption
>     would to do loss and reordering observability, but not completely
>     address them.
>

Yes. We have to be serious about network manageability. There has to be
a sweet spot between expose everything so network management sees it and
encrypt everything so middle boxes do not breach privacy or ossify the
protocol. I think tricks like the spin bit and/or a small-modulo
sequence number may be close to that sweet spot.

Part of me would want to see these spin bit and small modulo sequence
number down in the IP header. That would look like a very nice use of
the IPv6 flow-ID. Wouldn't it be nice if network management was based on
the network header? But failing that, maybe we need to start something
in QUIC.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 15:08:25 +1100

>> multipath) should not be able to associate that packet to the prior flow.

Agreed.  This remains the primary target.  I don't think that there
are any negatives with this design with respect to this use case (or
at least I found nothing in Brian's email on this point).

> No. That one can only be solved through a voluntary action from the sender.
> If the client is in the middle of sending a stream, correlation is trivial
> whatever we do.

This might not be entirely true.  In the current design, a client can
opt out and refuse to send a connection ID even if the server wants
one.  However, I suspect that all you will get in that case is
failure.  Success would only be possible if a server used 5 tuple as
its primary way of identifying connections, and it seems like we'll
see that happen very rarely.  The connection ID bit in the short
header is a design point that I intend to address when the
larger/variable-length connection ID changes come in.

> There are however two plausible improvements:
>
> a) Explicit migration after signalling by the NAT box. We would need some
> new protocol to do that, maybe ICMP based. It could work in the "mobile
> router" case.

This seems a little hopeful to me.  Also, I can imagine a NAT dropping
packets to "save" clients from exposing session continuity.  I don't
really want to see that sort of NAT feature being deployed.  These
boxes are already hard enough to deal with.

> b) Opportunistic migration out of quiescence. NAT rebinding typically happen
> after a period of silence. Clients that just start sending after a long
> silence may decide to "simulate a migration", to break the correlation.

This is what I have always assumed.  Maybe we should write that little
tip down.  Doing so might increase the demand on new connection IDs so
that those who actually need to use them will find that they are
usable.

https://github.com/quicwg/base-drafts/issues/1087

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 31 Jan 2018 07:44:32 +0000

> Am 31.01.2018 um 04:08 schrieb Martin Thomson <[email-masked]>:
> 

If that is the goal, I think the complexity of the proposed solution is not justified. Just select a new random offset when you migrate but increase the packet number monotonously otherwise to support manageability.

I’m really concerned about complexity here. Even though this scheme is not very complex, any complexity is a potential source for future implementation errors which can also led to restrictions in what changes can be deploy with future versions. Making a protocol as simple as possible and thereby the spec as easy understandable as possible is also key for deployment. If we add complexity here without making it clear what the goal or additional benefit is of the complexity, I think that is just wrong.

My 2c.
Mirja

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 31 Jan 2018 09:52:32 +0000

+1 - Simply: This *is* complicated and seems to add little.

Gorry

On 31/01/2018, 07:44, Mirja Kühlewind wrote:
>
>> Am 31.01.2018 um 04:08 schrieb Martin Thomson<[email-masked]>:
>>
>> On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema<[email-masked]>  wrote:

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 Jan 2018 09:54:51 +0000

> On 30 Jan 2018, at 20:31, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> Why isn't this already the case? I just take a valid packet, change a bit in the MAC, and resend it a bunch of times.

It seems to me that the borked MAC replay is easy to distinguish and dynamically filter at the receiver: if you see this, someone is screwing with you, and you can safely blackhole them. On the other hand, a stream of packets that look valid to the decryption stage but that will be rejected as irrelevant but not insane seems harder to reject and blackhole in the general case

Cheers,

Brian

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 31 Jan 2018 10:00:14 +0000

> +1 - Simply: This *is* complicated and seems to add little.

So as an implementor (chair hat off), this adds very little to the overall complexity of the protocol.

Lars

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 Jan 2018 10:14:22 +0000

> On 30 Jan 2018, at 21:00, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
> I think this beats the alternatives, either complex-but-fragile obfuscation schemes, or separate per-path encryption contexts. Also, I like that this is somewhat future-proof -- it allows building future multipath extension at an almost minimal cost.

I'll note that this presupposes a class of designs for MPQUIC. There's another entire class where a higher-layer end-to-end multistream association maps down to a set of completely separate QUIC connections. I don't know that we're at a point where we can say that we should prefer one over the other (and indeed, we shouldn't try to be before QUIC version 2).

>> (1) An unprivileged on-path device that sees a packet from a flow that is migrated on purpose by an endpoint (i.e., due to connection migration or multipath) should not be able to associate that p…

Okay. This seems like a reasonable goal.

> No. That one can only be solved through a voluntary action from the sender. If the client is in the middle of sending a stream, correlation is trivial whatever we do.

Yep.

> a) Explicit migration after signalling by the NAT box. We would need some new protocol to do that, maybe ICMP based. It could work in the "mobile router" case.

You could bind this to something like a future, more dynamic PvD. Or you could have done it inline with PLUS, had that been a thing we'd decided to do. In either case deployment before the end of next decade seems optimistic.

> b) Opportunistic migration out of quiescence. NAT rebinding typically happen after a period of silence. Clients that just start sending after a long silence may decide to "simulate a migration", to break the correlation.

Seems like it'd be simpler just to always try to 0RTT resume after being quiet for more than 30s, though that would require the application mapping to be resumption-aware.

> Yes. We have to be serious about network manageability. There has to be a sweet spot between expose everything so network management sees it and encrypt everything so middle boxes do not breach privacy or ossify the protocol. I think tricks like the spin bit and/or a small-modulo sequence number may be close to that sweet spot.
> 
> Part of me would want to see these spin bit and small modulo sequence number down in the IP header. That would look like a very nice use of the IPv6 flow-ID.

As I understand it, the currently (spottily) deployed uses of the flow-ID, which ECMP based on it, would prevent that. I've only seen anecdata here though.

> Wouldn't it be nice if network management was based on the network header? But failing that, maybe we need to start something in QUIC.

That ship sailed a long while ago (cf. RFC 7872). We have indeed specified relatively higher-overhead DO headers for diagnostics (RFC 8250), though given Internet deployment issues with extension headers and DO, it's really only intended for usage in local networks.

There's are reasons practice has migrated to passive observation of TCP for this sort of thing, and building a protocol to address TCP ossification won't fix them.

Cheers,

Brian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 21:40:03 +1100

> Seems like it'd be simpler just to always try to 0RTT resume after being quiet for more than 30s, though that would require the application mapping to be resumption-aware.

You would lose a lot of state that way (absent some way of preserving
that state, which we don't have).  0-RTT also has a bunch of
drawbacks, including but not limited to: a pretty significant crypto
hit, a non-zero risk of not working, replay exposure, limitations on
number of bytes.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 31 Jan 2018 04:49:16 -0800

Originally I liked the idea of packet number encryption, but I am no longer
fully convinced considering that the gains are limited and the data being
protected are not likely secret to a powerful attacker anyway.

It is no longer possible to do AEAD in-place without first unwrapping the
packet number.

I don’t have any numbers on AES-NI setup cost, but it could be
significantly more expensive per byte to decrypt a single block compared to
decrypting a full packet, and there are also constrained devices to
consider.

This can lead to additional latency in packet handling and more per
connection storage requirement for crypto keys, and it strains the limited
crypto core resources.

With 17 byte connection ID’s they may be a (self-imposed) crypto overhead
on this as well using yet another crypto context.

There is also additional implementation complexity as Mirja mentions,
though I’m not sure that it is that much of a burden - the main issue is to
correctly derive the packet number key.

However, this must also be balanced against the alternatives in relation to
migration (though not all connections want/need the overhead and complexity
of migration):

Packet numbers MUST be unique across migration when using the same crypto
context, so

a) using separate packet number space per CID is separate crypto context
per CID
b) using a separate connection but allow streams to continue on a new
connection.
c) using a random gap (as is the case now), which might not be as secure is
desired (debatable I think)
d) doing nothing at all to protect packet number linkage

A separate packet number space has crypto overhead and so does a separate
connection (a, b), so not really simpler.

Getting rid of random gap c) would be a gain, but only if gaps were also
removed elsewhere, notably as protection abasing optimistic ACK attack from
hostile peer.

Options c, and d would allow the multi-path design to evolve for QUIC v2
without doing some half-baked stop-gap solution that might fit poorly into
that design.

Doing nothing at all would kind of be the same as giving up. But it would
be really nice to get rid of all packet number gaps, and it, it is really
really dubious that encrypting packet numbers would prevent linkage due to
timing analysis etc.

So in conclusion, perhaps packet number encryption is not without merits,
but perhaps it is getting a bit ahead of other design elements that need to
be in place first.

Mikkel

> at least I found nothing in Brian's email on this point).

If that is the goal, I think the complexity of the proposed solution is not
justified. Just select a new random offset when you migrate but increase
the packet number monotonously otherwise to support manageability.

I’m really concerned about complexity here. Even though this scheme is not
very complex, any complexity is a potential source for future
implementation errors which can also led to restrictions in what changes
can be deploy with future versions. Making a protocol as simple as possible
and thereby the spec as easy understandable as possible is also key for
deployment. If we add complexity here without making it clear what the goal
or additional benefit is of the complexity, I think that is just wrong.

My 2c.
Mirja

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Feb 2018 08:05:04 +1100

On Wed, Jan 31, 2018 at 11:49 PM, Mikkel Fahnøe Jørgensen
<[email-masked]> wrote:
> I don’t have any numbers on AES-NI setup cost, but it could be significantly
> more expensive per byte to decrypt a single block compared to decrypting a
> full packet, and there are also constrained devices to consider.

It's true that AES has some costs that relate to the installation of a
key, but those costs are paid just once per key.  Once a key is
installed, the per-packet cost is a single block, which - with AES-NI
- is a handful of cycles.  Even on very limited devices doesn't take
that much effort (though ChaCha is still cheaper.  Keep in mind that
we already have the GCM costs paid, since the packet number is part of
the AAD.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 31 Jan 2018 23:25:51 +0000

There are two obvious goals/benefits:
1) Slow/prevent ossification.
2) Raise the barrier higher for tracking/flow correlating.

If we have multiple CIDs (which are valid on more than one 5-tuple) and “multipath” (one could imagine switching between a bunch of IPv6 addresses which go to the same hosts) we can require a higher storage baseline before traffic can be correlated. This is where I believe #2 really comes into play. 

#1 is nothing to sneeze at: experience with TCP has shown very real harm from having things which allow sequencing of packets in the clear (unable to roll out changes which should have been compatible). To me, this is the primary use-case: maintaining future flexibility.

-=R

On 1/30/18, 11:45 PM, "QUIC on behalf of Mirja Kühlewind" <[email-masked] on behalf of [email-masked]> wrote:

    

    My 2c.
    Mirja

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Feb 2018 11:00:15 +1100

Roberto makes a point I keep forgetting.  This would allow clients to
alternate between connection IDs in a way that the protocol currently
cannot support.

And that reminds me of another thing: Jana/Eric's connection migration
design depends on something like this.  Simpler designs that use a gap
or randomized offset for each connection ID make linkability trivial
if you are alternating between paths in the same way that alternating
between connection IDs might.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Jan 2018 16:17:05 -0800

On Wed, Jan 31, 2018 at 3:25 PM, Roberto Peon <[email-masked]> wrote:

> If we have multiple CIDs (which are valid on more than one 5-tuple) and
> “multipath” (one could imagine switching between a bunch of IPv6 addresses
> which go to the same hosts) we can require a higher storage baseline before
> traffic can be correlated. This is where I believe #2 really comes into
> play.
>

Clarifying question:  when you says "multiple CIDs which are valid on more
than one 5-tuple" do you mean CID 1 is valid for 5-tuple A while CID 2 is
valid for 5-tuple B and CID 3 is valid for 5-tuple C, but the communicating
peers are really Alice'sPhone and Bob'sBank'sServer93 for all of the
above?   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?

Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Jan 2018 16:32:38 -0800

On Wed, Jan 31, 2018 at 4:00 PM, Martin Thomson <[email-masked]>
wrote:

> If you are using a standard pattern to probe for path availability before
immediate switching, a timing based correlation will work in many cases.
If you can break that linkage, what you need is the ability to use packet
numbers on each path that do not directly correlate in a way visible to the
non-cooperating path elements.   If you only care about the
make-before-break case of probing, you can achieve that much more simply,
but having probe packets use a designated packet number space that doesn't
overlap with the actual connection's packet number space until the
connection is confirmed, and then does random offset.  If you want to use
both paths at the same time, then you have the same problem MPTCP sees with
sequence number offsets in TCP.  That's where I think hiding the packet
numbers actually helps, but we haven't gotten any where close to that
design in the protocol, and there are other ways to achieve the same thing.

I still like this design, but I think we have to be careful in how we
describe its benefits; it's not going to break all linkability and it's not
going to make connection migration or multipath that much easier.  I think
that means we should take Mirja's comments on the implementation costs
seriously.  Ekr has already given an estimate, and I would appreciate
estimates from other groups as well.

Ted

> > #1 is nothing to sneeze at: experience with TCP has shown very real harm
> from having things which allow sequencing of packets in the clear (unable
> to roll out changes which should have been compatible). To me, this is the
> primary use-case: maintaining future flexibility.
> >
> > -=R
> >
> > On 1/30/18, 11:45 PM, "QUIC on behalf of Mirja Kühlewind" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >
> >
> >     If that is the goal, I think the complexity of the proposed solution
> is not justified. Just select a new random offset when you migrate but
> increase the packet number monotonously otherwise to support manageability.
> >
> >     I’m really concerned about complexity here. Even though this scheme
> is not very complex, any complexity is a potential source for future

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Jan 2018 14:44:19 -1000

On 1/31/2018 2:32 PM, Ted Hardie wrote:
> describe its benefits; it's not going to break all linkability and
> it's not going to make connection migration or multipath that much
> easier.  I think that means we should take Mirja's comments on the
> implementation costs seriously.  Ekr has already given an estimate,
> and I would appreciate estimates from other groups as well.

About implementation cost, maybe we should wait for feedback from the
actual implementations. Only Lars commented so far, and his feedback was
"no big deal". If Lars is correct, we ought to be able to demonstrate
interoperability soon after draft-10 is published. In any case, we will
have some good feedback on actual implementation cost.

-- Christian Huitema

---

From: Roberto Peon <[email-masked]>
Date: Thu, 1 Feb 2018 01:02:25 +0000

The latter assuming we allow the server to specify it.

-=R

From: Ted Hardie <[email-masked]>
Date: Wednesday, January 31, 2018 at 4:18 PM
To: Roberto Peon <[email-masked]>
Cc: Mirja Kühlewind <[email-masked]>, Martin Thomson <[email-masked]>, Brian Trammell <[email-masked]>, Eric Rescorla <[email-masked]>, QUIC WG <[email-masked]>, Christian Huitema <[email-masked]>
Subject: Re: Packet number encryption

On Wed, Jan 31, 2018 at 3:25 PM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
There are two obvious goals/benefits:
1) Slow/prevent ossification.
2) Raise the barrier higher for tracking/flow correlating.

Clarifying question:  when you says "multiple CIDs which are valid on more than one 5-tuple" do you mean CID 1 is valid for 5-tuple A while CID 2 is valid for 5-tuple B and CID 3 is valid for 5-tuple C, but the communicating peers are really Alice'sPhone and Bob'sBank'sServer93 for all of the above?   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?

Ted

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Feb 2018 13:00:40 +1100

With some light editing for quoting purposes...

On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <[email-masked]> 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?
>

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.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Jan 2018 16:25:01 -1000

> linear use of connection IDs would be unwise.
Then maybe we need a way for the client to signal that it won't use a
particular ID in the future.

For privacy reasons, IDs should only be used on single paths. If a
client tries to use a path and then gives up, the ID won't be used
anymore. So maybe the client needs to have a way to tell that to the
server. Something like an "OLD_CONNECTION_ID" frame.

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 31 Jan 2018 18:46:56 -0800

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.

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.

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.