Vista’s New TCP/IP Stack

30 Jan 2007

I came across this article at Microsoft today. A Google search for vista networking stack shows several commentaries about the Microsoft article. One writen commented about how bugs that were erradicated 15-20 years ago in TCP/IP stacks are back in Microsoft’s new stack.

Taking a look at the bullet points in the article, the very first one jumps out and says to me, “I’m the #1 reason that Microsoft reimplemented their TCP/IP stack from scratch.” That one reads:

Dual IP layer architecture for IPv6

After all the embarasing failures to produce a workable IPv6 stack (I first remember seeing “beta” code from Microsoft in 1999), it would seem they finally realised that the whole thing would have to be rearchitected.

Most of the bullet points in the article are fluff with a little bit of BS thrown in there two (obviously, the marketing department is still in full control of the Microsoft’s website). Lest you think I’m only here to bash Microsoft, here are some things that looks like improvements to me:

The interfaces in the current TCP/IP stack for TCP/IP security (filtering for local host traffic), the firewall hook, the filter hook, and the storage of packet filter information has been replaced with a new framework known as the Windows Filtering Platform (WFP). WFP provides filtering capability at all layers of the TCP/IP protocol stack. WFP is more secure, integrated in the stack, and much easier for independent software vendors (ISVs) to build drivers, services, and applications that must filter, analyze, or modify TCP/IP traffic. For more information about WFP, see Windows Filtering Platform.

This isn’t exactly new. Windows has had hooks into some parts of the network stack. Windows XP Service Pack 2 added some more key hooks. But one of the problems with the pre-Vista implementations is that tools which used these hooks couldn’t be guaranteed to always be able to process traffic. Although I haven’t gotten in-depth details of WFP, what I have read about it’s architecture it looks like it’s much more robust and complete.

The Next Generation TCP/IP stack can offload the processing of TCP and other types of traffic to Network Driver Interface Specification (NDIS) miniport drivers and network interface adapters. Offloading TCP and other protocol processing can improve performance for high-bandwidth networks or high-volume servers.

Although some NICs (mainly 3Com) have offloading engines that can take much or most of the load of IP and/or Ethernet packet/frame contruction and processing from the main CPU, thus freeing it for other tasks, the networking configuration of a particular Windows machine often prevented such offloading from occuring. Although I do not know any of the details as to why this happened, I have been told (by people who would have such detail) that it was due to the networking architecture of Windows. Again, I don’t have much detail on the architecture of this new feature in Vista, but what I have read leads me to believe that the new stack will make these NICs more useful as well as being easier for driver writers to implement.

The architecture of NDIS 5.1 and earlier versions limits receive protocol processing to a single processor. This limitation can inhibit scaling to large volumes of network traffic on a multi-processor computer. Receive-side Scaling resolves this issue by allowing the network load from a network adapter to be balanced across multiple processors. For more information, see Scalable Networking with RSS.

This is a much needed improvement for some systems, like Data Center Server (which already had something similar) and some beefier Windows Server boxes, but will not benefit end users much. If you were running a game that only utilized 1 of your multiple processors, theoretically, having the ability for the other processor to take over the networking processing would improve performance. Realistically, I doubt you could see the difference. Still, this is another welcome improvement in design.

The Next-Generation TCP/IP stack has an infrastructure to enable more modular components that can be dynamically inserted and removed.

Welcome to the 21st century! Linux has done that since kernel 2.0 was released (the first version that supported kernel modules).

The Next-Generation TCP/IP stack uses a new method to store configuration settings that enables more dynamic control and does not require a computer restart after settings are changed.

Of course, Windows 2000 supposedly eliminated almost all the code paths where networking changes that would require a reboot. I remember a Microsoft event where they told me that NT 5.0, as it was still called at that point, only had 6 remaining code paths (down from 27 or so) with the whole OS where a configuration change would require a reboot. However, in practice, most people experienced a need to reboot the system to make common networking configurations changes actually effective approximately 1 out of 2 times such changes were made.

One could also read, “We changed the configuration storage methods so you won’t know where to look anymore,” into that one.

From a security perspective, I’m very concerned about their new Inspection API (emphasis added):

The Next Generation TCP/IP stack exposes an Inspection API, which provides a consistent, general-purpose interface to perform deep inspection or data modification of packet contents. The Inspection API is part of WFP. The Next Generation TCP/IP stack provides access to the packet processing path at the Network and Transport layers.

So, it’s easy to hook into the Inspection API and use that to modify network traffic. It looks like it would also be trivial to inject any traffic you wanted to. Given the definition of the word inspection, I wouldn’t expect to find a modification mechanism integrated into the same sub-system.

Having a good set of instrumentation hooks into the entire network stack is important for certain types of software development, security research, auditing and a few other things. None of these should be taking place on production machines. However, it looks like Vista does not provide a way to disable the Inspection API. This could be used by a malicious program to monitor any network traffic it wanted to, or even to implement network communications that could possibly be entirely hidden from other programs (including security tools) and users. At the very least, the Inspection API should not be installed as part of the OS. Even the ability to disable it might not be enough, especially given Microsoft’s security track record.

Overall, however, I feel that I can agree with some of the reasons it appears were behind Microsoft’s decision to reimplement the TCP/IP stack from scratch for Vista and I feel that there are several valuable improvements.

That said, I still do not consider Windows networking stack, even the new one in Vista, to be remotely secure. There are too many unknowns and there is no proper, un-biased, third-party code scrutiny. Closed software simply can not be secure. Peer review by recognized outside experts is mandatory in order to build good security. That’s why burglar alarm companies invite ex-cons and security experts to do their best to penetrate their systems. That’s why insurrance companies do the same with all automobile security systems (as well as letting them asses the relative value of each system for their purposes). Microsoft doesn’t understand that and there’s no reason, from their perspective, that they need to; they’re in business to make money. Until the liability for bad security is placed on Microsoft (and other software vendors) there is no incentive for them to fix it.

Dogbert’s Password Recovery Service for Morons

25 Jan 2007

Enjoy not just one, but two great Dilbert cartoons.

Burning openSUSE 10.2 DVD

5 Jan 2007

Yesterday, I decided to burn the openSUSE 10.2 DVD for x86-64 so that I can install it on the new system. Fedora Core 6 is having lots of trouble getting the graphics working correctly on the new box (we’ll have to see if it’s any better after I update the BIOS).

So, I used KTorrent to download the DVD ISO for the x86-64 version of openSUSE 10.2, which I let run overnight (3.7GB takes a little while on a T1 line). I verified the MD5SUM on the ISO file and tried to use cdrecord to burn the image to a blank DVD. 865MB in, ka-blooey. A write error meant I had a Frisbee (or coaster, if you prefer). “OK, well that could just be one bad disc,” so I tried again. Same thing. “OK, perhaps if I turn the burn speed down,” but I now have 3 discs with ~865MB burned on them.

So, I installed k3b and tried to burn from the DVD image with that. It worked like a charm.

I’m not sure what switches k3b used, but it did run growisofs before starting the burn process. I’m not sure whether that was important or not. The cool thing is, this is an example of a frontend that is done right. With k3b, all sorts of burning situations are just handled. It will work with all sorts of disc burning and image related tools, can use transcode when creating audio or “MP3″ CDs, has DVD aware support and so much more.