IP Packet Redirector Driver Sample
Questions and Answers

The PCAUSA NetBug Reporter Interviews Thomas F. Divine...

NetBug: Hello, Thomas. I'd like to ask a few questions about the IP Redirector sample. First of all, what is it?

Thomas: The IP Redirector is tool that provides the capability for a user-mode application to filter IPv4 and ARP packets as they are sent and received on a Windows platform. The user-mode application can inspect each packet, modify packets, drop packets and inject its own packets as it sees fit. As far as these types of packets are concerned the user-mode application has total control of the packet flow.

The current product is derived from an earlier "Packet Redirector" (PktRedir) product that was originally developed as a NDIS 5 Intermediate (IM) driver for Windows 2000. The PktRedir was used fairly widely through Windows XP. This offering includes a substantial reliability improvements to the NDIS 5 driver as well as a NDIS 6 Lightweight filter (LWF) that extends support to Vista and later platforms.

NetBug: Lets get to it, Tom. I would think that user-mode per-packet filtering would be pretty darn slow. Your own notes on Rawether.net (http://rawether.net/support/KB06300101.htm) clearly show that per-packet transitions from kernel-mode to user-mode are  expensive. What do you have to say about that?

Thomas: That's certainly correct, NetBug. However, for certain applications per-packet user-mode filtering is practical and the expense negligible.

Clearly per-packet user-mode filtering is can only be reasonably applied on lower-bandwidth network interfaces. However there is an abundance of network paths where the IP Redirector fits in nicely.  Lets say that it can be applied to links with throughput less than 100 Mbps. That provides several several niches where IP Redirector fits in:

NetBug: Why did you pick those examples?

Thomas: Well, satellite communication is expensive and slow. Implementing WAN optimization is using IP Redirector is certainly practical. With IP Redirector the outgoing packet can be intercepted in user-mode and then handled by the application. For this sort of optimization packets to be optimized typically are handled in user-mode anyway. For example, they may be re-packaged in UDP datagrams and sent some other way.

NetBug: How can someone tell if the IP Redirector approach actually works and can be used for their application?

Thomas: Good question. PCAUSA offers a download of sample executables. You can find the download URL on the IP Redirector page. These sample executables include an application called User-Mode Transmit/Receive Loop (UMTxRxLoop.exe).

This is a very simple application but it is highly intrusive. Basically every inbound or outbound IPv4 and ARP packet is looped through the application and then re-inserted back into the kernel NDIS stack. You can run this application and observe for yourself the impact that the user-mode loop has on system and network performance. Of course, this loop is a simple user-mode pass-through and additional per-packet processing will slow things down a little more. But, it's a starting point in understanding whether the technique will work for a given application.

NetBug: What did you see when you ran UMTxRxLoop?

Thomas: I tested on a fairly high-end machine, but I was really surprised. Testing was done at the time Windows 7 RTM was being released so many tests were done with UMTxRxLoop running while downloading Windows 7 ISO images. The PCAUSA Internet link is a 4G network and there was almost no difference in throughput on this link with or without the user-mode loop running. CPU utilization was also remarkably low.

NetBug: What is the user-mode API like?

Thomas: There are a few details needed to select the interface to be used and setup some simple filters. But after that the user-mode interface is trivial. For a given interface the user-mode application operates on two Win32 handles:

To intercept packets being sent from the host just make a Win32 ReadFile operation on the upper or host-side handle. What is read is one complete network packet as a flat array of bytes. The data read includes the 14-byte Ethernet header plus the Ethernet payload. To pass the intercepted packet through to the network just pass the buffer that was read to a Win32 WriteFile call on the lower or net-side handle.

It is just as simple to intercept incoming packets. An early customer using IP Redirector got the message. Here's his comment:

"Incidentally at least to me your network framework is much better to work with than Microsoft’s KMDF. As yours are relatively less complicated so there is less chance of them having bugs. The bigger the framework is the greater is the probability of having bugs."

NetBug: Does the user-mode application need to deal with and "NDIS Stuff"?

Thomas: No. The user-mode application simply sees each packet as a flat array of bytes. The IP Redirector user-mode software doesn't impose any further structure than that.

For sure a developer using IP Redirector must have a solid understanding of IP networking and packet structure. However, he or she is free to inspect the packets using whatever tools desired.

The IP Redirector sample user-mode applications include some BSD INet headers that can be used to interpret packet if desired. Because of the simple packet representation simple casts of structure pointers can be used effectively.

Developers familiar with networking on other platforms (Ok, Linux, Unix...) can use IP Redirector without too much trouble. I've seen some pretty fancy code built by customers on this API.

NetBug: What sort of applications do you conceive of that could use the IP Redirector framework?

Thomas: My imagination is not nearly as good as that of potential customers. If the bandwidth is low enough almost anything goes. I've mentioned WAN optimization.

It has always bugged me (Excuse me, NetBug...) that Universities don't use the Windows platform more for low-level network investigation. Seems like it is always some sort of U*n*x teaching platform. I think that the flat packet format provided by IP Redir could be used effectively in the teaching environment. I don't see why IP Redirector couldn't be used to provide a complete programmable network topology that includes features implemented in software.

In this context the IP Redirector samples include a "Virtual Echo" application that simulates a possibly non-existent remote node as far a ICMP Echo is concerned.

Malware research comes to mind as well. IP Redirector can inject arbitrary IPv4 and ARP packets on the network or to the local host.

Prototyping also comes to mind. IP Redirector might need some extensions though...

NetBug: Ok. I want to harp on the downsides of this approach. It is easy to imagine that there would be problems with this approach under power transitions and other edge cases. What do you say?

Thomas: For sure these are scenarios that are critical for any deployed driver and application suite. We focused on these topics quite a bit during development and testing. Scenarios that we tested included:

For sure these scenarios can be handled. Lots of testing under DriverVerifier...

The implementation of the IP Redirector drivers use as many best-practices as possible. For example, IRPs are handled in Cancel-Safe Queues.

NetBug: What are other limitations that you should mention?

Thomas: The current IP Redirector only supports IPv4 and ARP redirection.

And, local traffic (localhost) traffic never reached the NDIS later. So, local intra-host IP traffic cannot be filtered at the NDIS layer.

Process information is not available at the NDIS layer. IP Redirector simply allows you to deal with individual packets. On the plus side, the user-mode application has complete access to all Windows user-mode APIs - some of which are not directly accessible in a NDIS driver.

NetBug: What about packet loss? If I Redirector reads one packet at a time isn't there a chance that packets will be lost between completing one ReadFile and making the next.

Thomas: NetBug you must be reading my mind! Yes that is a potential problem. The NDIS drivers do provide some packet buffering. I believe that the limit is currently about 256 packets that can be queued. When the limit is exceeded then certainly packets will be lost. I can't say that this isn't a problem, but can say that the approach is practical in many cases.

Certainly avoid Gbps and higher interfaces with IP redirector as well as server interfaces with Receive-Side Scaling (RSS) or Chimney Offload.

NetBug: Why would one use IP Redirector instead of the free Windows Filtering Platform (WFP) provided by Microsoft?

Thomas: That would depend on the application. WFP is certainly a powerful tool for the implementation of many types of network filtering products. Customers should certainly investigate whether WFP suits their needs. For sure I would think that firewalls and anti-virus software vendors would be foolish not to use WFP.

WFP is a fairly complex Windows-specific API that must be understood and mastered. WFP includes "hooks" into the Windows kernel-mode driver and the system that are not included in IP Redirector; for example, process information can be determined at some WFP layers.

On the other hand, IP Redirector is simple to understand and use. Customers must use due-diligence and make choices.

Of course, WFP is only available on Vista and later platforms. Supporting Windows XP may be of interest to some customers.

NetBug: Can the user-mode application inject faulty packets to the host or network?

Thomas: Any NDIS driver can inject faulty packets on the network. Any filter driver has the additional ability to send faulty packets "up the stack" to the host. So, yes.

Physical security is the only real security.

NetBug: Any plans to extend IP Redirector to support IPv6? What if a customer needs more than IPv4 and ARP filtering?

Thomas: This depends on customer requests. At present IPv4 is still the mainstay. Of course, PCAUSA is available to make modification to the driver on a contract basis.

NetBug: You say that IP Redirector works on platforms from Windows XP through Windows 7. Don't these platforms support different NDIS versions?

Thomas: Yes of course. IP Redirector includes a NDIS 5 Intermediate (IM) filter for Windows XP and a NDIS 6 Lightweight filter (LWF) for Windows Vista and later. However the use-mode application is mostly platform independent.

And yes: Windows 64-bit editions are supported for Vista and later platforms.

NetBug: Are the IP Redirector drivers WHQL signed?

Thomas: No. They are self-signed by PCAUSA for testing purposes. The driver version information includes comments that the drivers are "Evaluation Only. Not for commercial redistribution!".

PCAUSA feels that drivers should be signed by the company distributing products to the end user. So, the burden is on the IP Redirector customer to acquire WHQL signatures. PCAUSA can assist in obtaining WHQL signature on a contract basis.

NetBug: Does this mean that IP Redirector customers only get evaluation driver binaries?

Thomas: Of course not. IP Redirector customers are provided with complete source code to all components including the drivers. As part of the customer's product development the sample drivers should be rebuilt by the customer using a new name and the external copyrights (viewable in a file's Properties) should be changed to identify the distributor of the end-user product.

