NDIS high level overview
NDIS is a kernel driver that is used to perform TCP/IP filtering and inspection, it works on packets level and is able to modify, inject and drop packets.
When to use NDIS?
NDIS is mostly used for: Firewalls, NAT drivers, DHCP drivers, low level content inspection.
When not to use NDIS?
NDIS works on the packet level, if you have no use for it (for example parental control), it means that you have to rebuild the stream from packets, and in case you modify the traffic you will need to maintain stream sequence and ID numbers.
NDIS is driver based so it’s an advantage and a disadvantage, it depends on the needs of your software and your programming capabilities.
In Komodia’s Redirector can save you time if you plan to develop an interception component for workstations, save you atleast one year of development time.
NDIS detailed information
NDIS is an acronym for Network Driver Interface Specification. NDIS or the Network Driver Interface Specification allows various transport protocols like IPX, NetBEUI, TCP/IP and Native ATM to communicate with network adapters or any other hardware device. NDIS does it by providing a specification for the Network Driver Architecture. Once the transport protocol communicates with the network adapter using the specifications of the NDIS, then the network adapter can send and receive packets or data over the in-use network. Another important feature of NDIS is that it allows the components of higher-level protocols to be independent of network adapter. This is done by offering standard interface to the networking protocols. The network architecture of Microsoft Windows 2000 supports Network Driver Interface Specification; that is why all the drivers of the network adapters for Windows 2000 need to be written according to the NDIS specification.
The NDIS in Windows 2000 offers two types of interface; the connection-oriented interface and standard connectionless interface. In case of Windows NT version 4.0; its network architecture supported connectionless network interfaces and standards like FDDI, Ethernet and Token Ring. Precisely, a connectionless network transmits the data or the packets without managing or maintaining a connection with the network, unlike the connection-oriented networking. There is no guarantee in a connectionless network that the packets won’t be redundant, lost, delivered, modified or duplicated. Although these services are mainly provided, in case of connectionless networks, by various network protocols provided these services are really required.
The Network Driver Interface Specification or the NDIS in Windows 2000 is implemented by a special file which has a name of Ndis.sys. This file is also called as the NDIS wrapper. In brief, the NDIS wrapper is nothing but a complete piece of code. The NDIS device drivers are surrounded by this code or the NDIS wrapper; that’s why the term wrapper came in. The major functionality of the NDIS wrapper is to give a consistent interface between the NDIS device drivers and the protocol drivers. Moreover, the NDIS wrapper also contains certain supporting routines that assist in developing the NDIS drivers and make the overall development process easier.
There are two major types of NDIS drivers which are described here:
NDIS Intermediate drives:
One type of NDIS driver is called as the NDIS IM driver or the Intermediate Driver. Intermediate drivers or IM drivers are located between the Internet Protocol Layers and the MAC. All network traffic that is being accepted by NIC card can be controlled and monitored by the NDIS IM drivers. Technically and practically, the NDIS IM drivers implement two types of interfaces; protocol interface and the miniport interface. The miniport driver communicates with the miniport interface and the protocol driver communicates with the protocol interface; both of them reside in the IM driver. Having such a design and architecture allows to have chained IM drivers located between the protocol and miniport drivers. So, in short, the IM drivers or the Intermediate Drivers are located just above the miniport driver and just below the transport protocol in the overall networking protocol stack. The NDIS IM drivers are of two types which are mentioned below along with their brief introduction:
LAN Emulation IM Driver: The LAN Emulation IM driver is responsible for translating the connectionless Transport’s LAN format to the connection oriented format. Example of such connection-oriented format is the ATM. It seems that the Transport Protocols or the TP communicates with the Local Area Network Adapter or the Ethernet adapter. However, in real, the Transport Protocols communicates with a separate H/W device. The LAN emulation IM driver takes the packets that are going through or coming from the layer above and then it translates it. It translates the packet in a format that can be sent over a separate and a different medium.
Filter Driver: Filter Drivers are also a type of NDIS IM (Intermediate) Drivers. Their purpose is to carry out special operations and procedures on those packets that are transported using or through them. Examples of special operations include packet tracing, encryption or compression. When the packet goes through the Filter Drivers, operations like encryption or compression can be performed. There are various network services that utilize the Filter Drivers like the Network Load Balancing services or the QoS (Quality of Service) etc.
NDIS Protocol drivers
Another type of NDIS Driver is the NDIS Protocol Driver which exports a complete set of ProtocolXxx functions to the lower edge of the transport protocol stack. The protocol driver communicates with the NDIS in order to receive or send the packets. The NDIS protocol driver binds to an intermediate driver or an underlying miniport driver which than exports MiniportXxx interface; this is exported to the upper edge of the stack. One important feature of such NDIS protocol driver is that it may also support the Transport Driver Interface or the TDI at the upper edge. It is also possible for the NDIS protocol driver to privately export interface to high-level KM (Kernel-mode) driver. This can be done through a transport stack of drivers, which can include the stack that supports the Transport Driver Interface. For example, consider a multimodule transport implementation of TCP/IP standard protocol. In this case, an NDIS protocol driver can be at the lower or lowest module and the TDI may be at the highest.
One important point about the NDIS protocol drivers is that they always use the functions provided by the NDIS in order to communicate with the underlying NDIS drivers. By communicating with the NDIS drivers, they can receive and send packets. For instance, there is a protocol driver using a connectionless lower-edge (may be using Token Ring or Ethernet) who wants to send packets to the underlying NDIS driver; in this case, the protocol driver has to make a call of NdisSendPackets or NdisSend. In order to set the OIDs or the object identifiers of the connectionless drivers, the protocol driver has to call NdisRequest. If a protocol driver uses a connection oriented lower edge (e.g., in case of ATM) then the protocol driver must call NdisCoSendPackets in order to send network packets to the lower-edge or lower level NDIS driver. For setting those OIDs that are supported by connection oriented drivers, the protocol driver has to call NdisCoRequest.
Those Protocol Drivers are more portable amongst Microsoft OS that uses NDIS versions of such functions that are mentioned above. For the operating system to support these protocol drivers, it must also support the Win32 interface.