Protocol Drivers

Networking API drivers must take API requests and translate them into low-level network protocol requests for transmission across the network. The API drivers rely on transport protocol drivers in kernel mode to do the actual translation. Separating APIs from underlying protocols gives the networking architecture the flexibility of letting each API use a number of different protocols. The protocol drivers that Windows includes are TCP/IP, TCP/IP with IP version 6 (IPv6), NWLink, and the AppleTalk protocol. Here's a brief description of each protocol:

• The Internet's explosive growth and reliance on the TCP/IP protocol has made TCP/IP the preeminent protocol in Windows. The Defense Advanced Research Projects Agency (DARPA) developed TCP/IP in 1969 specifically as the foundation for the Internet; therefore, TCP/IP has WAN-friendly characteristics such as routability and good WAN performance. TCP/IP is the preferred Windows protocol. It is installed by default and cannot be removed.

• The 4-byte network addresses used by the IPv4 protocol used by the standard TCP/IP stack limits the number of public IP addresses to roughly 4 billion, which is a limit that will be pressed as more and more devices, such as cell phones and PDAs, acquire an Internet presence. For that reason, the IPv6 protocol, which has 16-byte addresses, is gaining adoption. Windows XP (Service Pack 1 and later) and Windows Server 2003 include a TCP/IP stack, \Windows\System32\Drivers\Tcpip6.sys, that implements IPv6. The Windows IPv6 stack also supports coexistence with IPv4 networks, through the use of tunneling.

• NWLink consists of Novell's IPX and SPX protocols. Windows includes NWLink for interoperability with Novell NetWare servers.

• The AppleTalk protocol is used by Apple McIntosh networks, and Windows support for the protocol allows Windows to interoperate with file and print services hosted on AppleTalk-based networks.

TDI transports in Windows generally implement all the protocols associated with their primary protocol. For example, the IPv4 TCP/IP driver (\Windows\System32\Drivers\Tcpip.sys) implements TCP, UDP, IP, ARP, ICMP, and IGMP. A TDI transport generally creates device objects that represent particular protocols so that clients can obtain a file object representing a protocol and issue network I/O to the protocol by using IRPs. The TCP/IP driver creates several device objects that represent various TDI-client accessible protocols: \Device\Tcp, \Device\Udp, \Device\Ip, and on Windows XP and Windows Server 2003, \Device\Rawip and \Device\Ipmulticast.

EXPERIMENT: Looking at TCP/IP's Device Objects

Using the kernel debugger to look at a live system, you can examine TCP/IP's device objects. After performing the !drvobj command to see the addresses of each of the driver's device objects, execute !devobj to view the name and other details about the device object.

lkd> !drvobj tcpip Driver object (8a01ada0) is for:  \Driver\Tcpip Driver Extension List:(id , addr) Device Object list: 8a0dbc88  8a0dc958  8a0dcd80  8a0eff18 8a0f32a0 lkd> !devobj 8a0dbc88 Device object (8a0dbc88) is for:  RawIp \Driver\Tcp ip DriverObject 8a01ada0 Current Irp 00000000 RefCount 3 Type 00000012 Flags 00000050 Dacl e100d19c DevExt 00000000 DevObjExt 8a0dbd40 ExtensionFlags (0000000000) Device queue is not busy. lkd> !devobj 8a0dc958 Device object (8a0dc958) is for:  Udp\Driver\Tcpip DriverObject 8a01ada0 Current Irp 00000000 RefCount 41 Type 00000012 Flags 00000050 Dacl e100d19c DevExt 00000000 DevObjExt 8a0dca10 ExtensionFlags (0000000000) Device queue is not busy. lkd> !devobj 8a0dcd80 Device object (8a0dcd80) is for:  Tcp\Driver\Tcpip DriverObject 8a01ada0 Current Irp 00000000 RefCount 302 Type 00000012 Flags 00000050 Dacl e1c3a1ac DevExt 00000000 DevObjExt 8a0dce38 ExtensionFlags (0000000000) Device queue is not busy. lkd> !devobj 8a0eff18 Device object (8a0eff18) is for:  IPMULTICAST\Driver\Tcpip DriverObject 8a01ada0 Current Irp 00000000 RefCount 0 Type 00000012 Flags 00000040 Dacl e100d19c DevExt 00000000 DevObjExt 8a0effd0 ExtensionFlags (0000000000) Device queue is not busy. lkd> !devobj8a0f32a0 Device object (8a0f32a0) is for:  Ip \Driver\Tcpip DriverObject 8a01ada0 Current Irp 00000000 RefCount 48 Type 00000012 Flags 00000050 Dacl e1c3a1ac DevExt 00000000 DevObjExt 8a0f3358 ExtensionFlags (0000000000) Device queue is not busy.

