Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide

  • Disclaimer: The content of this book is under development and subject to revisions.
  • Please forward any comments or suggestions to the writer or to DPGINPUT@microsoft.com.

© 1985-1999 Microsoft Corporation. All rights reserved.


Introduction to TCP/IP

Microsoft® Windows® 2000 has extensive support for the Transmission Control Protocol/Internet Protocol (TCP/IP) suite both as a protocol and a set of services for connectivity and management of IP internetworks. Knowledge of the basic concepts of TCP/IP is an absolute requirement for the proper understanding of the configuration, deployment, and troubleshooting of IP-based Windows 2000 and Microsoft® Windows NT® intranets.

In This Chapter

TCP/IP Protocol Suite

TCP/IP Protocol Architecture

IP Addressing

Name Resolution

IP Routing

Physical Address Resolution

Related Chapters in the Resource Kit

  • For more information about Windows 2000 network architecture, see “Windows 2000 Networking Architecture” in this book.

Additional Resources

For more information about TCP/IP, see:

  • Internetworking with TCP/IP, Vol 1, 3rd Edition by Douglas Comer, 1996, Prentice Hall.
  • Inside TCP/IP, 3rd Edition by Karanjit S. Siyan, 1997, New Riders Publishing.
  • TCP/IP Illustrated, Volume 1, The Protocols by Richard W. Stevens, 1994, Addison-Wesley.


TCP/IP Protocol Suite

TCP/IP is an industry-standard suite of protocols designed for large internetworks spanning wide area network (WAN) links. TCP/IP was developed in 1969 by the U.S. Department of Defense Advanced Research Projects Agency (DARPA), the result of a resource-sharing experiment called ARPANET (Advanced Research Projects Agency Network). The purpose of TCP/IP was to provide high-speed communication network links. Since 1969, ARPANET has grown into a worldwide community of networks known as the Internet.


Microsoft TCP/IP

Microsoft TCP/IP on Windows 2000 enables enterprise networking and connectivity on Windows 2000 and Windows NT–based computers. Adding TCP/IP to a Windows 2000 configuration offers the following advantages:

  • A standard, routable enterprise networking protocol that is the most complete and accepted protocol available. All modern network operating systems offer TCP/IP support, and most large networks rely on TCP/IP for much of their network traffic.
  • A technology for connecting dissimilar systems. Many standard connectivity utilities are available to access and transfer data between dissimilar systems, including File Transfer Protocol (FTP) and Telnet, a terminal emulation protocol. Several of these standard utilities are included with Windows 2000.
  • A robust, scaleable, cross-platform client/server framework. Microsoft TCP/IP offers the Windows Sockets interface, which is ideal for developing client/server applications that can run on Windows Sockets–compliant stacks from other vendors.
  • A method of gaining access to the Internet. The Internet consists of thousands of networks worldwide, connecting research facilities, universities, libraries, and private companies.

Note

The word internet (lowercase i) refers to multiple TCP/IP networks connected with routers. References to the Internet (uppercase I) refer to the worldwide public Internet. References to the intranet refer to a private internetwork.


TCP/IP Standards

The standards for TCP/IP are published in a series of documents called Request for Comments (RFCs). RFCs describe the internal workings of the Internet. Some RFCs describe network services or protocols and their implementations, whereas others summarize policies. TCP/IP standards are always published as RFCs, although not all RFCs specify standards.

TCP/IP standards are not developed by a committee, but rather by consensus. Anyone can submit a document for publication as an RFC. Documents are reviewed by a technical expert, a task force, or the RFC editor, and then assigned a status. The status specifies whether a document is being considered as a standard.

There are five status assignments of RFCs as described in Table 2.1.

Table 2.1 Status Assignments of RFCs

Status | Description
Required | Must be implemented on all TCP/IP-based hosts and gateways.
Recommended | Encouraged that all TCP/IP-based hosts and gateways implement the RFC specifications. Recommended RFCs are usually implemented.
Elective | Implementation is optional. Its application has been agreed to but is not a requirement.
Limited Use | Not intended for general use.
Not recommended | Not recommended for implementation.

If a document is being considered as a standard, it goes through stages of development, testing, and acceptance known as the Internet Standards Process. These stages are formally labeled maturity levels. Table 2.2 lists the three maturity levels for Internet Standards.

Table 2.2 Maturity Levels for Internet Standards

