Apogee Communications Technologies, Inc

Home

About

Solutions

News and Views

Product Focus

Links

Contact


Incorporated in 1994, providing consulting services in the New York Metro area in communications technologies - security, networking, systems architecture, design, implementation, certification and deployment.
 


VPNS - what are they and how do you choose the right one for your application?
 

Communications engineers use a layered model to help isolate functionality. It is very helpful to consider security in the context of these layers. VPNs can be built at any of the first 5 layers, but each has a quite different capability. The higher the layer, the greater the flexibility and the lower the deployment costs, but functionality is increasingly limited.

  1. The Physical layer. Traditionally this refers to the "wire" - an RS232/422 cable, 10Base2 Coax, 10 BaseT ethernet, optical fiber, etc. Nowadays this includes frame relay and other multiplexed media access methods. However the prevalence of wireless access where a so-called "Wired Equivalency Protocol" does not provide security truly equivalent to actual wire. The deregulation of the telecoms companies means that relying on limited access to cables is not as secure as it was. So Physical layer security is no longer adequate, even in a leased line environment. However, generally frame relay is considered acceptably secure but is still suffers from the disadvantage of requiring provisioning of point-to-point capacity for every site. VPNs at this level are very costly, inflexible, but can support ANY protocol.

  2. Data Link Layer. This essentially is the layer that describes the organization and timing of bits ]on the wire. Bisynch, HDLC, etc. are examples. There are security standards for this layer (L2PP, for example) and are quite suitable for point-to-point links. However, few real life applications are point to point. Note that at this layer, there may be any number of devices connected to one physical medium (Ethernet, Wireless Access Point, etc.) and they must each have a unique identifier (typically a Media Access Code or MAC). VPNs at this level are somewhat costly and inflexible, but can support most protocols.

  3. Network layer. This layer provides a mechanism for collections of devices to communicate with each other in an efficient way (i.e., by only passing relevant traffic from one collection to another). This environment is known as an internet. The public version of this is called the Internet, and a protocol, the Internet Protocol or IP has become the de-facto standard. Data to be sent over an IP network is split into packets and encapsulated with an IP header that contains, amongst other useful items, the source and destination address of the packet. Routers figure out how to forward the packet to its destination, converting the stream to the correct data link layer representation for each hop. IP forwarding is best-effort - there's no guarantee that the packets will arrive, and, of course, the contents are visible to every node it passes, resulting in every conceivable security vulnerability.

    IPSec (IP Security) is a fairly recent standard for security at the network layer. It comes in several flavors. One, best suited for site-to-site communications, requires an IPSec gateway at each site. Another, best suited for dedicated remote access (where the remote terminal does not access the Internet except to use the VPN) relies on a so-called IPSec shim to be installed on the terminal. The major bugbear is Network Address Translation (used to make one IP address serve multiple hosts) which blocks IPSec. VPNs at this level are less costly (the major cost is finding engineers who can program and manage the gateways), very flexible, but limited to IP and higher level protocols that use IP. In site-to-site mode it provides for bilateral authentication which may be a critical feature. It is very important to use a centrally managed solution (such as the Avaya LSMS), because for anything other than a very simple network, management becomes a nightmare.

  4. Transport Layer. Provides ends-to-end connectivity - takes care of making the underlying networks invisible. Two most popular examples: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP on IP (TCP/IP) provides delivery guarantees, in-order reception of data, and flow control. UDP does not. Netscape invented a security protocol the called Secure Sockets Layer (SSL) which is a resource intensive way of protecting individual transient TCP connections. The IETF has standardized this as TLS, Transport Layer Security. It is not meaningful to build a VPN at this layer in the model.

  5. Session Layer. Here, data streams are aggregated and passed in the context of an Authenticated, Authorized, and Audited session. ISO X.400 and X.500 relied on this but no practical implementations ever came into being. Sun's iPlanet Portal implements this exactly, multiplexing multiple data streams onto an SSL connection. It uses a unique local (i.e., at the PC or terminal) proxy called a Netlet (deployed as a signed Java Applet). If your VPN only has to support TCP/IP, and can tolerate synchronous round-trip delays, then the iPlanet Portal is a comparatively low cost, easy to deploy and configure way to implement a VPN.

  6. Presentation Layer. Largely defunct, this layer provided for virtual agents to map specific devices to virtual devices, for example, different terminals might map to a universal terminal so that a VT420 could talk to a 3270 controller. Nowadays this is wrapped into the next layer, You could consider (but nobody does) that HTML and XML belong here. Certainly, VPNs don't.

  7. Application Layer. Standard application protocols are defined here - like FTP, SMPT, HTTP, Telnet, etc. Programs like the Secure Shell implement security at this level but are not really suited for VPN construction.

Whatever your security needs, ApogeeCT can provide an engineered recommendation/solution. Please contact ApogeeCT for more information or for a worksheet.



Copyright © 2002,2003 Apogee Communications Technologies Inc., All Rights Reserved. Privacy Statement. Comments or suggestions? Please send email to the site administrator