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 < [email protected]> 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 “explicit” 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 principle, > it is possible to choose the method or the combination of methods based on > the level of security that must be guaranteed. > > > > Regards, > > > > Giuseppe > > > > > > *From:* Explicit-meas [mailto:[email protected]] *On Behalf > Of *Spencer Dawkins at IETF > *Sent:* Tuesday, March 30, 2021 11:44 PM > *To:* Lubashev, Igor <[email protected]> > *Cc:* [email protected]; [email protected]; IETF IPPM WG ([email protected]) > <[email protected]>; [email protected]; HAMCHAOUI Isabelle > IMT/OLN <[email protected]>; Cociglio Mauro <mauro.cociglio= > [email protected]>; Ian Swett <ianswett= > [email protected]>; [email protected] > *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 <[email protected]> > wrote: > > Thank you, Ian and Spencer. > > > > Sorry for top posting (the thread could otherwise get a little long and I > am using Outlook…). > > > > 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 – upstream/downstream > loss. We do discuss privacy-related 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 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 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 “unknown third parties” on path every time they communicate > over the Internet. With the explicit measurements proposals, the set of > “unknown third parties” is not changing. What endpoints must 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 AND > 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-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 interesting bits of information without a user "opting > 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’s own systems?) – the primary goal of this > draft. > > > > Very best, > > > > - Igor > >