Maturity Level | Description
Proposed Standard | A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable.
Draft Standard | A Draft Standard must be well understood and known to be quite stable, both in its semantics and as a basis for developing an implementation.
Internet Standard | The Internet Standard specification (which might simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.

When a document is published, it is assigned an RFC number. The original RFC is never updated. If changes are required, a new RFC is published with a new number. Therefore, it is important to verify that you have the most recent RFC on a particular topic.

RFCs can be obtained in several ways. The simplest way to obtain any RFC or a full and current indexed listing of all RFCs published to date, is to access http://www.rfc-editor.org/rfc.html on the World Wide Web.


TCP/IP Protocol Architecture

TCP/IP protocols map to a four-layer conceptual model known as the DARPA model, named after the U.S. government agency that initially developed TCP/IP. The four layers of the DARPA model are: Application, Transport, Internet, and Network Interface. Each layer in the DARPA model corresponds to one or more layers of the seven-layer Open Systems Interconnection (OSI) model.

Figure 2.1 shows the TCP/IP protocol architecture.

Figure 2.1 TCP/IP Protocol Architecture

Network Interface Layer

The Network Interface Layer (also called the Network Access Layer) is responsible for placing TCP/IP packets on the network medium and receiving TCP/IP packets off the network medium. TCP/IP was designed to be independent of the network access method, frame format, and medium. In this way, TCP/IP can be used to connect differing network types. These include LAN technologies such as Ethernet and Token Ring and WAN technologies such as X.25 and Frame Relay. Independence from any specific network technology gives TCP/IP the ability to be adapted to new technologies such as Asynchronous Transfer Mode (ATM).

The Network Interface Layer encompasses the Data Link and Physical layers of the OSI Model. Note that the Internet Layer does not take advantage of sequencing and acknowledgment services that might be present in the Data-Link Layer. An unreliable Network Interface Layer is assumed, and reliable communications through session establishment and the sequencing and acknowledgment of packets is the responsibility of the Transport Layer.

Internet Layer

The Internet Layer is responsible for addressing, packaging, and routing functions. The core protocols of the Internet Layer are IP, ARP, ICMP, and IGMP.

  • The Internet Protocol (IP) is a routable protocol responsible for IP addressing and the fragmentation and reassembly of packets.
  • The Address Resolution Protocol (ARP) is responsible for the resolution of the Internet Layer address to the Network Interface Layer address such as a hardware address.
  • The Internet Control Message Protocol (ICMP) is responsible for providing diagnostic functions and reporting errors due to the unsuccessful delivery of IP packets.
  • The Internet Group Management Protocol (IGMP) is responsible for the management of IP multicast groups.

The Internet Layer is analogous to the Network layer of the OSI model.

Transport Layer

The Transport Layer (also known as the Host-to-Host Transport Layer) is responsible for providing the Application Layer with session and datagram communication services. The core protocols of the Transport Layer are TCP and the User Datagram Protocol (UDP).

  • TCP provides a one-to-one, connection-oriented, reliable communications service. TCP is responsible for the establishment of a TCP connection, the sequencing and acknowledgment of packets sent, and the recovery of packets lost during transmission.
  • UDP provides a one-to-one or one-to-many, connectionless, unreliable communications service. UDP is used when the amount of data to be transferred is small (such as the data that would fit into a single packet), when the overhead of establishing a TCP connection is not desired or when the applications or upper layer protocols provide reliable delivery.

The Transport Layer encompasses the responsibilities of the OSI Transport Layer and some of the responsibilities of the OSI Session Layer.

Application Layer

The Application Layer provides applications the ability to access the services of the other layers and defines the protocols that applications use to exchange data. There are many Application Layer protocols and new protocols are always being developed.

The most widely known Application Layer protocols are those used for the exchange of user information:

  • The HyperText Transfer Protocol (HTTP) is used to transfer files that make up the Web pages of the World Wide Web.
  • The File Transfer Protocol (FTP) is used for interactive file transfer.
  • The Simple Mail Transfer Protocol (SMTP) is used for the transfer of mail messages and attachments.
  • Telnet, a terminal emulation protocol, is used for logging on remotely to network hosts.

Additionally, the following Application Layer protocols help facilitate the use and management of TCP/IP networks:

  • The Domain Name System (DNS) is used to resolve a host name to an IP address.
  • The Routing Information Protocol (RIP) is a routing protocol that routers use to exchange routing information on an IP internetwork.
  • The Simple Network Management Protocol (SNMP) is used between a network management console and network devices (routers, bridges, intelligent hubs) to collect and exchange network management information.

Examples of Application Layer interfaces for TCP/IP applications are Windows Sockets and NetBIOS. Windows Sockets provides a standard application programming interface (API) under Microsoft Windows 2000. NetBIOS is an industry standard interface for accessing protocol services such as sessions, datagrams, and name resolution. More information on Windows Sockets and NetBIOS is provided later in this chapter.


TCP/IP Core Protocols

The TCP/IP protocol component that is installed in your network operating system is a series of interconnected protocols called the core protocols of TCP/IP. All other applications and other protocols in the TCP/IP protocol suite rely on the basic services provided by the following protocols: IP, ARP, ICMP, IGMP, TCP, and UDP.

IP

IP is a connectionless, unreliable datagram protocol primarily responsible for addressing and routing packets between hosts. Connectionless means that a session is not established before exchanging data. Unreliable means that delivery is not guaranteed. IP always makes a “best effort” attempt to deliver a packet. An IP packet might be lost, delivered out of sequence, duplicated, or delayed. IP does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets is the responsibility of a higher-layer protocol, such as TCP. IP is defined in RFC 791.

An IP packet consists of an IP header and an IP payload. Table 2.3 describes the key fields in the IP header.

Table 2.3 Key Fields in the IP Header

IP Header Field | Function
Source IP Address | The IP address of the original source of the IP datagram.
Destination IP Address | The IP address of the final destination of the IP datagram.
Identification | Used to identify a specific IP datagram and to identify all fragments of a specific IP datagram if fragmentation occurs.
Protocol | Informs IP at the destination host whether to pass the packet up to TCP, UDP, ICMP, or other protocols.
Checksum | A simple mathematical computation used to verify the integrity of the IP header.
Time-to-Live (TTL) | Designates the number of networks on which the datagram is allowed to travel before being discarded by a router. The TTL is set by the sending host and is used to prevent packets from endlessly circulating on an IP internetwork. When forwarding an IP packet, routers are required to decrease the TTL by at least one.

Fragmentation and Reassembly

If a router receives an IP packet that is too large for the network onto which the packet is being forwarded, IP fragments the original packet into smaller packets that fit on the downstream network. When the packets arrive at their final destination, IP on the destination host reassembles the fragments into the original payload. This process is referred to as fragmentation and reassembly. Fragmentation can occur in environments that have a mix of networking technologies, such as Ethernet or Token Ring.

The fragmentation and reassembly works as follows:

  • When an IP packet is sent by the source, it places a unique value in the Identification field.
  • The IP packet is received at the router. The IP router notes that the maximum transmission unit (MTU) of the network onto which the packet is to be forwarded is smaller than the size of the IP packet.
  • IP divides the original IP payload into fragments that fit on the next network. Each fragment is sent with its own IP header that contains:
    • The original Identification field identifying all fragments that belong together.
    • The More Fragments Flag indicating that other fragments follow. The More Fragments Flag is not set on the last fragment, because no other fragments follow it.
    • The Fragment Offset field indicating the position of the fragment relative to the original IP payload.

When the fragments are received by IP at the remote host, they are identified by the Identification field as belonging together. The Fragment Offset is then used to reassemble the fragments into the original IP payload.

ARP

When IP packets are sent on shared access, broadcast-based networking technologies such as Ethernet or Token Ring, the Media Access Control (MAC) address corresponding to a forwarding IP address must be resolved. ARP uses MAC-level broadcasts to resolve a known forwarding IP address to its MAC address. ARP is defined in RFC 826.

For more information about ARP, see the “Physical Address Resolution” section later in this chapter.

ICMP

Internet Control Message Protocol (ICMP) provides troubleshooting facilities and error reporting for packets that are undeliverable. For example, if IP is unable to deliver a packet to the destination host, ICMP sends a Destination Unreachable message to the source host. Table 2.4 shows the most common ICMP messages.

Table 2.4 Common ICMP Messages

ICMP Message | Function
Echo Request | Troubleshooting message used to check IP connectivity to a desired host.
Echo Reply | Response to an ICMP Echo Request.
Redirect | Sent by a router to inform a sending host of a better route to a destination IP address.
Source Quench | Sent by a router to inform a sending host that its IP datagrams are being dropped due to congestion at the router. The sending host then lowers its transmission rate. Source Quench is an elective ICMP message and is not commonly implemented.
Destination Unreachable | Sent by a router or the destination host to inform the sending host that the datagram cannot be delivered.

There are a series of defined Destination Unreachable ICMP messages. Table 2.5 describes the most common messages.

Table 2.5 Common ICMP Destination Unreachable Messages

Destination Unreachable Message | Description
Network Unreachable | Sent by an IP router when a route to the destination network can not be found.
Host Unreachable | Sent by an IP router when a destination host on the destination network can not be found. This message is only used on connection-oriented network technologies (WAN links). IP routers on connectionless network technologies (such as Ethernet or Token Ring) do not send Host Unreachable messages.
Protocol Unreachable | Sent by the destination IP node when the Protocol field in the IP header cannot be matched with an IP client protocol currently loaded.
Port Unreachable | Sent by the destination IP node when the Destination Port in the UDP header cannot be matched with a process using that port.
Fragmentation Needed and DF Set | Sent by an IP router when fragmentation must occur but is not allowed due to the source node setting the Don’t Fragment (DF) flag in the IP header.
Source Route Failed | Sent by an IP router when the delivery of the IP packet using the source route information stored as source route option headers fails.

ICMP does not make IP a reliable protocol. ICMP attempts to report errors and provide feedback on specific conditions. ICMP messages are carried as unacknowledged IP datagrams and are themselves unreliable. ICMP is defined in RFC 792.

IGMP

Internet Group Management Protocol (IGMP) is a protocol that manages host membership in IP multicast groups. An IP multicast group, also known as a host group, is a set of hosts that listen for IP traffic destined for a specific multicast IP address. Multicast IP traffic is sent to a single MAC address but processed by multiple IP hosts. A given host listens on a specific IP multicast address and receives all packets to that IP address. The following are some of the additional aspects of IP multicasting:

  • Host group membership is dynamic, hosts can join and leave the group at any time.
  • A host group can be of any size.
  • Members of a host group can span IP routers across multiple networks. This situation requires IP multicast support on the IP routers and the ability for hosts to register their group membership with local routers. Host registration is accomplished using IGMP.
  • A host can send traffic to an IP multicast address without belonging to the corresponding host group.

For a host to receive IP multicasts, an application must inform IP that it will receive multicasts at a specified destination IP multicast address. If the network technology supports hardware-based multicasting, the network interface is told to pass up packets for a specific multicast address. In the case of Ethernet, the network adapter is programmed to respond to a multicast MAC address corresponding the desired IP multicast address.

A host supports IP multicast at one of the following levels:

  • Level 0: No support to send or receive IP multicast traffic.
  • Level 1: Support exists to send but not receive IP multicast traffic.
  • Level 2: Support exists to both send and receive IP multicast traffic. Windows 2000 and Windows NT TCP/IP supports level 2 IP multicasting.

The protocol to register host group information is IGMP. IGMP is required on all hosts that support level 2 IP multicasting. IGMP packets are sent using an IP header.

IGMP messages take two forms:

  • When a host joins a host group, it sends an IGMP Host Membership Report message to the all-hosts IP multicast address (224.0.0.1) or to the desired multicast address declaring its membership in a specific host group by referencing the IP multicast address.
  • When a router polls a network to ensure there are members of a specific host group, it sends an IGMP Host Membership Query message to the all-hosts IP multicast address. If no responses to the poll are received after several polls, the router assumes no membership in that group for that network and stops advertising that group-network information to other routers.

For IP multicasting to span routers across an internetwork, multicast routing protocols are used by routers to communicate host group information so that each router supporting multicast forwarding is aware of which networks contain members of which host groups.

TCP

TCP is a reliable, connection-oriented delivery service. The data is transmitted in segments. Connection-oriented means that a connection must be established before hosts can exchange data. Reliability is achieved by assigning a sequence number to each segment transmitted. An acknowledgment is used to verify that the data was received by the other host. For each segment sent, the receiving host must return an acknowledgment (ACK) within a specified period for bytes received. If an ACK is not received, the data is retransmitted. TCP is defined in RFC 793.

TCP uses byte-stream communications, wherein data within the TCP segment is treated as a sequence of bytes with no record or field boundaries. Table 2.6 describes the key fields in the TCP header.

Table 2.6 Key Fields in the TCP Header

Field | Function
Source Port | TCP port of sending host.
Destination Port | TCP port of destination host.
Sequence Number | Sequence number of the first byte of data in the TCP segment.
Acknowledgment Number | Sequence number of the byte the sender expects to receive next from the other side of the connection.
Window | Current size of a TCP buffer on the host sending this TCP segment to store incoming segments.
TCP Checksum | Verifies the integrity of the TCP header and the TCP data.

TCP Ports

A TCP port provides a specific location for delivery of TCP segments. Port numbers below 1024 are well-known ports and are assigned by the Internet Assigned Numbers Authority (IANA). Table 2.7 lists a few well-known TCP ports.

Table 2.7 Well-known TCP Ports

TCP Port Number | Description
20 | FTP (Data Channel)
21 | FTP (Control Channel)
23 | Telnet
80 | HTTP used for the World Wide Web
139 | NetBIOS session service

For a complete list of assigned TCP ports, see RFC 1700.

TCP Three-Way Handshake

A TCP connection is initialized through a three-way handshake. The purpose of the three-way handshake is to synchronize the sequence number and acknowledgment numbers of both sides of the connection and exchange TCP Window sizes. The following steps outline the process:

  1. The client sends a TCP segment to the server with an initial Sequence Number for the connection and a Window size indicating the size of a buffer on the client to store incoming segments from the server.
  2. The server sends back a TCP segment containing its chosen initial Sequence Number, an acknowledgment of the client’s Sequence Number, and a Window size indicating the size of a buffer on the server to store incoming segments from the client.
  3. The client sends a TCP segment to the server containing an acknowledgement of the server’s Sequence Number.

TCP uses a similar handshake process to end a connection. This guarantees that both hosts have finished transmitting and that all data was received.

UDP

UDP provides a connectionless datagram service that offers unreliable, best-effort delivery of data transmitted in messages. This means that neither the arrival of datagrams nor the correct sequencing of delivered packets is guaranteed. UDP does not recover from lost data through retransmission. UDP is defined in RFC 768.

UDP is used by applications that do not require an acknowledgment of receipt of data and that typically transmit small amounts of data at one time. The NetBIOS name service, NetBIOS datagram service, and the SNMP are examples of services and applications that use UDP. Table 2.8 describes the key fields in the UDP header.

Table 2.8 Key Fields in the UDP Header

Field | Function
Source Port | UDP port of sending host.
Destination Port | UDP port of destination host.
UDP Checksum | Verifies the integrity of the UDP header and the UDP data.

UDP Ports

To use UDP, an application must supply the IP address and UDP port number of the destination application. A port provides a location for sending messages. A port functions as a multiplexed message queue, meaning that it can receive multiple messages at a time. Each port is identified by a unique number. It is important to note that UDP ports are distinct and separate from TCP ports even though some of them use the same number. Table 2.9 lists well-known UDP ports.

Table 2.9 Well-known UDP Ports

UDP Port Number | Description
53 | Domain Name System (DNS) Name Queries
69 | Trivial File Transfer Protocol (TFTP)
137 | NetBIOS name service
138 | NetBIOS datagram service
161 | SNMP

For a complete list of assigned UDP ports, see RFC 1700.


TCP/IP Application Interfaces

For applications to access the services offered by the core TCP/IP protocols in a standard way, network operating systems like Windows 2000 make industry standard application programming interfaces (APIs) available. Application interfaces are sets of functions and commands that are programmatically called by application code to perform network functions. For example, a Web browser application connecting to a Web site needs access to TCP’s connection establishment service using its API.

Figure 2.2 shows two common TCP/IP application interfaces, Windows Sockets and NetBIOS, and their relation to the core protocols.

Figure 2.2 APIs for TCP/IP

Windows Sockets Interface

The Windows Sockets API is a standard API under Microsoft Windows 2000 for applications that use TCP and UDP. Applications written to the Windows Sockets API run on many versions of TCP/IP. TCP/IP utilities and the SNMP service are examples of applications written to the Windows Sockets interface.

Windows Sockets provides services that allow applications to bind to a particular port and IP address on a host, initiate and accept a connection, send and receive data, and close a connection. There are two types of sockets:

  1. A stream socket provides a two-way, reliable, sequenced, and unduplicated flow of data using TCP.
  2. A datagram socket provides the bi-directional flow of data using UDP.

A socket is defined by a protocol and an address on the host. The format of the address is specific to each protocol. In TCP/IP, the address is the combination of the IP address and port. Two sockets, one for each end of the connection, form a bi-directional communications path.

To communicate, an application specifies the protocol, the IP address of the destination host, and the port of the destination application. After the application is connected, information can be sent and received.

NetBIOS Interface

NetBIOS was developed for IBM in 1983 by Sytek Corporation to allow applications to communicate over a network. NetBIOS defines two entities, a session level interface and a session management/data transport protocol.

The NetBIOS interface is a standard API for user applications to submit network I/O and control directives to underlying network protocol software. An application program that uses the NetBIOS interface API for network communication can be run on any protocol software that supports the NetBIOS interface.

NetBIOS also defines a protocol that functions at the session/transport level. This is implemented by the underlying protocol software (such as the NetBios Frames Protocol (NBFP), a component of NetBEUI, or NetBIOS over TCP/IP (NetBT)) to perform the network I/O required to accommodate the NetBIOS interface command set. NetBIOS over TCP/IP is defined in RFCs 1001 and 1002.

NetBIOS provides commands and support for NetBIOS Name Management, NetBIOS Datagrams, and NetBIOS Sessions.

NetBIOS Name Management

NetBIOS name management services provide the following functions:

  • Name Registration and Release

    When a TCP/IP host initializes, it registers its NetBIOS names by broadcasting or directing a NetBIOS name registration request to a NetBIOS Name Server such as a Windows Internet Name Service (WINS) server. If another host has registered the same NetBIOS name, either the host or a NetBIOS Name Server responds with a negative name registration response. The initiating host receives an initialization error as a result.

    When the workstation service on a host is stopped, the host discontinues broadcasting a negative name registration response when someone else tries to use the name and sends a name release to a NetBIOS Name Server. The NetBIOS name is said to be released and available for use by another host.

  • Name Resolution

    When a NetBIOS application wants to communicate with another NetBIOS application, the IP address of the NetBIOS application must be resolved. NetBIOS over TCP/IP performs this function by either broadcasting a NetBIOS name query on the local network or sending a NetBIOS name query to a NetBIOS Name Server.

    For more information about NetBIOS name resolution, see the “NetBIOS Name Resolution” section of this chapter.

The NetBIOS Name Service uses UDP port 137.

NetBIOS Datagrams

The NetBIOS datagram service provides delivery of datagrams that are connectionless, nonsequenced, and unreliable. Datagrams can be directed to a specific NetBIOS name or broadcast to a group of names. Delivery is unreliable in that only the users who are logged on to the network receive the message. The datagram service can initiate and receive both broadcast and directed messages. The datagram service uses UDP port 138.

NetBIOS Sessions

The NetBIOS session service provides delivery of NetBIOS messages that are connection-oriented, sequenced, and reliable. NetBIOS sessions use TCP connections and provide session establishment, keepalive, and termination. The session service allows concurrent data transfers in both directions using TCP port 139.


IP Addressing

Each TCP/IP host is identified by a logical IP address. The IP address is a network layer address and has no dependence on the data-link layer address (such as a MAC address of a network adapter). A unique IP address is required for each host and network component that communicates using TCP/IP.

The IP address identifies a system’s location on the network in the same way a street address identifies a house on a city block. Just as a street address must identify a unique residence, an IP address must be globally unique and have a uniform format.

Each IP address includes a network ID and a host ID.

  • The network ID (also known as a network address) identifies the systems that are located on the same physical network bounded by IP routers. All systems on the same physical network must have the same network ID. The network ID must be unique to the internetwork.
  • The host ID (also known as a host address) identifies a workstation, server, router, or other TCP/IP host within a network. The address for each host must be unique to the network ID.

Note

Network ID refers to any IP network ID, whether it is class-based, a subnet, or a supernet.

An IP address consists of 32 bits. Rather than working with 32 bits at a time, it is a common practice to segment the 32 bits of the IP address into four 8-bit fields called octets. Each octet is converted to a decimal number (the Base 10 numbering system) in the range 0-255 and separated by a period (a dot). This format is called dotted decimal notation. Table 2.10 provides an example of an IP address in binary and dotted decimal formats.

Table 2.10 An IP address in Binary and Dotted Decimal Format

Binary Format | Dotted Decimal Notation
11000000 10101000 00000011 00011000 | 192.168.3.24

The notation w.x.y.z is used when referring to a generalized IP address, and is shown in Figure 2.3.

Figure 2.3 IP Address


Address Classes

The Internet community originally defined five address classes to accommodate networks of varying sizes. Microsoft TCP/IP supports class A, B, and C addresses assigned to hosts. The class of address defines which bits are used for the network ID and which bits are used for the host ID. It also defines the possible number of networks and the number of hosts per network.

Class A

Class A addresses are assigned to networks with a very large number of hosts. The high-order bit in a class A address is always set to zero. The next seven bits (completing the first octet) complete the network ID. The remaining 24 bits (the last three octets) represent the host ID. This allows for 126 networks and 16,777,214 hosts per network. Figure 2.4 illustrates the structure of class A addresses.

Figure2.4 Class A IP Addresses

Class B

Class B addresses are assigned to medium-sized to large-sized networks. The two high-order bits in a class B address are always set to binary 1 0. The next 14 bits (completing the first two octets) complete the network ID. The remaining 16 bits (last two octets) represent the host ID. This allows for 16,384 networks and 65,534 hosts per network. Figure 2.5 illustrates the structure of class B addresses.

Figure 2.5 Class B IP Addresses

Class C

Class C addresses are used for small networks. The three high-order bits in a class C address are always set to binary 1 1 0. The next 21 bits (completing the first three octets) complete the network ID. The remaining 8 bits (last octet) represent the host ID. This allows for 2,097,152 networks and 254 hosts per network. Figure 2.6 illustrates the structure of class C addresses.

Figure 2.6 Class C IP Addresses

Class D

Class D addresses are reserved for IP multicast addresses. The four high-order bits in a class D address are always set to binary 1 1 1 0. The remaining bits are for the address that interested hosts recognize. Microsoft supports class D addresses for applications to multicast data to multicast-capable hosts on an internetwork.

Class E

Class E is an experimental address that is reserved for future use. The high-order bits in a class E address are set to 1111.

Table 2.11 is a summary of address classes A, B, and C that can be used for host IP addresses.

Table 2.11 IP Address Class Summary

Class | Value for w1 | Network ID Portion | Host ID Portion | Available Networks | Hosts per Network
A | 1–126 | w | x.y.z | 126 | 16,777,214
B | 128–191 | w.x | y.z | 16,384 | 65,534
C | 192–223 | w.x.y | z | 2,097,152 | 254
1 The class A address 127.x.y.z is reserved for loopback testing and interprocess communication on the local computer.

Network ID Guidelines

The network ID identifies the TCP/IP hosts that are located on the same physical network. All hosts on the same physical network must be assigned the same network ID to communicate with each other.

Follow these guidelines when assigning a network ID:

  • The network address must be unique to the IP internetwork. If you plan on having a direct routed connection to the public Internet, the network ID must be unique to the Internet. If you do not plan on connecting to the public Internet, the local network ID must be unique to your private internetwork.
  • The network ID cannot begin with the number 127. The number 127 in a class A address is reserved for internal loopback functions.
  • All bits within the network ID cannot be set to 1. All 1’s in the network ID are reserved for use as an IP broadcast address.
  • All bits within the network ID cannot be set to 0. All 0’s in the network ID are used to denote a specific host on the local network and are not routed.

Table 2.12 lists the valid ranges of network IDs based on the IP address classes. To denote IP network IDs, the host bits are all set to 0. Note that even though expressed in dotted decimal notation, the network ID is not an IP address.

Table 2.12 Class Ranges of Network IDs

Address Class | First Network ID | Last Network ID
Class A | 1.0.0.0 | 126.0.0.0
Class B | 128.0.0.0 | 191.255.0.0
Class C | 192.0.0.0 | 223.255.255.0

Host ID Guidelines

The host ID identifies a TCP/IP host within a network. The combination of IP network ID and IP host ID is an IP address.

Follow these guidelines when assigning a host ID:

  • The host ID must be unique to the network ID.
  • All bits within the host ID cannot be set to 1 because this host ID is reserved as a broadcast address to send a packet to all hosts on a network.
  • All bits in the host ID cannot be set to 0 because this host ID is reserved to denote the IP network ID.

Table 2.13 lists the valid ranges of host IDs based on the IP address classes.

Table 2.13 Class Ranges of Host IDs

Address Class | First Host ID | Last Host ID
Class A | w.0.0.1 | w.255.255.254
Class B | w.x.0.1 | w.x.255.254
Class C | w.x.y.1 | w.x.y.254


Subnets and Subnet Masks

The Internet Address Classes accommodate three scales of IP internetworks, where the 32-bits of the IP address are apportioned between network IDs and host IDs depending on how many networks and hosts per network are needed. However, consider the class A network ID, which has the possibility of over 16 million hosts on the same network. All the hosts on the same physical network bounded by IP routers share the same broadcast traffic; they are in the same broadcast domain. It is not practical to have 16 million nodes in the same broadcast domain. The result is that most of the 16 million host addresses are unassignable and are wasted. Even a class B network with 65 thousand hosts is impractical.

In an effort to create smaller broadcast domains and to better utilize the bits in the host ID, an IP network can be subdivided into smaller networks, each bounded by an IP router and assigned a new subnetted network ID, which is a subset of the original class-based network ID.

This creates subnets, subdivisions of an IP network each with their own unique subnetted network ID. Subnetted network IDs are created by using bits from the host ID portion of the original class-based network ID.

Consider the example in Figure 2.7. The class B network of 139.12.0.0 can have up to 65,534 nodes. This is far too many nodes, and in fact the current network is becoming saturated with broadcast traffic. The subnetting of network 139.12.0.0 should be done in such a way so that it does not impact nor require the reconfiguration of the rest of the IP internetwork.

Figure 2.7 Network 139.12.0.0 Before Subnetting

Network 139.12.0.0 is subnetted by utilizing the first 8 host bits (the third octet) for the new subnetted network ID. When 139.12.0.0 is subnetted, as shown in Figure 2.8, separate networks with their own subnetted network IDs (139.12.1.0, 139.12.2.0, 139.12.3.0) are created. The router is aware of the separate subnetted networks IDs and routes IP packets to the appropriate subnet.

Note that the rest of the IP internetwork still regards all the nodes on the three subnets as being on network 139.12.0.0. The other routers in the IP internetwork are unaware of the subnetting being done on network 139.12.0.0 and therefore require no reconfiguration.

Figure 2.8 Network 139.12.0.0 After Subnetting

A key element of subnetting is still missing. How does the router who is subdividing network 139.12.0.0 know how the network is being subdivided and which subnets are available on which router interfaces? To give the IP nodes this new level of awareness, they must be told exactly how to discern the new subnetted network ID regardless of Internet Address Classes. A subnet mask is used to tell an IP node how to extract a class-based or subnetted network ID.

Subnet Masks

With the advent of subnetting, one can no longer rely on the definition of the IP address classes to determine the network ID in the IP address. A new value is needed to define which part of the IP address is the network ID and which part is the host ID regardless of whether class-based or subnetted network IDs are being used.

RFC 950 defines the use of a subnet mask (also referred to as an address mask) as a 32-bit value that is used to distinguish the network ID from the host ID in an arbitrary IP address. The bits of the subnet mask are defined as follows:

  • All bits that correspond to the network ID are set to 1.
  • All bits that correspond to the host ID are set to 0.

Each host on a TCP/IP network requires a subnet mask even on a single segment network. Either a default subnet mask, which is used when using class-based network IDs, or a custom subnet mask, which is used when subnetting or supernetting, is configured on each TCP/IP node.

Dotted Decimal Representation of Subnet Masks

Subnet masks are frequently expressed in dotted decimal notation. After the bits are set for the network ID and host ID portion, the resulting 32-bit number is converted to dotted decimal notation. Note that even though expressed in dotted decimal notation, a subnet mask is not an IP address.

A default subnet mask is based on the IP address classes and is used on TCP/IP networks that are not divided into subnets. Table 2.14 lists the default subnet masks using the dotted decimal notation for the subnet mask.

Table 2.14 Default Subnet Masks (Dotted Decimal Notation)

Address Class | Bits for Subnet Mask | Subnet Mask
Class A | 11111111 00000000 00000000 00000000 | 255.0.0.0
Class B | 11111111 11111111 00000000 00000000 | 255.255.0.0
Class C | 11111111 11111111 11111111 00000000 | 255.255.255.0

Custom subnet masks are those that differ from these default subnet masks when you are doing subnetting or supernetting. For example, 138.96.58.0 is an 8-bit subnetted class B network ID. 8 bits of the class-based host ID are being used to express subnetted network IDs. The subnet mask uses a total of 24 bits (255.255.255.0) to define the subnetted network ID. The subnetted network ID and its corresponding subnet mask is then expressed in dotted decimal notation as:

138.96.58.0, 255.255.255.0

Network Prefix Length Representation of Subnet Masks

Because the network ID bits must always be chosen in a contiguous fashion from the high order bits, a shorthand way of expressing a subnet mask is to denote the number of bits that define the network ID as a network prefix using the network prefix notation: /<# of bits>. Table 2.15 lists the default subnet masks using the network prefix notation for the subnet mask.

Table 2.15 Default Subnet Masks (Network Prefix Notation)

Address Class | Bits for Subnet Mask | Network Prefix
Class A | 11111111 00000000 00000000 00000000 | /8
Class B | 11111111 11111111 00000000 00000000 | /16
Class C | 11111111 11111111 11111111 00000000 | /24

For example, the class B network ID 138.96.0.0 with the subnet mask of 255.255.0.0 would be expressed in network prefix notation as 138.96.0.0/16.

As an example of a custom subnet mask, 138.96.58.0 is an 8-bit subnetted class B network ID. The subnet mask uses a total of 24 bits to define the subnetted network ID. The subnetted network ID and its corresponding subnet mask is then expressed in network prefix notation as:

138.96.58.0/24

Note

Because all hosts on the same network must use the same network ID, all hosts on the same network must use the same network ID as defined by the same subnet mask. For example, 138.23.0.0/16 is not the same network ID as 138.23.0.0/24. The network ID 138.23.0.0/16 implies a range of valid host IP addresses from 138.23.0.1 to 138.23.255.254. The network ID 138.23.0.0/24 implies a range of valid host IP addresses from 138.23.0.1 to 138.23.0.254. Clearly, these network IDs do not represent the same range of IP addresses.

Determining the Network ID

To extract the network ID from an arbitrary IP address using an arbitrary subnet mask, IP uses a mathematical operation called a logical AND comparison. In an AND comparison, the result of two items being compared is true only when both items being compared are true; otherwise, the result is false. Applying this principle to bits, the result is 1 when both bits being compared are 1, otherwise the result is 0.

IP performs a logical AND comparison with the 32-bit IP address and the 32-bit subnet mask. This operation is known as a bit-wise logical AND. The result of the bit-wise logical AND of the IP address and the subnet mask is the network ID.

For example, what is the network ID of the IP node 129.56.189.41 with a subnet mask of 255.255.240.0?

To obtain the result, turn both numbers into their binary equivalents and line them up. Then perform the AND operation on each bit and write down the result.

10000001 00111000 10111101 00101001  IP Address
11111111 11111111 11110000 00000000  Subnet Mask
10000001 00111000 10110000 00000000  Network ID

The result of the bit-wise logical AND of the 32 bits of the IP address and the subnet mask is the network ID 129.56.176.0.


Subnetting

Although the conceptual notion of subnetting by utilizing host bits is straightforward, the actual mechanics of subnetting are a bit more complicated. Subnetting requires a three step procedure:

  1. Determine the number of host bits to be used for the subnetting.
  2. Enumerate the new subnetted network IDs.
  3. Enumerate the IP addresses for each new subnetted network ID.

Step 1: Determining the Number of Host Bits

The number of host bits being used for subnetting determines the possible number of subnets and hosts per subnet. Before you choose the number of host bits, you should have a good idea of the number of subnets and hosts you will have in the future. Using more bits for the subnet mask than required saves you the time of reassigning IP addresses in the future.

The more host bits that are used, the more subnets (subnetted network IDs) you can have — but with fewer hosts. Using too many host bits allows for growth in the number of subnets but limits the growth in the number of hosts. Using too few hosts allows for growth in the number of hosts but limits the growth in the number of subnets.

For example, Figure 2.9 illustrates the subnetting of up to the first 8 host bits of a class B network ID. If you choose one host bit for subnetting, you obtain 2 subnetted network IDs with 16,382 hosts per subnetted network ID. If you choose 8 host bits for subnetting, you obtain 256 subnetted network IDs with 254 hosts per subnetted network ID.

Figure 2.9 Subnetting a Class B Network ID

In practice, network administrators define a maximum number of nodes they want on a single network. Recall that all nodes on a single network share all the same broadcast traffic; they reside in the same broadcast domain. Therefore, growth in the number of subnets is favored over growth in the number of hosts per subnet.

Follow these guidelines to determine the number of host bits to use for subnetting.

  1. Determine how many subnets you need now and will need in the future. Each physical network is a subnet. WAN connections can also count as subnets depending on whether your routers support unnumbered connections.
  2. Use additional bits for the subnet mask if:
    • You will never require as many hosts per subnet as allowed by the remaining bits.
    • The number of subnets will increase in the future, requiring additional host bits.

To determine the desired subnetting scheme, start with an existing network ID to be subnetted. The network ID to be subnetted can be a class-based network ID, a subnetted network ID, or a supernet. The existing network ID contains a series of network ID bits that are fixed and a series of host ID bits that are variable. Based on your requirements for the number of subnets and the number of hosts per subnet, choose a specific number of host bits to be used for the subnetting.

Table 2.16 shows the subnetting of a class A network ID. Based on a required number of subnets, and a maximum number of hosts per subnet, a subnetting scheme can be chosen.

Table 2.16 Subnetting a Class A Network ID

Required Number of Subnets | Number of Host Bits | Subnet Mask | Number of Hosts per Subnet
1-2 | 1 | 255.128.0.0 or /9 | 8,388,606
3-4 | 2 | 255.192.0.0 or /10 | 4,194,302
5-8 | 3 | 255.224.0.0 or /11 | 2,097,150
9-16 | 4 | 255.240.0.0 or /12 | 1,048,574
17-32 | 5 | 255.248.0.0 or /13 | 524,286
33-64 | 6 | 255.252.0.0 or /14 | 262,142
65-128 | 7 | 255.254.0.0 or /15 | 131,070
129-256 | 8 | 255.255.0.0 or /16 | 65,534
257-512 | 9 | 255.255.128.0 or /17 | 32,766
513-1,024 | 10 | 255.255.192.0 or /18 | 16,382
1,025-2,048 | 11 | 255.255.224.0 or /19 | 8,190
2,049-4,096 | 12 | 255.255.240.0 or /20 | 4,094
4,097-8,192 | 13 | 255.255.248.0 or /21 | 2,046
8,193-16,384 | 14 | 255.255.252.0 or /22 | 1,022
16,385-32,768 | 15 | 255.255.254.0 or /23 | 510
32,769-65,536 | 16 | 255.255.255.0 or /24 | 254
65,537-131,072 | 17 | 255.255.255.128 or /25 | 126
131,073-262,144 | 18 | 255.255.255.192 or /26 | 62
262,145-524,288 | 19 | 255.255.255.224 or /27 | 30
524,289-1,048,576 | 20 | 255.255.255.240 or /28 | 14
1,048,577-2,097,152 | 21 | 255.255.255.248 or /29 | 6
2,097,153-4,194,304 | 22 | 255.255.255.252 or /30 | 2

Table 2.17 shows the subnetting of a class B network ID.

Table 2.17 Subnetting a Class B Network ID

Required Number of Subnets | Number of Host Bits | Subnet Mask | Number of Hosts per Subnet
1-2 | 1 | 255.255.128.0 or /17 | 32,766
3-4 | 2 | 255.255.192.0 or /18 | 16,382
5-8 | 3 | 255.255.224.0 or /19 | 8,190
9-16 | 4 | 255.255.240.0 or /20 | 4,094
17-32 | 5 | 255.255.248.0 or /21 | 2,046
33-64 | 6 | 255.255.252.0 or /22 | 1,022
65-128 | 7 | 255.255.254.0 or /23 | 510
129-256 | 8 | 255.255.255.0 or /24 | 254
257-512 | 9 | 255.255.255.128 or /25 | 126
513-1,024 | 10 | 255.255.255.192 or /26 | 62
1,025-2,048 | 11 | 255.255.255.224 or /27 | 30
2,049-4,096 | 12 | 255.255.255.240 or /28 | 14
4,097-8,192 | 13 | 255.255.255.248 or /29 | 6
8,193-16,384 | 14 | 255.255.255.252 or /30 | 2

Table 2.18 shows the subnetting of a class C network ID.

Table 2.18 Subnetting a Class C Network ID

Required Number of Subnets | Number of Host Bits | Subnet Mask | Number of Hosts per Subnet
1-2 | 1 | 255.255.255.128 or /25 | 126
3-4 | 2 | 255.255.255.192 or /26 | 62
5-8 | 3 | 255.255.255.224 or /27 | 30
9-16 | 4 | 255.255.255.240 or /28 | 14
17-32 | 5 | 255.255.255.248 or /29 | 6
33-64 | 6 | 255.255.255.252 or /30 | 2

Step 2: Enumerating Subnetted Network IDs

Based on the number of host bits you use for your subnetting, you must list the new subnetted network IDs. There are two main approaches:

  • Binary—List all possible combinations of the host bits chosen for subnetting and convert each combination to dotted decimal notation.
  • Decimal—Add a calculated increment value to each successive subnetted network ID and convert to dotted decimal notation.

Either method produces the same result: the enumerated list of subnetted network IDs.

Note

There are a variety of documented shortcut techniques for subnetting. However, they only work under a specific set of constraints (for example, only up to 8 bits of a class-based network ID). The following methods described are designed to work for any subnetting situation (class-based, more than 8 bits, supernetting, variable length subnetting).

To create the enumerated list of subnetted network IDs using the binary method

  1. Based on n, the number of host bits chosen for subnetting, create a 3-column table with 2n entries. The first column is the subnet number (starting with 1), the second column is the binary representation of the subnetted network ID, and the third column is the dotted decimal representation of the subnetted network ID.

    For each binary representation, the bits of the network ID being subnetted are fixed to their appropriate values and the remaining host bits are set to all 0’s. The host bits chosen for subnetting vary.

  2. In the first table entry, set the subnet bits to all 0’s and convert to dotted decimal notation. The original network ID is subnetted with its new subnet mask.
  3. In the next table entry, increase the value within the subnet bits.
  4. Convert the binary result to dotted decimal notation.
  5. Repeat steps 3 and 4 until the table is complete.

For example, create a 3-bit subnet of the private network ID 192.168.0.0. The subnet mask for the new subnetted network IDs is 255.255.224.0 or /19. Based on n = 3, construct a table with 8 (= 23) entries. The entry for subnet 1 is the all 0’s subnet. Additional entries in the table are successive increments of the subnet bits, as shown in Table 2.19. The host bits used for subnetting are underlined.

Table 2.19 Binary Subnetting Technique for Network ID 192.168.0.0

Subnet | Binary Representation | Subnetted Network ID
1 | 11000000.10101000.00000000.00000000 | 192.168.0.0/19
2 | 11000000.10101000.00100000.00000000 | 192.168.32.0/19
3 | 11000000.10101000.01000000.00000000 | 192.168.64.0/19
4 | 11000000.10101000.01100000.00000000 | 192.168.96.0/19
5 | 11000000.10101000.10000000.00000000 | 192.168.128.0/19
6 | 11000000.10101000.10100000.00000000 | 192.168.160.0/19
7 | 11000000.10101000.11000000.00000000 | 192.168.192.0/19
8 | 11000000.10101000.11100000.00000000 | 192.168.224.0/19

To create the enumerated list of subnetted network IDs using the decimal method:

  1. Based on n, the number of host bits chosen for subnetting, create a 3-column table with 2n entries. The first column is the subnet number (starting with 1), the second column is the decimal (Base 10 numbering system) representation of the 32-bit subnetted network ID, and the third column is the dotted decimal representation of the subnetted network ID.
  2. Convert the network ID (w.x.y.z) being subnetted from dotted decimal notation to N, a decimal representation of the 32-bit network ID:

    N = w*16777216 + x*65536 + y*256 + z

  3. Compute the increment value I based on h, the number of host bits remaining:

    I = 2h

  4. In the first table entry, the decimal representation of the subnetted network ID is N and the subnetted network ID is w.x.y.z with its new subnet mask.
  5. In the next table entry, add I to the previous table entry’s decimal representation.
  6. Convert the decimal representation of the subnetted network ID to dotted decimal notation (W.X.Y.Z) through the following formula (where s is the decimal representation of the subnetted network ID):

    W = INT(s/16777216)

    X = INT((s mod(16777216))/65536)

    Y = INT((s mod(65536))/256)

    Z = s mod(256)

    INT( ) denotes integer division, mod( ) denotes the modulus, the remainder upon division.

  7. Repeat steps 5 and 6 until the table is complete.

For example, create a 3-bit subnet of the private network ID 192.168.0.0. Based on n = 3, we construct a table with 8 entries. The entry for subnet 1 is the all 0’s subnet. N, the decimal representation of 192.168.0.0, is 3232235520, the result of 192*16777216 + 168*65536. Because there are 13 host bits remaining, the increment I is 213 = 8192. Additional entries in the table are successive increments of 8192 as shown in Table 2.20.

Table 2.20 Decimal Subnetting Technique for Network ID 192.168.0.0

Subnet | Decimal Representation | Subnetted Network ID
1 | 3232235520 | 192.168.0.0/19
2 | 3232243712 | 192.168.32.0/19
3 | 3232251904 | 192.168.64.0/19
4 | 3232260096 | 192.168.96.0/19
5 | 3232268288 | 192.168.128.0/19
6 | 3232276480 | 192.168.160.0/19
7 | 3232284672 | 192.168.192.0/19
8 | 3232292864 | 192.168.224.0/19

Note

RFC 950 forbade the use of the subnetted network IDs where the bits being used for subnetting are set to all 0’s (the all-zeros subnet) and all 1’s (the all-ones subnet). The all-zeros subnet caused problems for early routing protocols and the all-ones subnet conflicts with a special broadcast address called the all-subnets directed broadcast address.

However, RFC 1812 now permits the use of the all-zeros and all-ones subnets in a CIDR-compliant environment. CIDR-compliant environments use modern routing protocols that do not have a problem with the all-zeros subnet and with which the use of the all-subnets directed broadcast has been deprecated.

Before you use the all-zeros and all-ones subnets, verify that they are supported by your hosts and routers. Windows 2000 and Windows NT support the use of the all-zeros and all-ones subnets.

Step 3: Enumerating IP Addresses for Each Subnetted Network ID

Based on the enumeration of the subnetted network IDs, you must now list the valid IP addresses for new subnetted network IDs. To list each IP address individually would be too tedious. Instead, enumerate the IP addresses for each subnetted network ID by defining the range of IP addresses (the first and the last) for each subnetted network ID. There are two main approaches:

  • Binary—Write down the first and last IP address for each subnetted network ID and convert to dotted decimal notation.
  • Decimal—Add values incrementally, corresponding to the first and last IP addresses for each subnetted network ID and convert to dotted decimal notation.

Either method produces the same result: the range of IP addresses for each subnetted network ID.

To create the range of IP addresses using the binary method

  1. Based on n, the number of host bits chosen for subnetting, create a 3-column table with 2n entries. Alternately, add two columns to the previous table used for enumerating the subnetted network IDs. The first column is the subnet number (starting with 1), the second column is the binary representation of the first and last IP address for the subnetted network ID, and the third column is the dotted decimal representation of the first and last IP address of the subnetted network ID.
  2. For each binary representation, the first IP address is the address in which all the host bits are set to 0 except for the last host bit. The last IP address is the address in which all the host bits are set to 1 except for the last host bit.
  3. Convert the binary representation to dotted decimal notation.
  4. Repeat steps 2 and 3 until the table is complete.

For example, the range of IP addresses for the 3 bit subnetting of 192.168.0.0 is shown in Table 2.21. The bits used for subnetting are underlined.

Table 2.21 Binary Enumeration of IP Addresses

Subnet | Binary Representation | Range of IP Addresses
1 | 11000000.10101000.00000000.00000001 - 11000000.10101000.00011111.11111110 | 192.168.0.1 - 192.168.31.254
2 | 11000000.10101000.00100000.00000001 - 11000000.10101000.00111111.11111110 | 192.168.32.1 - 192.168.63.254
3 | 11000000.10101000.01000000.00000001 - 11000000.10101000.01011111.11111110 | 192.168.64.1 - 192.168.95.254
4 | 11000000.10101000.01100000.00000001 - 11000000.10101000.01111111.11111110 | 192.168.96.1 - 192.168.127.254
5 | 11000000.10101000.10000000.00000001 - 11000000.10101000.10011111.11111110 | 192.168.128.1 - 192.168.159.254
6 | 11000000.10101000.10100000.00000001 - 11000000.10101000.10111111.11111110 | 192.168.160.1 - 192.168.191.254
7 | 11000000.10101000.11000000.00000001 - 11000000.10101000.11011111.11111110 | 192.168.192.1 - 192.168.223.254
8 | 11000000.10101000.11100000.00000001 - 11000000.10101000.11111111.11111110 | 192.168.224.1 - 192.168.255.254

To create the range of IP addresses using the decimal method

  1. Based on n, the number of host bits chosen for subnetting, create a 3-column table with 2n entries. Alternately, add two columns to the previous table used for enumerating the subnetted network IDs. The first column is the subnet number (starting with 1), the second column is the decimal representation of the first and last IP address for the subnetted network ID, and the third column is the dotted decimal representation of the first and last IP address of the subnetted network ID.
  2. Compute the increment value J based on h, the number of host bits remaining:

    J = 2h - 2

  3. For each decimal representation, the first IP address is N + 1 where N is the decimal representation of the subnetted network ID. The last IP address is N + J.
  4. Convert the decimal representation of the first and last IP addresses to dotted decimal notation (W.X.Y.Z) through the following formula (where s is the decimal representation of the first or last IP address):

    W = INT(s/16777216)

    X = INT((s mod(16777216))/65536)

    Y = INT((s mod(65536))/256)

    Z = s mod(256)

    INT( ) denotes integer division, mod( ) denotes the modulus, the remainder upon division.

  5. Repeat steps 2 and 3 until the table is complete.

For example, the range of IP addresses for the 3 bit subnetting of 192.168.0.0 is shown in Table 2.22. The increment J is 213 - 2 = 8190.

Table 2.22 Decimal Enumeration of IP Addresses

Subnet | Decimal Representation | Range of IP Addresses
1 | 3232235521 - 3232243710 | 192.168.0.1 - 192.168.31.254
2 | 3232243713 - 3232251902 | 192.168.32.1 - 192.168.63.254
3 | 3232251905 - 3232260094 | 192.168.64.1 - 192.168.95.254
4 | 3232260097 - 3232268286 | 192.168.96.1 - 192.168.127.254
5 | 3232268289 - 3232276478 | 192.168.128.1 - 192.168.159.254
6 | 3232276479 - 3232284670 | 192.168.160.1 - 192.168.191.254
7 | 3232284673 - 3232292862 | 192.168.192.1 - 192.168.223.254
8 | 3232292863 - 3232301054 | 192.168.224.1 - 192.168.255.254


Variable Length Subnetting

One of the original uses for subnetting was to subdivide a class-based network ID into a series of equal-sized subnets. For example, a 4-bit subnetting of a class B network ID produced 16 equal-sized subnets (using the all-ones and all-zeros subnets). However, subnetting is a general method of utilizing host bits to express subnets and does not require equal-sized subnets.

Subnets of different size can exist within a class-based network ID. This is well-suited to real-world environments, where networks of an organization contain different numbers of hosts, and different-sized subnets are needed to minimize the wasting of IP addresses. The creation and deployment of various-sized subnets of a network ID is known as variable length subnetting and uses variable length subnet masks (VLSM).

Variable length subnetting is a technique of allocating subnetted network IDs that use subnet masks of different sizes. However, all subnetted network IDs are unique and can be distinguished from each other by their corresponding subnet mask.

The mechanics of variable length subnetting are essentially that of performing subnetting on a previously subnetted network ID. When subnetting, the network ID bits are fixed and a certain number of host bits are chosen to express subnets. With variable length subnetting, the network ID being subnetted has already been subnetted.

For example, given the class-based network ID of 135.41.0.0/16, a required configuration is 1 subnet with up to 32,000 hosts, 15 subnets with up to 2,000 hosts, and 8 subnets with up to 250 hosts.

One Subnet with up to 32,000 Hosts

To achieve a requirement of 1 subnet with approximately 32,000 hosts, a 1-bit subnetting of the class-based network ID of 135.41.0.0 is done, producing 2 subnets, 135.41.0.0/17 and 135.41.128.0/17. This subnetting allows up to 32,766 hosts per subnet. 135.41.0.0/17 is chosen as the network ID, which fulfills the requirement.

Table 2.23 shows one subnet with up to 32,766 hosts.

Table 2.23 One Subnet with up to 32,766 Hosts

Subnet Number Network ID (Dotted Decimal) Network ID (Network Prefix)
1

135.41.0.0, 255.255.128.0

135.41.0.0/17

Fifteen Subnets with up to 2,000 Hosts

To achieve a requirement of 15 subnets with approximately 2,000 hosts, a 4-bit subnetting of the subnetted network ID of 135.41.128.0/17 is done. This produces 16 subnets (135.41.128.0/21, 135.41.136.0/21 . . . 135.41.240.0/21, 135.41.248.0/21), allowing up to 2,046 hosts per subnet. The first 15 subnetted network IDs (135.41.128.0/21 to 135.41.240.0/21) are chosen as the network IDs, which fulfills the requirement.

Table 2.24 illustrates 15 subnets with up to 2,000 hosts.

Table 2.24 Fifteen Subnets with up to 2,046 Hosts

Subnet Number | Network ID (Dotted Decimal) | Network ID (Network Prefix)
1 | 135.41.128.0, 255.255.248.0 | 135.41.128.0/21
2 | 135.41.136.0, 255.255.248.0 | 135.41.136.0/21
3 | 135.41.144.0, 255.255.248.0 | 135.41.144.0/21
4 | 135.41.152.0, 255.255.248.0 | 135.41.152.0/21
5 | 135.41.160.0, 255.255.248.0 | 135.41.160.0/21
6 | 135.41.168.0, 255.255.248.0 | 135.41.168.0/21
7 | 135.41.176.0, 255.255.248.0 | 135.41.176.0/21
8 | 135.41.184.0, 255.255.248.0 | 135.41.184.0/21
9 | 135.41.192.0, 255.255.248.0 | 135.41.192.0/21
10 | 135.41.200.0, 255.255.248.0 | 135.41.200.0/21
11 | 135.41.208.0, 255.255.248.0 | 135.41.208.0/21
12 | 135.41.216.0, 255.255.248.0 | 135.41.216.0/21
13 | 135.41.224.0, 255.255.248.0 | 135.41.224.0/21
14 | 135.41.232.0, 255.255.248.0 | 135.41.232.0/21
15 | 135.41.240.0, 255.255.248.0 | 135.41.240.0/21

Eight Subnets with up to 250 Hosts

To achieve a requirement of 8 subnets with up to 250 hosts, a 3-bit subnetting of subnetted network ID of 135.41.248.0/21 is done, producing 8 subnets (135.41.248.0/24, 135.41.249.0/24 . . . 135.41.254.0/24, 135.41.255.0/24) and allowing up to 254 hosts per subnet. All 8 subnetted network IDs (135.41.248.0/24 to 135.41.255.0/24) are chosen as the network IDs, which fulfills the requirement.

Table 2.25 illustrates 8 subnets with approximately 250 hosts.

Table 2.25 Eight subnets with up to 254 Hosts

Subnet Number | Network ID (Dotted Decimal) | Network ID (Network Prefix)
1 | 135.41.248.0, 255.255.255.0 | 135.41.248.0/24
2 | 135.41.249.0, 255.255.255.0 | 135.41.249.0/24
3 | 135.41.250.0, 255.255.255.0 | 135.41.250.0/24
4 | 135.41.251.0, 255.255.255.0 | 135.41.251.0/24
5 | 135.41.252.0, 255.255.255.0 | 135.41.252.0/24
6 | 135.41.253.0, 255.255.255.0 | 135.41.253.0/24
7 | 135.41.254.0, 255.255.255.0 | 135.41.254.0/24
8 | 135.41.255.0, 255.255.255.0 | 135.41.255.0/24

The variable length subnetting of 135.41.0.0/16 is shown graphically in Figure 2.10.

Figure 2.10 Variable-Length Subnetting of 135.41.0.0/16

Note

In dynamic routing environments, variable-length subnetting can only been deployed where the subnet mask is advertised along with the network ID. Routing Information Protocol (RIP) for IP version 1 does not support variable-length subnetting. RIP for IP version 2, Open Shortest Path First (OSPF), and BGPv4 all support variable-length subnetting.


Supernetting and Classless Interdomain Routing

With the recent growth of the Internet, it became clear to the Internet authorities that the class B network IDs would soon be depleted. For most organizations, a class C network ID does not contain enough host IDs and a class B network ID has enough bits to provide a flexible subnetting scheme within the organization.

The Internet authorities devised a new method of assigning network IDs to prevent the depletion of class B network IDs. Rather than assigning a class B network ID, InterNIC assigns a range of class C network IDs that contain enough network and host IDs for the organization’s needs. This is known as supernetting. For example, rather than allocating a class B network ID to an organization that has up to 2,000 hosts, the InterNIC allocates a range of 8 class C network IDs. Each class C network ID accommodates 254 hosts, for a total of 2,032 host IDs.

Although this technique helps conserve class B network IDs, it creates a new problem. Using conventional routing techniques, the routers on the Internet now must have 8 class C network ID entries in their routing tables to route IP packets to the organization. To prevent Internet routers from becoming overwhelmed with routes, a technique called Classless Interdomain Routing (CIDR) is used to collapse multiple network ID entries into a single entry corresponding to all of the class C network IDs allocated to that organization.

Conceptually, CIDR creates the routing table entry: {Starting Network ID, count}, where Starting Network ID is the first class C network ID and the count is the number of class C network IDs allocated. In practice, a supernetted subnet mask is used to convey the same information. To express the situation where 8 class C network IDs are allocated starting with Network ID 220.78.168.0:

Starting Network ID | 220.78.168.0 | 100111100 01001110 10101000 00000000
Ending Network ID | 220.78.175.0 | 100111100 01001110 10101111 00000000

Note that the first 21 bits (underlined) of all the above Class C network IDs are the same. The last three bits of the third octet vary from 000 to 111. The CIDR entry in the routing tables of the Internet routers becomes:

Network ID | Subnet Mask | Subnet Mask (binary)
220.78.168.0 | 255.255.248.0 | 1111111111 11111111 11111000 00000000

In network prefix notation, the CIDR entry is 220.78.168.0/21.

A block of addresses using CIDR is known as a CIDR block.

Note

Because subnet masks are used to express the count, class-based network IDs must be allocated in groups corresponding to powers of 2.

In order to support CIDR, routers must be able to exchange routing information in the form of {Network ID, Subnet Mask} pairs. RIP for IP version 2, OSPF and BGPv4 are routing protocols that support CIDR. RIP for IP version 1 does not support CIDR.

Address Space Perspective

The use of CIDR to allocate addresses promotes a new perspective on IP network IDs. In the above example, the CIDR block {220.78.168.0, 255.255.248.0} can be thought of in two ways:

  • A block of 8 class C network IDs.
  • An address space in which 21 bits are fixed and 11 bits are assignable.

In the latter perspective, IP network IDs lose their class-based heritage and become separate IP address spaces, subsets of the original IP address space defined by the 32-bit IP address. Each IP network ID (class-based, subnetted, CIDR block), is an address space in which certain bits are fixed (the network ID bits) and certain bits are variable (the host bits). The host bits are assignable as host IDs or, using subnetting techniques, can be used in whatever manner best suits the needs of the organization.


Public and Private Addresses

If your intranet is not connected to the Internet, any IP addressing can be deployed. If direct (routed) or indirect (proxy or translator) connectivity to the Internet is desired, there are two types of addresses employed on the Internet, public addresses and private addresses.

Public Addresses

Public addresses are assigned by InterNIC and consist of class-based network IDs or blocks of CIDR-based addresses (called CIDR blocks) that are guaranteed to be globally unique to the Internet.

When the public addresses are assigned, routes are programmed into the routers of the Internet so that traffic to the assigned public addresses can reach their locations. Traffic to destination public addresses are reachable on the Internet.

For example, when an organization is assigned a CIDR block in the form of a network ID and subnet mask, that {network ID, subnet mask} pair also exists as a route in the routers of the Internet. IP packets destined to an address within the CIDR block are routed to the proper destination.

Illegal Addresses

Private intranets that have no intent on connecting to the Internet can choose any addresses they want, even public addresses that have been assigned by the InterNIC. If an organization later decides to connect to the Internet, its current address scheme might include addresses already assigned by the InterNIC to other organizations. These addresses would be duplicate or conflicting addresses and are known as illegal addresses. Connectivity from illegal addresses to Internet locations is not possible.

For example, a private organization chooses to use 207.46.130.0/24 as its intranet address space. The public address 207.46.130.0/24 has been assigned to the Microsoft corporation and routes exist on the Internet routers to route all packets destined to IP addresses on 207.46.130.0/24 to Microsoft routers. As long as the private organization does not connect to the Internet, there is no problem because the two address spaces are on separate IP internetworks. If the private organization then connected directly to the Internet and continued to use 207.46.130.0/24 as its address space, then any Internet response traffic to locations on the 207.46.130.0/24 network would be routed to Microsoft routers, not to the routers of the private organization.

Private Addresses

Each IP node requires an IP address that is globally unique to the IP internetwork. In the case of the Internet, each IP node on a network connected to the Internet requires an IP address that is globally unique to the Internet. As the Internet grew, organizations connecting to the Internet required a public address for each node on their intranets. This requirement placed a huge demand on the pool of available public addresses.

When analyzing the addressing needs of organizations, the designers of the Internet noted that for many organizations, most of the hosts on the organization’s intranet did not require direct connectivity to Internet hosts. Those hosts that did require a specific set of Internet services, such as the World Wide Web access and e-mail, typically access the Internet services through application layer gateways such as proxy servers and e-mail servers. The result is that most organizations only required a small amount of public addresses for those nodes (such as proxies, routers, firewalls, and translators) that were directly connected to the Internet.

For the hosts within the organization that do not require direct access to the Internet, IP addresses that do not duplicate already-assigned public addresses are required. To solve this addressing problem, the Internet designers reserved a portion of the IP address space and named this space the private address space. An IP address in the private address space is never assigned as a public address. IP addresses within the private address space are known as private addresses. Because the public and private address spaces do not overlap, private addresses never duplicate public addresses.

The private address space specified in RFC 1597 is defined by the following three address blocks:

  • The 10.0.0.0/8 private network is a class A network ID that allows the following range of valid IP addresses: 10.0.0.1 to 10.255.255.254. The 10.0.0.0/8 private network has 24 host bits that can be used for any subnetting scheme within the private organization.

  • The 172.16.0.0/12 private network can be interpreted either as a block of 16 class B network IDs or as a 20-bit assignable address space (20 host bits) that can be used for any subnetting scheme within the private organization. The 172.16.0.0/12 private network allows the following range of valid IP addresses: 172.16.0.1 to 172.31.255.254.

  • The 192.168.0.0/16 private network can be interpreted either as a block of 256 class C network IDs or as a 16-bit assignable address space (16 host bits) that can be used for any subnetting scheme within the private organization. The 192.168.0.0/16 private network allows the following range of valid IP addresses: 192.168.0.1 to 192.168.255.254.

The result of many organizations using private addresses is that the private address space is re-used, helping to prevent the depletion of public addresses.

Because the IP addresses in the private address space will never be assigned by the InterNIC as public addresses, there will never exist routes in the Internet routers for private addresses. Private addresses are not reachable on the Internet. Therefore, Internet traffic from a host that has a private address must either send its requests to an application layer gateway (such as a proxy server), which has a valid public address, or have its private address translated into a valid public address by a network address translator (NAT) before it is sent on the Internet. For more information about NAT, see “Unicast IP Routing” in the Microsoft® Windows® 2000 Internetworking guide.


Name Resolution

While IP is designed to work with the 32-bit IP addresses of the source and the destination hosts, computers users are much better at using and remembering names than IP addresses.

If a name is used as an alias for the IP address, there must exist a mechanism for assigning that name to the appropriate IP node to ensure its uniqueness and resolving it to its IP address.

In this section, the mechanisms used for assigning and resolving host names (which are used by Windows Sockets applications), and NetBIOS names (which are used by NetBIOS applications) are discussed.


Host Name Resolution

A host name is an alias assigned to an IP node to identify it as a TCP/IP host. The host name can be up to 255 characters long and can contain alphabetic and numeric characters and the “-“ and “.” characters. Multiple host names can be assigned to the same host. For Windows 2000–based computers, the host name does not have to match the Windows 2000 computer name.

Windows Sockets applications, such as Microsoft® Internet Explorer and the FTP utility, can use one of two values for the destination to be connected: the IP address or a host name. When the IP address is specified, name resolution is not needed. When a host name is specified, the host name must be resolved to an IP address before IP-based communication with the desired resource can begin.

Host names can take various forms. The two most common forms are a nickname and a domain name. A nickname is an alias to an IP address that individual people can assign and use. A domain name is a structured name that follows Internet conventions.

Domain Names

To facilitate different organizations and their desires to have scaleable, customizable naming scheme in which to operate, the InterNIC has created and maintains a hierarchical namespace called the Domain Name System (DNS). DNS is a naming scheme that looks similar to the directory structure for files on a disk. However, instead of tracing a file from the root directory through subdirectories to its final location and its file name, a host name is traced from its final location through its parent domains back up to the root. The unique name of the host, representing its position in the hierarchy, is called its Fully Qualified Domain Name (FQDN). The top-level domain namespace is shown in Figure 2.11 with example second-level and subdomains.

Figure 2.11 Domain Name System

The domain namespace consists of:

  • The root domain, representing the root of the namespace and indicated with a “” (null).
  • Top-level domains, those directly below the root, indicating a type of organization. On the Internet, the InterNIC is responsible for the maintenance of top-level domain names. Table 2.26 has a partial list of the Internet’s top-level domain names.

Table 2.26 Internet Top-Level Domain Names

Domain Name | Meaning
COM | Commercial organization
EDU | Educational institution
GOV | Government institution
MIL | Military group
NET | Major network support center
ORG | Organization other than those above
INT | International organization
<country code> | Each country (geographic scheme)

  • Second-level domains, below the top level domains, identifying a specific organization within its top-level domain. On the Internet, the InterNIC is responsible for the maintenance of second-level domain names and ensuring their uniqueness.
  • Subdomains of the organization, below the second-level domain. The individual organization is responsible for the creation and maintenance of subdomains.

For example, for the FQDN ftpsrv.wcoast.slate.com:

  • The trailing period (.) denotes that this is an FQDN with the name relative to the root of the domain namespace. The trailing period is usually not required for FQDNs and if it is missing it is assumed to be present.
  • com is the top-level domain, indicating a commercial organization.
  • slate is the second-level domain, indicating the Slate magazine company.
  • wcoast is a subdomain of slate.com indicating the West Coast division of the Slate magazine company.
  • ftpsrv is the name of the FTP server in the West Coast division.

Domain names are not case sensitive.

Organizations not connected to the Internet can implement whatever top and second-level domain names they want. However, typical implementations do adhere to the InterNIC specification so that eventual participation in the Internet will not require a renaming process.

Host Name Resolution Using a HOSTS File

One common way to resolve a host name to an IP address is to use a locally stored database file that contains IP-address-to-host-name mappings. On most UNIX systems, this file is /etc/hosts. On Windows 2000 systems, it is the HOSTS file in the \SystemRoot\system32\drivers\etc directory.

Following is an example of the contents of the HOSTS file:

#
# Table of IP addresses and host names
#
127.0.0.1        localhost
139.41.34.1        router
167.91.45.121    server1.central.slate.com s1

Within the HOSTS file:

  • Multiple host names can be assigned to the same IP address. Note that the server at the IP address 167.91.45.121 can be referred to by its FQDN (server1.central.slate.com) or a nickname (s1). This allows the user at this computer to refer to this server using the nickname s1 rather than typing the entire FQDN.
  • Entries can be case sensitive depending on the platform. Entries in the HOSTS file for UNIX computers are case sensitive. Entries in the HOSTS file for Windows 2000 and Windows NT–based computers are not case sensitive.

The advantage of using a HOSTS file is that it is customizable for the user. Each user can create whatever entries they want, including easy-to-remember nicknames for frequently accessed resources. However, the individual maintenance of the HOSTS file does not scale well to storing large numbers of FQDN mappings.

Host Name Resolution Using a DNS server

To make host name resolution scaleable and centrally manageable, IP address mappings for FQDNs are stored on DNS servers, a computer that stores FQDN-to-IP-address mappings. To enable the querying of a DNS server by a host computer, a component called the DNS resolver is enabled and configured with the IP address of the DNS server. The DNS resolver is a built-in component of TCP/IP protocol stacks supplied with most network operating systems, including Windows 2000.

When a Windows Sockets application is given an FQDN as the destination location, the application calls a Windows Sockets function to resolve the name to an IP address. The request is passed to the DNS resolver component in the TCP/IP protocol. The DNS resolver packages the FQDN request as a DNS Name Query packet and sends it to the DNS server.

DNS is a distributed naming system. Rather than storing all the records for the entire namespace on each DNS server, each DNS server only stores the records for a specific portion of the namespace. The DNS server is authoritative for the portion of the namespace that corresponds to records stored on that DNS server. In the case of the Internet, hundreds of DNS servers store various portions of the Internet namespace. To facilitate the resolution of any valid domain name by any DNS server, DNS servers are also configured with pointer records to other DNS servers.

The following process outlines what happens when the DNS resolver component on a host sends a DNS query to a DNS server. This process is shown in Figure 2.12 and is simplified so that you can gain a basic understanding of the DNS resolution process.

  1. The DNS resolver component formats a DNS Name Query containing the FQDN and sends it to the configured DNS server.
  2. The DNS server checks the FQDN in the DNS Name Query against locally stored address records. If a record is found, the IP address corresponding to the requested FQDN is sent back to the client.
  3. If the FQDN is not found, the DNS server forwards the request to a DNS server that is authoritative for the FQDN.
  4. The authoritative DNS server returns the reply, containing the resolved IP address, back to the original DNS server.
  5. The original DNS server sends the IP address mapping information to the client.

Figure 2.12 Resolving an FQDN Using DNS servers

To obtain the IP address of a server that is authoritative for the FQDN, DNS servers on the Internet go through an iterative process of querying multiple DNS servers until the authoritative server is found. More details about this iterative process can be found in “Windows 2000 DNS” in this book.

Combining a Local Database File with DNS

TCP/IP implementations, including Windows 2000, allow the use of both a local database file and a DNS server to resolve host names. When a user specifies a host name in a TCP/IP command or utility:

  1. TCP/IP checks the local database file (the HOSTS file) for a matching name.
  2. If a matching name is not found in the local database file, the host name is packaged as a DNS Name Query and sent to the configured DNS server.

Combining both methods gives the user the ability to have a local database file to resolve personalized nicknames and to use the globally distributed DNS database to resolve FQDNs.


NetBIOS Name Resolution

NetBIOS name resolution is the process of successfully mapping a NetBIOS name to an IP address. A NetBIOS name is a 16-byte address used to identify a NetBIOS resource on the network. A NetBIOS name is either a unique (exclusive) or group (non-exclusive) name. When a NetBIOS process communicates with a specific process on a specific computer, a unique name is used. When a NetBIOS process communicates with multiple processes on multiple computers, a group name is used.

The NetBIOS name acts as a session layer application identifier. For example, the NetBIOS Session service operates over TCP port 139. All NetBIOS over TCP/IP session requests are addressed to TCP destination port 139. To identify with which NetBIOS application to establish a NetBIOS session, the NetBIOS name is used.

An example of a process using a NetBIOS name is the file and print sharing server service on a Windows 2000–based computer. When your computer starts up, the server service registers a unique NetBIOS name based on your computer’s name. The exact name used by the server service is the 15 character computer name plus a 16th character of 0x20. If the computer name is not 15 characters long, it is padded with spaces up to 15 characters long. Other network services also use the computer name to build their NetBIOS names so the 16th character is used to uniquely identify each service, such as the redirector, server, or messenger services. Figure 2.13 shows the NetBIOS names associated with the server, redirector, and messenger services.

Figure 2.13 NetBIOS Names and Services

When you attempt to make a file sharing connection to a Windows 2000–based computer by name, the server service on the file server you specify corresponds to a specific NetBIOS name. For example, when you attempt to connect to the computer called CORPSERVER, the NetBIOS name corresponding to the server service is “CORPSERVER <20>” (note the padding using spaces). Before a file and print sharing connection can be established, a TCP connection must be created. In order for a TCP connection to be established, the NetBIOS name “CORPSERVER <20>” must be resolved to an IP address.

To view the NetBIOS names registered by NetBIOS processes running on a Windows 2000 computer, type "nbtstat -n" at the Windows 2000 command prompt.

NetBIOS Node Types

The exact mechanism by which NetBIOS names are resolved to IP addresses depends on the node’s configured NetBIOS Node Type. RFC 1001 define the NetBIOS Node Types, as listed in Table 2.27.

Table 2.27 NetBIOS Node Types

Node Type | Description
B-node (broadcast) | B-node uses broadcasted NetBIOS Name Queries for name registration and resolution. B-node has two major problems: (1) In a large internetwork, broadcasts can increase the network load, and (2) Routers typically do not forward broadcasts, so only NetBIOS names on the local network can be resolved.
P-node (peer-peer) | P-node uses a NetBIOS name server (NBNS), such as Windows Internet Name Service (WINS), to resolve NetBIOS names. P-node does not use broadcasts; instead, it queries the name server directly. The most significant problems with P-node are that all computers must be configured with the IP address of the NBNS, and if the NBNS is down, computers are not able to communicate even on the local network.
M-node (mixed) | M-node is a combination of B-node and P-node. By default, an M-node functions as a B-node. If it is unable to resolve a name by broadcast, it uses the NBNS of P-node.
H-node (hybrid) | H-node is a combination of P-node and B-node. By default, an H-node functions as a P-node. If it is unable to resolve a name through the NetBIOS name server, it uses a broadcast to resolve the name.

Windows 2000–based computers are B-node by default and become H-node when configured for a WINS server (H-node). Windows 2000 also utilizes a local database file called LMHOSTS to resolve remote NetBIOS names.

For more information about WINS, see “Windows Internet Name Service (WINS)” in this book. For more information about the LMHOSTS file, see “LMHOSTS” in this book.


IP Routing

After the host name or NetBIOS name is resolved to an IP address, the IP packet must be sent by the sending host to the resolved IP address. Routing is the process of forwarding a packet based on the destination IP address. Routing occurs at a sending TCP/IP host and at an IP router. A router is a device that forwards the packets from one network to another. Routers are also commonly referred to as gateways. In both cases, sending host and router, a decision has to be made about where the packet is forwarded.

To make these decisions, the IP layer consults a routing table stored in memory. Routing table entries are created by default when TCP/IP initializes and additional entries are added either manually by a system administrator or automatically through communication with routers.


Direct and Indirect Delivery

Forwarded IP packets use at least one of two types of delivery based on whether the IP packet is forwarded to the final destination or whether it is forwarded to an IP router. These two types of delivery are known as direct and indirect delivery.

Direct delivery occurs when the IP node (either the sending node or an IP router) forwards a packet to the final destination on a directly attached network. The IP node encapsulates the IP datagram in a frame format for the Network Interface Layer (such as Ethernet or Token Ring) addressed to the destination’s physical address.

Indirect delivery occurs when the IP node (either the sending node or an IP router) forwards a packet to an intermediate node (an IP router) because the final destination is not on a directly attached network. The IP node encapsulates the IP datagram in a frame format, addressed to the IP router’s physical address, for the Network Interface Layer (such as Ethernet or Token Ring).

IP routing is a combination of direct and indirect deliveries.

In Figure 2.14, when sending packets to node B, node A performs a direct delivery. When sending packets to node C, node A performs an indirect delivery to Router 1. Router 1 performs an indirect delivery to Router 2. Router 2 performs a direct delivery to node C.

Figure 2.14 Direct and Indirect Deliveries


IP Routing Table

A routing table is present on all IP nodes. The routing table stores information about IP networks and how they can be reached (either directly or indirectly). Because all IP nodes perform some form of IP routing, routing tables are not exclusive to IP routers. Any node loading the TCP/IP protocol has a routing table. There are a series of default entries according to the configuration of the node and additional entries can be entered either manually through TCP/IP utilities or dynamically through interaction with routers.

When an IP packet is to be forwarded, the routing table is used to determine:

  1. The forwarding IP address:

    For a direct delivery, the forwarding IP address is the destination IP address in the IP packet. For an indirect delivery, the forwarding IP address is the IP address of a router.

  2. The interface to be used for the forwarding:

    The interface identifies the physical or logical interface such as a network adapter that is used to forward the packet to either its destination or the next router.

IP Routing Table Entry Types

An entry in the IP routing table contains the following information in the order presented:

Network ID. The network ID corresponding to the route. The Network ID can be class-based, a subnet, a supernet, or an IP address for a host route.

Subnet Mask. The subnet mask that is used to match a destination IP address to the Network ID.

Next Hop. The IP address of the next hop.

Interface. An indication of which network interface is used to forward the IP packet.

Metric. A number used to indicate the cost of the route so the best route among possible multiple routes to the same destination can be selected. A common use of the metric is to indicate the number of hops (routers crossed) to the Network ID. The route with the lowest metric is the best route.

Routing table entries can be used to store the following types of routes:

Directly Attached Network IDs. Routes for network IDs that are directly attached. For directly attached networks, the Next Hop field can be blank or contain the IP address of the interface on that network.

Remote Network IDs. Routes for network IDs that are not directly attached but are available across other routers. For remote networks, the Next Hop field is the IP address of a local router in between the forwarding node and the remote network.

Host Routes. A route to a specific IP address. Host routes allow routing to occur on a per-IP address basis. For host routes, the Network ID is the IP address of the specified host and the subnet mask is 255.255.255.255.

Default Route. The default route is designed to be used when a more specific Network ID or host route is not found. The default route network ID is 0.0.0.0 with the subnet mask of 0.0.0.0.

Route Determination Process

To determine which routing table entry is used for the forwarding decision, IP uses the following process:

  • For each entry in routing table, perform a bit-wise logical AND between the Destination IP address and the Subnet Mask. Compare the result with the Network ID of the entry for a match.
  • The list of matching routes is compiled. The route that has the longest match (the route that matched the most amount of bits with the destination IP address) is chosen. The longest matching route is the most specific route to the destination IP address. If multiple entries with the longest match are found (multiple routes to the same network ID, for example), the router uses the lowest metric to select the best route. If multiple entries exist that are the longest match and the lowest metric, the router is free to choose which routing table entry to use.

The end result of the route determination process is the choice of a single route in the routing table. The route chosen yields a forwarding IP address (the next hop IP address) and an interface (the port). If the route determination process fails to find a route, IP declares a routing error. For the sending host, an IP routing error is internally indicated to the upper layer protocol such as TCP or UDP. For a router, an ICMP Destination Unreachable-Network Unreachable message is sent to the source host.

Example Routing Table for Windows 2000

Table 2.28 shows the default routing table for a Windows 2000–based host (not a router). The host has a single network adapter and has the IP address 157.55.27.90, subnet mask 255.255.240.0 (/20), and default gateway of 157.55.16.1.

Table 2.28 Windows 2000 Routing Table

Network Destination | Netmask | Gateway | Interface | Metric | Purpose
0.0.0.0 | 0.0.0.0 | 157.55.16.1 | 157.55.27.90 | 1 | Default Route
127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 | 1 | Loopback Network
127.0.0.1 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 1 | Loopback Address
157.55.16.0 | 255.255.240.0 | 157.55.27.90 | 157.55.27.90 | 1 | Directly Attached Network
157.55.27.90 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 1 | Local Host
157.55.255.255 | 255.255.255.255 | 157.55.27.90 | 157.55.27.90 | 1 | Network Broadcast
224.0.0.0 | 224.0.0.0 | 157.55.27.90 | 157.55.27.90 | 1 | Multicast Address
255.255.255.255 | 255.255.255.255 | 157.55.27.90 | 157.55.27.90 | 1 | Limited Broadcast

  • Default Route.

    The entry corresponding to the default gateway configuration is a Network Address of 0.0.0.0 with a subnet mask of 0.0.0.0. Any destination IP address joined with 0.0.0.0 by a logical AND results in 0.0.0.0. Therefore, for any IP address, the default route produces a match. If the default route is chosen because no better routes were found, the IP packet is forwarded to the IP address in the Gateway column using the interface corresponding to the IP address in the Interface column.

  • Loopback Network

    The loopback network entry is designed to take any IP address of the form 127.x.y.z and forward it to the special loopback address of 127.0.0.1.

  • Loopback Address

    The loopback address entry is a host route that forwards packets addressed to 127.0.0.1 to the special loopback address of 127.0.0.1.

  • Directly Attached Network

    The local network entry corresponds to the directly attached network. IP packets destined for the directly attached network are not forwarded to a router but sent directly to the destination. Note that the Gateway Address and Interface column are the IP address of the node. This indicates that the packet is sent out the network adapter corresponding to the node’s IP address.

  • Local Host

    The local host entry is a host route (subnet mask of 255.255.255.255) corresponding to the IP address of the host. All IP datagrams to the IP address of the host are forwarded to the loopback address.

  • Network Broadcast

    The network broadcast entry is a host route (subnet mask of 255.255.255.255) corresponding to the all-subnets directed broadcast address (all subnets of class B network ID 157.55.0.0). Packets addressed to the all-subnets directed broadcast are sent out the network adapter corresponding to the node’s IP address.

  • Multicast Address

    The multicast address, with its class D subnet mask, is used to route any multicast IP packets out the netcard corresponding to the node’s IP address.

  • Limited Broadcast

    The limited broadcast address is a host route (subnet mask of 255.255.255.255). Packets addressed to the limited broadcast are sent out the netcard corresponding to the node’s IP address.

To view the IP routing table on a Windows 2000 computer, type route print at a Windows 2000 command prompt.

When determining the forwarding IP address from a route in the routing table:

  • If the Gateway address is the same as the interface address, the forwarding IP address is set to the destination IP address of the IP packet.
  • If the Gateway address is not the same as the interface address, the forwarding IP address is set to the gateway address.

For example, when traffic is sent to 157.55.16.48, the most specific route is the route for the directly attached network (157.55.16.0/20). The forwarding IP address is set to destination IP address (157.55.16.48) and the interface is the network adapter, which has been assigned the IP address 157.55.27.90.

When sending traffic to 157.20.0.79, the most specific route is the default route (0.0.0.0/0). The forwarding IP address is set to the gateway address (157.20.16.1) and the interface is the network adapter, which has been assigned the IP address 157.55.27.90.


Routing Processes

The IP routing processes on all nodes involved in the delivery of an IP packet includes: the sending host, the intermediate routers, and the destination host.

IP on the Sending Host

When a packet is sent by a sending host, the packet is handed from an upper layer protocol (TCP, UDP, or ICMP) to IP. IP on the sending host does the following:

  1. Sets the Time-to-Live (TTL) value to either a default or application-specified value.
  2. IP checks its routing table for the best route to the destination IP address.

    If no route is found, IP indicates a routing error to the upper layer protocol (TCP, UDP, or ICMP).

  3. Based on the most specific route, IP determines the forwarding IP address and the interface to be used for forwarding the packet.
  4. IP hands the packet, the forwarding IP address, and the interface to ARP, and ARP resolves the forwarding IP address to its MAC address and forwards the packet.

IP on the Router

When a packet is received at a router, the packet is passed up to IP. IP on the router does the following:

  1. IP verifies the IP header checksum.

    If the IP header checksum fails, the IP packet is discarded without notification to the user. This is known as a silent discard.

  2. IP verifies whether the destination IP address in the IP datagram corresponds to an IP address assigned to a router interface.

    If so, the router processes the IP datagram as the destination host (see Step 3 in the “IP on the Destination Host” section).

  3. If the destination IP address is not the router, IP decreases the time-to-live (TTL) by 1.

    If the TTL is 0, the router discards the packet and sends an ICMP Time Expired-TTL Expired message to the sender.

  4. If the TTL is 1 or greater, IP updates the TTL field and calculates a new IP header checksum.
  5. IP checks its routing table for the best route to the destination IP address in the IP datagram.

    If no route is found, the router discards the packet and sends an ICMP Destination Unreachable-Network Unreachable message to the sender.

  6. Based on the best route found, IP determines the forwarding IP address and the interface to be used for the forwarding.
  7. IP hands the packet, the forwarding IP address, and the interface to ARP, and ARP forwards the packet to the appropriate MAC address.

This entire process is repeated at each router in the path between the source and destination host.

IP on the Destination Host

When a packet is received at the destination host, it is passed up to IP. IP on the destination host does the following:

  1. IP verifies the IP header checksum.

    If the IP header checksum fails, the IP packet is silently discarded.

  2. IP verifies that the destination IP address in the IP datagram corresponds to an IP address assigned to the host.

    If the destination IP address is not the host, the IP packet is silently discarded.

  3. Based on the IP protocol field, IP passes the IP datagram without the IP header to the appropriate upper-level protocol.

    If the protocol does not exist, ICMP sends a Destination Unreachable-Protocol Unreachable message back to the sender.

  4. For TCP and UDP packets, the destination port is checked and the TCP segment or UDP header is processed.

    If no application exists for the UDP port number, ICMP sends a Destination Unreachable-Port Unreachable message back to the sender. If no application exists for the TCP port number, TCP sends a Connection Reset segment back to the sender.


Static and Dynamic IP Routers

For IP routing between routers to occur efficiently in the IP internetwork, routers must have explicit knowledge of remote network IDs or be properly configured with a default route. On large IP internetworks, one of the challenges faced by network administrators is how to maintain the routing tables on their IP routers so that IP traffic flow is traveling the best path and is fault-tolerant.

There are two ways of maintaining routing table entries on IP routers:

  • Manually—Static IP routers have routing tables that do not change unless manually changed by a network administrator.

    Static routing relies on the manual administration of the routing table. Remote network IDs are not discovered by static routers and must be manually configured. Static routers are not fault tolerant. If a static router goes down, neighboring routers do not sense the fault and inform other routers.

  • Automatically—Dynamic IP routers have routing tables that change automatically based on the communication of routing information with other routers.

    Dynamic routing employs the use of routing protocols, such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), to dynamically update the routing table through the exchange of routing information between routers. Remote network IDs are discovered by dynamic routers and automatically entered into the routing table. Dynamic routers are fault-tolerant. If a dynamic router goes down, the fault is sensed by neighboring routers who propagate the changed routing information to the other routers in the internetwork.

