TLS 1.3, QUIC, HTTP/3, and SMB 3.1.1
If you think Windows Server 2022 will go unnoticed, you might be mistaken. There are more than enough new features or capabilities to cause a bit of a stir. Just on the network side of things alone, some exciting things come into play that will fuel our discussions’ fire.
TLS 1.3, QUIC, HTTP/3, and SMB 3.1.1 cause some controversy with people. What are you on about Didier? I mean, they challenge the dominance of TCP in some way or another. That is a controversy by itself. Can that even be done with impunity? Are the benefits of QUIC worthwhile compared to everything else slowing down your internet experience? On top of that, they cause some ruckus amongst incumbent security practices. Yes, we have already seen the advice to block UDP over port 443 for now, at least until everyone figures out what to do.
This article will position Microsoft’s QUIC efforts in the ecosystem and why this is so important. Mind you, not all QUIC scenarios are available in all Windows Server 2022 editions. For example, QUIC over SMB is exclusively available on Windows Server 2022 Azure Edition, which only runs on Azure and Azure Stack HCI.
QUIC in Windows Server 2022
You can find many a definition of QUIC all over the Internet. QUIC is an IETF-standardized protocol that replaces TCP with an (initially) Internet-oriented UDP mechanism that improves performance and congestion. While doing so, it strives to maintain TCP’s reliability & broad applicability. QUIC is always encrypted and requires TLS 1.3 with certificate authentication to establish the tunnel. I recommend you read The Road to QUIC (cloudflare.com) for a detailed overview of the challenges QUIC tries to address. It also discusses how QUIC does this and what is needed to deal with NAT and ECMP challenges in edge routing for the network operators.
For our understanding here, below are the main goals of QUIC.
1. QUIC achieves reduced connection times over TLS. QUIC replaces the lengthy TCP TLS handshake and encryption key exchange with a single handshake. With TCP, that requires three round-trip requests. The actual data transfer with TCP also has overhead associated with it, which QUIC with UDP seeks to avoid.
Figure : QUIC reduces the round trips during the TLS handshake significantly
2. QUIC delivers better performance in case of data packet loss. When data packets are lost, HTTP/2 over TCP suffers from head-of-line blocking. If one data packet is lost, the receiving end waits for it to be retrieved. HOL blocking impacts the connection performance negatively as other streams are blocked while waiting for this. The QUIC protocol allows streams of data packets to reach their destination independently. As such, performance is a lot less impacted by data packet loss.
3. QUIC allows for easy network changes leading to more stable connections. When connected to a resource via TCP and your network changes (moving between wifi and 4G, between separate wifi networks, …), your connection times out and needs to reestablish. QUIC uses the concept of unique identifiers to make this process smoother. Reestablishing these is done by sending a packet instead of establishing a new connection, even when your IP address changes.
4. It encourages adoption by making development easy. QUIC can be implemented on the application level, making it easier to do and allowing for more flexibility. With TCP being part of the operating system kernel, you are dependent on that implementation. That is not the case with QUIC.
Microsoft created MSQuic, which is their open-source implementation of the IETF QUIC transport protocol. In the Microsoft ecosystem, both HTTP/3 web traffic and SMB file traffic leverage MsQuic.
Figure 2:QUIC not quick, but it sure is fast. (Photo by John Cameron on Unsplash)
QUIC and UDP are tied together at the hip. The variety of network traffic use cases that leverage UDP is steadily growing. For that reason, Microsoft also worked on improving UDP performance. They are not just doing this for the ever more used UDP workloads via Real-time Transport Protocol (RTP used in VoIP and media streaming) or gaming use cases. MsQuic is the reason that in Windows Server 2022, you’ll see UDP Segmentation Offload (USO) arrive. USO offloads most of the work related to sending UDP packets from the operating system’s CPU to the NIC’s hardware. On top of this, they also introduce UDP Receive Side Coalescing (UDP RSC) and UDP send segmentation (UDP SS). UDP RSC complements USO and coalesces UDP packets to reduce CPU cycles during UDP processing. UDP SS helps reduce overhead by sending more segments as one large packet, and as stated above, with supported hardware, offloads for this are available.
Microsoft works very hard to make sure the UDP performance is stellar. Right now, they are up to 7.99 Gbps upload speed on a single connection. See Making MsQuic Blazing Fast for more information. These efforts show that QUIC speed improvements are not just about TLS 1.3 connection/negotiation speeds. That all makes sense because Microsoft will not make SMB run over QUIC if the cost would be subpar performance.
TLS 1.3
When looking at Windows Server 2022, one of the 1st things you’ll notice is that it enabled TLS 1.3 by default. You might think that’s nice for your web hosting needs and not having to terminate your TLS1.3 sessions at your load balancers or content delivery network (CDN) layer and retransmitting them to your web services over TLS1.2. While that is true and useful, there is so much more to this.
TLS 1.3 is a requirement and enabler of QUIC. But TLS 1.3 also causes worries to the SecOps people, with some media stating it makes firewalls blind. But things are not bad as it seems. While passive decryption is dead with TLS 1.3, with Perfect Forward Secrecy, that was already the case with TLS 1.2. For safe listing specific sites from decryption, the industry will need to address some challenges.
The claim that the robust encryption of TLS 1.3 conflicts with the need or desire to see all network traffic to guarantee security is a bit false. It should only be done in trusted environments while respecting privacy and legal boundaries. But still, the sentiment reminds me of governments that claim to have that same need all of the time and everywhere. In the end, there is a just cause for this in specific environments and use cases. That is fine as longs as such measures are limited to those environments when justified and with oversight.
As you would expect, some security vendors already have centralized decryption solutions in place to sell to you and turn the drawbacks of TLS 1.3 into a sales opportunity. It might kill some of the speed benefits of TLS 1.3, but hey, we already did that to TLS 1.2 with the same products. That is called the price of inspecting network traffic.
HTTP/3
HTTP/3 is also in Windows Server 2022, and HTTP/3 is nothing else than HTTP over QUIC. QUIC requires TLS1.3. So yes, we are getting QUIC support in Window Server 2022, and supporting TLS 1.3 was paramount for this to happen. If you think this is fast, well, no, it is timely as QUIC got onto our radar screen somewhere in 2015 when Google was pushing TLS + HTTP/2 over UDP after successfully seeing SPDY evolve into the HTTP/2 standard that same year. In 2019 it became available to us, and not long after, I enabled it on my blog, for example. So skipping this another Windows release would have been disappointing.
Why would we bother with HTTP/3? Next to more robust security, it provides faster connections as well as smooth transitions between networks. That is very handy for that always on the move workforce. Even when they only move between the kitchen, home office, and garden table during a pandemic. Mobile users on slower networks will notice the difference exceptionally well, but in the end, all traffic can benefit from it. Remember when we got RDP over UDP and what that meant to the user experience?
Speed bumps ahead
I acknowledge, just like others, that there will be challenges to get HTTP/3 adopted fast in the enterprise IT world. I mean, think about the firewall and security policy changes this will require. I can see the CISO, security officers, managers, network architects, etc., discussing this, and I don’t particularly want to be part of the change board meetings.
Figure 3: Traffic to my blog – I am more in the “let’s get the benefits of QUIC now” camp and have adapted to put it to work!
Blocking UPD leads to a fallback to HTTP/2 over TCP to keep things working. The fact that things will still work might very well take the speed out of adoption. Losing the momentum of adoption will ensure two things. Consulting firms will be making a lot of money, and time will be lost discussing HTTP/3 implementations. I do not even want to dive into the discussions around the impact of TLS 1.3 in TLS packet inspection. Or heaven forbid, how those expensive stateful enterprise-grade firewalls will need to be augmented even more by application-level solutions. If I were in sales, I’d be writing my sales pitches already about how my products are TLS 1.3 and QUIC ready. In any case, blocking QUIC at the firewall be unsustainable, especially when QUIC gains more and more momentum.
Meanwhile, those enterprise IT systems will be slower compared to everything else out there. There are certainties in IT! Wait a minute, Didier, what do you mean by “slow”? That will not make or break the speed of a website, surely?. True, but think of the bigger picture and Internet on 50 to 60 percent HTTP/3 versus HTTP/2. It is about cloud-scale, and your five websites with thirty thousand visitors a day do not rise to that level of consideration. On top of that, you know how it is with speed. It is very addictive; you are not going back to slower voluntarily.
SMB 3.1,1
We had TLS 1.3 and QUIC; where is game changer number three, SMB 3.1.1? Well, there are a lot of network-related new performance improvements and security-enhancing features in Windows Server 2022. The SMB protocol is one of the places where these improvements are visible and game-changing. Think about better encryption, compression, and better performance of SMB with encryption and signing when leveraging RDMA. But what causes a real stir is SMB over QUIC. Before you run off to testing this in Windows Server 2022, let me tell you that this will only be available in the Windows Server 2022 Azure Edition, which is in public preview since June 24th, 2022.
I have, well, not quite literally, seen some security and network professionals shit their pants over the prospect of SMB starting to work over port 443 instead of 445.
There are two opposing viewpoints here. First of all, dealing with the challenges of making SMB work across ISPs and corporate firewalls is hard. Many people, consumers, corporate users, and IT professionals often struggle to use and support VPNs. They are happy when hearing about secure, VPN-free SMB over the Internet. You could consider TLS 1.3, which QUIC always uses, as the autoconfigured VPN. Many firewall configs and most Internet service providers block port 445 for in and outbound traffic, and for a good reason: security. But we live in the era of work from anywhere and work more and more in hybrid scenarios.
Figure 4: Secure, flexible working from anywhere, QUIC focuses on those users’ needs (Photo by Standsome Worklifestyle on Unsplash
Securing SMB is not something many organizations have in place end to end. And certainly not over the Internet. Hence the need for a slew of site-to-site and point-to-site VPN solutions.
Secondly, there is the need or desire to secure and protect the data. People like to regulate where it is copied and stored. That’s the other side of this story. These people are horrified by that prospect.
- Firewalls will now have to deal with securing HTTP/3 but also SMB over QUIC.
- So they’ll need expensive traffic inspection to figure out what data is going where.
- How do we secure not just who but also where people copy files to and persist them? Sure the data in transit is protected by TLS 1.3, but what about at rest where the data ends up?
While VPNs are not the perfect solution, they are well known and established. VPNs also offer a lot of choices in types and implementation amongst vendors and cloud players. But QUIC is disturbing the balance in the security universe. Until everyone establishes who to blame, I am sorry, I mean learns how to deal with securing QUIC; the above will make for some lively discussions.
I am not saying there are no challenges. They do exist, and not just for security implementations. They certainly exist for load balancing (ECMP) and edge routing by the network operators, but they will address these.
What does SMB over QUIC achieve?
When QUIC becomes the transport protocol used for SMB, optionally replacing TCP and RDMA, TLS 1.3 secures the SMB payloads via encryption, even if SMB encryption itself is not enabled. All this while enjoying the multiplexing over port 443 that SMB over QUIC provides.
By default, SMB over QUIC prevents man-in-the-middle attacks. It also prevents spoofing and blocks sniffing of the payload or exposing user credentials on the Internet. The complete SMB conversation – negotiate capabilities, authentication, authorization, message bodies – happens inside the QUIC layer. The experience is as if the user was in an IPSEC or VPN tunnel but without the hassle.
Figure 5: A use case for QUIC? Customer focus, those road warriors, for example (Photo by whereslugo on Unsplash
But even for the business, there are benefits. The user experience for SMB over QUIC remains precisely the same on the road, from home, the corporate LAN, or the branch office. Please do not underestimate this. It is hard and expensive to train users, especially when different environments require different processes. If that ease of use comes without compromising security, OpSec will feel the pressure to facilitate adoption.
How does that experience remain the same? SMB will try TCP and RDMA as it does now, but it will also try QUIC. If SMB can get faster performance on a local network with RDMA or plain TCP/IP, it will use that. But when a user is traveling or if a policy enforces QUIC, it is used seamlessly. For the users and applications, this is a transparent experience. There is nothing for them to remember to do differently.
This transparent experience comes in handy because SMB over QUIC is about much more than just accessing file shares over the Internet without a VPN. By nature, all sorts of SMB traffic can go over QUIC. That means live migration, storage live migration, CSV traffic, Azure Stack HCI SBL traffic, etc. It opens up performance benefits and even allows for live migration with compression when using SMB. All this while keeping the experience the same. How cool is that? For many workloads, it will give profound performance benefits and optimizations without needing to leverage RDMA. Not that RDMA is dead because of this, as this will remain a “better together” story. It’s early days yet, but that’s how I think how things will end up.
Conclusion
TLS 1.3, HTTP/3, and SMB over QUIC are foundational technologies in Windows Server 2022. SMB over QUIC is going to be very interesting. SMB is getting some very nice improvements in its own right. Next to what we discussed above, Microsoft is raising the security bar as the threat landscape evolves. SMB now supports AES-256 encryption. They also improved the performance when using SMB encryption or signing with SMB Direct/RDMA. Finally, SMB now also supports compression, which improves network performance and reduces copy time. But all that is for future articles.
QUIC will appear in the OS for other use cases, as well as in other clients. Edge Chromium and other browsers are prime examples of this and where QUIC is supported today. It will be interesting to see if QUIC makes it into Windows Server 2019 as well. Time will tell, but it seems Windows Server 2019 has an Azure Edition as well, so who knows?
