Re: [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)

[Ian Swett <[e-mail]>]

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 <
[e-mail]> 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:[e-mail]] *On Behalf
> Of *Spencer Dawkins at IETF
> *Sent:* Tuesday, March 30, 2021 11:44 PM
> *To:* Lubashev, Igor <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; IETF IPPM WG ([e-mail])
> <[e-mail]>; [e-mail]; HAMCHAOUI Isabelle
> IMT/OLN <[e-mail]>; Cociglio Mauro <mauro.cociglio=
> [e-mail]>; Ian Swett <ianswett=
> [e-mail]>; [e-mail]
> *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 <[e-mail]>
> 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
>
>