[Rpm] [Make-wifi-fast] tack - reducing acks on wlans

[Keith Winstein]

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 <p>, and I'm ACKing
   the datagram you sent to destination <d> that had public ID <id>. I promise
   I will deliver that datagram soon to destination <d>. Do you want me to
   keep sending these?" (and maybe the endpoint is like, "Sure, keep sending
   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 still
   have occasional end-to-end ACKs) and decide never to trust the intermediary
   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 <michawe at ifi.uio.no> wrote:

> Hi again,
>
> A clarification about one point here - I had overlooked “close-by”, 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’t 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’s another answer:  this is solved by encryption between the host and
> the MASQUE proxy. That’s okay, I’m not questioning this part of the
> design.  What I say is: the MASQUE proxy itself shouldn’t 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’t speak
> against the e2e encryption of payload!)
>
> Cheers,
> Michael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/rpm/attachments/20211021/e4af785d/attachment.html>