How Dial-up Remote Access Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Dial-up Remote Access Works

In this section

• Remote Access Server Architecture

• Dial-up Remote Access Protocols

• Dial-up Remote Access Processes and Interactions

• Related Information

Dial-up remote access is a remote access technology that is available as part of Routing and Remote Access that is included in Windows Server 2003. With dial-up remote access, a remote access client uses the telecommunications infrastructure to create a temporary physical or virtual circuit to a port on a remote access server, which is typically attached to a corporate network.

The physical or logical connection between the remote access server and the remote access client is made possible through dial-up equipment installed at the remote access client, the remote access server, and the wide area network (WAN) infrastructure. The nature of the dial-up equipment and WAN infrastructure varies, depending on the type of connection.

The following telecommunications technologies can make up the WAN infrastructure:

• Public Switched Telephone Network (PSTN)

• Integrated Services Digital Network (ISDN)

• X.25

• Asynchronous Transfer Mode (ATM) over asymmetric digital subscriber line (ADSL)

For more information about dial-up remote access configurations with each of these telecommunications technologies, see “What Is Dial-up Remote Access?.”

Remote Access Server Architecture

To understand how dial-up remote access works in Windows Server 2003, you must first understand the architecture of the remote access server. The following figure illustrates how the remote access server components work together.

Remote Access Server Architecture

The following table describes the remote access server components.

Remote Access Server Components

Component	Description
Ndis.sys	The Network Driver Interface Specification (NDIS) wrapper provides the NDIS packet-level interface to the TCP/IP and AppleTalk protocols.
Ndiswan.sys	The NDISWAN driver is an intermediate NDIS driver that provides an IEEE 802.3 miniport interface to protocol drivers and a protocol interface to WAN miniport drivers. NDISWAN provides framing, compression, and encryption services for remote access connections.
WAN miniport driver	The WAN miniport driver contains the code required to operate the dial-up equipment. To use an adapter supporting WAN media, such as Integrated Services Digital Network (ISDN) or asynchronous transfer mode (ATM) with Windows Server 2003 remote access, the adapter vendor must create a WAN miniport driver.
Remote access components	These components are libraries that provide remote access programming interface for applications, Point-to-Point (PPP) protocols (link control, authentication, and network control protocols), and so on. Remote access components can communicate directly with the NDISWAN driver or by accessing the Telephony API (TAPI).
TAPI components	These components are libraries that provide a call control programming interface for all TAPI-aware applications. TAPI components communicate directly with the NDISWAN driver to manage connections.

Routing and Remote Access can be invoked from the command line and is available to the following application programming interfaces (APIs):

• For the remote access server, MultiProtocol Routing (MPR) API.

• For the remote access client, remote access API.

For more information about the APIs associated with remote access, see the Windows Server 2003 Software Development Kit (SDK).

Dial-up Remote Access Protocols

Dial-up remote access uses PPP, a data link layer protocol that uses network layer protocols, including TCP/IP and AppleTalk, to transmit data across a WAN infrastructure.

This section describes PPP and the following protocols and methods that are part of the process when using PPP.

• PPP encapsulation, including PPP over Ethernet (PPPoE)

• PPP Link Control Protocol (LCP)

• Multilink Protocol (MP), Bandwidth Allocation Protocol (BAP), and Bandwidth Allocation Control Protocol (BACP)

• PPP Network Control Protocols (NCPs)

• PPP authentication protocols

PPP performs the following functions:

• Provides multiprotocol data-link layer encapsulation.

  PPP creates frames that contain separate Internet Protocol (IP) datagrams.

• Establishes, maintains, and ends the logical link.

  The PPP protocol uses LCP to establish and configure the parameters of the data-link connection. LCP negotiation includes the authentication of the credentials of the remote access client.

• Provides protocol configuration.

  After the data-link connection has been negotiated, NCPs such as Internet Protocol Control Protocol (IPCP) and AppleTalk Control Protocol (ATCP) negotiate parameters to configure PPP peers. For example, for IPCP, an IP address is allocated to the remote access client by the remote access server. Compression and encryption are also negotiated.

Note

• PPP can terminate the link at any time. Termination generally occurs due to carrier loss, authentication failure, link quality failure, time-out, or link closure by the dial-up client or system administrator. When the link is closing, PPP informs the network layer protocols so that they can take appropriate action.

PPP Encapsulation

PPP encapsulation uses a variant of the International Organization for Standardization (ISO) High-Level Data Link Control (HDLC) protocol to encapsulate multiprotocol datagrams as the payload of PPP frames. The PPP header and trailer are shown in the following figure.

PPP Encapsulation

The fields are described as follows:

• Flag - Set to 0x7E (bit sequence 011111110) to signify the beginning and end of a PPP frame. In successive PPP frames, only a single Flag character is used.

  Note

  • The Flag character must not occur in the middle of the PPP frame. Character stuffing and bit stuffing are used to ensure that the Flag character occurs at the beginning and the end of the frame. For more information, see “Dial-up Remote Access Processes and Interactions” later in this section.

• Address - In HDLC environments, the Address field is used to address the frame to the destination node. On a point-to-point link, the destination node does not need to be addressed. Therefore, for PPP, the Address field is set to 0xFF, the broadcast address. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Address field is not included.

• Control - In HDLC environments, the Control field is used for data-link layer sequencing and acknowledgments. PPP does not provide link-to-link reliable data transfer. Therefore, for all PPP frames, the Control field is set to 0x03 to indicate an unnumbered information frame. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Control field is not included.

• Protocol ID - The 2-byte Protocol ID field identifies the protocol of the PPP payload. If both PPP peers agree to perform protocol field compression during LCP negotiation, the Protocol ID field is one byte for Protocol IDs in the range of 0x00-00 to 0x00-FF.

• PPP Payload - An encapsulation of IP datagrams or AppleTalk datagrams.

• Frame Check Sequence (FCS) - A 16-bit checksum that is used to check for bit-level errors in the PPP frame. If the receiver’s calculation of the FCS does not match the FCS in the PPP frame, the PPP frame is silently discarded.

The maximum size of a PPP frame, known as the maximum receive unit (MRU), is determined during the negotiation of the logical link. The default MRU is 1,500 bytes. If the MRU is negotiated lower than 1,500 bytes, a PPP host must still have the ability to receive 1,500-byte frames in the event of link synchronization failure.

The following table lists typical values for the PPP Protocol ID.

PPP Protocol IDs

Protocol	Protocol ID/Compressed Value
IP	0x00-21 / 0x21
AppleTalk	0x00-29 / 0x29
Van Jacobsen Compressed TCP/IP	0x00-2D / 0x2D
Multilink	0x00-3D / 0x3D
Microsoft Point-to-Point Compression Protocol (MPPC)	0x00-FD / 0xFD
Microsoft Point-to-Point Encryption Protocol (MPPE)	0x00-FD / 0xFD

If MPPE or MPPC are negotiated, then the PPP Protocol ID is set to 0x00-FD. With MPPE and MPPC both using the same PPP Protocol ID, each peer must know that the resulting PPP payload either is encrypted or compressed, or both.

• If only MPPC is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is compressed.

• If only MPPE is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is encrypted.

• If both MPPC and MPPE are negotiated, then compression always occurs before encryption. The compressed PPP frame, consisting of the PPP protocol ID field set to 0xFD and the compressed data, is then encrypted and encapsulated with another PPP header consisting of the protocol ID field set to 0xFD and a 2-byte MPPE header.

PPPoE

PPPoE (PPP over Ethernet) is a method of encapsulating PPP frames so that they can be sent over an Ethernet network. PPPoE was created so that Internet service providers (ISPs) that deploy a broadband Internet access technology in a bridged Ethernet topology, such as cable modems or Digital Subscriber Line (DSL), can use the per-user authentication and connection identification facilities of PPP to identify individual customer connections for accounting and billing purposes. For more information about PPPoE, see RFC 2516.

The following figure shows a PPPoE frame.

PPPoE Frame Structure

The following are the fields in the PPPoE frame:

• Preamble - An 8-byte field that consists of 7 bytes of alternating 1s and 0s (each byte is the bit sequence 10101010) to synchronize a receiving station and a 1-byte 10101011 sequence that indicates the start of a frame. The Preamble provides receiver synchronization and frame delimitation services.

• Destination Address - A 6-byte field that indicates the destination’s address. The destination can be a unicast, a multicast, or the Ethernet broadcast address. The unicast address is also known as an individual, physical, hardware, or media access control (MAC) address. For the Ethernet broadcast address, all 48 bits are set to 1 to create the address 0xFF-FF-FF-FF-FF-FF.

