From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.cs.Stanford.EDU (smtp2.cs.stanford.edu [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 945763B29E; Thu, 21 Oct 2021 03:58:05 -0400 (EDT) Received: from mail-oi1-f182.google.com ([209.85.167.182]:46049) by smtp2.cs.Stanford.EDU with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mdSxf-0000Zf-8g; Thu, 21 Oct 2021 00:58:04 -0700 Received: by mail-oi1-f182.google.com with SMTP id z126so12713953oiz.12; Thu, 21 Oct 2021 00:58:03 -0700 (PDT) X-Gm-Message-State: AOAM530c5MQiY/YJSmycqGTca/uiC7nvU5Z6ouuraQoZEyz1Ev25c9TD NaHc/75PGFlC/YtsO++cfTd/NBUKMQWq1+1CZQ== X-Google-Smtp-Source: ABdhPJxle5IIzdgJQmPyPiC+X7tcSfjb6AEmlOGdLp70v+5jMKTCCyRA54NaT3CvZnqwzEQOwMzvoTbiSB7+66zazpw= X-Received: by 2002:a05:6808:1383:: with SMTP id c3mr772327oiw.80.1634803082856; Thu, 21 Oct 2021 00:58:02 -0700 (PDT) MIME-Version: 1.0 References: <4BD0AC02-62FB-4AE4-B83B-BAF5CCEA2B24@ifi.uio.no> <87lf2of2sl.fsf@toke.dk> <09884015-6428-4402-BE61-9091006D1FB8@ifi.uio.no> <87ee8gf013.fsf@toke.dk> <9C553AC1-B470-4887-B770-9FD23D586889@apple.com> <178233EF-5125-415E-9D05-A25729FC1413@ifi.uio.no> In-Reply-To: <178233EF-5125-415E-9D05-A25729FC1413@ifi.uio.no> From: Keith Winstein Date: Thu, 21 Oct 2021 00:57:25 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Michael Welzl Cc: Omer Shapira , Rpm , Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000080bf705ced841f4" X-Spam-Score: -1.0 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin on smtp2.cs.Stanford.EDU X-Scan-Signature: a17fa95ecc931ea5becae2cea4d17935 Subject: Re: [Rpm] [Make-wifi-fast] tack - reducing acks on wlans X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 07:58:05 -0000 --000000000000080bf705ced841f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems like there is probably some design available that decouples (1) the end-to-end encrypted transport protocol from (2) the optional network assistance, and allows the two protocols to evolve semi-separately without mutual trust (and giving the endpoints the option of whether or not to react to volunteered network assistance). E.g., just to sketch out a straw person: - Protocol 1: The end-to-end protocol defines a unique "public ID" for each datagram. This could be implicit, e.g. "the SHA256/64 hash of the encrypted UDP datagram," or QUIC could start exposing its Packet Numbers (authenticating them but not encrypting them). - Protocol 2: An intermediary that wants to volunteer assistance (e.g. a Wi-Fi AP) can send its own messages to either endpoint, ideally by appending them to the end-to-end payload for datagrams already in flight= , or by generating and sending its own datagrams. These messages would be defined by a separate protocol spec and could evolve separately. - Protocol 2: You could imagine a useful message for protocol #2 might express something like, "I'm a Wi-Fi AP with public key

, and I'm ACK= ing the datagram you sent to destination that had public ID . I prom= ise I will deliver that datagram soon to destination . Do you want me to keep sending these?" (and maybe the endpoint is like, "Sure, keep sendin= g those," or, "Not interested, please stop.") - Protocol 1: The endpoints can now decide what to do with this extra info. For example, they could decide that the endpoint receiver should switch to super delayed ACKs itself (maybe one every N seconds or M megabytes), and the sender will trust the Protocol 2 ACKs for congestion-control and retransmission purposes, while still using the Protocol 1 ACKs for ultimate reliability. (I.e. the sender won't discard outstanding data from a reliable stream until it's been ACKed by the endpoint.) - If the Protocol 2 ACKs seem to be lying about receiving something that never gets to the endpoint, the endpoints can detect this (since they st= ill have occasional end-to-end ACKs) and decide never to trust the intermedi= ary again and go back to previous behavior. It would be nice not to give up the benefits of end-to-end authenticated ACKs, while allowing intermediaries to provide most of the benefits we get with TCP acceleration, and also without tightly coupling these protocols to prevent them from evolving separately. I think it is probably possible, at least for this kind of use case. But I don't think there's much of a will to do this in practice; it's not something the major traffic sources seem particularly interested in afaik. -Keith On Thu, Oct 21, 2021 at 12:18 AM Michael Welzl wrote: > Hi again, > > A clarification about one point here - I had overlooked =E2=80=9Cclose-by= =E2=80=9D, now I > think I understand the attack: this is a host on the same WiFi network, > spoofing packets, and sending NACKs (or DupACKs, for TCP, probably) - rig= ht? > > See below: > > Yet, the QUIC protocol makes ACKs part of the protected payload. Having > the ACKs protected by the frame protection allows ensuring that nobody ha= d > meddled with the ACKs - and by this to avoid an entire class of attacks > that put a close-by endpoint which NACKs segments. > > > Were such attacks a real problem before QUIC was designed? And besides, > aren=E2=80=99t MASQUE proxies visible and authenticated? > > > So this seems not to be a matching answer for the attack that I now think > you have in mind. > Here=E2=80=99s another answer: this is solved by encryption between the = host and > the MASQUE proxy. That=E2=80=99s okay, I=E2=80=99m not questioning this p= art of the > design. What I say is: the MASQUE proxy itself shouldn=E2=80=99t have to= relay > e2e-encrypted transport headers (which I *believe* it does, but I really > still have some catching-up to do). (and of course I also don=E2=80=99t = speak > against the e2e encryption of payload!) > > Cheers, > Michael > > --000000000000080bf705ced841f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It seems like there is probably some design available= that decouples (1) the end-to-end encrypted transport protocol from (2) th= e optional network assistance, and allows the two protocols to evolve semi-= separately without mutual trust (and giving the endpoints the option of whe= ther or not to react to volunteered network assistance).

=
E.g., just to sketch out a straw person:
  • Proto= col 1: The end-to-end protocol defines a unique "public ID" for e= ach datagram. This could be implicit, e.g. "the SHA256/64 hash of the = encrypted UDP datagram," or QUIC could start exposing its Packet Numbe= rs (authenticating them but not encrypting them).
  • Protocol 2: An in= termediary that wants to volunteer assistance (e.g. a Wi-Fi AP) can send it= s own messages to either endpoint, ideally by appending them to the end-to-= end payload for datagrams already in flight, or by generating and sending i= ts own datagrams. These messages would be defined by a separate protocol sp= ec and could evolve separately.
  • Protocol 2: You could imagine a use= ful message for protocol #2 might express something like, "I'm a W= i-Fi AP with public key <p>, and I'm ACKing the datagram you sent= to destination <d> that had public ID <id>. I promise I will d= eliver that datagram soon to destination <d>. Do you want me to keep = sending these?" (and maybe the endpoint is like, "Sure, keep send= ing those," or, "Not interested, please stop.")
  • = Protocol 1: The endpoints can now decide what to do with this extra info. F= or example, they could decide that the endpoint receiver should switch to s= uper delayed ACKs itself (maybe one every N seconds or M megabytes), and th= e sender will trust the Protocol 2 ACKs for congestion-control and retransm= ission purposes, while still using the Protocol 1 ACKs for ultimate reliabi= lity. (I.e. the sender won't discard outstanding data from a reliable s= tream until it's been ACKed by the endpoint.)
  • If the Protocol 2= ACKs seem to be lying about receiving something that never gets to the end= point, the endpoints can detect this (since they still have occasional end-= to-end ACKs) and decide never to trust the intermediary again and go back t= o previous behavior.
It would be nice not to give up the = benefits of end-to-end authenticated ACKs, while allowing intermediaries to= provide most of the benefits we get with TCP acceleration, and also withou= t tightly coupling these protocols to prevent them from evolving separately= . I think it is probably possible, at least for this kind of use case. But = I don't think there's much of a will to do this in practice; it'= ;s not something the major traffic sources seem particularly interested in = afaik.

-Keith

On Thu, Oct 21, 2= 021 at 12:18 AM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi again,

A clarif= ication about one point here - I had overlooked =E2=80=9Cclose-by=E2=80=9D,= now I think I understand the attack: this is a host on the same WiFi netwo= rk, spoofing packets, and sending NACKs (or DupACKs, for TCP, probably) - r= ight?

See below:

Yet, the QUIC protocol makes ACKs part of the protected payload. Ha= ving the ACKs protected by the frame protection allows ensuring that nobody= had meddled with the ACKs - and by this to avoid an entire class of attack= s that put a close-by endpoint which NACKs segments.

Were such attacks a real problem be= fore QUIC was designed?=C2=A0 And besides, aren=E2=80=99t MASQUE proxies vi= sible and authenticated?

= So this seems not to be a matching answer for the attack that I now think y= ou have in mind.
Here=E2=80=99s another answer: =C2=A0this is sol= ved by encryption between the host and the MASQUE proxy. That=E2=80=99s oka= y, I=E2=80=99m not questioning this part of the design.=C2=A0 What I say is= : the MASQUE proxy itself shouldn=E2=80=99t have to relay e2e-encrypted tra= nsport headers (which I *believe* it does, but I really still have some cat= ching-up to do). =C2=A0(and of course I also don=E2=80=99t speak against th= e e2e encryption of payload!)

Cheers,
Mi= chael

--000000000000080bf705ced841f4--