| Introduction | |
| Why You Should Convert Your Components to WFP | |
| WFP Architecture | |
| Converting Components to Use WFP | |
| Summary | |
| Resources |
This information applies for the following operating systems:
Windows Vista
Windows Server 2008
Windows Filtering Platform (WFP) is a new architecture in Windows Vista and Windows Server 2008 that enables independent software vendors (ISVs) to filter and modify TCP/IP packets, monitor or authorize connections, filter Internet Protocol security (IPsec)-protected traffic, and filter remote procedure calls (RPCs). Filtering and modifying TCP/IP packets provides unprecedented access to the TCP/IP packet processing path. In this path, you can examine or modify outgoing and incoming packets before additional processing occurs. By accessing the TCP/IP processing path at different layers, you can more easily create firewalls, antivirus software, diagnostic software, and other types of applications and services.
WFP provides APIs so that you can participate in the filtering decisions that occur at several layers in the TCP/IP protocol stack. WFP also integrates and provides support for next-generation firewall features such as authenticated communication and dynamic firewall configuration that is based on an application's use of the Windows Sockets API. This capability is also known as an application-based policy.
WFP is not a firewall. It is a set of system services and user-mode and kernel-mode APIs that enable you to develop firewalls and other connection-monitoring or packet-processing software. For example, the Windows Firewall in Windows Vista and Windows Server 2008 uses WFP.
If you are building new software for Windows Vista or Windows Server 2008, the advantages of using WFP are higher performance, less programming complexity, and built-in diagnostic support. Additionally, you can use the built-in filtering engine for both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) traffic. WFP also provides a strong security framework in which correctly configured filters cannot be bypassed.
Note: To improve performance, TCP/IP in Windows Vista and Windows Server 2008 can offload tasks or connections to a network adapter that has the appropriate TCP/IP-offload capabilities. Connections that are not filtered by WFP can be offloaded without affecting performance.
Windows Vista includes a new architecture for the TCP/IP protocol stack. This architecture is an integrated implementation of both IPv4 and IPv6 and is known as a dual IP layer architecture. The methods of directly accessing the TCP/IP protocol stack for packet processing in Windows XP and Windows Server 2003 have changed significantly. These methods include the firewall hook, the filter hook, and other methods that involve custom solutions such as Transport Driver Interface (TDI) filter drivers. For correct operation and to perform the equivalent function in Windows Vista and Windows Server 2008, generally you must change your application, service, or driver.
Note: Windows Vista and Windows Server 2008 continue to support TDI filter drivers and Windows Sockets layered service providers (LSPs).
To change your existing component, see "Converting Components to Use WFP" later in this paper. Generally, you must map the current method that is used to access the TCP/IP packet processing path to the equivalent method that uses WFP for Windows Vista and Windows Server 2008. Revising your software for the new TCP/IP protocol stack and WFP architecture can provide additional capabilities for components that rely on the TCP/IP packet processing path. These capabilities might not have existed in versions of Windows earlier than Windows Vista and Windows Server 2008.
The following list outlines some benefits of using WFP:
| • | You have a fine level of access control to the TCP/IP packet processing path. This control differs from the filter and firewall hook methods that are supported in Windows XP and Windows Server 2003, which provide limited access to the TCP/IP processing path. |
| • | Because WFP already provides a filtering engine, you are not required to build your own filtering logic and engine. You can just tap into the WFP filtering engine and concentrate on the value that your component adds. |
| • | When you use WFP, there is much less risk of affecting your component with a future service pack release. |
| • | Implementing a firewall or packet filtering value-added solution is easier because the filtering logic and the hooks into the various layers of the TCP/IP protocol already exist. |
| • | Depending on the filtering and processing needs of your component, you might be able to move your component from kernel mode into user mode, which makes it easier to develop your component. Additionally, a crash in the user-mode component does not affect the entire Windows system. |
| • | Because all the applications and services use the same filtering engine, it is easier to determine whether other applications or services exist that perform the same function. |
| • | It is easier to develop filtering solutions that can coexist with other WFP-based filtering solutions, all of which follow WFP filter arbitration rules. |
You should use WFP in the following situations:
| • | Your component must examine TCP/IP traffic at a specific layer of the TCP/IP protocol stack. |
| • | Your component works with IPsec-protected traffic. |
| • | You want to perform packet processing after IPsec decryption. |
| • | You want to use the built-in IPv6 filtering engine to perform IPv6 packet filtering, rather than building an IPv6 filtering engine yourself. |
Figure 1 shows the WFP architecture and its extensibility for third-party applications, services, and drivers.