• Source Address - A 6-byte field that indicates the sending node’s unicast address.

• EtherType - The Ethernet II header for PPPoE frames. EtherType is set to 0x88-63 for PPPoE discovery frames and 0x88-64 for PPP session frames. For more information about Ethernet II, see RFC 894.

• Version - A 4-bit field that is set to the value of 1.

• Type - A 4-bit field that is set to the value of 1.

• Code - A 1-byte field that is used to identify the type of PPPoE message. There are defined values for the PPPoE frames exchanged during the discovery phase. For PPP session frames, the Code field is set to 0.

• Session_ID - A 2-byte field that identifies the PPPoE session ID. This field is set to 0 until a session ID is negotiated with the access concentrator (AC) during the discovery phase of the PPPoE connection.

• Length - A 2-byte field that is used to indicate the size, in bytes, of the PPPoE payload.

• PPPoE Payload - A variable-sized payload that can contain either one or more PPPoE tags for PPPoE frames sent during the discovery phase or PPP frames for the PPP session phase. PPPoE tags are information elements in type-length-value (TLV) format. Typical PPPoE tags used during the discovery phase are Service-Name (the name of the ISP or service offered by the AC) and AC-Name (the name of the AC). For a complete list of PPPoE tags and their structure, see RFC 2516.

• Frame Check Sequence (FCS) - A 4-byte field that provides bit-level integrity verification on the bits in the Ethernet II frame. The FCS is also called a cyclical redundancy check (CRC). The source node calculates the FCS and places the result in this field. When the destination receives the FCS, it runs the same CRC algorithm and compares its own value with the one placed in the FCS field by the source node. If the two values match, the frame is considered valid and the destination node processes it. If the two values do not match, the frame is silently discarded.

For more information about the PPPoE connection process, see “Dial-up Remote Access Processes and Interactions” later in this section.

LCP

LCP (Link Control Protocol) negotiates link and PPP parameters to dynamically configure the data link layer of a PPP connection. Common LCP options include the PPP MRU, the authentication protocol, compression of PPP header fields, callback, and multilink options. For more information about LCP, see RFC 1661.

LCP Packet Structure

LCP uses the PPP Protocol ID of 0xC0-21. The packet structure of LCP is illustrated in the following figure. Each LCP packet is a single LCP message that consists of an LCP Code field identifying the type of LCP packet; an Identifier field so that requests and replies can be matched; a Length field indicating the size of the LCP packet; and LCP packet type-specific data.

LCP Packet Structure

The following table lists the LCP packet types.

LCP Packet Types

LCP Code	LCP Packet Type	Description
1	Configure-Request	Sent to open or reset a PPP connection. Configure-Request contains a list of LCP options with changes to default option values.
2	Configure-Ack	Sent when all of the values of all of the LCP options in the last Configure-Request received are recognized and acceptable. When both PPP peers send and receive Configure-Acks, the LCP negotiation is complete.
3	Configure-Nack	Sent when all the LCP options are recognized, but the values of some options are not acceptable. Configure-Nack includes the offending options and their acceptable values.
4	Configure-Reject	Sent when LCP options are not recognized or not acceptable for negotiation. Configure-Reject includes the unrecognized or non-negotiable options.
5	Terminate-Request	Optionally sent to close the PPP connection.
6	Terminate-Ack	Sent in response to the Terminate-Request.
7	Code-Reject	Sent when the LCP code is unknown. The Code-Reject message includes the offending LCP packet.
8	Protocol-Reject	Sent when the PPP frame contains an unknown Protocol ID. The Protocol-Reject message includes the offending LCP packet. Protocol-Reject is typically sent by a PPP peer in response to a PPP NCP for a local area network (LAN) protocol not enabled on the PPP peer.
9	Echo-Request	Optionally sent to test the PPP connection.
10	Echo-Reply	Sent in response to an Echo-Request. The PPP Echo-Request and Echo-Reply are not related to the Internet Control Message Protocol (ICMP) Echo Request and Echo Reply messages.
11	Discard-Request	Optionally sent to exercise the link in the outbound direction.

LCP Options

When using the Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject LCP packet types, the LCP data portion of the LCP packet consists of one or more LCP options, as illustrated in the following figure. Each LCP option consists of an option Type field; a Length field indicating the total length, in bytes, of the option; and the data associated with the option.

LCP Options

The following table lists common LCP options negotiated by Microsoft PPP peers.

LCP Options

Option Name	Option Type	Option Length	Description
Maximum Receive Unit (MRU)	1	4	The maximum size (up to 65,535) of the PPP frame. The default MRU is 1,500. If neither peer is changing the default, this option is not negotiated.
Asynchronous Control Character Map (ACCM)	2	6	A bit map that enables (bit set to 1) or disables (bit set to 0) the use of character escapes for asynchronous links for the 32 ASCII control characters from 0x00 to 0x20. By default, character escapes are used. The ACCM bit map is set to 0x00-00-00-00 for links with XON/XOFF software flow control.
Authentication Protocol	3	5 or 6	Indicates the authentication protocol used during the authentication phase of the connection. Values for this field for Microsoft PPP peers are 0xC2-27 for Extensible Authentication Protocol (EAP); 0xC2-23-80 for Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP); 0xC2-23-81 for MS-CHAP version 2; 0xC2-23-05 for Message Digest 5 Challenge Handshake Authentication Protocol (MD5-CHAP); 0xC0-27 for Shiva Password Authentication Protocol (SPAP); and 0xC0-23 for PAP.
Magic Number	5	6	A random number chosen to distinguish a peer and detect looped back lines.
Protocol Compression	7	2	A flag indicating that the PPP Protocol ID be compressed to a single octet when the 2-byte Protocol ID is in the range of 0x00-00 to 0x00-FF.
Address and Control Field Compression	8	2	A flag indicating that the PPP Address field (always set to 0xFF) and the PPP Control field (always set to 0x03) must be removed from the PPP header.
Callback	13 or 0x0D	3	A 1-octet indicator of how callback is to be determined. For remote access clients and servers running Microsoft Windows 32-bit operating systems, the callback option octet is set to 0x06, indicating that the callback is determined during Callback Control Protocol (CBCP) negotiation.

NCP

After the link and PPP parameters have been negotiated with LCP, the PPP peers then use a series of NCPs (Network Control Protocols) to negotiate the parameters of individual LAN protocols. Microsoft PPP supports the NCPs listed in the following table.

Network Control Protocols

Protocol	Description
IPCP	IPCP negotiates the use of IP.
ATCP	ATCP negotiates the use of AppleTalk.
Compression Control Protocol (CCP)	CCP packets are exchanged to configure MPPC (Microsoft Point-to-Point Compression Protocol) and MPPE (Microsoft Point-to-Point Encryption Protocol).
BACP (Bandwidth Allocation Control Protocol)	Working with MP (Multilink Protocol) and BAP (Bandwidth Allocation Protocol), BACP elects a favored peer in case both PPP peers request to add or remove a connection at the same time.

IPCP

IPCP (Internet Protocol Control Protocol) as used by Microsoft PPP peers is documented in RFC 1332 and RFC 1877. IPCP negotiates IP-based parameters to dynamically configure a TCP/IP-based PPP peer across a point-to-point link. Common IPCP options include an IP address and the IP addresses of Domain Name System (DNS) servers.

Packet Structure

IPCP uses the PPP Protocol ID of 0x80-21. The packet structure of IPCP is exactly the same as LCP, except only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject IPCP packet types, the IPCP data portion of the IPCP packet consists of one or more IPCP options. Each IPCP option consists of an Option Type field; an Option Length field indicating the total length, in bytes, of the option; and the data associated with the option.

Negotiated Options

The following table lists the IPCP options negotiated by Microsoft PPP peers.

IPCP Options

Option Name	Option Type	Option Length	Description
IP compression protocol	2	4	The Van Jacobsen TCP compression protocol.
IP address	3	6	The IP address to be allocated to the remote access client.
Primary DNS server address	129 or 0x81	6	The primary DNS server for the remote access client.
Primary NBNS server address	130 or 0x82	6	The primary NBNS (WINS) server for the remote access client.
Secondary DNS server address	131 or 0x83	6	The secondary DNS server for the remote access client.
Secondary NBNS server address	132 or 0x84	6	The secondary NBNS (WINS) server for the remote access client.

