[vpn-help] VPN Client Road Map Modifications ...

[Matthew Grooms]

All,

	With version 1.1 of the VPN Client on the horizon, I wanted to make an 
announcement concerning some recent changes to the 'VPN Client Road Map 
and Future Versions' page of the website.

http://www.shrew.net/vpn/todo.php

	The page is now a more accurate representation of the current 
development plan and goals. If you have reviewed the Road Map recently, 
you may have noticed that a 2.0 release involves changes to the kernel 
driver architecture. After some serious thought, I have decided to fast 
track the new architecture in an effort to correct certain design flaws 
of the 1.x series.

	As the VPN Client has matured, the user-land components have seen a 
great deal of improvement. The kernel driver components were completed 
and stabilized as early as possible and have remained mostly unchanged 
during the life of the 1.x series. While the simplistic nature of these 
drivers was a win for quick implementation and stability, they simply do 
not offer flexibility that future products require. A more forward 
looking model has been chosen and an initial implementation has been 
developed.

Current Driver Architecture :

   IPSECC
   IPSECD
==========
IP | VPROT
----------
NIC | VNET

	In this diagram, everything above the double line is a user-land 
component and everything below is an NDIS kernel component. The VPROT 
driver is an NDIS Protocol driver that sits parallel to the MS TCP/IP 
driver. The VNET driver is an NDIS Miniport driver that sits parallel to 
other network card drivers. The VPROT driver is used to send and receive 
public traffic and the VNET driver is used to send and receive private 
traffic.

Future Driver Architecture :

   IPSECC
   IPSECD
==========
     IP
----------
    VFLT
----------
NIC | VNET

	As you can see, the new kernel driver architecture is quite different. 
The major change is that the NDIS Protocol driver has been supplanted by 
an NDIS Intermediate Filter driver. Since an Intermediate driver sets 
between NDIS Protocol and Miniport drivers, the client will now be able 
to interact with packets that are passed to Miniports other than VNET. 
The second advantage is that packets can be injected below the MS TCP/IP 
layer and intercepted before they are allowed to pass back up to higher 
level protocols. Lastly, VNET can be dumbed down to nearly a do-nothing 
stub driver as all traffic inspection and redirection can be handled at 
the Intermediate driver layer.

	While it will take some time to fully stabilize these new kernel 
drivers, the bulk of the initial work has already been completed. With 
the new model in place, the following changes are now possible ...

1) Prevent TCP/IP from responding with 'unkown UDP port' ICMP messages
2) Add support for VPN tunnels using public interface addresses
3) Add support for in-kernel ESP processing
4) Add support for an optional client side firewall

	After all the required functionality has been added to the kernel 
drivers and stability has been achieved, I will begin the process of 
submitting the components to Microsoft for WHQL certification. After the 
components are certified, digitally signed driver packages can be 
distributed with the VPN Client Software. I hope to make this happen 
before the end of the 2.x series.

Thanks,

-Matthew