From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (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 CD5773B29E; Wed, 20 Oct 2021 19:20:10 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19KNHX77015914; Wed, 20 Oct 2021 16:20:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=UWRT9RotS7f6Lm8NxoiX1cmPWiN2D1gPAA8C/1VJRDY=; b=CKHxhBayVSFS9Csi6inP69Vg7sS62UTsZ6kKDsHaiyCi7ZVQK2ZDDOBqUHRNudeFgor3 deOgjFmyWWPWqAU/2pazMQ3/WlvJFOzrX6DPNjYHp00Dk12FzCdUVtxoEGo6ELtQt4nR YyvC6OHBWnFZiTQrn6UbF8KqqKGSSiAynOOxDyaaFqLESp/QeYXBS0i66JoP9L3mg8yb bpmxnU/ReE7KIqEq+nGr7JQtgjCD0BzFVjTa1/5Ya0BmLmRLHngzadd64x3wMzW6P22c ptioN0QsPZbDPn314yBZSc+eyF6NdrKHT7s883wsG64OGxGNrh7DBQkvfMn1JHAOH8Dm EQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3bsjdryrua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Oct 2021 16:20:03 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R1A00153U5ERE60@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 20 Oct 2021 16:20:02 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1A00O00U2WK900@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 20 Oct 2021 16:20:02 -0700 (PDT) X-Va-A: X-Va-T-CD: 91949cb67ad5a17194231cf3cf1e09f7 X-Va-E-CD: d3a48291620af73eb9fcea673981ba5f X-Va-R-CD: 5cdfdcba50b9d9b947b9f24c432665be X-Va-CD: 0 X-Va-ID: 82fa2433-f508-41d7-866e-ee3b2ec25bce X-V-A: X-V-T-CD: 91949cb67ad5a17194231cf3cf1e09f7 X-V-E-CD: d3a48291620af73eb9fcea673981ba5f X-V-R-CD: 5cdfdcba50b9d9b947b9f24c432665be X-V-CD: 0 X-V-ID: 13428cd6-c7ca-4e2c-9e1f-6905b652c96a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_06:2021-10-20, 2021-10-20 signatures=0 Received: from smtpclient.apple (unknown [17.11.42.216]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1A010I9U5DYT00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 20 Oct 2021 16:20:02 -0700 (PDT) From: Omer Shapira Message-id: <9C553AC1-B470-4887-B770-9FD23D586889@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_43A60DE9-275C-4743-A765-E05B92CA81E3" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3696.80.2\)) Date: Wed, 20 Oct 2021 16:20:01 -0700 In-reply-to: Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Rpm , Make-Wifi-fast , Keith Winstein To: Michael Welzl 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> X-Mailer: Apple Mail (2.3696.80.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_06:2021-10-20, 2021-10-20 signatures=0 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: Wed, 20 Oct 2021 23:20:11 -0000 --Apple-Mail=_43A60DE9-275C-4743-A765-E05B92CA81E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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. 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. > 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. >=20 > Cheers, > Michael >=20 > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm = --Apple-Mail=_43A60DE9-275C-4743-A765-E05B92CA81E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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.

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.


Cheers,
Michael

_______________________________________________
Rpm mailing list
Rpm@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/rpm

= --Apple-Mail=_43A60DE9-275C-4743-A765-E05B92CA81E3--