Re: Packet number encryption

[Ted Hardie <[e-mail]>]

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

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


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