There are no IPCP options for these common TCP/IP configuration items:

• Subnet mask

  The subnet mask is assumed by the remote access client to be the class-based subnet mask of the IP address that is allocated to the remote access client.

• Default gateway

  The default gateway IP address is not allocated by the remote access server. However, a default route is created on the remote access client, which points to the remote access connection. If a default route already exists in the routing table, then the metric of the existing default route is increased and a new default route is added with a lower metric. This is the default behavior for remote access clients running Windows 32-bit operating systems. This behavior can be modified by disabling the UseDefault Gateway on Remote Network setting on the TCP/IP properties of a remote access client’s phone book entry or dial-up connection object.

• DNS domain name

  The DNS domain name configured from the TCP/IP protocol properties on the remote access server is not negotiated during IPCP. For Windows Server 2003 remote access clients, the DNS domain name can be obtained through a DHCPInform message. For more information, see “TCP/IP Configuration for Remote Access Clients” later in this section.

ATCP

ATCP (AppleTalk Control Protocol) as used by Microsoft PPP peers is documented in RFC 1378. ATCP negotiates AppleTalk-based parameters to dynamically configure an AppleTalk-based PPP peer across a point-to-point link. Common ATCP options include AppleTalk address and server information.

Packet Structure

ATCP uses the PPP Protocol ID of 0x80-29. The packet structure of ATCP is exactly the same as the packet structure for LCP, except that only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject ATCP packet types, the ATCP data portion of the ATCP packet consists of one or more ATCP options. Each ATCP option consists of an option Type field; an option Length field indicating the total length, in bytes, of the option; and the data associated with the option.

Negotiated Options

The following table lists the ATCP options negotiated by Microsoft PPP peers.

ATCP Options

Option Name	Option Type	Option Length	Description
AppleTalk Address	1	6	Negotiates the AppleTalk network and node numbers.
Server Information	3	16	Used to convey information about the remote access server.

CCP

CCP (Compression Control Protocol) is documented in RFC 1962. CCP negotiates parameters to dynamically configure, enable, and disable data compression algorithms between PPP peers across a point-to-point link. Common CCP options include an organization identifier and the use of MPPC.

Packet Structure

CCP uses the PPP Protocol ID of 0x80-FD. The packet structure of CCP is exactly the same as the packet structure for LCP, except only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject CCP packet types, the CCP data portion of the CCP packet consists of one or more CCP options. Each CCP option consists of an option Type field; an option Length field indicating the total length, in bytes, of the option; and the data associated with the option.

Negotiated Options

The following table lists the CCP options negotiated by Microsoft PPP peers.

CCP Options

Option Name	Option Type	Option Length	Description
Organization Unique Identifier	0	6 or larger	Used to negotiate an organization’s proprietary compression protocol.
MPPC	18 or 0x12	6	Used to indicate the use of MPPC, MPPE, and the encryption strength.

MPPE and MPPC

With CCP option 18, Microsoft PPP peers negotiate both MPPC and MPPE at the same time. The option data field for CCP option 18 is 4 bytes (32 bits) long. Bits within this data field are used as flags to indicate:

• Whether compression is enabled (0x00-00-00-01).

• Whether 40-bit session keys are derived from the LAN Manager version of the user’s password (0x00-00-00-10).

• Whether 40-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-02-00).

• Whether 56-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-00-80).

• Whether 128-bit session keys are derived from the Windows NT version of the user’s password (0x00-00-00-40).

• Whether the encryption keys are refreshed with each PPP frame (0x01-00-00-00).

For multiple choices, the flag values are added together. For example, for compression (0x00-00-00-01) and 128-bit encryption keys (0x00-00-00-40), the resulting 32-bit option data field is set to 0x00-00-00-41.

Note

• The Encryption Control Protocol (ECP) is used to negotiate a specific encryption method and is documented in RFC 1968. However, for Microsoft PPP peers, the only supported encryption is MPPE, which is negotiated during CCP with the negotiation of MPPC. Therefore, Microsoft PPP peers do not use ECP.

MP, BAP, and BACP

Windows Server 2003 remote access supports the Multilink protocols listed in the following table.

Multilink Protocols

Protocol	Description
MP	Allows multiple physical links to appear as a single logical link over which data can be sent and received.
BAP	Used to dynamically add or remove additional links to an MP connection.
BACP	Elects a favored peer in case both PPP peers request to add or remove a connection at the same time.

MP

MP is defined in RFC 1990 and used to aggregate multiple physical links into a single logical link. A good example is the aggregation of both B-channels of an ISDN Basic Rate Interface (BRI) connection. MP fragments, sequences, and re-orders alternating packets sent across multiple physical connections so that the end result is a single logical link with the combined bandwidth of all of the aggregated physical links. MP is the recommended method of combining multiple B-channels of a BRI connection because the support for bonding, the combining of ISDN B-channels through hardware support, can be specific to the ISDN adapter. MP can be used for any ISDN adapter. MP must be supported on both sides of the connection.

The following figure illustrates the structure of an MP frame. The payload of a Multilink PPP packet is either a fragment of a PPP frame or the entire PPP frame. Multilink PPP fragmentation need not occur if the Multilink PPP packet fits within the MRU of the link. To prevent incorrect ordering of the datagrams or fragments across multiple links, additional fields are used between the PPP Protocol field and the IP datagram. Multilink PPP uses the PPP Protocol ID of 0x00-3D.

Multilink PPP

RFC 1717 defines two different packet formats for short sequence numbers and long sequence numbers. The sequence number is used to prevent the misordering of frames that are sent across multiple links, not to sequence fragments.

For short sequence numbers, a two-byte Delimitation/Sequence # field consists of four bits used for delimitation and 12 bits used for the sequence number. Within the delimitation field are two flags. The first bit (the Beginning bit) is an indicator that this fragment begins a sequence of fragments corresponding to a packet. The second bit (the Ending bit) is an indicator that this fragment ends a sequence of fragments corresponding to a packet. The other bits in the first four bits of the short sequence number header are set to 0.

For a PPP frame that is sent without fragmentation, both the Beginning and Ending bits are set. For a PPP frame that is larger than the MRU of the physical link, the PPP frame is fragmented, and each fragment is sent as a separate PPP packet. MP performs a data-link layer fragmentation that is not related to IP fragmentation.

For long sequence numbers, a four-byte Delimitation/Sequence # field consists of eight bits (one byte) used for delimitation, and 24 bits (3 bytes) used for the sequence number. Within the delimitation field, the same bits as the short sequence number header define the Beginning bit and the Ending bit. The other bits in the first byte of the long sequence number header are set to 0. The long sequence number header is used by default, unless the short sequence number is chosen during LCP negotiation.

The following table lists Multilink LCP options negotiated by Microsoft PPP peers. For information about other Multilink options, see RFC 1990.

Multilink LCP Options

Option Name	Option Type	Option Length	Description
Multilink Maximum Receive Reconstructed Unit	17 or 0x11	4	Specifies the number of octets that a peer can reconstruct when performing reassembly of fragmented MP frames.
Short Sequence Number Header Format	18 or 0x12	2	Specifies the use of the short sequence number in the MP header.
Multilink Endpoint Discriminator	19 or 0x13	9	A unique system identifier to differentiate links from two PPP peers with the same authenticated name.

BAP

Although MP allows for multiple physical links to be aggregated, MP does not provide a mechanism to adapt to changing conditions by adding extra links when needed or terminating extra links when unneeded. This additional capability is provided by BAP and BACP, as defined in RFC 2125. BAP is a PPP control protocol that is used on an MP connection to dynamically manage links. BAP uses the PPP Protocol of ID 0xC0-2D.

For example, an MP and BAP-enabled remote access client and remote access server create an MP connection consisting of a single physical link. As the use of the single link rises to a configured level, the remote access client uses a BAP Call-Request message to request an additional link. The BAP Call-Request message specifies the type of link desired, such as analog phone, ISDN, or X.25. The remote access server then sends a BAP Call-Response message that contains the phone number of an available port on the remote access server of the same type specified by the remote access client in the BAP Call-Request.

When use on the second link drops to a specified level, either the remote access client or the remote access server can send a BAP Link-Drop-Query-Request message to drop the link.

BAP also supports a Callback-Request message in which the requesting peer specifies the link type and the number to call back. For more information about BAP messages, see RFC 2125.

The following table lists the BAP LCP option negotiated by Microsoft PPP peers.

BAP LCP Option