For more information about routing principles, see “Unicast Routing Overview,” in the Internetworking book. For more information about IP routing protocols, see “Unicast IP Support,” in the Internetworking book.


Physical Address Resolution

Based on the destination IP address and the route determination process, IP determines the forwarding IP address and interface to be used to forward the packet. IP then hands the IP packet, the forwarding IP address, and the interface, to ARP.

If the forwarding IP address is the same as the destination IP address, then ARP performs a direct delivery. In a direct delivery, the MAC address corresponding to the destination IP address must be resolved.

If the forwarding IP address is not the same as the destination IP address, then ARP performs an indirect delivery. The forwarding IP address is the IP address of a router between the current IP node and the final destination. In an indirect delivery, the MAC address corresponding to the IP address of the router must be resolved.

To resolve a forwarding IP address to its MAC address, ARP uses the broadcasting facility on shared access networking technologies (such as Ethernet or Token Ring) to send out a broadcasted ARP Request frame. An ARP Reply, containing the MAC address corresponding to the desired forwarding IP address, is sent back to the sender of the ARP Request.


ARP Cache

To keep the number of broadcasted ARP Request frames to a minimum, many TCP/IP protocol stacks incorporate an ARP cache, a table of recently resolved IP addresses and their corresponding MAC addresses. The ARP cache is checked first before sending an ARP Request frame. Each interface has its own ARP cache.

Depending on the vendor implementation, the ARP cache can have the following qualities:

  • ARP cache entries can be dynamic (based on ARP Replies) or static. Static ARP entries are permanent and are manually added using a TCP/IP utility such as the ARP utility provided with Windows 2000. Static ARP cache entries are used to prevent ARP Requests for commonly-used local IP addresses, such as routers and servers. The problem with static ARP entries is that they have to be manually updated when network interface equipment changes.
  • Dynamic ARP cache entries have a time-out value associated with them to remove entries in the cache after a specified period of time. Dynamic ARP cache entries for Windows 2000 TCP/IP are given a maximum time of ten minutes before being removed.

To view the ARP cache on a Windows 2000 computer, type arp-a at a Windows 2000 command prompt.


ARP Process

IP sends information to ARP. ARP receives the IP packet, the forwarding IP address, and the interface to be used to forward the packet. Whether performing a direct or indirect delivery, ARP performs the following process, as displayed in Figure 2.15:

  1. Based on the interface and the forwarding IP address, ARP consults the appropriate ARP cache for an entry for the forwarding IP address. If an entry is found, ARP skips to step 6.
  2. If the mapping is not found, ARP builds an ARP Request frame containing the MAC Address of the interface sending the ARP Request, the IP address of the interface sending the ARP Request, and the forwarding IP address. ARP then broadcasts the ARP Request using the appropriate interface.
  3. All hosts receive the broadcasted frame and the ARP Request is processed. If the receiving host’s IP address matches the requested IP address (the forwarding IP address), its ARP cache is updated with the address mapping of the sender of the ARP Request.

    If the receiving host’s IP address does not match the requested IP address, the ARP request is silently discarded.

  4. The receiving host formulates an ARP Reply containing the requested MAC address and sends it directly to the sender of the ARP Request.
  5. When the ARP Reply is received by the sender of the ARP Request, it updates its ARP cache with the address mapping.

    Between the ARP Request and the ARP Reply, both hosts have each other’s address mappings in their ARP caches.

  6. The IP packet is sent to the MAC address of the forwarding host by addressing it to the resolved MAC address.

Figure 2.15 ARP Process


Understanding DNS

DNS enables you to use hierarchical, friendly names to easily locate computers and other resources on an IP network. The following sections describe the basic Domain Name System (DNS) concepts, including features explained in newer Requests for Comments (RFCs), such as dynamic update. Microsoft® Windows® 2000–specific implementation of DNS is not covered within this chapter, except where indicated.

DNS is a distributed database that contains mappings of domain names to data. It is also a protocol for Transmission Control Protocol/Internet Protocol (TCP/IP) networks, defined by the DNS Requests for Comments (RFCs). DNS defines the following:

  • A mechanism for querying and updating the database.
  • A mechanism for replicating the information in the database among servers.
  • A schema of the database.

In This Chapter

Introduction to the Domain Name System

DNS servers

Name Resolution

Resource Records and Zone Files

Zone Transfer

Dynamic Update

DNS Standards

Related Chapters in the Resource Kit

  • For more information about TCP/IP protocols, see “Introduction to TCP/IP” in this book.

Additional Resources

  • For more information about conceptual information about DNS, see DNS and BIND by Paul Albitz and Cricket Liu, O’Reilley & Associates, Inc., 1997.
  • For more information about Requests for Comments (RFCs) and Internet drafts, see http://www.ietf.org/.


Introduction to the Domain Name System

Although TCP/IP uses IP addresses to locate and connect to hosts (computers and other TCP/IP network devices), users typically prefer to use host names. For example, users prefer the friendly name ftp.reskit.com, instead of its IP address, 172.16.23.55. The Domain Name System (DNS), defined in RFCs 1034 and 1035, is used on the Internet to provide a standard naming convention for locating IP-based computers.

On the Internet, before the implementation of DNS, the use of names to locate resources on TCP/IP networks was supported by a file called hosts. Network administrators entered the host names and their IP addresses into the hosts file, and computers used the file for name resolution.

The hosts file uses a flat namespace. A namespace is a set grouping in which names can be used to symbolically represent another type of information, such as an IP address, and in which specific rules are established that determine how names can be created and used. Some namespaces, such as DNS, are hierarchically structured and provide rules that allow for the namespace to be divided into subsets of names for distributing and delegating parts of the namespace to others. Other namespaces, such as the hosts namespace, are flat or unstructured. They cannot be divided and must be distributed in their entirety. Because the hosts file used a flat namespace, using the hosts file posed a problem for network administrators. As the number of computers and users on the Internet grew, the task of updating and distributing the hosts file became unmanageable.

DNS replaces the hosts file with a distributed database that implements a hierarchical naming system. This naming system allows for growth on the Internet and the creation of host names that are unique throughout the Internet and private TCP/IP-based intranets.


Domain Namespace

The naming system on which DNS is based is a hierarchical and logical tree structure called the domain namespace. Organizations can also create private networks that are not visible on the Internet, using their own domain namespaces. Figure 7.1 shows part of the Internet domain namespace, from the root domain and top-level Internet domains, to the fictional domain named reskit.com that contains a host (computer) named Mfgserver.

Figure 7.1 Domain Name System

Each node, or intersection, in the DNS tree represents either a domain or a host. Domains can contain both hosts and other domains (referred to as subdomains). Each organization is assigned authority for a portion of the domain namespace and is responsible for administering, subdividing, and naming the domains and computers within that portion of the domain.

Subdividing is an important concept in DNS. Creating subdivisions of the domain namespace and private TCP/IP network domains supports new growth on the Internet and the ability to continually expand name and administrative groupings. Subdivisions are generally based on departmental or geographic divisions.

For example, the reskit.com domain could include sites in North America and Europe. A DNS administrator of the reskit.com domain could subdivide the domain to create two subdomains that reflect these groupings: noam and eu. Figure 7.2 shows an example of these subdomains.

Figure 7.2 Subdomains

Domain Name

Computers and domains are named based on their position in the domain tree. For example, because reskit is a subdomain of the .com domain, the domain name for reskit is reskit.com.

Every computer in the domain tree can be identified by a fully qualified domain name (FQDN). The FQDN is a DNS domain name that has been stated unambiguously so as to indicate with absolute certainty its location relative to the root of the domain tree. This contrasts with a relative name, which is a name relative to some domain other than the root.

For example, the FQDN for the server in the reskit.com domain is constructed as Mfgserver.reskit.com., which is the concatenation of the computer name (Mfgserver) with the domain name (reskit.com), and the trailing dot (.). The trailing dot signifies the root of the namespace, thereby indicating that the name is written as an FQDN.

Note

In general, domain names and computer names have naming restrictions that allow only the use of characters a-z, A-Z, 0-9, and the dash or minus sign (-). The use of characters such as the slash (/), and underscore (_) is not allowed by specification, and the use of the period (.) is allowed only between domain names (for example, “reskit.com”) or at the end of a FQDN. Domain names are not case-sensitive.

However, the Microsoft DNS server does allow the use of underscore (_) in a name, to support NetBIOS names that included the underscore. You can configure the DNS server to enforce all RFC character restrictions or to ignore all character restrictions. It is best to enforce all RFC character restrictions, so that non-Microsoft clients can access the DNS server.

The Internet Domain Namespace

The root (the top-most level) of the Internet domain namespace is managed by an Internet name registration authority, which delegates administrative responsibility for portions of the domain namespace to organizations that connect to the Internet.

Beneath the root domain lie the top-level domains, also managed by the Internet name registration authority. There are three types of top-level domains:

Organizational domains.
These are named by using a 3-character code that indicates the primary function or activity of the organizations contained within the domain. Organizational domains are generally only for organizations within the United States, and most organizations located in the United States are contained within one of these organizational domains.
Geographical domains.
These are named by using the 2-character country codes established by the International Standards Organization (ISO) 3166.
Reverse domain.
This is a special domain, named in-addr.arpa, that is used for IP address-to-name mappings (referred to as reverse name lookup). For more information, see “Name Resolution” later in this chapter. There is also a special domain, named IP6.INT, used for IP version 6 reverse lookups. For information, see RFC 1886.

The most commonly used top-level DNS name components for organizations in the United States are described in the Table 7.1.

Table 7.1 Top-Level Name Component of the DNS Hierarchy

Top-Level Name Component | Description | Example Domain Name
.com | An Internet name authority delegates portions of the domain namespace under this level to commercial organizations, such as the Microsoft Corporation. | Microsoft.com
.edu | An Internet name authority delegates portions of this domain namespace to educational organizations, such as the Massachusetts Institute of Technology (MIT). | mit.edu
.gov | An Internet name authority delegates portions of this domain namespace to governmental organizations, such as the White House in Washington, D.C. | whitehouse.gov
.int | An Internet name authority delegates portions of this domain namespace to international organizations, such as the North Atlantic Treaty Organization (NATO). | nato.int
.mil | An Internet name authority delegates portions of this domain namespace to military operations, such as the Defense Date Network (DDN). | ddn.mil
.net | An Internet name authority delegates portions of this domain namespace to networking organizations, such as the National Science Foundation (NSF). | nsf.net
.org | An Internet name authority delegates portions of this domain namespace to noncommercial organizations, such as the Center for Networked Information Discovery and Retrieval (CNIDR). | cnidr.org

In addition to the top-level domains listed above, individual countries have their own top-level domains. For example, .ca is the top-level domain for Canada.

Beneath the top-level domains, an Internet name authority delegates domains to organizations that connect to the Internet. The organizations to which an Internet name authority delegates a portion of the domain namespace are then responsible for naming the computers and network devices within their assigned domain and its subdivisions. These organizations use DNS servers to manage the name-to-IP address and IP address-to-name mappings for host devices contained within their portion of the namespace.


Basic DNS Concepts

This section provides brief definitions of additional DNS concepts, which are described in more detail in the following sections of this chapter.

DNS servers.
DNS servers are computers that run DNS server programs containing name-to-IP address mappings, IP address-to-name mappings, and information about the domain tree structure. DNS servers also attempt to resolve client queries. When queried, DNS servers can provide the requested information, provide a pointer to another server that can help resolve the query, or respond that it does not have the information or that the information does not exist.
DNS resolvers.
DNS resolvers are programs that use DNS queries to extract information from servers. Resolvers can communicate with either remote DNS servers or the DNS server program running on the local computer. Resolvers are usually built into utility programs or are accessible through library functions. A resolver can run on either a DNS client or a DNS server.
Resource records.
Resource records are sets of information in the DNS database that can be used to process client queries. Each DNS server contains the resource records it needs to answer queries for the portion of the DNS namespace for which it is authoritative. (When a DNS server is authoritative for a portion of the DNS namespace, it is responsible for making sure the information about that portion of the DNS namespace is correct.)
Zone files.
A DNS server can have one or more files, called zone files, that contain information (resource records) about the zones (portions of the DNS namespace) for which the server is authoritative. One exception is the Active Directory–integrated Windows 2000 DNS server.


Zones

A zone is a portion of the DNS namespace that corresponds to a series of records in a file stored on a DNS server. Each zone is anchored at a specific domain node. However, zones are not domains. A domain is a branch of the namespace, whereas a zone is a portion of the DNS namespace stored in a file, and can contain multiple domains. A domain can be subdivided into several partitions, and each partition, or zone, can be controlled by a separate DNS server. Using the zone file, the DNS server answers queries about hosts in its zone, and is authoritative for that zone. Zone files can be primary or secondary. A primary zone file is administered locally, whereas a secondary zone file must be replicated from a server containing the primary zone file.

Figure 7.3 shows an example of a domain that contains two primary zone files. In this example, the domain reskit.com contains two subdomains: noam and eu. Authority for the noam subdomain has been delegated to the server noamdc1 in the noam subdomain. Thus, as Figure 7.3 shows, one primary zone file, on noamdc1, hosts the noam.reskit.com subdomain, and a second primary zone file, on reskitdc1, controls the reskit.com domain and the europe.reskit.com subdomain.

Figure 7.3 Domains and Zones

Rather than delegating the noam zone to noamdc1, the administrator can also configure reskitdc1 to host the zone file for noam, just as reskitdc1 hosts the zone file for eu.

Also, you cannot configure two different servers to manage the same primary zone files; only one server can manage the primary zone file for each domain.

You can configure a single DNS server to manage one zone or multiple zones, depending on your needs. You can create multiple zones to distribute administrative tasks to different groups and to provide efficient data distribution. You can also store the same zone on multiple servers to provide load balancing and fault tolerance.

For information about what zone files contain, see “Resource Records and Zone Files” later in this chapter.


DNS servers

DNS servers store information about one or more zones, generally in the form of zone files. When a DNS server receives a DNS query, it attempts to locate the requested information by retrieving data from its local zone files. If this fails because the server is not authoritative for the domain requested and thus does not have the data for the requested domain, the server can check its cache, communicate with other DNS servers to resolve the request, or refer the client to another DNS server that might know the answer.

DNS servers can host primary and secondary zones. You can configure servers to host as many different primary or secondary zones as is practical, which means that a server might host the primary zone files for one zone and the secondary zone files for another zone, or it might host only the primary or only the secondary file for a zone. For each zone, the server that hosts the primary zone files is considered the primary server for that zone, and the server that hosts the secondary zone files is considered the secondary server for that zone.

Primary zone files are locally administered. When a change is made to the zone data, such as delegating a portion of the zone to another DNS server or adding resource records in the zone, these changes must be made on the primary DNS server for that zone, so that the new information can be entered in the local zone file.

In contrast, secondary zone files are replicated from another server. When a zone is defined on a secondary server for that zone, the zone is configured with the name of the server from which the zone is to be replicated. This server can either be a primary or secondary server for the zone, and is sometimes called a master server for the zone.

When a secondary server for the zone starts up, it contacts the master server for the zone and initiates a zone transfer. The secondary server for the zone can also periodically contact the master server for the zone to see whether the zone data has changed. If so, it can initiate a transfer of the zone files, referred to as a zone transfer. For more information about zone transfers, see “Zone Transfer” later in this chapter.

You must have a primary server for each zone. Additionally, you should have at least one secondary server for each zone. Otherwise, if the primary server for the zone goes down, no one will be able to resolve the names in that zone.

Secondary servers provide the following benefits:

  • Fault tolerance

    When a secondary server is configured for a zone, clients can still resolve names for that zone even if the primary server for the zone goes down. Generally, plan to install the primary and secondary servers for the zone on different subnets. Therefore, if connectivity to one subnet is lost, DNS clients can still direct queries to the name server on the other subnet.

  • Reduction of traffic on wide area links

    You can add a secondary server for the zone in a remote location that has a large number of clients, and then configure the client to try those servers first. This can prevent clients from communicating across slow links for DNS queries.

  • Reduction of load on the primary server for the zone

    The secondary server can answer queries for the zone, reducing the number of queries the primary server for the zone must answer.

The following sections describe servers that act as caching-only servers, forwarders, and slaves.


Caching-Only Servers

All DNS servers perform caching; whenever they successfully resolve a name, they store the result for a certain amount of time. This speeds the performance of DNS resolution, reduces DNS-related query traffic, and improves reliability. For more information, see “Caching and Time to Live” later in this chapter.

Certain DNS servers, known as caching-only servers, simply perform queries, cache the answers, and return the results. They are not authoritative for any domains and do not contain any zone files. They only store data that they have cached while resolving queries.

The benefit provided by caching-only servers is that they do not generate zone transfer network traffic because they do not contain any zone files. However, there is one disadvantage: when the server is initially started, it has no cached information and must build up this information over time as it services requests.


Forwarders and Slaves

When a DNS server receives a query, it attempts to locate the requested information within its local zone files and from the cache. If it cannot locate the requested information, it must communicate with other servers to resolve the request. However, in some cases network administrators might not want the server to communicate directly with other servers. For example, if your organization were connected to the Internet by means of a slow wide area link, you would not want every DNS server in your organization to connect directly to DNS servers on the Internet.

To solve this problem, DNS allows for the use of forwarders. Forwarders are DNS servers that are designated to provide forwarding of off-site queries for other DNS servers. For example, you could designate one DNS server as a forwarder for names of computers on the Internet, and then configure your other servers to use that forwarder when answering queries about names of computers on the Internet. You do not need to perform any special configurations on the computer designated as a forwarder.

A server can use a forwarder in a nonexclusive or exclusive mode. In a nonexclusive mode, when a server receives a DNS query that it cannot resolve through its own zone files, it passes the query to one of the designated forwarders. The forwarder then carries out whatever communication is necessary to resolve the query and returns the results to the requesting server, which returns the results to the original requester. If the forwarder cannot resolve the query, the server that received the original query attempts to resolve the query on its own.

In an exclusive mode, servers rely completely on the name-resolving ability of the forwarders. Servers using forwarders in an exclusive mode are known as slaves. Slaves can also be caching-only servers. When a slave receives a DNS query that it cannot resolve through its own zone files, it passes the query to one of the designated forwarders. The forwarder then carries out whatever communication is necessary to resolve the query and returns the results to the slave, which returns the results to the original requester. If the forwarder cannot resolve the request, the slave returns a query failure to the original requestor. Slaves make no attempt to resolve the query on their own if the forwarder cannot satisfy the request.


