From nobody Thu Apr 1 06:42:30 2021 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F413A1221 for ; Thu, 1 Apr 2021 06:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Gwf9Xd_KXQzR for ; Thu, 1 Apr 2021 06:42:22 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 B312E3A1222 for ; Thu, 1 Apr 2021 06:42:20 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id o16so1911955wrn.0 for ; Thu, 01 Apr 2021 06:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+2UkLBtPo+p0nwg8ZLw1r8AsJXAEkgdpwuCCaQFfmoI=; b=LnpvKkjpKlmlFdhDK5kEWik/JfRTwfoVVoH10RA3UdsIw5oV6c09KkIB19RSDiL7dD 8lOaKLk9PJXUMl4sTJKPa+Guo0g5NvB3AV0xwTESPmYOdOM9Ybh0eJf49CqRzpww9rLN Pie8EjX2NlkM3A3YN4v4jnZVw63kwcoHpl53RQHUdulze5UzjaXj6f+uNd5krtxRefxO RHvIGmJG5+zwdRE2vwmqNBgNIKOlpYEy0i2iE73D4ueFJH5QM3mfFwjt2Y7eMW5FQGdx AOdx4pctfeo7fcOlJSQkOqFsuuDkyO2EK9Dyd+rPhynWKnBVNyXD8/xUjQube+9M2q41 PjHQ== 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=+2UkLBtPo+p0nwg8ZLw1r8AsJXAEkgdpwuCCaQFfmoI=; b=gWm09KU44fQFX/93HH/ZO6DLyHmzFKroPUJcwAx/0n6FIcBSwpHRJHmqFXIfWFk7Q2 WA/JXP7kCbn4VPwvITOTRgM/dMlb2zW3QMX8X/7QmITmisYYmjBYyypXOaBZW3+5hUQs TYnXnlpZAyOUaIvR7zi1iKiPLgOM1Oi2sU3XH/gPeKmMwVU60q4VsvaDiQ7Z0tE7Finu zOsSuM+oh/vLY+VYzypWiWdcIlu63UoMToIhnRugLdBXR5CrviPRQ4M3b15V6CpXpM7u 2GZLcZKiOCpanY0i2kv6lGB6Hip8JbTbrV6ZzfHRQNN3FtG8O/1i4/aaJ0JS8xBGCx6X yTQw== X-Gm-Message-State: AOAM531rHjVWduucnOHzDXbhvYa2R2AAhF1B3ngxC6hscHgRwooVRZ1p 4oMzuAPPQuoTGpxtGiBlKQ5zJnS424cWfl5kJ2G+dw== X-Google-Smtp-Source: ABdhPJx/p7FXpCmShHZX/XV3hyf/mwlMPWhmUiqm4cr4/QkiY1A3xhHj1WOT3K3ZQS8viqEIfp5AmfN4W/50+AfCVTU= X-Received: by 2002:a05:6000:c7:: with SMTP id q7mr9861620wrx.356.1617284537521; Thu, 01 Apr 2021 06:42:17 -0700 (PDT) MIME-Version: 1.0 References: <8f60ffc8e0fd4376ba911c03f5c43039@TELMBXD14BA020.telecomitalia.local> <56398ea2e37a4a6ca53e85eb39add9a2@usma1ex-dag1mb5.msg.corp.akamai.com> <8332062d02c04f40af1ed3baef49dafc@usma1ex-dag1mb5.msg.corp.akamai.com> <5d60e177b8ee477fb6409a4a0d2af81a@huawei.com> In-Reply-To: <5d60e177b8ee477fb6409a4a0d2af81a@huawei.com> From: Ian Swett Date: Thu, 1 Apr 2021 09:42:05 -0400 Message-ID: To: Giuseppe Fioccola Cc: Spencer Dawkins at IETF , "Lubashev, Igor" , "explicit-meas@ietf.org" , "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , "alexandre.ferrieux@orange.com" , "HAMCHAOUI Isabelle IMT/OLN" , Cociglio Mauro , "quic@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005c896905bee96659" Archived-At: Subject: Re: [tsvwg] [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 13:42:27 -0000 --0000000000005c896905bee96659 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Igor, the security considerations are definitely helpful. I'm not sure other working groups in the IETF(thinking QUIC) will find that sufficient, but I agree that I don't have any specific concerns as an individual. I also agree that scoping this to a specific signal(loss) makes the privacy implications possible to reason about, vs PLUS which was much more expansive. Ian On Wed, Mar 31, 2021 at 1:49 PM Giuseppe Fioccola < giuseppe.fioccola@huawei.com> wrote: > Hi Spencer, Igor, Ian, All, > > It is interesting to look at the similar discussion for PLUS back in 2016 > and the related concerns about endpoints sending information to network > entities. > > On the one hand, this draft describes several =E2=80=9Cexplicit=E2=80=9D = measurement > methods which send information to an on-path observer. But, on the other > hand, it is worth mentioning that each one of the methods has different > privacy implications. Different kinds of information are exposed to the > on-path observer depending on which method is chosen. > > For example the Spin bit exposes an end-to-end delay metric while the > sQuare bit exposes only endpoint-to-observer loss metric. So, in principl= e, > it is possible to choose the method or the combination of methods based o= n > the level of security that must be guaranteed. > > > > Regards, > > > > Giuseppe > > > > > > *From:* Explicit-meas [mailto:explicit-meas-bounces@ietf.org] *On Behalf > Of *Spencer Dawkins at IETF > *Sent:* Tuesday, March 30, 2021 11:44 PM > *To:* Lubashev, Igor > *Cc:* explicit-meas@ietf.org; tsvwg@ietf.org; IETF IPPM WG (ippm@ietf.org= ) > ; alexandre.ferrieux@orange.com; HAMCHAOUI Isabelle > IMT/OLN ; Cociglio Mauro 40telecomitalia.it@dmarc.ietf.org>; Ian Swett 40google.com@dmarc.ietf.org>; quic@ietf.org > *Subject:* Re: [Explicit-meas] Comparing Alternate Marking and Explicit > Flow Measurements (Spin bit, ...) > > > > Hi, Igor, > > > > On Tue, Mar 30, 2021 at 11:11 AM Lubashev, Igor > wrote: > > Thank you, Ian and Spencer. > > > > Sorry for top posting (the thread could otherwise get a little long and I > am using Outlook=E2=80=A6). > > > > Ian, we did consider privacy implications of the markings. Because all > markings and internal counters are completely reset when there is a CID > change, we did not see the markings compromise linkability during > migrations. Otherwise, since the markings are minimal, we see them only > disclosing the information they are meant to disclose =E2=80=93 upstream/= downstream > loss. We do discuss privacy-related implications of disclosing > upstream/downstream loss in > https://datatracker.ietf.org/doc/html/draft-ferrieuxhamchaoui-quic-lossbi= ts-03#section-8. > However, the discussion in the ID is theoretical and is not a result of > large global study whose results are confirmed by independent third > parties. I would be happy to collaborate on this with an interested PhD > student or another researcher. > > > > Spencer, I will review the PLUS minutes. In a setup when endpoints are > sending information to unknown third parties, my immediate concern is les= s > with the third parties being unknown and more with the extent of the > information sent being unknown. After all, endpoints are already sending > information to =E2=80=9Cunknown third parties=E2=80=9D on path every time= they communicate > over the Internet. With the explicit measurements proposals, the set of > =E2=80=9Cunknown third parties=E2=80=9D is not changing. What endpoints m= ust focus on is > the information content of the signal. In any case, the abovementioned > draft allows for endpoints to decide whether this signal is being sent AN= D > ensures that a certain portion of all connections does not use this > signaling (so connections explicitly opting out do not stand out). > > > > This was exactly the concern PLUS tripped over (IMO). > > > > The concern being expressed was that the PLUS format allocated a > fixed-length field (IIRC) that did not define every bit in the fixed-leng= th > field, so in the mind of the SEC types, a (let's just say it out loud) > mobile operator who also sends you your phone, so controls both ends, cou= ld > start sending itself interesting bits of information without a user "opti= ng > in", OR knowing that they should be trying to "opt out". > > > > PLUS happened at IETF 96 (in 2016), and I'm guessing that we are doing > more with automated updates in 2021 than we were doing in 2016 (also the > year QUIC was chartered, although Google had been using gQUIC for several > years previously, so "change the behavior after a browser upgrade" was on > our horizon). > > > > One didn't have to be a mobile operator mailing you a cell phone to add > interesting behaviors without you, the user, realizing that. > > > > Brian and Mirja would remember the details better (they were at the front > of the room, while I was in the back, where ADs usually live). > > > > But that's what I was trying to describe. I hope it makes sense. And good > luck. This was important work that we didn't know how to charter at the > time (again, IMO). > > > > Best, > > > > Spencer > > > > Delivery of qlog to specific operators is possible, but it does not help > much to locate the source of the loss/delay (upstream of the operator? > downstream? in the operator=E2=80=99s own systems?) =E2=80=93 the primary= goal of this > draft. > > > > Very best, > > > > - Igor > > --0000000000005c896905bee96659 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Igor, the security considerations are definitely he= lpful.=C2=A0 I'm not sure other working groups in the IETF(thinking QUI= C) will find that sufficient, but I agree that I don't have any specifi= c concerns as an individual.

