What if you could filter IPsec encrypted traffic? What if you could easily filter both IPv4 and IPv6 traffic? What if you could write just a few lines of user-mode code to filter applications based on port, protocol and application ID?
To do all this and much more, Windows Vista exposes a set of user and kernel-mode programming interfaces for implementing firewalls, anti-virus, anti-spyware, intrusion detection, and more. This set of interfaces makes up our new Windows Filtering Platform (WFP) in Vista. WFP will be the basis of Windows Vista-compliant security products built by leading security companies around the world.
Here’s a sneak preview to WFP’s value-add for Windows Vista through the eyes of Abolade Gbadegesin, Networking Architect:
For Windows Vista we’ve rethought the way that components integrate with the networking stack, and how they extend its behavior. In the past it’s been necessary for such components to examine frames passing through the NDIS layer, or examining I/O request packets passing through the TDI layer. The new networking stack now allows such components to instead participate in the state machines at multiple layers, providing notifications of significant internal state transitions, eliminating the need for guesswork, and making it easier to extend the stack in a robust way.
Extensions to the stack allow developers to perform rich stream and packet filtering. Here’s what Anupama Vasanth, automation developer/tester for WFP, has to say:
WFP enables inspection and modification of stream and packet data coming in. A stream can be paused and later resumed; parts of the stream can be permitted, blocked or replaced with different data. There can be multiple stream modifiers performing stream modification. The stream can be pended if more data is needed to make a filtering decision on the stream. A typical use of this would be an application that needed to screen the stream for unwanted words.
Packet modification is also supported by different re-injection APIs. In this case, the packet is cloned, modified and re-injected either in the send, receive or forward path. Packet modification can involve header modification (e.g. port, source, destination addresses for NAT scenarios) or payload modification (both content and size can change). Packets can also be pended and then injected at a later time or discarded at a later time depending on the filtering policies.
While WFP provides a rich filtering interface, it also exposes a new set of socket-level security APIs that enable Windows Sockets applications to leverage with IPsec for securing traffic. Kartik Murthy, IPsec developer, has the following comments on these new secure socket APIs:
Traditionally, IPsec has been used to protect network traffic via central administrative configuration using local or Active Directory group policy. The Secure Sockets API is an extension to the Windows Sockets API that allows socket applications to directly control security of their traffic over a network. The API extension allows applications to provide security policy and requirements for their traffic, and query the security settings applied on their traffic. For instance, applications can use this API to query a remote peer’s security token and use it to perform application-level access checks, or client applications can simply specify the Server Principal Name (SPN) of the server to prevent any man-in-the-middle attacks. Today, applications can already secure their traffic by using SSL, etc. But in comparison, the Winsock extension has been designed to make it very easy for a network application to secure its traffic, with minimal additional code, while letting Windows Sockets abstract away the complexity.
If you wish to learn more, I will be presenting a WFP session at WinHEC 2006 in Seattle (May 23-25). It will cover different filtering technologies supported to date, and how WFP takes filtering to the next level. The session will also illustrate the use of WFP APIs in different scenarios.
Program Manager, Core Networking