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
Here’s a sneak preview to WFP’s value-add for Windows Vista through the eyes of
Extensions to the stack allow developers to perform rich stream and packet filtering. Here’s what
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.
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
Program Manager, Core Networking