Remote Access Services (RAS)

Home - Network - Lec1 and 2 - Lec3 - Lec3b - Lec4 - Lec5 and 6 - Lec7 - Lec8 - Lec9 - Lec10 - Lec11


Time was that the only users you needed to worry about were those physically connected to your network. Then came portable/laptop/notebook/hand-held computers, and the age of mobile computing packed with road warriors and telecommuters was born. This was followed by the success of the World Wide Web on the Internet, which created the need for an internal Web-like presence, called an intranet. What's more, clients, customers, suppliers, and vendors needed access to your files and documents. Adding them created what's now called an extranet. We're going to lump all these topics together as Remote Access Services, because most of this access-whether by employees, vendors, or clients-is remote from your location.

Users today expect to be able to use the same applications and services no matter where they're located at any given time. Business partners also want access to your data because they need it to supply your company, buy from it, or cooperate on projects. Anyone not directly connected to your corporate network is using RAS in one form or another, whether that's a dial-up connection via modem or a secured Internet connection, also called an extranet or a virtual private network (VPN). This demand for connectivity has placed a tremendous burden on Information Technology (IT) departments. In order to understand why there's such a need for reliable RAS service, this chapter begins by examining the chain of events leading up to modem RAS. It then goes on to examine intranets, extranets, and VPNs, with specific emphasis placed on their functional distinctions, their operational implications and uses, as well as some of their key component technologies.

History of Remote Access Networking
In the late 1950s, computer data centers were mystical places filled with people in white lab coats. These data centers made computer services accessible for the masses, but users of these early data centers were forced to deal with the many rules and requirements put forth by the data center personnel. Many times, these rules would place serious constraints on the users. Inconvenient hours, formatting requirements, and any of a myriad of requirements made all users feel subservient to the data center. Consequently, managers began looking for ways to gain access to the mainframe systems without having to go through the actual data center.

In larger corporations where mainframes were responsible for tracking budgets and inventories, management began to realize the importance of decentralizing this information.

If the executives and middle managers were forced to access this data with large, cumbersome weekly printouts, the data they were using was only as good as the last printout. In many cases, a seven-day lag in information was unacceptable. This led to more printouts, and many managers felt that using these reports on a daily or weekly basis was a waste of time. Something had to happen. Access to the data in these mainframes needed to reach the user level, and it had to reach it fast.

Something monumental did happen: Line drivers and line conditioners became available. These devices allowed the data center to remotely connect terminals to the mainframe computer. The first candidates for these terminals were the managers of the data center themselves. Following that, terminals began to appear all over the workplace. Soon, the information that had been available in only one location within the organization was being put into the hands of the people needing the information. Imagine that!

The 1970s
In the early days of "number crunching," it was very rare to find an organization dispersed over a geographical area. For that reason, there was little interest in networking large mainframes together. Corporations, universities, and government agencies were the only major users of mainframe systems, and of the three, the government was the only entity interested in connecting computers that were separated geographically. However, as the U.S. Defense Advanced Research Projects Agency (DARPA) began to perfect the idea of computers communicating with other nonsimilar computers, the private sector began to take notice.

The modem became an extremely important device at this time, and the first modems were really nothing more than acoustic coupling devices that enabled a telephone to interface with a port on a computer system. A user connected to one data center could now gain access to information in other data centers via the network connections that existed between the centers. The modem data network was born

Computer professionals then began to connect smarter terminal equipment to their mainframe systems. At the same time, terminals started to have built-in memory capabilities. This enabled them to store setup information. That way, when a terminal was used to establish a connection or session with a computer, the common setup commands could be automatically sent between the computer system and the terminal.

This convenience served only to whet the appetite of many mainframe users. The small computer system had arrived on the scene.
Users of data services began to experiment with connecting small computers via modems to their larger cousin-the mainframe. Although the original users of remote access connections were computer scientists and technicians, the concept was proven sound. Now it was possible to pass data back and forth between small computers and large mainframe systems.

The 1980s
The IBM personal computer (PC) was introduced in 1981. Soon, several local area network (LAN) operating systems became available. As small computer LANs became a standard in the workplace, the desire to remotely access these LANs from anywhere via a dial-up connection grew. Modems became cheap and available, and users began to demand quality dial-up connections for their PCs.

Novell, IBM, and Microsoft began to introduce various software packages embedded in their operating systems. These packages were designed to accommodate dial-up service. With emulation programs such as ProComm, PC users could dial in to large computer systems or networks configured with standalone modems or modem pools.

The Advanced Research Projects Agency Network (ARPANET) became the Internet in 1969. Universities and private corporations were soon exploiting it, and in 1984 there were 1,000 mainframe computers connected to each other via the Internet. Between 1987 and 1994, the Internet grew from 10,000 connected hosts to two million connected hosts. Users began to demand Internet access from their homes, and Novell and Microsoft were happy to accommodate them. Remote access in the 1990s has been able to closely duplicate and emulate the LAN services that users have come to depend upon.

The Craze of the 90s
Today, it's not uncommon to see the acronym RAS used as frequently as the acronym PC. Users are demanding that RAS networking be able to provide the same power of a LAN connection when dialing into servers and network systems. Microsoft has built RAS into its 32-bit operating systems (Windows 95/Windows 98 and Windows NT/Windows 2000), and many third-party software packages now exist. RAS has become one of the most important technologies in the world of computing.