Load Sharing

DNS servers use a mechanism called round robin or load sharing, explained in RFC 1794, to share and distribute loads for network resources. Round robin rotates the order of resource record (RR) data returned in a query answer in which multiple RRs exist of the same RR type for a queried DNS domain name.

For example, suppose you have three World Wide Web servers with the same domain name, WWWServer, that all display the Web page for www.reskit.com, and you want to share the load between them. On the name server, you would create the following resource records:

www.reskit.com.        IN      A        172.16.64.11
www.reskit.com.        IN      A        172.17.64.22
www.reskit.com.        IN      A        172.18.64.33

A name server configured to perform round robin would rotate the order of the IP addresses when answering client requests. In this example, the name server would reply to the first client request by ordering the addresses as 172.16.64.11, 172.17.64.22, and 172.18.64.33. It would reply to the second client response by ordering the addresses as 172.17.64.22, 172.18.64.33, and 172.16.64.11. The rotation process continues until data from all of the same type of resource records associated with a name have been rotated to the top of the list returned in answering client queries. The client is required to try the first IP address listed.

For load sharing to be most effective, you should make the TTL (Time to Live) in the A (Address) resource records short. As a result, the data expires from clients more quickly so clients must query more often, each time receiving a different ordering of IP addresses.

Name servers running Windows 2000 and versions of BIND 4.9.3 and later perform this type of load sharing. Earlier versions of BIND performed a different type of load sharing; for more information, see RFC 1794.


Name Resolution

DNS clients use small program libraries called resolvers that perform DNS queries to servers on behalf of the client. Keep in mind throughout this discussion that a DNS server can also be a client to another server.

Note

Computers running under Microsoft® Windows NT® Workstation or Microsoft® Windows NT® Server version 4.0 automatically use DNS name resolution when a name query contains a name that contains a period or is greater than 15 bytes in length. Computers running Windows 2000 always try DNS name resolution. For more information about DNS and NetBIOS name resolution, see “TCP/IP Implementation Details” in this book.

DNS clients can perform two different kinds of lookups. They can perform forward lookups, in which they send a host name and request the IP address, and they can perform reverse lookups, in which they send an IP address and request the host name.

Regardless of whether the client is requesting an IP address or requesting a host name, DNS clients can make two types of queries: recursive and iterative.


Recursive and Iterative Queries

With a recursive name query, the DNS client requires that the DNS server respond to the client with either the requested name -to-IP address mapping or an error message stating that the data or domain name does not exist. The DNS server can not just refer the DNS client to a different DNS server.

Thus, if a DNS server does not have the requested information when it receives a recursive query, it queries other servers until it gets the information, or until the name query fails.

Recursive name queries are generally made by a DNS client to a DNS server, or by a DNS server that is configured to pass unresolved name queries to another DNS server, as in the case of a DNS server configured to use a forwarder.

An iterative name query is one in which DNS client allows the DNS server to return the best answer it can give based on its cache or zone data. If the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a referral (that is, a pointer to an authoritative DNS server in a lower level of the domain namespace). The DNS client can then query the authoritative DNS server for which it obtained a referral. It continues this process until it locates a DNS server that is authoritative for the queried name, or until an error or time-out condition is met.

This process is sometimes referred to as “walking the tree,” and this type of query is typically initiated by a DNS server that attempts to resolve a recursive name query for a DNS client.

Figure 7.4 shows an example of iterative and recursive queries. This example assumes that none of the servers have the requested information in their caches.

Figure 7.4 Iterative and Recursive Queries

In the example shown in Figure 7.4, a client somewhere on the Internet needs the IP address of noam.reskit.com. The following events take place:

  1. The client contacts NameServer1 with a recursive query for noam.reskit.com. The server must now return either the answer or an error message.
  2. NameServer1 checks its cache and zone files for the answer, but does not find it, so it contacts a server at the root of the Internet (that is, a root DNS server) with an iterative query for noam.reskit.com.
  3. The server at the root of the Internet does not know the answer, so it responds with a referral to an authoritative server in the .com domain.
  4. NameServer1 contacts a server in the .com domain with an iterative query for noam.reskit.com.
  5. The server in the .com domain does not know the exact answer, so it responds with a referral to an authoritative server in the reskit.com domain.
  6. NameServer1 contacts the server in the reskit.com domain with an iterative query for noam.reskit.com.
  7. The server in the reskit.com domain does know the answer. It responds with the correct IP address.
  8. NameServer1 responds to the client query with the IP address for noam.reskit.com.

Note

When a computer running Windows 2000 receives a referral to multiple servers, the computer tries querying each name server once. On subsequent queries, the computer uses whichever name server responds the fastest.


Caching and Time to Live

When a server is processing a recursive query, it might be required to send out several queries to find the definitive answer. The server caches all of the information that it receives during this process for a time that is specified in the returned data. This amount of time is referred to as the Time to Live (TTL) and is specified in seconds. The server administrator of the zone that contains the data decides on the TTL for the data. Smaller TTL values help ensure that information about the domain is more consistent across the network, in the event that this data changes often. However, this also increases the load on the name servers that contain the name, and it also increases Internet traffic.

Once data is cached by a DNS server, the DNS server must start decreasing the TTL from its original value so that it will know when to flush the data from its cache. When the DNS server answers a query with its cached data, it includes the remaining TTL for the data. The resolver can then cache this data, using the TTL sent by the server.


Negative Caching

In addition to caching information about how to locate a particular host or name server, resolvers can also cache negative responses, that is, the information that a specific resource record set (RRset) or domain name does not exist. Negative caching can reduce the response time for negative answers. It can also reduce network traffic by reducing the number of messages that must be sent between resolvers and name servers.

Negative caching is specified in RFCs 1034 and 2308. RFC 1034 describes how to cache negative responses and makes negative caching optional. RFC 2308 requires resolvers to cache negative responses if they cache any responses. It also describes a way for name servers to forward cached negative responses to resolvers.

When name servers forward cached negative responses to a resolver, or when resolvers cache negative responses, they must include the Start of Authority (SOA) field, which indicates whether or not the server is authoritative for the zone. Just as with ordinary caching, they must also start decreasing the TTL.


Resource Records and Zone Files

To resolve names, servers consult their zone files (also called DNS database files or simply db files). The files contain resource records (RRs) that make up the resource information associated with the domain. For example, some resource records contain friendly-name to IP address mappings, and others contain the location of other DNS servers.

Certain resource records not only include information about servers in the domain, but also serve to define the domain by specifying which servers are authoritative for which zones. These resource records, the SOA and NS resource records, are described in more detail later in this section.


Resource Record Format

Many resource records have the following syntax:

Owner    TTL        Class    Type        RDATA

Table 7.2 describes each of these fields.

Table 7.2 Typical Resource Record Fields

Name | Description
Owner | The name of the host or the domain to which this resource record belongs.
Time to Live (TTL) | A 32-bit integer that represents, in seconds, the length of time that a resolver should cache this entry before it is discarded. This field is optional, and if it is not specified, the client uses the TTL in the SOA record.
Class | Defines the protocol family in use. It is almost always IN for the Internet system. The other value defined in RFC 1034 is CH for the Chaos system, which was used experimentally at the Massachusetts Institute of Technology. This field is optional.
Type | Identifies the type of resource represented by this record.
RDATA | The resource data. It is a variable type that represents the information being described by the type. For example, in an address record, this is the 32-bit IP address that represents the host defined by the resource record.

Resource records are represented in binary form in packets when lookups and responses are made using DNS. In the database files, however, resource records are represented as text entries. Most resource records are represented as single-line text entries. If an entry is going to span more than one line, you can use parentheses to encapsulate the information. In many implementations of DNS, only the Start of Authority (SOA) record can be multiple lines. For readability, blank lines and comments are often inserted in the zone files, and are ignored by the DNS server. Comments always start with a semicolon (;) and end with a carriage return.


Resource Record Types

Different types of resource records can be used to provide DNS-based data about computers on a TCP/IP network. This section describes the following resource records:

  • SOA
  • NS
  • A
  • PTR
  • CNAME
  • MX
  • SRV

Next, it lists all of the other resource records specified by RFC standards. Finally, it lists resource records that are specific to the Windows 2000 implementation and one resource record specified by the ATM Forum.

Start of Authority Resource Records

The Start of Authority (SOA) resource record defines the zone for which the server is authoritative. For example, in the DNS configuration specified earlier in Figure 7.2, the server noamdc1 is authoritative for the noam zone and contains the zone file for the domain. The zone file contains an SOA resource record, which indicates that noamdc1 is authoritative for the noam domain. The following example shows the SOA resource record:

noam.reskit.com.  IN  SOA (
                noamdc1.noam.reskit.com.        ; authoritative  server
                                                     for the zone
                administrator.noam.reskit.com.    ; zone admin e-mail
                                                ; (responsible person)
                5099                                ; serial number
                3600                               ; refresh (1 hour)
                600                                 ; retry (10 mins)
                86400                               ; expire (1 day)
                60        )                         ; minimum TTL (1 min)

SOA resource records include the following fields:

  • The Owner, TTL, Class, and Type fields, as described in “Resource Record Format” earlier in this chapter.
  • The Authoritative Server field shows the DNS server authoritative for the zone.
  • The Responsible Person field shows the e-mail address of the administrator responsible for the zone. It uses a period (.) instead of an at symbol (@).
  • The Serial Number field shows how many times the zone has been updated. When a zone’s secondary server contacts the master server for that zone to determine whether it needs to initiate a zone transfer, the zone’s secondary server compares its own serial number with the master server’s serial number. If the master server’s serial number is higher, the secondary server initiates a zone transfer.

Note

Serial numbers are 32-bit unsigned integers ranging from zero to 4,294,967,295. When the value reaches 4,294,967,295, this field wraps around to zero. However, zero is considered higher than 4,294,967,295, because of a special type of arithmetic specified by the DNS standards, called sequence space arithmetic. With sequence space arithmetic, half the numbers in the 32-bit range are considered lower than any given value, and the other half are considered higher. That is, given a serial number x, all the numbers from (x+1) to (x+2,147,483,647) are considered higher than x, and all the numbers from (x+1+2,147,483,647) to (x-1) are considered lower than x.

When the serial number reaches half of its 32-bit range, the secondary server must expire its copy of the zone.

  • The Refresh Number field shows how often the secondary server for the zone checks to see whether the zone has been changed.
  • The Retry Number field shows how long the secondary server for the zone waits for a response from the master server before retrying.
  • The Expire Number field shows how long the secondary server for the zone should continue to check before discarding its own zone file as invalid.
  • The Minimum Time to Live field applies to all the resource records in the zone file whenever a time to live value is not specified in a resource record. Whenever a resolver queries the server, the server sends back resource records along with the minimum time to live.

Name Server Resource Records

The name server (NS) resource record, like the SOA resource record, serves to define the database. The SOA resource record defines the database by indicating the domain for which the server was authoritative. NS resource records, in contrast, indicate other servers that contain information about the zone. They indicate secondary servers for the zone specified in the SOA resource record, and they indicate the primary servers for any delegated zones.

For example, when the administrator on reskit.com delegated authority for the noam subdomain to noamdc1, the following line was added to the zone files for reskit.com on the noam DNS server (noamdc1):

noam.reskit.com.     IN     NS        noamdc1.reskit.com.

Address Resource Records

The address (A) resource record maps a host name to an IP address, so the resolvers can request the corresponding IP address for a host name. For example, the following A resource record, located in the zone files for the noam subdomain, maps the host name of the server to its IP address:

noamdc1         IN        A        172.16.48.1

Pointer Records

The pointer (PTR) resource record, in contrast to the A resource record, maps an IP address to a host name. For example, the following PTR resource record, located in the zone files in the in-addr.arpa domain, maps the IP address of noamdc1 to its host name:

1.48.16.172.in-addr.arpa.        IN        PTR        noamdc1.reskit.com.

Canonical Name Resource Records

The canonical name (CNAME) resource record creates an alias (synonymous name) for the specified host name. You can use CNAME records to hide the implementation details of your network from the clients that connect to it. For example, suppose you want to put an ftp server named ftp1 on your noam subdomain, but you know that in six months you will move it to a computer named ftp2, and you do not want your users to have to know about the change. You could just create an alias called ftp that points to ftp1, and then when you move your computer, you need only change the CNAME record. For example, the following CNAME resource record creates an alias for ftp1:

ftp        IN        CNAME        ftp1.noam.reskit.com.

Once the CNAME record is located, the DNS server attempts to resolve the name using an A record.

Mail Exchange Resource Records

The mail exchange (MX) resource record specifies a mail exchange server for a DNS domain name. A mail exchange server is a host that will either process or forward mail for the DNS domain name. Processing the mail means either delivering it to the addressee or passing it to a different type of mail transport. Forwarding the mail means sending it to its final destination server, sending it using Simple Message Transfer Protocol (SMTP) to another mail exchange server that is closer to the final destination, or queuing it for a specified amount of time.

If you want to use multiple mail exchange servers in one domain, you can have multiple MX records for that domain. The following example shows MX resource records for the mail servers in the noam subdomain:

noam.reskit.com.    IN        MX        0    mailserver1.noam.reskit.com.
noam.reskit.com.    IN        MX        10    mailserver2.noam.reskit.com.
noam.reskit.com.    IN        MX        10    mailserver3.noam.reskit.com.

The fourth field in this resource record is the mail server priority, or preference value. The preference value specifies the preference given to the MX record among MX records at the same value. Lower records are preferred. Thus, when a mailer needs to send mail to a certain domain, it first contacts a DNS server for that domain and retrieves all the MX records. It then contacts the mailer with the lowest preference value.

For example, suppose Jane Doe sends an e-mail message to JohnDoe@noam.reskit.com on a day that mailserver1 is down, but mailserver2 is working. Her mailer tries to deliver the message to mailserver1, because it has the lowest preference value, but it fails because mailserver1 is down. This time, Jane’s mailer can choose either mailserver2 or mailserver3, because their preference values are equal. It successfully delivers the message to mailserver2.

To prevent mail loops, if the mailer is on a host that is listed as an MX for the destination host, the mailer can deliver only to an MX with a lower preference value than its own host.

Note

Only mail exchange servers use MX records.

Service Resource Records

With MX records, you can have multiple mail servers in a domain, and when a mailer needs to send mail to a host in the domain, it can find the location of a mail exchange server. But what about other applications, such as the World Wide Web or telnet?

Service (SRV) resource records, described in RFC 2052, enable you to specify the location of the servers for a specific service, protocol, and domain. Thus, if you have two Web servers in your domain, you can create SRV resource records specifying which hosts serve as Web servers, and resolvers can then retrieve all the SRV resource records for the Web servers.

SRV resource records do not use the syntax described earlier. The format of an SRV record is as follows:

Service.Proto.NameTTLClassSRVPriorityWeightPortTarget

  • The Service field specifies the name of the service, such as http or telnet. Some services are defined in the standards, and others can be defined locally.
  • The Proto field specifies the protocol, such as TCP or UDP.
  • The Name field specifies the domain name the resource record refers to.
  • The TTL and Class fields are the same as the fields defined earlier in this chapter.
  • The Priority field specifies the priority of the host. Clients attempt to contact the host with the lowest priority.
  • The Weight field is a load balancing mechanism. When the priority field is the same for two records in the same domain, clients should try records with higher weights more often.
  • The Port field shows the port of the service on this host.
  • The Target field shows the fully qualified domain name for the host.

The following example shows SRV records for Web servers:

http.tcp.reskit.com. SRV 0     0     80         webserver1.noam.reskit.com.
http.tcp.reskit.com. SRV 10 0     80        webserver2.noam.reskit.com.

Note

This example does not specify a TTL and Class. Therefore, the resolver uses the minimum TTL specified in the SOA resource record and the IN Class.

If a computer needs to locate a Web server in the reskit.com domain, the resolver sends the following query:

http.tcp.www.reskit.com

The DNS server replies with the SRV records listed above. The resolver then chooses between WebServer1 and WebServer2 by looking at their priority values. Because WebServer1 has the lowest priority value, it chooses WebServer1.

Note

If the priority values had been the same, but the weight values had been different, the client would have chosen a Web server randomly, except that the server with the highest weight value would have had a higher probability of being chosen.

Next, the resolver requests the A record for webserver1, and the DNS server sends the A record. Finally, the client attempts to contact the Web server.

Less Common Resource Records

Table 7.3 shows some other resource records and the RFCs that define them. Many of these resource records are considered experimental.

Table 7.3 Less Common Resource Record Types

Record Type | RFC | Description
AAAA | 1886 | Special address record that maps a host (computer or other network device) name to an IPv6 address.
AFSDB | 1183 | Gives the location of either an Andrew File System (AFS) cell database server, or a Distributed Computing Environment (DCE) cell's authenticated server. The AFS system uses DNS to map a DNS domain name to the name of an AFS cell database server. The Open Software Foundation's DCE Naming Service uses DNS for a similar function.
HINFO | 1034 | The host information resource record identifies a host's hardware type and operating system. The CPU Type and Operating System identifiers should come from the computer names and system names listed in RFC 1700.
ISDN | 1183 | The Integrated Services Digital Network (ISDN) resource record is a variation of the A (address) resource record. Rather than mapping a host name to an IP address, the ISDN record maps the name to an ISDN address. An ISDN address is a phone number that consists of a country code, an area code or country code, a local phone number, and optionally, a subaddress. The ISDN resource record is designed to be used in conjunction with the route through (RT) resource record.
MB | 1035 | The mailbox (MB) resource record is an experimental record that specifies a DNS host with the specified mailbox. Other related experimental records are the mail group (MG) resource record, the mailbox rename (MR) resource record, and the mailbox information (MINFO) resource record.
MG | 1035 | The mail group (MG) resource record is an experimental record that specifies a mailbox that is a member of the mail group (mailing list) specified by the DNS domain name. Other related experimental records are the MB resource record, the MR resource record, and the MINFO resource record.
MINFO | 1035 | The MINFO resource record is an experimental record that specifies a mailbox that is responsible for the specified mailing list or mailbox. Other related experimental records are the MB resource record, the MG resource record, and the MR resource record.
MR | 1035 | The MR resource record is an experimental record that specifies a mailbox that is the proper rename of another specified mailbox. Other related experimental records are the MB resource record, the MG resource record, and the MINFO resource record.
RP | 1183 | Identifies the responsible person (RP) for the specified DNS domain or host.
RT | 1183 | The route through (RT) resource record specifies an intermediate host that routes packets to a destination host. The RT record is used in conjunction with the ISDN and X25 resource records. It is syntactically and semantically similar to the MX record type and is used in much the same way.
TXT | 1035 | The text resource (TXT) record associates general textual information with an item in the DNS database. A typical use is for identifying a host's location (for example, Location: Building 26S, Room 2499). A single TXT record can contain multiple strings, up to 64 KB.
WKS | 1035 | The well-known service (WKS) resource record describes the services provided by a particular protocol on a particular interface. The protocol is usually UDP or TCP, but can be any of the entries listed in the PROTOCOLS file (\%systemroot%\system32\drivers\etc\protocol). The services are the services below port number 256 from the SERVICES file (\%systemroot%\system32\drivers\etc\services).
X.25 | 1183 | The X.25 resource record is a variation of the A (address) resource record. Rather than mapping a host name to an IP address, the X.25 record maps the name to an X.121 address. X.121 is the International Standards Organization (ISO) standard that specifies the format of addresses used in X.25 networks. The X.25 resource record is designed to be used in conjunction with the route through (RT) resource record.

Resource Records Not Defined in RFCs

In addition to the resource record types listed in the RFCs, Windows 2000 uses the following resource record types, shown in Table 7.4.

Table 7.4 Resource Record Types Not Defined in the RFCs

Name | Description
WINS | The Windows 2000 DNS server can use a WINS server for looking up the host portion of a DNS name, and therefore, may be attached only to a zone root.
WINS reverse lookup (WINS-R) | This entry is used in a reverse lookup file for the DNS server to use a WINS server for finding the host portion of the DNS name given its IP address using a NetBIOS adapter status query.
ATMA | The ATMA resource record, defined by the ATF Forum, is used to map domain names to ATM addresses. For more information, download the ATM Name System Specification Version 1.0, from ftp://ftp.atmforum.com/pub/approved-specs/af-saa-0069.000.doc.


Zone Files

The DNS standards do not specify the internal data structure that stores resource records, and various implementations differ. Generally, servers use zone files stored on that server in plain text, but it is not required. With Windows 2000, you can integrate your DNS database with the Active Directory database, in which case the zone files are stored in the Active Directory database.

One common implementation of DNS, the UNIX Berkeley Internet Domain (BIND) implementation, generally uses the following file names and is shown in Table 7.5.

Table 7.5 Zone File Names Used in BIND

Name | Description
db.domain | Maps host names to IP addresses. For example, if your domain is reskit.com, then this file will be called db.reskit.com.
db.addr | Maps IP addresses to host names. For example, if your network is the class C network address 172.16.32.0, then this file will be called db.172.16.32.
db.cache | Also known as the root hints file, this file contains the names and IP addresses for the name servers that maintain the root domain. This file is essentially the same on all servers that use Internet root DNS servers, but must be modified for servers that use private root DNS servers. (A root DNS server is a DNS server that is authoritative for the root of the namespace.)
db.127.0.0 | Used to resolve queries to the loopback address. It is essentially the same on all name servers and must be present.

The names of the database files are arbitrary and are specified in the configuration of the DNS server. By default, the Microsoft Windows 2000 DNS server does not use the same file names as a typical UNIX BIND DNS server. However, if you are porting DNS db files from another DNS server, you can configure the Microsoft Windows 2000 DNS server to use the BIND file names

The following sections explain the contents of the zone files and describe one additional file, the BOOT file, which is used by UNIX BIND servers, though not specified in the DNS standards.

Forward Lookup File

Forward lookup files contain information needed to resolve names within the domain. They must include SOA and NS records and can include any type of resource record.

Reverse Lookup File

Reverse lookup files contain information needed to perform reverse lookups. They include SOA, NS, and PTR records.

With most queries, the client supplies a name and requests the IP address that corresponds to that name. This type of query is typically described as a forward lookup.

But what if a client already has a computer’s IP address and wants to determine the DNS name for the computer? This is important for programs that implement security based on the connecting host name, and is also used for TCP/IP network troubleshooting. The DNS standard provides for this possibility through reverse lookups.

Because DNS was not primarily designed to provide this type of query, there is no direct correlation in the DNS namespace between how domain names and IP addresses are assigned. If the only means to answer a reverse lookup were to conduct a thorough search of all domains in the DNS namespace, the reverse query search would be too exhaustive to perform in any practical way.

To solve this problem, a special domain called in-addr.arpa was created. This domain uses a reverse in which subdomains are formed using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses. With this arrangement, administration of lower limbs of the in-addr.arpa domain can be delegated to organizations as they are assigned their class A, B, or C IP network IDs.

Figure 7.5 shows a branch of the in-addr.arpa namespace.

Figure 7.5 In-addr.arpa Namespace

The in-addr.arpa domain tree requires PTR resource records to store and provide reverse mappings for IP addresses of their corresponding host names.

If a client queries a DNS server for the host name associated with the IP address 172.16.44.1, the name resolution process follows these steps:

  1. The client queries the zone’s primary DNS server for a PTR record using a name query for the host named 1.44.16.172.in-addr.arpa.
  2. If the primary DNS server for the zone cannot answer the query, the primary DNS server for the zone can use iterative queries to find the name server that can answer the query.
  3. If the primary DNS server for the zone finds the correct name server, it queries that name server for the appropriate PTR record.
  4. The primary DNS server responds to the client with the appropriate PTR record.

Inverse Queries

In addition to reverse lookups, some DNS servers support what is known as an inverse query. Just as with a reverse lookup, a client making an inverse query provides the IP address and requests the host name. However, the server does not use the in-addr.arpa domain to find the answer, and it does not query any other servers. Instead, it simply checks its own zone files for the answer, and if it does not find the answer, it returns an error message. There is no way for either the server or the client to know whether the IP address is simply missing from that server’s zone files, or whether it does not exist.

Because support for inverse queries is optional and because servers often cannot provide a definitive answer, inverse queries are of limited use. Only certain applications use inverse queries, such as earlier versions of nslookup.

For compatibility with older versions of BIND, Windows 2000 supports inverse queries.

For more information about inverse queries, see RFC 1035.


Root Hints Files

The root hints file, also called the cache hints file, contains host information that is needed to resolve names outside of the authoritative domains. It contains the names and addresses of root DNS servers.

Note

The root hints file does not include information needed to resolve names within authoritative domains, as described in “Caching and Time to Live” earlier in this chapter.

If your network is connected to the Internet, the root hints file should contain records for the root DNS servers on the Internet. By default, a root hints file with current Internet root DNS mappings is automatically installed as the Cache.dns file in the \%Systemroot%\System32\Dns directory.

If your network is not connected to the Internet, you would replace the NS records in the cache file with NS records for the DNS servers that are authoritative for the root of your private TCP/IP network.

For example, suppose you have set up the reskit.com domain with two internal root DNS servers (InternalRoot1 and InternalRoot2), configured with information about how to reach the name servers in the reskit.com domain. You then create a root hints file for other name servers in your network, pointing to the internal root DNS servers. That way, if they receive a query they cannot resolve, they can simply query the internal roots file.

The following reskit root hints file provides name-to-IP address mappings for name servers in the reskit.com domain.

; Internal root hints file for reskit.com, which is not connected to
; the Internet
.    86400        IN        NS        InternalRoot1.reskit.com.
.    86400        IN        NS        InternalRoot2.reskit.com.

InternalRoot1.reskit.com.    86400    IN    NS        172.16.64.1
InternalRoot2.reskit.com.    86400    IN    NS        172.16.64.2

You can also use a hints file that points to non-root domains, such as .com, .gov, or .net.

Note

The Windows 2000 DNS server makes a best effort to determine whether the network is connected to the Internet and, if not, creates its own cache file.


Boot Files

Although the boot file is not actually defined in the RFCs and is not needed for a server to be RFC compliant, it is described here for completeness. This file is part of the BIND-specific implementation of DNS.

It is not used by default in the Microsoft implementation of DNS. If advantageous, you can port an existing BIND boot file to a Microsoft DNS server. The Windows 2000 DNS server supports only a subset of the BIND boot file directives.

The BIND Boot file controls the startup behavior of the DNS server. Commands must start at the beginning of a line and no spaces can precede commands. Recognized commands include directory, cache, primary, and secondary. Table 7.6 shows descriptions of boot file commands supported by Windows 2000.

Table 7.6 Descriptions of Boot File Commands

Command | Description
Directory command | Specifies a directory where other files referred to in the boot file can be found.
Cache command | Specifies a file used to help the DNS server contact name servers for the root domain. This command and the file it refers to must be present.
Primary command | Specifies a domain for which this name server is authoritative and a zone file that contains the resource records for that domain. Multiple primary command records can exist in the boot file.
Secondary command | Specifies a domain for which this name server is authoritative and a list of master server IP addresses from which to attempt downloading the zone information. It also defines the name of the local file for caching this zone. Multiple secondary command records can exist in the boot file.

Table 7.7 shows the syntax of boot file commands supported by Windows 2000.

Table 7.7 Syntax of Boot File Commands Supported by Windows 2000

Syntax | Example
directory <directory> | directory c:\winnts\system32\dns
cache <filename> | cache cache
primary <domain> <filename> | primary reskit.com example.dns primary dev.reskit.com dev.dns
secondary <domain> <hostlist> <local filename> | secondary test.reskit.com 157.55.200.100 test.dns
forwarders <hostlist> | forwarders 172.16.64.4 172.16.64.8
slave (follows the forwarders parameter) | forwarders 172.16.64.4 172.16.64.8 slave

For more information about the BIND boot file, see Knowledge Base article Q194513, “The Structure of a Domain Name System Boot File.”


Zone Transfer

When changes are made to the zone file on a master server, these changes must be replicated to all the secondary servers for that zone, using a mechanism called zone transfer. In the original DNS specifications, only one form of zone transfer was available, known as full zone transfer. New RFCs have defined two additional types of zone transfer: incremental zone transfer and DNS Notify. This section describes all three types.


Full Zone Transfer

In a full zone transfer, defined in the original DNS specifications, the master server for a zone transmits the entire zone database to the secondary server for that zone. Secondary servers initiate full zone transfers using the following process:

  1. The secondary server for the zone waits a certain amount of time (specified in the Refresh field of the SOA resource record), and then polls the master server for its SOA.
  2. The master server for the zone responds with the SOA resource record.
  3. The secondary server for the zone compares the returned serial number to its own serial number. If the serial number sent by the master server for the zone is higher than its own serial number, that means its zone database is out of date, and it uses an AXFR request (a request for a full zone transfer) to request a zone transfer.
  4. The master server for the zone sends the full zone database to the secondary server.

If the master server for the zone does not respond to the secondary server’s poll (step 1), the secondary server retries after the interval specified in the Retry field of the SOA resource record. If there is still no answer after the interval specified in the Expire field, it discards its zone file and is no longer authoritative for the zone.

Note

Name servers running versions of BIND earlier than 4.9.4 can send and receive only one resource record per message during a full zone transfer. Name servers running versions of BIND 4.9.4 and later, and Windows 2000, can send and receive multiple resource records per message. This improves the performance of full zone transfers.

However, to provide backward compatibility, name servers running Windows 2000 default to sending only one resource record per message if any non-Windows secondary servers are configured for the zone. If you have secondary name servers running versions of BIND 4.9.4 and later, configuring your Windows 2000 to send multiple resource records per message improves performance. For more information, see Knowledge Base article Q151416, “Microsoft DNS Compatibility w/BIND Versions Earlier Than 4.9.4.”


Incremental Transfer

Full zone transfers can consume a great deal of network bandwidth, especially for complex DNS configurations. To solve this problem, RFC 1995 specifies an additional standard, incremental zone transfer. With incremental zone transfer, only part of the zone must be transferred.

Incremental zone transfer works much the same as full zone transfer. The secondary server for the zone still uses the SOA resource record to determine when to poll the master server for the zone, when to retry, and so on. However, if it needs to perform a zone transfer, it sends an incremental zone transfer (IXFR) query instead of an AXFR query, requesting that the master server for the zone perform an incremental zone transfer.

The master server for the zone, meanwhile, maintains a recent version history of the zone file, which observes any record changes that occurred in the most recent version updates of the zone file. Then, if the master server for the zone has a newer version of the file, it can forward only those record changes that have occurred between the two different versions of the zone file to the secondary server for the zone. The master server sends the oldest updates first and the newest updates last.

When the secondary server receives an incremental zone transfer, it creates a new version of the zone file and begins replacing its resource records with the updated resource records, starting with the oldest updates and ending with the newest updates. When all of the updates have been made, the secondary server replaces its old version of the zone file with the new version of the zone file.

The master server for the zone is not required to perform an incremental transfer. It can perform a full zone transfer if it does not support incremental zone transfer, if it does not have all the necessary data for performing an incremental zone transfer, or if an incremental zone transfer takes more bandwidth than a full zone transfer.

Even though incremental zone transfer saves network bandwidth, it uses space on the server to record the version history. To conserve space, servers can purge the version history.


DNS Notify

DNS Notify is a revision to the DNS standard (RFC 1996) that proposes that the master server for a zone notify certain secondary servers in that zone of changes, and the secondary servers can then check to see whether they need to initiate a zone transfer. This process can help improve consistency of zone data among secondary servers.

To determine which secondary servers in a zone to send the changes to, the master server for the zone contains a notify set, which is a list of the IP addresses for those secondary servers. The master server for the zone notifies only listed servers when zone updates occur. The notify set can also be used to restrict access to servers that attempt to “pull” or request zone updates.

When the local zone file on a master server for the zone is updated, the following events take place:

  1. The Serial Number field in the SOA record is updated to indicate that a new version of the zone file has been written to a disk.
  2. The master server then sends a notify message to other servers that are part of its notify set.
  3. All secondary servers for the zone that receive the notify message respond by initiating an SOA-type query back to the notifying master server to determine if the notifying server’s zone file is a later version than the currently stored copy of the zone file.
  4. If a notified server determines that the serial number used in the SOA record of the notifying server’s zone file is higher (more recent) than the serial number used in the SOA record for its current zone copy, the notified server requests an AXFR or IXFR zone transfer.

Note

Windows 2000 uses the Notify set to provide security. Name servers send zone transfers only to servers listed in their Notify sets. For more information, see Knowledge Base Article 193837, “Microsoft® Windows NT® 4.0 DNS server Default Zone Security Settings.”


Dynamic Update

Dynamic update is a new standard, specified in RFC 2136, that provides a means of dynamically updating zone data on a zone’s primary server when a server requests an update.

Originally, DNS was designed to support only static changes to a zone database. Because of the design limitations of static DNS, the ability to add, remove, or modify resource records could only be performed manually by a DNS system administrator.

For example, a DNS system administrator would edit records on a zone’s primary server and the revised zone database would then be propagated to clients during zone transfer. This design is workable when the number of changes is small and updates occur infrequently, but can otherwise become unmanageable.

With dynamic update, on the other hand, the primary server for the zone can also be configured to support updates that are initiated by another server that supports dynamic update. For example, it could accept updates from secondary servers for the zone or DHCP servers. Updates are sent using a standard UPDATE message format and can include the addition or deletion of individual resource records (RRs) or sets of resource records (RRsets).

In order for a request for a dynamic update to be performed, several prerequisite conditions can also be identified. Where prerequisites are set, all such conditions must be met before an update is allowed. Some examples of prerequisites that can be set are:

  • A required RR or RRset already exists or is in use prior to an update.
  • A required RR or RRset does not exist or is not in use prior to an update.
  • A requesting server is permitted to initiate an update of a specified RR or RRset.

Each prerequisite must be satisfied in order for an update to occur. After all prerequisites are met, the zone’s primary server can then proceed with an update of its local zone files. Multiple updates can be processed concurrently only if one update does not depend on the final result of another update.


DNS Standards

Although the core DNS standards (as set forth in RFCs 1034 and 1035) have been well-established since their acceptance as standards in 1987, numerous revisions to DNS have been made in the intervening years. These revisions have been brought about by additional RFCs and Internet drafts, which are independently authored and submitted to the IETF for further circulation and review before being accepted as standards throughout the Internet.

Table 7.8 lists the accepted and proposed RFC standards that Windows 2000 supports. You can find them all at http://www.ietf.org.

Table 7.8 DNS-related RFC Standards Supported by Windows 2000

Number | Status | Title
1034 | Standard | Domain Names - Concepts and Facilities
1035 | Standard | Domain Names - Implementation and Specification
1101 | Unknown | DNS Encoding of Network Names and Other Types
1464 | Experimental | Using the Domain Name System to Store Arbitrary String Attributes
1536 | Informational | Common DNS Implementation Errors and Suggested Fixes
1591 | Informational | Domain Name System Structure and Delegation
1664 | Experimental | Using the Internet DNS to Distribute Mail Address Mapping Tables
1706 | Informational | DNS NSAP Resource Records
1712 | Experimental | DNS Encoding of Geographical Location
1794 | Informational | DNS Support for Load Balancing
1886 | Proposed | DNS Extensions to Support IP Version 6
1912 | Informational | Common DNS Operational and Configuration Errors
1995 | Proposed | Incremental Zone Transfer in DNS
1996 | Proposed | A Mechanism for Prompt DNS Notification of Zone Changes
2052 | Experimental | A DNS RR for Specifying the Location of Services (DNS SRV)
2136 | Proposed | Dynamic Updates in the Domain Name System (DNS UPDATE)
2308 | Standards Track | Negative Caching of DNS Queries (DNS NCACHE)


