User Datagram Protocol (UDP)
UDP provides a connectionless, unreliable transport service. It is often used for communications that use broadcast or multicast IP datagrams. Since delivery of UDP datagrams is not guaranteed, applications using UDP must supply their own mechanisms for reliability, if needed. Microsoft networking components use UDP for logon, browsing, and name resolution. UDP can also be used to carry IP multicast streams.
UDP is used for NetBIOS name resolution by unicast to a NetBIOS name server or subnet broadcasts, and for DNS host name to IP address resolution. NetBIOS name resolution is accomplished over UDP port 137. DNS queries use UDP port 53. Because UDP itself does not guarantee delivery of datagrams, both of these services use their own retransmission schemes if they receive no answer to queries. Broadcast UDP datagrams are not usually forwarded over IP routers, so NetBIOS name resolution in a routed environment requires a name server of some type, or the use of static database files.
Many NetBIOS applications use mailslot messaging. A second-class mailslot is a simple mechanism for sending a message from one NetBIOS name to another over UDP. Mailslot messages can be broadcast on a subnet or directed to the remote host. To direct a mailslot message to another host, there must be some method of NetBIOS name resolution available. Microsoft provides WINS for this purpose.
NetBIOS over TCP/IP (NetBT)
The Windows Server 2003 implementation of NetBIOS over TCP/IP is referred to as NetBT. NetBT uses the following TCP and UDP ports:
-
UDP port 137 (name services)
-
UDP port 138 (datagram services)
-
TCP port 139 (session services)
NetBIOS over TCP/IP is specified by RFC 1001 and RFC 1002. The Netbt.sys driver is a kernel-mode component that supports the Transport Driver Interface (TDI) interface. Services such as Workstation (redirector) and Server (file server) use the TDI interface directly, but traditional NetBIOS applications have their calls mapped to TDI calls by the Netbios.sys driver. Using TDI to make calls to NetBT is a more difficult programming task, but can provide higher performance and freedom from historical NetBIOS limitations. NetBIOS concepts are discussed further in the “Network Application Interfaces” section of this paper.
Transport Driver Interface (TDI)
Microsoft developed the Transport Driver Interface (TDI) to provide greater flexibility and functionality than is provided by existing interfaces, such as NetBIOS and Windows Sockets. All Windows transport providers expose TDI. The TDI specification describes the set of primitive functions by which transport drivers and TDI clients communicate and the call mechanisms used for accessing them. Currently, TDI is kernel-mode only.
The Windows Server 2003 redirector and server both use TDI directly, rather than going through the NetBIOS mapping layer. By doing so, they are not subject to many of the restrictions imposed by NetBIOS, such as the legacy 254-session limit.
TDI Features
TDI may be the most difficult to use of all Windows network APIs. It is a simple conduit, so the programmer must determine the format and meaning of messages.
TDI includes the following features:
-
Most Windows Server 2003 transports support TDI
-
An open naming and addressing scheme
-
Message and stream-mode data transfer
-
Asynchronous operation
-
Support for unsolicited indication of events
-
Extensibility—clients can submit private requests to a transport driver that understands them.
-
Support for limited use of standard kernel-mode I/O functions to send and receive data
-
32-bit addressing and values
-
Support for Access Control Lists (ACLs, used for security) on TDI address objects
More information about TDI is available from the Windows DDK.
Security Considerations
Network security is a serious consideration for administrators with computers exposed to public networks. Microsoft’s TCP/IP stack has been strengthened against many attacks and in its default state handles most of the common attacks. Some additional protection against popular Denial of Service attacks can be added by setting the value of the SynAttackProtect parameter in the registry. This key allows the administrator to choose several levels of protection against SYN attacks.
Here are general guidelines that can lower your exposure to attack:
-
Disable unnecessary or optional services (for instance, the Client for Microsoft Networks and the File and Printer Sharing for Microsoft Networks components on the network connections of an IIS server).
-
Enable TCP/IP filtering and restrict access to only the ports that are necessary for the server to function. See the Windows NT, Terminal Server, and Microsoft Exchange Services Use TCP/IP Ports for a list of ports that Windows services use.
-
Disable NetBIOS over TCP/IP on network connections where it is not needed.
-
Configure static IP addresses and parameters for network adapters connected to the Internet.
-
Configure registry parameters for maximum protection (see Appendix D).
Consult the Microsoft Security Web site regularly for security bulletins.
Network Application Interfaces
There are a number of ways that network applications can communicate using the TCP/IP protocol stack. Some of them, such as named pipes, go through the network redirector, which is part of the Workstation service. Many older applications were written to the NetBIOS interface, which is supported by NetBIOS over TCP/IP.
The Windows Sockets interface is the most popular API for writing Windows network applications today. A quick overview of the Windows Sockets Interface and the NetBIOS Interface is presented here.
|