For these reasons, any potentially successful IT professional needs a full understanding of RAS. Many corporations are geographically dispersed, and RAS is the best way employees can maintain constant ties to corporate computing resources. Email, work sharing, and many other applications are RAS-capable these days. RAS has earned its rightful place in the IT community. The next sections discuss what RAS does and the features it provides.

Remote Connection Setup
In order to accommodate a dial-up connection, protocols must be used to standardize the way each end of the connection negotiates the data flowing between the host and the user.

Note: For the purposes of this chapter, the term host refers to the server, computer system, or network that the RAS user connects to. The term user refers to the computer that the RAS user connects from.

In the early days of dial-up connections, the PCs doing the dialing were meant to emulate directly connected terminal equipment. These dial-up connections were used to enable the PC to took and act the same as a terminal directly connected to the host. As a result, the only software needed in the user's PC was dialing software and a program that simulated the same character signals (that is, ASCII or EBCDIC codes) that a terminal produced.

Note: ASCII refers to the American Standard Code for Information Interchange; it's a seven-bit character code. EBCDIC refers to Extended Binary Coded Decimal Interchange Code, an 8-bit character code invented by IBM.

These first dial-up systems were effective, but they were also slow. Modem connect speeds were generally less than 1,200bps (bits per second). Some of the earlier connections were acoustic coupling devices in which the telephone receiver was connected to an acoustic coupler resembling two Mickey Mouse ears.

Early Protocol Standards
The only protocols that came into play during these early, point-to-point, user-to-host remote connections were the protocols defining the electromechanical standards between the modems and the telephone lines themselves. In the United States, the Bell Telephone Company established standards defining modem-to-modem connections. Early standards were the Bell 103 and Bell 212A. Later, these were adopted internationally, and the CCITT developed standards V.21 and V.22. These standards define the transmission between two connected modems.

Note: CCITT is an acronym for the French title of the International Telecommunications Consultative Committee. The "V" and "X" standards apply to data communications connections. Typically, the V standards are for data connections and modem use over voice and dial-up circuits. The X standards refer to digital/data standards. These standards are occasionally updated or deleted. The CCITT defines standards recommended for use by the entire world. Recently reorganized, the CCITT is now called the International Telecommunications Union (ITU).

The AT Command Set
Hayes, Inc. came out with the Hayes Smartmodern and standardized the AT (attention) command set for use with PCs and dial-up modems. This AT command set is still used. Today, the AT command set is incorporated into most terminal-emulation software for the PC. It's this command set that enables a PC to force a modem off hook, to dial, and so on. Remember, though, in the early days users had to manually enter AT commands to force the modem to do something.

This connection limited users to performing only those functions the host system could perform. If the direct-connection terminals in the data centers did not have access to network resources, then typically the dial-up users didn't have access either.

Perhaps the best example of terminal remote access service is the type of networking that was used on computer systems for banks during this period. Banks would network smaller host systems in branch offices with larger mainframe hosts in the parent office. The smaller branch systems were set up to update the larger, central hosts.

Many times, these banks would set up the branch systems to perform an "upward" passage of data to the central host on a real-time basis. This was done on dedicated telephone lines and modems. However, the "downward" flow of data from the central host to the branch systems was done only once a day. Figure below shows an example. Branches A and B are indeed connected to the central system. However, they're not connected to each other. Data flowing from the branch systems to the central system is constant, but data flowing from the central system to the branches is on a once-a-day basis. Therefore, the data in the branch systems is always from the previous business day.


Basically, all dial-up access came through a branch office. Dial-up access in those days tried to mimic what the terminals connected to the mainframe by direct wiring were capable of doing. The next section examines the upper-level processes that take place when users initiate remote access sessions with host systems.

RAS Connection Protocols
To examine the upper-level processes of remote connections, you need to explore the two most prevalent connection protocols in use today on remote access connections. As an introduction to the discussion of these protocols, a quick summary of the process that occurs when a user-to-host remote access session is established is in order.

Establishing a Session
To initiate a remote connection, one end (usually the user) dials out to the other end (usually the host). Today, the user's PC running some sort of dialing program accomplishes this. Windows 95/98 and NT/2000 have a built-in dial-up networking function. After the modems have negotiated a connection with each other via the telephone line and the carrier is stable between them, digital signals on the output port of the modem pass this information back to the user's PC.

Note: Carrier refers to the pilot (or main analog signal) that a modem transmits to another modem over a communications link when a data communications connection is established between the two devices.

Second, the user invokes the software program he is using to communicate with the host system. This may be some terminal emulation package such as ProComm, or it may be a built-in dialing program. Again, Win32 has built-in negotiation software in its dial-up networking function. Whatever the user needs to do in order to negotiate upper-level processes in the host is done at this time. For example, perhaps the user invokes some unique program written exclusively for a particular corporation.

