Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Functional Description of WAN Device Support

Outside the confines of PC networks, which run for the most part over a limited set of compatible Ethernet technologies, lies the wide world of WAN communications across the

Public Switched Telephone Network , or PSTN. This is a world where flat satin cables lead to corroded punchdown blocks that connect to 30-year-old signal aggregators that tie to ATM interconnects that interface with multimillion-dollar switches that communicate over fiber optic networks designed and built by hundreds of different vendors and operated by thousands of corporate and government entities, all of whom never seem talk to each other over the very networks they control.

Apparently the only person in the last 50 years who has not had any say at all in the structure of the public switched telephone network was my grandmother, and that's only because her complaints to AT&T always got lost in the only system that is even more complex than the PSTN: the public mail service.

Figuring out how to patch PC data communications into the hodgepodge of the PSTN has absorbed the talents of some of the finest engineers and scientists this generation has produced. I try hard to recognize and respect the complexity of their task while I spend days and days trying to get a simple DSL connection into an apartment so that a travel-challenged client can work from home without hassling with a modem.

From the point of view of connecting a Windows user in one location in the world to a server running Windows Server 2003 in another location in the same world, the available alternatives fall into these general categories:

• Circuit-switched networks.
  Interfacing with these networks generally involves the familiar analog dial-up connections used by modems. You can also use switched digital connections via ISDN devices.




• Packet-switched networks.
  Interfacing with these networks is done via X.25 PADs (Packet Assembler/Disassemblers) and Frame Relay Access Devices (FRADS) of one form or another. Connections across packet-switched networks either involve a Permanent Virtual Circuit (PVC) or the much less common Switched Virtual Circuit (SVC). Individual devices can make direct connection to each other via Point-to-Point Protocol (PPP) over Frame Relay.




• Cell-switched networks.
  These networks primarily consist of Asynchronous Transfer Mode (ATM) devices. Although ATM typically makes up the backbone of a network, PCs can access each other directly over ATM using LANE (LAN Emulation) interfaces. Devices can make direct connection to each other over a cell-switched network via PPPoA (Point-to-Point over ATM).




• Dedicated networks.
  This is a generic term for interfaces that have a full-time connection to the PSTN. Most organizations use full or fractional T-1 (DS-1) lines, although some use DS-3 and faster if their budget allows.




• Broadband.
  This is a generic term for technologies that use high-bandwidth signaling to connect customer premise equipment to a special interface either at a PSTN central office or a digital network service center. Broadband includes a myriad of DSL flavors along with digital cable.

WAN Support and NDIS

The day-to-day business of running a communications server involves very little interaction with the devices that interface with the WAN. However, getting the server properly configured, or fixing it when it decides to take a small vacation, can involve a variety of challenges directly related to how the devices communicate with each other inside the Windows Executive. Figure 20.1 shows a diagram of the network drivers used to support WAN communications.

Windows supports WAN interfaces by making them appear to be standard network adapters. This permits the upper level protocols to go about their business without concern for the way data is getting shoveled around the network. Data link and media access control services that communicate to these devices are managed by the

Network Device Interface Specification (NDIS) drivers.

Because of their special nature, circuit-switched devices such as modems and ISDN terminal adapters are separately managed by

Telephony API (TAPI) drivers that then interface with NDIS. The details of this connection do not normally help configuration and troubleshooting, but it is a good idea to remember that a particular modem might work fine when making serial connection that is handled solely by TAPI but fail miserably when called upon to do networking services.

NDIS communicates with network adapters via miniport drivers. The generic miniport for WAN communications is the RAS Async Adapter driver, Asyncmac.sys. The INF file Netrasa.inf in \Windows\INF contains the setup information for this and other virtual WAN miniport drivers, such as the Layer 2 Tunneling Protocol (L2TP) interface, Point-to-Point Tunneling Protocol (PPTP) interface, and the direct parallel interface (PTI).

NDIS works with the adapter minidriver to build a frame that conforms to the appropriate IEEE 802 specification for the interface. For example, an Ethernet frame conforms to IEEE 802.2, whereas a frame suitable for wireless Ethernet conforms to 802.11b. For WAN interfaces, NDIS uses an intermediate driver, Ndiswan.sys, to construct a communications frame that conforms to the requirements of the underlying PPP connection. The format for the framing is defined in RFC 1662, "PPP in HDLC-like Framing."

[View full width]
HKLM | System | CurrentControlSet | Control | Class | 
{4D36E96D-E325-11CE-BFC1-08002BE10318}

Point-to-Point Protocol (PPP)

When it comes to data communications, a LAN is like the stock exchange. There's lots of shouting and signaling and tallying and somehow, in the end, transactions are completed. PC communications over a WAN are more deliberate and more focused. One box talks to another box over a link the two of them work step-by-step to create. The protocol used to create that communications link is called the

Point-to-Point Protocol , or PPP.

PPP has a lot of duties and it uses a suite of helper protocols to accomplish those duties. The protocols are defined in RFC 1661, "Point-to-Point Protocol." Here is a quick list of the stages involved in a PPP transaction followed by a description of the protocols used at each stage:

• Link Establishment.
  During this stage, two physical devices must establish a data link connection that defines who they are, what size and type of frame to use, and what authentication protocol will follow.




• Authentication.
  In this stage, the remote access server takes credentials supplied by the user who initiated the connection and uses them to validate the user's identity. This dial-in authentication is independent of any network authentication that might be required after the PPP connection is made.




• Network Layer Establishment.
  After the user has been authenticated, the client interface is given an IP address and additional configuration settings, such as compression and encryption. It might also be required to hang up and wait for a callback to verify the actual source of the call.

Link Establishment

A PPP transaction begins with a negotiation performed using the

Link Control Protocol , or LCP. This protocol is responsible for defining the data link parameters for the underlying network connection. These parameters include the following:

• Maximum Received Reconstructed Unit (MRRU) .
  This is the maximum frame size that will be transmitted over the connection. Messages larger than this frame size are dissected then reassembled. The MRRU is defined in RFC 1717, "PPP Multilink Protocol," and is set to 1614 bytes by default. (See the "PPPoE" section later in this chapter for additional constraints on the frame size.)




• Asynchronous-Control-Character-Map (ACCM) .
  The first 32 ASCII characters can act as control characters in an asynchronous serial connection. They are also potentially part of the data stream if that stream contains binary files. The ACCM option represents control characters as discrete bits in a 32-bit sequence. For example, Ctrl+L (^L) would be represented by bit 12. If the mask is set to all 0s, this indicates that no mapping is required.




• Authentication Type.
  This option determines the authentication method that will be used in the next phase of the connection. The method depends on the configuration of the client and server. There are five options: EAP (0xC2-27), MS-CHAPv1 (0xC2-23-80), MS-CHAPv2 (0xC2-23-81), CHAP (0xC2-23-05), SPAP (0xC0-27), and PAP (0xC0-23).




• Magic Number.
  A magic number is a random number that validates the packet source. If a host sees its own magic number in a packet, it knows there has been a loopback. It then discards the packet and re-establishes the link.




• Protocol Field Compression.
  This option permits compression of the protocol field in the PPP frame. Both parties must agree to set this option before it can be used. The option is set ON by default.




• Address and Control Field Compression.
  This option permits compression of the 1-byte Address field and the 1-byte control field in the PPP header. This option is set ON by default.

Authentication

PPPPPP Authentication" section.

Network Layer Establishment

After the user has been authenticated, PPP gives the helm to the

Network Control Protocol , or NCP. This protocol is responsible for establishing the network link over the top of the data link built by LCP.

NCP employs several additional protocols. These include the following:

• Callback control




• Compression control




• Encryption control




• Transport control

Callback Control Protocol (CBCP)

This protocol determines the callback options, if any, that have been set for the user. In Windows Server 2003, the user's callback options are contained in one of two places. For standalone dial-up servers, the information is stored in the user's SAM account. For domains, the information is stored in the user's Active Directory object in the MSRADIUS-Callback-Number attribute. CBCP provides three options for setting callbacks:

• No Callback .
  If this option is set, CBCP immediately returns control back to NCP.




• Callback Set by Caller .
  If this option is set, CBCP tells the dial-in client that a callback is required and requests a callback number. The user enters a phone number then CBCP terminates the connection. The client waits for a callback from the server. The number entered by the user is recorded in the Event log. This option is commonly used to support overseas callers because an outbound call from the States is much cheaper than an inbound call from overseas.




• Callback Preset To .
  If this option is set, CBCP tells the dial-up client that a preset callback number has been defined. The client acknowledges then terminates the call and waits for a callback from the server. The server dials the preset number, re-establishes the link, and turns control back to NCP. This option is used when you want to make absolutely certain that a particular user is making the connection.

Compression Control Protocol (CCP)

This protocol negotiates a data compression method. Windows uses a variation of CCP called

Microsoft Point-to-Point Compression , or MPPC. It is documented in informational RFC 2118. MPPC can negotiate additional features with Windows clients while still supporting standard CCP for non-Windows clients. MPPC uses options set by the dial-up client and server to determine the compression setting.

By default, Windows PPP uses software compression. Unfortunately, TAPI exposes a feature that enables hardware compression, as well. You should not use both simultaneously. This wastes cycles compressing frames that will just get compressed again by the modem. Software compression is usually faster, so if you want to disable hardware compression, the option is available at Control Panel | Phone and Modem | Modem Configuration Properties.

With Windows 98 clients, always leave software compression enabled. The PPP connection transaction will fail if software compression is not selected.

Encryption Control

Standard PPP assumes that higher-level application protocols will encrypt the data stream if encryption is desired. Microsoft added encryption negotiation in the network establishment phase of PPP. The option is selected in Dial-Up Properties under the Security tab. Figure 20.3 shows an example from an XP client. Windows 9x uses a similar configuration window in Dial-Up Networking.

When you select the encryption option, the client and server and encrypt the data stream using