Option Name	Option Type	Option Length	Description
BAP Link Discriminator	23 or 0x17	4	A unique number used to identify a link in a Multilink PPP connection.

BACP

BACP is a PPP NCP that negotiates a single option: the election of a favored peer. If both peers of an MP and BAP-enabled connection send BAP Call-Request or BAP Link-Drop-Query-Request messages at the same time, the favored peer is the peer whose requests are implemented.

BACP uses the PPP Protocol ID of 0xC0-2B. The packet structure of BACP is exactly the same as the packet structure for LCP, except that only packet types 1 through 7 are defined. For Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject BACP packet types, the BACP data portion of the BACP packet consists of the single BACP Favored-Peer option listed in the following table.

BACP Favored Peer Option

Option Name	Option Type	Option Length	Description
Favored-Peer	1	6	A randomly allocated 4-byte magic number used to elect a favored BAP peer. The favored peer is the peer with the lowest magic number.

PPP Authentication Protocols

After both PPP peers agree on a single, specific PPP authentication protocol, authentication for PPP is accomplished through that protocol.

Windows Server 2003 remote access supports the PPP authentication protocols listed in the following table.

PPP Authentication Protocols

Protocol	Description	Security Level
PAP ( Password Authentication Protocol)	Uses plaintext passwords. It is typically negotiated if the remote access client and remote access server cannot negotiate a more secure form of validation.	The least secure authentication protocol. Does not protect against replay attacks, remote client impersonation, or remote server impersonation.
SPAP (Shiva Password Authentication Protocol)	A reversible encryption mechanism employed by Shiva remote access servers.	More secure than PAP, but less secure than CHAP or MS-CHAP. Does not protect against remote server impersonation.
CHAP (Challenge Handshake Authentication Protocol)	A challenge-response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response.	An improvement over PAP and SPAP in that the password is not sent over the PPP link. Requires a plaintext version of the password to validate the challenge response. Does not protect against remote server impersonation.
MS-CHAP (Microsoft Challenge Handshake Authentication Protocol version 1)	A nonreversible, encrypted password authentication protocol that is similar to CHAP.	More secure than CHAP. Requires an MD4 hash of the password to validate the challenge response. Does not protect against remote server impersonation
MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2)	An upgrade of MS-CHAP.	Provides stronger security than MS-CHAP. A comparison of MS-CHAP and MS-CHAP v2 features appears later in this section.
EAP (Extensible Authentication Protocol)	Allows for arbitrary authentication of a remote access connection through the use of authentication schemes known as EAP types.	Offers the strongest security by providing the most flexibility in authentication variations.

For information about authentication processes for PPP authentication protocols, see “Dial-up and Remote Access Processes and Interactions” later in this section.

PAP

PAP is included in Windows Server 2003 so that:

• Remote access clients running Windows 32-bit operating systems can connect to older remote access servers that do not support a secure authentication protocol

• Remote access clients running Microsoft operating systems that do not support a secure remote access protocol can connect to remote access servers running Windows 32-bit operating systems.

Note

• To make your remote access server more secure, ensure that PAP is disabled. As a consequence, however, older remote access clients not running Microsoft operating systems that do not support secure authentication protocols will be unable to connect.

SPAP

A Windows Server 2003 remote access client can use SPAP to authenticate itself to a Shiva remote access server. A remote access client running Windows 32-bit operating systems can use SPAP to authenticate itself to a Windows Server 2003 remote access server.

CHAP

CHAP is used by vendors of dial-in servers and clients. CHAP is supported by both the Windows Server 2003 remote access server and remote access client.

CHAP protects against replay attacks by using an arbitrary challenge string per authentication attempt. Instead of sending the password over the link, the password is used to create a one-way hash from a challenge string. The server, knowing the client’s password, can duplicate the operation and compare the result with that sent in the client’s response.

CHAP requires that local or domain passwords are stored in a reversibly encrypted form.

MS-CHAP

As in CHAP, the remote access server sends a challenge that consists of a session ID and an arbitrary challenge string to the remote client. The remote client must return the user name and an MD4 hash of the challenge string, the session ID, and the MD4-hashed password.

One difference between CHAP and MS-CHAP is that, in CHAP, the plaintext version of the password must be available to validate the challenge response. With MS-CHAP, the remote access server requires only the MD4 hash of the password to validate the challenge response. In Windows Server 2003, the user’s password is stored as an MD4 hash and in a reversibly encrypted form. When CHAP is used, the remote access server decrypts the reversibly encrypted password to validate the remote access client’s response.

MS-CHAP also allows for error codes including a “password expired” code and password changes. MS-CHAP protects against replay attacks by using an arbitrary challenge string per authentication attempt.

If MS-CHAP is used as the authentication protocol and MPPE is negotiated, then shared secret encryption keys are generated by each PPP peer. MS-CHAP also provides a set of messages that allows a user to change the password during the user authentication process.

MS-CHAP v2

Windows Server 2003 includes support for MS-CHAP v2, which provides stronger security for remote access connections. The following table compares the security features of MS-CHAP to those of MS-CHAP v2.

MS-CHAP and MS-CHAP v2 Security Feature Comparison

MS-CHAP	MS-CHAP v2
LAN Manager encoding of the response used for backward compatibility with older Microsoft remote access clients is cryptographically weak.	LAN Manager-encoded responses are not allowed.
LAN Manager encoding of password changes is cryptographically weak.	LAN Manager-encoded password changes are not allowed.
Only one-way authentication is possible. The remote access client cannot verify that it is dialing in to its organization’s remote access server or a masquerading remote access server.	Two-way authentication, also known as mutual authentication, is provided. The remote access client receives verification that the remote access server that it is dialing in to has access to the user’s password.
With 40-bit encryption, the cryptographic key is based on the user’s password. Each time the user connects with the same password, the same cryptographic key is generated.	The cryptographic key is always based on the user’s password and an arbitrary challenge string. Each time the user connects with the same password, a different cryptographic key is used.
A single cryptographic key is used for data sent in both directions on the connection.	Separate cryptographic keys are generated for transmitted and received data.

EAP

EAP is an extension to PPP that allows for arbitrary authentication mechanisms to be employed for the validation of a PPP connection. With PPP authentication protocols such as MS-CHAP and SPAP, a specific authentication mechanism is chosen during the link establishment phase. Then, during the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order.

With EAP, the authentication mechanism is not chosen during the link establishment phase. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. After the connection authentication phase is reached, the PPP peers must first negotiate the use of a specific EAP authentication scheme known as an EAP type. After the EAP type is agreed on, EAP allows for an open-ended conversation between the remote access client and the remote access server that can vary based on the parameters of the connection. The conversation consists of requests for authentication information and the responses. The length and detail of the authentication conversation depends on the EAP type.

For example, when EAP is used with security token cards, the remote access server can separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the user passes through another level of authentication. When all questions have been answered satisfactorily, the user is authenticated and permitted access to the network.

The use of EAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC2-27. After LCP negotiation is complete, EAP messages use the PPP Protocol ID of 0xC2-27. Windows Server 2003 includes support for the MD5-Challenge and Extensible Authentication Protocol-Transport Level Security (EAP-TLS) EAP types.

EAP is designed to allow authentication plug-in modules at both the client and server ends of a connection. By installing an EAP type library file on both the remote access client and the remote access server, a new EAP type can be supported. This presents vendors with the opportunity to supply a new authentication scheme at any time. EAP provides the most flexibility in authentication uniqueness and variations.

Note

• Protected Extensible Authentication Protocol (PEAP) is used as an authentication method for 802.11 wireless client computers, but is not supported for other remote access clients. For more information, see the “IAS Technical Reference” and “802.11 Wireless Technical Reference.”

EAP Infrastructure

EAP is a set of internal components that provide architectural support for EAP types. For successful authentication, both the remote access client and authenticator must have the same EAP authentication module installed. Windows Server 2003 provides two EAP types: MD5-Challenge and EAP-TLS. EAP-TLS is available only for members of a domain. In addition, EAP contains EAP-RADIUS, which is not an EAP type, but is used to send EAP messages to a RADIUS server for authentication.

You can also install additional EAP types. The components for an EAP type must be installed on every remote access client and every authenticator.

MD5-Challenge

MD5-Challenge is the CHAP authentication mechanism used within the EAP framework. Rather than negotiating to perform MD5-Challenge authentication during the link establishment phase, the authenticator and peer negotiate to use EAP during the connection authentication phase.

MD5-Challenge is a required EAP type and can be used to test EAP interoperability. Like CHAP, MD5-Challenge requires that local or domain passwords are stored in a reversibly encrypted form.