TCP/IP Access Protocols
Most people who are involved with remote access connections are connecting to the Internet or a company intranet. For this reason, Transport Control Protocol/Internet Protocol (TCP/IP) is the protocol suite used to pass data back and forth over the connection. Today, when TCP/IP is being used as the main transport protocol suite, either SLIP or PPP (see the next two sections) will be used as the main access protocol for dial-up sessions between a PC and a RAS server.

SLIP
The main carrying mechanism that moves data in the TCP/IP world is the IP packet. Without going into a lengthy discussion of IP and IP addressing, you should note that IP is the connectionless Internet protocol that moves TCP and User Datagrarn Protocol (UDP) packets from one place to another. TCP and UDP packets carry the data the user has sent. In other words, consider IP as the carrier and the TCP or UDP packet as the item being carried.

Any dial-up connection that could carry IP packets needed to be configured to transmit all the characters in the IP packet. Therefore, 3COM developed a new protocol called the Serial Line Internet Protocol (SLIP). SLIP has never become a standard Internet protocol. All SLIP does is "frame" an IP packet and send it through from one end to the other. This protocol provides no addressing, packet type identification, error control, or compression. However, this lack of capabilities also means SLIP is very easy to implement.

Rick Adams implemented SLIP for Berkeley UNIX in 1984, and released it into the public domain. Remote access for Internet services became commonplace.

To this day, many PC connection programs designed for Internet connectivity have a SLIP option. The fact that there's no standard SLIP specification means there's no maximum defined packet size. Many forms of SLIP came into being in the late 1980s, but SLIP provides only a frame for carrying IP packets over serial lines. Remember, the user's PC still has to communicate with its modem using AT commands. The modem still has to dial out and establish a connection with the host computer's modem. Today, ITU standards are responsible for maintaining modem-to-modem connectivity.

SLIP comes into play only after a stable connection has been made between the modems, and the user and host system have established connectivity. After this occurs, the SLIP protocol enables the passage of IP packets over this serial user-to-host connection. Remember this: SLIP passes no address information. This means that each computer (host and user) must know the other's address in order for packets to pass back and forth effectively. This is always a function of whatever type of SLIP software/dialer you're using in the user PC and the SLIP software in the host system.

SLIP has many limitations, and users demand error-free connections when dialing into host systems. The fact that SLIP could not perform any compression, addressing, or error checking made users demand a better connection protocol. This gave way to the birth of PPP

PPP
The Point-to-Point Protocol (PPP) is another design that grew out of user demand. This protocol is designed primarily to provide a link between two peers on serial ports. Typically, the use of PPP is limited to dial-up user-to-host connections. However, some people use PPP in host-to-host or host-to-router connections. This chapter examines PPP as it's used in remote access, dial-up connections.

PPP has been standardized as a true Internet protocol. SLIP never earned that distinction. Many users still swear by SLIP, but the error rate can be astronomical at times. If you

want a remote access connection that operates properly when passing IP packets, PPP is the protocol of choice.

Like SLIP, PPP also packages the IP packets within its frame, but other actions are occurring in addition to framing the data. PPP also sets up a session of link control between the user and host, and this session is controlled by the Link Control Protocol (LCP). LCP then sets up the link between the user and the host on a PPP session.

This is actually the first thing that happens when a PPP session begins. LCP packets are transmitted between the user and the host. These packets actually configure and test the link that's established. Issues such as link quality and link echo are tested to ensure the link is stable. Here are the three classes of LCP packets:

LCP ensures that the link is running and stable and then passes this information to the main PPP protocol to declare the link up. After this has happened, PPP sends out what is called a Network Control Protocol packet (or NCP packet). The NCP packet is specific to the type of data to be passed over the PPP link.

An NCP packet is sent by the originator of the PPP connection (in most cases, the user who dialed the host). This NCP packet tells the host what type of traffic is to be passed over the PPP link. The name of the PPP Network Control Protocol (NCP) for IP datagrams is called IP Control Protocol (IPCP) and is responsible for configuring, enabling, and disabling IP functionality at both ends of the link. IPCP packets may not be sent until LCP has finished the configuration negotiation phase. After that phase is complete, the IPCP protocol will signal that it's ready to begin forwarding IP packets and datagrams.

After this happens, the user and the host are capable of transmitting and receiving IP datagrams and packets. As discussed previously, IP is the mainstay of the Internet today in terms of the carrying mechanism. For that reason, it makes no sense to discuss other NCPs that PPP may use to transfer data. However, many other NCP protocols are incorporated into some versions of PPP

Current Trends
SLIP and PPP are definitely the workhorses of remote access sessions these days. It's rare to see users of remote access services using anything other than these two protocols when passing data between themselves and a host system. For setting up RAS servers in Windows NT, the PPP protocol is used in 99 percent of the implementations today. However, you also need to understand the services RAS servers are required to provide after a PPP connection has been established.

Remote Access Transport Services
In the world of RAS, users are interested in being able to connect to a host system, using that host system for whatever purpose they need, and then disconnecting the RAS connection. It would be impossible in a chapter this size to go into all the different services a user may use on a remote connection. Instead, this chapter reviews today's most-used services.

How RAS Users Are Currently Connecting
Most large organizations, many mid-sized ones, and quite a few small businesses have established corporate intranets. Users of a corporate intranet are generally using PCs located in their work areas. However, if they're active telecommuters, on-the-road workers, or work-at-home types, they may take a laptop PC from place to place.