So that networking API drivers don't need to employ various interfaces for each transport protocol they might want to use, Microsoft established the Transport Driver Interface (TDI) standard. As mentioned earlier in this chapter, a TDI interface is essentially a convention for the way network requests format into IRPs and for the way network addresses and communications are allocated. Transport protocols that adhere to the TDI standard export the TDI interface to their clients, which include networking API drivers such as AFD and the redirector. A transport protocol implemented as a Windows device driver is known as a TDI transport. Because TDI transports are device drivers, they format requests they receive from clients as IRPs.

Support functions in the \Windows\System32\Drivers\Tdi.sys library, along with definitions developers include in their drivers, make up the TDI interface. The TDI programming model is very similar to that of Winsock. A TDI client executes the following steps to establish a connection with a remote server:

1. The client allocates and formats an address open TDI IRP to allocate an address. The TDI transport returns a file object, which is known as an address object, that represents the address. This step is the equivalent of using the bind Winsock function.

2. The client then allocates and formats a connection open TDI IRP, and the TDI transport returns a file object, which is known as a connection object, that represents the connection. This step is the equivalent of the use of the Winsock socket function.

3. The client associates the connection object to the address object with an associate address TDI IRP. (There's no equivalent to this step in Winsock.)

4. A TDI client that accepts remote connections issues a listen TDI IRP specifying the number of connections supported for a connection object and then issues an accept TDI IRP, which completes when a remote system establishes a connection (or an error occurs). These operations are equivalent to the use of the Winsock listen and accept functions.

5. A TDI client that wants to establish a connection with a remote server issues a connect TDI IRP, specifying the connection object, that the TDI transport completes when a connection is established (or an error occurs). Issuing a connect TDI IRP is the equivalent of using the connect Winsock function.

TDI also supports connectionless communications for connectionless protocols such as UDP. In addition, TDI provides a means whereby a TDI client can register event callbacks (that is, functions that are directly invoked) with TDI transports. When it receives data from across the network, a TDI transport can invoke a registered client receive callback, for example. This event-based callback feature of TDI allows the TDI transport to notify its clients of network events, and clients that rely on event callbacks don't need to preallocate resources such as buffers when receiving network data because they can view the contents of the buffers supplied by a TDI protocol driver.

EXPERIMENT: Watching TDI Activity

TDImon, a utility from http://www.sysinternals.com, is a form of filter driver that attaches to the \Device\Tcp and \Device\Udp device objects that the TCP/IP driver creates. After attaching, TDImon sees every IRP that TDI clients issue to these protocols. By intercepting TDI client event callback registration, it also monitors event callbacks. The TDImon driver sends information about the TDI activity for display in its GUI, where you can see the time of an operation, the type of TDI activity that took place, the local and remote addresses of a TCP connection or the local address of a UDP endpoint, the resulting status code of the IRP or event callback, and additional information such as the number of bytes sent or received. Here's a screen shot of TDImon watching the TDI activity that is generated when Microsoft Internet Explorer browses a Web page:

As evidence that TDI operations are inherently asynchronous, the PENDING codes in the Result column indicate that an operation initiated but that the IRP defining the operation hasn't yet completed. To accurately show the order of completions with respect to the start of other operations, the issuing of each IRP or event callback is tagged with a sequence number. If other IRPs are issued or completed before an IRP completes, the IRP's completion is also tagged with a sequence number that is shown in the Result column. For example, the IRP that was tagged with sequence number 1278 in the screen shot completed after the one tagged with 1279 was issued, so you see 1280 in the Result column for IRP 1278.

TCP/IP Extensions

Other Windows networking services extend basic networking features of the TCP/IP protocol driver by relying on add-on drivers that integrate with the TCP/IP protocol driver using private interfaces. These include network address translation (NAT), IP filtering, IP hooking, and Internet Protocol security (IPSec). Figure 13-17 shows how these extensions interface with the TCP/IP driver.

Figure 13-17. TCP/IP extension architecture

Network Address Translation

Network address translation (NAT) is a routing service that allows multiple private IP addresses to map to a single public IP address. Without NAT, each computer of a LAN must be assigned a public IP address to communicate across the Internet. NAT allows one computer of the LAN to be assigned an IP address and the other computers to use private IP address and be connected to the Internet through that computer. NAT translates between private IP addresses and the public IP address as necessary, routing packets between LAN computers and the Internet.

NAT components on Windows consist of a NAT device driver, \Windows\System32\Drivers\ Ipnat.sys, that interfaces with the TCP/IP stack as well as editors that can perform additional packet processing beyond address and port translation. NAT can be installed as a routing protocol component with the Routing And Remote Access MMC snap-in or by configuring Internet Connection Sharing (ICS) using the Network Connections folder (although NAT is much more configurable when installed using the Routing And Remote Access MMC snap-in).

IP Filtering

Windows 2000, Windows XP, and Windows Server 2003 all include a very basic IP filtering capability where a user can choose to allow only certain ports or IP protocols. While this capability can serve to protect a computer from unauthorized network accesses, its drawback is that it is static and does not automatically create new filters for traffic initiated by applications running on the computer.

Windows XP introduces a personal firewall capability called Internet Connection Firewall (ICF) that goes beyond the basic filtering just described. ICF implements a stateful firewall, which is one that keeps track of traffic flow so that it distinguishes between TCP/IP traffic that originates on the local LAN and unsolicited traffic that originates on the Internet. When ICF is enabled on an interface, by default all unsolicited incoming traffic received by the computer is discarded. A user or application can define exceptions so that services running on the computer, such as file and printer sharing or a Web site, can be accessed from other computers.

The ICF/ICS service, which executes in a Svchost process, passes exception rules defined in the ICF user interface to the IPNat driver. In kernel mode, ICF is implemented in the same driver, \Windows\System32\Drivers\Ipnat.Sys, that implements Network Address Translation. The NAT driver registers with the TCP/IP driver as a firewall hook driver. The TCP/IP driver executes the callback functions of each registered firewall hook as it processes both inbound and outbound IP packets. A callback function can provide NAT functionality by modifying source and destination addresses in a packet, or as a firewall by returning a status code to TCP/IP that requests that TCP/IP drop the packet and cease processing for it.

Although Ipnat implements ICF using the TCP/IP firewall hook interface, Microsoft recommends that third parties implement packet filtering as an NDIS Intermediate Driver (described later in this chapter).

IP Filter and Filter Hook

Windows XP and Windows Server 2003 include a user-mode packet filtering API and an IP filter driver, \Windows\System32\Drivers\Ipfltrdrv.sys, that together allow applications to manage packet flow into and out of a system. The IP filter driver also allows at most one driver to register as a filter hook driver. In a manner similar to the way it interacts with firewall hook drivers, TCP/IP executes a function that the IP filter driver specifies, which allows the IP filter to drop or modify packets. The IP filter in turn invokes a callback specified by the filter hook driver, propagating modifications or a request to drop the packet to the TCP/IP driver.

The filter hook functionality provided by the system allows third-parties to add translation, firewall, logging, or other functionality to the system.

Internet Protocol Security

Internet Protocol security (IPSec), which is integrated with the Windows TCP/IP stack, helps protect unicast IP data against attacks such as eavesdropping, sniffer attacks, data modification, IP address spoofing, and man-in-the-middle attacks. You can use IPSec to provide defense-in-depth against network-based attacks from untrusted computers, attacks which can result in the denial-of-service of applications, services, or the network; data corruption, data theft, user-credential theft; and the administrative control over servers, other computers, and the network. IPSec helps defend against network-based attacks through cryptography-based security services, security protocols, and dynamic key management.

IPSec provides the following properties for unicast IP packets sent between trusted hosts:

• Data origin authentication, which verifies the origin of an IP packet and ensures that unauthenticated parties cannot access data.

• Data integrity, which protects an IP packet from being modified in transit without being detected.

• Data confidentiality, which encrypts the payload of IP packets before transmission. Data confidentiality ensures that only the IPSec peer with which a computer is communicating can read and interpret the contents of the packets.

• Anti-replay (or replay protection), which ensures that each IP packet is unique and can't be reused. This property prevents an attacker from intercepting IP packets and inserting modified packets into a data stream between a source computer and a destination computer. When anti-replay is used, attackers cannot reply to captured messages to establish a session or gain unauthorized access to data.

You can use IPSec to help defend against network-based attacks by configuring host-based IPSec packet filtering and enforcing trusted communications. When you use IPSec for host-based IPSec packet filtering, IPSec can permit or block specific types of unicast IP traffic based on source and destination address combinations and specific protocols and specific ports. Because IPSec is integrated at the IP layer (layer 3) of the TCP/IP stack and it is applied to all applications, you do not need to configure separate security for each application that uses TCP/IP.

In an Active Directory environment, Group Policy can be used to configure domains, sites, and organizational units (OUs), and IPSec policies can then be assigned as required to Group Policy Objects (GPOs). Alternatively, you can configure and assign local IPSec policies. Active Directory-based IPSec policies are stored in Active Directory, and a copy of the current policy is maintained in a cache in the local Registry. Local IPSec policies are stored in the local system registry.

To establish trusted communications, IPSec uses mutual authentication, and it supports the following authentication methods: Kerberos version 5, a computer X.509 version 3 public key certificate, or a preshared key.

The Windows implementation of IPSec is based on IPSec Requests for Comments (RFCs). The Windows IPSec architecture includes the IPSec Policy Agent, the Internet Key Exchange (IKE) protocol, and an IPSec driver:

• IPSec Policy Agent The IPSec Policy Agent runs as a service in the Local Security Authority Subsystem process. (See Chapter 8 for information on LSASS.) In the Services snap-in in the Microsoft Management Console (MMC), the IPSec Policy Agent appears in the list of computer services under the name IPSEC services. The IPSec Policy Agent obtains IPSec policy from an Active Directory domain or the local registry, and then passes IP address filters to the IPSec driver and authentication and security settings to IKE.

• IKE IKE waits for requests to negotiate security associations (SAs) from the IPSec driver, negotiates the SAs, and then sends the SA settings back to the IPSec driver. SAs are a combination of mutually agreeable IPSec policy settings and keys that defines the security services, mechanisms, and keys that are used to help secure communications between IPSec peers. Each SA is a one-way or simplex connection that secures the traffic it carries. IKE negotiates main mode SAs and quick mode SAs when requested by the IPSec driver. The IKE main mode (or ISAKMP) SA protects the IKE negotiation. The quick mode (or IPSec) SAs protect application traffic.

• IPSec driver The IPSec driver is a device driver (\Windows\System32\Drivers\Ipsec.sys) that is bound to the TCP/IP driver and that processes packets that pass through the TCP/IP driver. The IPSec driver monitors and secures outbound unicast IP traffic, and it monitors, decrypts, and validates inbound unicast IP packets. The driver receives filters from the IPSec Policy Agent, and then permits, blocks, or secures packets as required. To secure traffic, the IPSec driver uses active SA settings, or it requests that new SAs be created.

You can use the IP Security Policy Management snap-in that is available in MMC to create and manage IPSec policy. This snap-in can be used to create, modify, and store local IPSec policies or Active Directory based IPSec policies, and to modify IPSec policy on remote computers. In Windows XP and Windows Server 2003, after IPSec-secured communication is established, you can monitor IPSec information for local computers and for remote computers by using the IP Security Monitor snap-in that is available in MMC.