Figure 1. Architecture of the WFP and its extensibility for third-party components
The WFP architecture consists of the following components:
| • | Win32 API |
| • | Base Filtering Engine |
| • | Kernel-Mode Filtering Engine |
| • | Callout drivers |
Third-party ISVs can use WFP to build applications or services in the following ways:
| • | Some applications and services use only simple packet filtering. For these applications and services, the only requirement is a user-mode application or service that uses the WFP Win32 APIs to set filters at the appropriate layers in the new TCP/IP stack. No kernel-mode callout drivers are required. |
| • | For applications and services that must perform deep packet inspection or modification, you must create one or more callout drivers or a user-mode application or service. The callout driver or a user-mode application or service can use the WFP Win32 APIs to set filters at the appropriate layers in the TCP/IP stack, subject to further inspection by the callout driver. When incoming or outgoing traffic matches these filters, the Kernel-Mode Filtering Engine hands the packet to the callout driver, which performs inspection or modification before it returns the packet. Sometimes, a user-mode application or service is not required. |
Table 1 lists the existing methods for packet processing in Windows XP and Windows Server 2003 and how you must change them in Windows Vista and Windows Server 2008 to use WFP.
Table 1. Changes to existing packet processing methods
| Existing method in Windows XP and Windows Server 2003 | New method in Windows Vista and Windows Server 2008 |
Firewall hook or filter hook driver for simple packet filtering. | User-mode application or service that uses WFP Win32 APIs. |
Firewall hook or filter hook driver for deep packet inspection or modification. | IP layer, Transport layer, or Application Layer Enforcement (ALE) layer callout driver and optional user-mode application or service that uses WFP Win32 APIs. |
Transport Driver Interface (TDI) filter driver for simple packet filtering. | User-mode application or service that uses WFP Win32 APIs. |
TDI filter driver for deep packet or stream inspection or modification. | ALE callout driver and optional user-mode application or service that uses WFP Win32 APIs. |
TDI filter driver for TCP connection or User Datagram Protocol (UDP) traffic management. | Stream/Datagram Data layer callout driver and optional user-mode application or service that uses WFP Win32 APIs. TDI filter drivers performing advanced TCP connection management-such as proxying, duplicating, or cloning connections-should continue to use a TDI filter driver. |
Windows Sockets LSP for simple packet filtering. | User-mode application or service that uses WFP APIs. |
Windows Sockets LSP for deep packet inspection or modification. | ALE, Transport, or Stream/Datagram Data layer callout driver and optional user-mode application or service that uses WFP Win32 APIs. |
Network Device Interface Specification (NDIS) intermediate driver for simple packet filtering. | User-mode application or service that uses WFP APIs. |
NDIS intermediate driver for TCP connection or UDP traffic management. | ALE or Stream layer callout driver and optional user-mode application or service that uses WFP Win32 APIs. |
NDIS lightweight filter driver to perform media access control (MAC)-level filtering. | Continued use of an NDIS lightweight filter driver (WFP does not support MAC-level filtering). |
Note: TDI is supported in Windows Vista and Windows Server 2008. However, Microsoft is considering removing TDI in future versions of Windows.
The new WFP in Windows Vista and Windows Server 2008 enables TCP/IP packet filtering and modification, connection monitoring or authorization, IPsec filtering, and RPC filtering. Generally, you must convert your TCP/IP filtering or connection monitoring component in Windows XP and Windows Server 2003 to use a WFP user-mode application or service, a WFP kernel-mode callout driver, or both for Windows Vista and Windows Server 2008.
WFP User-Mode Application or Service:
Windows Filtering Platform - Win32 APIs
http://msdn.microsoft.com/en-us/library/aa366510.aspx
WFP Kernel-Mode Callout Driver:
Windows Filtering Platform Callout Drivers – Windows Driver Kit
http://msdn.microsoft.com/en-us/library/ms796374.aspx
Other:
Articles on WFP in the Windows Core Networking Blog
http://blogs.msdn.com/wndp/archive/tags/WFP/default.aspx
WFP Discussion Forum
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1637&SiteID=1
WFP Sample Project
http://blogs.msdn.com/onoj/archive/2007/05/09/windows-filtering-platform-sample.aspx