In order for these people to be productive when using remote access connections, these connections must provide identical services to the users' PCs in all locations. Whether he's sitting at the desk in his corporate office using a direct LAN connection or dialing in from a hotel, what a user sees on the PC screen must be the same at all times. After allowing for exceptions, this should be the goal of any RAS arrangements being implemented on a corporate intranet.

Some users may be used to dialing into a computer at their central headquarters on a regular basis. If so, dialing in from home or a place of employment should be the same. Many corporations have one central dial-up host that serves the entire corporation. Other users are many times dialing into an Internet Service Provider (ISP) and simply using the ISP's email capabilities to pass mail to people in other organizations.

Given any situation, you can make several assumptions about most RAS connections:

Most RAS connections are established for users to gain access to a LAN, a corporate intranet, or the Internet. Every rule has exceptions, and these statements can be challenged. However, in most cases, these statements hold true. The next section discusses what TCP/IP can do for its remote users.

TCP/IP: The RAS Workhorse
No discussion of RAS would be complete without a discussion of TCP/IR TCP/IP is one of the most misused terms in the world of computing and telecommunications. TCP/IP is actually two things. First, it's a combination protocol. This combination protocol was formed when the Transport Control Protocol (TCP) was combined with the Internet Protocol (IP). Second, TCP/IP forms the basis of a suite of other protocols used on the Internet and in corporate intranets.

A discussion of these other protocols is not within the scope of this chapter (see Chapter 4, "The Network and Transport Layers," for an in-depth discussion); however, the more common protocols, such as Telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP), are all part of this TCP/IP suite. The Internet was the proving ground for these protocols, and long before the Open Systems Interconnect (OSI) Reference Model was put together, TCP/IP was an entirely open system (see Chapter 1, "A Networking Primer"). Open simply means that any system claiming to be TCP/IP compliant can communicate with any other system claiming to be fully TCP/IP compliant.

When TCP/IP is fully implemented in RAS user-to-host connections, all the wonderful "toys" users are addicted to on their office LANs can also be used on their remote PCs. Web browsers such as Netscape and Internet Explorer, email programs such as Eudora, FTP programs such as WS-FTP, and others can all be implemented in the remote users' PCs.

TCP/IP has limitations, but it's still the number-one protocol used today to move data around. The future may change the way an IP packet looks, as the entire networking industry is looking to implement IPv6 addressing on all the Internet hosts, using a 128bit versus 32-bit addressing scheme (see Chapter 4, "The Network and Transport Layers").

As far as RAS is concerned, TCP/IP is currently the number-one workhorse, being implemented in all RAS connections. After the RAS connection has been established, TCP/IP is then implemented and activated by peer processes in the user and host computer systems. For this reason, the user system is assigned an IP address. This IP address is what's used to properly address and control the flow of data from user to host and from host to user.

Assigning IP Addresses
Any corporate LAN or intranet using TCP/IP as its means to address systems on the network also assigns IP addresses to RAS users and RAS connections. These IP addresses are either static (that is, never changing) or dynamic, which means that the network assigns a different IP address every time the RAS connection is made. Typically, this is done by the host system using a protocol known as Dynamic Host Configuration Protocol (DHCP). This protocol is implemented in a DHCP server (host system), and it assigns and keeps track of the IP addresses that are handed out on RAS connections. DHCP can also be used on LANs to hand out IP addresses when LAN users log on to their PCs.

After the RAS Connection Is Established
To establish a RAS connection, the user's PC (using a modem) dials the host system. The host system answers the call, establishes the connection, and upper processes in the host cooperate with upper processes in the user system to get the transport system running. With TCP/IP, the host either reads the IP address of the user system (if it's static) or assigns an IP address (in other words, dynamic IP is being used). Either one of these actions gets TCP/IP up and running.

After this has happened (that is, true TCP/IP connectivity is established between the user and the host), the user is now free to start the applications to be used over the RAS connection. These applications can now be used to give the user full access to the same services on the office PC.

Most users and hosts initiate TCP/IP as the main transport service on a connection. However, many people out there in smaller enterprises are still using the NetBEUI protocol as well as IPX/SPX These purely local area networking protocols are discussed in depth later, "The Network and Transport Layers," but we'll briefly look at why neither is today's protocol of choice for remote access.

NetBEUI is not the protocol of choice for several reasons:

NetBEUI is not a routable protocol like TCP/IP. NetBEUI signals have no real means to travel outside the confines of a LAN. In some cases, Token Ring source routing has been used to route NetBEUI from a Token Ring LAN, but this method is neither efficient nor effective. NetBEUI is optimized for the LAN environment only.

