Security | Remote Access | VPN

There are two essential security issues with remote access: authentication of the user, and the user’s authorization to use particular services. One old and proven way of authorizing dial-in is call-back. In a call-back authorization, the caller dials into a remote access server and enters a log-in name and password. The remote access server then hangs up the modem connection and searches its database to authenticate the user. If the user is authenticated, the access server calls the user back at a predefined number. This method can work for a telecommuter who always works at home, but naturally fails if the worker travels.

Although call-back could be improved (for example, the access server could be reprogrammed to dial a specific hotel telephone based on a preapproved travel itinerary), the industry has agreed on a much more versatile security application: The Remote Authentication Dial-In User Service (RADIUS). RADIUS is an important application by itself; the following example describes how it works:

• 1. Using a modem, the user’s PC dials in to a modem that is connected to a remote access server.

• 2. Once this connection is completed, the user is prompted for the log-in name and password.

• 3. The access server encrypts log-in and password information and sends it to a centralized RADIUS server, which decrypts the data and passes it on to the appropriate security system module. (The encryption and decryption steps are omitted in some networks.)

• 4. The security system module authenticates (or rejects) the caller; if the caller is authenticated, the RADIUS server checks its database to find out which services the caller is authorized to use. [This includes specific protocols supported by the user’s PC, such as Point-to-Point Protocol (PPP) or Serial Line Internet Protocol (SLIP),  If the authentication process fails, the caller is denied access to the network. Otherwise, the authorization and specifics of the applicable services are sent to the access server. The RADIUS server may also send policing information (such as the data rate for carrying user data) to the access server, as well as filtering information, which limits the caller’s access to the enterprise network resources (for example, the caller may be allowed to access e-mail, but not to change or even copy the contents of files). To ensure that requests are not responded to by unauthorized sources, the RADIUS server sends an authentication key identifying itself to the RAS.

Some networks may require multiple levels of passwords for resource access, in which case RADIUS may be involved in authorizing relevant access.

In the preceding description, the seemingly unnecessary references to the security system module (why would RADIUS itself not do that?) are actually essential to understanding of the service: Support of any specific security mechanism is not a function of RADIUS per se; instead, RADIUS interworks with security mechanisms.

Remote Dial-in Access Applications and Virtual Private Networks

Remote dial-in access (or simply remote access) is the way many users access the Internet. It is also used in the telecommuting service whereby corporate road warriors and those who work at home access corporate IP networks. On the surface, both types of access look the same. In fact, the very procedure (dialing a number and entering a password) and the end-user equipment necessary (a telephone line and a modem) to accesses the network are identical. At least one important piece of the underlying technology pertinent—carrying IP packets over PSTN lines—is also present in both types of services. There are significant differences as well, with underlying issues, between accessing the Internet privately (through an ISP) and accessing corporate networks. We treat remote dial-in access simply as part of VPNs, discussed in a section that follows.

One problem inherent to data access from home via a telephone line is that the line will be busy for the duration of the data access session. The busy line has posed a number of problems for households with only one telephone line. One solution, perhaps most typical for many American households, is to have two lines. Another is to have ISDN installed (which is still rather expensive). Yet another solution is to use a special modem that splits the line into data and voice. Then, of course, there are service solutions (such as the Internet call-waiting service). As it becomes more available, the xDSL technology will eliminate the need to dial at all!

With remote access, in its oldest form (See Figure 1), a user simply established a point-to-point link between a terminal (connected to a modem) and a remote computer (also connected to a modem).

Figure 1: Terminal-to-host dial-in access.

As PCs became household appliances, the terminals virtually disappeared. PCs are presently used both as terminals (with so-called shell accounts, provided by both ISPs and corporations) and IP hosts. Even with the shell accounts, users get access to the Internet (including the Web) through a host. However, with shell accounts, the graphical interface that has made the World Wide Web so popular is not available.

To act as a host, a PC typically dials in the remote access server (RAS) of an IP network (as depicted in Figure 2, where the PSTN path happens to traverse three telephone switches). What actually distinguishes a host equipped with a set of modems from an access server? The answer is simple: A RAS is an IP router equipped with a set of modems or digital signal processors capable of terminating a call. Remote access servers are sometimes called remote access concentrators. Although both terms are used interchangeably, some people use the latter term only when referring to large multiservice modules, which have access to asynchronous transfer mode (ATM) networks, X.25-based public data networks (PDNs), and other non-IP networks (hence the term multiservice).

Figure 2: Host-to-host dial-in access.

Having just defined a RAS, we should note that the data network access may be not so remote. First of all, an enterprise or ISP can place several access servers (see Figure 3) so that users in different geographic areas can call local numbers. Second, remote access can also be outsourced. A remote access outsourcing application uses the existing network infrastructure of a larger service provider to offer remote access termination service to enterprise customers. Then, with the Internet offload application (also called Internet call diversion), the very edge (that is, the central office switch) of the PSTN can recognize the call (based on the dialed number, for example) as a data call, and terminate it at a colocated or even internal access server. From there the call is passed to the appropriate ISP (or enterprise) network (Figure 3).

Figure 3: Internet offload.

The Internet offloading application has been created out of urgency. The ever increasing use of Internet access has manifested a serious problem with the PSTN: The duration (or holding time, in telephony parlance) of such data calls far exceeds what telephone companies expected from voice calls (and consequently engineered their network for). As a result, more and more real (voice) calls became blocked throughout the PSTN, and the problem became so serious that specialized solutions to offload the data traffic from telephone switches to data networks, were urgently requested by telephone companies. The problem warrants special attention here if only because it was among the first instances where data-over-voice applications required significant restructuring of the PSTN. What is especially interesting is that even the old PSTN paradigm—the more calls and the longer they are, the better—has changed! The danger of these long data calls blocking voice traffic became so serious that the telephone companies decided they did not want data calls in the voice network. This conflict has created a classic example of PSTN-Internet integration by necessity.

Multihoming | Remote Access

One important detail affecting the design of access servers (which, for example, may contain the LAC function) is that their routers are typically located at the borders of enterprise or ISP networks. The servers then act as gateways to their respective networks. Three applications —remote dial-in, VPN, and IP telephony—deal with the IP packets that can traverse more than one network. For this reason, the remote access products that support the VPN service and IP telephony gateways benefit from the implementation of Border Gateway Protocol (BGP) version 4 (RFC 1771).

Although the subject of routing algorithms is outside of the scope, a short discussion of BGP is warranted. You may notice that some issues (such as policing) inherent in BGP are very similar to—and, in some cases, even the same as—those pertinent to the QoS standards addressed. BGP is the means of realizing multihoming (that is, maintenance of connections to multiple ISPs or enterprise networks). Thus, BGP is of considerable importance to dial-in access and VPN applications. The IETF has paid much attention to the BGP development, which dates back to ARPANET and then was pursued in the Inter-Domain Routing (idr) working group (www.ietf.org/html.charters/idr-charter.html ) over several years. Four versions of BGP have been released. In the latest series of RFCs, RFCs 1771 and 1772 have achieved the status of Draft Standards. Informational RFCs 1773 and 1774, respectively, document experiences with BGP-4 and provide an analysis.

RFC 1771 defines an autonomous system (AS) as “a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASs.” ISPs and enterprise networks are two typical examples of ASs.

Whereas interior nodes are concerned with making the best effort at delivering IP packets, exterior nodes have to deal with many other tasks. One task is to decide whether certain packets should be admitted to the AS; the other is to maintain the appearance of a coherent interior routing plan (which is not necessarily the case in practice). As RFC 1771 says: “The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of what destinations are reachable through it.”

There are two aspects to packet admission: Some packets may actually be destined to terminate in the AS, whereas others should be allowed to traverse it in order to get to other ASs.

In the world of the exterior nodes, which is significantly cozier than the world of all routers—if only because it is much smaller—the ASs are somewhat selfishly viewed as the means of connecting the exterior nodes. As far as transit through ASs is concerned, BGP provides the following taxonomy (illustrated in Figure 1):

§  Stub AS. An AS that has only a single connection to one other AS. Naturally, a stub AS only carries local traffic.

§  Multihomed AS. An AS that has connections to more than one other AS, but refuses to carry transit traffic.

§  Transit AS. An AS that has connections to more than one other AS and is designed (under certain policy restrictions) to carry both transit and local traffic.

Figure 1: The AS classification.

Stub and multihomed ASs do not need to employ BGP at their border nodes, but transit ASs do. The responsibilities of the border gateways involve, among other things, policing the incoming traffic.

This situation is strikingly similar to what used to happen at the borders of the Iron Curtain countries in Europe before the fall of the Curtain. In particular, the German Democratic Republic—the former East Germany—which had a piece of the free world (West Berlin) within its territory, was well equipped for dealing with transit traffic at its borders, where the cars queued up amid many uniformed men and women with automatic rifles and barking dogs. Unless all present in a car were citizens of East Germany or had prearranged visas for visiting specific places in the country, they were issued—for a fee—time-stamped transit visas that indicated a particular border point at which the car had to exit the country. The choice of destination border point belonged to the driver, but could not be changed once it was written in the visa. Furthermore, the car was supposed to reach its destination border point by (1) always staying on the East German highway network, (2) following the shortest path through this network, and (3) obeying all the laws of the country, which in this case were of course effectively reduced to the traffic laws. With that, the car was virtually tunneled through the country, its passengers seeing not much more than other cars and trucks—including many police cars—and vast fields on both sides of the highway. At the destination border checkpoint, more armed men and women with dogs were waiting. One of the many checks they performed was that of the initial time stamp. If the elapsed time indicated that the car had clearly spent more time in the country than it would have had it taken the shortest path, some specific policies applied, with the actual consequences (fines? imprisonment?) fortunately unknown to these authors. Another—and, alas, often unexpected—effect of time-stamping was discovered by those drivers whose traveling time was too short for the distance, which was a clear proof of speeding. The offense was punished by a large on-the-spot fine to be paid in cash and in hard currency. The latter policy example, however, is more illustrative of QoS rather than border gateway policies.

Policy-based routing is an essential job of the routers that serve as border gateways. Policy specification is a job of network administrators rather than of the protocol itself, but BGP routers do make routing decisions based on these policies.

In a deviation from other Internet routing protocols, BGP uses TCP (instead of a link layer protocol) as a reliable data transport for routing messages. The actual routing algorithm belongs to the so-called distance vector routing family, which operates by maintaining within each router a table of distances (costs) to all reachable routers and exchanging this information with other routers. The most lamented deficiency of the distance vector routing is that the “bad news,” (that is, loss of a link between two routers or router flop) propagates through the network extremely slowly. BGP differs from other distance vector routing protocols in that the routers maintain—and share with one another—full paths to the nodes reachable from them. That fixes the problem of spreading the bad news, because the routers notice all the nodes disappearing from neighbors’ paths as soon as they get the change information. Note that being reachable is not simply a matter of connectivity but also of active policies.

In an example of RFC 1772, a multihomed AS may actually act as a transit AS for some ASs by advertising to them paths to foreign gateways; on the other hand, a transit AS may restrict access to some ASs by never advertising paths to them (that is, declaring them unreachable). In the example of Figure 2, AS D is reachable to AS A through AS C, but AS B is not.

Figure 2: Access restriction.

Initially, a BGP router sends its whole routing table to its neighbors, which are supposed to keep it until the connection is closed because from now on they will receive only incremental updates. Even though TCP is used for transport, BGP still uses its own KeepAlive messages to ensure that the connection is open. The connection is closed whenever an error condition (such as nonreception of KeepAlive messages) is encountered. In addition to incremental updates, BGP-4 has added the concept of route aggregation so that information about groups of networks may be represented as a single entity.

BGP-4 has also addressed the problems of (1) the exhaustion of class B address space and (2) threatening growth of the routing tables. In listing the differences between BGP-4 and previous versions of BGP, RFC 1771 notes: “BGP-4 is capable of operating in an environment where a set of reachable destinations may be expressed via a single IP prefix. The concept of network classes, or subnetting, is foreign to BGP-4. . . . New text has been added to define semantics associated with IP prefixes.”