EAP-TLS

The Transport Layer Security (TLS) protocol, based on Secure Sockets Layer (SSL), allows applications to communicate securely. TLS provides authentication (user and data), data integrity, and data confidentiality services. To achieve these services, TLS specifies a framework that allows the following:

• Client and two-way authentication using symmetric or asymmetric encryption.

• Negotiation of the specific encryption algorithm (the cipher-suite).

• Secured exchange of encryption keys to be used for encrypting messages.

• Message integrity and user authentication using a message authentication code.

For more information about TLS, see RFC 2246. For more information about EAP-TLS, see RFC 2716.

EAP-TLS uses the TLS protocol for authentication during the establishment of a PPP connection. With EAP-TLS, mutual authentication between the PPP client and the authenticator is performed through the exchange and verification of certificates. The client attempting the connection sends a user certificate, and the authenticator sends a machine certificate. If smart cards are used for remote access authentication, EAP-TLS is the required authentication method. For more information about smart card authentication, see “IAS Technical Reference.”

EAP-TLS is supported only on Windows Server 2003 remote access server computers that are members of a Windows Server 2003 mixed or native domain. Stand-alone Windows Server 2003 remote access servers do not support EAP-TLS.

EAP-RADIUS

EAP-RADIUS passes EAP messages of any EAP type by the remote access server to a RADIUS server for authentication. The EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server. The remote access server becomes a pass-through device passing EAP messages between the remote access client and the RADIUS server. All processing of EAP messages occurs at the remote access client and the RADIUS server.

EAP-RADIUS is used in environments in which Remote Authentication Dial-In User Service (RADIUS) is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server.

In a typical use of EAP-RADIUS, the remote access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection attempt is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client.

For more information about RADIUS support for EAP, see RFC 2869.

CBCP

The Microsoft implementation of PPP includes the optional use of CBCP (Callback Control Protocol) immediately after authentication.

CBCP negotiates the use of callback in those cases in which the remote access server, after authenticating the remote access client, terminates the physical connection, waits a specified amount of time, and then calls the remote access client back at either a static or dynamically configured phone number. Common CBCP options include the phone number that will be used by the remote access server to call back the remote access client.

Packet Structure

CBCP uses the PPP Protocol ID of 0xC0-29. The packet structure of CBCP is exactly the same as the packet structure for LCP; however, only the Callback-Request (type 1), Callback-Response (type 2), and Callback-Ack (type 3) types are used. For all CBCP packet types, the CBCP data portion of the CBCP packet consists of one or more CBCP options. Each CBCP option consists of an option Type field; an option Length field indicating the total length, in bytes, of the option; and the data associated with the option.

Negotiated Options

The following table lists the CBCP options negotiated by Microsoft PPP peers.

CBCP Options

Option Name	Option Type	Option Length	Description
No callback	1	2	No callback is used for the connection.
Callback to a user-specified number	2	variable	The user of the remote access client computer determines the callback number.
Callback to an administrator-defined number	3	variable	Settings on the remote access server determine the callback number.
Callback to any of a list of numbers	4	variable	The remote access server calls back to one of a list of phone numbers.

Dial-up Remote Access Processes and Interactions

This section describes the following processes that take place when establishing a dial-up remote access connection.

• Remote access connection

• TCP/IP configuration for Remote Access clients

• PPP connection

• Connection attempt processing with Remote Access policies

• Broadcast Name Resolution

Remote Access Connection

Connections are established by remote access clients that call the remote access programming interface, which, in turn, uses TAPI to pass call connection information to the dial-up equipment. After the physical connection is made, TAPI is no longer used; other remote access components negotiate the connection with link, authentication, and network control protocols by communicating directly with NDISWAN.

After a remote access connection is established, protocol drivers can communicate over that connection using standard NDIS calls such as NdisSend(). NdisSend() calls for dial-up connections are forwarded to NDISWAN, which then determines the appropriate device and port, performs compression and encryption, provides PPP framing, and then forwards the completed frame to the WAN miniport driver. The WAN miniport driver then forwards the frame to the dial-up adapter.

All inbound remote access client connections, initiated by remote access clients to the remote access server, are represented as a single adapter called the remote access server interface. For each outbound remote access client connection, initiated by the remote access server, a separate interface is created.

To accept calls, the remote access server instructs each WAN miniport driver to indicate when it goes into a line-up state. When the call is placed, the WAN miniport driver passes the line-up state indicator through NDISWAN to the TAPI components. TAPI returns a call handle to NDISWAN to be used to refer to the physical connection, and then NDISWAN and the remote access components negotiate the rest of the remote access connection.

IP and AppleTalk Routing with Remote Access Server

After the remote access connection is established, the remote access client can begin sending LAN protocol traffic to the remote access server or to locations beyond the remote access server. When the remote access client sends LAN protocol traffic that is not destined for the remote access server, the remote access server must forward the LAN traffic to its appropriate destination. To accomplish this, the remote access server must have forwarding capabilities enabled on its routable protocols and act as an IP and AppleTalk router.

When Routing and Remote Access is installed and enabled to provide point-to-LAN remote access connectivity, it enables forwarding between the installed LAN adapters and the WAN miniport interface.

The following figure illustrates the remote access server architecture as it appears when routing IP packets. For simplicity, only IP routing is shown. However, AppleTalk routing operates in a similar way.

IP Routing on the Remote Access Server

Packet Processing from Remote Access Clients

The following process describes how IP packets sent by the remote access client are forwarded by the remote access server.

1. Depending on the dial-up technology, either the entire PPP frame is received by the WAN hardware and passed as a single frame to the appropriate WAN miniport driver, or individual bits of the PPP frame are passed to the appropriate WAN miniport driver.

2. The WAN miniport driver passes the PPP frame to Ndiswan.sys.

3. Ndiswan.sys verifies the PPP checksum and uses the PPP protocol ID to determine that it is an IP datagram.

4. The IP datagram is passed to the TCP/IP protocol driver.

5. The TCP/IP protocol driver, which is enabled for IP forwarding, determines a forwarding interface and an IP address based on the destination IP address in the IP datagram and the contents of its routing table.

6. To forward the IP datagram using the LAN adapter, the TCP/IP protocol calls NDIS with an NdisSend(), along with instructions to send it using the LAN adapter.

7. NDIS forwards the IP datagram to the appropriate LAN miniport driver.

8. The LAN miniport forwards the IP datagram to the LAN adapter through NDIS.

The end result is that packets from the remote access client are forwarded using the same IP routing process used for all IP routing. The success of the IP forwarding process depends on whether the remote access server can find a suitable entry in the IP routing table. Therefore, either the remote access server is configured with a default gateway, or the remote access server has specific routes to all the locations on the intranet to which the remote access server is attached. Specific routes can be added through static routes, or by enabling a routing protocol on the remote access server.

Packet Forwarding to Remote Access Clients

The following process describes how IP packets sent by intranet hosts to the remote access client are forwarded by the remote access server.

1. The LAN adapter passes a frame to its appropriate LAN miniport driver through NDIS. For information about how an IP datagram is forwarded to the MAC address of the remote access server, see “TCP/IP On-Subnet and Off-Subnet Addressing” in the next section.

2. The LAN miniport driver passes the IP datagram to the TCP/IP protocol driver through NDIS.

3. The TCP/IP protocol driver, which is enabled for IP forwarding, determines a forwarding interface and IP address based on the destination IP address in the IP datagram and the contents of its routing table. When the remote access client connects, a host route is created in the IP routing table for the IP address allocated to the remote access client that points to the remote access server interface.

4. To forward the IP datagram using the WAN adapter, the TCP/IP protocol calls NDIS with an NdisSend() with instructions to send it using NDISWAN and a specific connection handle.

5. NDISWAN resolves the connection handle to a specific device and port, adds a PPP header and trailer, and forwards the IP datagram to the appropriate WAN miniport driver through NDIS.

6. The WAN miniport driver forwards the IP datagram to the WAN adapter through NDIS.

The end result is that packets from intranet hosts are forwarded using the same IP routing process used for all IP routing. The success of the IP forwarding process depends on whether the IP addresses of remote access clients can be reached from the hosts on the intranet.

TCP/IP On-Subnet and Off-Subnet Addressing

The remote access server can be configured for on-subnet or off-subnet addressing. This addressing configuration determines how an IP node on a subnet to which the remote access server is attached resolves the MAC address of the remote access server.

