Windows Hardware Certification Requirements - Filter Driver
[!Important]
Microsoft Corporation Technical Documentation License Agreement
READ THIS! THIS IS A LEGAL AGREEMENT BETWEEN MICROSOFT CORPORATION ("MICROSOFT") AND THE RECIPIENT OF THESE MATERIALS, WHETHER AN INDIVIDUAL OR AN ENTITY ("YOU"). IF YOU HAVE ACCESSED THIS AGREEMENT IN THE PROCESS OF DOWNLOADING MATERIALS ("MATERIALS") FROM A MICROSOFT WEB SITE, BY CLICKING "I ACCEPT", DOWNLOADING, USING OR PROVIDING FEEDBACK ON THE MATERIALS, YOU AGREE TO THESE TERMS. IF THIS AGREEMENT IS ATTACHED TO MATERIALS, BY ACCESSING, USING OR PROVIDING FEEDBACK ON THE ATTACHED MATERIALS, YOU AGREE TO THESE TERMS.
For good and valuable consideration, the receipt and sufficiency of which are acknowledged, You and Microsoft agree as follows:
You may review these Materials only (a) as a reference to assist You in planning and designing Your product, service or technology ("Product") to interface with a Microsoft Product as described in these Materials; and (b) to provide feedback on these Materials to Microsoft. All other rights are retained by Microsoft; this agreement does not give You rights under any Microsoft patents. You may not (i) remove this agreement or any notices from these Materials, or (ii) give any part of these Materials, or assign or otherwise provide Your rights under this agreement, to anyone else.
These Materials may contain preliminary information or inaccuracies, and may not correctly represent any associated Microsoft Product as commercially released. All Materials are provided entirely "AS IS." To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.
If You are an entity and (a) merge into another entity or (b) a controlling ownership interest in You changes, Your right to use these Materials automatically terminates and You must destroy them.
You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to these Materials. However, any Feedback you voluntarily provide may be used in Microsoft Products and related specifications or other documentation (collectively, "Microsoft Offerings") which in turn may be relied upon by other third parties to develop their own Products. Accordingly, if You do give Microsoft Feedback on any version of these Materials or the Microsoft Offerings to which they apply, You agree: (a) Microsoft may freely use, reproduce, license, distribute, and otherwise commercialize Your Feedback in any Microsoft Offering; (b) You also grant third parties, without charge, only those patent rights necessary to enable other Products to use or interface with any specific parts of a Microsoft Product that incorporate Your Feedback; and (c) You will not give Microsoft any Feedback (i) that You have reason to believe is subject to any patent, copyright or other intellectual property claim or right of any third party; or (ii) subject to license terms which seek to require any Microsoft Offering incorporating or derived from such Feedback, or other Microsoft intellectual property, to be licensed to or otherwise shared with any third party.
Microsoft has no obligation to maintain confidentiality of any Microsoft Offering, but otherwise the confidentiality of Your Feedback, including Your identity as the source of such Feedback, is governed by Your NDA.
This agreement is governed by the laws of the State of Washington. Any dispute involving it must be brought in the federal or state superior courts located in King County, Washington, and You waive any defenses allowing the dispute to be litigated elsewhere. If there is litigation, the losing party must pay the other party s reasonable attorneys fees, costs and other expenses. If any part of this agreement is unenforceable, it will be considered modified to the extent necessary to make it enforceable, and the remainder shall continue in effect. This agreement is the entire agreement between You and Microsoft concerning these Materials; it may be changed only by a written document signed by both You and Microsoft.
Windows 8.1 System Update
For Windows 8.1, the critical areas that are new or have been updated are:
Product Type | Summary of Changes |
---|---|
Bus Controllers |
Requirements for supporting I C and UART Bus Controllers. For implementation details see requirements under Device.BusControllers. |
Fingerprint Reader |
Inbox support for fingerprint readers is being introduced in Windows 8.1. In order for fingerprint readers to work properly with Windows 8.1, it is recommended to use the Windows 8.1 class driver. For more information see Device.Input.FingerPrintReader. |
Graphics Adapter |
For Windows 8.1 all GPUs are required to have WDDM 1.3 driver which improve power management and performance. |
Hard Drive |
SATA Hybrid hard drives (as defined when the flash cache portion and the rotational component are in the same case) support is being added to Windows 8.1. For more details, see requirement under Device.Storage.Hd.Sata. |
Near Field Proximity |
NCI, a transport-independent communication protocol that standardizes the way a NFC controller and a device host, compliance is now required for Windows 8.1. |
Precision Touchpad |
Precision Touchpad is being introduced as a new product for Windows 8.1 Certification. In order for Precision Touchpads to function in Windows 8.1, they must meet the new requirements and exclusively utilized the Windows 8.1 class driver. Precisions Touchpads are required on all ARM based systems and are optional for x86/x64. |
Video Playback |
Video and audio playback requirements for both connected and non-connected standby systems (if implemented) to ensure glitch free video play of many common video formats. Exact requirements are under System.Client.VideoPlayback. |
WLAN |
Adding certification requirements to support 802.11ac, and to improve device/driver stability. |
The following set of changes will be enforced after January 1, 2014:
Product Type | Summary of Changes |
---|---|
Audio |
New communication fidelity (InAir) requirement for integrated speakers and microphone to ensure a great voice and video communication experience. See requirements under Device.Audio and System.Fundamentals.SystemAudio. |
Bluetooth |
In Windows 8.1, to ensure a uniform experience across Windows PCs with an integrated display with wireless capabilities, Bluetooth radio support is required if Wi-Fi is present on the PC beginning with new system submissions starting January 1, 2014. |
Connected Standby Power |
There are two new requirements beginning January 1, 2014. First in order to support all day usage for connected standby systems, these systems must support at least 6 hours of video playback at the displays native resolution. In addition, if these systems have a fan for a cooling, we need the fan to report its status to the Windows Operating system. Please see requirements under System.Client.PowerManagement and System.Fundamentals.PowerManagement for details. |
Webcam |
Starting with new system submissions on January 1, 2014, systems that have an integrated display must have a front/user facing webcam with a minimum resolution of 720p. For complete details see the requirements under the feature System.Client.Webcam. |
The following requirements will be enforced after January 1, 2015:
Product Type | Summary of Changes |
---|---|
Trusted Platform Module (TPM) 2.0 |
TPM 2.0 required to support PCR [7] in system firmware. All new systems submitting after January 1, 2015 must have TPM 2.0. |
Summary of Changes
Changed since the June 26, 2013 Publication |
Comments |
Filter.Driver.vSwitchExtension.ExtensionRequirements |
Updated |
Introduction
These requirements are Microsoft s guidelines for designing Windows Filtering Platform Drivers (WFP), File Systems Filter Drivers, Antivirus Filter Drivers, and Early Launch Anti-Malware (ELAM Filter Drivers). Successfully following this guidance allows a partner to receive certification and signing for their filter drivers.
The requirements are organized by feature using a Camel Case naming convention, which facilitates grouping related requirements and communicating their relationship to the Windows feature they are intended to support. Tests assessing compliance with the features are exposed during testing with the Hardware Certification Kit and can be related directly back to these requirements. Some requirements have passed forward from Logo requirements for earlier Windows versions which used a category based structure. We have included the older LogoPoint ID in the comments section for your convenience.
Optional Features and "If Implemented" Requirements
The Windows Hardware Certification Kit (Windows HCK) automatically detects all features that are implemented in a product. When the detected features include all required features that are needed to define a product type, then the product is certifiable for that product type.
If additional functionality is implemented in the filter driver design beyond the minimum list of features and their underlying requirements for a given product type, then the Windows HCK identifies those additional features and tests them for compliance with the corresponding requirements. Because these optional requirements apply only if the optional features are implemented, these requirements are identified as "If Implemented" in this document. If an optional feature is exposed, the associated "If implemented" requirements must be met for the filter driver to be successfully certified.
Filter.Driver.AntiVirus
Antivirus requirements for Filter drivers
Related Requirements |
Filter.Driver.AntiVirus.Functionality Filter.Driver.AntiVirus.IcarDetection Filter.Driver.AntiVirus.MiniFilter Filter.Driver.AntiVirus.NamedPipeAndMailSlots Filter.Driver.AntiVirus.RegistryAndProcess Filter.Driver.AntiVirus.Winsock |
Filter.Driver.AntiVirus.Functionality
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows File Systems, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.AntiVirus |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows File Systems, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Local File Systems
NT API, Win32 API and Win32 Mapped IO API usage
Object ID functionality
Reparse Points
Oplocks
System Cache usage
Transactional capability
Remote File Systems
Oplock semantics over SMB
Information about File System Behavior: https://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf. Information about Oplock semantics over SMB, see the [MS-SMB2] protocol document at: https://msdn.microsoft.com/library/cc246482(PROT.13).aspx
Additional Information
Enforcement Date |
Dec. 01, 2010 |
Filter.Driver.AntiVirus.IcarDetection
Anti-Virus Filter Drivers must be architected to exercise basic Anti-virus functionality, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.AntiVirus |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Anti-Virus Filter Drivers must be architected to exercise basic Anti-virus functionality, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
File Systems
Anti-virus functionality
Additional Information
Enforcement Date |
Dec. 01, 2010 |
Filter.Driver.AntiVirus.MiniFilter
A File System Filter Driver must be a Mini-Filter driver using the File Systems Filter Manager
Target Feature |
Filter.Driver.AntiVirus |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
This requirement will be tested implicitly. The driver detection mechanism of the Windows Hardware Certification Kit (WHCK) will be written such that legacy file system filter drivers are not enumerated. Only minifilter drivers will be enumerated and surfaced in the WHCK. As such, a user will be unable to select a legacy filter driver for logo testing via the WHCK.Information about Filter Manger and Minifilter Drivers available here:https://msdn.microsoft.com/library/ff540402(v=VS.85).aspxhttps://msdn.microsoft.com/windows/hardware/gg462968.aspx
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.AntiVirus.NamedPipeAndMailSlots
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Named Pipe and Mail Slots, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.AntiVirus |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Named Pipe and Mail Slots, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Named Pipe File System
Functionality and stress for common APIs
Anonymous pipes
Pipe modes
Open modes
Invalid pipe names
Flushing pipe
Max pipe instance
Pipe direction (in/out/duplex)
Input and output buffer sizes
Various call semantics, such as reconnecting a pipe that has been disconnected at the server end.
Behavior validation of all named pipes operations for each distinct state of a pipe instance.
Performance for named pipe creation and connection.
Through put for different in/out buffer sizes and number of clients.
Scalability of increasing number of clients to time it takes for connection to a named pipe instance
Mail Slot File System
Functionality and stress for common APIs
Information about Named Pipe and Mail Slots can be found at:https://msdn.microsoft.com/library/aa365574(v=VS.85).aspx
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.AntiVirus.RegistryAndProcess
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of the Windows Registry and Processes, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.AntiVirus |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of the Windows Registry and Processes, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Registry
NT API and Win32 API usage
Key Functions
Transaction Registry Operations
Symbolic Link behavior
Process
General Module Management
Race conditions at thread/process termination
Process management callback functionality
Thread and Process handle operations
Additional Information
Enforcement Date |
Dec. 01, 2010 |
Filter.Driver.AntiVirus.Winsock
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows Sockets, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.AntiVirus |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows Sockets, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Winsock
Winsock API functionality
Information about Winsock APIs can be found at:https://msdn.microsoft.com/library/ms740673(VS.85).aspx
Additional Information
Enforcement Date |
Dec. 01, 2010 |
Filter.Driver.EarlyLaunchAntiMalware
This section describes requirements for early launch driver.
Related Requirements |
Filter.Driver.EarlyLaunchAntiMalware.BackupDriver Filter.Driver.EarlyLaunchAntiMalware.ELAMSignatureAttributes Filter.Driver.EarlyLaunchAntiMalware.MVIMembership Filter.Driver.EarlyLaunchAntiMalware.Performance Filter.Driver.EarlyLaunchAntiMalware.SignatureData |
Filter.Driver.EarlyLaunchAntiMalware.BackupDriver
Early Launch Anti-malware drivers include a backup copy in case of corruption
Target Feature |
Filter.Driver.EarlyLaunchAntiMalware |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
The AM driver is critical to the boot success of the computer. If the driver gets corrupted, then the boot may not succeed. To provide the best user experience, it is required that when the AM driver is installed, it also installs a copy in the driver backup store. This ensures a smooth remediation experience in the case that the primary driver gets corrupted.The location of the ELAM backup store is defined by Windows, and stored in the registry:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EarlyLaunch ! BackupPath Design Notes:The early launch anti-malware (AM) drivers are started soon after the NTOS kernel starts. For each subsequent boot driver the AM driver receives a callback from the PnP manager to determine whether the boot driver should be initialized. The AM driver evaluates the boot driver and must return good, bad, or unknown. Based on the returned classification and defined policy, the PnP manager decides whether to initialize the boot driver.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.EarlyLaunchAntiMalware.ELAMSignatureAttributes
Requirement for the SignatureAttribute section in the ELAM INF Files
Target Feature |
Filter.Driver.EarlyLaunchAntiMalware |
Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
ELAM files need to be signed with a special signature as part of the submission process. The process of determining what signature each module needs is being standardized; each INF file now must include a SignatureAttributes section uniquely identifying what type of signature is applicable for the associated driver binaries. Adding this section to existing inf files is a very simple process.
An example follows:
[SignatureAttributes]
ELAMFILE.dll = SignatureAttributes.Elam
[SignatureAttributes.Elam]
Elam=true
Additional Information
Enforcement Date |
Jun. 26, 2013 |
Filter.Driver.EarlyLaunchAntiMalware.MVIMembership
Early Launch Anti-malware Drivers May Only Be Created by MVI Members
Target Feature |
Filter.Driver.EarlyLaunchAntiMalware |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Any Early Launch Anti-malware driver may only be created by Microsoft Virus Initiative (MVI) members. Design Notes:The early launch anti-malware (AM) drivers are started soon after the NTOS kernel starts. For each subsequent boot driver the AM driver receives a callback from the PnP manager to determine whether the boot driver should be initialized. The AM driver evaluates the boot driver and must return good, bad, or unknown. Based on the returned classification and defined policy, the PnP manager decides whether to initialize the boot driver.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.EarlyLaunchAntiMalware.Performance
Early Launch Anti-malware Drivers Must Be Performant
Target Feature |
Filter.Driver.EarlyLaunchAntiMalware |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Callback Latency:The AM driver is required to return a result for each callback within 0.5 ms of receiving the callback.Memory Allocation:The AM driver, including both the driver image as well as its configuration (signature) data, is required to have a limited memory footprint of 256KB or less.Unload Blocking:Each AM driver will receive a synchronous callback after the last boot driver has been initialized indicating that the AM driver will be unloaded. At this point the AM driver must cleanup and save any persistent status information. This must occur within 0.5 ms as measured from the time when the kernel issues the callback to the driver to the time the AM driver returns the callback.Design Notes:The early launch anti-malware (AM) drivers are started soon after the NTOS kernel starts. For each subsequent boot driver, the AM driver receives a callback from the PnP manager to determine whether the boot driver should be initialized. The AM driver evaluates the boot driver and must return good, bad, or unknown. Based on the returned classification and defined policy, the PnP manager decides whether to initialize the boot driver.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.EarlyLaunchAntiMalware.SignatureData
Early Launch Anti-malware Drivers Only Use Signature Data Stored in the Microsoft-specific Location
Target Feature |
Filter.Driver.EarlyLaunchAntiMalware |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
The AM driver must get its malware signature data from a single, well-known location and no other. The signature data shall be stored in the registry in a new "ELAM" hive under HKLM that is loaded by Winload, and will therefore be available to the AM driver prior to the file system being initialized. Each AM driver will have a unique key in which to store their signature blob. The registry path and key shall be of the format HKLM\ELAM\<Vendor Name>\Measured : Binary = <blob>. Design Notes:The early launch anti-malware (AM) drivers are started soon after the NTOS kernel starts. For each subsequent boot driver the AM driver receives a callback from the PnP manager to determine whether the boot driver should be initialized. The AM driver evaluates the boot driver and must return good, bad, or unknown. Based on the returned classification and defined policy, the PnP manager decides whether to initialize the boot driver.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.FileSystem
Related Requirements |
Filter.Driver.FileSystem.Functionality Filter.Driver.FileSystem.MiniFilter Filter.Driver.FileSystem.NamedPipeAndMailSlots Filter.Driver.FileSystem.RegistryAndProcess |
Filter.Driver.FileSystem.Functionality
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows File Systems, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.FileSystem |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows File Systems, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Local File Systems
NT API, Win32 API and Win32 Mapped IO API usage
Object ID functionality
Reparse Points
Oplocks
System Cache usage
Transactional capability
Remote File Systems
Oplock semantics over SMB
Information about File System Behavior: https://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf. Information about Oplock semantics over SMB, see the [MS-SMB2] protocol document at: https://msdn.microsoft.com/library/cc246482(PROT.13).aspx
Additional Information
Enforcement Date |
Dec. 01, 2010 |
Filter.Driver.FileSystem.MiniFilter
A File System Filter Driver must be a Mini-Filter driver using the File Systems Filter Manager
Target Feature |
Filter.Driver.FileSystem |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
This requirement will be tested implicitly. The gatherer will be written such that it enumerates and surfaces only mini-filter drivers for the Windows Hardware Certification Kit (WHCK). Hence, a user will be unable to select a legacy filter driver for certification testing.Information about Filter Manger and Mini-Filter Drivers available here:https://msdn.microsoft.com/library/ff540402(v=VS.85).aspx
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.FileSystem.NamedPipeAndMailSlots
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Named Pipe and Mail Slots, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.FileSystem |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Named Pipe and Mail Slots, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Named Pipe FS
Functionality and stress for common APIs
Anonymous pipes
Pipe modes
Open modes
Invalid pipe names
Flushing pipe
Max pipe instance
Pipe direction (in/out/duplex)
Input and output buffer sizes
Various call semantics, such as reconnecting a pipe that has been disconnected at the server end.
Behavior validation of all named pipes operations for each distinct state of a pipe instance.
Performance for named pipe creation and connection.
Through put for different in/out buffer sizes and number of clients.
Scalability of increasing number of clients to time it takes for connection to a named pipe instance
Mail Slot FS
Functionality and stress for common APIs
Information about Named Pipe and Mail Slots can be found at:https://msdn.microsoft.com/library/aa365574(v=VS.85).aspx
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.FileSystem.RegistryAndProcess
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows Registry and Processes, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.FileSystem |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers must be architected to maximize the reliability and functionality of Windows Registry and Processes, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Registry
NT API and Win32 API usage
Key Functions
Transaction Registry Operations
Symbolic Link behavior
Process
General Module Management
Race conditions at thread/process termination
Process management callback functionality
Thread and Process handle operations
Additional Information
Enforcement Date |
Dec. 01, 2010 |
Filter.Driver.Fundamentals
Corresponds to Device Driver Fundamentals, but for Filter Drivers.
Related Requirements |
Filter.Driver.Fundamentals.DriverQuality |
Filter.Driver.Fundamentals.DriverQuality
A Filter Driver must be of high quality
Target Feature |
Filter.Driver.Fundamentals |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Driver components must not cause the system to crash or leak resources. These resources include but are not limited to the following:
Memory
Graphics Device Interface (GDI) or user objects
Kernel objects such as files, mutex, semaphore, and device handles
Critical sections
Disk space
Printer handles
Design Notes:Sleep & PNP with IO Before And After Test - Test cycles the system through all sleep states and does basic PNP on all devices on the system.This test will be run with Driver Verifier enabled with standard settings.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.Network.LWF
LAN requirements
Related Requirements |
Filter.Driver.Network.LWF.Base Filter.Driver.Network.LWF.MTUSize |
Filter.Driver.Network.LWF.Base
All light weight filters must be NDIS 6.30 or greater
Target Feature |
Filter.Driver.Network.LWF |
Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All light weight filters must be NDIS 6.30 or greater and be compliant to the NDIS specification on MSDN.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.Network.LWF.MTUSize
All light weight filters must be able to accept arbitrary packet sizes which might be greater than the miniport's MTU.
Target Feature |
Filter.Driver.Network.LWF |
Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All light weight filters must be NDIS 6.30 or greater. All light weight filters must be able to accept arbitrary packet sizes which might be greater than the miniport's MTU.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.Security
Additional TDI filter driver and LSP requirements related to security.
Related Requirements |
Filter.Driver.Security.NoTDIFilterAndLSP |
Filter.Driver.Security.NoTDIFilterAndLSP
No TDI filters or LSPs are installed by the driver or associated software packages during installation or usage
Target Feature |
Filter.Driver.Security |
Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
There can be no use of TDI filters or LSPs by either kernel mode software or drivers, or user mode software or drivers.
Additional Information
Enforcement Date |
Mar. 01, 2012 |
Filter.Driver.vSwitchExtension
Related Requirements |
Filter.Driver.vSwitchExtension.ExtensionRequirements |
Filter.Driver.vSwitchExtension.ExtensionRequirements
Filter drivers that implement VM Switch Extensibility must support required functionalities, modes, and protocols
Target Feature |
Filter.Driver.vSwitchExtension |
Applies to |
Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Ethernet devices that implement VM Switch Extensibility must support required functionalities, modes, and protocols.
Requirements
An extension must pass NDIS Filter logo requirements
An extension must have a valid INF
An extension must make only NDIS, WDF, or WDM calls; any calls to other kernel mode components are not allowed
An extension must support Hyper-V Live Migration
Don t break LM, Save/Restore, Export/Import
Don t block saved data from another extension
Don t block other extension interactions
An unconfigured extension must not break connectivity between the host and external network
A capture extension must not break connectivity between vSwitch ports
An extension must pass the following switch/port/NIC configuration OIDs down the stack of an extension
OID_SWITCH_PARAMETERS
OID_SWITCH_PORT_ARRAY
OID_SWITCH_PORT_TEARDOWN
OID_SWITCH_PORT_DELETE
OID_SWITCH_NIC_ARRAY
OID_SWITCH_NIC_CONNECT
OID_SWITCH_NIC_DISCONNECT
OID_SWITCH_NIC_DELETE
OID_SWITCH_NIC_REQUEST
An extension must pass the following policy/status OIDs that it does not consume down the stack
OID_SWITCH_PORT_PROPERTY_ADD
OID_SWITCH_PORT_PROPERTY_UPDATE
OID_SWITCH_PORT_PROPERTY_DELETE
OID_SWITCH_PROPERTY_ADD
OID_SWITCH_PROPERTY_UPDATE
OID_SWITCH_PROPERTY_DELETE
OID_SWITCH_PORT_FEATURE_STATUS_QUERY
OID_SWITCH_FEATURE_STATUS_QUERY
An extension must pass the following policy OIDs down the stack
OID_SWITCH_PORT_PROPERTY_ENUM
OID_SWITCH_PROPERTY_ENUM
An extension must pass the following up the stack
NDIS_SWITCH_NIC_STATUS_INDICATION
A capture extension must not call any of the following functions:
SetNetBufferListSource;
AddNetBufferListDestination;
GrowNetBufferListDestinations;
UpdateNetBufferListDestinations;
CopyNetBufferListInfo;
ReportFilteredNetBufferLists;
A filter extension must not call any of the following functions:
AddNetBufferListDestination;
GrowNetBufferListDestinations;
A "filter" extension must never add a new destination to a NET_BUFFER_LIST.
A "forwarding" extension must only add destinations on ingress.
New packets generated by extensions must always be sent on ingress.
Calls to the following API must specify a NIC that is in Connected state (OID_SWITCH_NIC_CONNECT issued, OID_SWITCH_NIC_DISCONNECT not yet issued).
SetNetBufferListSource
AddNetBufferListDestination
UpdateNetBufferListDestinations (when adding new destinations)
ReferenceSwitchNic
Calls to the following API must specify a Port that is in Created state (OID_SWITCH_PORT_CREATE issued, OID_SWITCH_PORT_TEARDOWN not yet issued).
ReferenceSwitchPort
An extension must be capable of being enabled and disabled correctly
An extension must be packaged in a silently installable MSI to enable automatic deployment by management applications. The MSI may only contain a single extension and must have the following string fields set on the MSI. More information is available on MSDN under Installing Hyper-V Extensible Switch Extensions https://msdn.microsoft.com/library/windows/hardware/hh598191(v=vs.85).aspx
Description
Manufacturer
ProductVersion
ProductName
DriverID
DriverVersion
ExtensionType
IsManagedByExtensionManager (optional)
MinAplicableOSVersion
MaxAplicableOSVersion (optional)
Additional Information
Enforcement Date |
Oct. 30, 2011 |
Filter.Driver.WindowsFilteringPlatform
Related Requirements |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.AppContainers.SupportModernApplications Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.CleanUninstall Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.ConnectionProxying.NoDeadlocks Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmFilters.MaintainOneTerminating Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmProviders.AssociateWithObjects Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmProviders.MaintainIdentifying Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmSublayers.UseOwnOrBuiltIn Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.NetworkDiagnosticsFramework.HelperClass Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.NoAccessViolations Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.NoTamperingWith3rdPartyObjects Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.PacketInjection.NoDeadlocks Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.StreamInjection.NoStreamStarvation Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.SupportPowerManagedStates Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.WFPObjectACLs Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.Winsock Filter.Driver.WindowsFilteringPlatform.Firewall.DisableWindowsFirewallProperly Filter.Driver.WindowsFilteringPlatform.Firewall.NotOnlyPermitAllFilters Filter.Driver.WindowsFilteringPlatform.Firewall.Support5TupleExceptions Filter.Driver.WindowsFilteringPlatform.Firewall.SupportApplicationExceptions Filter.Driver.WindowsFilteringPlatform.Firewall.SupportMACAddressExceptions Filter.Driver.WindowsFilteringPlatform.Firewall.UseWindowsFilteringPlatform Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportAddressResolution Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportDynamicAddressing Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportIPv4 Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportIPv6 Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportNameResolution Filter.Driver.WindowsFilteringPlatform.Scenario.Support6to4 Filter.Driver.WindowsFilteringPlatform.Scenario.SupportAutomaticUpdates Filter.Driver.WindowsFilteringPlatform.Scenario.SupportBasicWebsiteBrowsing Filter.Driver.WindowsFilteringPlatform.Scenario.SupportFileAndPrinterSharing Filter.Driver.WindowsFilteringPlatform.Scenario.SupportICMPErrorMessages Filter.Driver.WindowsFilteringPlatform.Scenario.SupportInternetStreaming Filter.Driver.WindowsFilteringPlatform.Scenario.SupportMediaExtenderStreaming Filter.Driver.WindowsFilteringPlatform.Scenario.SupportMobileBroadBand Filter.Driver.WindowsFilteringPlatform.Scenario.SupportPeerNameResolution Filter.Driver.WindowsFilteringPlatform.Scenario.SupportRemoteAssistance Filter.Driver.WindowsFilteringPlatform.Scenario.SupportRemoteDesktop Filter.Driver.WindowsFilteringPlatform.Scenario.SupportTeredo Filter.Driver.WindowsFilteringPlatform.Scenario.SupportVirtualPrivateNetworking Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.InteropWithOtherExtensions Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.NoEgressModification Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.SupportLiveMigration Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.SupportRemoval Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.SupportReordering |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.AppContainers.SupportModernApplications
WFP-based products must not block App Container apps operating within their declared network intentions by default, and should only do so when following specific user/admin intention or protecting the system against a specific threat
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products must not block App Container apps operating within their declared network intentions by default, and should only do so when following specific user/admin intention or protecting the system against a specific threat
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.CleanUninstall
WFP-based products stop cleanly and clean up all running state upon uninstall
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This is to ensure that host firewalls do not leave unused objects upon uninstall, thereby potentially causing diagnostic issues if another separate host firewall is installed on the same PC. The following WFP objects need to be cleaned up: Provider, providerContext, Filter, subLayer, or callout In addition, additional installation requirements for applications (via the Software certification program) must be met. Design Notes: Applications can use either an MSI, or other installer that meets this requirement to ensure a satisfactory install/uninstall experience on a Windows based PC. The installation requirements for applications (in the Windows 7 Client Software Logo Program) are located in the following link: https://www.microsoft.com/downloads/details.aspx?FamilyID=27028822-B172-4CEC-91A3-26B610A4DA79&displaylang=en.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.ConnectionProxying.NoDeadlocks
WFP-based products which redirect or proxy at redirect layers (connect redirect), must use the new proxying API so that other WFP-based products can determine that the connection has been proxied.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products which redirect or proxy at redirect layers (connect redirect), must use the new proxy'ing API so that other WFP-based products can determine that the connection has been proxy'ed.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmFilters.MaintainOneTerminating
WFP-based products must create and maintain at least 1 terminating FWPM_FILTER object.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
A terminating filter is one that returns a permit / block decision. It may exist as a static filter or within a callout. The intent behind this requirement is to ensure premium host firewalls perform at least one permit or block decision and not simply maintain filters only for inspection purposes, whereas basic host firewalls may do so through WFP or through other means such as TDI, NDIS, WinSock LSP filters. Design Notes:The definition for the FWPM_FILTER object can be found in the following URL:https://go.microsoft.com/fwlink/?LinkID=116902&clcid=0x409.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmProviders.AssociateWithObjects
WFP-based products must associate all of their Provider Contexts, Filters, Sublayers, and Callouts with their corresponding identifying provider object
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
For examples that illustrate the code behavior expected for various types of objects please see below:Reference the name & product of the company within an identifying provider object: const PWSTR pCompanyName = L"Microsoft Corporation"; const PWSTR pProductName = L"Windows Firewall"; FWPM_PROVIDER0 myProvider; myProvider.displayData.name = pCompanyName; myProvider.displayData.description = pProductName; Initialize the provider object:FWPM_PROVIDER_CONTEXT0 myProviderContext;FWPM_PROVIDER0 myProvider;myProviderContext.providerKey = &(myProvider.providerKey);Initialize the subLayer object & associate it to your respective provider objectFWPM_SUBLAYER0 mySubLayer;FWPM_PROVIDER0 myProvider;mySubLayer.providerKey = &(myProvider.providerKey); Initialize the callout object & associate it to your respective provider objectFWPM_CALLOUT0 myCallout;FWPM_PROVIDER0 myProvider;myCallout.providerKey = &(myProvider.providerKey); Initialize the Filter object & associate it to your respective provider objectFWPM_FILTER0 myFilter;FWPM_PROVIDER0 myProvider;myFilter.providerKey = &(myProvider.providerKey);
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmProviders.MaintainIdentifying
WFP-based products must create and maintain at least 1 identifying FWPM_PROVIDER provider object
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
An "identifying provider object" must reference the name & product of the company as shown in the example below. FWPM_PROVIDER01. All vendors must create and maintain at least 1 provider.2. The provider.displayData.Name must contain the name of the company3. The provider.displayData.Description must contain the name of the productAll objects created & "owned" by the vendor must reference only their provider(s)const PWSTR pCompanyName = L"Microsoft Corporation";const PWSTR pProductName = L"Windows Firewall";FWPM_PROVIDER0 myProvider; myProvider.displayData.name = pCompanyName;myProvider.displayData.description = pProductName;Design Notes:The definition of the FWPM_PROVIDER object can be found in the following URL: https://go.microsoft.com/fwlink/?LinkID=116844&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.FwpmSublayers.UseOwnOrBuiltIn
WFP-based products must use only their own sublayer or one of the built-in sublayers
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
A host firewall's own sublayer may be used to ensure that its filters must not be bypassed by a higher weight filter from another host firewall. In addition, a host firewall must not override filters belonging to another host firewall.Design Notes:The definition for the FWPM_SUBLAYERobject can be found in the following URL:https://go.microsoft.com/fwlink/?LinkID=116845&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.NetworkDiagnosticsFramework.HelperClass
WFP-based products must include a Network Diagnostics Framework (NDF) helper class that extends the Filtering Platform helper class (FPHC)
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
The Windows Filtering Platform (WFP) includes a Network Diagnostics Framework (NDF) helper class, called the Filtering Platform helper class (FPHC). FPHC can help identify the root causes of connectivity issues caused by WFP. A host firewall can invoke its own NDF helper class. FPHC extensibility allows these third-party helper classes to be invoked during diagnostics.FPHC can identify WFP as the cause of a connectivity issue. If available, FPHC can also identify the provider that created the filter that is blocking network traffic. FPHC passes this information to NDF, which in turn can then notify the user that WFP is causing the connectivity problem and give the name of the provider blocking traffic.However, the FPHC cannot suggest a corrective action to the user, nor can it provide the reason that the filter is blocking traffic to the user. Only a FPHC extension can perform those tasks.Host firewalls must be able to successfully diagnose the inbound/outbound connection failures caused due to the host firewall, and provide an appropriate response to the end-user based on the diagnosis. (eg. Repair mechanism, message explaining to the user the reason why the connection failed, etc).Design Notes:More information regarding NDF and FPHC can be found in the following links:NDF : https://go.microsoft.com/fwlink/?LinkID=125463&clcid=0x409FPHC : https://go.microsoft.com/fwlink/?LinkID=125464&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.NoAccessViolations
WFP-based products must not be the resulting cause of any Access Violation under high load or during driver load/unload
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products must not be the resulting cause of any Access Violation under high load or during driver load/unload (while under network load or not).
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.NoTamperingWith3rdPartyObjects
WFP-based products must not attempt to remove or alter another WFP-based product's WFP objects and built-in objects
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This ensures interoperability between multiple host firewalls' WFP objects within the Operating System.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.PacketInjection.NoDeadlocks
WFP-based products must not continually modify network packets that have already been modified and re-injected, so as to create potential deadlocks
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Firewalls may use callouts to modify and re-inject network packets, when filtering at any layer. One or many host firewalls may be present on the same system. In the case where only one host firewall is present on the system, continually modifying & re-injecting the same packets may result in reduced performance and is to be avoided. In the case where multiple host firewalls (with callouts) are present on the system, the same network packet(s) may continually be modified by multiple callouts, When a host firewall continually modifies and reinjects the same packet it may result in the network packet never getting processed and could potentially create a deadlock, which is to be avoided. Host firewalls must not modify and reinject the same network packet more than 2 times per layer. If such a situation occurs, host firewalls may choose to let the packet go through, or drop the network packet.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.StreamInjection.NoStreamStarvation
WFP-based product callouts at FWPM_LAYER_STREAM must not starve ( ANDY TANG: What is the meaning of must not starve? How do we measure that?) the data throughput
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
To "Not Starve" means Stream layer callout indications should not be pended to queue up more than 8MB of data.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.SupportPowerManagedStates
WFP-based products must ensure network connectivity upon recovering from power managed states
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Tests must be run on a machine that supports all the power states (standby, hibernate, hybrid, shutdown, restart). Host Firewalls allow the system to enter into and recover from the above mentioned power managed states. Upon resuming from those particular power managed states requirements from WFP, should be met. Firewalls should never pend packets such that a power state change refuses to work due to the pended packets
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.WFPObjectACLs
WFP-based products must ACL all of their objects in a way that any other WFP-based product can at least enumerate those objects using the corresponding WFP enumeration APIs
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products must ACL all of their objects in a way that any other WFP-based product can at least enumerate those objects using the corresponding WFP enumeration APIs.This is to make sure that all WFP objects on the system can be enumerated by any Host firewall or application for diagnostic purposes.Design Notes:As an example, Filter objects must be able to be enumerated by the FwpmFilterEnum function documented in the following URL: https://go.microsoft.com/fwlink/?LinkID=116839&clcid=0x409Similarly, enumeration functions for other objects (provider, sublayer etc) can be found in the following URL: https://go.microsoft.com/fwlink/?LinkID=116840&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.Winsock
Kernel Mode Filter Drivers are architected to maximize the reliability and functionality of Windows Sockets, as well as interact accurately with the core components of the operating system
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Kernel Mode Filter Drivers are architected to maximize the reliability and functionality of Windows Sockets, as well as interact accurately with the core components of the operating system. Some areas of particular interest are:
Winsock
Winsock API functionality
Information about Winsock APIs can be found at:https://msdn.microsoft.com/library/ms740673(VS.85).aspx
Additional Information
Enforcement Date |
Dec. 01, 2010 |
Filter.Driver.WindowsFilteringPlatform.Firewall.DisableWindowsFirewallProperly
Host firewalls must disable Windows Firewall using only the supported method.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Host firewalls are provided the ability to selectively turn parts of Windows Firewall on or off. These parts specify different types of rules (and subsequently filter sets), and may also be referred to as categories. Filter sets that may be selectively turned off are Boot-Time Filters, Firewall Filters, Connection Security Filters, and Stealth Filters. The 'Register' interface is supported by the HNetCfg.FwProducts COM object. The put_DisplayName() call must be used to fill in your product information. Before turning off the firewall rules category, vendor firewalls must ensure that all filters must be installed. This requirement ensures better interoperability with Windows. In addition, if all installed host firewalls on the system are uninstalled for any reason, Windows Firewall is aware of this, and will automatically turn on the firewall filters, ensuring that the system is always protected. The Connection Security filters need to remain enabled to keep Windows scenarios protected. Specifically, the Connection Security filters ensure that the system supports communications which require authentication and encryptionDesign Notes: This requirement ensures that firewall vendors disable Windows Firewall per documented guidelines.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Firewall.NotOnlyPermitAllFilters
Host firewalls must not have only "permit_all" filters
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Host firewalls must not circumvent the intent of the Windows Filtering Platform API tests, by simply maintaining all 'permit_all' filters for all kinds of network traffic, which essentially is not meaningful filtering of network traffic. This applies to both, static as well as callout filters. Similarly, Host firewalls must not maintain only 'block_all' filters. However, that will be addressed when testing for consumer scenarios
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Firewall.Support5TupleExceptions
All host based firewalls must be able to Block/Allow by 5-Tuple Parts (including Port (ICMP Type and Code, UDP and TCP) IP Address, Protocol (e.g. UDP/TCP/ICMP)
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
All host based firewalls must be able to Block/Allow by 5-Tuple Parts (including Port (ICMP Type and Code, UDP and TCP) IP Address, Protocol (e.g. UDP/TCP/ICMP)
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Firewall.SupportApplicationExceptions
WFP-based products must support exceptions from corresponding applications
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
In addition to supporting scenarios based on applications within Windows it is important to support applications (installed by the home user), that are registered with the host firewall for filtering purposes. Firewalls may use parameters such as path, ports, etc as basis to permit or block application specific traffic. This scenario will need to work with native IPv4, native IPv6, 6to4 and Teredo packets.The word 'support' refers to the host firewall's capability to ensure exceptions from applications work with the host firewall, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Firewall.SupportMACAddressExceptions
All host based firewalls which have filters in L2 (Native/Mac) layers must be able to Block or Allow by Mac Address
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
All host based firewalls which have filters in L2 (Native/Mac) layers must be able to Block or Allow by Mac Address
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Firewall.UseWindowsFilteringPlatform
Firewalls must comply with Windows Filtering Platform based APIs for filtering network traffic on home user solutions
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
There must be no TDI, NDIS, WinSock LSP filters present upon installation of the host firewall on the PC. Only Windows Filtering Platform (WFP) based static filters / callouts must be used on home user products.Design Notes:For more information on Windows Filtering Platform, please see the following link: https://go.microsoft.com/fwlink/?LinkID=116899&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportAddressResolution
WFP-based products must support allowing for successful ARP and ICMP Neighbor Discovery exchanges
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products must support ARP (for IPv4) and ICMP Neighbor Discovery (for IPv6) exchanges.Firewalls allow for the system to send out ARP and ICMP Neighbor Discovery requests and replies, as well as receive ARP and ICMP Neighbor Discovery requests and repliesThe word 'support' refers to the host firewall's capability to make ARP work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:Host firewalls should allow the PC to send out ARP request on behalf of another node rather than only on behalf of itself, when ICS running on the host.As part of Internet Connection Sharing's (ICS) DHCP functionality, ICS DHCP can send out ARP requests on behalf of another node in the subnet.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportDynamicAddressing
WFP-based products support allowing for successful DHCP exchanges over both IPv4 and IPv6
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Host Firewalls support allowing successful DHCP exchanges over both IPv4 and IPv6.DHCP DISCOVER, DHCP REQUEST & DHCP INFORM packets can be transmitted over Outbound UDP Source Port 68 to Destination Port 67. DHCP OFFER & DHCP ACK & DHCP NACK packets can be received over Inbound UDP Source Port 67 to Destination Port 68. DHCPv6 packets can be transmitted over Outbound UDP Source Port 546 to Destination Port 547. DHCPv6 packets can be received over Inbound UDP Source Port 547 to Destination Port 546. The word 'support' refers to the host firewall's capability to allow successful DHCP exchanges, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc. to support the required functionality, even though the functionality may not be enabled by default in the UI.Design Notes:Details can be found in the following URL: https://go.microsoft.com/fwlink/?LinkID=116834&clcid=0x409Host firewalls should allow DHCP inbound and outbound as the server over the wireless interface when a service like ICS is running on the host.Internet Connection Sharing (ICS) acts as a DHCP server and expects to receive incoming DHCP clients.DHCP DISCOVER, DHCP REQUEST & DHCP INFORM packets can be received over Inbound UDP Source Port 68 to Destination Port 67. DHCP OFFER & DHCP ACK & DHCP NACK packets can be transmitted over Outbound UDP Source Port 67 to Destination Port 68.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportIPv4
WFP-based products must support IPv4 traffic
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This is to ensure that consumer host firewalls or other filtering components do not cause loss of basic IPv4 connectivity on the PC. The word 'support' refers to the host firewall's capability to make IPv4 work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI.Design Notes:More information about IPv4 RFCs can be found in the following link: https://go.microsoft.com/fwlink/?LinkID=116835&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportIPv6
WFP-based products must support IPv6 traffic
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Windows has IPv6 enabled by default. Host firewalls should not break native IPv6 connectivity (and therefore, Windows scenarios based on IPv6) for customers. The word 'support' refers to the host firewall's capability to make IPv6 work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI.Design Notes:More information about IPv6 can be found in the following link: https://go.microsoft.com/fwlink/?LinkID=116832&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.NetworkingFundamental.SupportNameResolution
WFP-based products must support allowing for successful DNS client queries
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
DNS QUERY packet can be sent out over [Outbound UDP Destination Port 53 (Domain Name Server)] and DNS QUERY RESPONSE packet to be received over [Inbound UDP Source Port 53 (Domain Name Server)]. Host firewalls should allow successful DNS client queries over both IPv4 and IPv6. The word 'support' refers to the host firewall's capability to allow successful DNS client queries, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:More information aboutDNS RFCs can be found in the following link: https://go.microsoft.com/fwlink/?LinkID=116835&clcid=0x409Host firewalls should allow this type of DNS traffic (Host as a server) over the wireless interface when a service like ICS is running on the host.This requirement applies to Internet Connection Sharing that acts as a DNS server (proxy) and expects receiving incoming DNS requests from clients on destination UDP port 53, and respond to the DNS client with DNS response with destination UDP port 53.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.Support6to4
WFP-based products must support 6to4
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
In certain markets, 6to4 technologies may help certain customers move to IPv6 connectivity. The following guidelines may help meet this requirement:
Host firewalls allow for the system to send and receive IPv6 packets over IPv4 protocol 41.
The word 'support' refers to the host firewall's capability to 6to4 work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:Please refer to the following article below for further information on 6to4:https://go.microsoft.com/fwlink/?LinkID=116837&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportAutomaticUpdates
WFP-based products must support Automatic Updates in Windows
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This is related to Automatic Updates / Windows Update (WU), which is a key scenario through which important patches are installed on your PC to keep it up to date. The following guideline may help meet this requirement:
Host firewalls allow outbound TCP connections to Destination Ports 80 & 443.
The word 'support' refers to the host firewall's capability to make Automatic Updates work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:For more information on Windows Updates/ Automatic Updates, please see the following link: https://go.microsoft.com/fwlink/?LinkID=116898&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportBasicWebsiteBrowsing
WFP-based products must support basic internet browsing experiences
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This is to ensure that basic internet browsing experiences are supported upon installation of a host firewall on a Windows based computer.Host firewalls must allow TCP packets over Ports 80 and 443 to support this scenario. This scenario must work with native IPv4, native IPv6, 6to4 and Teredo packets. The word 'support' refers to the host firewall's capability to ensure a successful internet browsing experience, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportFileAndPrinterSharing
WFP-based products must support file and printer sharing
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This is to ensure that home-users will be able to share content to and from other PCs inside of their home network, in addition to printing content on shared printers. Host firewalls must allow UDP packets specific to protocol 17 over Ports 137 / 138, and TCP packets specific to protocol 6 over ports 139/445. This scenario must work with native IPv4, native IPv6, 6to4 and Teredo packets. The following is not a requirement but is a requirement. TCP packets should be allowed over ports 5357/5358 & UDP packets should be allowed over port 3702. This scenario should work with native IPv4, native IPv6, 6to4 and Teredo packets. The word 'support' refers to the host firewall's capability to make file and printer sharing work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:Please refer to the following link for more information: https://go.microsoft.com/fwlink/?LinkID=116838&clcid=0x409 In Windows 7, HomeGroup enables users to easily share files and printers between computers.Please refer to the following documents for more information:
HomeGroup Firewall Requirements: https://technet.microsoft.com/appcompat/default.aspx
Network Location Dialog: https://technet.microsoft.com/appcompat/default.aspx
PNRP: https://technet.microsoft.com/appcompat/default.aspx
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportICMPErrorMessages
WFP-based products must support ICMP error messagesand discovery functions
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This is to ensure that host firewalls support ICMP error messages (per IETF RFCs 4890 and RFC 2979), for inbound/outbound packets that must not be dropped. Important discovery functions must also be supported. The specific error messages that need to be supported for both ICMPv4 and ICMPv6 are: Destination Unreachable, Time Exceeded and Parameter Problem. In addition, for ICMPv6, Packet too big, Router solicitation, Neighbor solicitation, Router advertisement, and neighbor advertisement discovery functions must be supported. The word 'support' refers to the host firewall's capability to make ICMP work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:For more information please see https://go.microsoft.com/fwlink/?LinkID=116835&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportInternetStreaming
WFP-based products must support Internet streaming and Media sharing for media player network sharing services
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
This is related to Automatic Updates / Windows Update (WU), which is a key scenario through which important patches are installed on your PC to keep it up to date. The following guidelines may help meet this requirement:Host firewalls allow outbound TCP connections to Destination Ports 80 & 443.The word 'support' refers to the host firewall's capability to make Automatic Updates work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:For more information on Windows Updates/ Automatic Updates, please see the following link: https://go.microsoft.com/fwlink/?LinkID=116898&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportMediaExtenderStreaming
WFP-based products must support media streaming scenarios based on extender technologies
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Extender technology is built into home entertainment devices such as TVs, DVD players, and cool, quiet components that allow you to keep your PC where it makes sense and use it as a "hub" to provide your digital entertainment to TVs throughout your house. These devices are called extender devices. For example: With the new Extenders for Windows Media Center, you can stream the digital media you have on your Windows Media Center PC in as many as five rooms in your house. Home-users may access the live and recorded TV, music, movies, videos, sports, Internet TV and other online content on Windows PCs through wired or wireless home networks. Windows Media Center Extenders use network ports to communicate with Windows PCs. The following exceptions tabled below may be useful in meeting this requirement:
Media Center Extender SPECIFIC |
|||
Binary |
Port |
Direction |
Scope |
svchost.exe (ssdpsrv) |
UDP 1900 |
Inbound |
Local Subnet |
svchost.exe (termservice) |
TCP 3390 |
Inbound |
Local Subnet |
svchost.exe (QWave) |
TCP 2177 |
Outbound, Inbound |
Local Subnet |
svchost.exe (QWave) |
UDP 2177 |
Outbound, Inbound |
Local Subnet |
System |
TCP 10244 |
Outbound, Inbound |
Local Subnet |
ehshell.exe |
TCP 554 |
Outbound, Inbound |
Local Subnet |
ehshell.exe |
UDP 5004, 5005 |
Outbound, Inbound |
Local Subnet |
ehshell.exe |
TCP 8554-8558 |
Outbound, Inbound |
Local Subnet |
ehshell.exe |
UDP 50004-50013 |
Outbound, Inbound |
Local Subnet |
ehshell.exe |
UDP 7777-7781 |
Outbound, Inbound |
Local Subnet |
mcrmgr.exe |
random |
Outbound |
Internet |
mc2prov.exe |
random |
Outbound |
Internet |
Svchost.exe (mcs2svc) |
random |
Outbound |
LocalSubnet |
Media Center Binaries/Ports |
|||
ehrecvr.exe |
random |
Outbound |
Internet |
ehrec.exe |
random |
Outbound |
Internet |
ehexthost.exe |
random |
Outbound, Inbound |
Internet |
mcupdate.exe |
random |
Outbound |
Internet |
Digital Cable Receiver Device (OCUR) |
|||
ehprivjob.exe |
UDP 5001-5006 |
Inbound |
Local Subnet |
svchost.exe |
UDP 1900 |
Outbound, Inbound |
Local Subnet |
System |
TCP 2869 |
Outbound, Inbound |
Local Subnet |
ehprivjob.exe |
TCP 554 |
Outbound |
Local Subnet |
ehprivjob.exe |
UDP 5757-5772 |
Outbound |
Local Subnet |
The word 'support' refers to the host firewall's capability to make internet streaming & media sharing for media player network sharing services, work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportMobileBroadBand
WFP-based products must allow mobile broadband devices that are compliant with Windows mobile broadband driver model to function correctly
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products must allow mobile broadband devices that are compliant with Windows mobile broadband driver model to function correctly.This is to ensure that host firewall functionality does not block the mobile broadband connectivity and the firewall functionality works with MB devices.Windows provides native support for mobile broadband (MB) data cards & embedded modules to work with Windows. The MB devices need to implement their driver as per Windows mobile broadband driver model. The MB driver model defines how the devices should be exposed to Windows and network packet format in which MB devices should exchange data between network and system.Design Notes:Following links provide more information about the Windows 7 mobile broadband driver model https://msdn.microsoft.com/network/dd579153.aspx https://msdn.microsoft.com/library/dd445735.aspx https://msdn.microsoft.com/library/dd445729.aspx
Additional Information
Enforcement Date |
Jun. 01, 2010 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportPeerNameResolution
WFP-based products must support Peer Name Resolution Protocol and the Peer-to-Peer Grouping Protocol
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Host firewalls support the Peer Name Resolution Protocol (PNRP) and the Peer-to-Peer Grouping Protocol, which are required by some Peer-to-Peer applications. The Peer Name Resolution Protocol provides secure, serverless name resolution, and the Peer-to-Peer Grouping Protocol provides secure, reliable multi-party communication. The following guidelines may be useful in meeting this requirement:
Host firewalls support native IPv6 (NETWORK-0244) as well as Teredo (NETWORK-0248) and IPv6 packets to IPv4 protocol 41 (^to4) (NETWORK-0249).
Host firewalls can allow for the system to send outbound, and receive inbound, UDP packets over port 3540.
Host firewalls can allow for the system to send outbound, and receive inbound, TCP packets over port 3587.
The word 'support' refers to the host firewall's capability to allow successful DHCP exchanges, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes: In Windows 7, HomeGroup enables users to easily share content and stream media between computers. P2P and PNRP are key components of HomeGroup.Please refer to the following documents for more information, these documents:
HomeGroup Firewall Requirements: https://technet.microsoft.com/appcompat/default.aspx
Network Location Dialog: https://technet.microsoft.com/appcompat/default.aspx
PNRP: https://technet.microsoft.com/appcompat/default.aspx
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportRemoteAssistance
WFP-based products must support Remote Assistance scenarios
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
The Remote Assistance scenario is used for a helper to connect to a computer and to show the user a solution to the problem. The following guidelines may help meet this requirement:Host firewalls allow the computer to be reached by native IPv4, native IPv6, Teredo, and 6to4 (pass the corresponding tests) and also allow traffic from the Remote Assistance application within Windows (msra.exe) through the firewall. The word 'support' refers to the host firewall's capability to make Remote Assistance work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:For information on how Remote Assistance works in general please see the article below:https://go.microsoft.com/fwlink/?LinkID=116842&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportRemoteDesktop
WFP-based products must support Remote desktop
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Remote Desktop Connection is a technology that allows you to connect to a remote computer in a different location. Remote desktop is a key Windows scenario that would be relevant for consumers with multiple PCs at home trying to access content that exists on one PC, from another PC. The following guideline may help meet this requirement:Host firewalls allow inbound TCP packets over Destination Port 3389 to support this scenario. This scenario will need to work with native IPv4, native IPv6, 6to4 and Teredo packets. The word 'support' refers to the host firewall's capability to make remote desktop work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:For more information on remote desktop please see the article below:https://go.microsoft.com/fwlink/?LinkID=116841&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportTeredo
WFP-based products must support Teredo
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
Teredo may be used as a connectivity mechanism to support certain Windows scenarios such as remote assistance, instant messaging and others. Hence preserving Teredo connectivity is critical to supporting Windows consumer scenarios. For this requirement, the following must be met:
Host firewalls allow DNS resolution of teredo.ipv6.microsoft.com.
To allow client to Teredo server communication, Host firewalls must allow for the system to send outbound UDP/IPv4 packets to UDP port 3544.
To allow Teredo connectivity, host firewalls must allow inbound and outbound UDP/IPv4 traffic over the Teredo client system ports. These ports can be obtained using the FWPMSystemPortsGet notification to determine the system port numbers used for communication using the Teredo interface.
Host firewalls support ICMP error messages & discovery functions (NETWORK-0250 logo requirement)
Host firewalls allow UPnP framework packets over UDP port 1900, and UPnP frameworkpackets over TCP port 2869
The word 'support' refers to the host firewall's capability to make Teredo work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:Please refer to the following article below for further information on Teredohttps://go.microsoft.com/fwlink/?LinkID=116836&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.SupportVirtualPrivateNetworking
WFP-based products must support VPN scenarios in Windows
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
The following protocols and ports must be allowed:
IP protocol 50: Allow ESP traffic
IP protocol 51: Allow AH traffic
UDP Port 500 / 4500: Allow ISAKMP traffic
TCP / UDP Port 88: Allow Kerberos traffic
This ensures that firewalls support IPsec scenarios, such as IPsec VPN, which are used on client PCs to connect securely over the internet. In addition, host firewalls should allow successful IPsec communication over both IPv4 and IPv6. Host firewalls should also allow UDP packets over port 1701, and TCP packets over port 443 to support this scenario. It is also recommended that host firewalls allow TCP packets specific over port 1723. IP protocol 47 based packets should also be allowed by the host firewall. The word 'support' refers to the host firewall's capability to make the VPN scenarios work, if the application/user/network needs it. The host firewall must also have properly configured objects such as filters, etc to support the required functionality, even though the functionality may not be enabled by default in the UI. Design Notes:Please refer to the following article for further information: https://go.microsoft.com/fwlink/?LinkID=116843&clcid=0x409
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.InteropWithOtherExtensions
WFP must not block traffic from another vSwitch extension (WFP or LWF) by default, and should only do so when following specific user/admin intention or protecting the system against a specific threat.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP must not block traffic from another vSwitch extension (WFP or LWF) by default, and should only do so when following specific user/admin intention or protecting the system against a specific threat.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.NoEgressModification
WFP-based products that operate in the vSwitch must not modify packets on the Egress path of the vSwitch.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products that operate in the vSwitch must not modify packets on the Egress path of the vSwitch.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.SupportLiveMigration
WFP-based products that operate in the vSwitch must present a minimal MOF for Live Migration.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products that operate in the vSwitch must present a minimal MOF for Live Migration. In the MOF it must declare itself Logo compliant for Live Migration and allow itself to be migrated or not block migration by default. The total time for migrations for Live Migration cannot be longer than 2 seconds.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.SupportRemoval
WFP-based products that operate in the vSwitch must present be allowed to be removed when the admin disabled WFP for the vSwitch instance.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products that operate in the vSwitch must be allowed to be removed when the admin disabled WFP for the vSwitch instance.
Additional Information
Enforcement Date |
Jun. 01, 2009 |
Filter.Driver.WindowsFilteringPlatform.Scenario.vSwitch.SupportReordering
WFP-based products that operate in the vSwitch must respond to WFP vmSwitch reorder events.
Target Feature |
Filter.Driver.WindowsFilteringPlatform |
Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64 Windows 8.1 Client x86, x64 |
Description
WFP-based products that operate in the vmSwitch must respond to WFP vmSwitch reorder events.
Additional Information
Enforcement Date |
Jun. 01, 2009 |