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
- My BoF report: multipath Martin Thomson
- Re: My BoF report: multipath Christian Huitema
- Re: My BoF report: multipath Spencer Dawkins at IETF
- Re: My BoF report: multipath Olivier Bonaventure
- Re: My BoF report: multipath Christian Huitema
- RE: My BoF report: multipath Flinck, Hannu (Nokia - FI/Espoo)
- Re: My BoF report: multipath Lucas Pardue
- Re: My BoF report: multipath Spencer Dawkins at IETF
- Re: My BoF report: multipath Behcet Sarikaya
- Re: My BoF report: multipath Lucas Pardue
- Re: My BoF report: multipath Roland Zink
- Privacy considerations of multipath (Re: My BoF r… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Roland Zink
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Christian Huitema
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Eric Kinnear
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: My BoF report: multipath Jana Iyengar
- Re: Privacy considerations of multipath (Re: My B… Eric Kinnear
- Re: Privacy considerations of multipath (Re: My B… Ian Swett
- Re: Privacy considerations of multipath (Re: My B… Mirja Kuehlewind
- Re: Privacy considerations of multipath (Re: My B… Behcet Sarikaya
- Re: Privacy considerations of multipath (Re: My B… Ian Swett
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue