8/4/2004 Of particular interest to me and this project are the two following sentences from the above Microsoft article:
If packets with specific IP addresses or TCP/UDP port numbers must be filtered, consider creating a user-mode application that uses the Packet Filtering API instead. The Packet Filtering API optimizes the system-supplied IP filter driver to process packets without the overhead that is associated with a filter-hook driver.

8/4/2004 Network devices and protocols: Windows DDK

8/4/2004 Don't mind this, these are my notes - NDIS Intermediate drivers
Windows security page
8/4/2004 I may terminate this project. Microsoft "IS" activating its ICF firewall in service pack 2. I will move this project to "Old projects page" and will now be a "Low priority". Upon release of updated ICF SP2 I will utilize the firewall and evaluate functionality. I suspect Microsoft will be sued by the firewall companies now because the software is pre-loaded in XP. I don't have much confidence with MS and security - look at the mess they have created today with needing anti-virus, pop up blockers, cookie blocks, firewalls!?!?!?!

8/29/2004 I have to say that Microsoft has impressed me with service pack 2, I'm certainly enjoying the pop up blocker. I'm not using and have not tried the Microsoft provided firewall - "GREAT JOB MS!"

Unless I get totally bored I won't be looking to start this project up again.

Internet Connection Firewall in SP2
ICF for SP2 will include a host of new features. This paper will discuss five 
of them that will have some impact on existing applications: 

On by default. Prior to SP2, Windows XP shipped with ICF disabled by default; 
users either needed to run a wizard or navigate through the Network 
Connections folder to enable ICF. By enabling ICF by default, the computer 
will be protected from many network based attacks. For example, if ICF had 
been enabled by default the recent Blaster attack would have been greatly 
reduced in impact, regardless of whether users were up to date with patches. 
This may have an impact on existing applications if the application does not 
work with stateful filtering by default. 

Boot time security. In earlier versions of Windows there is a window of time 
between when the network stack started and when ICF provided protection. 
Consequently, a packet could have been received and delivered to a service 
without ICF filtering it, potentially exposing the computer to 
vulnerabilities. In SP2, the firewall driver has a static rule called a boot-
time policy to perform stateful filtering. This will allow the computer to 
perform basic networking tasks such as DNS and DHCP and communicate with a 
Domain Controller to obtain policy. Once the firewall service is running, it 
will load and apply the run-time ICF policy and remove the boot-time filters. 
This change should increase system security without affecting applications. 

Application white list. Prior to SP2, applications needed to call the ICF APIs 
to enable the necessary listening ports to be open to send and receive 
messages. This proved difficult in peer-to-peer situations when the port was 
not known in advance. Further, it was up to the application to close the hole 
in the firewall, which could lead to unnecessary openings in the firewall 
should the application terminate unexpectedly. Additionally, these holes could 
only be opened by applications running in the security context of a local 
administrator. In SP2, an application that needs to listen to the network can 
be added to the Application White List. An application on the white list will 
have the necessary listening hole created automatically. By having an 
application on the white list, only necessary ports are opened, and they are 
only opened for the duration that the application is listening on it. This 
prevents an application from opening up a port it's not using and either 
deliberately or inadvertently exposing another application or service to 
network traffic from that port. Further, this also allows applications 
listening to the network to run as a regular user. Applications that work with 
stateful filtering do not need to be placed on the white list. Only 
administrators can add an application to the white list. 

RPC support. In earlier versions of Windows, ICF blocked RPC communication, 
causing functions such as file and print sharing and remote administration to 
fail. This was because the RPC process image filename was the same for many 
RPC servers (svchost.exe). SP2 enables granular control of which RPC services 
have the ability to traverse ICF. When opening a port, a caller may claim that 
the port is to be used for RPC. ICF will only accept this claim if the caller 
is running in the Local System, Network Service, or Local Service security 
contexts. ICF supports a profile level flag that enables RPC ports to be 
opened even if the caller is not on the Application White List: 
PrivilegedRpcServerPermission. By having granularity, administrators can 
control which RPC services are exposed to the network, limiting communication 
to only those who need it. 

"Shielded" mode. In the event a malicious application that finds and exploits 
a vulnerability in one of the listening Windows services is threatening users, 
SP2 introduces a setting to ICF, code-named "shielded" mode. This mode enables 
users to easily protect themselves by switching ICF to prevent all unsolicited 
inbound traffic until a patch is available, without having to reconfigure the 
firewall. When in this operation mode, the computer cannot listen for requests 
that originate from the network. Outgoing connections are the only connections 
that succeed. Any API call to open up a static hole will be allowed and the 
configuration stored, but it will not be applied until the ICF operational 
mode switches back to normal operation.