Internet Protocol Security

Internet Protocol Security (IPSec) is a framework of open standards for ensuring secure private communications over Internet Protocol (IP) networks through the use of cryptographic security services. The Microsoft® Windows® 2000 implementation of IPSec is based on standards developed by the Internet Engineering Task Force (IETF) IPSec working group.

In This Chapter

Security Issues with IP

Introducing IPSec

Services

IPSec Protocol Types

IPSec Components

Tunneling

IPSec Policy Structure

Security Planning Best Practices

Predefined Configurations

Common IPSec Planning Scenarios

Troubleshooting

The IPSec Monitoring Tool

Event Viewer and the Security Audit Log

Network Monitor

Related Chapters in the Resource Kit

  • For general information about the Internet Protocol (IP), see the Microsoft® Windows® 2000 Internetworking Guide.
  • For additional information about VPN concepts, see “Virtual Private Networking” in the Microsoft® Windows® 2000 Internetworking Guide.
  • For general security information, see the chapters under “Distributed Security” in the Microsoft® Windows® 2000 Distributed Systems Guide.


Security Issues with IP

Without security, both public and private networks are susceptible to unauthorized monitoring and access. Internal attacks might be a result of minimal or nonexistent intranet security; risks from outside the private network stem from connections to the Internet and extranets. Password-based user access controls alone do not protect data transmitted across a network.


Common Types of Network Attacks

Without security measures and controls in place, your data might be subjected to an attack. Some attacks are passive, meaning information is simply monitored; others are active, which means that the information is altered with the intent to corrupt or destroy your data or the network itself. Your networks and data are vulnerable to any of the following types of attacks if you have no layered security plan in place.

Eavesdropping

In general, the majority of network communications occurs in an unsecured or “clear-text” format, which allows an attacker who has gained access to data path(s) in your network to “listen in” or interpret (read) the traffic. When an attacker is eavesdropping on your communications, it is referred to as sniffing or snooping. The ability of an eavesdropper to monitor the network is generally the biggest security problem that administrators face in an enterprise. Without strong encryption services that are based on cryptography, your data can be read by others as it traverses the network.

Data Modification

After an attacker has read your data, the next logical step is to alter it. Even if you do not require confidentiality for all communications, you do not want any of your messages to be modified in transit. For example, if you are exchanging purchase requisitions, you do not want the items, amounts, or billing information to be modified. An attacker can modify the data in the packet easily without the knowledge of the sender or receiver.

Identity Spoofing (IP Address Spoofing)

Most networks and operating systems use the IP address of a computer to identify a valid entity. The IP address is a unique number and can be automatically assigned if your network has the Dynamic Host Configuration Protocol (DHCP) service enabled. The downside of this convenience is the ease with which an IP address is falsely assumed, which is known as identity spoofing. An attacker might also use special programs to construct IP packets that appear to originate from valid addresses inside the corporate intranet, rather than from the address of the attacker’s computer.

After gaining access to the network with a valid IP address, the attacker can modify, reroute, or delete your data. The attacker can also conduct other types of attacks, as described in the following sections.

Valid intranet users also have the ability to use IP spoofing, which allows them access to network resources to which they do not have user rights.

Password-Based Attacks

A common denominator of most operating system and network security plans is password-based access control. This means your access rights to a computer and network resources are determined by who you are, that is, your user name and your password.

Older applications do not always protect identity information as it is passed through the network for validation. This might allow an eavesdropper to gain this information and perform a password-based attack to gain access to the network by posing as a valid user.

When an attacker finds a valid user account, the attacker has the same rights as the real user. Therefore, if the user has administrator-level rights, the attacker also can create accounts for subsequent access at a later time.

After gaining access to your network with a valid account, an attacker can do any of the following:

  • Obtain lists of valid user and computer names and network information.
  • Modify server and network configurations, including access controls and routing tables.
  • Modify, reroute, or delete your data.

Valid intranet users also have the ability to use a password-based attack to gain access to network resources to which they do not have user rights.

Denial-of-Service Attack

Unlike password-based attack, the denial-of-service prevents normal use of your computer or network by valid users.

After gaining access to your network, the attacker can do any of the following:

  • Randomize the attention of your internal Information Systems staff so that they do not see the intrusion immediately, which allows the attacker to make more attacks during the diversion.
  • Send invalid data to applications or network services, which causes abnormal termination or behavior of the applications or services.
  • Flood a computer or the entire network with traffic until a shutdown occurs because of the overload.
  • Block traffic, which results in a loss of access to network resources by internal users.

Man-in-the-Middle Attack

As the name indicates, a man-in-the-middle attack occurs when someone between you and the person with whom you are communicating is actively monitoring, capturing, and controlling your data transparently. For example, the attacker can re-route a data exchange; when computers are communicating at low levels of the network layer, the computers might not be able to determine with whom they are exchanging data.

Man-in-the-middle attacks are like someone assuming your identity in order to read your message. The person on the other end might believe it is you because the attacker might be actively replying as you to keep the exchange going and gain more information. This attack is capable of the same damage as an application-layer attack, described later in this section.

Known-Key Attack

A key is a secret code or number necessary to interpret secured information. Although obtaining a key is a difficult and resource-intensive process for an attacker, it is possible to do. After an attacker obtains a key, that key is referred to as a compromised key, and the attacker can perform a known-key attack.

An attacker uses the compromised key to gain access to a secured communication without the sender or receiver being aware of the attack. With the compromised key, the attacker can decrypt or modify data, and also try to use the compromised key to compute additional keys, which might allow the attacker continued access to secured communications.

Sniffer Attack

A sniffer is an application or device that can read, monitor, and capture network data exchanges and read network packets. If the packets are not encrypted, a sniffer provides a full view of the data inside the packet. Even encapsulated (tunneled) packets can be broken open and read unless they are encrypted and the attacker does not have access to the key.

Using a sniffer, an attacker can do any of the following:

  • Analyze your network and gain information to eventually cause your network to crash or to become corrupted.
  • Read your communications.

Application-Layer Attack

An application-layer attack targets application servers by deliberately causing a fault in a server’s operating system or application(s). This results in the attacker gaining the ability to bypass normal access controls. The attacker takes advantage of this situation, gaining control of your application, system, or network, and can do any of the following:

  • Read, add, delete, or modify your data or operating system.
  • Introduce a virus program that uses your computers and software applications to copy viruses throughout your network.
  • Introduce a sniffer program to analyze your network and gain information that can eventually be used to crash or to corrupt your systems and network.
  • Abnormally terminate your data applications or operating systems.
  • Disable other security controls to enable future attacks.


Introducing IPSec

IPSec is the long-term direction for secure networking. It provides a key line of defense against private network and Internet attacks, balancing ease of use with security.

IPSec has two goals:

  • To protect IP packets.
  • To provide a defense against network attacks.

Both goals are met through the use of cryptography-based protection services, security protocols, and dynamic key management. This foundation provides both the strength and flexibility to protect communications between private network computers, domains, sites, remote sites, extranets, and dial-up clients. It can even be used to block receipt or transmission of specific traffic types.

IPSec is based on an end-to-end security model, meaning that the only computers that must know about IPSec are the sending and receiving computers. Each handles security at its respective end, with the assumption that the medium over which the communication takes place is not secure. Any computers that only route the data from source to destination are not required to support IPSec. This model allows IPSec to be successfully deployed for your existing enterprise scenarios:

  • Local area network (LAN): client/server, peer to peer.
  • Wide area network (WAN): router to router.
  • Remote access: dial-up clients; Internet access from private networks.

The Windows 2000 implementation of IPSec is based on industry standards currently in development by the Internet Engineering Task Force (IETF) IPSec working group.


In-Depth Defense

Data must be protected from interception, modification, or access by unauthorized parties. Network attacks can result in system downtime and public exposure of sensitive information.

Network protection strategies generally focus only on preventing attacks from outside the private network by using firewalls, secure routers (security gateways), and user authentication of dial-up access. This is referred to as perimeter security, and it does not protect against attacks from within the network.

User access control security methods (smart cards; Kerberos v5 authentication), are not adequate to protect against most network-level attacks, because they rely solely on user names and passwords. Many computers are shared by multiple users. As a result, the computer is often left in a logged-on state, making it unsecured. If a user name and password have been hijacked, user access control security cannot stop the attacker’s access to network resources.

Physical-level protection strategies, which are not commonly used, protect the actual network wires from being accessed and the network access points from being used. However, this rarely guarantees protection of the entire path the data must travel through the network from source to destination.

The best level of protection is provided with IPSec’s end-to-end model: the sending computer secures the data prior to transmission (before it ever reaches the network wires), and the receiving computer unsecures the data only after it has been received. For this reason, IPSec should be one of the components in your layered enterprise security plan. It protects your private data in a public environment by providing a strong, cryptography-based defense against attacks. All network traffic is secured packet by packet rather than just for a whole communication (that is, a flow of packets). Used in combination with strong user access control, perimeter, and physical level security, IPSec ensures an in-depth defense for your data.


Aggressive Protection Against Attacks

IPSec cannot prevent sniffing—that can only begin to be achieved by physical layer security. However, IPSec protects the data so that an attacker finds it extremely difficult or impossible to interpret. The level of protection provided is determined by the strength of the security levels specified in your IPSec policy structure.

IPSec has a number of features that significantly reduce or prevent the attacks discussed previously:

  • Sniffers, Lack of Privacy

    IPSec’s Encapsulating Security Payload (ESP) protocol provides data privacy by encrypting the IP packets.

  • Data Modification

    IPSec uses cryptography-based keys, shared only by the sending and receiving computers, to create a digital checksum for each IP packet. Any modifications to the packet alter the checksum, which indicates to the receiving computer that the packet was modified in transit.

  • Identity Spoofing, Password-based, Application-layer, and Denial-of-Service

    IPSec allows the exchange and verification of identities without exposing that information to interpretation by an attacker. Mutual verification (authentication) is used to establish trust between the communicating systems; only trusted systems can communicate with each other.

  • Man-in-the-Middle

    IPSec combines mutual authentication with shared, cryptography-based keys. Different base prime numbers for the key (key material) are used for each segment of the overall protection scheme, and new key material can be generated as often as your IPSec policy dictates.

  • Denial-of-Service

    IPSec uses IP packet filtering methodology as the basis for determining whether communication is allowed, secured, or blocked, according to the IP address ranges, protocols, or even specific protocol ports.

Layer 3 Protection

Usually the level of protection that IPSec provides requires high overhead. IPSec’s strategic implementation at the IP transport level (network Layer 3) enables a high level of protection with little overhead: deploying IPSec requires no changes to existing applications or operating systems.

The implementation of security at Layer 3 provides protection for all IP and upper layer protocols in the TCP/IP protocol suite, such as TCP, UDP, ICMP, Raw (protocol 255), and even custom protocols that send traffic at the IP layer. (See the “Introduction to TCP/IP” chapter in this book for more information about the network layer model.) The primary benefit of securing information at a lower layer is that all applications and services using IP for transport of data can be protected with IPSec without any modification to those applications or services.

Other security mechanisms that operate above Layer 3, such as Secure Sockets Layer (SSL), only provide security to applications that know how to use SSL (such as Web browsers). To protect communications for all your applications on your computer with SSL requires modifications to each application. Security mechanisms that operate below layer 3, such as link layer encryption, are only protecting the link, not necessarily all links along the data path. This makes link layer encryption unsuitable for end-to-end data protection on Internet or routed intranet scenarios.

Policy-Based Security

Although stronger security methods based on cryptography have become necessary to fully protect communication, a high level of security often greatly increases administrative overhead. IPSec avoids this with its use of policy-based administration.

IPSec policies, rather than applications or operations systems, are used to configure IPSec security services. The policies provide variable levels of protection for most traffic types in most existing networks.

Your network security administrator can configure IPSec policies to meet the security requirements of a user, group, application, domain, site, or global enterprise. Windows 2000 provides an administrative interface, called IPSec Policy Management, to create and manage IPSec policies centrally at the Active Directory level for domain members, or locally on a non-domain computer.

Simplified Deployment

Deploying IPSec on your network provides a high level of security for all network communications without detrimental effects to users, applications, or administrative overhead.

To achieve secure communications with a low cost of ownership, Windows 2000 simplifies the deployment of IPSec with the following:

  • Integration with the Windows 2000 Security Framework

    IPSec uses the Windows 2000 secure domain as a trust model. By default, IPSec policies use the Windows 2000 default authentication method (Kerberos v5 authentication) to identify and trust communicating computers. Computers that are members of a Windows 2000 domain or trusted domain can easily establish IPSec secured communications.

  • Centralized IPSec Policy Administration at the Active Directory Level

    IPSec policies can be assigned through the Group Policy features of Active Directory. This allows the IPSec policy to be assigned at the domain or organizational unit level, which eliminates the administrative overhead of configuring each computer individually.

  • Transparency of IPSec to Users and Applications

    Tight integration at the IP layer (Layer 3) provides security for any protocol in the TCP/IP suite. You do not need separate security packages for each protocol in the TCP/IP suite, because applications using TCP/IP pass the data to the IP protocol layer, where it is secured.

  • Flexible Security Configuration

    The security services within each policy can be customized to meet the majority of security requirements for the network and data traffic.

  • Automatic Key Management

    IPSec services dynamically exchange and manage cryptography-based keys between communicating computers.

  • Automatic Security Negotiation

    IPSec services dynamically negotiate a mutual set of security requirements between communicating computers, eliminating the need for both computers to have identical policies.

  • Public Key Infrastructure Support

    Using public key certificates for authentication is supported, to allow trust and secure communication with computers that do not belong to a Windows 2000 trusted domain.

  • Pre-Shared Key Support

    If authentication using the Kerberos v5 protocol or public key certificates is not possible, a pre-shared key (a shared, secret password), can be configured to enable authentication and trust between the communicating computers.


Services

IPSec provides a high level of security by using cryptography-based mechanisms. Cryptography allows information to be transmitted securely by hashing (integrity) and/or encrypting (confidentiality) the information.

A combination of an algorithm and a key is used to secure information:

  • The algorithm is the mathematical process by which the information is secured.
  • A key is the secret code or number required to read, modify, or verify secured data.

Windows 2000 IPSec supports the following services.


Security Properties

IPSec provides the following properties for secured communications:

  • Non-Repudiation

    Verifies that the sender of the message is the only person who could have sent it. The sender cannot deny having sent the message. Non-repudiation is a property of messages containing digital signatures when using public key technology. With public key technology, the sender’s private key is used to create a digital signature that is sent with the message. The receiver uses the sender’s public key to verify the digital signature. Because only the sender has possession of the private key, only the sender could have generated the digital signature. Non-repudiation is not a property of message authentication codes and hashes on messages using secret key technologies, because both the sender and the receiver have the secret key.

  • Anti-Replay

    Also called replay prevention, it ensures the uniqueness of each IP packet. Anti-replay ensures that data captured by an attacker cannot be re-used or “re-played” to establish a session or gain information illegally. This protects against attempts to intercept a message and then use the identical message to illegally gain access to resources, possibly even months later.

  • Integrity

    Protects data from unauthorized modification in transit, ensuring that the data received is exactly the same as the data sent. Hash functions sign each packet, which the receiving computer checks before opening the packet. If the packet - and therefore signature - has changed, the packet is discarded.

  • Confidentiality (encryption)

    Ensures that data is only disclosed to intended recipients. This is achieved by encrypting the data before transmission. This ensures that the data cannot be read during transmission, even if the packet is monitored or intercepted. Only the party with the shared, secret key is able to read the data (after decryption). This property is optional.

  • Authentication

    Verifies the origin and integrity of a message by assuring the genuine identity of each computer. Without strong authentication, an unknown computer and any data it sends is suspect. IPSec provides multiple methods of authentication, to ensure compatibility with computers not running Windows 2000 and remote computers.


Public Key Certificate-Based Authentication

Public Key Certificate–Based Authentication

A well-implemented public key infrastructure, in which security credentials can be presented without compromising those credentials in the process, resolves many security problems. IPSec works with your public key infrastructure to allow certificate-based authentication.

A public key certificate (PKC) ensures that who you say you are and who you really are do not differ. This process is called authentication, and a PKC is one type of authentication that reliably provides this verification.

Also called digital certificates, PKCs are like a virtual passport. They verify the identities of non-Windows 2000 computers, stand-alone computers, clients that are not members of a trusted domain, or computers that are not running the Kerberos v5 authentication protocol. (The Kerberos v5 protocol is the default Windows 2000 authentication method.)

For information about implementing a public key infrastructure, see “Security Solutions Using Public Key Technology” in the Microsoft Windows 2000 Distributed Systems Guide.


Pre-Shared Key Authentication

Windows 2000 can also use pre-shared keys for authentication. Pre-shared means the parties must agree on a shared, secret key that becomes part of the IPSec policy. Information is encrypted before transmission using the shared key, and decrypted on the receiving end using the same key; the encryption prevents attackers from gaining information. If the receiver can decrypt the information, identities are considered authenticated. This might cause problems if bogus packets are sent; these cannot be decrypted and this can cause a false assumption that authentication failed.


Public Key Cryptography

IPSec implements public key cryptography methods for authentication (certificate signing), and key exchange (the Diffie-Hellman algorithm). Public key cryptography has all the capabilities of secret key cryptography, but is generally more secure because it requires two keys—one for signing and encrypting the data, and one for verifying the signature and decrypting the data. This is often referred to as asymmetric cryptography, which simply means that two keys are required for the process.

Each user has a private key that is known only to that person, and a public key that is widely distributed. For example, if Alice wants to send a secured message to Bob, she uses Bob’s public key to encrypt the message. Only Bob can decrypt the message because that requires his private key. Although the keys in the pair are related, it is mathematically infeasible to generate one key using the other key. This is why the public key can be widely distributed. The private key, often referred to as the secret key, must remain closely guarded.


Integrity with Hash Functions

Hash message authentication codes (HMAC) “sign” packets to verify that information received is exactly the same as the information sent (integrity). This is critical when data is exchanged over unsecured media.

HMACs provide integrity by means of a hash function (algorithm), combined with a shared, secret key. A hash is more commonly described as a signature on the packet. This is somewhat inaccurate, because a hash differs from a digital signature: a hash uses a secret, shared key; a digital signature uses public key technology and the sending computer’s key. Hash functions are also sometimes referred to as message digests or one-way transforms. One-way transforms or functions are so named for two reasons: each party must perform the computation on their respective end, and because it is easy to go from message to digest but mathematically infeasible to go from digest to message. Conversely, two-way functions can go either way; encryption schemes are examples of two-way functions.

The hash signature itself is actually a cryptographic checksum or Message Integrity Code (MIC) that each party must compute to verify the message. For example, the sending computer uses an HMAC algorithm and shared key to compute the checksum for the message and includes it with the packet. The receiving computer must perform an HMAC computation on the received message, and compare it to the original (included in the packet from the sender). If the message has changed in transit, the hash values are different and the packet is rejected.

For integrity, you can choose between two hash functions when setting policy:

  • HMAC-MD5

    Message Digest 5 (MD5) is based on RFC 1321. It was a response to a weakness found in MD4, the previous incarnation of the original MD. MD5 is a little slower, but stronger.

    MD5 makes four passes over the data blocks (whereas MD4 made three passes), using a different number constant for each message word on every pass. This equates to 64, 32-bit constants used during the MD5 computation.

    Ultimately, this produces a 128-bit key used for integrity check.

  • HMAC-SHA

    Secure Hash Algorithm (SHA) was developed by the National Institute of Standards and Technology as described in FIPS PUB 180-1. The SHA process is closely modeled after MD5.

    SHA uses 79, 32-bit constants during the computation, which results in a 160-bit key that is used for integrity check. Longer key lengths provide greater security, so SHA is considered the stronger of the two.

For clarity and brevity, “sign” or “signature” is used for the remainder of this chapter when discussing how the hash function provides integrity.


Data Encryption: Confidentiality

Windows 2000 IPSec uses the Data Encryption Standard (DES) to provide confidentiality (data encryption). In addition, IPSec combines DES with additional algorithms to provide stronger security or to provide compliance with export requirements when not running domestic versions of Windows 2000.

DES

The DES algorithm was published in 1977 by the National Bureau of Standards. Although even DES-encrypted data can be successfully decrypted by an attacker, DES renders this endeavor infeasible because of the tremendous computing resources, money, and time required. Using IPSec, you can frequently regenerate keys during a communication. This prevents the entire data set from being compromised if one DES key is broken.

DES uses a 56-bit key, and maps a 64-bit input block into a 64-bit output block. The key appears to be a 64-bit key, but one bit in each of the 8 bytes is used for odd parity, resulting in 56 bits of usable key.

The input block is initially put through rounds to produce a 64-bit output block. A round is like shuffling a deck of cards—it is a randomization process to ensure that you produce different values each time. This key is used to generate 16, 48-bit, per-round keys. Each round takes as its input the outcome (key) of the previous round, plus the 48-bit key, and produces the next 56-bit key. After the sixteenth round, the key is permutated with the inverse of the initial permutation.

Cipher Block Chaining

Cipher Block Chaining (CBC) is used to hide patterns of identical blocks of data within a packet. An Initialization Vector (an initial random number) is used as the first random block to encrypt and decrypt a block of data. Different random blocks are used in conjunction with the secret key to encrypt each block. This ensures that identical clear-text data (unsecured data) results in unique, encrypted data blocks. Repeats can compromise the security of the key by providing a pattern with which an attacker can crack your encryption. Lack of repeats also prevents data expansion during encryption.

DES-CBC Variations

Windows 2000 IPSec provides the following DES-CBC options:

  • 3DES: 3DES is much more difficult to break than straight DES. It is the most secure of the DES combinations, and therefore slower in performance. 3DES processes each block three times, using a unique key each time:
    1. Encryption on the block with key 1
    2. Decryption on the block with key 2
    3. Encryption on the block with key 3

    This process is reversed if the computer is decrypting a packet.

  • 40-Bit DES: This permutation is provided to meet export requirements when not running domestic versions of Windows 2000. The straight DES-CBC is done with only 40 bits of keying material.
  • DES-CBC: This is provided for a base DES-CBC computation, with no additional algorithms, when the high security and overhead of 3DES is not necessary.


Key Management

A key is a secret code or number required to read, modify, or verify secured data. Keys are used in conjunction with algorithms (a mathematical process) to secure data. Windows 2000 automatically handles key generation and implements the following keying properties that maximize protection:

Dynamic Re-Keying

IPSec controls how often a new key is generated during the communication, using a method called dynamic re-keying. The communication is sent in blocks, and each block of data is secured with a different key. This prevents an attacker who has obtained part of a communication, and the corresponding session key(s), from obtaining the rest of the message.

IPSec policy allows expert users to control how often a new key is generated. If no values are configured, keys are regenerated automatically at default intervals.

Key Lengths

Every time the length of a key is increased by one bit, the number of possible keys doubles, making it exponentially more difficult to break the key. IPSec policy provides multiple algorithms to allow for short or long key lengths.

Key Material Generation: Diffie-Hellman

To enable secure communication, two computers must be able to gain the same, shared key (session key), without sending the key across a network because that would severely compromise the secret. Key Material Generation (DH) is designed to do just that.

DH predates Rivest-Shamir-Adleman (RSA) encryption and offers better performance. It is one of the oldest and most secure algorithms used for key exchange.

The two parties publicly exchange keying information, which Windows 2000 additionally protects with hash function encryption. Neither party ever exchanges the actual key; however, after their exchange of keying material, each is able to generate the identical shared key. At no time is the actual key ever exchanged.

DH keying material exchanged by the two parties can be based on 64, 96 or 128 bytes of keying material, known as DH groups. The strength of the DH group is directly related to the strength of the key. Strong DH groups combined with longer key lengths increase the degree of computational difficulty in trying to break the key.

IPSec uses the DH algorithm to provide the keying material for all other encryption keys. DH on its own provides no authentication; in the Windows 2000 IPSec implementation, identities are authenticated after the DH exchange takes place.

DH on its own does not prevent active attacks, but when combined with other Windows 2000 IPSec features, such as authentication, it is secure against both passive and active attacks.


IPSec Protocol Types

IPSec protocols provide data and identity (or addressing) protection services for each IP packet by adding their own security protocol header to each IP packet. The security protocol header resides between the IP header and the upper layer (layer 4) protocol header (TCP or UDP). The security protocol header provides the information for securing the payload (data) in the packet.


Authentication Header

Authentication Header (AH) provides authentication, integrity, and anti-replay for the entire packet (both the IP header and the data carried in the packet). It does not provide confidentiality, which means it does not encrypt the data. The data is readable, but protected by modification. AH uses the HMAC algorithms described earlier to sign the packet.

For example, Alice on Computer A sends data to Bob on Computer B. The IP header, the AH header, and the data are protected from modification by the signature. This means Alice can be certain it was really Bob who sent the data and that the data was unmodified.

Integrity and authentication are provided by the placement of the AH header between the IP header and the transport (layer 4) protocol header, which is shown as TCP/UDP in the Figure 9.1. AH uses an IP protocol decimal ID of 51 to identify itself in the IP header.

Figure 9.1 Authentication Header

AH can be used alone or in combination with the Encapsulating Security Payload (ESP) protocol.

The AH header contains the following fields:

  • Next Header

    Identifies the next header that uses the IP protocol ID. For example, the value might be “6” to indicate TCP.

  • Length

    Indicates the length of the AH header.

  • Security Parameters Index (SPI)

    Using in combination with the destination address and the security protocol (AH or ESP) to identify the correct security association for the communication. (For more information, see the “ISAKMP/Oakley” section later in this chapter.) The receiver uses this value to determine with which security association this packet should be identified.

  • Sequence Number

    Provides anti-replay. It is an incrementally increasing number (starting from 0) that is never allowed to cycle and that indicates the packet number sent over the security association for the communication. The receiver checks this field to verify that a packet for a security association with this number has not been received already. If one has been received, the packet is rejected.

  • Authentication Data

    Contains the Integrity Check Value (ICV) that is used to verify the integrity of the message. The receiver calculates the hash value and checks it against this value (calculated by the sender) to verify integrity.

Packet Signature

AH is inserted after the IP header and before an upper layer protocol such as TCP, UDP, or ICMP. If another security protocol is being used in addition to AH, the AH header is inserted before any other IPSec headers. The packet signature is shown graphically in Figure 9.2.

Figure 9.2 AH Integrity Signature

AH signs the entire packet.


Encapsulating Security Payload

Encapsulating Security Payload (ESP) provides confidentiality, in addition to authentication, integrity, and anti-replay. ESP can be used alone, in combination with AH, or nested with the tunneling protocol L2TP.

ESP does not normally sign the entire packet unless it is being tunneled—ordinarily, just the data is protected, not the IP header. For example, Alice on Computer A sends data to Bob on Computer B. The data is encrypted because ESP provides confidentiality. Upon receipt, after the verification process is complete, the data portion of the packet is decrypted. Bob can be certain it was really Alice who sent the data, that the data is unmodified, and that no one else was able to read it.

ESP indicates itself in the IP header using the IP protocol decimal ID of 50. As shown in the Figure 9.3, the ESP header is placed prior to the transport layer header (TCP or UDP).

Figure 9.3 ESP

The ESP header contains the following fields:

  • Security Parameters Index

    Identifies, when used in combination with the destination address and the security protocol (AH or ESP), the correct security association for the communication. The receiver uses this value to determine the security association with which this packet should be identified.

  • Sequence Number

    Provides anti-replay. It is an incrementally increasing number (starting from 0) that indicates the packet number sent over the security association for the communication. The sequence number is never allowed to cycle. The receiver checks this field to verify that a packet for a security association with this number has not been received already. If one has been received, the packet is rejected.

The ESP trailer contains the following fields:

  • Padding

    0 to 255 bytes is used for 32-bit alignment and with the block size of the block cipher.

  • Padding Length

    Indicates the length of the Padding field in bytes. This field is used by the receiver to discard the Padding field.

  • Next Header

    Identifies the nature of the payload, such as TCP or UDP.

The ESP Authentication Trailer contains the following field:

  • Authentication Data

    Contains the Integrity Check Value (ICV), and a Message Authentication Code (MAC) that is used to verify the sender’s identity and message integrity. The ICV is calculated over the ESP header, the payload data and the ESP trailer.

Packet Signature and Encryption

As shown in Figure 9.4, ESP provides protection for upper layer protocols. The Signed area indicates where the packet has been signed for integrity. The Encrypted area indicates what information is protected with confidentiality.

Figure 9.4 ESP: Signature and Encryption

ESP is inserted after the IP header and before an upper layer protocol, such as TCP, UDP, or ICMP, or before any other IPSec headers that have already been inserted. Everything following ESP (the upper layer protocol, the data, and the ESP trailer) is signed. The IP header is not signed, and therefore not necessarily protected from modification. The upper layer protocol information, the data, and the ESP trailer are encrypted.


IPSec Components

The following sections describe IPSec components.


IPSec Policy Agent Service

The purpose of the policy agent is to retrieve IPSec policy information and pass it to the other IPSec mechanisms that require that information to perform security services, as shown in Figure 9.5.

Figure 9.5 IPSec Policy Agent

The policy agent is an IPSec mechanism residing on each Windows 2000 computer, appearing in the list of system services. The policy agent performs the following tasks:

  • Retrieves the appropriate IPSec policy from Active Directory if the computer is a domain member. If the computer is a stand-alone computer, or not currently connected to the domain, the policy is retrieved from the local registry.
  • Sends policy information to the IPSec driver.

Retrieval of the policy occurs both at system start time, and at the interval specified in the IPSec policy (if the computer is a domain member). If IPSec policy information is centrally configured for any or all computers in a domain, the IPSec policy information is stored in Active Directory and the local registry of the computer to which it applies. If the computer has been disconnected from a domain and is using local policies, when the computer reconnects to the domain any domain policies assigned to that computer overrides the local policies. If a computer is not usually a domain member (for example, a stand-alone computer), or is a member of a domain that is not using Active Directory for policy storage, IPSec policies are stored in the local registry.

The policy agent starts automatically at system start time. If there are no IPSec policies in the directory service or registry, or if the policy agent cannot connect to the directory service, the policy agent waits for policy to be assigned or activated.


ISAKMP/Oakley

Before secured data can be exchanged, a contract between the two computers must be established. In this contract, called a security association (SA), both agree on how to exchange and protect information, as shown in Figure 9.6.

Figure 9.6 ISAKMP/Oakley

To build this contract between the two computers, the IETF has established a standard method of security association and key exchange resolution, which combines the Internet Security Association and Key Management Protocol (ISAKMP) and the Oakley key generation protocol:

  • ISAKMP centralizes security association management, reducing connection time.
  • Oakley generates and manages the authenticated keys used to secure the information.

This process protects not only computer to computer communications, but also protects remote computers that are requesting secure access to a corporate network; or any situation in which the negotiation for the final destination computer (endpoint) is actually performed by a security router or other proxy server. In the latter situation, referred to as ISAKMP client mode, the identities of the endpoints are hidden to further protect the communication.

What Is an SA?

An SA is a combination of a policy and key(s) which defines the common security services, mechanisms, and keys used to protect the communication from end to end. The security parameters index (SPI) is a unique, identifying value in the SA used to distinguish among multiple security associations existing at the receiving computer. For example, multiple associations might exist if a computer is securely communicating with multiple computers simultaneously. This situation occurs mostly when the computer is a file server or a remote access server which serves multiple clients. However, one computer can have multiple SAs with a single computer. In these situations, the receiving computer uses the SPI to determine which SA is used to process the incoming packets.

Key Establishment: Oakley

The purpose of the Oakley protocol is to establish extremely strong cryptography-based keys. This is a basic requirement of secured communications. To accomplish this, Oakley:

  • Defines how two parties can select prime number groups (which the DH exchange uses), to provide an additional degree of security.
  • Might derive keys from the DH exchange or from an existing key.
  • Provides identity protection, Perfect Forward Secrecy (PFS), and key lifetime and refresh limit enforcement.
  • Provides the required support for secret key (pre-shared) and certificate-based authentication methods.

The ISAKMP SA

To ensure successful, secure communication, ISAKMP/Oakley performs a two-phase operation. Confidentiality and authentication during each phase is assured by the use of negotiated encryption and authentication algorithms agreed on by the two computers. With the duties split between two phases, keying can be accomplished with great speed.

During the first phase, the two computers establish a secure, authenticated channel—the ISAKMP SA. (The SA is named in order to differentiate between the SAs established in each of the two phases.) Oakley refers to this process as Main Mode, and provides the necessary identity protection during this exchange. This ensures no identity information is sent without encryption between the communicating computers, thus enabling total privacy. ID protection is automatically provided, and can help prevent common types of network attacks such as Man-in-the-Middle and IP Spoofing by unauthenticated parties.

Phase 1 Negotiation

Following are the steps in Phase 1 negotiation.

  1. Policy Negotiation

    The following four mandatory parameters are negotiated as part of the ISAKMP SA:

    • The encryption algorithm (DES-CBC, 3DES, 40-bit DES).
    • The hash algorithm (MD5 or SHA).
    • The authentication method (Certificate, pre-shared key, Kerberos v5 authentication).
    • The Diffie-Hellman (DH) group to be used for the base keying material.

    If certificates or pre-shared keys are used for authentication, the computer identity is protected. However, if Kerberos v5 authentication is used, the computer identity is unencrypted until encryption of the entire identity payload takes place during authentication.

  2. DH Exchange (of public values)

    Each computer that has the necessary information generates the shared, secret key—the master key—for the ISAKMP SA. At no time are actual keys exchanged; only the base information needed by DH to generate the shared, secret key is exchanged. After this exchange, the Oakley service on each computer generates the master key used to protect the final round: authentication.

  3. Authentication

    The computers attempt to authenticate the DH exchange. Without successful authentication, communication cannot proceed. The master key is used, in conjunction with the negotiation algorithms and methods, to authenticate identities. The entire identity payload—including the identity type, port, and protocol—is hashed and encrypted using the keys generated from the DH exchange in the second round. The identity payload, regardless of which authentication method is used, is protected from both modification and interpretation.

The ISAKMP initiator presents an offer for a potential security association to the ISAKMP responder. The responder cannot modify the offer. Should the offer be modified, the initiator rejects the responder’s message. The responder sends either a reply accepting the offer or a reply with alternatives. In this example, the initiator of the communication has put multiple proposals in the message. The responder can then choose one of the SA attribute sets.

Messages during this phase have an automatic retry cycle which repeats five times. After three seconds, a soft SA is established (if policy allows). Should an ISAKMP response be received before the cycle times out, the soft SA is deleted and standard SA negotiation begins.

There is no limit to the number of exchanges that can take place. At a given time, the number of SAs formed are only limited by system resources. The ISAKMP/Oakley SA is symmetric or bi-directional, meaning that either party can use it to initiate the second phase.

The IPSec SA

Because this second phase involves the establishment of SAs negotiated on behalf of the IPSec service, it is named the IPSec SA. Keying material is refreshed or new keys are generated, if necessary, as a result of PFS, key lifetime, or refresh limits or the expiration of the ISKAMP SA. It is also referred to as the Oakley Quick Mode. It is not considered a whole exchange by itself because it is bound to the exchange of the first phase.

Phase 2 Negotiation

