Could this be implemented with an NDIS or TDI driver?

From: Steve Jackowski (stevej_at_deterministicnetworks.com)
Date: 04/11/04 

Date: Sun, 11 Apr 2004 08:08:15 -0700

Hi Bill,

As Thomas points out, the advantage to being above the
stack is that you see reassembled data. The main
dissadvantage is that you don't see the actual packets.
Above the stack you can use the TDI interface to see all
traffic, but this interface is complicated to use, may
cause performance problems, and can be different on the
various versions of Windows. So, if you're building a
product that should run across all Windows platforms,
this can be a maintenance nightmare.

An alternative to TDI is to write a layered service
provider (LSP) or to use a product like our ESP which is
an LSP, but you only have to write a DLL plugin to take
actions based on filters. The problem here is that at
the LSP level, you only see data that Winsock
applications are sending and receiving. While most
applications use Winsock, there are some, especially
certain ones provided by Microsoft, that use TDI and
you'd miss that traffic. Also, there are a number of
LSPs being written that don't properly handle multiple
LSPs on the same system, so you can run into support
problems when other people 'break' your product.

Below the stack, you do have the issue of reassembly.
However, depending on what you're filtering for, you may
be able to keep packet to packet state that lets you
avoid implementation of TCP reassembly. If you think
this is a viable approach, you should take a look at our
DNE framework toolkit that enables you to write a single
plugin driver that will run cross-platform (even non-
Windows). Because most VPN clients use DNE and DNE
handles ordering, you can order your plugin above any VPN
client. For more information, see
www.deterministicnetworks.com/Products/dne.asp. Note
that because a plugin runs under DNE's digitial
signature, you can avoid the time-consuming and costly
process of certifying your driver with WHQL.

One of our major security customers who does content
inspection and virus filtering uses a combination of DNE
and ESP. Their DNE plugin looks at packets to avoid
attacks while their ESP plugin does deep packet
inspection and proxy. We have a standard cross-platform
IOCTL interface between user and kernel space to
coordinate between plugins at both levels.

Let me know if you have further questions or interest.

Steve

>-----Original Message-----
>Hello Windows experts,
>
>I have UNIX development experience but am a Windows
newbie. I've been
>asked to find out the feasability of creating a Windows
client that
>does the following:
>
>* Sits above TCP/UDP, but below the applications
>* Is able to write to disk all TCP or UDP traffic on
selected ports
>* Is able to read the payload of a TCP or UDP packet
>* Is able to read from the file system
>* Is able to delete selected TCP or UDP traffic so that
the host
> applications do not see it.
>* Is able to pass selected TCP or UDP traffic to the
host applications
>* Is able to generate new TCP or UDP packets (i.e.
packets that did
> not enter this node from the network) that will be
sent to
> applications on this host.
>* Is able to generate TCP or UDP traffic destined for
another host
>* Maintains state between invocations
>
>In addition, if there is VPN software already on this
host, is there a
>way of ensuring that the client we want to develop sits
on top of the
>VPN software so that it sees only the decrypted traffic?
>
>What I have learned so far suggests this might be
possible with:
>
>1. A combination of an NDIS intermediate driver and
application, or
>2. A combination of a TDI driver and an application
>
>Will either one of these work? If not, is there some
other way of
>doing this? If this is possible, we will certainly get
experienced
>professional help in implementing this. Thanks in
advance for any
>pointers.
>
>Bill
>.
>

Relevant Pages

  • RE: tool for creating packets
    ... A very simple tool for TCP and UDP streaming is Test-TCP, ... and runs on Windows too, ... > create tcp and udp packets with m own payload. ...
    (Security-Basics)
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
    ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
    (freebsd-performance)
Loading