WFP

1 out of 1 rated this helpful- Rate this topic

Updated: May 15, 2008

On This Page

  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

Introduction

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.

 Top of page

Why You Should Convert Your Components to WFP

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.

 Top of page

WFP Architecture

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
  
  The Win32 API contains WFP filtering APIs. A third-party firewall or other application that performs packet filtering or processing can use the WFP filtering APIs to create filters within the Base Filtering Engine. These filters can use a set of predefined filtering conditions at each layer within the Kernel-Mode Filtering Engine. The IPsec Policy Agent service and Windows Firewall are examples of WFP applications that are included with Windows Vista and Windows Server 2008. For more information, see Windows Filtering Platform in the MSDN library.

• Base Filtering Engine
  
  This user-mode service implements the filter requests that user-mode filtering applications make by adding filters to the Kernel-Mode Filtering Engine.

• Kernel-Mode Filtering Engine
  
  This kernel-mode component stores the filters that filtering applications create through the Base Filtering Engine and interacts through filtering layers with the TCP/IP stack and the set of installed callout drivers. As a packet is being processed through the new TCP/IP stack, each layer contacts the Kernel-Mode Filtering Engine. The Kernel-Mode Filtering Engine checks the configured filters to determine whether the packet is permitted, should be dropped, or should be handed to an installed callout driver for packet inspection and modification.

• Callout drivers
  
  Callout drivers are used when simple packet filtering - checking the packet against the predefined WFP filtering conditions to determine whether the packet should be permitted or dropped - is not enough. To perform deep inspection of packet contents or data modification, you must have callout drivers. Deep inspection checks the traffic beyond the predefined filtering conditions. An example of deep inspection is antivirus software, which must inspect application layer data to ensure that no viruses or worms are present in the incoming data stream. An example of data modification is network address translation (NAT), in which a router changes the fields of an IPv4 packet as it forwards the packet. Windows Vista and Windows Server 2008 include callout drivers for IPsec processing and Internet Connection Sharing. Callout drivers can also create filters in the Base Filtering Engine by using the WFP kernel client.

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.

 Top of page

Converting Components to Use WFP

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 2003New method in Windows Vista and Windows Server 2008Firewall 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.

 Top of page

Summary

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.