Hi Rob, Without wading into the other technicals of the discussion at this point, I just wanted to comment that there is at least one significant exception to your absolute statement below ( "no one with a serious load..."), and it's quite possible given the circumstantial information here that this particular exception may be what's motivating this thread, or is at least closely related. The Netflix Open Connect Appliances, last I saw published, were closing in on 1 Tbps of TLS from a single chassis and are pretty well known to have been architected without user-space networking.
Absent that one giant slice of internet traffic, I would agree your point does broadly apply (and I'm well familiar with user-space networking - for example, the core of f-stack project you mentioned was originally misappropriated code of mine). Best, Pat On Sun, Mar 26, 2023 at 8:05 PM Rob Sayre <say...@gmail.com> wrote: > Hi, > > The problem is also incompletely described, right? > > It doesn't address stuff like: > https://github.com/F-Stack/f-stack > > There, you have userspace networking right off the NIC using DPDK or > equivalent. This is how all big websites work (this one is from Tencent), > because it's easier to drain connections as you upgrade the software, and > it's fast enough to saturate the network hardware. > > I don't mind the kernel hacking rhetoric, but no one with a serious load > does this. (or, if you do, look at that f-stack link...) > > thanks, > Rob > > > On Sun, Mar 26, 2023 at 3:00 PM Eric Rescorla <e...@rtfm.com> wrote: > >> Hans Petter, >> >> Before I address your technical points, I would observe that your >> tone here isn't ideal for getting people excited about your ideas. >> If you think there's something that people don't understand, then >> by all means explain it, but telling people that they have a "total lack >> of kernel-side insight" or that their "technology and ideas will be >> totally >> left behind" doesn't really foster good will. >> >> >> On Sat, Mar 25, 2023 at 12:41 AM Hans Petter Selasky <h...@selasky.org> >> wrote: >> >>> On 3/24/23 23:59, Watson Ladd wrote: >>> > On Fri, Mar 24, 2023 at 2:09 AM Hans Petter Selasky <h...@selasky.org> >>> wrote: >>> > <snip> >>> >> OK >>> >> >>> >> I see where you guys are falling off. >>> >> >>> >> Professionals already encrypt the video files served using >>> >> (confidentiality, integrity and authenticity). >>> >> >>> >> These files are also served using HTTP, unencrypted, but then people >>> can >>> >> easily compare the contents to figure out what is being watched, even >>> if >>> >> encrypted. >>> >> >>> >> The transport layer TCP/IP/TLS does not need the authenticity part in >>> >> this case, because the files served are already fully encrypted, if >>> that >>> >> makes sense. >>> > >>> > The file is not what is transported over TLS connection. The HTTP >>> > response is transported. That response includes things like headers >>> > whose manipulation could have negative effects on security: e.g. >>> > setting cookies. >>> > >>> > There's also a fundamental architectural issue: the HTTP server does >>> > not know what file will be requested when negotiating the TLS >>> > ciphersuite, and the TLS connection is used across multiple HTTP >>> > requests. That makes accepting a different ciphersuite for some >>> > requests extremely difficult to actually implement. >>> > >>> > Does the underlying encryption ensure authenticity? >>> > >>> > Lastly I'm not sure I understand what the performance issue is with >>> > the offloading. I think what you're saying is you need more memory to >>> > track the encrypted and authenticated segments on retransmission than >>> > just knowing the offsets, but I think that would be a problem with any >>> > sort of TLS record packing that has different boundaries from the TCP >>> > segmentation. If you line them up, then the MAC tag isn't any more >>> > difficult. It also isn't the case that AES-GCM can ignore the >>> > segmentation even without the MAC: the nonce is xored with the >>> > write_iv, and then the nonce is combined with a counter starting at 1 >>> > that occupies the low 32 bits to get the keystream. >>> > >>> > Are you proposing just using AES-CTR ignoring the record segmentation >>> entirely? >>> >>> Hi Watson Ladd, >>> >>> I had a longer conversation on Whatsapp with another guy from the IETF >>> list. >>> >>> I see there is some knowledge gap between you guys sitting in the IETF >>> and me in the implementation department sort of. >>> >> >>> There are basically three ways to do TLS encryption: >>> >>> 1) OpenSSL (or the alike in user-space) >>> 2) AES CPU instructions in the kernel (all done in kernel space) >>> 3) The network card does AES encryption and decryption >>> >>> In case 1) and 2) there is no problem. >>> >>> In case 3) there is also no problem, until you have a packet loss and >>> retransmission. The NIC cannot remember previously computed SHA-256 and >>> AES-CTR data, and so if you need to retransmit only the SHA-256 hash >>> data, then all of the TLS record, usually up to 16 kilobytes, needs to >>> be "dumped" (not transmitted) via the crypto engine in the NIC, to >>> re-compute the SHA-256 hash data. >>> >> >> Several points here: >> 1. Can you explain where SHA-256 comes in here, as it's not used with >> AES-GCM? I'm not following the problematic scenario. >> >> 2. I understand that you say that there is a problem with packet loss and >> retransmission, but on correctly functioning networks, packet loss rates >> should be quite low (<5%), in which case the overhead of just treating >> the retransmission as if it were a fresh send. I agree that it's not >> ideal, >> but won't the overhead just be the same as if you were sending a few >> percent more data. >> >> 3. Being able to retransmit pre-encrypted TLS records is a feature of >> TLS over TCP, but not of QUIC, where retransmissions entail a fresh >> encryption. As more traffic moves to H3, especially for high-speed >> applications, it seems like any optimization we do here would be >> increasingly >> less useful. >> >> -Ekr >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