The following are the steps in Phase 2 negotiation.

  1. Policy negotiation

    The IPSec computers exchanges their requirements for securing the data transfer:

    • The IPSec protocol (AH or ESP)
    • The hash algorithm for integrity and authentication (MD5 or SHA)
    • The algorithm for encryption (if requested)

    A common agreement is reached, and two SAs are established: one for inbound and one for outbound communication.

  2. Session key material refresh or exchange

    Oakley refreshes the keying material and new, shared, or secret keys are generated for authentication, and possibly encryption, of the packets. If a re-key is required, a second DH exchange (as described in “Phase 1 Negotiation”) takes place prior to this (when Perfect Forward Secrecy is enabled), or a refresh of the original DH is used for the re-key. See the “Key Protection” section later in this chapter for more information on Perfect Forward Secrecy.

  3. The SAs and keys are passed to the IPSec driver, along with the SPI.

During this second negotiation of shared policy and keying material—this time to protect the data transfer—the information is protected by the ISKAMP SA. This means that all payloads except the ISAKMP header are encrypted and a hash signature follows the ISAKMP header which authenticates the message.

As the first phase provided identity protection, the second phase provides protection by refreshing the keying material to prevent bogus SAs (Oakley itself handles all prevention of replays on Oakley negotiations). ISAKMP/Oakley can accommodate a key exchange payload for an additional DH exchange, should a re-key be necessary (when master key PFS is enabled). Otherwise, ISAKMP/Oakley refreshes the keying material from the DH exchange in the first phase.

Quick Mode results in two security associations: one for inbound communication and one for outbound; each with its own SPI and key.

The retry algorithm for a message here is almost identical to the process discussed in “Phase 1 Negotiation,” with only one difference: If this process reaches a time-out for any reason during the second or greater negotiation off the same ISAKMP SA, a renegotiation of the ISAKMP SA is attempted. If a message for this phase is ever received with no ISAKMP SA established, it is rejected.

Using a single ISAKMP SA for multiple IPSec SA negotiations makes the process extremely fast. As long as the ISAKMP SA does not expire, renegotiation and re-authentication are not necessary. The number of IPSec SA negotiations that can be performed is determined by IPSec policy attributes. Note that excessive re-keying off the same ISAKMP SA could compromise the shared, secret key.

SA Lifetimes

The ISAKMP SA is cached to allow multiple IPSec SA negotiations (unless PFS is enabled for the master key, or the session key policy lifetimes have been reached). When a key lifetime is reached for the master or session key, the SA is renegotiated, in addition to the key refresh or regeneration.

When the default time-out period is reached for the ISAKMP SA (eight hours), or the master or session key lifetime is reached, a delete message is sent to the responder. The Oakley delete message tells the responder to expire the ISAKMP SA. This prevents bogus IPSec SAs from being formed because IPSec SAs are valid until their lifetime is expired by the IPSec driver, independently of the ISAKMP SA lifetime. Oakley does not expire the IPSec SA, because only the IPSec driver knows the number of seconds or bytes that have passed to reach the key lifetime.

Use caution when setting very disparate key lifetimes, which also determine the lifetime of the SA. For example, setting a master key lifetime of 8 hours and a session key lifetime of 2 hours can mean that you have an IPSec SA in place for almost 2 hours after the ISAKMP SA expired. This can occur if the IPSec SA is generated immediately before the ISAKMP SA expires.

If the power save features in Windows 2000 cause a hibernate or sleep, and an SA expires before the computer is reactivated, that SA is automatically re-negotiated. If Windows 2000 is shut down on one of the computers, the Oakley delete message is sent to clean up any remaining SAs. New SAs are negotiated when the computers reattempt communication. However, if Windows 2000 terminates abnormally, the Oakley delete messages are not sent. This can leave SAs in place until the default time-out period. In such a scenario, manually delete the SAs. For more information about manually deleting SAs, see the “Troubleshooting” and “Restarting the Policy Agent” sections later in this chapter.


Key Protection

The base prime numbers (keying material) and the strength of the keys for the master and session keys are enhanced by the following features. The features discussed here apply to one or both, as stated.

Key Lifetimes

Key lifetimes determine when a new key is generated, rather than how it is generated. Key lifetimes are also called dynamic re-keying or key regeneration. A key lifetime allows you to force a key regeneration after a specific interval. For example, if the communication takes 100,000 seconds and you specify the key lifetime as 1000 seconds, 10 keys are generated to complete the transfer. This ensures that even if attackers gain part of a communication, they are not able to gain the entire communication. Automatic key regeneration is provided; configuration is optional. Key lifetimes can be specified for both the master and session keys. Any time a key lifetime is reached, the SA is also renegotiated in addition to the key refresh or regeneration.

Session Key Refresh Limit

Repeated re-keying off a session key can compromise the Diffie-Hellman shared secret. Thus, a session key refresh limit is implemented to avoid a security compromise.

For example, Alice on Computer A sends a message to Bob on Computer B, and then sends another message to Bob a few minutes later. The same session key material might be reused because an SA was recently established with that computer. If you want to limit the number of times this occurs, configure the session key refresh limit to a low number.

If you have enabled Perfect Forward Secrecy (PFS) for the master key, the session key refresh limit is ignored because PFS forces key regeneration. Setting a session key refresh limit to 1 is identical to enabling master key PFS. If both a master key lifetime and a session key refresh limit is specified, whichever limit is hit first causes the subsequent re-key. By default, IPSec policy does not specify a session key refresh limit.

Diffie-Hellman Groups

Diffie-Hellman (DH) groups are used to determine the length of the base prime numbers (key material) for the DH exchange. The strength of any key derived from a DH exchange depends in part on the strength of the DH group the primes are based on.

Each DH group defines the length of the key material to be used. Group 2 (medium) is stronger than Group 1 (low). Group 1 protects 768 bits of keying material; Group 2 protects 1024 bits. A larger group means the resulting DH has more entropy and, therefore, is harder to break. The export group is provided for nondomestic versions of Windows 2000.

Oakley takes care of negotiating which group to use, ensuring there are not any negotiation failures as a result of a mismatched DH group between the two peers.

If PFS for the session is enabled, the DH is passed in the SA with the key information during the first message of the IPSec SA negotiation. This forces a new DH permutation which removes the session keying material from the initial DH exchange.

If the sender is using PFS for the session key, the responder is not required to use it as well. However, if the initiator is not using PFS for the session and the responder is using PFS, negotiation fails.

The DH group is the same for both the ISAKMP and IPSec SA negotiations. This means that when session key PFS is enabled, even though the DH group is set as part of the ISAKMP SA negotiation, it affects any re-keys during session key establishment.

Perfect Forward Secrecy

Unlike key lifetimes, Perfect Forward Secrecy (PFS) determines how a new key is generated, rather than when it is generated. Specifically, PFS ensures that compromise of a single key permits access only to data protected by that single key—not necessarily to the entire communication. To achieve this, PFS ensures that a key used to protect a transmission, in whichever phase, cannot be used to generate any additional keys. In addition, if the key used was derived from specific keying material, that material cannot be used to generate any other keys.

Master key PFS requires a re-authentication, so use it with caution. When it is enabled, the ISAKMP/Oakley service must re-authenticate identities, causing additional overhead for any domain controllers. It requires an exchange of ten messages and an authentication.

However, session key PFS can be done without the re-authentication and is therefore less resource-intensive. Session key PFS results in a DH exchange to generate new key material. It requires only four messages and no authentication.

PFS is not required to be enabled on both peers because it is not a negotiable property. If the responder requires PFS and the sender’s IPSec SA expires, it simply rejects the sender’s message and requires a new negotiation. The sender expires the ISAKMP SA and re-negotiates. PFS can be individually set for both the master and session keys.


The IPSec Driver

The IPSec driver is like a security watchdog. It grabs packets that must be processed for secure communications and requests ISAKMP/Oakley negotiations.

As shown in Figure 9.7, the IPSec driver receives the IP filter list from the IPSec policy agent. The IPSec driver watches all outgoing IP packets on the computer for a match with the stored IP filter list. Outbound packets initiate the negotiation for security when a match occurs. The IPSec driver notifies ISAKMP/Oakley to begin security negotiations.

Figure 9.7 IPSec Driver Services

After a successful negotiation is complete, the IPSec driver on the sending computer:

  1. Receives the session key, SA and SPI from ISAKMP/Oakley.
  2. Looks up the outbound SA in its database, and inserts the SPI from the SA into the IPSec header.
  3. Signs, and if confidentiality is required, encrypts the packets.
  4. Sends packets with SPI to the IP layer to be forwarded to the destination computer.

The IPSec driver on the receiving computer:

  1. Receives the session key, SA and SPI from ISAKMP/Oakley.
  2. Looks up the inbound SA in its database by destination address and SPI.
  3. Checks the signature and decrypts the packets (if required).
  4. Sends packets to the TCP/IP driver for passage to the receiving application.

The IPSec driver stores all current SAs in a database. If multiple SAs are present, the driver uses the SPI as needed to determine which SA goes with which packet.


The IPSec Model

Now that the function of each component has been explained individually, a comprehensive picture is necessary to complete an understanding of the architecture, as shown in Figure 9.8.

Figure 9.8 Overview: the IPSec Process

For simplicity, this is an intranet computer example. Each computer has an active IPSec policy.

  1. Alice, using a data application on Computer A, sends a message to Bob on Computer B.
  2. The IPSec driver on Computer A checks its stored IP Filter Lists to see whether the packets should be secured.
  3. The driver notifies ISAKMP/Oakley to begin negotiations.
  4. The ISAKMP/Oakley service on Computer B receives a message requesting secure negotiation.
  5. The two computers establish an ISAKMP SA and shared key.

Note

If Computer A and Computer B already have an ISAKMP SA in place from a previous communication (and PFS or key lifetimes have not expired), the two computers can go directly to establishing the IPSec SA.

  1. The IPSec SAs and keys are negotiated.
  2. The IPSec driver on Computer A uses the outbound SA to sign and encrypt the packets.
  3. The driver passes the packets to the IP layer, which routes the packets toward Computer B.
  4. Computer B’s network adapter driver receives the encrypted packets and passes them up to the IPSec driver.
  5. The IPSec driver on Computer B uses the inbound SA to check the integrity signature and decrypt the packets.
  6. The driver passes the decrypted packets up to the TCP/IP driver, which passes them to the receiving application on Computer B.

Although this appears to be a long series of time-consuming and complicated steps, it actually all happens quickly and transparently to each user.

Any routers or switches in the data path between the communicating computers simply forward the encrypted IP packets to their destination. However, if there is a firewall, security router, or proxy server, you must enable IP forwarding. For more information about IP forwarding, see Part 3, “Interoperability” in the Microsoft Windows 2000 Internetworking Guide.


Tunneling

Tunneling is also referred to as encapsulation because the original packet is hidden or encapsulated inside of a new packet. The header on the new packet provides the necessary routing information so it can travel through a transit internetwork without revealing final destination information from the original packet header. The transit internetwork can be any internetwork; a private intranet or the Internet. After the encapsulated packet reaches its destination on the transit internetwork, the encapsulation header is stripped and the packet or frame is forwarded to its final destination. The entire process of encapsulation, routing, and de-encapsulation of packets is known as tunneling.

A tunnel is the logical data path through which the encapsulated packets travel to their destination. To each party, the tunnel appears to be a point-to-point connection between them, with no intranet routers, switches, proxy servers, or other security gateways in between. When the tunnel is encrypted, such as with the Layer 2 Tunneling Protocol (L2TP) or IPSec’s Encapsulated Security Payload (ESP) protocol, it is referred to as a virtual private network. See the “Virtual Private Networking” chapter in the Microsoft Windows 2000 Internetworking Guide for additional, general information about tunneling and virtual private networks.

To the computers on each end of the tunnel, the connection appears to be a point-to-point interface with no intranet routers, switches, proxy servers, or other security gateways between them. For example, a salesperson working from a remote location can dial in, and securely exchange data with a corporate file server through a tunnel. From the salesperson’s perspective, the connection seems as direct as an onsite connection. Figure 9.9 shows the tunneling process.

Figure 9.9 The Tunneling Process

In this example, the transit network is whatever medium that is between the two parties. In reality, either computer could be an edge gateway (a router, firewall, proxy server, or other security gateway) that stands between the outside world and the private network. Regardless, the receiver is always the tunnel endpoint to the sender. Here, the Gateway is the tunnel endpoint to the remote client, and vice versa. The encapsulated packets travel across the network, in this case the Internet, through the tunnel. To each party, the Internet doesn’t exist—only the tunnel’s point-to-point, secure connection.

IPSec can, in combination with L2TP, provide tunneling and security for IP packets across any network. IPSec can also perform tunneling without L2TP, but it is only recommended for interoperability (such as when one of the computers does not support L2TP). In the recommended configuration, L2TP builds the tunnel, and IPSec secures the data. When IPSec performs tunneling without L2TP, the ESP protocol is used to build the tunnel and secure the packets.

If your network uses an edge gateway for security (a firewall, secure router, or proxy server in the logical data path), you have to configure special filtering. For more information about IPSec policies, see “IPSec Policy Considerations” later in this chapter.


Layer 2 Tunneling

L2TP performs Layer 2 tunneling, meaning the tunneled payload is a Data Link Layer frame. A PPP frame is encapsulated to be sent across a transit network. L2TP allows traffic in addition to IP to be tunneled, such as IPX and NetBEUI traffic. IPSec’s ESP only tunnels IP traffic.


Layer 3 IP Tunneling

IPSec’s ESP performs Layer 3 tunneling, meaning the tunneled payload is a Network Layer packet. The entire IP packet is encapsulated and secured for transfer.

ESP Tunnel Mode

As shown in Figure 9.10, when in tunnel mode the inner IP header (the original packet header) carries the ultimate source and destination addresses, and the outer IP header might contain addresses of security gateways.

Figure 9.10 ESP Tunnel Mode

The signed area indicates where the packet has been signed for integrity and authentication. The Encrypted area indicates what information is protected with confidentiality services.

Because a new header for tunneling is placed on the packet, everything following the ESP header is signed (except for the ESP authentication trailer), as it is now encapsulated in the tunneled packet. The original header is placed after the ESP header.

The entire packet is appended with an ESP trailer prior to encryption. Everything following the ESP header, except for the ESP authentication trailer, is encrypted, including the original header because it is now considered to be part of the data portion.

The entire ESP payload is then encapsulated within the new tunnel header, which is not encrypted. The information in the new tunnel header is only used to route the packet from origin to destination.

If the packet is being sent across a public network, the packet is routed to the IP address of the tunnel server for the receiving intranet. The packet itself is most likely destined for an intranet computer. The tunnel server decrypts the packet, throws away the ESP header, and uses the original IP header to route the packet to the intranet computer.

AH Tunnel Mode

The only difference between AH tunnel mode and ESP tunnel mode is how the packet is handled. As shown in Figure 9.11, AH signs the entire packet, including the new Tunnel Header (ESP does not sign the tunnel header). However, encryption is not provided by AH.

Figure 9.11 AH Tunnel Mode

ESP and AH can be combined to provide tunneling which includes both integrity for the entire packet, and confidentiality for the original IP packet, which contains the data being sent.


L2TP and IPSec

As shown in the Figure 9.12, when L2TP and IPSec are used in combination to provide a secured tunnel, the original packet header (shown here as the IP or IPX header), carries the ultimate source and destination addresses, and the outer IP header (shown as New IP Header) contains the next destination only - usually the address of the gateway.

The L2TP header carries the necessary information to route the L2TP payload to the proper tunnel. For more information about L2TP and tunneling, see the “Virtual Private Networking” chapter in the Windows 2000 Internetworking Guide.

The PPP header identifies the protocol of the original packet: IP or IPX.

Figure 9.12 L2TP/IPSec Tunnel Mode

When Layer 2 tunneling schemes run combined with IPSec in this manner, it provides the following additional benefits:

Stateless Encryption

Because IP is a connectionless protocol, IPSec encryption schemes encrypt packets individually and do not depend on the encryption of previous packets. Therefore, the compromising of one packet does not automatically lead to the ability to decrypt the rest of the packets in the communication. When Layer 2 tunneling protocols are run over IPSec, it is possible to utilize IPSec’s stateless encryption mechanisms rather than PPP’s stateful encryption mechanisms.

Choice of Encryption Algorithms

IPSec implementations typically offer support for a wider variety of encryption algorithms than do Layer 2 tunneling protocols, which are based on PPP encryption. However, when Layer 2 tunneling protocols are run over IPSec, all of IPSec’s encryption algorithms become available to encrypt the Layer 2 tunneling traffic.

Authentication, Integrity Check, and Replay Protection

IPSec provides support for security services not available in PPP and Layer 2 tunneling protocols. These include support for per-packet authentication, integrity checks and replay protection. However, when Layer 2 tunneling protocols are run over IPSec, all IPSec security services become available to protect Layer 2 tunneling traffic.


IPSec Policy Structure

IPSec policies can be applied to computers, sites, domains, or any organizational units (OUs) you create in Active Directory. When applied above the computer level to a Group Policy object such as a site, domain or OU, the IPSec policy is propagated to affect any members of that group.

Your organization's IPSec policies should be based on your organization's written (and unwritten) guidelines for secure operations. Through the use of security actions, called rules, one policy can be applied to heterogeneous security groups of computers or organizational units. For more information about choosing guidelines for secure operations, see the “Security Planning Best Practices” section later in this chapter.

There are two storage locations for IPSec policies:

  1. Active Directory
  2. Locally defined in the registry for stand-alone computers and computers which are not part of a trusted Windows 2000 domain. When the computer is temporarily not connected to a trusted Windows 2000 domain, the policy information is cached in the local registry.

Each policy you create should apply to a scenario you listed when you established a security plan. Special configuration settings might apply if you are assigning policies to a DHCP server, Domain Name System (DNS), Windows Internet Naming Service (WINS), Simple Network Management Protocol (SNMP), or remote access server.

Predefined (default) policies are provided which can be used as is, or modified to meet your needs, eliminating the need to create custom policies unless you have special requirements. These can be applied to both Active Directory (group) security policies and local security policies.


Policy Inheritance

Policy precedence follows the Group Policy inheritance model. Group policy is applied hierarchically from the least restrictive group (site) to the most restrictive group (OU). Group policy is also cumulative. Child containers inherit Group Policy from parent containers, and Group Policy processing occurs in the following order: site, domain, and organizational unit. This means that if you have assigned a specific Group Policy to a high-level parent container, that Group Policy applies to all containers beneath the parent container, including the user and computer objects in each container. However, if you explicitly specify a Group Policy for a child container, the child container’s Group Policy overrides the parent container’s Group Policy. For more information about Active Directory and Group Policy, see chapters under the “Active Directory” and “Desktop Configuration Management” parts in the Windows 2000 Distributed Systems Guide.

Things to keep in mind when assigning an IPSec policy:

  • IPSec policies applied to domain policy override local IPSec policy when that local computer is connected to the domain.
  • Precedence of Group Policy objects: IPSec policies assigned OUs in Active Directory override domain level policy for any members of that OU, and the lowest level OU IPSec policy overrides IPSec policy for higher level OUs for any members of that OU.


Rules

Rules govern how and when an IPSec policy protects communication. A rule provides the ability to trigger and control secure communication based on the source, destination, and type of IP traffic.

Each rule contains a list of IP filters and a collection of security actions that take place upon a match with that filter list:

  • Negotiation policies
  • Authentication methods
  • IP tunneling attributes
  • Connection types

Each policy can contain one or multiple rules; one or all of which can be active simultaneously. For example, you might want to have one policy for a site router, but you require different security actions for intranet and Internet communications. One policy can be used for the router by creating multiple rules: one for each possible communication scenario.

Default rules are provided with IPSec, and encompass a variety of client and server based communications. These can be used as is, or modified to your requirements.


IP Packet Filtering

Each TCP/IP computer is identified by a logical IP address. This address is unique for each computer that communicates using TCP/IP. Each 32-bit IP address identifies a computer system’s location on the network in the same way that a street address identifies each house on a city street.

Just as a street address has a standard two-part format (a house number and a street name), each IP address is separated internally into two parts, a network ID and a computer ID:

  • The network ID identifies a single network within a larger TCP/IP network (that is, a network of networks). All the systems that attach to and share access to this network share this common network ID within their full IP address. This ID is also used to identify each network uniquely within the larger network.
  • The computer ID identifies a workstation, server, router, or other TCP/IP device within each network. The computer ID for each device identifies a single system uniquely within its own network.

Filters

A rule provides the ability to trigger negotiation for a secure communication based on the source, destination, and type of IP traffic, a process called IP packet filtering. This provides a way for the network administrator to define precisely what IP traffic triggers an attempt to negotiate security between the two parties.

Each IP Filter list contains a list of filters. Each filter within an IP Filter List describes a particular subset of network traffic to be secured, both for inbound and outbound traffic:

  • Inbound filters, which apply to traffic received, allow the receiving computer to match the traffic with the IP Filter List. Inbound filters respond to requests for secure communication or match the traffic with an existing SA and process the secured packets.
  • Outbound filters, which apply to traffic leaving a computer toward a destination, trigger a security negotiation that must take place before traffic is sent.

For example, if Computer A always wants to exchange data securely with Computer B:

  • In order to send secured data to Computer B, Computer A's IPSec policy must have a filter for any outbound packets going to Computer B.
  • In order to receive secured data from Computer A, Computer B's IPSec policy must have a filter for any inbound packets from Computer A.

You must have a filter to cover any traffic for which the associated rule applies. A filter contains the following parameters:

  • The source and destination address of the IP packet. These can be configured from a very granular level, such as a single IP address or Domain Name System (DNS) name, to a global level that encompasses an entire subnet, or network.
  • The protocol over which the packet is being transferred. This automatically defaults to cover all protocols in the TCP/IP protocol suite. However, it can be configured to an individual protocol level to meet special requirements, including custom protocol numbers.
  • The source and destination port of the protocol for TCP and UDP. This also defaults to cover all ports, but can be configured to apply to only packets sent or received on a specific protocol port.


Negotiation Policies

The filter action sets the security requirements for Phase 2 of the communication. These requirements are specified in a list of security methods contained in the filter action, including which algorithms, security protocols, and key properties are to be used.

A filter action can be configured as a pass-through policy—one which does not allow secure communication. IPSec simply ignores traffic in this case. This is appropriate for traffic from computers such as Web TV servers, which are solely broadcasting communication which should never be secured.

In addition, to enable communication with non-IPSec-enabled computers, a filter action can be configured to use soft SAs (no security). If you need to configure a filter action like this be sure to limit the IP Filter List to a minimal scope.

Negotiation policies can also be set to block all traffic; for example, to stop communication from a rogue computer. If you are concerned about denial-of-service attacks, you might consider disabling the pass-through feature; however, the tradeoff is that communication from computers that do not initiate IPSec might be blocked.

The IPSec filter action can be set to use no security. However, it should be used with extreme caution: any communications affected by that policy could result in data being sent without protection if negotiation failed for any reason.


Connection Types

Designating a connection type for each rule allows you to determine what computer connections (network adapters or modems) are affected by your IPSec policy. Each rule has a connection property that designates whether the rule applies to multiple connections or just one connection. For example, you might want any tunneling rules to apply only to dial-up connections, not to local area network (LAN) connections.

Connections refers to anything you create in the Network Connections console. For example, you might decide to apply a rule to any LAN connections. All LAN connections you created in the Network Connections console are affected by that rule.


Authentication

Windows 2000 supports all of the following authentication methods:

  • The Kerberos v5 authentication protocol is the default authentication technology. The Kerberos v5 protocol issues tickets, or virtual proof-of-identity cards, when a computer logs on to a trusted domain. This method can be used for any clients running the Kerberos v5 protocol (whether or not they are Windows-based clients) that are members of a trusted domain. For more information about the Windows 2000-based Kerberos v5 authentication protocol, See the “Authentication” chapter in the Windows 2000 Distributed Systems Guide.
  • A pre-shared key can be specified. A pre-shared key is a shared, secret key that is previously agreed upon by two users. It is quick to use and does not require the client to run the Kerberos v5 protocol or have a public key certificate. Both parties must manually configure IPSec to use this pre-shared key. This is a simple method for authenticating non-Windows-based computers, stand-alone computers, or any clients not running the Kerberos v5 protocol. Note that this key is for authentication protection only; it is not used to encrypt the data.
  • Use a public key certificate in situations that include Internet access, remote to corporate resources, external business partner communications, or computers that do not run the Kerberos v5 authentication protocol. This requires that at least one trusted Certificate Authority (CA) has been configured. Windows 2000 supports X.509 version 3 certificates, including CA certificates generated by commercial certifying authorities. For information about the Windows 2000–based Kerberos v5 authentication protocol, see the Windows 2000 Distributed Systems Guide.

A rule can specify multiple authentication methods to ensure a common method is found when negotiating with a peer.


Security Planning Best Practices

The Windows 2000 IPSec Management snap-in greatly simplifies implementation. To take advantage of this and to avoid problematic implementations, you should:

  • Evaluate the type of information being sent over your network: is it sensitive financial data, proprietary information, or electronic mail? Some departments might require a higher level of security than the majority of the enterprise because of the nature of their function.
  • Determine where your information is stored, how it routes through the network, and from what computers access can be gained. This provides information about the speed, capacity, and utilization of the network prior to IPSec implementation, which is helpful for performance optimization.
  • Evaluate your vulnerability to the network attacks discussed at the beginning of this chapter.
  • Design and document an enterprise-wide network security plan. Take into account the following:
    • The general security framework of Windows 2000, including the Active Directory model for Group Policy objects and how security might be applied to those objects.
    • Your likely communication scenarios: remote access, extranets for business partners, communication between sites (router to router).
    • The level of security necessary for each scenario. For example, you might decide only Internet communications require confidentiality.
  • Design, create, and test the IPSec policies for each scenario in your plan. This allows you to clarify and refine what policies and policy structures are necessary.


Establishing a Security Plan

Implementing security, whether for a domain or a single computer, means finding a balance between fundamentally opposing forces: making information easily available to the largest number of users, and protecting important information from unauthorized access. Both IP security and the Windows 2000 security framework must be considered.

Finding the proper balance requires the following:

  • Assessing the risk and determining the appropriate level of security for your organization.
  • Identifying valuable information.
  • Defining security policies that use your risk management criteria and protect the identified information.
  • Determining how the policies can best be implemented within the existing organization.
  • Ensuring that management and technology requirements are in place.
  • Providing all users with secure and efficient access to the appropriate resources according to their needs.

Security considerations also are influenced by the operational context of the computer to which they apply. For example, the security required might differ depending on whether the computer is a domain controller, Web server, remote access server, file server, database server, intranet or remote client.

The Windows 2000 security framework is designed to fulfill the most stringent security requirements, and data protection at the IP layer is added with IPSec. However, software alone can quickly become ineffective without careful planning and assessment, effective security guidelines, enforcement, auditing, and sensible IPSec policy design and assignment.

The following security levels should be used as guidelines in implementing the level of security needed for your organization:

  • Minimal security
  • Standard security
  • High security

Minimal Security Levels

The following are the categories that provide minimal security protection.

General

Security might not be a concern for you if the computer is not used to exchange sensitive data. Windows 2000 allows you to make the system fully accessible, with no protection at all, if that is what your setup requires.

IP Security

By default, no IPSec policy is enabled. If your security plan calls for no protection at all, no administrative action is required.

Standard Security Levels

The following are the categories that provide standard security protection.

General

Most computers, especially file servers, are used to store sensitive and valuable data. You might also need to protect against accidental or deliberate changes to the way the computer is set up. The security measures must be balanced with the computers user’s need to do their work with minimal barriers to resources.

A secure system requires effort from both administrators and users. Administrators must implement IPSec policies in addition to the distributed security configurations required, and users must cultivate habits such as logging off at the end of the day and memorizing (rather than writing down) passwords.

There is no exact definition of the measures that define standard security. These can vary widely, depending on an organization’s policies and infrastructures.

IP Security

IPSec provides standard security levels with the following:

  • Default policies, and default policy properties which are secure, but do not necessarily require the highest level of security.
  • Optional, rather than required confidentiality services.

Security at this level speeds up throughput of intranet communications but still allows some level of security: integrity and authentication.

High Security Levels

The following are the categories that provide high-level security protection.

  • General

    Added precautions are needed for computers that contain an organization’s sensitive data, or are at risk for data theft or the accidental or malicious disruption of the system. Just because the data is traveling on an internal network does not mean it is safe; many attacks are from within.

    A high level of security also is appropriate for remote dial-up situations, or any public network communications.

    There is no exact definition of the measures that define a high security installation. These can vary widely, depending on an organization’s policies and infrastructures.

  • IP Security

    IPSec provides the following:

    • Default policies, such as Secure Server (Require Security), which require IPSec protection for all traffic being sent or received.
    • Strong confidentiality services to encrypt data for privacy.
    • Perfect Forward Secrecy, key lifetimes and limits, strong Diffie-Hellman groups, and extremely strong algorithms for privacy and integrity, like 3DES and SHA.

When data is extremely sensitive, you have the ability to disable communications with non-IPSec-aware computers, or in cases where the negotiation fails.


IPSec Policy Considerations

After you have defined you security plan, the following items must be taken into account when you create and assign IPSec policies:

  1. What do you want to secure? Traffic between some computers or all computers, or only certain protocols or ports?
  2. How do you want to secure it? With just integrity or also with confidentiality? And with what strength?
  3. Where do you want to secure it? Just over remote access connections, or also through the local area network?
  4. Who do you want to manage policy? Domain administrators, server administrators, or local computer administrators?
  5. Are export requirements an issue? Do you want data to be accessible from both computers that are running domestic versions of Windows 2000 and computers that are running export versions of Windows 2000?

Keep in the mind these recommendations when creating policies:

  • If you are using Windows 2000 domains for computer accounts, IPSec authentication can be accomplished by default with the built-in Kerberos v5 protocol. You do not have to deploy certificate infrastructures to secure clients, file servers, or organizational units in Active Directory.
  • Intranet communications might require lower levels of security than public network communications: no confidentiality; no tunneling; and allowance of non-secured communications. Lower levels of security speed up throughput of intranet communications, but still allow the protection services of integrity and authentication.
  • Try to use general filter addresses and the Default Response rule whenever possible, to eliminate the unnecessary creation of multiple filters to cover a group of computers. For example, where possible use Any IP address or Subnet Mask, rather than a filter for each specific source and destination IP address. Only specify an IP address or DNS name for a computer that has a static (fixed) IP address; otherwise, you must continually change your filter as the dynamic address is reassigned, or data is not secured because the address no longer matches.
  • Take advantage of the IP Filter List by adding multiple filters that group traffic from logically associated segments of your network.
  • Use negotiation policies, such as blocking or pass-through policies, to prevent communication with rogue computers and to make sure that security is not negotiated for non-essential data (such as Web TV) or computers that are not IPSec-enabled.
  • Try to use the default policies and rules whenever possible to save on administrative overhead spent on policy design. They can be modified and activated as necessary, or used as a model for custom policies.
  • In general, do not configure ESP to use No Confidentiality (a custom security method) unless you are securing traffic and you want a higher-layer protocol to handle data encryption. Otherwise, your data is not going to be encrypted.
  • Generally, IPSec rules specifying tunneling across the Internet should have a high level of security in the filter action, such as 3DES only. Because the encrypted data is traveling across a public network, confidentiality (ESP) is warranted to help prevent known key attacks. Also use short key lifetimes (less than 50 MB), to force frequent key generation. To ensure the highest level of protection, enable Perfect Forward Secrecy.

Remote Access Servers

Take into account the following for remote access servers:

  • Authentication methods must be set to use certificates and at least one computer-level certificate must be configured on each server and client, or pre-shared keys must be used. Windows 2000 domain controllers can be configured to auto-enroll domain members in a certificate authority. For more information about certificates, see the Windows 2000 online documentation.
  • In general, set the filter action to Require Security or a similar custom filter action you create. The filter action should not be configured to allow unsecured communication: Allow unsecured communication with non-IPSec-aware computers and Accept unsecured communication but always respond using IPSec should not be enabled. Otherwise, the potential for denial-of-service and other network attacks on the server is increased.
  • When you configure IP Filter Lists for VPN servers that have multiple interfaces and addresses, do not use My IP Address. IPSec attempts to enforce the filter on all interfaces. Use the specific IP address of the interface that sends and receives the traffic you are trying to secure.
  • If you want to remotely manage your VPN server, you must add a special IPSec rule to prevent TCP traffic from being blocked when it comes for the internal network. (This type of traffic is used by the remote access configuration tools in Windows 2000.)

    Add an IP Filter List to the rule which specifies an outgoing address of the corporate subnet, and an incoming address of the VPN server’s internal IP address. The protocol type in the filter should be TCP only.

    Add a filter action which enables Accept unsecured communication and Allow communication with non-IPSec-enabled computers.

Note

If the computer from which the administrator is remotely managing is not IPSec-enabled, set the filter action to Permit filter action.

SNMP

If you are running SNMP, you must add a special IPSec rule to prevent SNMP messages from being blocked. In the rule, create an IP Filter List that specifies a protocol type of UDP, and ports 161 and 162. (This requires two filters: one for each port.) The source and destination addresses should be those of the SNMP management system(s) and agent(s).

The filter action must be set to Permit filter action.

Security Gateway Filtering

Typically, security gateways are systems that serve as access points from the local area network or intranet to the external Internet. The role of a security gateway can be performed by a firewall, a proxy server, or a router.

Special filtering must be enabled to allow IPSec-secured data packets to pass through. At a minimum, the following input and output filters must be created on the security gateway’s Internet interface.

Input Filters

These are the types of input filters:

  • IP Protocol ID of 51 (0x33) for inbound IPSec Authentication Header traffic.
  • IP Protocol ID of 50 (0x32) for inbound IPSec Encapsulating Security Protocol traffic.
  • UDP port 500 (0x1F4) for inbound ISAKMP/Oakley negotiation traffic.

Output Filters

These are the types of output filters:

  • IP Protocol ID of 51 (0x33) for outbound IPSec Authentication Header traffic.
  • IP Protocol ID of 50 (0x32) for outbound IPSec Encapsulating Security Protocol traffic.
  • UDP port 500 (0x1F4) for outbound ISAKMP/Oakley negotiation traffic.

DHCP, DNS, WINS servers, or Domain Controllers

If you enable IPSec for any servers running these services, consider whether or not all their clients are IPSec-capable. You must ensure that the policies, especially the authentication and negotiation settings, are compatible. Otherwise, secure negotiation might fail, in which case, clients can’t gain access to the server (and, therefore, to network resources).

When DNS servers Are Not IPSec-Enabled

If you want to specify a computer’s DNS name in an IP Filter List specification (rather than the IP address), but your DNS servers are not IPSec-enabled, a special policy setting is required. Otherwise, IPSec and other services on the server might not be able to successfully resolve the DNS computer name to a valid IP address. The setting consists of a filter to exempt traffic between the computer and to exempt the DNS server from requiring IPSec.

To add a filter to the applicable policy and rule:

  1. In the Addressing page of the IP Filter List dialog box:
    • Set the Source Address to My IP address.
    • Set the Destination Address to the IP address of your DNS server.
    • Enable Mirrored to automatically create the inbound filter.
  2. In the Protocol page of the IP Filter List dialog box:
    • Set From this Port and To this Port to 53. (This is the common port used by most DNS servers for communication; you should set this to whatever port your DNS service has been configured to use for traffic.)

Additionally, the filter action for this rule must be set to Do not allow secure communication; no security methods should be configured. This ensures that DNS traffic is never secured with IPSec.

IPSec depends on packet filters that capture data packets mainly based on IP address. Using a DNS name in the IPSec policy instead of an IP address allows easier administration, however it should be used with caution.