NetBEUI does not support the routing of messages to other networks, and its interface must be adapted to other protocols such as IPX and TCP/IP. If you feel you must use NetBEUI, the best method is to install both NetBEUI and TCP/IP in each PC on the LAN. Then you can set the server up to use NetBEUI for communication within the LAN and TCP/IP for communication beyond the LAN. This provides the best way to ensure that NetBEUI causes minimal problems. On a large LAN, TCP/IP is all you need; NetBEUI just slows things down. NetBEUI is a very chatty protocol. A lot of information is passed back and forth on computers that use NetBEUI as a data-transfer mechanism. This continual passing of information causes NetBEUI to hog a lot of space on the LAN when it's being used. The originating system sends out a broadcast packet to determine where the other computer is. Each computer on the LAN must examine this packet. On a large LAN, this amounts to constant packet examination by all the PCs on the LAN. Some LANs still use NetBEUI. RAS users dialing into these LANs need to use a program in their PCs that's capable of performing NetBEUI connectivity over the dial-up connection. Win32 systems provide this capability in its dial-up networking program. However, the bottom line is that you don't really want to use NetBEUI unless you have to.

One thing makes Novell's IPX/SPX combination a winner: It can be routed. It also performs error checking and allows internetworking of LANs. Because IPX is always dynamically routed and the routing architecture works by leaming network addressing automatically, nothing special needs to be done in the setup of an IPX network to get routing to function. IPX/SPX networking has several drawbacks, however:

It's more limited in terms of how many addresses are available. It consists of a four-byte network number, a six-byte node number, and a two-byte socket number. The node number is the hardware address of the actual user's PC network interface card (NIC). This number must be unique inside the particular IPX network. The network number must be the same for all nodes on a physical network segment. Socket numbers correspond to the particular service being accessed.

IPX/SPX connections require the capability to broadcast to other NetWare servers and IPX routers on the network. That's how they can all find one another on Novell networks. Because there's no effective way to broadcast using IP, all the servers and routers on the network need to maintain a list of the IP addresses of the other IPX servers and routers on the network, which can be a limiting factor.

Today, RAS users of Novell networks (up through version 4.x) are able to utilize certain TCP/IP transport mechanisms by tunneling IPX over TCP/IP. Tunneling is done by using UDP, another member of the TCP/IP suite. Novell networks can be set up to take IPX packets and place them inside UDP packets. These UDP packets are then packaged inside an IP packet the very same way TCP packets are packaged in a larger IP packet. After this has occurred, the IPX data is transmitted over the network in these IP packets. With NetWare 5, Novell has implemented full IP connectivity as a replacement for IPX/SPX.

In summation, RAS users are generally on TCP/IP connections when dialing into the host; however, there may be times when NetBEUI or IPX/SPX can be used. Therefore, it behooves you to know and understand these other two transport protocols.

PPTP
The Point-to-Point Tunneling Protocol (PPTP) is gaining a lot of attention lately because it enables RAS users to connect to a host system that may be far away on the other end of a TCP/IP network. In other words, a RAS user can dial into one host system, and this host system can then transfer the RAS user's data to another host system very far away on the same TCP/IP. Now you're probably wondering why this seems different from a RAS user simply dialing into a host that's connected to the Internet. After all, after he has done this, that connection provides access to all the resources on the Internet. However, when a corporation wants to maintain a private network and it's not large

enough to financially afford the costs of a large intranet, PPTP can help build an "intranet on the Internet."

That's the real utility of PPTP. It enables corporations to set up virtual private networks (VPNs) via the Internet. PPTP comes prepackaged with Windows NT/2000, and can be added onto Windows 95/98. RAS users can use the PPTP protocol to securely connect to a private network as a remote access client via the Internet. In other words, PPTP enables users to set up and take down on-demand, virtual private networks over the Internet.

PPTP has been successful because a PPTP forum was developed. The companies of the PPTP forum, which include Microsoft, Ascend Communications, 3Com/Primary Access, ECI Telematics, and US Robotics, are all working together to ensure the future of PPTP Figure below shows how PPTP sets up these VPNs over the Internet.



The process starts when the RAS user connects to a local ISP with a modem. This connection uses the PPP protocol to establish the connection and encrypt data packets. After a connection to the Internet established by the PPP protocol has been established, the PPTP protocol steps in and creates a control connection from the RAS user to the distant PPTP server on the Internet. This is a TCP/IP connection over the Internet, but because it was established by PPTP, it's called the PPTP tunnel.

Finally, the PPTP protocol creates IP datagrams containing encrypted PPP packets that are then sent through the PPTP tunnel to the PPTP server. The PPTP server disassembles the IP datagrams, decrypts the PPP packets, and then routes the decrypted packets to the VPN, which is typically a LAN on the other side of the PPTP server. In this way, PPTP creates a private network connection over the Internet. It's gaining a lot of attention these days, and ISPs are anxious to work with their clients to provide dial-up PPTP for travelling, hotel-bound, or telecommuting workers.

This means that small companies can have an intranet-like private network that runs over the Internet. In this situation, the costs to establish a wide area network (WAN) using PPTP can be a lot cheaper than having to actually purchase and install dial-up host systems all over the country. The dial-up access is provided by an ISP. When you look at the

cost of leased lines to connect hosts together, the amount can be staggering. However, the cheap, flat-rate pricing that most ISPs can offer makes it a common-sense choice to use PPTP to create a private network.

Network Operating Systems and RAS Capabilities
All three major local area networking operating systems-NetWare, Windows NT/Windows 2000, and Banyan Vines-support RAS in very similar ways. Although the discussion that follows focuses on Windows NT/2000 (which we'll call "NT" for simplicity's sake) , the same scenarios will work for all three networking systems.

