Re: Privacy considerations of multipath (Re: My BoF report: multipath)

[Spencer Dawkins at IETF <[e-mail]>]

On Fri, Oct 23, 2020 at 4:44 PM Roland Zink <[e-mail]> wrote:

> Hi Lucas,
>
>
> 1)  Just opening a second QUIC connection is not enough as it will most
> likely use the same path as the first. Some API to list interfaces and
> their properties is needed. Then the second second connection can be bound
> to the desired interface. If for example you want to check the available
> WiFi networks in Android then you need location permissions and the user
> needs to grant them and can revoke them anytime. In addition you need to
> write some legal text what you do with this data.
>
>
> 2) Is probably similar to 1) but may use some system library to do the job
> and hide it from the application itself.
>
>
> I can't speak for others but my expectation would be that some OS-level
> API should abstract network layer information when possible. Still and e2e
> solution will reveal the clients changing external IP addresses on the
> server side. A longer lived multipath connection may be used to track the
> user.
>
I'm probably starting to sound like a broken record, but we chartered TAPS
in 2014 to think about hiding bizarre transport attributes from
applications (among other things) using an abstract application programming
interface, and I note that
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ is now
targeting Propose Standard, and
https://tools.ietf.org/html/draft-ietf-taps-interface-09#section-5.2.13 is
about multipath.

Has anyone been looking at this? TAPS has been chugging away since before
QUIC was chartered, and certainly didn't want to do anything to slow QUICv1
work down, but now that QUICv1 is past Publication Requested, should we be?

Best,

Spencer