This should only be done if the computer has a static IP address (one not obtained automatically from DHCP) because it is not as secure as using a specific IP address. For example, if an attacker breaks into the DNS server and changes the IP addresses associated with DNS names, IPSec might get an IP address that is different than the actual IP address, resulting in no security for the computer specified by that DNS name.


Predefined Configurations

IPSec reduces the complexity of security planning and implementation by providing predefined policies, rules, IP filter lists, and negotiation policies.


Predefined Policies

Policies are provided as a model for creating your own policies, and to eliminate the need for you to create policies except where special requirements are necessary. Three default policies are provided: Client (Respond Only), Server (Request Security), and Secure Server (Require Security). These policies can be edited to meet your requirements or used as templates for your own custom policies. The latter might be more appropriate for actual deployment. All of the predefined policies are designed for computers that are members of a Windows 2000 domain.

Client (Respond Only)

This policy is for computers that generally should not send secured data. For example, a file server that sends primarily Web TV or other multimedia transmissions usually does not require IPSec; or many intranet clients might not require IPSec except when requested by another computer. However, this policy enables the computer on which it is active to respond to requests for IPSec-secured communications. The Default Response rule is used to negotiate security with hosts that request IPSec. Only the requested protocol and port traffic for that communication request is secured.

This policy does not enable communication with computers running the Secure Server (Require Security) policy; in such cases, Server (Request Security) must be used.

Server (Request Security)

This is designed for a computer that should generally attempt to use IPSec for all outgoing communications. In addition, this policy allows the computer to accept any unsecured (clear text) traffic, but always attempts to secure any further communications by requesting security to the original sender. By default, the policy allows unsecured communication in case the other computer is not IPSec-enabled—–this means that communication with this computer might be unsecured. Communication will fall back to unsecured after a 40-second negotiation attempt.

This policy is generally appropriate for file servers that handle sensitive data that should be protected by IPSec when transmitted over the network. It is also appropriate for clients that must initiate communication to file servers that have the Secure Server (Require Security) policy assigned.

Secure Server (Require Security)

This policy is designed for a computer that is required to use secured communications for both inbound and outbound traffic, such as a corporate or departmental file server that regularly passes sensitive data to intranet clients.

This policy is configured to reject any incoming unsecured communications; outgoing traffic is never sent unsecured. Thus, this policy should be used with caution because communication is blocked if a peer is not IPSec-enabled, or fails to negotiate a common security method.

Clients that must communicate with a server running Secure Server (Require Security) must use the Server (Request Security) policy, not Client (Respond Only).


Predefined Rules

The Default Response rule is provided as a model for creating your own rules or to eliminate the need for you to create your own rules except where special requirements are necessary.

The Default Response rule is added to each new policy you create, but not automatically activated unless you chose to do so when using the IP Security Policy wizard. This rule is appropriate for any computer, client or server that does not generally need security; but the computer must be able to securely respond when another computer requests secured communication.

The Security Methods, Authentication Methods, and Connection Type can be modified to meet your requirements. However, enabling communication with non-IPSec–aware computers is not available in this rule, as the idea of the Default Rule is to block unsecured communications.


Planning for Workgroup, End-to-End Communications

In a small office, computers are often connected by a peer-to-peer workgroup, because the overhead of a domain is not necessary a result of the smaller number of computers. Figure 9.13 shows an example of end-to-end security.

Figure 9.13 Workgroup: End-to-End Security

Policies

The following are the types of policies to consider.

File Server: Server (Request Security)

Server (Request Security) must be assigned to ensure that all communication sent by the File Server is secured.

Because this is a Workgroup, the rules in Server (Request Security) must be modified to use the pre-shared key method for authentication. The default method of Kerberos v5 authentication is only available with a domain-based architecture, as are certificates.

Clients: Client (Respond Only)

Client (Respond Only) must be assigned to ensure the clients can communicate with the File Server. Security between clients is not used in this example. If this is also required, Server (Request Security) should be used instead. Again, the authentication method must be modified to pre-shared key and the pre-shared key must be the same key you chose for the File Server policy.


Planning for Intranet Domain, End-to-End Communications

Prior to the availability of IPSec, providing security for groups regularly working with highly sensitive information required segmenting the intranet—having groups of computers on different, physical segments prevented security violations.

With IPSec, you can have groups of secure computers within the same physical intranet. In this scenario, it is assumed that for the majority of the time, most clients do not need to communicate securely. However, in this scenario, a group of file servers store sensitive information for which intranet clients require access. During actual deployments, this might be a domain in which clients and servers regularly work with highly sensitive data, such as in a finance department. (See the example in Figure 9.14.) All computers have computer accounts in Active Directory.

Figure 9.14 An Intranet Domain with End-to-End Communications

The computers are grouped into Active Directory OUs for security reasons: to allow the assignment of appropriate IPSec policies depending on the function of the computer or computers:

  • A few servers have extremely sensitive information; these are members of the Highest Security Servers OU.
  • However, most of the servers can fall back to clear if necessary to allow non-Windows 2000 computers in the domain to communicate successfully with the servers; these are members of the Secure Servers OU.
  • The clients require some level of IPSec, in order to communicate with both sets of servers.

Any Kerberos v5 authentication exchanges between the clients and the domain controller are already encrypted, and the IPSec policy download from Active Directory to the member computers is protected by LDAP security, so a high level of security between the clients and the domain controller is unnecessary. However, user permissions are still a necessary part of using security to protect access to the file shares available on any of the Highest Security of Very Secure Servers; IPSec secures only the network level traffic, so that potential sniffers and attackers cannot modify or interpret the data, but does not secure whether a particular user has access permissions to a server share. For more information about user permissions, Kerberos v5 authentication, or LDAP, see chapters under Part 3, “Distributed Security” in the Windows 2000 Distributed Systems Guide.

Grouping computers into Organizational Units (OUs) enables the assignment of IPSec policies to only those that require IPSec; and the assignments of the appropriate level of IPSec to avoid excessive overhead. In this scenario, Active Directory stores the IPSec policies for all computers. Policy precedence is based on the Group Policy inheritance model. The policy assigned to an OU overrides a domain-level policy; therefore, the computers inherit the policy assigned to the OU of which they are members. Computers that are not members of an OU are automatically placed in the default Active Directory group (Computers). These domain members inherit the domain-level policy; including the domain controller itself, which like all computers is a member of the Computers group.

Policies Required

The following are the required policies.

Domain Computers Group: Client (Respond Only) (Modified)

Any computers that are part of the Computers domain group inherit the IPSec policy assigned to the domain security policy. Because these computers need to communicate with members of the Secure Servers OU and the Highest Security Servers OU, a modified version of the Client (Respond Only) policy is assigned to the domain group security policy.

A rule is added to the Client (Respond Only) policy, which enables these computers to initiate security. This is required in order to communicate with the Highest Security Servers OU, which is running the Secure Server (Require Security) policy. Normally, Client (Respond Only) only listens for requests to negotiate; however, Secure Server (Require Security) requires the other computer to initiate the request for security. The rule settings consist of the following:

  • IP Filter List, which covers traffic to and from all computers in the Finance domain.
  • Filter Action: Request Security (Optional).
  • Authentication Method: Kerberos v5 authentication (default).
  • Connection Type: All local area network connections.
  • Tunnel Settings: None (default).

This rule ensures that when a member of the domain Computers group must communicate with a member of the Highest Security Servers OU, these computers are able to initiate secure communication.

However, the default rules in the policy ensure that, for traffic between the Secure Servers OU and the domain Computer group, bandwidth is not used to negotiate security unless secure communications are requested.

Secure Servers OU: Server (Request Security)

Members of this OU try to communicate securely, and require the ability to initiate security in order to communicate with members of the Highest Security Servers OU. Because of this latter requirement, Client (Respond Only) does not work because it does not handle the initiation of security, only the response. Server (Request Security) allows these computers to initiate when necessary, but also allows the computers to continue communication with non-Windows 2000 legacy systems that might be part of the domain.

Highest Security Servers OU: Secure Server (Require Security)

File servers that are members of this OU want to lock out any computer that does not initiate and successfully negotiate security. These are servers that contain highly sensitive data. The Secure Server (Require Security) policy is applied to the Secure Servers OU, to ensure the following:

  • Communications initiated with normal traffic (without security) are never accepted (with the exception of the traffic types discussed in the earlier section “Security Gateway Filtering” such as the Kerberos v5 protocol).
  • Communication never falls back to normal traffic if negotiations fail or if the non-Windows 2000 computer is not IPSec-capable.

Even communication with the domain controller is negotiated and secured. Because of the strictness of this policy, you might have to add exemptions for DNS and SNMP traffic. For information about altering IPSec policy, see the “IPSec Policy Considerations” section later in this chapter.


Planning for Remote Access Communications

Secured remote communication is achieved by a combination of L2TP and IPSec: L2TP is used to build the tunnel; IPSec secures the data. The L2TP connection properties must be configured to use IPSec for security.

Roving Clients

A common requirement is secure communications between remote clients and the enterprise network. In this scenario, the remote client represents a roving user; in actual deployment this could be a salesman who travels frequently but needs to gain regular access to network resources and information; or an employee who is working from a home office. Figure 9.15 shows a gateway server that provides edge security for the enterprise intranet.

Figure 9.15 L2TP/IPSec with Remote Access Clients

The remote client might or might not go through an Internet Service Provider (ISP); an ISP is shown here to represent the path of communication the client uses to gain access to the gateway. The tunnel runs from the remote client to the gateway because it is used only to protect communication through the Internet. However, the Virtual Private Network (VPN) extends from the remote client to the enterprise intranet; to the remote client, it is as if there were a direct connection to the network clients and servers.

Branch Offices

A large enterprise often has multiple sites that need to communicate, such as a corporate office in New York and a sales office in Washington. As in the previous scenario, L2TP is combined with IPSec to provide simple, efficient way to build and protect the necessary tunnel across the Internet between the sites. In Figure 9.16, routers provide edge security and a communication route between the two sites.

Figure 9.16 L2TP/IPSec Router-to-Router Tunneling

The routers can have a lease line, demand dial, or other type of connection. The tunnel runs between the routers only because it is used to protect communication through the Internet. However, the VPN extends between the intranet computers at each site that are exchanging data.

Securing Remote Communication

Secure remote communication is achieved by combining the Layer 2 Tunneling Protocol (L2TP) with the security layer of IPSec: L2TP is used to build the tunnel; IPSec secures the data. Instead of configuring IPSec policies, these remote communication scenarios require configuration of the L2TP security properties.

When L2TP is configured to use IPSec for security:

  • The required IP Filter and Filter Action lists are dynamically set in the IPSec Policy Agent for the duration of the connection.
  • Authentication is determined by L2TP, which requires a public key certificate.
  • Default key exchange settings are in effect.

The level of IP security used for the duration of the connection is dependent upon the L2TP security configuration:

No Encryption

IPSec does not negotiate for security.

Optional Encryption

  • If the other computer requests or requires secured communication, IPSec offers security levels, ranging from ESP/3DES to AH/MD5, (including export algorithms).
  • Session key Perfect Forward Secrecy is not enabled. However, it will be if the other computer requests it.
  • Fallback to unsecured communication is allowed.

Required Encryption

The computer requires secured communication. The set of security offers is identical to that of Optional Encryption, with the exception that fallback to unsecured communication is not allowed.

For more information about configuring L2TP, see the “Virtual Private Networking” and “Remote Access Server” chapters in the Windows 2000 Internetworking Guide.


Planning for IPSec-Tunneled Communications

To ensure interoperability, IPSec has the ability to directly perform tunneling services in cases where one or all of the computers is not L2TP-capable. To enable IPSec tunneling, a physical interface and a static IP address for each computer is required (the routing tables must be updated with these IP addresses). The routers have tunneling rules in an IPSec policy, which is essentially the expressional equivalent of two static routes. Figure 9.17 shows IPSec-tunneled communications.

Figure 9.17 IPSec Wide Area Network (WAN) Tunneling

Figure 9.17 is similar to Figure 9.16, with a few important exceptions:

  • Each router has a physical interface for the connection to the Internet. The IP address for each external interface is a publicly routable IP address.
  • The IPSec policies specify tunnel endpoints in their rules (referred to as tunneling rules):
    • Traffic from the Washington subnet to the New York subnet, to be tunneled through to the New York router.
    • Traffic from the New York subnet to the Washington subnet, to be tunneled through to the Washington router.
  • Each tunneling rule uses the ESP protocol to provide both the tunnel and strong encryption. See “Tunneling” earlier in this chapter.

You must build a custom policy to avoid lengthy editing of predefined policies. However, you should use the Require Security filter action to ensure security is always initiated between the routers and never falls back to normal traffic (unsecured).

Policy Requirements: Washington Router

An outbound rule with the following settings should be added.

Filter

This filter secures traffic outbound from the Washington intranet going to the New York intranet:

  • Source: 192.168.0.0 and a subnet mask of 255.255.0.0.
  • Destination: 172.16.0.0, 255.255.0.0.
  • Mirror: Not enabled (this is not supported for tunnel-based rules).

Tunnel Setting

Because static IP addresses are required, you must chose Specify a tunnel endpoint by IP Address and enter the address of the New York router, which is 172.31.1.1

To secure traffic outbound from the New York intranet and inbound to the Washington intranet, an inbound rule with the following settings should be added to the policy filter:

  • Source: 172.16.0.0 and a subnet mask of 255.255.0.0.
  • Destination: 192.168.0.0 and a subnet mask of 255.255.0.0.
  • Mirror: Not enabled.

Tunnel Setting

Because static IP addresses are required, you must chose Specify a tunnel endpoint by IP Address and enter the address of the Washington router as follows:

192.250.1.1

Authentication

For both rules this must be pre-shared key or certificates. Certificates are recommended. With a pre-shared key, you risk the value of the key becoming known through accidental disclosure because both sides must use the same pre-shared key value.

Filter Action

The filter action should be based on your security plan, and how it outlines the level of security required for this type of scenario. The only requirement is that the negotiation policies must be the same for both the inbound and outbound rules or communication fails. Selecting the Require Security filter action is recommended because it provides the high level of security required for this situation. However, it is also recommended that the security methods list be reduced to only ESPS-3DES-SHA1 because only this level ensures adequate encryption levels across the public Internet.


Troubleshooting

This section contains methods for determining the cause of secured communication problems, as well as tools that can be used to verify secured communications during testing of your deployment scenarios. Run normal workloads on applications during your testing to gain realistic feedback. During initial tests, if you want to view the packet contents with Network Monitor or a sniffer, use the security method level of Medium or a custom level of AH. ESP prevents viewing of the packet, because of the encryption.

Note

Failure in core networking services, such as DHCP, DNS, and WINS, can cause unpredictable IPSec failures.


General Troubleshooting

The following are possible reasons for secured communication failures and suggested resolutions for these failures.

Remote Communications Fail

If you are a remote client, and only secured communication attempts are failing, review the section “Security Planning Best Practices” earlier in this chapter and its remote communications scenarios to verify your authentication method is correct, and you have compatible security methods with the remote access server.

Intranet Communications Fail

If two computers have been communicating successfully and secured communication between them suddenly fails, do the following:

  • Ping the other computer to verify the computer is still on the network. If the first ping times out, wait for 5-10 seconds, and then ping a second time. If you receive another time-out message, check to see if the list of acceptable security methods in your filter action has changed since the last communication with that computer. The old security associations that are based on previous security methods might still be in effect. If so, try the next step.
  • Restart the policy agent. This clears up any old security associations. For information about how to restart the policy agent, see “Restarting the Policy Agent” at the end of this troubleshooting section.

Other Causes of Failure

Try a policy integrity check to verify that changes made to any policy settings have been updated in Active Directory or registry. See “Testing Policy Integrity” later in this section.

If you have removed an existing computer from a domain or have changed to using local policy instead of Active Directory policy, you might have to restart the policy agent. Otherwise, the policy agent continues to attempt to reach Active Directory and does not use registry policy.

Multihomed computers have multiple default routes, which might cause problems.

To specify a default route

  1. At a command prompt, type:

    route print

    and press ENTER.

  2. Verify whether more than one route line has a Destination of 0.0.0.0 and whether there is more than one route line with the lowest Metric (generally 1).
  3. If either is true, delete one of the default routes or verify that one of the default routes has a Metric value that is lower than all the others.


Solving Basic IPSec Problems

These are some methods for resolving basic IPSec-related problems.

Policy Agent Is Retrieving Policy from the Wrong Place

Follow these steps to correct the problem:

  1. Examine the policy agent log. This might require turning on the registry settings for the log.
  2. View the %Windir%\IPSecPA.log in a text editor. If examination of the last few lines doesn’t indicate the policy source, proceed to the next step.
  3. At the command prompt, type:
findstr

This log indicates whether you are using Active Directory Group Policy or local policy.

  1. Run Event Viewer, and examine the System Log. If you are using Active Directory policy, polling events should display.
  2. If you are using domain policy but want to use local policy, leave the domain and reboot, or have the applicable Group Policy object moved in the directory so you don’t receive domain policy.

Policies Don’t Match

Follow these steps to correct the problem:

  1. Run Event Viewer, and examine the Security Log. Recent events include attempts at Oakley negotiation with a description of their success or failure.
  2. Check the security log on the computer specified by the IP address in the log message.
  3. Determine the cause of policy mismatch and fix it:
    • Verify that authentication methods are compatible.
    • Verify that there is at least one compatible security method.

Only Soft SAs Are Established

If soft SAs are preventing standard SAs, do the following:

  1. Run Ipsecmon.exe on one of the peers.

    If an SA exists between the two computers without “None” listed as the security setting, this indicates a soft SA. The soft SA remains as long as traffic is regularly sent between the computers.

    To prevent this, stop all traffic until the SA times out (usually five minutes), verify that the SA is gone in IPSecMon.exe, and then start traffic again. A hard SA should be established if policies are compatible.

  2. Restart the policy agent or wait until five minutes after traffic has stopped for the soft SA to expire.

“Bad SPI” Messages in Event Viewer

This message appears if a key lifetime value is set too low or if the SA has expired but the sender continues to transmit data to the receiver. To verify and correct, follow this procedure:

  1. Run IPSecmon.exe.
  2. Examine the number of re-keys.

    If the number of re-keys is very large compared to the amount of time the connections have been active, set the key lifetimes in the policy to be longer. Good values for high-traffic Ethernet connections are greater than 50 MB and greater than five minutes.

This might not entirely eliminate “Bad SPI” messages, but it should significantly reduce their occurrence.


Verifying Secured Communications

You can use the following tools to determine if IPSec is active and secured communication is successful.

Using Ping to Verify a Valid Network Connection

This procedure determines whether standard, unsecured communication can take place.

At the command prompt, type:

PING IP Address

where IP Address is the address of the computer with which you are trying to communicate.

You should receive four replies to the ping. This verifies that you can communicate with your partner. However, if one of the computers is using the Secure Server (Require Security) policy and the other does not have an appropriate policy (such as Server (Request Security)) to deal with Secure Server (Require Security), four Destination Computer Unreachable messages are received.

If you are not receiving a response from the ping command, see the chapter “TCP/IP Troubleshooting” in this book for more information about determining the problem.

Verifying Policy Has Been Assigned

Use the following tools to verify that policy has been assigned:

  1. IPSec Monitor

    When IPSec Monitor opens, there is a message in the lower-right corner that indicates whether IPSec is enabled on the computer. For IPSec to be enabled, a policy must be assigned. However, no policies are listed in the IPSec Monitor Security Association list unless an SA with another computer is currently active.

  2. Event Viewer

    The IPSec Policy Agent makes entries to the System Log to indicate the source of its policy. It also indicates the polling interval, as specified by the active policy, for checking policy changes in Active Directory. Administrators who edit the active IPSec policy on the local computer cause the changes to take effect immediately.

    You can also see whether the computer is using local policy or policy from Active Directory by viewing the Event Log. Specifically, view the System Log informational entry by the IPSec Policy Agent.

  3. TCP/IP Properties

    By displaying the properties for the Internet Protocol (TCP/IP), you can see the active IPSec policy. If the computer is running local IPSec policy, the name is displayed in an editable form. If the computer is running policy assigned through Active Directory Group Policy, the name and dialog is displayed as grayed out and is not editable. For instructions about displaying TCP/IP properties, see Windows 2000 online Help.

Using PING to Test Policy Assignment

When using the Server (Request Security) or Secure Server (Require Security) policies, the ICMP packet sent by the PING command matches the IP Filter List in these policies, and IPSec attempts to secure the PING. However, this process takes longer than PING normally waits for a response, which results in an erroneous Destination Unreachable message.

IPSec Monitor can be used to verify the results of PING: a security association is listed whenever PING is successful, regardless of whether it was a hard or a soft security association.

The following results are expected when PING is executed on a computer with a predefined IPSec policy.

Client (Respond Only)

  • Action: Ping a non-IPSec–enabled computer.
  • Result: Normal PING results. Client (Respond Only) only negotiates security in response to security requests.
  • Action: Ping an IPSec-enabled computer.
  • Result: Dependent on the other computer’s IPSec policy. If the other computer is using Server (Request Security), the computer tries to respond securely to the ping. If the security negotiation can be done in time, the ping is successful.

    If the other computer is using Secure Server (Require Security), it discards the packets, and you receive a “Request Timed Out” message. This is because Client (Respond Only) only responds to security requests, not initiate them, and Secure Server (Require Security) requires the other computer to initiate security.

Server (Request Security)

  • Action: Ping a non-IPSec–enabled computer.
  • Result: Initially, you receive a ”Destination Unreachable” message while negotiation for security is attempted. However, after two seconds a soft security association generally is established, and ping traffic succeeds.

Note

The actual time might be longer if you used a DNS name for the ping command because the DNS resolution requires a soft association to be established with the DNS server(s) first.

The default settings of this policy allow communication to fall back to clear if the other computer does not respond, and the ping succeeds after a soft association is created.

  • Action: Ping an IPSec-enabled computer.
  • Result: Initially, you receive a “Destination Unreachable” message while negotiation for security is attempted. However, after two seconds a soft security association generally is established, and ping traffic succeeds.

Note

The actual time might be longer if you used a DNS name for the ping command because the DNS resolution requires a soft association to be established with the DNS server(s) first.

If negotiations fail, IPSec might install a blocking filter for that destination IP address. In that case, all traffic is blocked for five minutes, during which time ping returns time outs. However, the default settings of this policy allow communication to fall back to clear if the other computer does not respond, and ping succeeds after a soft association is created.

Secure Server (Require Security)

In both of the instances that have been discussed for Secure Server (Require Security), ping is not able to resolve the DNS name and fails unless the DNS servers are IPSec-enabled or there are exemptions in IPSec policy for DNS traffic.

  • Action: Ping a non-IPSec–enabled computer.
  • Result: Ping might not be able to resolve the DNS name and in that case returns an “Unknown computer [computer]” message.

Note

If you activated the Secure Server (Require Security) policy and the DNS name in the local DNS cache immediately prior to the ping, the name resolves and the ping returns immediately with four “Destination Computer Unreachable” messages.

  • Action: Ping an IPSec-enabled computer.
  • Result: Again, ping might not be able to resolve the DNS name. However, If the DNS name can be resolved or if you ping by IP address, PING immediately returns a "Destination Unreachable" message while negotiations for secure communication begin. If it succeeds, secure ping traffic succeeds after two to four seconds. If it fails, IPSec installs a blocking filter for that destination IP address and all traffic is blocked for five minutes, during which time ping returns time outs.


The IPSec Monitoring Tool

The IPSec monitor can confirm whether your secured communications are successful, by displaying the active security associations on local or remote computers.

For example, you can use IPSec Monitor to determine whether there has been a pattern of authentication or security association failures, possibly indicating incompatible security policy settings.

The IPSec monitor can be run on the local computer or it can be run remotely if you have a network connection to the remote computer.

To start the IPSec monitor

  1. Click Start, and then click Run.
  2. Type:

    ipsecmon computername.

  3. Use the Options button to set the refresh rate.

An entry is displayed for each active security association. The information contained in each entry includes the name of the active IPSec policy, the active filter action and IP Filter List (including details of the active filter), and the tunnel endpoint (if one was specified).

It can also provide statistics to aid in performance tuning and troubleshooting, including the following statistics:

  • The number and type of active security associations.
  • The total number of master and session keys (Main and Quick modes). Successful IPSec security associations initially cause one master key and one session key. Subsequent key regenerations are shown as additional session keys.
  • The total number of confidential (ESP) or authenticated (ESP or AH) bytes sent or received.

Note

Because ESP provides authenticity and confidentiality, both counters are incremented.

  • The total number of soft associations.

The refresh rate is the only configurable option. By default, the statistics update every 15 seconds. The statistics are accumulated with each communication that uses IPSec.


Event Viewer and the Security Audit Log

An event is any significant occurrence in the system that requires notification. Event logging starts automatically each time you start Windows 2000. With Event Viewer, you can view the System Log for troubleshooting problems with the policy agent, and the Security Log for Oakley informational messages, and messages regarding failed IPSec communications.

For example, to determine why one of the services is not running, you can use filtering on the System Log to only display messages pertaining to the Policy Agent. You can also choose to only display a particular type of Policy Agent event message. You can use the same filtering on the Security Log for Oakley messages.

  1. Start Event Viewer by choosing Computer Management from the Administrative Tools menu.
  2. Expand the System Tools folder.
  3. Expand the Event Viewer folder to display the System and Security logs.
  4. Use the Action menu to apply filtering.


Event Log Messages

The following are common IPSec-related messages that might appear in Event Viewer.

System Log Messages

There are two messages:

System Log Informational Event 279

  • Source: Policy Agent
  • Category: None

Indicates whether an IPSec policy is in effect on the computer, the source of the IPSec policy (local, domain), and Active Directory polling interval (if policy source is domain).

Also indicates that a change to an IPSec policy has been detected in the policy source. In this case, the text shows as “Updating IPSec Policy.”

System Log Error Event 284

  • Source: Policy Agent
  • Category: None

Indicates the policy agent was unable to contact Active Directory for the domain in which the computer is a member.

Security Log Messages

This log contains messages from ISAKMP/Oakley.

Security Log Success Audit Event 541

  • Source: Security
  • Category: Logon/Logoff

Indicates an IPSec “hard” security association has been established. (Soft security associations are not audited).

Security Log Success Audit Event 542

  • Source: Security
  • Category: Logon/Logoff

Indicates an IPSec “hard” or “soft” security association has ended. (A known issue causes the deletion event of the soft security association to be audited).

Application Log

This log contains messages from ISAKMP/Oakley.

Note

The following messages are indicators that a domestic version of Windows 2000 has attempted to negotiate higher security than an export client can support.

Application Warning Event 541

  • Source: Oakley
  • Category: None

Indicates the export client can not generate domestic-strength key material; the resulting negotiation agrees only on export strength key material.

Application Warning Event 542

  • Source: Oakley
  • Category: None

Indicates the export client can not perform encryption stronger than 40-bit DES; the resulting negotiation agrees only on 40-bit DES (provided the other computer can do 40-bit DES).


Network Monitor

The Windows 2000 Network Monitor (Netmon) can be used to view the AH and ESP security protocol transmissions. Netmon captures information transferred over a network at any given time.

To ease the troubleshooting process, an interface was developed whereby parsers based on Netmon could obtain local packets prior to encryption and after decryption to display in the Netmon application. Note that this functionality is limited to Netmon drivers running locally.

Network Monitor displays packets secured with AH as a TCP, ICMP or UDP packet. When you open the packet in Network Monitor, the AH header is displayed. Because ESP encrypts the original header, Network Monitor displays packets secured with ESP as ESP packets. The actual data in the ESP packet is not readable because of the encryption.

In the Next Header field, ESP is displayed as IP protocol number 50 (decimal), and AH is displayed as 51 (decimal). ISAKMP/Oakley is displayed as UDP port number 500 (decimal).

Configure Network Monitor with the addresses of the source and destination computers with which you want to communicate. For example, to filter IP secured traffic between Computer A with IP address 172.16.0.10 and Computer B with IP address 172.16.0.5, specify that address pair in a capture filter.

Netmon v2.0 contains basic interpreters for IPSec and ISAKMP packets. If IPSec is encrypting the packets, then the contents are not visible, but the packet itself is visible. You can use your own network sniffer, however, it might not be able to interpret the IPSec-specific portions of the IP packets. For installation instructions for NetMon, see Windows 2000 Help.


Using Network Monitor to Capture Traffic

Use the following procedure to capture network traffic.

To capture network traffic

  1. Click Start, point to Programs, then Administrative Tools, then Network Monitor.
  2. Click Netmon.
  3. From the Capture menu, click Filter.

    The Capture Filter dialog box appears, under (Address Pairs), INCLUDE *ANY<-->*ANY should be selected.

  4. Click Edit.
  5. Under Station 1 list, select Your Computer Name, Your IP Address.
  6. Under Direction, select <-->, Under Station 2 list select *ANY, and then click OK.

    In the Capture Filter dialog box under (Address Pairs), INCLUDE Your Computer Name (IP) <--> *ANY should be displayed.

  7. Click OK.

    You can save the captured traffic to view later.


Capturing Unsecured Traffic

Use the following procedure to capture unsecured traffic.

To generate and capture network traffic

  1. Start Network Monitor.
  2. From the Capture menu, click Start.
  3. Open a command prompt window.
  4. Type:
PING IP Address

where IP address is the address of the computer to which you are trying to communicate.

  1. Return to Network Monitor.
  2. From the Capture menu, click Stop, then View.

    You should have either 8 or 16 frames captured. If both you and your partner did a PING at the same time, you would have 16 frames.

  3. Double-click the first ICMP frame in the Summary pane.

    You now have a Detail pane in the center and a Hex pane at the bottom. In the Detail pane there are four entries: Frame, Ethernet, IP, and ICMP. These are the different parts of the overall frame sent during a PING.

  4. From the Detail pane, double-click the IP entry, and scroll to the bottom.

    There the Source Address, Destination Address and 40 bytes of data are displayed.

  5. Click IP: Data: Number of data bytes remaining = xxxx.

In the Hex pane on the bottom, a hex dump and the actual data that was sent are displayed.


Capturing Packets Secured with Authentication Header

Use the following procedure to capture packets secured with an authentication header.

To capture packets

  1. Start Network Monitor.
  2. From the Capture menu, click Filter.
  3. Verify the filter INCLUDE Your Computer Name (IP) <--> *ANY, is still configured, and then click OK. Otherwise see the procedure “Using Network Monitor to capture traffic,” to configure the filter.
  4. From the Capture menu, click Start.
  5. Open a command prompt window.
  6. Type:

    PING IP Address

    where IP address is the address of the computer to which you are trying to communicate. You might have to repeat this step because PING has a very short time out and there is some delay in establishing the IPSec association between the two computers.

  7. Return to Network Monitor.
  8. From the Capture menu, click Stop, then View.

    In the frame, the Next Header field display 51, indicated a packet secured by AH.

  9. Double-click the first AH frame.

    Three entries in the Detail pane are displayed: Frame, Ethernet, and IP.

  10. In the Detail Pane, expand the IP entry.
  11. Scroll to the bottom of the Detail Pane, and click on IP Data: Number of data bytes remaining = xxxx.

IPSec has created a hash of the ICMP and Data fields of the frame. By doing this, IPSec prevents someone from capturing the data, altering it and re-sending the bad data. Looking at the Hex pane, you can still see the 32 characters sent in the PING. By configuring an AH security method, you ensure authentication but do not encrypt the data in the packet. AH ensures the packet data, as well as most of the IP header, is not modified in transit.


Capturing Packets Secured with ESP

Use the following procedure to capture packets secured with ESP.

To configure IP Security for ESP security method

  1. Start Network Monitor.
  2. From the Capture menu, click Filter.
  3. Verify the filter INCLUDE Your Computer Name (IP) <--> *ANY, is still configured, and then click OK. Otherwise, see the procedure “Using Network Monitor to Capture Traffic,” to configure the filter.
  4. From the Capture menu, click Start.
  5. Open a command prompt window.
  6. Type:

    PING IP Address

    where IP address is the address of the computer to which you are trying to communicate. You might have to repeat this step because PING has a very short time out and there is some delay in establishing the IPSec association between the two computers.

  7. Return to Network Monitor.
  8. From the Capture menu, click Stop, and then click View.

    In the frame, the Next Header field is displayed as 50, indicating a packet secured by ESP.

  9. Double-click the first ESP frame.

    In the Detail pane, four entries are displayed: Frame, Ethernet, IP, and ESP. IPSec has created a hash of the ICMP and Data fields of the frame.

  10. In the Detail pane, double-click the IP entry, and scroll to the bottom of the Detail pane.
  11. Double-click the IP: Data: Number of data bytes remaining = xxxx line.

    There, 76 bytes of data are displayed.

To see that the data has been encrypted, view the Hex pane. IPSec has created a hash of the ICMP and Data fields of the frame, and encrypted the data fields of the frame.


Only Secured Communication Fails

These are possible reasons for a failure in secured communication.

Broken Links in Policy Components

Because Active Directory treats the last information saved as current, if multiple administrators are editing a policy it is possible to break the links between policy components. For example:

  • PolicyA uses FilterA.
  • PolicyB uses FilterB.

    This means that FilterA has a link to PolicyA, and FilterB links to PolicyB.

  • Bob edits PolicyA, and adds a rule that uses FilterC.
  • At the same time, Alice edits PolicyB from a different location, and adds a rule that also uses FilterC.

    If both save the changes simultaneously, it is possible for FilterC to link to both PolicyA and PolicyB. Because that is unlikely, if PolicyA is saved last, it overwrites the link from FilterC to PolicyB. FilterC only links to PolicyA. This causes problems when FilterC is modified. Only PolicyA picks up the new changes; PolicyB does not.

The policy integrity check eliminates this problem by verifying the links in all IPSec policies. It is a good idea to run the integrity check after making modifications to a policy.

To check policy integrity

  1. Start the IP Security Management snap-in.
  2. Click Action.
  3. Point to Task, and click policy integrity check.

All the IPSec policies listed in the console are checked. If any filters or settings are invalid, an error message is displayed.

Soft SAs Are Preventing Hard SAs

If Soft SAs are preventing standard SAs (hard), run IPSecMon on one of the peers. If an SA exists between the two computers with “None” listed as the security setting, this indicates a soft SA. This soft SA remains on that computer as long as traffic is regularly sent between the two computers. To prevent this, follow this procedure:

  1. Stop all traffic until the SA times out (usually five minutes), verify the SA is gone in IPSecMon, and start traffic again.

    A hard SA should be established if policies are compatible.

  2. Restart the policy agent. (SAs cannot be deleted manually. To delete an SA you must restart the policy agent.)

Restarting the Policy Agent

You can use System Services Management to start, stop, or restart the policy agent. This might be necessary to clear up old SAs or soft associations or to force a refresh of policy from Active Directory to domain clients.

Use Event Viewer to determine possible causes of failure if the policy agent does not start.

To restart the IPSec Policy Agent

  1. Start the System Service Management snap-in.
  2. In the System Service Management results pane, double-click IPSec Policy Agent.
  3. Click Restart.

The restarting of the policy agent also forces the restarting of the IPSec driver.

Reinstalling IPSec Components

If the files necessary for IPSec components, such as ISAKMP/Oakley, the IPSec Policy Agent, or the IPSec Driver have been removed or deleted, you can reinstall the IPSec components by removing and reinstalling TCP/IP. The IPSec components are reinstalled as part of the Internet Protocol installation.


Simple Network Management Protocol Service