To begin, we'll examine the two most common implementations of Windows NT RAS: Using RAS As an Internet Gateway/Router for a LAN
In order to act as a router or a gateway, an NT server must have two separate networks connected to it.

An NT server can sit between two separate networks, such as a LAN and the Internet. Within the NT server are two separate network interfaces. For this discussion, assume one of these interfaces is a modem. In almost all cases in which NT is configured to perform Internet gateway routing via RAS, the other network interface is a standard Token Ring or Ethernet network interface card (NIC). Figure below illustrates this point.

In the figure Network A is an Ethernet LAN connected to the NT server's NIC card, and Network B is simply a modem for connectivity to the Internet. This arrangement enables the users connected to the LAN to have access to the Internet through the NT RAS server. NT basically routes information between these two separate networks based on the IP address and subnet mask information.

As an example, assume that the IP address assigned to the Ethernet NIC in the Figure (Network A) is 234.56.78.90, with a subnet mask of 255. 255.255. 0. This means the NT server will assume any IP address between 234. 56. 78. 1 and 234. 56. 78. 254 resides on Network A. Any other IP address the NT server encounters is assumed to be out on the Internet (Network B) side of the server.

On the other side of the NT server, a modem connects to the Internet (Network B). The NT server has an account on an ISP, and the ISP assigns the block of IP addresses from 234. 56. 78. 1 through 234. 56. 78. 254 to this NT server.


If a user on the Internet sends data destined for IP address 234. 56. 78.50, this information is routed to the ISP via the Internet. After the ISP gets the data, it initiates a call by dialing the telephone number of the modem on the NT server. The server's modem answers the ISP's modem and establishes a PPP connection. Now the data destined to the NT server passes through the PPP connection to the NT server. The NT server, in turn, looks at the IP address being sent to it.

Because that address is one of the addresses the server knows is on the Ethernet LAN attached to its NIC card, it sends this data destined for 234. 56. 78. 50 out on the LAN. This data then flows to a PC assigned this address. That's how Internet data reaches the user on the LAN via the RAS gateway. Now consider the way information from the LAN destined for the Internet gets through the NT RAS server and out to the Internet.

Whenever users on the LAN send information to each other via TCP/IP they, of course, use their assigned addresses. Because all the addresses assigned in the example are between 234. 56. 78. 1 and 234. 56. 78. 254, you can have 254 users on the LAN constantly sending information to each other. This includes the NT server, because it has address 234.56. 78. 90 in this example.

You may be wondering how the NT server knows LAN traffic is passed among users on the LAN and does not need to pass through the server and go out to the Internet. If you recall, the subnet mask programmed into the NT RAS server for Network A is 255. 255. 255. 0. This is the magic that's making the gateway function work. Because it has a subnet of 255. 255. 255. 0, the server looks at each IP packet transmitted on Network A, the LAN segment. As long as the first three octets of a packet begin with 234. 56. 78, the server assumes this data belongs on the LAN and not the Internet. The subnet mask tells the story.

This is how subnet masking works. A mask of 255. 255. 255. 0 is telling the server to review the first three octets. If the subnet mask is 255. 255. 0. 0, the server reviews the first two octets, and if the subnet mask is 255.0.0.0, the server reviews the first IP address octet only.

When the appropriate number of subnet bits match the same number of the IP address physically assigned to the server, the server reviews the remaining bits and ensures it's not 90. If it is 90, the server assumes the data in this IP packet is addressed to itself, and in this example, it is.

Now, imagine that one of the users on the LAN sends out IP packets destined for IP address 236.45.11.2 and the data is destined for the Internet. The NT server looks at the address. Because the first three octets are not 234.56.78, the server knows this data is destined for a system out on the Internet. It passes that data out through the RAS setup, the modem dials the ISP's modem, and this establishes a PPP connection to send the data along its way.

We've just perfected an Internet/LAN gateway in both directions! This is probably the most common RAS setup utilized in NT servers hosting small LANs of between 5 and 75 users who want Internet access at an affordable rate. Most ISPs happily assist their users in setting this up. Your ISP can assign the IP addresses and subnet mask for your LAN based on your needs, your number of users, and the addresses it has available.

Using RAS to Provide Internet Access for Dial-in Users
If you want to look at the other side of the RAS coin, you need to understand how RAS implemented on an NT server can provide Internet access for a corporation's employees, as shown in Figure below

In Figure above, Network A is a NIC connection, as in the previous example. However, in this example, the NT RAS server is also tied to the Internet via an Integrated Services Digital Network (ISDN) connection.

Network B has the same setup as before. However, this NT RAS server is now a dial-in Internet access point for RAS users as well as an Internet gateway for the LAN users in Network A. The sequence of events that provide Internet access for a LAN user is pretty much the same as it was before, except this time, the RAS setup in the NT server is enabled for dial-in access only. Because this is the case, any IP packets addressed to an address other than one on the LAN are sent via the ISDN connection to the Internet.