• On-subnet addressing is the allocation of IP addresses to remote access clients that are in a range defined by a subnet to which the remote access server is attached. On-subnet addressing uses a subset of addresses of an attached subnet.

• Off-subnet addressing is the allocation of IP addresses to remote access clients that are not in a range defined by a subnet to which the remote access server is attached. Off-subnet addressing uses a separate subnet address space that is unique to the intranet.

On-Subnet Addressing and Proxy ARP

With on-subnet addressing, remote access clients are logically on the same subnet as a subnet attached to the remote access server. Proxy Address Resolution Protocol (ARP) is used by the remote access server to receive IP datagrams that are forwarded to remote access clients.

There are two cases in which Proxy ARP is used:

• When the remote access server is configured to use Dynamic Host Configuration Protocol (DHCP) to obtain addresses for IP-based remote access clients.

• When the remote access server is configured with a static IP address pool that consists of address ranges that are a subset of the addresses for a subnet to which the remote access server is attached.

In either case, the remote access clients are logically on the same subnet as the remote access server. Therefore, IP nodes on that subnet forwarding IP datagrams to a remote access client perform a direct delivery by sending a broadcast ARP Request frame for the remote access client’s IP address.

The remote access client cannot respond to the ARP Request because the remote access server does not forward the ARP Request frame to the remote access client, and the remote access client does not have a MAC address corresponding to the remote access connection.

Therefore, the remote access server responds with an ARP Reply frame with its own MAC address. The node forwarding the packet then sends the IP datagram to the remote access server’s MAC address. The remote access server then uses the IP routing process to forward the IP datagram across the dial-up connection to the remote access client.

Off-Subnet Addressing and IP Routing

With off-subnet addressing, remote access clients are logically on a separate subnet that can be reached across the remote access server. In this case, Proxy ARP is not used. The remote access server is acting as a router between the subnet of the remote access clients and the subnets to which the remote access server is attached. IP nodes on the LAN-based subnets attached to the remote access server that forward IP datagrams to a remote access client perform an indirect delivery by sending a broadcast ARP Request frame for the remote access server’s IP address.

To reach remote access clients from IP nodes on the intranet, routes that represent the address ranges of the IP address pool and point to the LAN interface of the remote access server must be present in intranet routers.

When the first TCP/IP-based remote access client connects, routes corresponding to the off-subnet address ranges that point to the remote access server interface are added to the IP routing table of the remote access server. If the remote access server is configured with an IP routing protocol, the new routes are advertised to neighboring routers by using the advertising process of the configured routing protocol. If the remote access server is not configured with an IP routing protocol, routes corresponding to the off-subnet address ranges that point to the remote access server’s LAN interface must be added to the routers of the intranet.

TCP/IP Configuration for Remote Access Clients

This section describes how the remote access server for Windows Server 2003 allocates network configuration parameters for TCP/IP-based remote access clients.

IPCP Configuration

To configure a TCP/IP-based remote access client with IPCP, the remote access server allocates an IP address and assigns the IP addresses of DNS and WINS servers.

IP Address Allocation

To allocate an IP address to a remote access client, the remote access server is either configured to use DHCP to obtain IP addresses, or with a static IP address pool.

DHCP and Automatic Private IP Addressing

When the remote access server is configured to use DHCP to obtain IP addresses, Routing and Remote Access instructs the DHCP client component to obtain 10 IP addresses from a DHCP server. The remote access server uses the first IP address obtained from DHCP for the remote access server interface, and subsequent addresses are allocated to TCP/IP-based remote access clients as they connect. IP addresses freed due to disconnected remote access clients are reused.

When all 10 IP addresses are used, the remote access server uses the DHCP client component to obtain 10 more. You can modify the number of IP addresses obtained at a time by changing a registry entry. For more information about registry entries for dial-up remote access, see “Dial-up Remote Access Tools and Settings.”

With the Windows NT 4.0 remote access server, the DHCP-allocated addresses are recorded and reused when remote access is restarted. The Windows Server 2003 and Windows 2000 Server remote access servers now release all DHCP-allocated IP addresses using DHCPRELEASE messages each time the service is stopped.

If the remote access server initially starts using DHCP-allocated addresses and the DHCP server becomes unavailable, then an IP address cannot be allocated to additional TCP/IP-based remote access clients.

If a DHCP server is not available when Routing and Remote Access is started, then the DHCP client returns 10 addresses in the range of 169.254.0.1 to 169.254.255.254 to allocate to remote access clients. The address range 169.254.0.0/16 is used for Automatic Private IP Addressing (APIPA). APIPA addresses for point-to-LAN remote access connectivity work only if the network to which the remote access server computer is attached is also using APIPA addresses. If the local network is not using APIPA addresses, remote access clients are only able to obtain point-to-point remote access connectivity. For more information about APIPA, see “DHCP Technical Reference.”

If a DHCP server becomes available, then the next time Routing and Remote Access needs IP addresses, DHCP addresses are obtained. These DHCP addresses are allocated to remote access clients that connected after the addresses were obtained.

The remote access server uses a specific LAN interface to obtain DHCP-allocated IP addresses for remote access clients. You can select which LAN interface to use from the IP tab on the properties of a remote access router in the Routing and Remote Access snap-in. By default, Allow RAS to select adapter is selected, which means that Routing and Remote Access randomly picks a LAN interface to use.

Static IP Address Pool

When a static IP address pool is configured, the remote access server uses the first IP address in the first address range for the remote access server interface, and subsequent addresses are allocated to TCP/IP-based remote access clients as they connect. IP addresses freed due to disconnected remote access clients are reused.

If an address range in the static IP address pool is for off-subnet addresses, either enable an appropriate routing protocol on the remote access server or add the routes corresponding to the IP address ranges to the routers of your intranet. For more information, see “TCP/IP On-Subnet and Off-Subnet Addressing” earlier in this section.

DNS and WINS Address Assignment

As part of the IPCP negotiation, the remote access server assigns the IP addresses of DNS and WINS servers. The set of DNS and WINS server IP addresses that are assigned to the remote access client depends on the following factors:

• Whether DNS and WINS server IP address assignment is prohibited.

• Whether DNS and WINS server IP addresses for remote access clients are globally configured by using data stored in the registry.

• Whether the remote access server has more than one LAN interface.

• Whether the DNS and WINS server IP addresses for the remote access server are configured statically or are obtained through DHCP.

Prohibiting DNS and WINS IP Address Assignment

You can prevent the remote access server from assigning DNS and WINS IP addresses by changing a registry entry.

Configuring Global DNS and WINS IP Address Assignment

You can globally configure DNS and WINS server IP addresses for remote access clients by entering the IP addresses in the registry.

For more information about registry entries for dial-up remote access, see “Dial-up Remote Access Tools and Settings.”

Multiple LAN Interfaces

If the DNS and WINS server IP address assignment is not prohibited or globally configured, then the remote access server allocates the DNS and WINS server IP addresses of a LAN interface on the remote access server to remote access clients. If there is only one LAN interface, which is the typical configuration of a dial-up remote access server, the remote access server allocates the DNS and WINS server IP addresses of the single LAN interface to remote access clients. If there is more than one LAN interface, the DNS and WINS server IP addresses of a specific LAN interface must be determined.

With multiple LAN interfaces, which is the typical configuration of a VPN remote access server, the remote access server, by default, picks one LAN interface randomly during startup and uses the DNS and WINS server IP addresses of the chosen LAN interface to allocate to remote access clients. To override this behavior, you can select the desired LAN interface through the IP tab on the properties of a remote access router in the Routing and Remote Access snap-in. By default, Allow RAS to select adapter is selected.

Static Configuration or DHCP

After the LAN adapter for DNS and WINS server IP address assignment has been determined:

• If the LAN adapter has a static IP configuration, then the IP addresses of the statically-configured DNS and WINS servers are allocated to remote access clients.

• If the LAN adapter obtained its IP configuration using DHCP, then the IP addresses of the DHCP-obtained DNS and WINS servers are allocated to remote access clients.

The following figure illustrates the way in which the remote access server determines the set of DNS and WINS server IP addresses to assign to remote access clients during IPCP negotiation.

Determining DNS and WINS Server IP Address

Overriding IPCP-Allocated DNS and WINS Server IP Addresses with DHCPInform

