Remote Access
| This section defines remote access as access from a workstation that is not directly connected to a LAN served by the provider VPN. This can be dialup users, digital subscriber line (DSL), cable, or, increasingly, mobile wireless users. This chapter's intent is not to give a full treatment to these access methods, as would be needed by a provider planning to deploy DSL, cable, or wireless services. Rather, the intent is to provide enough information for the enterprise network manager to understand the issues as they relate to incorporating these services in an overall network architecture and to make the choices that best suit the requirements at hand. The choices are as follows:
These two questions have a total of four options: remote access via a provider's network, with or without encryption (implying that you place dialup users in your virtual routing/forwarding instance [VRF] within the provider network), and remote access via separate connections to your network, with or without encryption. The choice of which option to select is based on the level of trust and the sensitivity of the data being transported. Additionally, the cost of support must not be ignored in this selection. The cost of support needs to include consideration for a separate connection to the corporate network if that option is selected, support of separate remote-access equipment, maintenance of IPsec encryption keys, and phone support for remote-access users whose connection difficulties take more time to troubleshoot. As the use of remote-access technology has grown, the access methods preferred by network managers have changed. Initially, dialup access to a central number with Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) authentication was deployed. As the need for greater footprint at a lower cost came along, Layer 2 Tunneling Protocol (L2TP) solutions started to appear from providers. Now, IPsec over many different access methodologies is prevalent. Each of the following subsections details a different access technology from the perspective of access via enterprise-owned equipment as well as provider-owned equipment. Provider-owned equipment typically adds to the complexity of mapping users to VRFs for the provider but simplifies the enterprise network management requirements. Dial Access via RASRemote-access server (RAS) was the first method used for remote access in enterprises. The concept is simple. You place a remote-access server that can receive incoming dialup calls on the corporate LAN. Then anyone with dialup access can call over a plain old telephone service (POTS) line. The setup for these devices is fairly straightforward. It is reviewed here to set the scene for the solutions that are more commonplace today, because the more recent solutions build from this foundation. Dialup access started off using Serial Line Internet Protocol (SLIP) but rapidly got replaced because of shortcomings, such as lack of support for address negotiation by PPP. A complete description of this protocol may be obtained from the link given in the "References" section at the end of this chapter, titled General PPP Information. You can find RFCs for PPP by searching for PPP at http://www.ietf.org/iesg/1rfc_index.txt. As its name suggests, PPP handles the data link communication between two adjacent nodes. L2TP was created to extend PPP-based negotiation and data transport over packet-based networks. It is discussed in the next section as it pertains to enterprise networks. Briefly, PPP supports asynchronous as well as synchronous communications, supports the running of multiple Layer 3 protocols over one link, allows dynamic address assignment, and handles authentication. In a RAS environment where users are dialing in via POTS (or, equally possible, via ISDN), the process is for a workstation with dialer software to dial the RAS's number. PPP authenticates the user and gives her an IP address, and then she gains access to the network. The next section provides an overview of this process. In PPP communications, the primary communication between the two ends consists of two parts: Link Control Protocol (LCP) and Network Control Packets (NCPs). LCP establishes and maintains the Layer 2 connection, whereas the NCPs are specific to each Layer 3 protocol. The first phase of PPP negotiation is the exchange of LCP packets, which is the basic introduction of the two nodes that need to communicate. Here, each node agrees on general communications parameters, such as the maximum frame size and the use of compression. An optional phase checks line quality to see if the NCPs can be brought up. When the link negotiation is complete, an optional authentication process takes place via PAP or CHAP, which are defined in RFC 1334. This authentication needs to be configured into each node along with the username and password (or the location of the username and password). PAP is simple to break into by using modem playback. The authentication performed by PAP sends a username and password from the dialer to the dialed node in clear text. This process continues until a connection is either granted or terminated. By capturing the tones sent by the modem down the phone line, an intruder without the username and password can play back those tones down the phone line and gain access. However, PAP is not used much any more, which makes this nearly a nonissue. CHAP is a stronger authentication process. The LCP negotiates the link, and then the dialer receives a "challenge" from the dialed node. The peer responds with a value calculated by using a "one-way hash" function. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise, the connection should be terminated. CHAP provides protection against playback attack through the use of an incrementally changing identifier and a variable challenge value. The use of repeated challenges is intended to limit the time of exposure to any single attack. The authenticator is in control of the frequency and timing of the challenges. This authentication method depends on a "secret" known only to the authenticator and that peer. The secret is not sent over the link. This method clearly defeats the modem playback security issue. Several different encryption methods may be employed to encrypt the username and password pair using the challenge key. Message Digest 5 (MD5) is the most common. With authentication complete, the NCP negotiation can continue. Typical NCPs implemented are IP Control Protocol (IPCP) for IP and IPX Control Protocol (IPXCP) for Internetwork Packet Exchange (IPX). After the NCP negotiates the Layer 3 information, traffic can flow. RAS ConfigurationA basic configuration for a RAS port that is suitable for a dialer node connecting by either POTS or ISDN is as follows. (This is by no means the only way to do things, but it is a simple and proven method.) Typically, small RAS installations are supported by multiple POTS lines configured in a hunt group by the phone company so that dialer nodes can all be configured with the same access number. As this type of access grows within an enterprise, it is typically replaced with one or more PRI connections serviced by an 800 number to reduce costs. Example 9-1 shows one way to configure each of the ports on the RAS. Example 9-1. RAS Port Configuration
There are three sections to the relevant configuration commands for each async port: the asynchronous port configuration, the authentication username and password, and the line speed communication. Clearly, the first line specifies PPP encapsulation. The second line places the port in dedicated mode (it can also be placed in interactive mode). Placing the port in interactive mode can be perceived as a security risk, because it presents the user with a prompt, which lets the user input a username and password. The third line specifies the use of Van Jacobsen header compression. This is on by default, but it is good practice to ensure that it is enabled in the configuration in case it has been inadvertently turned off. The async default ip address command defines the IP address that will be given to nodes dialing in and connecting to this port. The next line refers to the Asynchronous Control Character map. This is a configuration that tells the port to ignore certain control characters within the data stream. This is useful if you want to tell the port not to react to X/ON and X/OFF signals within the data stream. The map given here defines the setting to ignore these well-known flow control signals. CHAP is specified as the authentication method, and the interface is configured to do a lookup for each packet being sent so as not to have traffic coming from a high-speed LAN overrun the slow-speed async line with the no ip route-cache command. The next section identifies the username and password, with the line section specifying the line transmission features. The speed specified is the asynchronous data rate between the modem and the router port. It does not relate to the model train speed over the dialup link. The train speed is normally less than 56 kbps, depending on link quality. V.42b is used to detect common sequences of bits and create a dictionary of codes that represent larger sequences of these commonly transferred bits. By this means of using a short code to represent a longer string of data, V.42b modems can sustain transfer rates above 56 kbps, but it depends on the data constructs being transferred. Finally, the Domain Name System (DNS) server for async clients is identified in the configuration. As shown, there are many ways to configure this operation. The "References" section at the end of this chapter provides a link to a more scalable option that uses the interface group-async feature that simplifies configuration. It clones configurations between async ports and local pools of addresses to assign to incoming dialer nodes. As you examine ways a service provider can take some of the burden off the enterprise network through VPN services, ensure that the components are supported. Dial Access via L2TPThis section covers the operation of L2TP-based services offered to enterprises. Enterprises should not have to maintain RASs, dial-in lines, and banks of modems themselves, especially when service providers already have existing equipment deployed and support staff that can take the burden of maintaining, upgrading, and supporting that environment. Before L2TP-based dial solutions, enterprises had to provide a central RAS with a toll or 800 number or distribute RAS geographically throughout their network and face the burden of remote support for those devices. Now with L2TP, client software can be provided to enterprise users that gives them a local access number to call within most locations in the U.S. or international access points of presence (PoPs). So the users actually dial in to a service provider-maintained bank of modems. The dialed connection is then transported over the service provider infrastructure to the enterprise. This is a straightforward concept, but some consideration needs to be given to authentication, adding new users, and so on. Additionally, if the enterprise is taking a Multiprotocol Label Switching (MPLS) VPN service from the provider, you have to decide whether the provider delivers these dial-in user connections via a separate link to the enterprise or uses intelligence within the network to place the user in the enterprise VRF and therefore does not require a separate connection to the enterprise network for remote-access users. L2TP ComponentsThere are several enabling component terms to define when a service provider delivers local dialup access numbers to an enterprise user base and then transports those dial-in user connections to the enterprise head office. The L2TP terms L2TP Access Concentrator (LAC) and L2TP Network Server (LNS) are shown in Figure 9-1. Figure 9-1. L2TP Components The LAC is the device that remote users dial in to. The LAC's role is to accept the incoming call and tunnel it over the packet network to the LNS at the enterprise where the determination of call completion or termination is made. LNS is the server side of the L2TP process. It resides on the enterprise LAN and terminates both the L2TP tunnel from the LAC and the PPP sessions from the PCs dialing the LAC. L2TP functionality is associated with Virtual Private Dialup Network (VPDN). Almost all of the operation should be transparent to the enterprise. However, it is valuable for the enterprise network manager to understand the service being purchased and the issues to consider when interfacing with the service provider. L2TP Call ProcedureUnderstanding the call procedure is important when troubleshooting dialup issues, so you must know what the responsibility of the enterprise-provided equipment is, as well as what the responsibility of the provider equipment is. This is also useful when deciding whether you want the direct kind of VPDN deployment that terminates into an LNS on the enterprise premises or a service that terminates the remote users into your VRF in the provider network. The call procedure starts with a PC using PPP to dial the LAC. Throughout the process, the PC is completely unaware that it is communicating with a VPDN system (other than the fact that it will use a domain name in the user ID). As soon as the call is placed, the first step the LAC takes is to challenge the PC, which responds with an e-mail address, such as lewis@enterprise.com. This e-mail address identifies the user and the domain name the user belongs to. At this stage, the LAC sees the domain name, which indicates to the LAC that this is a VPDN user. It then searches for an existing L2TP tunnel to enterprise.com. If none exists, one is created. The primary concern from the enterprise perspective is that of username administration. It is clearly undesirable from both the enterprise and provider viewpoints to have the username list administered by the provider. Fortunately, this is not necessary. The service provider equipment can be configured to authenticate usernames against a RADIUS server administered by the enterprise. Configurations for this are given in the RADIUS reference at the end of this chapter. In this setup, the provider equipment is responsible for only identifying the domain name and then forwarding the authorization request to the appropriate RADIUS server for the domain name. The only additional concerns from the enterprise perspective are that the RADIUS server authenticating these user names must be both accessible from the provider network and secure from unauthorized users. The issue of securing an enterprise network from an attached provider network is addressed in Chapter 7. L2TP is suitable not only for extending enterprise remote-access connectivity over a provider infrastructure. It also lets providers extend the reach of their networks over the infrastructure of other providers in the same manner. In fact, it is normal to see the same set of dialup numbers for a given location appear in the dial options from many different providers, because many have agreements to offer their dial services through other providers. Connecting L2TP Solutions to VRFsSo far, the L2TP solutions presented require a separate connection (either logical or physical) between the provider and the enterprise to support remote users. The enterprise infrastructure can be further simplified by reducing this to a single connection if the provider takes on the burden of placing these remote-access users in the enterprise VRF within its network. However, this introduces an additional level of complexity to the provider network operation. The complexity comes in terms of how a remote-access user is identified and placed within the VRF assigned to the enterprise by the provider. From the perspective of the provider network, a remote user can connect anywhere in the network. The user needs to be authenticated and assigned an IP address for access to the enterprise network and to be transported from wherever he or she connects to the provider network to the enterprise. Cisco has designed, tested, and deployed solutions that support this type of functionality for dialup, DSL, and cable users. The dialup and DSL solutions are quite similar. The cable solution leverages the Data over Cable Service Interface Specification (DOCSIS) standard to simplify VPN association. Figure 9-2 shows the general architecture of service deployment for remote access to the MPLS VPN. Figure 9-2. MPLS VPN Remote-Access Architecture To better understand this architecture, you must first understand its components. The terms and definitions are as follows:
The VHG-PE is where the mapping and intelligence to take a remote-access user to the correct enterprise reside. With this architecture, the provider may elect to configure a number of different options, all of which should be transparent to the enterprise user:
Take a closer look at this dial case by examining the setup shown in Figure 9-3. Figure 9-3. End-to-End Architecture for Remote Access over an MPLS Service The following lists one possible sequence of events that must occur for a remote-access dial user to become part of its corporation's VPN:
The remote user is now part of the customer VPN. Packets can flow to and from the remote user. The key issue for the enterprise to consider with this type of solution is maintaining the list of usernames requiring authentication and address pool management for the remote users to gain access to enterprise network resources. A PE assigns addresses to remote users using local address pools, the service provider's RADIUS server, or the SP's DHCP server:
DSL ConsiderationsFigure 9-4 shows the specifics of a DSL architecture using L2TP with DSL access. Figure 9-4. Architecture Incorporating PPPoE and PPPoA Incoming PPP over X (PPPoX) sessions, arriving at the LAC, are L2TP-tunneled to the VHG-PE that maps them to the corresponding VRF. The advantage of this solution for the provider is the ability to provide enhanced aggregation and route summarization at the edge of the MPLS VPN core. This solution is very similar to the dial RA in L2TP to MPLS VPN solution shown in Figure 9-3. The following events occur when the remote user creates a PPPoX session over DSL in an attempt to access its corporate network or ISP (the customer network, as shown in Figure 9-4):
Cable ConsiderationsFigure 9-5 shows the components of a system to map cable users to specific VPNs. Figure 9-5. Architecture for Cable Remote Access In DOCSIS 1.0, all traffic from a given cable router (or cable modem) carries the same SID. On the cable modem termination system (CMTS) VHG-PE, all traffic with the same SID value terminates on the same subinterface. At the CMTS VHG-PE, the subinterface is statically configured to map all traffic to a specific VRF. As a result, traffic from all customer premises equipment (CPE) behind a given cable router is mapped to the same VPN. This solution has no domain name-based remote user authorization or authentication. Address assignment is DHCP-based. Accounting is based on NetFlow. The initial focus of cable solutions was to offer open access to ISPs, but using cable solutions to offer enterprise VPNs is entirely possible. A remote user can access a special web page and request to change his or her ISP/VPN. For such a change to take effect, both the cable router/modem and the PCs behind it must be reset, and SID-to-VRF mapping on the CMTS VHG-PE must be changed. |
EAN: 2147483647
Pages: 136