For remote LAN access, the protocol of choice is the Internet Engineering Task Force's (IETF's) Point-to-Point Protocol (PPP). PPP is defined in RFC 1134, "The Point-to-Point Protocol: A Proposal for Multi-Protocol Transmission of Datagrams over Point-to-Point Links" and RFC 1661, "The Point-to-Point Protocol (PPP)." These RFCs provide a standardized method for transporting multiprotocol datagrams over point-to-point links.
The PPP algorithm moves network packets over a modem or ISDN link by placing them inside a high-level data-link control (HDLC) frame. The algorithm then transfers the frames over the circuit-switched connection to the network. Once the packets arrive at their destination, the PPP algorithm removes them from the frames and places them on the network. Interestingly, both ISDN and PPP employ the same HDLC-based frame structure, as shown in the figure
"Frame Formats"
.
PPP can operate over a v
ariety of serial devices, as well as over just about any serial link, including those using analog modems. But when it comes to PPP performance, throughput is important. For decent PPP connections, the connection should use nothing less than a 14.4-Kbps (V.32bis) modem on both ends; 28.8-Kbps (V.34) or faster modems are highly recommended. ISDN devices generally have sufficient throughput (64 Kbps on two B channels) to do a good job of supporting PPP sessions.
On an enterprise network, a communications server and a bridge/router bank provide access for PPP connections. These same tools are used by an Internet service provider (ISP) offering Internet access. The user's PC establishes a connection to the network through PPP client software running on the PC.
The same method applies whether modems or terminal adapters are used on the remote side to connect to the Internet or to an enterprise network. A PPP-based package, such as NetManage's Chameleon or Novell's LAN Workplace for Windows, is installed
in the remote PC. The PC is then connected via the serial port to a modem or terminal adapter.
PPP packages generally include dialer software, which handles the task of establishing the telephone connection. Once the connection is made to the network, PPP negotiates the Link Control Protocol (LCP) and authenticates the remote device. If these negotiations are successful, the network session begins.
Bridging Issues
Terminal adapters and modems are not the only devices that have the ability to support PPP. A PPP connection can also be made through a remote side bridge or router that supports PPP internally. With a bridge or router, the remote PC is connected via a network interface card (NIC) over a small LAN between the PC and the ISDN device. The negotiation process works in much the same manner to bring up a PPP session with a bridge or a router as it does with a modem or a terminal adapter.
An enhancement to PPP, called Multilink Point-to-Point Protocol (MP), is defined in
IETF RFC 1717, "The PPP Multilink Protocol (MP)." MP has the ability to aggregate multiple ISDN B channels for enhanced throughput. It can handle a maximum of 384 Kbps (six B channels) before compression, which is certainly a respectable throughput rate in anybody's book.
PPP can be used whether the serial connection is provided by bridges or routers. But there are differences between PPP connections over bridges and those over routers. Bridges tend to be simpler to configure but provide fewer capabilities than routers. The figure
"Stacks Compared"
shows a typical PPP bridging stack and a PPP IP routing stack.
Note that the same interface appears at the top and bottom layers of both stacks. Whether bridging or routing is in use, the network protocol is always on the top layer. The bottom layer is the PPP framing on the B channels. That is, the layer is ISDN layer 2, where the PPP packets are placed in HDLC frames.
The difference between bridging and routing stacks occurs
when the control protocol is in use. A bridging stack uses the IETF-defined Bridge Control Protocol (BCP). BCP, which operates on layer 2, is responsible for examining the packets and determining their destination. A routing stack operates on layer 3. It supports many of the functions that are typically found in routing, such as time to live, least-cost routes, parallel links, protocol filtering, and other functions.
While BCP supports all protocols, routing stacks must be created to support specific protocols. For example, the IP Control Protocol (IPCP) is an IETF-defined protocol that performs the routing network functions for TCP/IP. If IPX is implemented in the router, then the IPX Control Protocol (IPXCP) is used in place of, or in addition to, IPCP. Similar control protocols are being developed for other network protocols.
Secure Conduits
The IETF has defined two protocols for security over PPP connections. The Password Authentication Protocol (PAP) and Challenge-Handshake
Authentication Protocol (CHAP) are both specified in RFC 1334, "PPP Authentication Protocols." PAP and CHAP are often included as internal protocols in ISDN network devices.
PAP and CHAP both support the authentication of remote devices. However, PAP provides only a basic authentication level. Under PAP, an identification, a password, and account pairs are repeatedly sent by the remote device to the authentication device. This is done until authentication is acknowledged by the authentication device or the connection is terminated.
Since PAP sends passwords "in the clear," there's some risk that the connection's security may be compromised. For example, a hacker could record the legitimate user's PAP log-in sequence and then play back the recorded log-in at a later time to gain access to the network. Since PAP has no time-out function, the hacker is free to use repeated trial-and-error attempts.
CHAP is a more robust authentication protocol. The CHAP algorithm depends on a calculated value, or
"secret," that's at least 1 octet in length and is known only to the authenticator and the remote-access device. Because the CHAP secret is never sent over the link, it's highly effective against playback and trial-and-error attempts.
Instead of sending the secret, CHAP sends a "challenge" to the remote unit attempting to connect to the network. The remote unit responds with a value calculated by a common algorithm used by both devices. The authentication device checks the response against its own calculation of the expected value. If the values match, the authentication is acknowledged; otherwise, the connection is terminated. RFC 1334 expects each new challenge value to be unique, which prevents an attacker from using a previously intercepted response to obtain network access.
CHAP and PAP help ensure that the correct remote device has dialed in to the network. You should remember, however, that both protocols authenticate only the remote device. They do not authenticate the user or the calling nu
mber. Therefore, they should always be used in combination with other security methods, such as log-in sequences and caller ID. Additional security measures, such as Kerberos, the Terminal Access Controller Access Control System (TACACS), and the Remote Authentication Dial-In User Service (Radius), should be used to supplement PPP security.
illustration_link (15 Kbytes)
Both ISDN and PPP use the same HDLC-based frame structure, which expedites the process of routing frames through a network.
illustration_link (14 Kbytes)
Both stacks present the same interfaces; this allows easy integration of devices into a large network.
Jeffrey N. Fritz is a telecommunications engineer for West Virginia University's Telecommunications and Network Services department. He is the author of Remote LAN Access: a guide for networkers and the rest of us (Manning Press/Prentice-Hall PTR, 1996). You can contact him at
jfritz@wvu.edu
.
Building Bridges and Secure Connections