Microsoft Point-to-Point Encryption protocol, or MPPE, as documented in RFC 3078, "Microsoft Point-To-Point Encryption (MPPE) Protocol," and RFC 3079, "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)."

MPPE uses RC4 streaming encryption with a 128-bit cipher key now that export controls on strong encryption have been relaxed. Bruce Schneier from Counterpane Systems (Configuring Virtual Private Network Connections" for details.

Control Protocols

After compression and encryption protocols have been defined, NCP turns its attention to the control protocols that configure the interface to the networking protocols used by the system. Each network transport supported by Windows Server 2003 has a corresponding control protocol. They are as follows:

• IPCP (Internet Protocol Control Protocol

  ) .
  This protocol is defined in RFC 1332, "The PPP Internet Protocol Control Protocol (IPCP)." IPCP sets parameters such as the client's IP address, primary and secondary DNS servers, primary and secondary WINS servers, and the option to use Van Jacobson compression for the IP header.




• IPXCP (IPX Control Protocol

  ) .
  This protocol is used to control NetWare's Internetwork Packet Exchange (IPX) over a dial-in connection as defined in RFC 1552, "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)." IPXCP sets parameters such as the IPX Network Number, the IPX Node Number, the IPX Compression Protocol, the IPX Routing Protocol, and the IPX Router Name.




• NBFCP (NetBIOS Frame Control Protocol

  ) .
  This protocol is defined in RFC 2097, "The PPP NetBIOS Frames Control Protocol (NBFCP)." NBFCP sets parameters such as NetBIOS Name Projection that lists the names of the servers to add to the NetBIOS Name table at the client and Peer Information that declares whether the client is an end-point or a gateway. There is also an IEEE MAC Address Required option to specify whether transmitted frames include MAC addresses to facilitate communication on the other side of a gateway and a Multicast Filtering option to control NetBIOS broadcasts through the gateway. At the conclusion of the IPCP negotiation phase, PPP is finished and the link is established. NDIS takes over and begins sending data to the interface.

PPPoE

PPP is not limited to connections between circuit-switched interfaces such as modems and ISDN terminal adapters. Windows can use PPP to establish a direct data link connection between two entities over a number of underlying WAN protocols.

One increasingly common example of this ability is the use of PPP to authenticate and connect a DSL user to a DSL provider network over an existing full-time broadband connection. This link uses a variation of PPP called

PPP over Ethernet, or PPPoE, documented in RFC 2516, "A Method for Transmitting PPP Over Ethernet (PPPoE)."

Purportedly, the reason for using PPPoE lies with security. In early DSL implementations, each DSL interface was assigned a fixed IP address and was "always on" the network. A server or workstation with a DSL interface could route users onto the Internet using NAT, or the user could get an inexpensive hardware gateway to do the same thing. DSL providers saw this as a security vulnerability because users could do mischief from the anonymity of a NAT connection.

The real purpose for PPPoE, though, lies with revenue generation rather than security. A single DSL line can handle dozens of users, and the customer gets those connections for the cost of a single Digital Subscriber Line (DSL) interface. This is common practice over dedicated connections like a T-1, but the revenue model for T-1 networking is much different than for DSL, which is far less expensive.

The industry wrangled over this for a while and came up with PPPoE as way to manage user accounts individually over the same DSL interface. Each PPPoE request is separately authenticated and separately logged and billed. Servers running Windows Server 2003 and XP desktops have PPPoE support built in, so there is no need to install separate authentication software.

One important limitation imposed by PPPoE is a reduction of the maximum frame size that can be transmitted by clients through a server that has a PPPoE-enabled connection. A standard Ethernet frame has a useful payload of 1500 bytes (octets). This is termed the

Maximum Transmission Unit , or MTU. The PPPoE header takes 6 octets with an additional 2 octets for the PPP protocol ID. This leaves an MTU of 1492.

When a TCP/IP client negotiates a connection to a server, the two entities negotiate an MTU. This is ordinarily 1500 octets. If the client sits behind a server with a PPPoE connection, the PPPoE server will drop the frame and return an Internet Control Management Protocol (ICMP) message to the server telling it that the MTU is 1492. If the web server has been configured to refuse ICMP, and many are, the web page will not load completely.

A handy diagnostic technique to check for this situation is to ping the web server from the client with the l switch to specify a payload size and the f switch to prevent fragmentation. The syntax would be as follows:

ping f l 1492 <internet_host>

If you get an error saying Packet needs to be fragmented but DF set, you'll know that you've exceeded the MTU of the web server or one of the intervening routers.

You can avoid these sorts of problems by reducing the MTU at clients that sit behind a server that uses a PPPoE device. You can do this for each client or you can make the change at one client then export the change using Regedit into to a file that can be applied to the remaining clients in a logon script. Here are the changes:

Key:    HKLM | System | CurrentControlSet | Services | Ndiswan | Parameters | Protocols | 0
Values: ProtocolType
Data: 0x0800 (REG_DWORD)
Values:  PPPProtocolType
Data: 0x0021 (REG_DWORD)
Values:  ProtocolMTU
Data: <MTU size> (REG_DWORD)