Re: Packet number encryption

[Martin Thomson <[e-mail]>]

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.

On Thu, Feb 1, 2018 at 10:25 AM, Roberto Peon <[e-mail]> wrote:
> 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" <[e-mail] on behalf of [e-mail]> wrote:
>
>
>
>     > Am 31.01.2018 um 04:08 schrieb Martin Thomson <[e-mail]>:
>     >
>     > On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema <[e-mail]> wrote:
>     >>> (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.
>     >
>     > 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).
>
>     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
>
>
>