From nobody Fri Oct 23 15:11:05 2020 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE8B3A0994; Fri, 23 Oct 2020 15:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXDC_HCR8N7A; Fri, 23 Oct 2020 15:11:01 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FE63A0990; Fri, 23 Oct 2020 15:11:01 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id l15so2436551ybp.2; Fri, 23 Oct 2020 15:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HKyHaZE9rHBvGZPHlx1+E8+sUW6tCS+s+YfZ3sFJH+U=; b=S1tzkCAEeUfl3lbWiVjSFfOd260is03YY5o2EeQY6cQlIS8dqLaf8t/2o9Y4Nv1t1g 24wWP/ZpranPb5ExB3yzjJokPHTj4AhL2Pm7xIBz17r28K1k5G25WRLppM8RzNBHj3UJ OCEXfDvtQd54N1S761EKU1p0WmFqgDNU9AH1JKIgq8xqs6e33hIGsIZtLb2U/8IGaUsd YQ+bB6I3bZO/Aiv8/kjYSH+N+WrbSYToJeoF7/CYY9ExyqRBPhP7J0h09jbMIOuLd6go zsLMkhrRx8JWXDJQzEaD38JxcUVjCW6SB7GK7kfM42dvJAJqSID/Sfps9xblGnpu+5/K 5h7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HKyHaZE9rHBvGZPHlx1+E8+sUW6tCS+s+YfZ3sFJH+U=; b=G+nRf3ZpoOeYBJ1v+5BzOPP6mn+L0CBvdl/sdRhntiZJrf1OUqA2YYY1dU2gb5OeV2 cBIe1KrRnQk06JxLl54QKeQ+BAcWjAyPWJeD3K/m+D5nwxnkAJdMaxbUxVYieYoDRqHb Eg/oE/+nxMXFFEbeasqiIoRESIrfUZoDMnfFE6tlnmjMzWwyleD+YZriLDsYHG6aavzN /jj69rY69AngwCjcR0Z7zqk5bh85i8HUpp1zBMFeeq32vMPCegKqbXlI/IyNC4rCe8XX KGEmU+5/hen5l3i12ZCA1kEWA6PKsLCw4jsgtXzag6sQJ3FqIQEEQCaiYYYnB84BIl6I FpaQ== X-Gm-Message-State: AOAM532UBQ0nWQa5Aa926HJeV4wNLR8uPX3mvV/VTHvds/EghnUz/7Xq nr0URE9jwLynUxhv7mEZFSMMRcLI9pt8tzOtfZJqW2mY+PI= X-Google-Smtp-Source: ABdhPJw1VV0wvnZ9cGlj/PP+JjHRxyz57mwjzfHiyWwKzo5eDKou+oEVIUmjaT5eHLXOuEIMInSSuXF0Qtd4uZCvjls= X-Received: by 2002:a25:cc89:: with SMTP id l131mr5834703ybf.154.1603491060714; Fri, 23 Oct 2020 15:11:00 -0700 (PDT) MIME-Version: 1.0 References: <5741601d-7e67-898e-5840-70feceb994e9@uclouvain.be> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 23 Oct 2020 17:10:34 -0500 Message-ID: Subject: Re: Privacy considerations of multipath (Re: My BoF report: multipath) To: Roland Zink Cc: Lucas Pardue , QUIC WG , taps-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000001325f205b25ddb57" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 22:11:03 -0000 --0000000000001325f205b25ddb57 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 23, 2020 at 4:44 PM Roland Zink 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 --0000000000001325f205b25ddb57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 23, 2020 at 4:44 PM Rolan= d Zink <roland@zinks.de> wrote= :
=20 =20 =20

Hi Lucas,


1)=C2=A0 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 T= APS in 2014 to think about hiding bizarre transport attributes from applica= tions (among other things) using an abstract application programming interf= ace, and I note that=C2=A0https://datatracker.ietf.org/doc/draft-ietf-taps-int= erface/ is now targeting Propose Standard, and=C2=A0https://to= ols.ietf.org/html/draft-ietf-taps-interface-09#section-5.2.13 is about = multipath.=C2=A0

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

Best,

Spencer
--0000000000001325f205b25ddb57--