NetBug: Are there ongoing royalties required to distribute products derived from IP Redirector?

Thomas: There probably should be, but there are no ongoing royalty requirements at this time. There is a limitation in the length of time that PCAUSA will provide technical support and product updates. If a customer doesn't maintain an ongoing subscription for support from PCAUSA then he or she is on their own.

NetBug: What sort of support is provided with the IP Redirector product?

Thomas: The IP Redirector software is a robust sample suite. PCAUSA will provide whatever support it can in helping customers install and run the sample applications.

However, the product is definitely inexpensive in relationship to the investment made in developing it. So, the price of the product does not include support in the development of the user-mode applications or in the area of making proprietary modifications or extensions to the drivers.

PCAUSA will certainly be pleased to provide consulting services in these areas on a contract basis if desired.

NetBug: How can I get answers to any unanswered questions?

Thomas: Just send me an email. I'll post it below, but you'll have to edit it in the obvious way:

    TDIVINE at PCAUSA dot COM

Thanks for the Q&A NetBug. I hope this has been helpful!

PCAUSA Home · Privacy Statement · Products · Ordering · Support · Utilities · Resources
Mailing Lists  · PCAUSA Newsletter · PCAUSA Discussion List
 

Rawether for Windows and WinDis 32 are trademarks of Printing Communications Assoc., Inc. (PCAUSA)
Microsoft, MS, Windows, Windows 95, Windows 98, Windows Millennium, Windows 2000, and Win32 are registered trademarks and Visual C++ and Windows NT are trademarks of the Microsoft Corporation.
Send mail to webmaster@pcausa.com with questions or comments about this web site.
Copyright © 1996-2010 Printing Communications Assoc., Inc. (PCAUSA)
Last modified: February 04, 2010