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

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 23 October 2020 23:02 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
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 6CFFD3A0A5E; Fri, 23 Oct 2020 16:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 5mZ7s1Ol7fvN; Fri, 23 Oct 2020 16:02:55 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 23EC53A0A50; Fri, 23 Oct 2020 16:02:55 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id bc23so3076507edb.5; Fri, 23 Oct 2020 16:02:55 -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=Jfl+kU9eCrC/G3iDjQ3cKJlzZsatdZ1SrhPBoypVZaU=; b=rpXJB6vXFQlFOcQZBSCO2JsuEKyGTqV67brkvOJownxRIMwp65po+bLI4vqf6WVZkv MQKg7ddLoL1YXZTjZQoToyvlIiLMZb0X5YgJ1wXtG5jx1jxVHN0w2Pe7vES23YXMFKkH zc8K6PBKKJ3FK5w4qz4Fn+kRXnbFa6xwuAdaIezFtSPH2gG5YtjktpwVW26kocwk81M2 r2Oh4gpIOcHiHUGoSPmcCa5RgMqFOkk8ppJaVfwg0a1zywu3XOb35CYGUkbHJRloKt0s 2xT1zzPuEXOzCfdfQGkPd8P45kr9FvFY4Lke6Bo9hPyhQA8NgqHoTBCFyiVHvomVEJj4 gS5Q==
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=Jfl+kU9eCrC/G3iDjQ3cKJlzZsatdZ1SrhPBoypVZaU=; b=PrGgR1N1fYwyw43awGlQZ5FJutQtpbreOU6euKAAytxP7ciUub51JQI6Mf/I0xCTjb iK1wB7hwgHS/j25iqXdT6PfWw2jxPMr5UxMi2bNPCdHFcM8gz3RK3Yr3vdFYss4Qg8D1 kgEWfKfXLVFJ0zIjAhj4fu1WXSkM4Bjrnu5Pb1hPWri+TEtcIucdNcfUDXXOHO4P75oj pemBEpiNH4jYyrl1IiLoRAPAOG/WCvJzYrHtGCIKasm88D+g8FiL8/fW0ZOGoMm4Koeh YajfZor/Bcgzt3YToGbkEdJRy0MbfNeHx8pXMfpByaER0KFwm3DCGs+50uEkEhF2ggat gOdg==
X-Gm-Message-State: AOAM5304p59NFcbbrBH5n6DV9cmBlalRZ+eiSxQMiQCyJK2hXSRmPMpZ Ih7DphHkqCUqbFIZsGIGhf6Ipfp7b6wbUMrtF8o=
X-Google-Smtp-Source: ABdhPJy80fXQdvp8U77zJLgP6pUPUCNTi1lNwSD1DNpLjsHTkybX7D+ycCfwUbaWPaJVB8riut2U+5uApsxo4TchuA0=
X-Received: by 2002:a05:6402:6ca:: with SMTP id n10mr4657079edy.273.1603494173397; Fri, 23 Oct 2020 16:02:53 -0700 (PDT)
MIME-Version: 1.0
References: <d84c82b1-fa67-4676-9ce2-d2a53d81b5f7@www.fastmail.com> <5741601d-7e67-898e-5840-70feceb994e9@uclouvain.be> <CALGR9oZW0s6c6+N+3R8bD17yPBPQa4E_cVOaTOSNTVQPYy6sUg@mail.gmail.com> <CAC8QAcditJ0nzdCNHOhi-1xtezoXb0u=hrGBWtZ3Cj3XP6CW4g@mail.gmail.com> <CALGR9oZfw5LqfPyZw6Yb8JTmuqi0prTL0f0yT9Rdq6oz5u51fg@mail.gmail.com> <ccbd3f9a-883e-6262-5735-2b9f25c6c6c4@zinks.de> <CALGR9oaw_-dbYSu5oN1Usvwr2h8wp-gvcmzx+0+2HJM-4Ac+4A@mail.gmail.com> <c09ff2f3-771b-11df-68f3-c690efa998c7@zinks.de> <CAKKJt-exKQa8o6Gn1=-SdDFQSrRGMtDsWJy62=RAQMD_T=P7ZQ@mail.gmail.com> <818d4f85-faa6-110c-7a94-441d7fe53166@huitema.net>
In-Reply-To: <818d4f85-faa6-110c-7a94-441d7fe53166@huitema.net>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Sat, 24 Oct 2020 00:02:41 +0100
Message-ID: <CALGR9oZzznU9qTc-T6xVYJOOT4cEhC8tunYK94x+HkQNmHFvEg@mail.gmail.com>
Subject: Re: Privacy considerations of multipath (Re: My BoF report: multipath)
To: Christian Huitema <huitema@huitema.net>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Roland Zink <roland@zinks.de>, QUIC WG <quic@ietf.org>, taps-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009ad74c05b25e940d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/il9ZWvG0nN0EAVPrsq0dkCWP1FY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2020 23:02:57 -0000

Maybe I just lack imagination but this is the part of the "put it in
transport and everyone gets it for free" line that I've not understood.

For example, Cloudflare's quiche implementation of QUIC is I/O agnostic,
you put application data in, it gives you QUIC packets back and you do with
them what you like. This flexibility means it's portable to lots of
platforms and applications. It's been able to slide into curl and nginx
implementations without a need to re-architect. More people using the
library means more diverse use cases and better coverage of protocol
features.

I don't know what a TAPS-quiche integration would look like or provide.
>From looking at
https://tools.ietf.org/html/draft-ietf-taps-interface-09#section-7.1.7 a
lot of the decisions are "implementation specific". I'd hazard a guess that
each implementation would make its own decisions and want to expose
different things to the application. And even if *it* didn't expose network
information, it would need access. So either it sits in the application and
uses a platform API that could've been used all along, or it gets compiled
into the platform and now we lose agility.

Cheers
Lucas