If a dial-in user wants Internet access, the sequence of events is as follows. First, a user (Fred, in this example) dials into the modem (Network B). When a PPP connection is set up between Fred's PC and the NT RAS server, TCP/IP begins to flow across this PPP connection. Fred then sends out data destined for the Internet.

Assume for the purposes of this discussion that the IP addresses are the same as those used before. If you recall, the NIC in the server was assigned IP address 234. 56. 78.90, and the subnet mask being used on the LAN segment (Network A) was 255. 255.255. 0. Assume also that all the remote dial-in RAS users are assigned static IP addresses. (A static IP address is an address permanently assigned to a user.)

In this example, you can use the address 243. 65. 87. 10 to dial up Fred. Now, when Fred gets the TCP/IP flowing between his PC and the NT server, the NT server recognizes that Fred's address does not belong on the LAN. After all, it's not between 234. 56. 78. 1 and 234. 56. 78. 254, and it doesn't match up with anything else on the server. The server knows 243.65. 87. 10 is assigned to Fred. Anything Fred sends out not addressed to himself that does not fit between 234.56. 78. 1 and 234. 56. 78.254 is sent out to the Internet via the ISDN connection.

As mentioned earlier, the RAS is set up for dial-in access only, which is easily accomplished in NT RAS setup options. However, this does not mean that bidirectional IP traffic doesn't flow over the PPP link. It simply means the NT server knows incoming requests are to be handled by the RAS modem only, and this also means that Internet traffic coming to and from the LAN traverses the Internet ISDN link.

Likewise, after a remote RAS user has dialed into the server and established a TCP/IP connection, any Internet traffic coming to and from the RAS user traverses the Internet ISDN link. If Fred starts transmitting data destined for 166. 34. 27.128, the NT server knows that address is not on the LAN (Network A). The server also recognizes it as not being destined for the server's NIC card or for Fred. Consequently, data goes out the ISDN connection to the Internet.

In summation, two major RAS setups are being used today: RAS Security Issues
Security is always a concern on any network, and RAS setups are just as susceptible to security problems. However, the security issues for RAS are really no different than they are for any other network configuration, with a few exceptions.

Because Windows NT is the main operating system being used for RAS access, we'll discuss security issues in NT terms, but the principles apply to all operating systems.

No system is ever secure, and as soon as you place a modem on your network, you always open a door to would-be bad guys (sometimes wrongly called hackers). For example, recall the previous discussion about banks. They used to pass data from their central computers to their branch computers once a day. This practice was an early form of security. Any infiltrator who could get into a branch computer system could not use that access to get to the central computer in terms of adding money to an account. It also eliminated pulling money down to the branch office.

Three forms of security are used on RAS connections: Passwords
Anyone setting up a RAS system should set up user login IDs and passwords for the users who connect to the server. In NT, Novell NetWare Connect, Banyan Intranet Connect, and any other remote package, passwords are a standard option.

You must educate users not to use their names, Social Security numbers, and so on as their passwords, because these are easily detectable. They're the first passwords an infiltrator tries to use. Password use and administration are common sense. Passwords are the first line of defense on most RAS servers.

Dialers
Dialers provide another wall of defense following passwords. Most dialers function by requiring a secret code number to be transmitted to the server by the user of the RAS services. When the user dials into the RAS server, it's configured to ask for a certain code number. This code number may be randomly generated by the dialer or put into the dialer each time the user uses the system to make a RAS connection.

Dialers, code dialers, and code-generating dialers are very popular with large corporations. If a corporation has a large, almost unmanageable amount of people using its RAS services, a dialer can provide an excellent way to ensure that security is maintained. Weekly code updates can be distributed only to valid employees. In this manner, a former employee or infiltrator is thwarted when trying to log onto the network.

Callback Systems
These systems date back to the 1960s. In those days, infiltrators weren't as computer savvy. Therefore, security consisted of adding a simple callback system. When an authorized user entered his login ID and password, the system would hang up and dial a predetermined number to call this user back, thereby ensuring that he was at the appropriate physical station. This worked fairly well until criminals learned how to tap the lines coming out of the computer system, By doing this, they could answer the callback.

Today, callback is used very rarely in private industry, but when used, it's usually combined with some sort of code-generating software. This ensures that the person being called back is not an infiltrator who tapped into the computer system's telephone lines. This type of security is not a standard part of NT's RAS software, and any callback service implemented has to be done with a callback software application. However, if done correctly, callback can be one of the strongest ways to keep bad guys out of your system. For that reason, the U.S. government and many security agencies have implemented personalized callback systems that are virtually foolproof in most cases. Many private industry organizations are actually reconsidering the virtues of callback systems, because they can be made almost airtight when combined with code-generation software.

Intranets and the Internet
Initially, intranets weren't really intranets. They were amalgamations of leased lines and routers that companies used to forward packets of data for their users and traditional business application types. The predominant internetworking protocol used in these private leased-line networks was the Internet Protocol (IP). The commercialization of the Internet and the proliferation of hypertext led to the evolution of private IP networks into intranets. Many companies unwittingly began this evolution when they interconnected their private IP wide area networks (WANs) to the Internet. Ostensibly, this was done to provide access to the rich and vast data stores of the Internet, but this was just the first step in a fundamental change in the way they would use IP WANs in the future.