To answer the challenges of designing an effective network management platform for heterogeneous Transmission Control Protocol/Internet Protocol (TCP/IP)-based networks, the Simple Network Management Protocol (SNMP) was defined in 1988 and approved as an Internet standard in 1990 by the Internet Activities Board (IAB). SNMP service provides the ability to monitor and communicate status information between a variety of hosts. This chapter provides an administrator with the background and conceptual material necessary to understand and implement SNMP within the context of Microsoft® Windows® 2000.

In This Chapter

What is SNMP?

Overview of SNMP

Windows 2000 SNMP Agent Properties

Security

Architecture of Windows 2000 SNMP

Special Considerations in Implementing SNMP

SNMP Tools

Registry Settings

Troubleshooting SNMP

Related Chapters in the Resource Kit

  • For information about securing SNMP messages, see “Internet Protocol Security” in this book.
  • For more information about viewing counters related to SNMP-managed objects, see the section “Managing DHCP, DNS, WINS, and IIS” in this chapter.

Additional Resources

For more information about SNMP, see the following books:

  • Windows NT SNMP by J. D. Murray, 1998, O’Reilly & Associates.
  • Understanding SNMP MIBs by D. Perkins and E. McGinnis, 1997, Prentice Hall PTR.
  • The Simple Book: An Introduction to Management of TCP/IP-based Internets by M. T. Rose, 1994, Prentice-Hall, Inc.
  • SNMP Versions 1 & 2: Simple Network Management Protocol Theory and Practice by M. Hein and D. Griffiths, 1995, International Thomson Computer Press.
  • SNMP, SNMPv2 and CMIP: The Practical Guide to Network-Management Standards by W. Stallings, 1993, Addison-Wesley Publishing Company.

  • For additional information about the Windows 2000 implementation of SNMP, see the Microsoft Knowledge Base, available through the Microsoft Support Online Web site at http://support.microsoft.com/support/. To take advantage of this repository of technical information, you must be a registered user. If you attempt to view a Knowledge Base article and you either are not registered or are not recognized by the system, you will be directed to a registration page where you can register for this free service or retrieve your online profile.

For information about installing and configuring Microsoft SNMP Service, see Microsoft Windows 2000 Server Help.


What is SNMP?

SNMP is a network management standard widely used with TCP/IP networks and, more recently, with Internet Packet Exchange (IPX) networks. The SNMP standard includes the following Request for Comment (RFC)-compliant constructs:

  • The Management Information Base II (MIB II), RFC 1213. A set of manageable objects that represent various types of information about a host, such as the number of active sessions or the available hard drive space.
  • The Structure for Management Information (SMI). A separate Internet RFC that describes the object syntax for specifying how MIB data can be referenced and stored.
  • Simple Network Management Protocol (SNMP), RFC 1157. A standard that defines how communication occurs between SNMP-capable devices and the types of messages that are allowed.

SNMP provides a method of managing network nodes (servers, workstations, routers, bridges, and hubs) from a centrally-located host. SNMP performs its management services by using a distributed architecture of management systems and agents. As shown in Figure 13.1, the centrally-located host, which is running network management software, is referred to as an SNMP management system or SNMP manager. Managed network nodes are referred to as SNMP agents.

Figure 13.1 Distributed Architecture of SNMP

Network management is critical for resource management and auditing. SNMP can be used in several ways.

  • Configure remote devices

    You can configure information so that it can be sent to each networked host from the management system.

  • Monitor network performance

    You can track the speed of processing and network throughput and collect information about the success of data transmissions.

  • Detect network faults or inappropriate access

    You can configure trigger alarms on network devices that alert you to the occurrence of specific events. When an alarm is triggered, the device forwards an event message to the management system. Common types of events for which an alarm can be configured include:

    • The shut down or restart of a device
    • The detection of a link failure on a router
    • Inappropriate access
  • Audit network usage

    You can monitor overall network usage to identify user or group access or types of usage for network devices or services. This information can then be used to generate direct billing of individual or group accounts or to justify current network costs or planned expenditures.

The Windows 2000 implementation of SNMP is a 32 - bit service that supports computers that are running TCP/IP and IPX protocols. It is an optional service on Microsoft® Windows® 2000 Professional, and can be installed after TCP/IP and IPX have been successfully configured. Windows 2000 implements SNMP versions 1 and 2C. These versions are based on industry standards that define how network management information is structured, stored, and communicated between agents and management systems for TCP/IP-based networks.

The Windows 2000 SNMP Service provides an agent that allows centralized, remote management of computers that are running the following software:

  • Microsoft® Windows® 2000 Server
  • Windows 2000 Professional
  • Windows 2000 and Microsoft® Windows NT® – based Windows Internet Naming Service (WINS)
  • Windows 2000 and Windows NT – based Dynamic Host Configuration Protocol (DHCP)
  • Windows 2000 and Windows NT – based Microsoft® Internet Information Service (IIS)
  • Microsoft® LAN Manager

To use the information that Windows 2000 SNMP Service provides, you must have at least one centrally-located host that is running an SNMP management software application. The Windows 2000 SNMP Service provides only the SNMP agent; it does not currently include SNMP management software. You can use Hewlett Packard Openview Network Manager, IBM NetView, or some other third-party SNMP management software application on the host that you want to act as the management system. Alternatively, you can develop your own SNMP management software application by using the two application programming interfaces (APIs) that are provided with Windows 2000:

  • WinSMNP API (WinSNMP.dll), which provides a set of functions for encoding, decoding, sending and receiving SNMP messages.
  • Management API (Mgmtapi.dll), which provides a basic set of functions that can be used to develop fast and simple SNMP management systems.

The SNMPUtil.exe tool, which is provided on the Microsoft® Windows® 2000 Resource Kit companion CD, is meant to be used as an example of a management software application built on top of the Management API. For additional information about the Management API, see “Architecture of Windows 2000 SNMP” later in this chapter. The Windows 2000 SNMP Service also supports network management programs provided by third-party vendors.

SNMP REQUESTS FOR COMMENTS (RFC)

SNMP standards are defined in RFCs published by the Internet Engineering Task Force (IETF) and other working groups.

SNMP version 1 is defined in the following RFCs:

RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets. Defines the subset of ASN.1 used in SNMP version 1.

RFC 1157: Simple Network Management Protocol (SNMP). Defines SNMP communication formats and operations.

RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets. MIB-II. Defines basic and industry-common types of managed objects.

RFC 1573: Evolution of the Interfaces Group of MIB-II. Revision of the MIB-II Interfaces Group.

SNMP version 2 is defined in the following RFCs:

RFC 1902: Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). Defines the subset of ASN.1 used in SNMP version 2.

RFC 1904: Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). Describes how the minimal level of conformance can be denoted within a Management Information Base (MIB).

RFC 1905: Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). Defines SNMP version 2 communication formats and operations.

RFC 1906: Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2). Defines how SNMP version 2 can be run over IP, IPX, Open Systems Interconnection (OSI), and AppleTalk.

RFC 1907: Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). Defines the managed objects that describe the behavior of the SNMP version 2 entity.

RFC 1908: Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. Describes coexistence between SNMP version 1 and SNMP version 2.


Overview of SNMP

SNMP uses a distributed architecture of management systems and agents. The following sections discuss the role of each component, including the objects and messages used to store and retrieve managed information.


Management Systems and Agents

Utilizing SNMP services requires two components, as shown in Figure 13.2:

  • An SNMP management system
  • An SNMP agent

The SNMP management software application does not have to run on the same computer as the SNMP agents.

Figure 13.2 SNMP Management System and Agent

The SNMP management system, also known as the management console, can request the following information from managed computers (SNMP agents):

  • Network protocol identification and statistics
  • Dynamic identification of devices attached to the network (a process referred to as discovery)
  • Hardware and software configuration data
  • Device performance and usage statistics
  • Device error and event messages
  • Program and application usage statistics

The management system can also send a configuration request to the agent that requests the agent to change a local parameter; however, this is a rare occurrence because most client parameters have read - only access.

Several SNMP management tools are provided on the Microsoft Windows 2000 Resource Kit companion CD. For more information about management tools, see “Architecture of Windows 2000 SNMP” later in this chapter.

SNMP agents provide SNMP management systems with information about activities that occur at the Internet Protocol (IP) network layer and respond to management system requests for information. Any computer that is running SNMP agent software, such as the Windows 2000 SNMP Service, is an SNMP agent. The agent service can be configured to determine what statistics are to be tracked and what management systems are authorized to request information.

In general, agents do not originate messages — they only respond to messages. The exception is alarm messages triggered by specific events, which are known as trap messages. A trap is an alarm- triggering event on an agent computer, such as a system reboot or illegal access. Traps and trap messages provide a rudimentary form of security by notifying the management system any time such an event occurs.

For detailed information about SNMP requests and trap messages, see “SNMP Messages” later in this chapter.


Management Information Base

A Management Information Base (MIB) is a container of objects, each of which represents a particular type of information. This collection of objects contains information required by a management system. For example, one MIB object represents the number of active sessions on an agent; another represents the amount of available hard drive space on the agent. All of the information that a management system might request from an agent is stored in various MIBs.

A MIB defines the following values for each object it contains:

  • Name and identifier.
  • Defined data type.
  • A textual description of the object.
  • An index method used for complex data type objects (usually described as a multidimensional array or as tabular data).

    Examples of complex data are a list of all the network interfaces configured into the system, a routing table, or the Address Resolution Protocol (ARP) table.

  • Read/write permissions.

Each object in a MIB has a unique identifier that includes the following information:

  • Type (counter, string, gauge, or address).
  • Access level (read or read/write).
  • Size restriction.
  • Range information.

The Windows 2000 SNMP Service supports the HOST MIB, Internet MIB II, LAN Manager MIB II, Host Resources MIB, and Microsoft proprietary MIBs. (For more information about the Windows 2000-based MIBs and descriptions of all objects in the MIB, see the appendix “MIB Object Types for Windows 2000.”)

The Windows 2000 SNMP agent has a modular, extendible design that supports multiple MIBs through an agent API. The Windows 2000 SNMP agent is also known as the extendible agent, whereas the supported MIBs are also known as SNMP subagents or extension-agents. When the SNMP service is started, the SNMP agent loads any SNMP extension - agent dynamic-link libraries (DLLs) that are configured in the registry. This design makes it possible to add new MIBs easily. Microsoft and third - party developers can develop MIBs for new hardware and software components and integrate them easily into an existing SNMP service.

Table 13.1 is a list of the MIBs that ship with Windows 2000. The DLLs for MIB-II, LAN Manager MIB-II, and the Host Resources MIBs are installed automatically with the SNMP service. The other MIBs listed in this table are installed when their respective services are installed.

Table 13.1 MIBs that Ship with Windows 2000 SNMP Service

MIB | Description
ACS.MIB | Microsoft-defined MIB for the Admission Control Service (ACS)
DHCP.MIB | Microsoft-defined MIB for the Dynamic Host Configuration Protocol (DHCP) service
FTP.MIB | Microsoft-defined MIB for the File Transfer Protocol (FTP) service
GOPHERD.MIB | Microsoft-defined MIB for the Gopher service
HOSTMIB.MIB | Host Resources MIB
HTTP.MIB | Microsoft-defined MIB for the Hypertext Transfer Protocol (HTTP) service
INETSRV.MIB | Microsoft-defined MIB for Internet Information Services (IIS) components
IPFORWD.MIB | IP Forwarding MIB
LMMIB2.MIB | LAN Manager MIB-II
MIB_II.MIB | MIB-II
MIPX.MIB | Microsoft-defined MIB for the Internetwork Packet Exchange (IPX) Protocol
MRIPSAP.MIB | Microsoft-defined MIB for the Routing Information Protocol (RIP)
MSFT.MIB | MIB that defines Microsoft's enterprise object identifier (object identifier)
MSIPBTP.MIB | Microsoft-defined MIB for the Boot Protocol (BOOTP) service
MSIPRIP2.MIB | Microsoft-defined MIB for the Routing Information Protocol version 2 (RIP2)
NIPX.MIB | Novell-defined MIB for the IPX Protocol
SMI.MIB | MIB that defines SMI version 1 information
WFOSPF.MIB | WellFleet-defined MIB for the Open Shortest Path First (OSPF) routing protocol
WINS.MIB | Microsoft-defined MIB for the Windows Internet Name Service (WINS)

In addition to being configured in the registry of the SNMP agent, new MIBs must also be registered in the SNMP management software application on the management system. For more information about registering new MIBS in the manager, see the documentation included with your management software application.


Object Identifiers

To keep track of all of the information stored in a MIB, each object is labeled with a unique tag called an object identifier (object identifier). The object identifier is implemented as an internationally accepted, multi-part, hierarchical naming scheme that is governed by the Internet Engineering Task Force (IETF). This naming scheme allows developers and vendors to create new components and resources and to assign a globally unique object identifier for each new component or resource without duplicating any existing namespace.

SNMP management software applications use the object identifier to identify the managed objects on each agent. The management system sends a message that requests information about an object and identifies the object by the object identifier. The agent uses the object identifier to retrieve the appropriate information and sends the response back to the management system.

The object identifier itself is actually a sequence of labels that begins at the top of the hierarchy and ends with the object to which the object identifier is being assigned. As the example in Figure 13.3 illustrates, iso.org.dod.internet.private.enterprise.lanmanager is the object name for LAN Manager and the object number is 1.3.6.1.4.1.77.

Figure 13.3 The MIB Namespace Hierarchy

At a specific level in the namespace hierarchy, the IETF grants to individual organizations the authority to create new MIBS under that organization. The private namespace assigned to Microsoft is 1.3.6.1.4.1.311. Microsoft has the authority to create new MIBs under this namespace and to assign names to them, such as the Microsoft IIS Service MIB.

Table 13.2 identifies the Windows 2000–based MIBs and the base object from which all other objects in the MIB are derived. When the SNMP service is started, each agent sends the object identifier for the base object in its MIB to the management system. This allows the management system to identify what managed objects are actually installed on each agent when the manager submits requests for information.

Table 13.2 Base Object Identifiers

MIB Name | Base Object name | Base Object Identifier (object identifier) | Description
Internet MIB-II Mib_ii.mib | iso.org.dod.internet. mgmt.mib-2 | 1.3.6.1.2.1 | Defines objects that are essential for configuration and fault analysis. Internet MIB-II is defined in RFC 1213.
LAN Manager MIB-II Lmmib2.mib | iso.org.dod.internet. private.enterprise. lanmanager | 1.3.6.1.4.1.77 | Defines objects that include such items as statistical, share, session, user, and logon information.
Microsoft DHCP Service MIB Dhcp.mib | iso.org.dod.internet. private.enterprise. microsoft.software. dhcp | 1.3.6.1.4.1.311.1.3 | Contains statistics for the DHCP service and DHCP scope information.
Microsoft Internet Information Service MIB Inetsrv.mib | iso.org.dod.internet. private.enterprise. microsoft.software.iis | 1.3.6.1.4.1.311.1.7 | The FTP, Gopher, and HTTP server MIBs are derived from the Internet Information Services base object.
Microsoft WINS Service MIB Wins.mib | iso.org.dod.internet. private.enterprise. microsoft.software. wins | 1.3.6.1.4.1.311.1.2 | Contains information about the WINS service, including statistics, database information, and push and pull data.


SNMP Messages

Both agents and management systems use SNMP messages to inspect and communicate information about managed objects. SNMP messages are sent via the User Datagram Protocol (UDP). IP is used to route messages between the management system and host.

When SNMP management programs send requests to a network device, the agent program on the device receives the requests and retrieves the requested information from the MIBs. The agent then sends the requested information back to the initiating SNMP manager program. An SNMP agent sends information:

  • When it responds to a request for information from a management system.
  • When a trap event occurs.

To perform these tasks, the management system and agent programs use the following messages:

  • GET

    The basic SNMP request message. Sent by a management system, it requests information about a single MIB entry on an agent — for example, the amount of free drive space.

  • GET-NEXT

    An extended type of request message that can be used to browse the entire hierarchy of management objects. When it processes a GET-NEXT request for a particular object, the agent returns the identity and value of the object that logically follows the previous information that was sent. The GET-NEXT request is useful mostly for dynamic tables, such as an internal IP route table.

  • SET

    A message that can be used to send and assign an updated MIB value to the agent when write access is permitted.

  • GETBULK

    A requests that the data transferred by the agent be as large as possible within the given restraints of message size. This minimizes the number of protocol exchanges required to retrieve a large amount of management information.

  • NOTIFY

    Also called a trap message, NOTIFY is an unsolicited message that is sent by an agent to a management system when the agent detects a certain type of event. For example, a trap message might be sent when a system restart occurs. The management system that receives the trap message is referred to as the trap destination.

By default, computer software port 161 is used to listen for SNMP messages and port 162 is used to listen for SNMP traps. You can change these port settings by configuring the local Services file. For more information about how to do this, see “Changing SNMP Port Settings” later in this chapter.

The example illustrated in Figure 13.4 shows how management systems and agents communicate information.

Figure 13.4 SNMP Manager and Agent Interaction

The communication process is as follows:

  1. A management system forms an SNMP message that contains an information request (GET), the name of the community to which the management system belongs, and the destination of the message —the agent’s IP address (131.107.3.24).
  2. The SNMP message is sent to the agent.
  3. The agent receives the packet and decodes it. The community name (Public) is verified as acceptable.
  4. The SNMP service calls the appropriate subagent to retrieve the session information requested from the MIB.
  5. The SNMP takes the session information from the subagent and forms a return SNMP message that contains the number of active sessions and the destination —the management system’s IP address (131.107.7.29).
  6. The SNMP message is sent to the management system.


Windows 2000 SNMP Agent Properties

Table 13.3 lists the types of services that can be configured for the management of computers on your system.

Table 13.3 SNMP Agent Services

Type of Agent Service | Conditions for Selecting the Type of Service
Physical | The computer manages physical devices, such as a hard disk partition.
Management of logical devices | The computer uses applications that send data using the TCP/IP protocol suite. This service should always be enabled.
Datalink/Subnetwork | The computer manages a bridge.
Internet | The computer functions as an IP gateway (router).
End-to-end | The computer functions as an IP host. This service should always be enabled.

The configuration of the SNMP service contains information about the following:

  • The name of the person to contact, such as the network administrator.
  • The location of the contact person.

You can configure these agent properties by using the Agent tab in the Microsoft SNMP Properties sheet. This information can also be retrieved remotely via SNMP requests. For more information about configuring agent properties, see Windows 2000 Server Help.


Security

The SNMP service provides a rudimentary form of security through the use of community names and authentication traps. You can restrict SNMP communications for the agent and allow it to communicate with only a set list of SNMP management systems.


Traps

Traps can be used for limited security checking. When traps are configured for an agent, the SNMP service generates trap messages when specific events occur. For example, an agent can be configured to initiate an authentication trap if a request for information is sent by a management system the agent doesn’t recognize. A message from such a management system is sent to a trap destination, which is specified explicitly in the SNMP service configuration. Trap messages can also be generated for events such as host system startup, shutdown, or password violation.

Trap destinations consist of the host name and the IP address or IPX address of the management system. The trap destination must be a network – enabled host that is running SNMP management software. Although trap destinations are configured by the administrator, the events (such as a system reboot) that generate a trap message are internally defined by the agent.

You can configure trap destinations by using the Traps tab in the Microsoft SNMP Properties sheet. For more information about configuring trap destinations, see Windows 2000 Help.


Communities

Each SNMP management host and agent belongs to an SNMP community. An SNMP community is a collection of hosts grouped together for administrative purposes. Deciding what computers should belong to the same community is generally, but not always, determined by the physical proximity of the computers. Communities are identified by the names you assign to them.

Community names can be used to authenticate SNMP messages and, thus, provide a rudimentary security scheme for the SNMP service. Although a host can belong to several communities at the same time, an SNMP agent will not accept requests from a management system in a community that is not on its list of acceptable community names.

There is no relationship between community names and domain names or workgroup names. A community name can be thought of as a password shared by SNMP management consoles and managed computers. It is your responsibility as a system administrator to set hard - to - guess community names when you install the SNMP service.

In the example illustrated in Figure 13.5, there are two communities — Public and Public2. Agent1 can respond to SNMP requests from and can send traps to Manager2 because they are both members of the Public2 community. Agent2, Agent3, and Agent4 can respond to SNMP requests from and can send traps to Manager1 because they are all members of the (default) Public community.

Figure 13.5 Example of SNMP Communities

Community names are managed by configuring the SNMP security properties. For more information about configuring security properties, see Windows 2000 Server Help.

When an SNMP agent receives a message, the community name contained in the packet is verified against the agent’s list of acceptable community names. After the name is determined to be acceptable, the request is evaluated against the agent’s list of access permissions for that community. The types of permissions that can be granted to a community include the following:

  • None

    The SNMP agent does not process the request. When the agent receives an SNMP message from a management system in this community, it discards the request and generates an authentication trap.

  • Notify

    The SNMP agent sends only trap messages to this community. The agent discards requests from management systems in this community and generates an authentication trap.

  • Read Only

    The agent does not process SET requests from this community. It processes only GET, GETNEXT, and GETBULK requests. The agent discards SET requests from manager systems in this community and generates an authentication trap.

  • Read Create

    The SNMP agent processes or creates all requests from this community. It processes SET, GET, GETNEXT, and GETBULK requests, including SET requests that require the addition of a new object to a MIB table.

  • Read Write

    Currently identical to Read Create.

Community permissions are configured by using the SNMP Security tab of the Microsoft SNMP Properties sheet.

Community names are transmitted as cleartext, that is, without encryption. Because unencrypted transmissions are vulnerable to attacks by hackers with network analysis software, the use of SNMP community names represents a potential security risk. However, Windows 2000 IP Security can be configured to help protect SNMP messages from these attacks. For more information about configuring for IP security, see “Securing SNMP Messages with IP Security” later in this chapter.


Configuring SNMP Security Options

The following options can be configured to enable SNMP security:

  • Accepted Community Names. The SNMP service requires the configuration of at least one default community name. The name Public is generally used as the community name because it is the common name that is universally accepted in all SNMP implementations. You can delete or change the default community name or add multiple community names. The community names configured in this option are used in trap destinations. If the SNMP agent receives a request from a community that is not on this list, it generates an authentication trap.

Caution

If you remove all of the community names, including the default name Public, SNMP responds to any community names that are presented; therefore, no security is implemented.

  • Permissions. You can select permission levels that determine how an agent processes SNMP requests from the various communities. For example, you can configure the permission level to block the SNMP agent from processing any request from a specific community.
  • Accept SNMP Packets from Any Host. In this context, the source host and list of acceptable hosts refers to the source SNMP management system and the list of other acceptable management systems. When this option is enabled, no SNMP packets are rejected on the basis of the name or address of the source host or on the basis of the list of acceptable hosts. This option is enabled by default.
  • Only Accept SNMP Packets from These Hosts. Selecting this option provides limited security. When the option is enabled, only SNMP packets received from the hosts on a list of acceptable hosts are accepted. The SNMP agent rejects messages from other hosts and sends an authentication trap. Limiting access to only hosts on a list provides a higher level of security than limiting access to specific communities because a community name can encompass a large group of hosts.
  • Send Authentication Traps. When an SNMP agent receives a request that does not contain a valid community name or the host that is sending the message is not on the list of acceptable hosts, the agent can send an authentication trap message to one or more trap destinations (management systems). The trap message indicates that the SNMP request failed authentication. This is a default setting.

SNMP security is configured by using the Security tab in the Microsoft SNMP Properties sheet. For more information about configuring SNMP security, see Windows 2000 Server Help.


SNMP Event Translator

This new feature allows an administrator to specify SNMP events to be translated as SNMP traps. The frequency of event translation may also be specified, along with log file options.

A command line tool, Evntcmd.exe, or a user interface, Evntwin.exe can be used for configuration. Both files, along with the event translator Evntagnt.dll, are located in the %windir&\system32 directory, and may be launched through a Windows 2000 command window.

The event translator uses the SNMP service to generate the trap. By default, no events are translated. For information about how to use and configure this utility, see the SNMP online documentation.


Architecture of Windows 2000 SNMP

The internal architecture of the Windows 2000 implementation of SNMP is divided into management and agent functions; in some cases, these functions overlap, as illustrated in Figure 13.6.

Figure 13.6 Model of Windows 2000 SNMP Architecture

The internal components directly involved in carrying out SNMP functions are the following:

  • Microsoft SNMP Service (Snmp.exe)

    The SNMP service receives the SNMP packets from the network, decodes them, and then dispatches them to the appropriate SNMP subagents. The SNMP service is also called the SNMP Master Agent or the SNMP Extendible Agent. The service is also responsible for intercepting events (traps) from the SNMP subagents and forwarding trap messages to the appropriate management systems.

  • SNMP Subagents (Mib.dll)

    Also known as SNMP Extension Agents (such as Inetmib.dll, Hostmib.dll, Lmmib2.dll), subagents are dynamic-link libraries that export a set of entry points. When an SNMP message is received, the SNMP service decodes the content and passes it to the appropriate subagent by calling one of these entry points. After it processes the message, the subagent passes the information back to the SNMP service. In turn, the service forms the data into an SNMP message and sends it back to the management system. The SNMP service and all SNMP subagents depend on the SNMP Tool API.

  • SNMP Tool API (Snmpapi.dll)

    This tool provides the functions required by both the agent and manager for processing SNMP messages. The SNMP service uses this library for memory management operations, address- decoding routines, object identifier handling routines, and so forth. A set of routines is also provided that helps the SNMP subagents handle and order the SNMP objects. Although it is not necessary to use the Snmpapi.dll, the development of additional SNMP subagents is greatly facilitated by the framework defined by this tool.

  • WinSNMP API (Wsnmp32.dll) and Management API (Mgmtapi.dll)

    These APIs are provided to facilitate the development of SNMP management software applications. The WinSNMP API provides a set of functions for encoding, decoding, sending, and receiving SNMP messages. The Management API is a simple, limited API that is written on top of the WinSNMP and SNMP Tool APIs. It provides a very basic set of functions that can be used to quickly develop basic SNMP management software applications.

  • SNMP Trap Service (Snmptrap.exe)

    The trap service is a separate SNMP component that allows management software applications to receive trap messages sent by SNMP agents. The service receives incoming trap messages from the network and forwards them through the WinSNMP API (Wsnmp32.dll) to the appropriate management system.

  • SNMP Manager Applications (Snmputil.exe)

    This tool, which is provided on the Microsoft Windows 2000 Resource Kit companion CD, is meant to be used as an example of a management software application that is built on top of the Management API. You can develop applications by using either the Management API or the WinSNMP API, or both. Alternatively, you can develop a management application directly on top of the Microsoft Windows Sockets API and not use either the Management API or the WinSNMP API. For more information about developing an SNMP management application, see the Microsoft® Windows® 2000 Platform SDK documentation.


Special Considerations in Implementing SNMP

To take advantage of the SNMP service, review the following sections to avoid problematic implementations.


Changing SNMP Port Settings

SNMP uses the default UDP port 161 for general SNMP messages and UDP port 162 for SNMP trap messages. If these ports are being used by another protocol or service, you can change the settings by modifying the local Services file on the agent. The Services file is located in SystemDrive%%SystemRoot%\System32\Drivers\Etc

There is no file extension. You can use any text - based editor to modify the file. The management system must also be configured to listen and send on the new ports.

Caution

If you have previously configured IP security to encrypt SNMP messages on the default ports, you must also update the IP security policy with the new port settings. Otherwise, communication can be erroneously blocked or SNMP communications might not be secured.


Securing SNMP Messages with IP Security

If you want to use IPSec to protect SNMP messages, you must configure all SNMP – enabled systems to use IPSec, or the communications will fail. If you can’t configure all SNMP – enabled systems to use IPSec, at a minimum, you must configure the IPSec policies of the systems that are SNMP – enabled so that they can send cleartext (unencrypted) information. However, this somewhat defeats the idea of trying to secure messages because all communications will be unsecured.

IP Security does not automatically encrypt the SNMP protocol. You must create filter specifications in the appropriate IP filter list for traffic between the management systems and SNMP agents. The filter specification must include two sets of settings.

The first set of filter specifications are for typical SNMP traffic (SNMP messages) between the management system and the SNMP agents:

  • Mirrored: enabled
  • Protocol Type: TCP
  • Source and Destination Ports: 161
  • Mirrored: enabled
  • Protocol Type: UDP
  • Source and Destination Ports: 161

The second set of filter specifications are for SNMP trap messages sent to the management system from the SNMP agents:

  • Mirrored: enabled
  • Protocol Type: TCP
  • Source and Destination Ports: 162
  • Mirrored: enabled
  • Protocol Type: UDP
  • Source and Destination Ports: 162

For additional information about creating filter specifications, see either “Internet Protocol Security” later in this chapter or see Windows 2000 Server Help.


Managing DHCP, Domain Name System (DNS), Windows Internet Naming Service (WINS), and IIS

A network administrator might use SNMP to assist in the following duties:

  • View and change parameters in the LAN Manager and MIB-II MIBs.
  • Monitor and configure parameters for any WINS servers on the network.
  • Monitor DHCP servers.
  • Use Performance Monitor to monitor TCP/IP – related performance counters (Internet Control Message Protocol (ICMP), IP, Network Interface, TCP, UDP, DHCP, FTP, WINS, and IIS performance counters).

    For more information about Performance Monitor, see the Microsoft® Windows® 2000 Professional Resource Kit, Core Technologies for Windows 2000 Professional and Windows 2000 Server.

  • Use the tools on the Microsoft Windows 2000 Resource Kit companion CD to perform simple SNMP management functions.

Using Performance Monitor

All Performance Monitor counters installed on a computer can be viewed with SNMP. To view Performance Monitor counters with SNMP, use the Perf2MIB tool provided on the Microsoft Windows 2000 Resource Kit companion CD. For additional information about how to use the Perf2mib.exe tool, see Tools Help on the companion CD.

Monitoring DHCP

The Windows 2000 – based DHCP server objects and IIS objects can be monitored but not configured by using SNMP.

Managing WINS

All but a few of the WINS server objects can be monitored and configured by using SNMP. For information about what WINS parameters can be configured using SNMP, refer to the WINS MIB in the appendix “MIB Object Types for Windows 2000.” Any WINS objects defined with read/write permissions can be configured.


SNMP Tools

Table 13.4 contains descriptions of SNMP – related tools and files that are provided on the Microsoft Windows 2000 Resource Kit companion CD. For additional information about using these tools, see Tools Help on the companion CD.

Table 13.4 SNMP –related Tools and Files

File Name | Description
*.mib | MIB source files. Supplies the ASN.1 description of the extension-agents installed on the host.
Mibcc.exe | Converts the ASN.1 MIB description into the binary Mib.bin file.
Snmputil.exe | An example of a management software application that is built on top of the Management API. For more information about the Management API, see “Architecture of Windows 2000 SNMP” later in the chapter.


Registry Settings

The SNMP service converts the information in the registry into a format that can be used by third - party SNMP network management programs. Whenever possible, use the Windows 2000 SNMP Service user interface to alter service settings. When changes are made to SNMP service properties through the user interface, the corresponding SNMP registry settings are modified, with the exception of the following registry setting, which defines the list of extension agents (subagents) that are configured:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SNMP\Parameters\
ExtensionAgents

At service startup, all extension agents defined in the registry are loaded.

If you manually change registry settings for SNMP (for example, changing community names, adding or removing extension agents, or changing trap destinations), the service must be stopped and restarted.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.


Troubleshooting SNMP

This section contains methods for determining the cause of SNMP-related communication problems. Run normal workloads during your testing to gain realistic feedback.


Event Viewer

SNMP error handling has been improved in Windows 2000 Server and Windows 2000 Professional. Manual configuration of SNMP error – logging parameters has been replaced with improved error handling that is integrated with Event Viewer. Use Event Viewer if you suspect a problem with the SNMP service. For troubleshooting procedures, see Windows 2000 Server Help.

To use Event Viewer

  1. Click Start, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Event Viewer.
  2. Select System Log.
  3. Double-click an SNMP event in the Scope pane to display event details.

You can configure a View filter to display only SNMP messages. For more information about using Event Viewer, refer to Windows 2000 Server Help.


WINS Service

When querying a WINS server, you might need to increase the SNMP time-out period on the SNMP management system. If some WINS queries work and others time out, increase the time-out period.


IPX addresses

If you enter an IPX address as a trap destination when installing SNMP Service, the following error message might appear when you restart your computer:

Error 3

This occurs when the IPX address has been entered incorrectly, using a comma or hyphen to separate a network number from a Media Access Control (MAC) address. For example, SNMP management software such as HP OpenView may normally accept an address like: 00008022,0002C0-F7AABD. However, the Windows 2000 SNMP Service does not recognize an address with a comma or hyphen between the network number and MAC address.

The address used for an IPX trap destination must follow the 8.12 format for the network number and MAC address. For example, the following format is valid, where xxxxxxxx is the network number and yyyyyyyyyyyy is the MAC address:

xxxxxxxx.yyyyyyyyyyyy


SNMP Service Files

For your convenience and as a possible aid in troubleshooting, Table 13.5 contains a list of the SNMP - associated files provided as part of the Microsoft Windows 2000 SNMP Service.

Table 13.5 SNMP Service Files

File Name | Description
Dhcpmib.dll | DHCP MIB extension-agent DLL. Available only when the DHCP server is installed on a computer that is running Windows 2000 Server.
Inetmib1.dll | MIB-II extension-agent DLL. Also supports the ipForward MIB.
Hostmib.dll | Host Resources extension-agent (RFC 1514–compliant).
Lmmib2.dll | LAN Manager extension-agent DLL. Available only when the service is installed on a computer that is running Windows 2000 Server.
Wsnmp32.dll, Mgmtapi.dll | Windows 2000–based SNMP manager APIs. Listen for manager requests and send the requests to and receive responses from SNMP agents.
Mib.bin | Installed with the SNMP service and used by the Management API (Mgmtapi.dll). Maps text-based object names to numerical object identifiers.
Snmp.exe | SNMP agent service. A master (proxy) agent. Accepts manager program requests and forwards the requests to the appropriate extension-subagent DLL for processing.
Snmptrap.exe | A background process. Receives SNMP traps from the SNMP agent and forwards them to the SNMP Management API on the management console. Starts only when the SNMP manager API receives a manager request for traps.
Winsmib.dll | WINS MIB extension-agent DLL. Available only when the WINS server is installed on a computer that is running Windows 2000 Server.
Acsmib.dll | Admission Control Service (ACS) MIB extension-agent DLL. Available only when the ACS is installed on a computer that is running Windows 2000 Server.
Ftpmib.dll | FTP MIB extension-agent DLL. Available only when the FTP service is installed on a computer that is running Windows 2000 Server.
Httpmib.dll | HTTP Service MIB extension-agent DLL. Available only when the service is installed on a computer that is running Windows 2000 Server.
Rtipxmib.dll | IPX MIB extension-agent DLL. Available only when the protocol is installed on a computer that is running Windows 2000 Server. It also supports management information for the RIP and Service Advertising Protocol (SAP) protocols running in an IPX environment.
Ripagnt.dll | RIP MIB extension-agent DLL. Available only when routing services are installed on a computer that is running Windows 2000 Server.
Bpagnt.dll | Microsoft-defined MIB for the BOOTP service.


Chapter 9

Common IPSec Planning Scenarios

The following scenarios are examples of common situations in which IPSec can be deployed. These scenarios are meant to provide options to consider when you plan IPSec implementations and policy settings. Each enterprise might have unique requirements that require customized policy settings.

Scenarios that review domain-based networks are referring to Windows 2000 domains running Active Directory.


Copywright

This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unpublished work. © 1998 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, and other names of Microsoft products and/or services referenced herein are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Any RFC excerpts are subject to the following statement:

Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.