From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 B23633B29E; Thu, 21 Oct 2021 02:19:31 -0400 (EDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mdRQG-006Xhq-Nt; Thu, 21 Oct 2021 08:19:28 +0200 Received: from ti0182q160-6611.bb.online.no ([95.34.115.34] helo=[192.168.1.7]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1mdRQF-0000Ty-33; Thu, 21 Oct 2021 08:19:28 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9C12B581-7BA2-4C89-97F9-D989151D2900" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Thu, 21 Oct 2021 08:19:25 +0200 In-Reply-To: <9C553AC1-B470-4887-B770-9FD23D586889@apple.com> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Rpm , Make-Wifi-fast , Keith Winstein To: Omer Shapira 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> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 95.34.115.34 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.115.34; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: FCCEAF942905CE8F59A5E4294A8FEDB26514333B 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 06:19:32 -0000 --Apple-Mail=_9C12B581-7BA2-4C89-97F9-D989151D2900 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 21, 2021, at 1:20 AM, Omer Shapira = wrote: >=20 >=20 >=20 >> On Oct 20, 2021, at 3:54 AM, Michael Welzl via Rpm = > wrote: >>=20 >>=20 >>=20 >>> On 20 Oct 2021, at 12:44, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >>>=20 >>> Michael Welzl > = writes: >>>=20 >>>>> On 20 Oct 2021, at 11:44, Toke H=C3=B8iland-J=C3=B8rgensen = > wrote: >>>>>=20 >>>>> Michael Welzl > = writes: >>>>>=20 >>>>>> Am I being naive? Why can't such an ARQ proxy be deployed? Is it = just >>>>>> because standardizing this negotiation is too difficult, or would = it >>>>>> also be too computationally heavy for an AP perhaps, at high = speeds? >>>>>=20 >>>>> Immediate thought: this won't work for QUIC >>>>=20 >>>> .... as-is, true, though MASQUE is still being defined. Is this an >>>> argument for defining it accordingly? >>>=20 >>> MASQUE is proxying, right? Not quite sure if it's supposed to be = also >>> MITM'ing the traffic? >>=20 >> Wellllll.... I'm not 100% sure. If I understood it correctly, ideas = on the table would have it do this in case of tunneling TCP/IP over = QUIC, but not in case of QUIC itself - but to me, this isn't necessarily = good design? Because: =3D> >>=20 >>=20 >>> In any case, it would require clients to negotiate >>> a proxy session with the AP and trust it to do that properly? >>=20 >> =3D> Yes. >>=20 >>=20 >>> This may >>> work for a managed setup in an enterprise, but do you really expect = me >>> to be OK with any random access point in a coffee shop being a MITM? >>=20 >> MiTM is a harsh term for just being able to ACK on my behalf. Some = capabilities could be defined, as long as they're indeed defined = clearly. >> So I don't see why "yes, you can ACK my packets on my behalf when you = get a LL-ACK from me" is MiTM'ing. I believe that things are now all = being lumped together, which may be why the design may end up being too = prohibitive. >=20 > Yet, the QUIC protocol makes ACKs part of the protected payload. = Having 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 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? >> Someone showed me a paper which lets such proxies ACK by reflecting = parts of the encrypted packet... I don't remember the title now and = don't have a pointer, but: it can be done anyway (if the sender is able = to parse these ACKs). Not being a part of the standard means nobody will = implement such a sender though. >=20 >=20 > Michael, it sounds to me that what you are describing is something = that belongs to the datalink layer (LL or MAC), maybe with an addition = of namespaces (at the MAC layer) which can be aligned with the streams / = connections. However, once we get into QUIC, the assumption that we are = free to meddle with the ACK frames is problematic. I know it is, but I doubt that this is good design. Here you have an = enforced inability for cross-layer interaction (which could be done nice = and clean, with a vertical interface) due to the enforcement of e2e = transport, with everything encrypted. This connects to the question in = another email: >>> Immediate thought: this won't work for QUIC >>=20 >> .... as-is, true, though MASQUE is still being defined. Is this an = argument for defining it accordingly? >=20 > Can you elaborate?=20 If I understood it correctly, MASQUE will (always? I=E2=80=99m not sure) = maintain an end-to-end connection including encryption of headers, = preventing ACKs, and preventing the division of congestion control at = the proxy. I=E2=80=99m certain that this poor design, especially since = MASQUE proxies are not transparent - so why not trust them to do these = things right? Yet, I=E2=80=99m also quite convinced that trying to argue against any = of the security mechanisms in QUIC will make me age faster, and I = cherish the years that I still have left :-) Anyway, if mmWave links become more prevalent at some point in the = future, I=E2=80=99ll be happy that we still have TCP as well. Already, = I=E2=80=99ve seen presentations of e.g. satellite systems working better = with TCP than with QUIC due to the proxying capability=E2=80=A6 is this = a big surprise? As LL capacity fluctuations become more prevalent, and = grow in magnitude, e2e mechanisms will become worse. Cheers, Michael --Apple-Mail=_9C12B581-7BA2-4C89-97F9-D989151D2900 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 21, 2021, at 1:20 AM, Omer Shapira <omer_shapira@apple.com> wrote:



On Oct 20, 2021, at 3:54 AM, Michael Welzl via Rpm <rpm@lists.bufferbloat.net> wrote:



On 20 Oct 2021, at 12:44, Toke = H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:

Michael Welzl <michawe@ifi.uio.no> writes:

On 20 Oct 2021, at 11:44, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:

Michael Welzl <michawe@ifi.uio.no> = writes:

Am I being naive? Why can't such an ARQ proxy be deployed? Is = it just
because standardizing this negotiation is too = difficult, or would it
also be too computationally heavy = for an AP perhaps, at high speeds?

Immediate thought: this won't work for QUIC

.... as-is, true, though MASQUE = is still being defined. Is this an
argument for defining = it accordingly?

MASQUE is = proxying, right? Not quite sure if it's supposed to be also
MITM'ing the traffic?

Wellllll.... I'm not 100% sure. = If I understood it correctly, ideas on the table would have it do this = in case of tunneling TCP/IP over QUIC, but not in case of QUIC itself - = but to me, this isn't necessarily good design? Because: =3D>


In = any case, it would require clients to negotiate
a proxy = session with the AP and trust it to do that properly?

=3D> Yes.


This may
work for a = managed setup in an enterprise, but do you really expect me
to be OK with any random access point in a coffee shop being = a MITM?

MiTM is a harsh term for just being able to ACK on my behalf. = Some capabilities could be defined, as long as they're indeed defined = clearly.
So I don't see why "yes, you can ACK my packets on my behalf = when you get a LL-ACK from me" is MiTM'ing.  I believe that things = are now all being lumped together, which may be why the design may end = up being too prohibitive.

Yet, the QUIC protocol makes ACKs part of the protected = payload. Having 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 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?


Someone = showed me a paper which lets such proxies ACK by reflecting parts of the = encrypted packet... I don't remember the title now and don't have a = pointer, but: it can be done anyway (if the sender is able to parse = these ACKs). Not being a part of the standard means nobody will = implement such a sender though.


Michael, it sounds to me that what you are describing is = something that belongs to the datalink layer (LL or MAC), maybe with an = addition of namespaces (at the MAC layer) which can be aligned with the = streams / connections. However, once we get into QUIC, the assumption = that we are free to meddle with the ACK frames is = problematic.

I know it is, but I doubt that this is good = design. Here you have an enforced inability for cross-layer interaction = (which could be done nice and clean, with a vertical interface) due to = the enforcement of e2e transport, with everything encrypted. This = connects to the question in another email:


Immediate thought: this won't work for QUIC

.... as-is, true, though MASQUE = is still being defined. Is this an argument for defining it = accordingly?

Can you = elaborate? 

If I understood it correctly, MASQUE will (always? = I=E2=80=99m not sure) maintain an end-to-end connection including = encryption of headers, preventing ACKs, and preventing the division of = congestion control at the proxy. I=E2=80=99m certain that this poor = design, especially since MASQUE proxies are not transparent - so why not = trust them to do these things right?

Yet, I=E2=80=99m also quite convinced that trying = to argue against any of the security mechanisms in QUIC will make me age = faster, and I cherish the years that I still have left =  :-)

Anyway, if mmWave links = become more prevalent at some point in the future, I=E2=80=99ll be happy = that we still have TCP as well. Already, I=E2=80=99ve seen presentations = of e.g. satellite systems working better with TCP than with QUIC due to = the proxying capability=E2=80=A6 is this a big surprise?  As LL = capacity fluctuations become more prevalent, and grow in magnitude, e2e = mechanisms will become worse.

Cheers,
Michael

= --Apple-Mail=_9C12B581-7BA2-4C89-97F9-D989151D2900--