After IPCP is completed, Windows Server 2003 remote access clients send their remote access servers a DHCPInform message. DHCPInform is a DHCP message used by DHCP clients to obtain DHCP options. While PPP remote access clients do not use DHCP to obtain IP addresses for the remote access connection, Windows Server 2003 remote access client’s use the DHCPInform message to obtain DNS server IP addresses, WINS server IP addresses, and a DNS domain name. The DHCPInform message is sent after the IPCP negotiation is concluded.

The DHCPInform message received by the remote access server is then forwarded to a DHCP server. The remote access server forwards DHCPInform messages only if it has been configured with the DHCP Relay Agent, as discussed in the following section. The response to the DHCPInform message is forwarded back to the requesting remote access client.

If the DHCPInform response contains DNS and WINS server IP address options, then these new values override what was allocated during IPCP. When the remote access client is a Windows Server 2003 remote access client and the DHCPInform response contains a DNS domain name, the DNS domain name is used as the per-adapter DNS suffix for the remote access connection of the remote access client. For more information on per-adapter DNS suffixes, see the “DNS Technical Reference.”

Remote Access Server and the DHCP Relay Agent

To facilitate the forwarding of DHCPInform messages between remote access clients and DHCP servers, the remote access server uses the DHCP Relay Agent, a component of the Windows Server 2003 remote access router. To configure the remote access server to use the DHCP Relay Agent, add the Internal interface to the DHCP Relay Agent IP routing protocol with the Routing and Remote Access snap-in.

If the remote access server is using DHCP to obtain IP addresses for remote access clients, then the remote access server uses the DHCP Relay Agent to forward DHCPInform messages to the DHCP server of the selected LAN interface, which is found on the IP tab on the properties of a remote access router in the Routing and Remote Access snap-in.

If the remote access server is using a static IP address pool to obtain IP addresses for remote access clients, then the DHCP Relay Agent must be configured with the IP address of at least one DHCP server. Otherwise, DHCPInform messages sent by remote access clients are silently discarded by the remote access server.

PPP Connection

The following four phases must be completed successfully before the PPP connection is ready to transfer user data:

1. PPP configuration

2. Authentication

3. Callback

4. Protocol configuration

Phase 1: PPP Configuration

PPP configures PPP protocol parameters using LCP. During the initial LCP phase, each peer negotiates communication options that are used to send data and include:

• PPP parameters, such as MRU, Address and Control field compression, and Protocol ID compression.

• Which authentication protocols are used to authenticate the remote access client. An authentication protocol is selected but not implemented until the authentication phase.

• Multilink options.

Preventing the Flag Character from Occurring in the Middle of a PPP Frame

PPP employs two different methods to prevent the occurrence of the Flag character from appearing in the middle of a frame.

PPP on Asynchronous Links

On asynchronous links, such as analog phone lines, PPP uses a technique called character stuffing to prevent the occurrence of the Flag character within the PPP frame. If the Flag character (0x7E) occurs elsewhere in the PPP frame, the sender replaces it with the sequence 0x7D-5E. The 0x7D character is known as the PPP Escape character. If the PPP Escape character occurs, the sender replaces it with the sequence 0x7D-5D. The receiver translates 0x7D-5E sequences back to 0x7E and 0x7D-5D sequences back to 0x7D.

In addition, character values less than 0x20 can be modified to prevent the serial drivers from interpreting them as control characters. If negotiated by LCP, characters below 0x20 are modified by sending the sequence: 0x7D-[Original character with the 6th bit complemented]. For example, the byte 0x01 would be transmitted as 0x7D-0x21.

PPP on Synchronous Links

With synchronous links, such as T-Carrier, ISDN, or other digital links, a technique called bit stuffing is used to prevent the occurrence of the Flag character within the PPP frame. The Flag character is the bit sequence 01111110. Bit stuffing ensures that six 1 bits in a row occur only when the Flag character is sent. To accomplish this, bit stuffing sends the Flag character unmodified and elsewhere inserts a 0 bit whenever a sequence of five 1 bits occurs. Therefore, the bit sequence 111111 is encoded on the medium as 1111101 and the bit sequence 111110 is encoded as 1111100. Bit stuffing means that a byte can be encoded on the medium as more than eight bits, but the stuffed bits are added and removed by the synchronous link hardware.

PPPoE Connection

The PPPoE connection process has the following two phases:

1. A discovery phase, in which a client computer uses PPPoE frames to discover the presence of an AC, a device that terminates the cable modem or DSL connection and provides access to the Internet, and to determine a PPPoE session ID.

2. A PPP session phase, in which a PPP connection is established and used for data transfer in the same way as a dial-up or VPN-based PPP connection.

Phase 1: PPPoE Discovery

The PPPoE discovery phase consists of the following four PPPoE frames:

1. The PPPoE Active Discovery Initiation (PADI) frame is sent by the PPPoE client to the Ethernet broadcast address (0xFF-FF-FF-FF-FF-FF). Within the Ethernet payload, the Code field is set to 9; the Session ID is set to 0; and there is a single Service-Name PPPoE tag, as well as other tags as needed. If the network connection in the Network Connections folder corresponding to the broadband Internet adapter has been configured with a service name, that service name is sent. Otherwise, the PADI frame is sent with a null service name.

2. The PPPoE Active Discovery Offer (PADO) frame is sent by the AC to the unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is set to 7; the Session ID is set to 0; and there are the AC-Name and Service-Name tags, as well as other tags as needed. If the network connection in the Network Connections folder corresponding to the broadband Internet adapter has not been configured with a service name, it is automatically set to the value of the Service-Name tag in the PADO frame.

3. The PPPoE Active Discovery Request (PADR) frame is sent by the PPPoE client to the unicast MAC address of the AC. Within the Ethernet payload, the Code field is set to 25; the Session ID is set to 0; and there is a Service-Name tag and other tags as needed.

4. The PPPoE Active Discovery Session (PADS) frame is sent by the AC to the unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is set to 101; the Session ID field is set to the session ID for the PPP session of the PPPoE client; and there is a Service-Name tag, as well as other tags as needed.

To terminate the PPPoE session, either the PPPoE client or the AC can send a PPPoE Active Discovery Terminate (PADT) frame, which contains the Code field set to 167 and the session ID set to the session being terminated.

Phase 2: PPP Session

After the PPPoE discovery process is complete, a PPP connection is negotiated and network protocol data, such as IP datagrams, are sent over the PPPoE connection. The following figure shows a PPPoE frame that contains a PPP frame.

Structure of a PPPoE Frame Containing a PPP Frame

Because of the additional PPPoE overhead, the maximum size of PPP frames that can be sent over a PPPoE connection is 1494 bytes.

LCP Negotiation

During the LCP negotiation, LCP packets are exchanged between PPP peers to negotiate a set of options and option values when sending data. The LCP negotiation is actually two separate dialogues between two PPP peers (Peer 1 and Peer 2):

1. Peer 1 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to Peer 2. This dialogue starts with Peer 1 sending a Configure-Request message and ends when Peer 2 sends a Configure-Ack message.

2. Peer 2 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to Peer 1. This dialogue starts with Peer 2 sending a Configure-Request message and ends when Peer 1 sends a Configure-Ack message.

Peer 1 and Peer 2 do not have to use the same set of LCP options.

When a PPP peer sends its initial Configure-Request, the response can be any of the following:

• A Configure-Nack message because one or more options have unacceptable values.

• A Configure-Reject message because one or more of the options are unknown or not negotiable.

• A Configure-Ack message because all of the options have acceptable values.

When a PPP peer receives a Configure-Nack message or Configure-Reject message, it sends a new Configure-Request message with modified options or option values. When a Configure-Ack message is received, the PPP peer is ready to send data.

The following figure shows a LCP negotiation process for Peer 1 using the options W, X, Y, and Z.

Sample LCP Negotiation

The following sequence describes the LCP negotiation show in the figure:

1. Peer 1 sends a Configure-Request message requesting option W; option X set to 100; option Y set to 0; and option Z. Options W and Z are flag options.

2. Peer 2 does not understand option Z, so it sends a Configure-Reject message containing option Z.

3. Peer 1 sends a new Configure-Request message requesting option W; option X set to 100; and option Y set to 0.

4. Peer 2 prefers that option X be set to 200, so it sends a Configure-Nack message containing option X and its preferred value.

5. Peer 1 sends a new Configure-Request message requesting option W; option X set to 200; and option Y set to 0.

6. Peer 2 sends a Configure-Ack message.

Each time Peer 1 sends a new Configure-Request message, it changes the Identifier value in the LCP header so that Configure-Request messages can be matched with their responses.

