Demand-Dial Routing
Demand-Dial Routing |
|
Security for demand-dial connections uses the same security features as remote access connections including:
For more information about callback, caller ID, and remote access account lockout, see "Remote Access Server" in this book and Windows 2000 Server Help.
The user account of the calling router must be a valid account in the security database of the answering router or RADIUS server (if RADIUS authentication is being used) and it must either be granted remote access permission either explicitly in the user account (remote access permission of the dial-in properties of the user account is set to Allow access) or implicitly through the remote access permission setting on a remote access policy (the remote access permission of the dial-in properties of the user account is set to Control access through Remote Access Policy and a matching remote access policy remote access permission is set to Grant remote access).
The calling router can be authenticated at the user level and the computer level.
As part of the PPP connection establishment process, the calling router's credentials must be authenticated. User-level authentication occurs through one of the following PPP authentication methods:
In all of the previously listed authentication methods except EAP-TLS, the calling router's credentials consist of a user name, a domain, and a password. In all of the previously listed authentication methods except PAP, the password is sent over the connection in an encrypted or hashed form.
In the case of EAP-TLS, the calling router's credentials consist of a user certificate that is validated by the answering router. EAP-TLS requires a public key infrastructure (PKI) to issue and validate certificates.
Computer-level authentication occurs in two cases for demand-dial routing:
Computer certificates require a public key infrastructure (PKI) to issue and validate certificates.
Authentication of the demand-dial connection can be one-way or mutual.
With one-way authentication, the calling router authenticates itself to the answering router. PAP, SPAP, CHAP, MS-CHAP v1, and EAP-MD5 authentication methods only provide for the passing of credentials from the calling router to the answering router. With one-way authentication, the calling router does not receive any verification that the answering router is the proper router. One-way authentication does not provide protection from unauthorized or masquerading answering routers.
With mutual authentication, the calling router authenticates itself to the answering router and the answering router authenticates itself to the calling router. Both ends of the connection verify the identity of the other end of the connection. MS-CHAP v2 and EAP-TLS authentication methods provide mutual authentication.
With MS-CHAP v2, both sides of the connection send a hash of a challenge string and the user password. If successful, both ends of the connection are ensured that the other end of the connection has access to the user account's password.
With EAP-TLS, the calling router sends a user certificate that is validated by the answering router and the answering router sends a computer certificate that is validated by the calling router. EAP-TLS is the most secure form of mutual authentication, however it requires a PKI.
Note
Windows NT 4.0 with the Routing and Remote Access Service (RRAS) supports a feature called two-way authentication. Two-way authentication uses one-way authentication methods to perform mutual authentication. When two-way authentication is enabled on a demand-dial interface, the calling router forces the answering router to authenticate itself after the calling router authenticates itself to the answering router. A Windows 2000 calling router never requests to authenticate a Windows NT 4.0 RRAS answering router. However, a Windows 2000 answering router authenticates itself when requested by a Windows NT 4.0 RRAS calling router.
There are two forms of encryption available for demand-dial connections: Microsoft Point-to-Point Encryption (MPPE) and Internet Protocol Security (IPSec).
All PPP connections, including PPTP but not including L2TP, can use Microsoft Point-to-Point Encryption (MPPE). MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher and is only used when either the EAP-TLS or MS-CHAP (version 1 or version 2) authentication methods are used.
MPPE can use 40-bit, 56-bit, or 128-bit encryption keys. The 40-bit key is designed for backward compatibility and international use. The 56-bit key is designed for international use and adheres to United States encryption export laws. The 128-bit key is designed for North American use. By default, the highest key strength supported by the calling router and answering router is negotiated during the connection establishment process. If the answering router requires a higher key strength than is supported by the calling router, the connection attempt is rejected.
For demand-dial connections using L2TP over IPSec, encryption is determined by the establishment of the IPSec security association (SA). The available encryption algorithms include:
The initial encryption keys are derived from the IPSec authentication process. For more information about IPSec settings for L2TP over IPSec connections, see "Virtual Private Networking" in this book. For more information about IPSec, see "Internet Protocol Security" in the Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide.
IP and IPX packet filters on the demand-dial interface can be used to restrict the types of traffic that are allowed in to (input filters) and out of (output filters) the interface. IP and IPX packet filtering only occurs when the demand-dial interface is in a connected state.
Packet filtering is especially useful for an extranet, a portion of your private intranet that is accessible to business partners over demand-dial connections. For example, when a business partner makes a demand-dial connection, packet filters on the demand-dial interface can restrict the TCP/IP traffic to only specific network segments or specific resources as identified by IP address and TCP or UDP port number.
In addition to demand-dial interface packet filtering, TCP/IP packet filters can be configured on the profile of the remote access policy configured for calling routers. While primarily designed to restrict the traffic of remote access connections, remote access policy profile–based TCP/IP packet filters can be used for demand-dial routing. Rather than configure the same IP packet filters on many demand-dial interfaces, if all the demand-dial connections share the same IP packet filters and remote access policy, then remote access policy profile packet filters allow you to configure the IP packet filters once for all the demand-dial connections.