VPN Overview

doc
Số trang VPN Overview 45 Cỡ tệp VPN Overview 310 KB Lượt tải VPN Overview 0 Lượt đọc VPN Overview 0
Đánh giá VPN Overview
4.4 ( 17 lượt)
Nhấn vào bên dưới để tải tài liệu
Để tải xuống xem đầy đủ hãy nhấn vào bên trên
Chủ đề liên quan

Nội dung

Operating System Virtual Private Networking in Windows 2000: An Overview White Paper Abstract This white paper provides an overview of virtual private network (VPN) support in Windows 2000 and discusses some of the key technologies that permit virtual private networking over public internetworks. (Mang lien ket) © 1999 Microsoft Corporation. All rights reserved. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. The BackOffice logo, Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation. Other product or company names mentioned herein may be the trademarks of their respective owners. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 0499 CONTENTS INTRODUCTION..........................................................1 Common Uses of VPNs.........................................................2 Remote Access Over the Internet 2 Connecting Networks Over the Internet 3 Connecting Computers over an Intranet 3 Basic VPN Requirements.......................................................4 TUNNELING BASICS....................................................6 Tunneling Protocols................................................................7 How Tunneling Works 7 Tunneling Protocols and the Basic Tunneling Requirements 8 Point-to-Point Protocol (PPP).................................................9 Phase 1: PPP Link Establishment 9 Phase 2: User Authentication 9 Phase 3: PPP Callback Control 11 Phase 4: Invoking Network Layer Protocol(s) 11 Data-Transfer Phase 11 Point-to-Point Tunneling Protocol (PPTP)...........................12 Layer Two Tunneling Protocol (L2TP).................................12 PPTP Compared to L2TP/IPSec 13 Advantages of L2TP/IPSec over PPTP 13 Advantages of PPTP over L2TP/IPSec 14 Internet Protocol Security (IPSec) Tunnel Mode.................14 Tunnel Types........................................................................15 Voluntary Tunneling 15 Compulsory Tunneling 16 ADVANCED SECURITY FEATURES.............................17 Symmetric vs. Asymmetric Encryption (Private Key vs. Public Key)......................................................................................17 Certificates...........................................................................17 Extensible Authentication Protocol (EAP)............................18 Transport Level Security (EAP-TLS) 18 IP Security (IPSec)...............................................................18 Negotiated Security Association 19 Authentication Header 19 Encapsulating Security Payload 19 USER ADMINISTRATION............................................20 Support in Windows 2000....................................................20 Scalability.............................................................................20 RADIUS................................................................................20 ACCOUNTING, AUDITING, AND ALARMING...............22 CONCLUSION............................................................23 For More Information............................................................23 INTRODUCTION A virtual private network (VPN) is the extension of a private network that encompasses links across shared or public networks like the Internet. A VPN enables(cho phep) you to send data between two computers across a shared or public internetwork in a manner that emulates the properties of a point-to-point private link. The act of configuring and creating a virtual private network is known as virtual private networking. To emulate(Mo phong) a point-to-point link, data is encapsulated(goi gon), or wrapped(bao boc), with a header that provides routing information(thong tin duong truyen) allowing it to traverse(di ngang qua) the shared or public transit(di qua) internetwork to reach(di den) its endpoint(diem cuoi). To emulate a private link, the data being sent is encrypted for confidentiality(can mat). Packets that are intercepted(chan) on the shared or public network are indecipherable (khong the doc ra duoc) without(tru phi) the encryption keys. The portion(phan) of the connection in which the private data is encapsulated(tomluoc) is known as the tunnel(duong ham). The portion of the connection in which the private data is encrypted is known as the virtual private network (VPN) connection. Figure 1: Virtual private network connection VPN connections allow users working at home or on the road(duong pho) to connect in a secure fashion(cach) to a remote corporate(doan the) server using the routing infrastructure(Co so ha tang) provided by a public internetwork (such as the Internet). From the user’s perspective(hinh phoi canh), the VPN connection is a point-to-point(diem den diem) connection between the user’s computer and a corporate server. The nature of the intermediate(trung gian) internetwork is irrelevant(khong thich hop) to the user because it appears(hinh thuc) as if the data is being sent over a dedicated(chuyen dung) private link. VPN technology also allows a corporation to connect to branch(chia nga) offices or to other companies over a public internetwork (such as the Internet), while maintaining(duy tri) secure communications. The VPN connection across the Internet logically(hop ly) operates as a wide area network (WAN) link between the sites. In both of these cases, the secure connection across the internetwork appears to the user as a private network communication—despite(mac du) the fact(thuc te) that this communication occurs over a public internetwork—hence(do do) the name virtual private network. VPN technology is designed to address issues(duoc dua ra) surrounding(phu can) the current(hien nay) business(giao dich) trend(xu huong) toward(huong ve) increased telecommuting(lam viec tu xa) and widely distributed(phan phoi) global(toan cau) operations, where workers must be able to connect to central resources and must be able to communicate(lien lac) with each other. To provide employees with the ability(kha nang) to connect to corporate computing resources, regardless(khong quan tam) of their location, a corporation must deploy (trien khai) a scalable(co ty le thay doi) remote access solution. Typically(dien hinh), corporations choose either an MIS department(so) solution, where an internal information systems department is charged(nhiem vu) with buying, installing, and maintaining corporate modem pools and a private network infrastructure(co so ha tang); or they choose a value-added(them vao gia tri) network (WAN) solution, where they pay(tra) an outsourced(nguyen lieu) company to buy, install, and maintain modem pools and a telecommunication(phat di bang truyen hinh) infrastructure.(co so ha tang) Neither of these solutions(giai phap) provides the necessary scalability, in terms of cost, flexible administration(quan ly), and demand(nhu cau) for connections. Therefore, it makes sense(kha nang) to replace(thay the) the modem pools and private network infrastructure with a less expensive solution based on Internet technology so that the business can focus on its core competencies. With an Internet solution, a few Internet connections through Internet service providers (ISPs) and VPN server computers can serve(phuc vu) the remote networking needs of hundreds or thousands of remote clients and branch offices. Common Uses of VPNs The next few subsections(phan con) describe the more common VPN configurations in more detail. Remote Access Over the Internet VPNs provide remote access to corporate resources over the public Internet, while maintaining privacy(su bi mat) of information. Figure 2 shows a VPN connection used to connect a remote user to a corporate intranet(mang noi bo). Figure 2: Using a VPN connection to connect a remote client to a private intranet Rather(dung hon) than making a long distance (or 1-800) call to a corporate or outsourced network access server (NAS), the user calls a local ISP. Using the connection to the local ISP, the VPN software creates a virtual private network between the dial-up user and the corporate VPN server across the Internet. Connecting Networks Over the Internet There are two methods for using VPNs to connect local area networks at remote sites:  Using dedicated lines to connect a branch office(nhanh) to a corporate LAN. Rather(dung hon) than using an expensive long-haul dedicated circuit between the branch office and the corporate hub, both the branch office and the corporate hub routers can use a local dedicated circuit and local ISP to connect to the Internet. The VPN software uses the local ISP connections and the Internet to create a virtual private network between the branch office router and corporate hub router.  Using a dial-up line to connect a branch office to a corporate LAN. Rather than having a router at the branch office make a long distance(khoang cach) (or 1-800) call to a corporate or outsourced NAS, the router at the branch office can call the local ISP. The VPN software uses the connection to the local ISP to create a VPN between the branch office router and the corporate hub router across the Internet. Figure 3: Using a VPN connection to connect two remote sites In both cases, the facilities(dieu kien thuan loi) that connect the branch office and corporate offices to the Internet are local. The corporate hub router that acts as a VPN server must be connected to a local ISP with a dedicated(chuyen dung) line. This VPN server must be listening 24 hours a day for incoming VPN traffic. Connecting Computers over an Intranet In some corporate internetworks, the departmental(thuoc cuc) data is so sensitive(de bi hong) that the department’s LAN is physically disconnected from the rest(tram dung) of the corporate internetwork. Although this protects the department’s (bo) confidential(bi mat) information, it creates information accessibility(de bi anh huong) problems for those users not physically connected to the separate(rieng biet) LAN. Figure 4: Using a VPN connection to connect to a secured or hidden network VPNs allow the department’s LAN to be physically connected to the corporate internetwork but separated(tach roi) by a VPN server. The VPN server is not acting as a router between the corporate internetwork and the department LAN. A router would connect the two networks, allowing everyone access to the sensitive(de bi anh huong) LAN. By using a VPN, the network administrator can ensure(dam bao) that only those users on the corporate internetwork who have appropriate(thich hop) credentials(uy quyen) (based on a need-to-know policy(chinh sach) within the company) can establish(thanh lap) a VPN with the VPN server and gain access to the protected resources of the department. Additionally, all communication across the VPN can be encrypted for data TUNNELING BASICS confidentiality. Those users who do not have the proper(thich hop) credentials(uy nhiem) cannot view the department LAN. Basic VPN Requirements(dieu kien can thiet) Typically, when deploying(trien khai) a remote networking solution, an enterprise(viec lam kho khan) needs to facilitate controlled access to corporate resources and information. The solution must allow roaming(cuoc di rong) or remote clients to connect to LAN resources, and the solution must allow remote offices to connect to each other to share resources and information (router-torouter connections). In addition, the solution must ensure(bao dam) the privacy(su bi mat) and integrity(tinh toan ven) of data as it traverses(di ngang qua) the Internet. The same concerns(lien quan) apply in the case of sensitive data traversing a corporate internetwork. Therefore, a VPN solution should provide at least all of the following:  User Authentication. The solution must verify the VPN client’s identity and restrict VPN access to authorized users only. It must also provide audit and accounting records to show who accessed what information and when.  Address Management. The solution must assign a VPN client’s address on the intranet and ensure that private addresses are kept private.  Data Encryption. Data carried on the public network must be rendered unreadable to unauthorized clients on the network.  Key Management. The solution must generate and refresh encryption keys for the client and the server.  Multiprotocol Support. The solution must handle common protocols used in the public network. These include IP, Internetwork Packet Exchange (IPX), and so on. An Internet VPN solution based on the Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) meets all of these basic requirements and takes advantage of the broad availability of the Internet. Other solutions, including Internet Protocol Security (IPSec), meet only some of these requirements, but remain useful for specific situations. The remainder of this paper discusses VPN concepts, protocols, and components in greater detail. Tunneling is a method of using an internetwork infrastructure to transfer data for one network over another network. The data to be transferred (or payload) can be the frames (or packets) of another protocol. Instead(thay vi) of sending a frame as it is produced by the originating(hinh thanh) node, the tunneling protocol encapsulates the frame in an additional header. The additional header provides routing information so that the encapsulated payload can traverse the intermediate internetwork. The encapsulated packets are then routed between tunnel endpoints over the internetwork. The logical path through which the encapsulated packets travel through the internetwork is called a tunnel. Once the encapsulated frames reach their destination on the internetwork, the frame is decapsulated and forwarded to its final destination. Tunneling includes this entire process (encapsulation(goi gon), transmission, and decapsulation of packets). Figure 5: Tunneling The transit(di qua) internetwork can be any internetwork—the Internet is a public internetwork(mang lien ket) and is the most widely(rong rai) known real world example. There are many examples of tunnels that are carried over corporate internetworks. And while the Internet provides one of the most pervasive(lan tran) and cost-effective(ket qua) internetworks, references to the Internet in this paper can be replaced(thay the) by any other public or private internetwork that acts as a transit(huong di) internetwork. Tunneling technologies have been in existence(ton tai) for some time. Some examples of mature(hoan thien) technologies include:  SNA tunneling over IP internetworks. When System Network Architecture (SNA) traffic is sent across a corporate IP internetwork, the SNA frame is encapsulated(goi gon) in a UDP and IP header.  IPX tunneling for Novell NetWare over IP internetworks. When an IPX packet is sent to a NetWare server or IPX router, the server or the router wraps(boc trong) the IPX packet in a UDP and IP header, and then sends it across an IP internetwork. The destination IP-to-IPX router removes the UDP and IP header and forwards the packet to the IPX destination. New tunneling technologies have been introduced in recent(gan day) years. These newer(hien dai) technologies—which are the primary focus of this paper— include:  Point-to-Point Tunneling Protocol (PPTP). PPTP allows IP, IPX, or NetBEUI traffic to be encrypted, and then encapsulated in an IP header to be sent across a corporate IP internetwork or a public IP internetwork such as the Internet.  Layer Two Tunneling Protocol (L2TP). L2TP allows IP, IPX, or NetBEUI traffic to be encrypted, and then sent over any medium that supports point-topoint datagram delivery, such as IP, X.25, Frame Relay, or ATM.  IPSec tunnel mode. IPSec tunnel mode allows IP packets to be encrypted, and then encapsulated in an IP header to be sent across a corporate IP internetwork or a public IP internetwork such as the Internet. Tunneling Protocols For a tunnel to be established(thiet lap), both the tunnel client and the tunnel server must be using the same tunneling protocol. Tunneling technology can be based on either a Layer 2 or a Layer 3 tunneling protocol. These layers correspond(tuong ung) to the Open Systems Interconnection(su lien ket) (OSI) Reference Model. Layer 2 protocols correspond to the data-link layer and use frames as their unit of exchange(trao doi). PPTP and L2TP are Layer 2 tunneling protocols; both encapsulate the payload(trong tai) in a PPP frame to be sent across an internetwork. Layer 3 protocols correspond to the Network layer, and use packets. IPSec tunnel mode is an example of a Layer 3 tunneling protocol and encapsulate IP packets in an additional IP header before sending them across an IP internetwork. How Tunneling Works For Layer 2 tunneling technologies, such as PPTP and L2TP, a tunnel is similar to a session; both of the tunnel endpoints must agree(dong y) to the tunnel and must negotiate(thuong luong) configuration variables, such as address assignment or encryption or compression(nen) parameters(tham so). In most cases, data transferred(truyen) across the tunnel is sent using a datagram-based protocol. A tunnel maintenance(duy tri) protocol is used as the mechanism to manage the tunnel. Layer 3 tunneling technologies generally assume(xac nhan) that all of the configuration issues(dua ra) are preconfigured, often by manual processes. For these protocols, there may be no tunnel maintenance(duy tri) phase(giai doan). For Layer 2 protocols (PPTP and L2TP), however, a tunnel must be created, maintained, and then terminated.(ket thuc) Once the tunnel is established(thiet lap), tunneled data can be sent. The tunnel client or server uses a tunnel data transfer protocol to prepare(chuan bi) the data for transfer. For example, when the tunnel client sends a payload(trong tai) to the tunnel server, the tunnel client first appends(buoc vao) a tunnel data transfer protocol header to the payload. The client then sends the resulting encapsulated payload across the internetwork, which routes it to the tunnel server. The tunnel server accepts(chap nhan) the packets, removes the tunnel data transfer protocol header, and forwards the payload to the target network. Information sent between the tunnel server and the tunnel client behaves(chay) similarly. Tunneling Protocols and the Basic Tunneling Requirements(nhu cau) Because they are based on the well-defined PPP protocol, Layer 2 protocols (such as PPTP and L2TP) inherit(thua ke) a suite of useful features. These features, and their Layer 3 counterparts address the basic VPN requirements, as outlined(phat thao) below.  User Authentication. Layer 2 tunneling protocols inherit the user authentication schemes(luoc do) of PPP, including the EAP methods discussed below. Many Layer 3 tunneling schemes assume(thua nhan) that the endpoints were well known (and authenticated) before the tunnel was established. An exception to this is IPSec Internet Key Exchange (IKE) negotiation, which provides mutual(qua lai) authentication of the tunnel endpoints. Most IPSec implementations(su thi hanh) including Windows 2000 support computer-based certificates(giay chung nhan) only, rather(dung hon la) than user certificates. As a result, any user with access to one of the endpoint computers can use the tunnel. This potential(tiem nang) security weakness(nhuoc diem) can be eliminated(loai tru) when IPSec is paired(lien ket) with a Layer 2 protocol such as L2TP.  Token card support. Using the Extensible(co the mo rong) Authentication Protocol (EAP), Layer 2 tunneling protocols can support a wide variety(da dang) of authentication methods, including one-time(truoc day) passwords, cryptographic(mat ma) calculators(may tinh), and smart(thong minh) cards. Layer 3 tunneling protocols can use similar methods; for example, IPSec defines public key certificate(giay chung nhan) authentication in its IKE negotiation.  Dynamic address assignment. Layer 2 tunneling supports dynamic assignment of client addresses based on the Network Control Protocol (NCP) negotiation mechanism. Generally, Layer 3 tunneling schemes assume that an address has already(roi) been assigned prior(truoc khi) to initiation of the tunnel. Schemes for assignment of addresses in IPSec tunnel mode are currently(hien nay) under development and are not yet available.  Data compression(nen). Layer 2 tunneling protocols support PPP-based compression schemes. For example, the Microsoft implementations(thuc hien) of both PPTP and L2TP use Microsoft Point-to-Point Compression (MPPC). The IETF is investigating(dieu tra nghien cua) similar mechanisms (such as IP Compression) for the Layer 3 tunneling protocols.  Data encryption(ma hoa). Layer 2 tunneling protocols support PPP-based data encryption mechanisms. The Microsoft implementation of PPTP supports optional(tuy chon) use of Microsoft Point-to-Point Encryption (MPPE), based on the RSA/RC4 algorithm. Layer 3 tunneling protocols can use similar methods; for example, IPSec defines several optional(tuy chon) data encryption methods, which are negotiated(thuong luong) during the IKE exchange. The Microsoft implementation(thi hanh) of the L2TP protocol uses IPSec encryption to protect the data stream from the VPN client to the VPN server.  Key Management. MPPE, a Layer 2 encryption mechanism, relies(dua vao) on the initial key generated during user authentication, and then refreshes it periodically. IPSec explicitly(ro rang) negotiates(thoa thuan) a common key during(trong luc) the IKE exchange, and also refreshes it periodically(trong thoi gian dinh ki).  Multiprotocol support. Layer 2 tunneling supports multiple payload protocols, which makes it easy for tunneling clients to access their corporate networks using IP, IPX, NetBEUI, and so on. In contrast(tuong phan), Layer 3 tunneling protocols, such as IPSec tunnel mode, typically support only target(nham muc tieu) networks that use the IP protocol. Point-to-Point Protocol (PPP) Because the Layer 2 protocols depend(phu thuoc) heavily(nang ne) on the features originally specified for PPP, it is worth examining this protocol more closely. PPP was designed to send data across dial-up or dedicated point-topoint connections. PPP encapsulates IP, IPX, and NetBEUI packets within PPP frames, and then transmits the PPP-encapsulated packets across a point-to-point link. PPP is used between a dial-up client(tram quay so) and an NAS. There are four distinct phases of negotiation in a PPP dial-up session. Each of these four phases must complete successfully before the PPP connection is ready to transfer user data. Phase 1: PPP Link Establishment PPP uses Link Control Protocol (LCP) to establish, maintain(duy tri), and end the physical connection. During(trong thoi gian) the initial LCP phase, basic communication options are selected. During the link establishment phase (Phase 1), authentication protocols are selected, but they are not actually implemented until the connection authentication phase (Phase 2). Similarly, during LCP a decision is made as to whether the two peers will negotiate the use of compression and/or encryption. The actual choice of compression and encryption algorithms and other details occurs during Phase 4. Phase 2: User Authentication In the second phase, the client PC presents the user’s credentials to the remote access server. A secure authentication scheme provides protection against replay attacks and remote client impersonation. A replay attack occurs(xay ra) when a third party monitors a successful connection and uses captured packets to play back the remote client’s response so that it can gain an authenticated connection. Remote client impersonation occurs when a third party takes over an authenticated connection. The intruder waits until the connection has been authenticated, and then traps the conversation parameters, disconnects the authenticated user, and takes control of the authenticated connection. Most implementations of PPP provide limited authentication methods, typically Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and Microsoft Challenge Handshake Authentication Protocol (MS-CHAP).  Password Authentication Protocol (PAP). PAP is a simple, clear-text authentication scheme. The NAS requests the user name and password, and PAP returns them in clear text(van ban ro) (unencrypted). Obviously, this authentication scheme is not secure because a third party could capture the user’s name and password and use it to get subsequent access to the NAS and all of the resources provided by the NAS. PAP provides no protection against replay attacks or remote client impersonation once the user’s password is compromised.  Challenge-Handshake Authentication Protocol (CHAP). CHAP is an encrypted authentication mechanism that avoids transmission of the actual password on the connection. The NAS sends a challenge, which consists of a session ID and an arbitrary challenge string, to the remote client. The remote client must use the MD5 one-way hashing algorithm to return the user name and an encryption of the challenge, session ID, and the client’s password. The user name is sent unhashed. CHAP is an improvement over PAP because the clear-text password is not sent over the link. Instead, the password is used to create an encrypted hash from the original challenge. The server knows the client’s clear-text password and can, therefore, replicate the operation and compare the result to the password sent in the client’s response. CHAP protects against replay attacks by using an arbitrary challenge string for each authentication attempt. CHAP protects against remote client impersonation by unpredictably sending repeated challenges to the remote client throughout the duration of the connection.  Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP). MS-CHAP is an encrypted authentication mechanism very similar to CHAP. As in CHAP, the NAS sends a challenge, which consists of a session ID and an arbitrary challenge string, to the remote client. The remote client must return the user name and an encrypted form of the challenge string, the session ID, and the MD4-hashed password. This design, which uses a hash of the MD4 hash of the password, provides an additional level of security because it allows the server to store hashed passwords instead of clear-text passwords. MS-CHAP also provides additional error codes, including a password expired code, and additional encrypted client-server messages that permit users to change their passwords. In MS-CHAP, both the access client and the NAS independently generate an initial key for subsequent data encryption by MPPE. Therefore, MS-CHAP authentication is required to enable MPPE-based data encryption.  MS-CHAP version 2 (MS-CHAP v2). MS-CHAP v2 is an updated encrypted authentication mechanism that provides stronger security for the exchange of user name and password credentials and determination of encryption keys. With MS-CHAP v2, the NAS sends a challenge to the access client that consists of a session identifier and an arbitrary challenge string. The remote access client sends a response that contains the user name, an arbitrary peer challenge string, and an encrypted form of the received challenge string, the peer challenge string, the session identifier, and the user's password. The NAS checks the response from the client and sends back a response containing an indication of the success or failure of the connection attempt and an authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user's password. The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection. Using this process, MS-CHAP v2 provides mutual authenticationthe NAS verifies that the access client has knowledge of the user's password and the access client verifies that the NAS has knowledge of the user's password. MS-CHAP v2 also determines two encryption keys, one for data sent and one for data received. During phase 2 of PPP link configuration, the NAS collects the authentication data, and then validates the data against its own user database or a central authentication database server, such as one maintained by a Windows domain controller, or the authentication data is sent to a Remote Authentication Dial-in User Service (RADIUS) server. Phase 3: PPP Callback Control The Microsoft implementation of PPP includes an optional callback control phase. This phase uses the Callback Control Protocol (CBCP) immediately after the authentication phase. If configured for callback, both the remote client and NAS disconnect after authentication. The NAS then calls the remote client back at a specified phone number. This provides an additional level of security to dialup networking. The NAS allows connections from remote clients physically residing at specific phone numbers only. Phase 4: Invoking Network Layer Protocol(s) Once the previous phases have been completed, PPP invokes the various network control protocols (NCPs) that were selected during the link establishment phase (Phase 1) to configure protocols used by the remote client. For example, during this phase the IP control protocol (IPCP) can assign a dynamic address to the dial-in user. In the Microsoft implementation of PPP, the compression control protocol is used to negotiate both data compression (using MPPC) and data encryption (using MPPE) for because both are implemented in the same routine. Data-Transfer Phase Once the four phases of negotiation have been completed, PPP begins to forward data to and from the two peers. Each transmitted data packet is wrapped in a PPP header which is removed by the receiving system. If data compression was selected in phase 1 and negotiated in phase 4, data is compressed before transmission. If data encryption is selected and negotiated, data is encrypted before transmission. Point-to-Point Tunneling Protocol (PPTP) PPTP is a Layer 2 protocol that encapsulates PPP frames in IP datagrams for transmission over an IP internetwork, such as the Internet. PPTP can be used for remote access and router-to-router VPN connections. PPTP is documented in RFC 2637. The Point-to-Point Tunneling Protocol (PPTP) uses a TCP connection for tunnel maintenance and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted and/or compressed. Figure 6 shows the structure of a PPTP packet containing user data. Figure 6. Structure of a PPTP packet containing user data Layer Two Tunneling Protocol (L2TP) L2TP is a combination of PPTP and Layer 2 Forwarding (L2F), a technology proposed by Cisco Systems, Inc. L2TP represents the best features of PPTP and L2F. L2TP encapsulates PPP frames to be sent over IP, X.25, Frame Relay, or Asynchronous Transfer Mode (ATM) networks. When configured to use IP as its datagram transport, L2TP can be used as a tunneling protocol over the Internet. L2TP is documented in RFC 2661. L2TP over IP internetworks uses UDP and a series of L2TP messages for tunnel maintenance. L2TP also uses UDP to send L2TP-encapsulated PPP frames as the tunneled data. The payloads of encapsulated PPP frames can be encrypted and/or compressed. Figure 7 shows the structure of an L2TP packet containing user data. Figure 7. Structure of an L2TP packet containing user data In Windows 2000, IPSec Encapsulating Security Payload (ESP) is used to encrypt the L2TP packet. This is known as L2TP/IPSec. The result after applying ESP is shown in Figure 8. Figure 8. Encryption of an L2TP packet with IPSec ESP PPTP Compared to L2TP/IPSec Both PPTP and L2TP/IPSec use PPP to provide an initial envelope for the data, and then append additional headers for transport through the internetwork. However, there are the following differences:  With PPTP, data encryption begins after the PPP connection process (and, therefore, PPP authentication) is completed. With L2TP/IPSec, data encryption begins before the PPP connection process by negotiating an IPSec security association.  PPTP connections use MPPE, a stream cipher that is based on the RivestShamir-Aldeman (RSA) RC-4 encryption algorithm and uses 40, 56, or 128bit encryption keys. Stream ciphers encrypt data as a bit stream. L2TP/IPSec connections use the Data Encryption Standard (DES), which is a block cipher that uses either a 56-bit key for DES or three 56-bit keys for 3-DES. Block ciphers encrypt data in discrete blocks (64-bit blocks, in the case of DES).  PPTP connections require only user-level authentication through a PPP-based authentication protocol. L2TP/IPSec connections require the same user-level authentication and, in addition, computer-level authentication using computer certificates. Advantages of L2TP/IPSec over PPTP The following are the advantages of using L2TP/IPSec over PPTP in Windows 2000:  IPSec provides per packet data authentication (proof that the data was sent by the authorized user), data integrity (proof that the data was not modified in transit), replay protection (prevention from resending a stream of captured packets), and data confidentiality (prevention from interpreting captured packets without the encryption key). By contrast, PPTP provides only perpacket data confidentiality.  L2TP/IPSec connections provide stronger authentication by requiring both computer-level authentication through certificates and user-level authentication through a PPP authentication protocol.  PPP packets exchanged during user-level authentication are never sent in an unencrypted form because the PPP connection process for L2TP/IPSec occurs after the IPSec security associations (SAs) are established. If intercepted, the PPP authentication exchange for some types of PPP authentication protocols can be used to perform offline dictionary attacks and determine user passwords. By encrypting the PPP authentication exchange, offline dictionary attacks are only possible after the encrypted packets have been successfully decrypted. Advantages of PPTP over L2TP/IPSec The following are advantages of PPTP over L2TP/IPSec in Windows 2000:  PPTP does not require a certificate infrastructure. L2TP/IPSec requires a certificate infrastructure for issuing computer certificates to the VPN server computer (or other authenticating server) and all VPN client computers.  PPTP can be used by computers running Windows XP, Windows 2000, Windows NT version 4.0, Windows Millennium Edition (ME), Windows 98, and Windows 95 with the Windows Dial-Up Networking 1.3 Performance & Security Update. L2TP/IPSec can only be used with Windows XP and Windows 2000 VPN clients. Only these clients support the L2TP protocol, IPSec, and the use of certificates.  PPTP clients and server can be placed behind a network address translator (NAT) if the NAT has the appropriate editors for PPTP traffic. L2TP/IPSecbased VPN clients or servers cannot be placed behind a NAT because Internet Key Exchange (IKE) (the protocol used to negotiate SAs) and IPSecprotected traffic are not NAT-translatable. Internet Protocol Security (IPSec) Tunnel Mode IPSec is a Layer 3 protocol standard that supports the secured transfer of information across an IP internetwork. IPSec is more fully described in the Advanced Security section below. However, one aspect of IPSec should be discussed in the context of tunneling protocols. In addition to its definition of encryption mechanisms for IP traffic, IPSec defines the packet format for an IP over IP tunnel mode, generally referred to as IPSec tunnel mode. An IPSec tunnel consists of a tunnel client and a tunnel server, which are both configured to use IPSec tunneling and a negotiated encryption mechanism. IPSec tunnel mode uses the negotiated security method (if any) to encapsulate and encrypt entire IP packets for secure transfer across a private or public IP internetwork. The encrypted payload is then encapsulated again with a plain-text IP header and sent on the internetwork for delivery to the tunnel server. Upon receipt of this datagram, the tunnel server processes and discards the plain-text IP header, and then decrypts its contents to retrieve the original payload IP packet. The payload IP packet is then processed normally and routed to its destination on the target network. IPSec tunnel mode has the following features and limitations:  It supports IP traffic only.  It functions at the bottom of the IP stack; therefore, applications and higher-level protocols inherit its behavior.  It is controlled by a security policy—a set of filter-matching rules. This security policy establishes the encryption and tunneling mechanisms available, in order of preference, and the authentication methods available, also in order of preference. As soon as there is traffic, the two computers perform mutual authentication, and then negotiate the encryption methods to be used. Thereafter, all traffic is encrypted using the negotiated encryption mechanism, and then wrapped in a tunnel header. For more information about IPSec, see "Advanced Security" in this paper. Tunnel Types Tunnels can be created in various ways.  Voluntary tunnels: A user or client computer can issue a VPN request to configure and create a voluntary tunnel. In this case, the user’s computer is a tunnel endpoint and acts as the tunnel client.  Compulsory tunnels: A VPN-capable dial-up access server configures and creates a compulsory tunnel. With a compulsory tunnel, the user’s computer is not a tunnel endpoint. Another device, the dial-up access server, between the user’s computer and the tunnel server is the tunnel endpoint and acts as the tunnel client. To date, voluntary tunnels are proving to be the more popular type of tunnel. The following sections describe each of these tunnel types in greater detail. Voluntary Tunneling Voluntary tunneling occurs when a workstation or routing server uses tunneling client software to create a virtual connection to the target tunnel server. To accomplish this, the appropriate tunneling protocol must be installed on the client computer. For the protocols discussed in this paper, voluntary tunnels require an IP connection (either LAN or dial-up). In a dial-up situation, the client must establish a dial-up connection to the internetwork before the client can set up a tunnel. This is the most common case. The best example of this is the dial-up Internet user, who must dial an ISP and obtain an Internet connection before a tunnel over the Internet can be created. For a LAN-attached computer, the client already has a connection to the internetwork that can provide routing of encapsulated payloads to the chosen LAN tunnel server. This would be the case for a client on a corporate LAN that initiates a tunnel to reach a private or hidden subnet on that LAN (such as the Human Resources network discussed previously). It is a common misconception that VPN connections require a dial-up connection. They require only IP connectivity between the VPN client and VPN server. Some clients (such as home computers) use dial-up connections to the Internet to establish IP transport. This is a preliminary step in preparation for creating a tunnel and is not part of the tunnel protocol itself. Compulsory Tunneling A number of vendors that sell dial-up access servers have implemented the ability to create a tunnel on behalf of a dial-up client. The computer or network device providing the tunnel for the client computer is variously known as a Front End Processor (FEP) in PPTP, an L2TP Access Concentrator (LAC) in L2TP, or an IP Security Gateway in IPSec. For the purposes of this white paper, the term FEP is used to describe this functionality, regardless of the tunneling protocol. To carry out its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer connects. In the Internet example, the client computer places a dial-up call to a tunnelingenabled NAS at the ISP. For example, a corporation may have contracted with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a tunnel server connected to the corporation’s private network, thus consolidating calls from geographically diverse locations into a single Internet connection at the corporate network. This configuration is known as compulsory tunneling because the client is compelled to use the tunnel created by the FEP. Once the initial connection is made, all network traffic to and from the client is automatically sent through the tunnel. With compulsory tunneling, the client computer makes a single PPP connection. When a client dials into the NAS, a tunnel is created and all traffic is automatically routed through the tunnel. An FEP can be configured to tunnel all dial-up clients to a specific tunnel server. The FEP could also tunnel individual clients, based on the user name or destination. ADVANCED SECURITY FEATURES Unlike the separate tunnels created for each voluntary client, a tunnel between the FEP and the tunnel server can be shared by multiple dial-up clients. When a second client dials into the access server (FEP) to reach a destination for which a tunnel already exists, there is no need to create a new instance of the tunnel between the FEP and tunnel server. Instead, the data traffic for the new client is carried over the existing tunnel. Since there can be multiple clients in a single tunnel, the tunnel is not terminated until the last user of the tunnel disconnects. Because the Internet facilitates the creation of VPNs from anywhere, networks need strong security features to prevent unwelcome access to private networks and to protect private data as it traverses the public network. User authentication and data encryption have already been discussed. This section provides a brief look ahead to the stronger authentication and encryption capabilities that are available with EAP and IPSec. Symmetric vs. Asymmetric Encryption (Private Key vs. Public Key) Symmetric, or private-key, encryption (also known as conventional encryption) is based on a secret key that is shared by both communicating parties. The sending party uses the secret key as part of the mathematical operation to encrypt (or encipher) plain text to cipher text. The receiving party uses the same secret key to decrypt (or decipher) the cipher text to plain text. Examples of symmetric encryption schemes are the RSA RC4 algorithm (which provides the basis for Microsoft Point-to-Point Encryption (MPPE), Data Encryption Standard (DES), the International Data Encryption Algorithm (IDEA), and the Skipjack encryption technology proposed by the United States government (and implemented in the Clipper chip). Asymmetric, or public-key, encryption uses two different keys for each user: one is a private key known only to this one user; the other is a corresponding public key, which is accessible to anyone. The private and public keys are mathematically related by the encryption algorithm. One key is used for encryption and the other for decryption, depending on the nature of the communication service being implemented. In addition, public key encryption technologies allow digital signatures to be placed on messages. A digital signature uses the sender’s private key to encrypt some portion of the message. When the message is received, the receiver uses the sender’s public key to decipher the digital signature to verify the sender’s identity. Certificates With symmetric encryption, both sender and receiver have a shared secret key. The distribution of the secret key must occur (with adequate protection) prior to any encrypted communication. However, with asymmetric encryption, the sender uses a private key to encrypt or digitally sign messages, while the receiver uses a public key to decipher these messages. The public key can be freely distributed to anyone who needs to receive the encrypted or digitally signed messages. The sender needs to carefully protect the private key only. To secure the integrity of the public key, the public key is published with a certificate. A certificate (or public key certificate) is a data structure that is digitally signed by a certification authority (CA)—an authority that users of the certificate can trust. The certificate contains a series of values, such as the certificate name and usage, information identifying the owner of the public key, the public key itself, an expiration date, and the name of the certificate authority. The CA uses its private key to sign the certificate. If the receiver knows the public key of the certificate authority, the receiver can verify that the certificate is indeed from the trusted CA and, therefore, contains reliable information and a valid public key. Certificates can be distributed electronically (through Web access or email), on smart cards, or on floppy disks. In summary, public key certificates provide a convenient, reliable method for verifying the identity of a sender. IPSec can optionally use this method for end-toend authentication. Remote access servers can use public key certificates for user authentication, as described in the section "Transport Level Security (EAPTLS)." Extensible Authentication Protocol (EAP) As stated previously, most implementations of PPP provide very limited authentication methods. EAP is an IETF standard extension to PPP that allows for arbitrary authentication mechanisms for the validation of a PPP connection. EAP was designed to allow the dynamic addition of authentication plug-in modules at both the client and server ends of a connection. This allows vendors to supply a new authentication scheme at any time. EAP provides the highest flexibility in authentication uniqueness and variation. EAP is documented in RFC 2284 and is supported in Microsoft Windows 2000. Transport Level Security (EAP-TLS) EAP-TLS is an IETF standard (RFC 2716) for a strong authentication method based on public-key certificates. With EAP-TLS, a client presents a user certificate to the dial-in server, and the server presents a server certificate to the client. The first provides strong user authentication to the server; the second provides assurance that the user has reached the server that he or she expected. Both systems rely on a chain of trusted authorities to verify the validity of the offered certificate. The user’s certificate could be stored on the dial-up client computer or stored in an external smart card. In either case, the certificate cannot be accessed without some form of user identification (PIN number or name-and-password exchange) between the user and the client computer. This approach meets the somethingyou-know-plus-something-you-have criteria recommended by most security experts. EAP-TLS is the specific EAP method implemented in Microsoft Windows 2000. Like MS-CHAP and MS-CHAP v2, EAP-TLS returns an encryption key to enable subsequent data encryption by MPPE. IP Security (IPSec) IP Security (IPSec) was designed by the IETF as an end-to-end mechanism for ensuring data security in IP-based communications. IPSec has been defined in a series of RFCs, notably RFCs 2401, 2402, and 2406, which define the overall architecture, an authentication header to verify data integrity, and an encapsulation security payload for both data integrity and data encryption. IPSec defines two functions that ensure confidentiality: data encryption and data integrity. As defined by the IETF, IPSec uses an authentication header (AH) to provide source authentication and integrity without encryption, and the Encapsulating Security Payload (ESP) to provide authentication and integrity along with encryption. With IPSec, only the sender and recipient know the security key. If the authentication data is valid, the recipient knows that the communication came from the sender and that it was not changed in transit. IPSec can be envisioned as a layer below the TCP/IP stack. This layer is controlled by a security policy on each computer and a negotiated security association between the sender and receiver. The policy consists of a set of filters and associated security behaviors. If a packet’s IP address, protocol, and port number match a filter, the packet is subject to the associated security behavior. Negotiated Security Association The first such packet triggers a negotiation of a security association(su ket hop) between the sender and receiver. Internet Key Exchange (IKE) is the standard protocol for this negotiation(su thu xep). During an IKE negotiation, the two computers agree on authentication and data-security methods, perform mutual authentication, and then generate a shared key for subsequent data encryption. After the security association has been established, data transmission can proceed for each computer, applying data security treatment(xu ly) to the packets that it transmits to the remote receiver. The treatment can simply ensure the integrity of the transmitted data, or it can encrypt it as well. Authentication Header Data integrity and data authentication for IP payloads can be provided by an authentication header located between the IP header and the transport header. The authentication header includes authentication data and a sequence number, which together are used to verify the sender, ensure that the message has not been modified in transit, and prevent a replay attack. The IPSec authentication header provides no data encryption; clear-text messages can be sent, and the authentication header ensures that they USER ADMINISTRATION originated from a specific user and were not modified in transit. Encapsulating Security Payload For both data confidentiality and protection from third-party capture, ESP provides a mechanism to encrypt the IP payload. ESP also provides data authentication and data integrity services; therefore, ESP is an alternative to AH when data confidentiality is required. In selecting a VPN technology, it is important to consider administrative issues. Large networks need to store per-user directory information in a centralized data store, or directory service, so that administrators and applications can add to, modify, or query this information. Each access or tunnel server could maintain its own internal data base of per-user properties, such as names, passwords, and dial-in permission attributes. However, because it is administratively prohibitive to maintain multiple user accounts on multiple servers and keep them simultaneously current, most administrators set up a master account database at the directory server or primary domain controller, or on a RADIUS server. Support in Windows 2000 The Routing and Remote Access service in Windows 2000 Server is designed to work with per-user information stored locally or on a domain controller or on a RADIUS server. Using a domain controller simplifies system administration because dial-up permissions are a subset of the per-user information that the administrator is already managing in a single database. The Routing and Remote Access service is both a dial-up remote access server and VPN server for PPTP and L2TP connections. Consequently, these Layer 2 VPN solutions inherit all of the management infrastructure already in place for dial-up networking. In Windows 2000, the Routing and Remote Access service takes advantage of the new Active Directory, an enterprise-wide, replicated database based on the Lightweight Directory Access Protocol (LDAP). LDAP is an industry-standard protocol for accessing directory services and was developed as a simpler alternative to the X.500 DAP protocol. LDAP is extensible, vendor-independent, and standards-based. This integration with the Active Directory allows an administrator to assign a variety of connection properties for dial-up or VPN sessions to individual users or groups. These properties can define per-user filters, required authentication or encryption methods, time-of-day limitations, and so on. Scalability Redundancy and load balancing is accomplished using round-robin DNS to split requests among a number of VPN tunnel servers that share a common security perimeter. A security perimeter has one external DNS name—for example, microsoft.com—but several IP addresses, and loads are randomly distributed ACCOUNTING, AUDITING, AND ALARMING across all of the IP addresses. All servers can authenticate access requests against a shared database, such as a Windows domain controller. Windows domain databases are replicated between domain controllers. RADIUS The Remote Authentication Dial-in User Service (RADIUS) protocol is a popular method for managing remote user authentication and authorization. RADIUS is a lightweight, UDP-based protocol. RADIUS servers can be located anywhere on the Internet and provide authentication (including PPP PAP, CHAP, MS-CHAP, MS-CHAP v2, and EAP) and authorization for access servers such as NASes and VPN servers. In addition, RADIUS servers can provide a proxy service to forward authentication requests to distant RADIUS servers. For example, many ISPs have joined consortia to allow roaming subscribers to use local services from the nearest ISP for dial-up access to the Internet. These roaming alliances take advantage of the RADIUS proxy service. If an ISP recognizes a user name as being a subscriber to a remote network, the ISP uses a RADIUS proxy to forward the access request to the appropriate network. To properly administer a VPN system, network administrators should be able to track who uses the system, how many connections are made, unusual activity, error conditions, and situations that may indicate equipment failure. This information can be used for billing, auditing, and alarm or error-notification purposes. For example, an administrator may need to know who connected to the system and for how long in order to construct billing data. Unusual activity may indicate a misuse of the system or inadequate system resources. Real-time monitoring of equipment (for example, unusually high activity on one modem and inactivity on another) may generate alerts to notify the administrator of a modem failure. The tunnel server should provide all of this information, and the system should provide event logs, reports, and a data storage facility to handle the data appropriately. The RADIUS protocol defines a suite of call-accounting requests that are independent from the authentication requests discussed above. These messages from the NAS to the RADIUS server request the latter to generate accounting records at the start of a call, the end of a call, and at predetermined intervals during a call. The Routing and Remote Access service can be configured to generate these RADIUS accounting requests separately from connection requests (which could go to the domain controller or to a RADIUS server). This allows an administrator to configure an accounting RADIUS server, whether RADIUS is used for authentication or not. An accounting server can then collect records for every VPN connection for later analysis. A number of third-parties CONCLUSION FOR MORE INFORMATION have already written billing and audit packages that read these RADIUS accounting records and produce various useful reports. VPNs allow users or corporations to connect to remote servers, branch offices, or to other companies over a public internetwork, while maintaining secure communications. In all of these cases, the secure connection appears to the user as a private network communication—despite the fact that this communication occurs over a public internetwork. VPN technology is designed to address issues surrounding the current business trend toward increased telecommuting and widely distributed global operations, where workers must be able to connect to central resources and communicate with each other. This paper provides an overview of VPN and describes the basic requirements of useful VPN technologies: user authentication, address management, data encryption, key management, and multiprotocol support. It discusses how Layer 2 protocols, specifically PPTP and L2TP, meet these requirements. For the latest information on Windows 2000 Server, visit the Web site at http://www.microsoft.com/windows2000/server/default.asp. Operating System Microsoft Privacy Protected Network Access: Virtual Private Networking and Intranet Security White Paper Abstract The Microsoft® Windows® operating system includes technology to secure communications over private and public networks. Current products from Microsoft provide tools to provide security services at the link and transport layers, as well as providing application-layer security for electronic mail. Link layer security encrypts data in transit within remote access sessions as well as within branch network connections. Transport layer security permits protection of TCP-based protocols, including World Wide Web sessions. Windows 2000 will, in addition, provide end-to-end network layer security services through Internet Protocol (IP) Security, or IPSec, which permits security services to be applied on internal networks. This paper focuses on link layer and end-to-end security. It explains the Microsoft commitment to support Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and IPSec protocol to address diverse customer requirements. The paper also details Microsoft plans for implementing these protocols on the Windows operating systems. © 1999 Microsoft Corporation. All rights reserved. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Microsoft, Active Directory, MSN, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 0599 CONTENTS INTRODUCTION..........................................................1 PROTOCOLS FOR SECURE NETWORK COMMUNICATIONS.....................................................3 IPSec Design Goals and Overview........................................3 L2TP Design Goals and Overview.........................................4 PPTP Design Goals and Overview........................................4 MICROSOFT'S POSITIONS ON IPSEC, L2TP/IPSEC, AND PPTP...........................................................................6 IPSec......................................................................................6 L2TP/IPSec............................................................................6 PPTP......................................................................................7 MICROSOFT SUPPORT FOR IPSEC, L2TP, AND PPTP. . .8 IPSec......................................................................................8 L2TP.......................................................................................9 PPTP......................................................................................9 Remote Access Policy Management.....................................9 Client Management..............................................................10 PLATFORM SUPPORT FOR SECURE NETWORK COMMUNICATIONS...................................................11 FOR MORE INFORMATION........................................12 INTRODUCTION Network security is increasing in importance for companies of all sizes. Whether to protect information in transit in remote access sessions, branch network connections, or internal networks, solutions for this form of security are essential.(yeu to can thiet) In general, security is not a single product or technology but an integration(su hoa hop) of several(khac nhau) technologies combined with management policy that provides protection balanced with acceptable(co the chap nhan) risks. Microsoft takes security seriously(that su) and is working on a number of initiatives(su khoi dau) to provide customers with the technology and tools needed to easily define and manage security policy. Security services include confidentiality(su can mat), integrity(tinh toan ven) protection, authentication, authorization(su cho phep), and replay protection. Among(trong so) these tools are network encryption services that help minimize risks(rui ro) associated(ket hop) with transmitting sensitive(than trong) information over public and privately managed networks. Microsoft also takes total cost of ownership(quyen so huu) seriously and is committed to providing standards based solutions that maximize communications interoperability and flexibility using the Windows platform(dat tren nen). There are three major models for securing the network and Microsoft supports each of these:  Today, many applications are hosted for access across public and privately managed networks, secured through transport layer security technologies such as HTTPS, SOCKS, or SSL. Transport layer security as provided by SSL/TLS means that TCP-based applications are written specifically to use these security services. Microsoft supports SSL/TLS extensively (rong rai) across its products. However(tuy nhien), SSL/TLS applications are not well suited to centralized management because these services are frequently applied on a page-bypage basis. SOCKS is an authenticated firewall traversal protocol that provides for extensible(co the) authentication, as well as granular authorization for both incoming and outgoing sessions. SOCKS V, which is not supported by Microsoft, applies both to TCP and UDP-based protocols, and is amenable to centralized management. As a result, SSL/TLS, and SOCKS technologies are complementary and can be used together to provide transport layer security within virtual private networks and extranets. Microsoft VPN Overview White Paper 1 PROTOCOLS FOR SECURE NETWORK COMMUNICATIONS  Many companies use private or trusted network infrastructures including internal and outsourced cable-plants and wide area networks, which offer a level of privacy by virtue of physical security. Alone, these networks do not protect against inadvertent or intentional viewing of information as it passes over a network. With most security breaches occurring within a company network, additional technology is required to protect information from theft and attack.  End-to-end network security consists of security techniques and protocols that transparently secure communications requiring application awareness. Careful network design and configuration is required to achieve this security. These tools are generally managed through administrative policy so that communications are safely protected as they travel across a network, without the knowledge or involvement of applications or end users. All three models have been discussed in the industry under the broad category of Virtual Private Networking (VPN). While it is true that each model provides some level of private networking, this broad definition is a bit confusing. As such, Microsoft has adopted a more restricted definition of the term, and uses “VPN” to refer to providing security across a public or untrusted network infrastructure. This includes:  Secure remote access from client-to-gateway, either through Internet connections or within private or outsourced networks  Secure gateway-to-gateway connections, across the Internet or across private or outsourced networks. Additionally, Microsoft is leading the industry with the first operating system– integrated, solution for securing end-to-end communications within a private network. Windows 2000 integrates IPSec with the Active Directory™ directory service to deliver central control of policy based security administration. This paper discusses the Microsoft direction for both the VPN and end-to-end models for secure networking. It describes the key differences between the leading network protocols, discusses the Microsoft position relative to these protocols, and explains how Microsoft is supporting these protocols in its operating systems. Over the past few years, a number of protocols have emerged(ro Microsoft VPN Overview White Paper 2 net) that are categorized(phan loai) as VPN protocols and that encrypt communications. These include:  Internet Protocol Security (IPSec)—an architecture, protocol, and related Internet Key Exchange (IKE) protocol, which are described by IETF RFCs 2401-2409.  Layer 2 Forwarding (L2F)—created by Cisco Systems.  Layer 2 Tunneling Protocol (L2TP)—a combination of PPTP and L2F, which evolved through the IETF standards process.  Point-to-Point Tunneling Protocol (PPTP)—Created by the PPTP Industry Forum (US Robotics(now 3Com), 3Com/Primary Access, Ascend, Microsoft, and ECI Telematics). While IPSec, L2TP, and PPTP are viewed by many as competing technologies, these protocols offer different capabilities that are appropriate for different uses. To understand this, it is useful to consider the design goals and technical differences of the protocols. IPSec Design Goals and Overview IPSec provides integrity protection, authentication, and (optional) privacy and replay protection services for IP traffic. IPSec packets are of two types:  IP protocol 50 called the Encapsulating Security Payload (ESP) format, which provides privacy, authenticity, and integrity.  IP protocol 51 called the Authentication Header (AH) format, which only provides integrity and authenticity for packets, but not privacy IPSec can be used in two modes; transport mode which secures an existing IP packet from source to destination, and tunnel mode which puts an existing IP packet inside a new IP packet that is sent to a tunnel end point in the IPSec format. Both transport and tunnel mode can be encapsulated in ESP or AH headers. IPSec transport mode was designed to provide security for IP traffic end-to-end between two communicating systems, for example to secure a TCP connection or a UDP datagram. IPSec tunnel mode was designed primarily for network midpoints, routers, or gateways, to secure other IP traffic inside an IPSec tunnel that connects one private IP network to another private IP network over a public or untrusted IP network (for example, the Internet). In both cases, a complex security negotiation is Microsoft VPN Overview White Paper 3 performed between the two computers through the Internet Key Exchange (IKE), normally using PKI certificates for mutual authentication. The IETF RFC IPSec tunnel protocol specifications did not include mechanisms suitable for remote access VPN clients. Omitted features include user authentication options or client IP address configuration. To use IPSec tunnel mode for remote access, some vendors chose to extend the protocol in proprietary ways to solve these issues. While a few of these extensions are documented as Internet drafts, they lack standards status and are not generally interoperable. As a result, customers must seriously consider whether such implementations offer suitable multi-vendor interoperability. L2TP Design Goals and Overview L2TP is a mature IETF standards track protocol that has been widely implemented. L2TP encapsulates Point-to-Point Protocol (PPP) frames to be sent over IP, X.25, frame relay, or asynchronous transfer mode (ATM) networks. When configured to use IP as its transport, L2TP can be used as a VPN tunneling protocol over the Internet. L2TP over IP uses UDP port 1701 and includes a series of L2TP control messages for tunnel maintenance. L2TP also uses UDP to send L2TP-encapsulated PPP frames as the tunneled data. The encapsulated PPP frames can be encrypted or compressed. When L2TP tunnels appear as IP packets, they take advantage of standard IPSec security using IPSec transport mode for strong integrity, replay, authenticity, and privacy protection. L2TP was specifically designed for client connections to network access servers, as well as for gateway-togateway connections. Through its use of PPP, L2TP gains multiprotocol support for protocols such as IPX and Appletalk. PPP also provides a wide range of user authentication options, including CHAP, MS-CHAP, MS-CHAPv2 and Extensible Authentication Protocol (EAP) that supports token card and smart card authentication mechanisms. L2TP/IPSec therefore provides well-defined and interoperable tunneling, with the strong and interoperable security of IPSec. It is a good solution for secure remote access and secure gateway-to-gateway connections. PPTP Design Goals and Overview PPTP was designed to provide authenticated and encrypted communications between a client and a gateway or between two gateways—without requiring a public key infrastructure—by using a user ID and password. It was first delivered in 1996, two years Microsoft VPN Overview White Paper 4 before the availability of IPSec and L2TP. The design goal was simplicity, multiprotocol support, and ability to traverse a broad range of IP networks. The Point-to-Point Tunneling Protocol (PPTP) uses a TCP connection for tunnel maintenance and Generic Routing Encapsulation (GRE) encapsulated PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted and/or compressed. The use of PPP provides the ability to negotiate authentication, encryption, and IP address assignment services. Table 1 summarizes some of the key technical differences between these three security protocols. Microsoft VPN Overview White Paper 5 Table 1. Network Security Protocol Differences Feature Description PPTP / PPP User Authentication Can authenticate the user that Yes is initiating the communications. Machine Authentication Authenticates the machines involved in the communications. NAT Capable Can pass through Network Address Translators to hide one or both end-points of the communications. L2TP/ L2TP/ IPSec IPSe PPP IPSec Xport c Tunn el Yes Yes WIP1 WIP Yes2 Yes Yes Yes Yes Yes Yes No No No Multiprotocol Support Defines a standard method for Yes carrying IP and non-IP traffic. Yes Yes No WIP Dynamic Tunnel IP Address Assignment Defines a standard way to negotiate an IP address for the tunneled part of the communications. Important so that returned packets are routed back through the same session rather than through a non-tunneled and unsecured path and to eliminate static, manual end-system configuration. Yes Yes Yes N/A WIP Encryption Can encrypt traffic it carries. Yes Yes Yes Yes Yes Uses PKI Can use PKI to implement encryption and/or authentication. Yes Yes Yes Yes Yes Packet Authenticity Provides an authenticity method to ensure packet content is not changed in No No Yes Yes Yes 1 Support is not yet provided; however, there is work in progress (WIP) by the IETF IPSec working group. 2 When used as a client VPN connection, it authenticates the user, not the computer. When used as a gateway-to-gateway connection, the computer is assigned a user ID and is authenticated. Microsoft VPN Overview White Paper 6 Multicast support transit.MICROSOFT'S POSITIONS ON traffic IPSEC, Yes Can carry IP multicast L2TP/IPSEC, AND PPTP in addition to IP unicast traffic. Yes Yes No Yes IPSec By design, IPSec transport mode is ideal for delivering end-to-end authenticity and encryption within corporate networks. Microsoft is working closely within the IETF and with leading networking vendors to ensure interoperability within the specified IPSec standards that support this scenario. In most client-to-gateway VPN situations, user authentication and internal address configuration are critical aspects of security and management. Multicast support and defined methods for carrying multi-protocol traffic are also essential, particularly in gateway-togateway scenarios. To address this, many vendors have implemented proprietary and/or weakly adopted extensions to IPSec that inhibit multi-vendor interoperability. The IETF IPSec working group is currently exploring ways to address these issues, while minimizing packet overhead and leveraging the IETF IP framework. However, because IPSec tunnel mode does not have defined standard methods for extensible user-based authentication and address assignment for accomplishing these aspects yet, Microsoft has concluded that by itself, IPSec tunnel mode is unsuited to most client-to-gateway VPN situations. For gateway-to-gateway VPN scenarios, IPSec tunnel mode is fine— although interoperability problems for specific networking configurations may arise due to the varying number of IKE options supported, as well as the level of interoperability testing provided in products today. L2TP/IPSec L2TP is a well-defined, interoperable protocol that addresses the current shortcomings of IPSec-only client-to-gateway and gateway-to-gateway scenarios (user authentication, tunnel IP address assignment, and multiprotocol support). L2TP has broad vendor support, particularly among the largest network access equipment providers, and has verified interoperability. By placing L2TP as payload within an IPSec packet, communications benefit from the standards-based encryption and authenticity of IPSec, while also receiving a highly interoperable way to accomplish user authentication, tunnel address assignment, multiprotocol support, and multicast support using PPP. This combination is commonly referred to as L2TP/IPSec. Lacking a better pure IPSec standards Microsoft VPN Overview White Paper 7 solution, Microsoft believes that L2TP/IPSec provides the best standards based solution for multi-vendor, interoperable client-togateway VPN scenarios. Microsoft is working closely with key networking vendors including Cisco, 3Com, Lucent and IBM, to support this important combination. It should be noted that due to incompatibilities between the IKE protocol and Network Address Translation, it is not possible to use L2TP/IPsec or IPSec tunnel mode through a Network Address Translator while taking advantage of automated key exchange. Recently proposed work for L2TP specifies a header compression method for L2TP/IPSec. This work is important because it helps reduce protocol overhead dramatically while retaining the benefits of the rest of L2TP. Microsoft believes this header compression work represents an important direction for L2TP and supports the progression of this capability along the standards track. Microsoft also supports the continued development of standards-based, interoperable, and well-integrated solutions for IPSec tunnel mode in client-gateway applications. In particular, Microsoft believes that such solutions must not compromise the integrity of the IKE protocol by introducing excessive complexity. Additionally, IPSec Remote Access (IPSRA) solutions must be well integrated with existing network infrastructure, such as DHCP, and with existing IETF standards for extensible authentication, such as EAP and GSS_API. PPTP PPTP is broadly used today in both client-to-gateway and gateway-to-gateway scenarios. With mutual client/server authentication based on users' passwords and encryption keys seeded by the authentication process, PPTP is easy and inexpensive to set up and simple to administer. By virtue of its design, PPTP can also be passed through Network Address Translators (NAT). This NAT capability eliminates the requirement that each PPTP end-point have a registered IP address when used across the Internet. While L2TP/IPSec is an excellent solution for multi-vendor interoperability in both client-to-gateway and gateway-to-gateway scenarios, its usage of IPSec does require a PKI to be scalable. Also, because of incompatibilities between IKE And NAT, neither L2TP/IPSec, nor IPSec pure tunnel mode, nor IPSec transport can pass through typical NATs. Microsoft believes that PPTP will remain an important protocol choice for customers who do not require the sophistication of IPSec-based communications, who Microsoft VPN Overview White Paper 8 MICROSOFT SUPPORT FOR IPSEC, L2TP, AND PPTP do not want to deploy a PKI, or who require a NAT-capable VPN protocol. As such, Microsoft is committed to on-going support and advancement of PPTP. IPSec The Microsoft Windows 2000 operating system simplifies deployment and management of network security with Windows IP Security, a robust implementation of IPSec. IPSec protocol is an integral part of the TCP/IP protocol stack. Microsoft and Cisco Systems, Inc., have jointly developed IPSec and related services in Windows 2000. Interoperability is tested with Cisco and a number of other vendors for each of the examples below. Using IPSec, you can provide privacy, integrity and authenticity for network traffic in the following situations.  End-to-end security for IP unicast traffic, from client-to-server, server-to-server and client-to-client using IPSec transport mode  Remote access VPN client and gateway functions using L2TP secured by IPSec transport mode.  Site-to-Site VPN connections, across outsourced private WAN or Internet- based connections using L2TP/IPSec or IPSec tunnel mode. Windows IP Security builds upon the IETF IPSec architecture by integrating with Windows 2000 domains and the Active Directory service. Active Directory delivers policy-based, directory-enabled networking. IPSec policy is assigned and distributed to Windows 2000 domain members through Windows 2000 Group Policy. Local policy configuration is provided, so membership in a domain is not required. An automatic security negotiation and key management service is also provided using the IETF-defined Internet Key Exchange (IKE) protocol, RFC 2409. The implementation of IKE provides three authentication methods to establish trust between computers:  Kerberos v5.0 authentication is provided by the Windows 2000 domain that serves as a Kerberos version 5.0 Key Distribution Center (KDC). This provides easy deployment of secure communications between Windows 2000 computers that are members in a domain or across trusted domains. IKE only Microsoft VPN Overview White Paper 9 uses the authentication properties of Kerberos, as documented in draft-ietf-ipsec-isakmp-gss-auth-02.txt. Key generation for IPSec security associations is done using IKE RFC2409 methods.  Public/Private key signatures using certificates is compatible with several certificate systems, including Microsoft, Entrust, Verisign, and Netscape. This is part of RFC 2409.  Passwords, termed pre-shared authentication keys, are used strictly for establishing trust between computers. This is part of RFC 2409. Once configured with an IPSec policy, peer computers negotiate using IKE to establish a main security association for all traffic between the two computers. This involves authenticating using one of the methods above and generating a shared master key. The systems then use IKE to negotiate another security association for the application traffic they are trying to protect at the moment. This involves generating shared session keys. Only the two computers know both sets of keys. The data exchanged using the security association is very well-protected against modification or interpretation by attackers who may be in the network. The keys are automatically refreshed according to IPSec policy settings to provide constant protection according to the administrator defined policy. For customers familiar with technical details of IPSec, Windows 2000 supports DES (56-bit key strength) and 3DES (168-bit key strength) encryption algorithms, and SHA-1 and MD5 integrity algorithms. These algorithms are supported in all combinations in the ESP format. Because the AH format provides only integrity and authenticity, only MD5 and SHA-1 are used. L2TP Windows 2000 includes L2TP support when used with IPSec for client-to-gateway and gateway-to-gateway configurations. In these configurations, all traffic from the client to a gateway, and all traffic between two gateways is encrypted. This implementation has been tested with a variety of other vendor implementations of L2TP/IPSec. PPTP Windows 2000 includes PPTP support for client-to-gateway and gateway-to-gateway configurations. This implementation is consistent with the PPTP services available for the Microsoft Microsoft VPN Overview White Paper 10 Windows NT® Server, Windows NT Workstation, Windows 98, and Windows 95 operating systems. Customers can take advantage of their existing investment in Windows operating system–based platforms by using PPTP. Windows 2000-based systems can interoperate with Windows NT–based PPTP servers, and today's Windows–based systems interoperate with Windows 2000–based PPTP servers. In addition to password-based authentication, Windows 2000 PPTP can support public key authentication through the Extensible Authentication Protocol (EAP). Remote Access Policy Management Another dimension of security policy management that goes beyond encryption policy is access policy. In client-to-gateway and gateway-to-gateway situations, Windows 2000 provides a rich set of administrative policies that can be implemented to control user access through direct-dial, PPTP, and L2TP/IPSec connections. These access policies allow administrators to grant or deny access based upon a combination of user ID, time-of-day, protocol port, encryption level, and more. While available natively within a Windows 2000 Active Directory environment, these access policies can also be enforced on non-Windows 2000 environments through the use of RADIUS. For example, an existing Windows NT–based PPTP server can be configured to use a Windows 2000 Server to authenticate users through RADIUS. When used in this way, the Windows 2000 Server can be configured to enforce acce5ss policies and apply them to the Windows NT–based PPTP server. This is an example of how Windows 2000 can simplify and strengthen central administration during a transition to Windows 2000, and demonstrates one of the many benefits of using Windows 2000 for authentication in heterogeneous environments. Client Management As previously mentioned for IPSec, Active Directory is used to define and control IPSec policy. Installation of the PPTP, L2TP, and IPSec protocols is inherent in the installation of Windows 2000. Client configuration of these protocols for client-to-gateway scenarios can be accomplished in two ways:  On end systems, a New Connections wizard prompts the user through a simple set of screens to set configure the connection.  In larger scale installations, the Connection Manager Administration Kit and Connection Point Services can be used Microsoft VPN Overview White Paper 11 PLATFORM SUPPORT FOR SECURE NETWORK COMMUNICATIONS together to deliver a customized remote access direct-dial and VPN client to corporate systems. With these tools the administrator can provide the client with a specially configured profile that:  Brands the dialer consistent with corporate remote access programs.  Integrates customize help files and corporate remote access use licenses.  Integrates applications and other tools for automatic launch at various stages of the connection process.  Administers a central phonebook of remote access numbers.  Contracts with Internet Service Providers (ISPs) for management of point-of-presence (POP) phone numbers.  Configures clients to automatically update, and collates phonebooks from the ISP and the corporate phonebook servers. The resulting profile can be distributed centrally to clients through Microsoft System Management Services, Web downloads, file transfers, e-mail, floppy disks, or CDs. This lets administrators centrally manage clients while users get a single interface that:  Connects, regardless of type of protocol or connection (direct dial or VPN protocol).  Hides the complexity of the connection process (single click access).  Provides single sign-on using company user IDs (no separate ISP account required). Based on customer feedback, Microsoft considers this to be one of the most important components for deploying VPN services. Because IPSec and its related policy management, Kerberos authentication, PKI support, and hardware acceleration are integrated tightly into the Windows 2000 operating system and the Active Directory directory service, Windows-based desktop and server systems must be upgraded to Windows 2000 to take advantage of IPSec for end-to-end scenarios. Microsoft has no plans to deliver IPSec-only based services for the Windows NT, Microsoft VPN Overview White Paper 12 FOR MORE INFORMATION Windows 98, Windows 95, or Windows 3.x operating systems. Windows CE is under investigation at this time. L2TP/IPSec support is being delivered first in Windows 2000 Server and Windows 2000 Professional. Microsoft has no work planned for L2TP/IPSec on Windows NT or Windows 95 or Windows 3.x. Microsoft is working with customers to understand the specific requirements with regard to L2TP/IPSec and IPSec tunnel mode on Windows 98 and Windows CE. However, Microsoft has no work planned for L2TP/IPSec or IPSec tunnel mode on Windows 3.x. In addition to being an integral part of Windows 2000, PPTP continues to be supported on Windows NT, Windows 98, and Windows 95 operating systems. PPTP support for Windows CE is under investigation at this time. Microsoft intends to continue its leadership in the development of PPTP to address key customer scenarios that are unmet by IPSec and L2TP/IPSec standards. For the latest information on Windows 2000, visit our World Wide Web site at http://www.microsoft.com/windows/. For the latest information on Windows NT, visit our Web site at http://www.microsoft.com/ntserver and the Windows NT Server Forum on MSN™, and The Microsoft Network online service (GO WORD: MSNTS). Microsoft VPN Overview White Paper 13
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.