After the interconnection with the Internet was established, the evolution from IP WAN to intranet became inevitable. Companies immediately began to look for ways to turn the cost of the interconnection into a source of revenue, rather than strictly an added expense. This meant exploring the technologies needed to build, maintain, and support a presence on the Internet.

Users, too, began exploring the new world. Browsers were free (if you didn't mind downloading a new evaluation copy every 30 days!), and the Net beckoned. These adventurous users quickly tired of surfing. They began experimenting with creating their own individual and/or organizational home pages. The net effect was a somewhat ad hoc acceptance of the tools and technologies that would transform internal IP WANs into intranets. The actual transformation would have to wait until companies figured out what they could do (besides play) with these new technologies.

What's So Special About the Web?
The key enabling technology that made the Internet's content available to the masses, both individuals and companies, was the hyperconnectivity of the World Wide Web (WWW or Web). The Web is, arguably, the first successful universal middleware. Its combination of protocols, programming language, and universal client-presentation mechanism enables its executable programs, known as content, to run on almost any physical platform. This is possible because Web programs use a software-based runtime environment: the browser.

Note: Middleware is any software that performs a translation, conversion, or other intermediary function. As such, the term can be applied to an incredibly wide variety of software products. The benefit of having an intermediary is that it provides a consistent application programming interface (API), independent of physical platforms.

The Hypertext Transfer Protocol (visible as the browser's HTTP command) was developed by CERN, a Swiss particle physics laboratory, to facilitate research on the Internet. This protocol put the Internet's content a mouse-click away. Hiding content location behind a point-and-click graphical user interface (GUI) made obsolete much of the older, more painful means of finding and retrieving Internet files, such as the File Transfer Protocol (FTP) of the IP protocol suite. FTP is still useful, and very much needed; it just isn't used as a primary Internet information-retrieval mechanism.

What About Intranets? The success of the Internet and its World Wide Web accelerated the evolution of IP WANs to intranets. This was facilitated by the continuous development of Web-based software tools that were expressly designed for corporate environments. Software manufacturers realized that the real money to be made in Internet and Web technologies would come from companies, not individual users. Consequently, they targeted this market aggressively and developed everything from graphical user interface tools for the creation and management of sites and their content to new programming languages specifically designed for private, corporate Web environments.

Database companies, too, provided APIs for their products, as well as middleware that would enable users to extract data from their databases using a browser. The result of these investments in intranet technologies was the rapid success of almost anything Web related. Internal IP WANs became intranets when they embraced the WWW middleware and began using it broadly in support of their business processes. To be sure, early adopters limited their efforts to posting pictures of their families, pets, houses, cars, and so forth on the Web, but these insipid efforts were a necessary part of learning the capabilities of the new Web technologies.

Today, the browser is well on its way to becoming the universal presentation layer for all interactive applications. Even traditional, interactive applications are poised to become enveloped by intranets. Some of the more obvious examples include the replacement of conversant telephony systems and paper forms with Web-based systems. The possible uses for an intranet are limited only by one's imagination and budget.

The Key Differences Between the Internet and Intranets
Although they may appear technologically and functionally similar, intranets and the Internet must remain quite separate and distinct. The Internet is intentionally not secured. It's designed to be accessible by the general public, as well as by members of companies, educational facilities, government and/or research organizations, and so forth.

Intranets cannot afford such unrestricted accessibility. Access to networked resources must be parsed out on a need-to-have basis, even among the employees of the company. If such restrictions are essential to maintaining the integrity of the data, the implications of using IP to interconnect that carefully controlled network environment to the wild and (relatively) unregulated Internet are staggering.

The information assets of private IP WANs that are interconnected to the Internet must be protected from access by the general public. Typically, mechanisms such as firewalls (see the section "Firewalls Are No Panaceas," later in this chapter), access lists, host and application layer security, and so forth are used to limit access to the intranet resources

from the Internet. Given that the networked computing resources of an intranet are blocked from general access, the intranet (and its content) can't really be considered part of the Internet. Therefore, its inward-focused mimicry of the Internet has resulted in its name: intranet.

Extranets
As information technology architects have become increasingly familiar with the usage and capabilities of intranets, the need for selectively extending intranets beyond their traditional borders has become apparent. Specifically, any scenarios that feature tightly coupled or interlocking business processes between two or more companies are logical candidates for an extranet. An extranet is a selective integration of two or more intranets for the purposes of facilitating specific business processes.

Developing the extranet requires the interconnection of the participants' networks or intranets. Providing any connectivity at all using IP, or any other open internetworking protocol, results in the exposure of the entire contents of both intranets to accessibility from the other. Any security lapses on one side of the extranet automatically become security lapses for both intranets. The net effect of interconnecting two intranets is the creation of one large but semiprivate network. Ostensibly, some measure of trust and mutual dependence or interdependence must first exist on the business level before an extranet can be considered. Similarly, the benefits of an extranet must also be quantifiable and desirable to both parties; otherwise, they would not knowingly undertake such a risky venture.

The key to successful extranetting is to manage the risks down to an acceptable level. This requires understanding the risks inherent in the internetworking technologies.

rnetworking technologies.