From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 A1A813B29E; Thu, 21 Oct 2021 03:18:35 -0400 (EDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mdSLQ-000CuJ-Ie; Thu, 21 Oct 2021 09:18:32 +0200 Received: from ti0182q160-6611.bb.online.no ([95.34.115.34] helo=[192.168.1.7]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1mdSLP-0009BA-R8; Thu, 21 Oct 2021 09:18:32 +0200 From: Michael Welzl Message-Id: <178233EF-5125-415E-9D05-A25729FC1413@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_41F88FD6-BC0F-44B4-B2F2-70BD90CB1F6B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Thu, 21 Oct 2021 09:18:30 +0200 In-Reply-To: Cc: 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-mx12.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: F722CF3359ADE04C3C8188C77ED2A3224548D6EF 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:18:35 -0000 --Apple-Mail=_41F88FD6-BC0F-44B4-B2F2-70BD90CB1F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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) - right? 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 had meddled with the ACKs - and by this to avoid an entire class = of attacks that put a close-by endpoint which NACKs segments. >=20 > 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 part 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 --Apple-Mail=_41F88FD6-BC0F-44B4-B2F2-70BD90CB1F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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) - right?

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 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?

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 = part 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

= --Apple-Mail=_41F88FD6-BC0F-44B4-B2F2-70BD90CB1F6B--