This process describes only how Peer 1 sends data to Peer 2. A separate LCP negotiation must be performed so that Peer 2 can be configured to send data to Peer 1. Very often, the LCP packets for the two dialogues are intermixed during the connection process. Peer 1 is configuring the way it sends data at the same time as Peer 2.

Phase 2: Authentication

After LCP is complete, the authentication protocol agreed upon by the remote access server and the remote access client is implemented. The nature of this traffic is specific to the PPP authentication protocol.

PAP Negotiation

The use of PAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC0-23. After LCP negotiation is complete, PAP messages use the PPP protocol ID of 0xC0-23.

PAP is a simple exchange of messages:

1. The remote access client sends a PAP Authenticate-Request message to the remote access server containing the remote access clients user name and clear text.

2. The remote access server checks the user name and password and sends back either a PAP Authenticate-Ack message when the user’s credentials are correct, or a PAP Authenticate-Nak message when the user’s credentials are not correct.

SPAP Negotiation

The use of SPAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC0-27. After LCP negotiation is complete, SPAP messages use the PPP protocol ID of 0xC0-27.

Like PAP, SPAP is a simple exchange of messages:

1. The remote access client sends an SPAP Authenticate-Request message to the remote access server containing the remote access client’s user name and encrypted password.

2. The remote access server decrypts the password, checks the user name and password, and sends back either an SPAP Authenticate-Ack message when the user’s credentials are correct, or an SPAP Authenticate-Nak message with a reason why the user’s credentials are not correct.

CHAP Negotiation

The use of CHAP is negotiated during Phase 1 by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x05. After LCP negotiation is complete, CHAP messages use the PPP Protocol ID of 0xC2-23.

The challenge handshake authentication process for CHAP is an exchange of three messages:

1. The remote access server sends a CHAP Challenge message containing a session ID and an arbitrary challenge string.

2. The remote access client returns a CHAP Response message containing the user name in clear text and a hash of the challenge string, session ID, and the client's password using the MD5 one-way hashing algorithm.

3. The remote access server duplicates the hash and compares it to the hash in the CHAP Response. If the hashes are the same, the remote access server sends back a CHAP Success message. If the hashes are different, a CHAP Failure message is sent.

MS-CHAP Negotiation

The use of MS-CHAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x80. After LCP negotiation is complete, MS-CHAP messages use the PPP protocol ID of 0xC2-23.

The challenge handshake authentication process for MS-CHAP is an exchange of three messages:

1. The remote access server sends an MS-CHAP Challenge message containing a session ID and an arbitrary challenge string.

2. The remote access client returns an MS-CHAP Response message containing the user name in clear text and a hash of the challenge string, session ID, and the MD4 hash of the client’s password using the MD4 one-way hashing algorithm.

3. The remote access server duplicates the hash and compares it to the hash in the MS-CHAP Response. If the hashes are the same, the remote access server sends back an MS-CHAP Success message. If the hashes are different, an MS-CHAP Failure message is sent.

MS-CHAP v2 Negotiation

The use of MS-CHAP v2 is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3), the authentication protocol 0xC2-23, and the algorithm 0x81. After LCP negotiation is complete, MS-CHAP messages use the PPP protocol ID of 0xC2-23.

The challenge handshake authentication process for MS-CHAP v2 is an exchange of three messages:

1. The remote access server sends an MS-CHAP v2 Challenge message to the remote access client that consists of a session identifier and an arbitrary challenge string.

2. The remote access client sends an MS-CHAP v2 Response message that contains:

   • The user name.

   • An arbitrary peer challenge string.

   • A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user’s password.

3. The remote access server checks the MS-CHAP v2 Response message from the client and sends back an MS-CHAP v2 Response message containing:

   • An indication of the success or failure of the connection attempt.

   • An authenticated response based on the sent challenge string, the peer challenge string, the client’s encrypted response, and the user’s password.

4. The remote access client verifies the authentication response and if it is correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.

Client Verification with EAP-MD5

After the connection authentication phase is reached, the following process verifies the client:

1. The authenticator sends an EAP-Request message requesting the identity of the client.

2. The client sends its user ID to the authenticator as an EAP-Response message.

3. The authenticator sends an EAP-Request message containing the MD5 challenge string.

4. The client sends the MD5 hash of its user ID and password to the authenticator as an EAP-Response message.

5. On validation of the user ID and password, the authenticator sends a Success message to the client.

Phase 3: Callback

The Microsoft implementation of PPP includes an optional callback phase using CBCP immediately after authentication. The dial-in properties of the user account must be enabled for callback; otherwise, the remote access client cannot receive a call. Either the remote access client or the remote access server must specify the callback number.

If a connection is implementing callback, both PPP peers hang up and the remote access server calls the remote access client at the negotiated number.

Phase 4: Protocol Configuration

After the PPP is configured and callback is complete (optional), network layer protocols can be configured. With remote access on Windows 32-bit operating systems, the remote access server sends the remote access client Configuration-Request messages for all of the LAN protocols enabled for remote access on the remote access server. The remote access client either continues the negotiation of the LAN protocols enabled at the remote access client or sends an LCP Protocol-Reject message containing the Configuration-Request message.

IPCP and ATCP each go through a negotiation process very similar to LCP negotiation to configure their corresponding network layer protocol. CCP packets are exchanged to configure MPPC and MPPE.

Connection Attempt Processing with Remote Access Policies

To process a connection attempt, the parameters of the connection attempt are compared to the user name, password, and dial-in properties of the user account and the configured remote access policies.

Some general characteristics of remote access connection attempt processing are:

• If a connection attempt does not use a valid user name and password, then the connection attempt is denied.

• If there are no configured policies, then all connection attempts are denied.

• If the connection attempt does not match any of the remote access policies, then the connection attempt is denied.

• If the remote access permission of the user account for the remote access user is set to Deny Access, the connection attempt is always denied for that remote access user.

• The only time that a connection attempt is allowed is when it matches the conditions of a remote access policy; remote access permission is enabled either through the dial-in properties of the user account or through the remote access permission of the remote access policy (assuming the user’s remote access permission is set to control access through remote access policies); and the parameters of the connection attempt match or conform to the parameters and conditions of the dial-in properties of the user account and the remote access policy profile properties.

The following figure illustrates the processing of remote access connection attempts using the dial-in properties of the user account and remote access policies. The figure assumes that the user name and password sent during the authentication process match a valid user account.

Connection Attempt Processing

For more information about remote access policies and IAS, see “IAS Technical Reference.”

Broadcast Name Resolution

Enabling broadcast name resolution on a remote access server allows a remote access client to resolve full computer names and NetBIOS names of computers and other resources on a remote network that does not have either a DNS or a WINS server configured. This feature requires no configuration of the remote access clients; it is enabled by default on the remote access server.

When broadcast name resolution is enabled, the remote access server uses a NetBIOS over TCP/IP (NetBT) proxy to resolve names as follows:

1. A remote access client that must resolve a name to an IP address broadcasts a NetBIOS Name Query packet across all interfaces.

2. The remote access server receives the NetBIOS Name Query packet and checks its cache for the appropriate mapping of name to IP address.

   • If the remote access server has the appropriate mapping, it sends a NetBIOS Name Query Response packet to the remote access client.

   • If the remote access server does not have the appropriate mapping, it broadcasts the NetBIOS Name Query packet on all of its LAN interfaces. The resource whose name is being resolved sends a NetBIOS Name Query Response packet to the remote access client.

   After the remote access server routes the NetBIOS Name Query Response packet from the resource to the remote access client, the mappings remain in the cache of the server for a limited period of time. The default period of time is 10 minutes.

3. After this point, the remote access client uses the IP address of the resource to send packets to that resource.

As a result, a remote access client can resolve names of resources on a remote network as if the remote access client were on the same LAN as the resources.

Note

• By default, broadcast name resolution allows remote access clients to resolve names on a remote network, but it does not allow resources on a LAN to resolve the names of remote access clients. Remote access servers with broadcast name resolution enabled do not, by default, broadcast NetBIOS Name Query packets to interfaces that connect to the Internet. Unless you change this behavior, a remote access client cannot resolve the name of another remote access client. If you have a network that averages 10 connections or fewer, you might want to change this behavior.

Related Information

The following resources contain additional information that is relevant to this section.

• VPN Technical Reference

• IAS Technical Reference

• IPv4 Multicasting Technical Reference

• Demand Dial Routing Technical Reference

• DHCP Technical Reference

• DNS Technical Reference

• Connection Manager Technical Reference

• IETF RFC Database