I also agree that scoping t= his to a specific signal(loss) makes the privacy implications possible to r= eason=C2=A0about, vs PLUS which was much more expansive.

Ian

On Wed, Mar 31, 2021 at 1:49 PM Giuseppe Fioccola <giuseppe.fiocc= ola@huawei.com> wrote:

Hi Spencer, Igor, Ian, All,

It is interesting to look at the similar dis= cussion for PLUS back in 2016 and the related concerns about endpoints send= ing information to network entities.

On the one hand, this draft describes severa= l =E2=80=9Cexplicit=E2=80=9D measurement methods which send information to = an on-path observer. But, on the other hand, it is worth mentioning that each one of the methods has different privacy implications= . Different kinds of information are exposed to the on-path observer depend= ing on which method is chosen.

For example the Spin bit exposes an end-to-e= nd delay metric while the sQuare bit exposes only endpoint-to-observer loss= metric. So, in principle, it is possible to choose the method or the combination of methods based on the level of s= ecurity that must be guaranteed.

=C2=A0

Regards,

=C2=A0

Giuseppe

=C2=A0

=C2=A0

From: Explicit-meas [mailto:explicit-meas-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, March 30, 2021 11:44 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: expl= icit-meas@ietf.org; tsvwg@ietf.org; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>; alexandre.ferrieux@orange.com; HAMCHAOUI Isa= belle IMT/OLN <isabelle.hamchaoui@orange.com>; Cociglio Mauro <mauro= .cociglio=3D40telecomitalia.it@dmarc.ietf.org>; Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; quic@ietf.org
Subject: Re: [Explicit-meas] Comparing Alternate Marking and Explici= t Flow Measurements (Spin bit, ...)

=C2=A0

Hi, Igor,=C2=A0

=C2=A0

On Tue, Mar 30, 2021 at 11:11 AM Lubashev, Igor <= ilubashe@akamai.co= m> wrote:

Thank you, Ian and Spencer.

=C2=A0

Sorry for top posting (the thread could otherwise ge= t a little long and I am using Outlook=E2=80=A6).

=C2=A0

Ian, we did consider privacy implications of the mar= kings. Because all markings and internal counters are completely reset when= there is a CID change, we did not see the markings compromise linkability during migrations. Otherwise, since the markings ar= e minimal, we see them only disclosing the information they are meant to di= sclose =E2=80=93 upstream/downstream loss.=C2=A0 We do discuss privacy-rela= ted implications of disclosing upstream/downstream loss in https://datatracker.ietf.org/doc/html/draft-ferrieuxhamchaoui-quic-lossbits= -03#section-8. However, the discussion in the ID is theoretical and is = not a result of large global study whose results are confirmed by independe= nt third parties. I would be happy to collaborate on this with an interested PhD student or another researche= r.

=C2=A0

Spencer, I will review the PLUS minutes. In a setup = when endpoints are sending information to unknown third parties, my immedia= te concern is less with the third parties being unknown and more with the extent of the information sent being unknown. After all,= endpoints are already sending information to =E2=80=9Cunknown third partie= s=E2=80=9D on path every time they communicate over the Internet. With the = explicit measurements proposals, the set of =E2=80=9Cunknown third parties=E2=80=9D is not changing. What endpoints must focus on is th= e information content of the signal. In any case, the abovementioned draft = allows for endpoints to decide whether this signal is being sent AND ensure= s that a certain portion of all connections does not use this signaling (so connections explicitly opting out do not s= tand out).

=C2=A0

This was exactly the concern PLUS tripped over (IMO)= .=C2=A0

=C2=A0

The concern being expressed was that the PLUS format= allocated a fixed-length field (IIRC) that did not define every bit in the= fixed-length field, so in the mind of the SEC types, a (let's just say= it out loud) mobile operator who also sends you your phone, so controls both ends, could start sending itself in= teresting bits of information without a user "opting in", OR know= ing that they should be trying to "opt out".=C2=A0<= /p>

=C2=A0

PLUS happened at IETF 96 (in 2016), and I'm gues= sing that we are doing more with automated updates in 2021 than we were doi= ng in 2016 (also the year QUIC=C2=A0was chartered, although Google had been= using gQUIC for several years previously, so "change the behavior after a browser upgrade" was on our hori= zon).=C2=A0

=C2=A0

One didn't have to be a mobile operator mailing = you a cell phone to add interesting behaviors without you, the user, realiz= ing that.=C2=A0

=C2=A0

Brian and Mirja would remember the details better (t= hey were at the front of the room, while I was in the back, where ADs usual= ly live).=C2=A0

=C2=A0

But that's what I was trying to describe. I hope= it makes sense. And good luck. This was important work that we didn't = know how to charter at the time (again, IMO).=C2=A0

=C2=A0

Best,

=C2=A0

Spencer

=C2=A0

Delivery of qlog to specific operators is possible, = but it does not help much to locate the source of the loss/delay (upstream = of the operator? downstream? in the operator=E2=80=99s own systems?) =E2=80=93 the primary goal of this draft.

=C2=A0

Very best,

=C2=A0

  • Igor
--0000000000005c896905bee96659--