10.3 VPNs in a WLAN Environment

As the Internet has increased in popularity, its use as a public medium for transporting data between private networks has also increased. Correspondingly, the inherent security risks of transited data over the Internet has also increased. VPNs provide a method to securely communicate over public or unsecured network connections. VPNs use encryption to ensure that third parties cannot read data in transit and authentication to ensure that only authorized users can access the network connection. VPN servers are essentially encrypting routers that provide authentication support.

Before VPNs, dedicated leased lines that linked the various local area networks (LANs) were the only way to safely connect multiple sites within or between organizations. The high expense and time required to install dedicated lines limited this type of solution to very large corporations that could afford to absorb such expenses. VPNs can be used to create inexpensive secure connections at a fraction of the cost of a leased line. VPNs' ease of use and practicality in the Internet environment has resulted in wide industry acceptance as an alternative to leased lines and for use in preventing unauthorized access. VPNs provide very secure encryption and increased security through point-to-point connections. Other advantages of VPNs in wireless environments include that (1) established standards are readily available from many vendors , (2) significant numbers of VPN servers work with established authentication methods such as RADIUS, (3) Web browser authentication can also be used to allow almost any type of user access to the network, and (4) most security administrators already understand VPN technology. In contrast to 802.1 x /EAP solutions, Class-of-Service (CoS) mechanisms such as Role-Based Access Control (RBAC) can be deployed in VPNs to reduce broadcast domains.

A form of encapsulation called tunneling is used in VPNs. Tunneling is where one protocol is carried within another from one endpoint to another inside the VPN. Encapsulation, data integrity, and data encryption are the primary properties of VPN connections. When private data are encapsulated, they include a header that allows the data to transit the Internet, so each network serves to authenticate the user, and the VPN server can authenticate the client to verify whether the client has permission to access the network. If mutual authentication is used, the client will also verify the VPN server's identity. Cryptographic checksums can be included for data integrity, so the receiver can verify that the data originated from the sender and were not tampered with in the process of transmission.

A key is used by the sender to encrypt data and by the receiver to decrypt data. The size of the key and the type of encryption algorithm used will determine how easily an attacker could decrypt the data. It should be noted that stronger encryption algorithms require more time to be processed by the VPN server and by the client device necessary to encrypt and decrypt data. This process can affect the latency of the transmission.

When a VPN is used over a wireless medium, it is normally referred to as a wireless VPN. Mobile users can use wireless VPNs to securely access a corporate network from remote locations such as a wireless hotspot or from segmented parts of the LAN behind an enterprise wireless gateway or firewall device. A wireless VPN also ensures data privacy over an unsecured network segment, preventing a potential attacker from analyzing wireless data connections that could provide the attacker with passwords or other sensitive data.

VPNs have an advantage over other solutions because they consist primarily of resources that are already in place and that can be enhanced by VPN hardware products, software packages, or both. These additional components are used to implement the VPN security protocols. In most organizations, VPNs are limited to internal data that transit the Internet. VPN security is applied between a pair of endpoints, each of which is connected through the Internet to one or more computers. The VPN client is the device that initiates a connection to a VPN server, also called a VPN concentrator. A VPN client can be either an individual computer that requires remote access or a router that obtains a peer-to-peer or router-to-router VPN connection.

A VPN connection between the locations is referred to as a tunnel. This tunnel results from the encapsulation of one protocol inside another. Credentials provided by the client or peer device are used to authenticate to the peer or VPN server device. VPN authentication commonly occurs through the use of identity validation methods such as passwords, SmartCards, certificates, or biometrics. The data is encrypted on one end of the connection and transmitted to the other end, where it is decrypted. The VPN ceases to exist when one side terminates the connection. Communication standards used to build and manage these tunnels and to encapsulate private data are called tunneling protocols . The Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP) [15], and Internet Protocol Security (IPSec) [16] are the most common protocol standards used in VPN solutions today.

In any wireless environment, maximum security requires that both Layer 2 and Layer 3 of the OSI model (see Figure 10.1) should be secured. Although VPN technology is an important part of an overall security design, VPNs do not always fulfill every design requirement in a wireless networking environment. A deployment that maximizes security may result in high costs, reduced throughput, high network overhead, and high administrative overhead. It is important to ensure that the cost of the solution is directly related to the value of the data being protected. In other words, does the solution warrant the burdens that might result from its implementation?

VPNs had broad industry acceptance well before they were used as a WLAN security solution. The concepts of VPNs have been understood by security administrators for many years , well before the recent proliferation of WLAN networks. 802.1 x solutions have become popular because of the higher costs and difficulty often associated with implementation of VPNs. Many manufacturers suggest that 802.1 x /EAP solutions are better suited to wireless as a single solution rather than VPNs; however, they neglect to discuss the high costs, high encryption overhead, and redundant authentication associated with incorporating Layer 2 solutions with Layer 3 solutions. This has resulted in 802.1 x /EAP solutions gaining popularity over VPNs in some markets. Other disadvantages of VPNs include their expense, advanced routing difficulties, interoperability issues between VPN technology vendors, lack of operating system support for VPNs across multiple platforms, difficulty in configuring, deploying, and maintaining clients and servers, reduced throughput because of high encryption/decryption overhead, and the fact that subnet roaming is subject to breakage because of the reliance on Layer 3 technology.

Layer 3 VPNs have an inherent security flaw when used in wireless networks because wireless networks operate at Layer 2 of the OSI model and leave access points and wireless bridges open to attack. Using an Enterprise Wireless Gateway (EWG) or a VPN server appliance as a WLAN solution only exacerbates this problem. Despite the advantages of using an EWG, a serious security issue may result if it isn't dealt with properly. 802.1 x solutions provide a layered security solution that can eliminate this risk.

A rather serious security risk is encountered when companies deploy wireless solutions with VPN technology for use by an employee from home to allow them to telecommute through the VPN. Any neighbor or passerby could associate to the residential access point. An IP address from the employee's home network must be allocated and treated as a known and trusted host on the network. Locating an attacker that uses this method of attack is virtually impossible under these circumstances because their use of an open wireless access point can only be traced to the employee residence.

Remote NOC or IT data centers usually administer wireless VPNs. There are often unsecured wired networks between the points of management and the VPN devices. Remote management of VPN servers should be conducted over a VPN tunnel. Wireless hotspots are securely managed in this manner. Distributed VPN servers will terminate tunnels to wireless clients and wrap all user data in another upstream tunnel to deliver the data securely to a centralized VPN server that connects to the Internet and/or a corporate network.

To ensure that the VPN technology will grow with your organization, the following should be considered when choosing a VPN solution for your enterprise:

Replacement and end-user retraining
Standards support and maturity
Price of new hardware and software components
Vendor interoperability
Use of proprietary software
Whether or not the new devices fit within the existing network
Security and management architectures

The wireless network you are designing may be required to expand to serve hundreds or even thousands of users. Therefore, it is imperative that the wireless VPN solution can scale to meet the forecasted demand of users.

One of the primary reasons for installing a wireless network is so users have the ability to roam and retain access to the corporate network. If VPN subnet roaming is not corrected with proper feature sets, the value of a wireless VPN is lost. When a user roams across routers, the computer typically obtains a new IP address from the new subnet using DHCP. VPN connections will break and interrupt any data flow in process as a result of this roaming and change in IP addresses. Mobile IP has been successfully introduced as part of the VPN solution to solve this problem. Routing protocols and bridged interfaces are used to bridge together wireless and wired networks, and they are also used by some vendors to solve subnet-roaming problems while using a VPN solution. In theory, this combination works well, but it is complicated to configure and manage in large environments.

When using VPNs in WLANs, segmentation will happen at Layer 3 in the network rather than in Layer 2, as with 802.1 x /EAP solutions. This design is especially processor intensive and requires skilled, experienced IT professionals to implement it correctly. The wireless security design differs greatly from that used for an 802.1 x /EAP solution. For example, it may be necessary to deploy a networkwide virtual LAN (VLAN) or multiple VLANs just for use with wireless. Although this method is the accepted standard and is widely used today, it requires significant administrative overhead for deployment.

10.3.1 VPN Types

Although there are many types of VPNs (including remote access, extranets, branch offices, SOHO, and wireless), there are only two types of connections: remote access and router-to-router. This section provides an overview of how VPN technology is used with WLANs. When VPN technology is used in a wireless environment, a client must have VPN software loaded whether or not it is a computer or a router used as a client.

The VPN server can provide upstream network access to the client or to just those network resources the VPN has available locally. A connection to a VPN server is created when a client initiates a remote-access VPN. A remote-access VPN is a point-to-point connection where packets are transmitted through the tunnel originating from the client and are sent to the server or from the server to the client. For added security, VPNs can be configured for mutual authentication of client and server; however, in most cases, such as dial-up Remote Access Server (RAS), authentication is not mutual, and only the server authenticates the client.

A VPN connection over a wireless medium leaves the access point open to attack. Access points are Layer 2 devices that can be managed at Layer 3. Because they are Layer 2 devices, they do not care what kind of traffic is traversing the wireless medium and will simply forward all traffic from the wireless side to the wired side without regard for security; however, if the VPN server is implemented directly inside the access point, it will act as more of a wireless router than just an access point. Combined with secured management features such as HTTPS, a VPN provides a very secure solution but results in slow processing problems. Because wireless access points are generally inexpensive devices lacking powerful CPUs, the added overhead of VPN management features, access point features, routing functions, high encryption overhead, and overall VPN setup and tear-down will degrade the performance of these units very quickly.

Secure VPN redirection occurs when an access point is configured to allow incoming VPN traffic to be sent to a single VPN server host. This should be considered when only one VPN server is being used. Each wireless router is redirecting the VPN traffic to a specified IP address.

EWGs are the most common implementation of VPNs in WLAN environments. EWGs typically have VPN features, remote management, firewall features, RBAC, throughput management, and many other useful features.

Some VPNs can be configured for mutual authentication of client and server for added security. In many cases, such as dial-up RAS, authentication is not mutual, and only the server authenticates the client. A remote-access VPN is created when a client initiates a connection to a VPN server. The VPN server can provide upstream network access to the client or to network resources the VPN has available locally. Because a remote-access VPN is a point-to-point connection, packets are transmitted through the tunnel originating from the client and are sent to the server.

PPTP, L2TP, IPSec, and SSH2 are some of the many types of VPN protocols that are used in conjunction with WLANs. All of these protocols rely on tunneling of some form and usually employ encryption. The method and level of encryption levels deployed with each of the VPN types varies greatly. VPN encryption can take place through either a software-or hardware-based solution. Software-based encryption/decryption typically increases latency and decreases throughput. In contrast, hardware encryption/decryption accelerators decrease latency and increase throughput.

Accelerators, also called off-load processors, are often included in access points and VPN servers for speeding up the encryption/decryption processes used in WEP. In some cases, the VPN server is implemented as part of a PC server, where a PCI card and accompanying software serve as the accelerator. The accelerator is often another chip on the motherboard when implemented in a VPN appliance such as an EWG. Newer EWGs may have gigabit Ethernet interfaces. These units normally don't push more than 100 Mbps of heavily encrypted (e.g., IPSec using 3DES or AES) traffic and only have Gigabit interfaces for use when encryption is not desired. It is common to see EWG units push traffic at around 300 Mbps, even when encryption is not used.

PPTP

Point-to-Point Tunneling Protocol (PPTP) is a simple, low-cost, easy-to-implement wireless security VPN solution based on the client/server architecture. It supports multiple encapsulated protocols, authentication, and encryption based on the Point-to-Point Protocol (PPP) [17]. Most of Microsoft's desktop and server operating systems having PPTP [18] native support.

Microsoft Point-to-Point Encryption (MPPE) is supported by PPTP using the RC4 algorithm with a 128-bit key. Most local and external authentication using RADIUS is supported through PPTP on VPN servers. A software product called POPTOP has been implemented on Linux servers to provide PPTP support and is fully compatible with Microsoft PPTP client software. The destination IP address, encryption parameters, username, and password are the only pieces of information needed to form a PPTP connection, making it very popular for use over wireless networks.

PPTP forms a tunnel between the client and server. DHCP can be used for both subnets inside and outside the tunnel, eliminating most of the administrative overhead. PPTP is often implemented as an IP-in-IP tunnel (http://faqs.org/rfcs/rfc1853.html), where the client/server connection has an IP subnet and the tunnel has a different subnet, with the tunnel IP addresses typically allocated by the PPTP VPN server.

On wireless networks, IP-in-IP is by far the most common protocol used for encapsulating data transported with PPTP. The PPTP client connects with the server by "dialing" the server over the IP network. The server authenticates the user and establishes a tunnel address to begin passing traffic to and from the client.

Typical authentication methods used by PPTP are PAP, MS-CHAP, and MS-CHAPv2. Because of the security requirements placed on WLAN implementations by most organizations, MS-CHAPv2 authentication against a RADIUS or LDAP-compliant database with MPPE encryption is commonly used for security. The 128-bit MPPE provides adequate security protection for most SOHO networks or networks that do not have high-value /sensitive data or systems to protect. When keeping administrative and network overhead costs down is a higher priority than security controls, encrypting data with 128-bit MPPE inside a tunnel provides enough protection to stop the casual or unskilled war driver while maintaining due diligence in protecting noncritical corporate data.

L2TP/IPSEC

L2TP combines the best of Cisco's Layer 2 Forwarding (L2F) protocol and Microsoft's PPTP. It is a key building block for VPNs in the dial access space [19]. Cisco and other network industry leaders support L2TP. Large implementations of call terminations in the Telco and ISP space commonly use L2TP. L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS) are the two distinct components of an L2TP network. A client's physical connection, such as a dial-up connection to the Internet, is terminated by the LAC, and the upstream LNS terminates the PPP session. This solution is highly scalable for Telcos and ISPs because LACs can route PPP sessions to various service providers or locations. L2TP is often combined with IPSec for security because it does not define any encryption standard.

Mutual authentication can be achieved through IPSec using shared keys or certificates and strong encryption. Although L2TP's current use in wireless networks is rare, it will likely gain popularity as L2TP support is included in EWGs. As a result of the rapid increase of hotspot users throughout the world, Wireless ISPs (WISPs) will gain market share, and L2TP/IPSec will find an appropriate use in the marketplace . Both the Microsoft Windows 2000 and Windows XP operating system support L2TP/IPSec VPN technology.

L2TP/IPSec and PPTP are similar in that they both provide a logical transport mechanism to send PPP frames; provide tunneling and encapsulation, so that PPP frames based on any protocol can be sent across an IP network; and rely on the PPP connection process to perform user authentication, typically using a username, password, and protocol configuration. They do, however, have some significant differences. With PPTP, data encryption begins after the PPP connection process and authentication are completed, so the user authentication process is not encrypted. Data encryption begins before the PPP connection process with L2TP/IPSec, so the user authentication process is encrypted. MPPE uses PPTP connections, which use the Rivest-Shamir-Aldeman (RSA) RC-4 encryption algorithm and 40-, 56-, or 128-bit encryption keys. The Data Encryption Standard (DES) algorithm is used for L2TP/IPSec connections, which uses either a 56-bit key for DES or three 56-bit keys for Triple DES (3DES). The Microsoft L2TP/IPSec VPN client supports only DES encryption.

PPTP connections require only user-level authentication through a PPP-based authentication protocol. L2TP/IPSec connections require two levels of authentication. To protect the L2TP-encapsulated data, an L2TP/ IPSec client must perform a computer-level authentication with a certificate or a preshared key to create the IPSec Security Associations (SAs). The L2TP portion of the connection performs the same user-level authentication as PPTP after the IPSec SAs are successfully created.

PPTP only provides per-packet data confidentiality, whereas IPSec provides per-packet data origin authentication. This function is significant because it will help comply with new regulatory requirements by providing transactional nonrepudiation with proof the data was sent, accessed, or viewed by the authorized user. Data integrity is provided because there is proof the data was not modified in transit. PPTP also provides replay protection by preventing the resend of a stream of captured packets. Data confidentiality is achieved by preventing the captured packets from being interpreted without the encryption key.

Two steps necessary to complete the authentication process are used by L2TP/IPSec connections to create stronger authentication: (1) using certificates or preshared keys as a computer-level authentication for the IPSec session, and (2) using a PPP authentication protocol for the L2TP tunnel as user-level authentication. If captured as plaintext, the PPP authentication exchange for some types of PPP authentication protocols can be used to perform offline dictionary attacks and determine user passwords. By encrypting the PPP authentication exchange using L2TP/IPSec, offline dictionary attacks are only possible after the encrypted packets have been successfully decrypted. PPP frames exchanged during user-level authentication are never sent in cleartext because the PPP portion of the exchange occurs after the IPSec SAs are established.

One of the problems with L2TP/IPSec is the Internet Key Exchange (IKE), the protocol used to negotiate SAs, and the fact that IPSec-protected traffic is not NAT-translatable. This prevents IPSec peers from being placed behind a Network Address Translator (NAT). A new set of Internet standards describe IPSec NAT traversal, allowing for L2TP/IPSec connections to be created. The new standard addresses client and server computers that support IPSec NAT traversal located behind one or more NAT segments, where IKE messages and processing are modified and IPSec-protected packets are encapsulated as User Datagram Protocol (UDP) messages.

L2TP/IPSec could only be used with Windows XP and Windows 2000 until the release of the Microsoft L2TP/IPSec VPN client because only those VPN clients supported the L2TP protocol and IPSec. The release of the Microsoft L2TP/IPSec VPN client has made it possible for computers running all versions of Windows 98, Windows Millennium Edition, and Windows NT Workstation 4.0 to also create L2TP/IPSec remote-access VPN connections.

IPSEC/IKE

IPSec/IKE supports a wide variety of encryption algorithms to include DES, 3DES, AES, and RC4, as well as data integrity mechanisms such as MD5 and SHA-1. IPSec/IKE actually refers to a collection of IETF standards that include specifics on key management protocols and encrypted packet protocols. There are two forms of IPSec data integrity: 128-bit strength Message Digest 5 (MD5)-HMAC or 160-bit strength Secure Hash Algorithm (SHA)-HMAC. The bit strength of SHA is greater and is considered more secure, and it is recommended for use because the increased security outweighs the slight increase in overhead costs.

IPSec is a network layer VPN technology, which means that it operates independently of the applications that use it. The IPSec/IKE standard also supports preshared secrets (e.g., passwords and passphrases) and X.509 digital certificates used for authenticating VPN peers. IPSec encapsulates the original IP data packet with its own packet, hiding all application protocol information when using Tunnel Mode IPSec. The IPSec tunnel is negotiated via IKE. After the successful negotiation and creation of an IPSec tunnel, one-to-many connections of various types (e.g., Web, e-mail, file transfer, VoIP) can flow over it, with each connection destined for different servers behind the VPN gateway.

The U.S. government is promoting strong authentication and encryption, helping to promote IPSec as the leading VPN security solution. IPSec has also gained widespread acceptance in wireless environments because of its support for EWGs, Mobile IP solutions, VPN appliances, and VPN server software packages. IPSec still has a high barrier to entry because of its high administrative overhead costs (resulting from configuration and troubleshooting complexities) when used in VPN solutions.

Even though IPSec has significant implementation drawbacks, it has a rich set of security features that are useful to prevent eavesdropping, data modification, forgery, reply, man-in-the-middle, and denial-of-service attacks. By encrypting headers and data, only the receiver can understand the data transmitted, thus preventing the risk of eavesdropping. IPSec prevents unauthorized data modification by guaranteeing that packets transmitted are not intercepted and altered in any way through the use of cryptographically generated keys available only to the sending and receiving computers. A checksum is included in each packet, and any alteration by an attacker would alter the checksum. The keying of data and the encryption of identities prevents an attacker from conducting forgery attacks by inserting spoofed packets into the transmission. IPSec traffic is sequenced , so data cannot be retrieved by an attacker and resent at a later time as a replay attack. Mutual authentication and shared keys used in IPSec prevent an intruder from claiming to be a valid client or server as part of a man-in-themiddle attack. The packet filtering features of IPSec can be configured to block communications that do not originate from a valid IP address range, do not use an authorized protocol, or are not sent from a specific port, eliminating the risk of denial-of-service attacks.

The Authentication Header (AH) [20] and Encapsulating Security Payload (ESP) are the two main protocols used with IPSec. Authentication and integrity are achieved by applying a keyed one-way hash function to the datagram. This creates a message digest for the datagrams passed between two systems by the AH. If any part of the datagram is changed during transit, the receiver will detect the change when it performs an identical oneway hash function on the datagram and compares the value of the message digest the sender has supplied. The one-way hash also involves the use of a shared secret between the two systems, meaning that authenticity can be guaranteed . The AH may also enforce antireplay protection by requiring a receiving host to set the replay bit in the header to verify the packet has been seen. This prevents an attacker from performing multiple resends of a packet that may have been compromised.

Except for fields such as the IP Header and the Time To Live (TTL) fields, which are modified by routers along the transmission path , the AH function is applied to the entire datagram. The hashing function is simply the process of taking a snapshot of what is there and recording it for later use in authentication, and it should not be confused with an encryption process. The AH process starts with the IP header and data payload being hashed for integrity. The hash is then used to build a new AH header, which is appended to the original packet, and the new packet is transmitted to the IPSec peer router, which hashes the IP header and data payload, extracts the transmitted hash from the AH header, and compares the two hashes. The hashes must match exactly. If even one bit is changed in the transmitted packet, the hashed output on the received packet will change and the AH header will not match.

Encapsulating Security Payload (ESP) is a security protocol that provides confidentiality by performing encryption at the IP layer. ESP provides confidentiality through encryption, data origin authentication, integrity, an optional antireplay service, and limited traffic-flow confidentiality by defeating traffic-flow analysis [21]. A variety of symmetric encryption algorithms is supported by ESP. The default algorithm for IPSec is the 56-bit DES algorithm, which is required by the standard to be implemented to guarantee interoperability among IPSec products.

Two modes, transport and tunnel, are supported by IPSec. Only the data portion, also known as the payload of each packet, is encrypted by transport mode, leaving the header unencrypted. Both the header and the payload are encrypted in the secure tunnel mode. Although the data portion of the packet is encrypted in transport mode, the originating machine address behind the VPN gateway is transmitted in the clear and is available to anyone watching traffic on an insecure or public network. The entire packet is encapsulated by the IPSec gateway, and a new header is wrapped around the packet using tunnel mode. All data is encrypted, and only the publicly available gateway address is visible.

The rules for deciding when to use AH or ESP are simple. The AH protocol is used when you want to make sure data from an authenticated source is transferred with integrity and does not need confidentiality. ESP is used when you need to keep data private and confidential. The upper-layer protocols (in transport mode) and the entire original IP datagram (in tunnel mode) are encrypted by ESP, rendering them unreadable from a wireless medium. If the gateway were being treated as a host, the transport mode would be used between endstations or between an endstation and a gateway. When the gateway is acting as a proxy for the hosts behind it, the tunnel mode is commonly used between gateways or at an endstation to a gateway. Obtaining addresses by eavesdropping for information transported via the transport mode could give an attacker the opportunity to perform a spoofing attack to gain unauthorized network access. For this reason, transport mode is rarely used for enterprise VPNs.

Because no dial-up session is established, the use of IPSec/IKE in a wireless remote-access scenario differs from the use of PPTP. Encapsulation or special headers between two endpoints are all that is needed for the IP session connection. The client machine IPSec configuration is often done through client software. Authentication and encryption policy rules are sent as part of the client configuration when the client machine is connecting to an IPSec host or gateway. Once the traffic is sent to a remote destination, the connection is authenticated and encrypted, and traffic is allowed to proceed across the connection. If the client software has been properly configured, this process will be transparent to the user.

The configuration of policies on client and server devices is a part of IPSec administration and addresses what authentication and encryption connection parameters will be used for a particular connection. The configuration policies may include whether to secure a single connection or all connections, connection type and ID such as a secure gateway tunnel and IP address, the mode (e.g., transport or tunnel), ID type such as a digital certificate or preshared key, negotiation mode (e.g., main or aggressive ); Perfect Forward Secrecy (PFS, PFS Key Group [Diffie-Hellman type]) enabled or disabled; and replay detection enabled or disabled.

The Phase I proposal included the encryption algorithm, hash algorithm, SA life, and key group while the Phase II proposal included SA life, compression, and ESP/AH. Only IP unicast traffic is supported by the IPSec standard. If multiple protocols or IP multicast tunneling is needed, another tunneling protocol is required. Support for tunneling packets other than IP unicast types is provided by either PPTP or L2TP. It is important to understand the advantages and disadvantages of certificate use in IPSec authentication versus preshared keys when making decisions as to which method to deploy. Certificates are advantageous in the IPSec environment because all IP types and services are supported. Other advantages include the following:

Failover without dropping sessions (available from multiple vendors)
Dynamic rekeying
Strong algorithms and long key lengths that make encryption very strong
The same technology base that will work in client-to-site , site-to-site, and client-to-client configurations
Support for strong authentication technologies and directory integration
IPSec client manufacturers' starting to bundle personal firewalls and other security functions such as antivirus and IDS/IPS with their IPSec client products
That once a key exchange is complete, many connections can utilize an established tunnel

IPSec can be troublesome because it typically requires a client software installation, and not all required client operating systems may be supported. Interoperability between IPSec clients and IPSec servers/gateways is weak because of configuration issues. Client configuration is required before the tunnel is established. The firewall policy may not allow IKE or IPSec, which will result in connectivity being adversely affected by firewalls between the client and gateway. Connectivity can be adversely affected by NAT or proxy devices between the client and gateway. A VPN gateway client that has a tunnel into an organization without personal firewalls and/or access controls can become a target for hackers. In such situations, the client device can effectively be turned into a router, which provides an unauthorized entry path into the organization.

SSH2

SSH is an open standard defined by the IETF [22]. A cryptographically secure TCP/IP tunnel between two authenticated computers is provided through the implementation of (SSH2) [23] Secure Shell v2 protocol. Authentication is implemented within the application, and encryption occurs at a special SSH transport layer. A client/server model is used by SSH2, and such implementations require special client/server software to communicate because the client must initiate the request for a secure connection. A client's username and password, a public key, or both authentication methods can be used in sequence as an added level of security. SSH2 mitigates eavesdropping, man-in-the-middle, insertion, and replay attacks that are common to wireless networks through the use of secure command shell, secure file transfer, and port forwarding.

10.3.2 Tools and Technologies to Enhance VPN Security

In this section, the tools and technologies used to enhance VPN security in a WLAN are described. Such tools include secure shells, port forwarding, secure file transfer, public key authentication, and Mobile IP. The Secure File Transfer Protocol (SFTP) is an interactive file transfer program, similar to FTP, that performs all operations over an encrypted secure shell transport. The use of secure shells (SSH clients) often includes logging onto a remote machine and executing commands remotely. SFTP also uses many features of secure shell, such as public key authentication and compression. Port forwarding is used to create an encrypted communication session between an SSH server and an SSH client. It maps a specific port on the server to one on the client to securely "pipe" traffic through a firewall and over the Internet. Certificate-based security and its appropriate use in WLANs through a public key authentication architecture is discussed later in this section. Mobile IP is a standard that allows users with mobile devices whose IP addresses are associated with one network to stay connected when moving to a different network and a different IP address. Mobile IP is most often found in wireless WAN environments, where users need to carry their mobile devices across multiple LANs with different IP addresses.

Secure Shells

Command shells are valuable tools that enhance security productivity within wireless environments. They provide a user with the ability to execute programs, edit files, view the contents of directories, access custom database applications, and run other OS-level commands. A command shell can also be used as a remote logon by administrators to start batch jobs; start, view, or stop services and processes; create user accounts; and change permissions on files and directories.

Using Telnet to manage and access WLAN infrastructure devices such as access points, wireless bridges, and wireless workgroup bridges is an unnecessary security risk. It is very common for Telnet to be used to manage wired infrastructure devices across unsecured wireless links. The use of SSH2 eliminates the risk of unsecured wireless links between the management station and the device being managed. The management station must have an SSH2 software package loaded in order to interface with these units. Manufacturers have started to enable SSH2 features in their wireless infrastructure devices.

During the process of getting connected to the Secure Shell server, the client and server must agree on which cipher will be used to encrypt and decrypt data. The server will provide a list of ciphers it supports to the client. The client will select the first cipher found matching in the server-provided list that it can support. The client and the server will both generate random session keys as the connection is being established. Both the client and host use the same session key to encrypt and decrypt the data. A different key is used for the send and receive channels. Session keys are generated before user authentication and after host authentication is completed so usernames and passwords can be sent in an encrypted format. The keys can be replaced at regular intervals during the session and are destroyed when the process is completed.

SSH2 uses Message Authentication Code (MAC) algorithms to greatly improve on the original Secure Shell's (SSH1) simple 32-bit Cyclic Redundancy Check (CRC) data integrity checking method [24]. This occurs as a result of weak or nonexistent access control at either end of the transaction; the integrity of the data sent from one end and arriving unaltered at the other end with the use of SSH2 could be compromised if someone is able to insert unwanted data into the data stream.

Compression is performed by the Secure Shell protocol before encryption and can improve the efficiency of a connection and significantly reduce the overhead costs incurred when encrypting data. Secure Shell provides log messages that can be turned on or off or configured to give varying levels of detail, which can be helpful when troubleshooting to determine the source of a problem.

Port Forwarding

When port forwarding is properly configured, it can be a powerful tool to provide security to otherwise unsecured TCP/IP applications. Secure Shell reroutes traffic from a program, usually a client, through an encrypted tunnel to the other side of the connection, which is usually a server. Requirements to open additional ports on a firewall or router are eliminated because multiple applications can transmit data over a single multiplexed channel. The port forwarding capabilities of Secure Shell can be used to create an encrypted tunnel over which an application can be run. Port 22 is used to route SSH2 encrypted traffic from client to server and vice versa. Two types of port forwarding commonly used with WLANs are local and remote. SSH2 client local port forwarding is configured to listen for traffic destined to specific ports and to redirect this traffic into the SSH2 tunnel on port 22 while the data is still on the local machine. It simply forwards the traffic to its original destination when traffic is delivered to the SSH2 server, creating an effective secure bypass for traversing unsecured network segments. If graphical remote control is used for an application, Secure Shell will not be a sufficient solution. SSH2 client remote port forwarding establishes a secure tunnel using the server and sends requests to the server to perform all remote functions. If the host were directed to retrieve e-mail from a POP3 server, it would request that the SSH2 server send a POP3 request using the client's user credentials to the appropriate server on its behalf . The mail is forwarded to the client through the SSH2 tunnel after the server receives it. Both local and remote port forwarding are easy to configure and scalable. Although configuring the client side of the connection can be a somewhat difficult task, recently released software packages make this configuration process much easier.

Secure File Transfer

SFTP is a subsystem of the Secure Shell protocol layered over the Secure Shell protocol to handle file transfers [25]. Unencrypted FTP usernames and passwords sent over unsecured wireless links are easy targets for application layer analyzers such as WinSniffer or ettercap. SFTP encrypts both the username/password pair and the data being transferred using the same port as the Secure Shell server, eliminating the need to open another port on the firewall or router. Because the same port is used, SFTP is not normally used simultaneously with local or remote port redirection. The use of SFTP also avoids the Network Address Translation (NAT) issues that can often be a problem when using regular FTP. If the WLAN does not allow unsecured connectivity to any valuable network resources, SSH2 is a good alternative to securing wireless links.

Public Key Authentication

Public key authentication uses a pair of computer-generated keys: one public and one private. Each key is typically between 1,024 and 2,048 bits in length. The fact that you can see the contents of a public key is of little value unless you have the corresponding private key.

A key generation module is typically used to generate public-private key pairs. Each key is generated at the same time. Although they are related, neither can be computed from the corresponding public key. A copy of the client's public key must be uploaded to the server in order to access an account on a Secure Shell server. One of the most secure methods available to authenticate Secure Shell is public key authentication. These key sets can also be used to sign data.

The client must prove that it has the private counterpart to the public key when it connects to the server, after which access is granted. The private key never leaves the client machine, so it cannot be stolen or compromised in transit. If the private key is stolen from the client, it usually has an associated passphrase that must be entered when used, and an attacker would still need to guess the passphrase in order to gain access. In this way, public key authentication does not trust any information from a client or allow any access to be granted until the client can prove it has the "secret" private key.

Digital certificates used for authentication have many advantages. Sets of passwords for entities that need to be authenticated when using certificates no longer have to be maintained by users when using digital certificates. The CA adds to the level of security because it only issues certificates to trusted entities. Because the issuer signs each certificate, forging a certificate or making copies of new certificates is very difficult. It is also very difficult for a malicious user to impersonate a certificate holder. A certificate is all that is needed to authenticate a computer for L2TP/IPSec connections; however, passwords must still be maintained for the user authentication portion of the L2TP/IPSec connection. The main disadvantage to using digital certificates for authentication is that a PKI must be deployed to issue certificates to users. Preshared key authentication has some advantages over the use of digital certificates because they do not require the investment in PKI necessary for using certificates with L2TP/IPSec authentication. Preshared keys are also relatively easy to configure on a remote-access client.

There are also some disadvantages to using preshared key authentication that should be weighed before making a decision between using them or a PKI. All users of Microsoft L2TP/IPSec VPN clients connecting to the Windows 2000 VPN server using preshared key authentication must configure with the same preshared key because the Windows 2000 Server can only configure one preshared key for all L2TP/IPSec connections that require a preshared key for authentication. If the preshared key on a VPN server is changed, a client using a preshared key will be unable to connect to that server until the preshared key on the client is also changed. Unlike certificates, the origin, history, and valid lifetime of a preshared key cannot be determined.

IPSec authentication will fail if the preshared key configured for the L2TP/IPSecVPN client is not exactly the same as the preshared key configured on the VPN server. The preshared key for a L2TP/IPSec VPN client can be a string of any combination of keyboard characters from 8 to 255 characters long. The Microsoft IPSec VPN Configuration Utility allows the user to cut and paste a character string for the preshared key into the data entry field. Rather than having software "remember" the preshared key for them, users should be required to manually type the preshared key. Unfortunately, a key that is long and complex enough to provide adequate security will be difficult for users to type and remember.

Another problem with preshared keys is a weakness of the method by which they are distributed. The strength of sequence of characters in a preshared key depends on its secrecy not being compromised. Quite often, preshared keys are distributed to users through unencrypted e-mail, allowing anyone receiving, intercepting, or reading the e-mail to gain unauthorized access to the preshared key. A strong preshared key requires a random sequence of upper-and lowercase letters , numbers, and punctuation. Unfortunately, in many cases, these are short, easy-to-guess preshared keys that are susceptible to an online dictionary attack. An attacker can successfully authenticate the IPSec portion of the connection if he or she is able to compromise the preshared key and can still present a valid set of credentials for the PPP portion of the connection. In contrast, it is very difficult to compromise a certificate. The use of preshared keys to authenticate L2TP/IPSec connections is considered a relatively weak authentication method. PKI and certificates should be used if you require a strong authentication method.

Mobile IP

If a user receives an IP address from a DHCP server on one network segment and then roams across a router by associating with an access point on another network segment, the Layer 3 connection is broken and the dynamic IP address assignment is lost. If a mobile client roams to a network outside the control of his or her network administrator, such as at another company, it is likely that that DHCP will be unavailable for that user.

Mobile IP is specified in RFC 2002 [26] and is an increasingly common WLAN solution used to address the problem of mobile clients roaming across subnet boundaries. Because security is not specified in RFC 2002, Mobile IP is often combined with IPSec to form Mobile IP VPN solutions, providing maximum flexibility and security while roaming. The Home Agent (HA) and Foreign Agent (FA) are the two primary components of Mobile IP. The HA has a static IP address and serves as a VPN concentrator for mobile clients. It is typically a server or router sitting on what is known as the "home" network. The client registers with the HA when it attaches to the home network. Mobile IP software must be installed on the client machines to facilitate their participation in the Mobile IP VPN process. When the client roams to any network other than the home network (foreign), the client registers (notifies) the HA of its new address on the foreign network (called a "care-of" address). This registration lets the HA know not to participate in communications between the client and other hosts. A VPN tunnel for data security is formed by the client between itself and the HA. The HA then acts on behalf of the roaming client, routing any traffic destined to the client's home static IP address to the roaming client at its new care-of address.

The client may use DHCP to obtain an IP address while on the foreign network and notify the HA of this new care-of address or broadcast for an FA. Mobile IP clients may roam for FAs that are placed on networks to assist clients in making IP and VPN connections back to the HA when no DHCP server is available. When no DHCP server is present, the FA can act as a liaison between the client and the HA; however, it is generally preferred for the client to have the ability to use DHCP to obtain an address so the client can route traffic to the HA by itself. In some cases, a proprietary Layer 2 protocol is used between the client software and the FA to transport information received by the FA on behalf of the client. The FA is preconfigured with HA connectivity information and acts as the care-of address for the client.

An IP datagram is encapsulated within another IP datagram by Mobile IP to allow the mobile system to have two different addresses. The first address is the mobile node's home address, and the second address is the mobile node's care-of address, which changes at each new point of attachment. The roaming problem is solved by the Mobile IP specification for a tunnel created from the HA to the current location for the mobile node.

A sequence of events must occur in Mobile IP to allow a mobile node to roam without losing connectivity. An IP address is requested from the local DHCP server after the mobile node roams onto a foreign network. If no IP address is received, the client locates the FA through broadcasting and notifies the FA of its presence on the network. The FA will register the mobile node's new care-of address with the mobile node's HA. The HA accepts packets destined to the mobile node on behalf of the mobile node. The packets accepted by the HA are wrapped with a new IP header using the care-of address. The new header encapsulates the original packet, so the mobile node's home address has no effect on packet routing until it arrives at the care-of address. The FA then unwraps the packet and forwards it to the destination mobile node. A new care-of address is registered with the roaming client's HA whenever the mobile node moves again.

Additional security layering is required to effectively secure Mobile IP because the specification only addresses redirection attacks and leaves all other security issues unanswered. The specification requires a Mobile IP home authentication extension to be present in all registration requests (and corresponding registration replies) in order to eliminate problems of remote redirects. A redirection attack occurs when an attacker tells the HA the mobile node has a new care-of address, which is actually the attacker's machine, in order to get the HA to send all packets destined to the mobile node to the attacker's machine.

Enterprise firewalls are usually configured to block packets coming from the Internet and destined for machines residing behind the firewall. This presents difficulties for mobile nodes attempting to communicate with other computers on their home network and is problematic when Mobile IP and firewalls have to work together. This can also happen in reverse when a mobile node is on a foreign network sending outbound traffic to the HA through a firewall. The firewall does not let the return traffic through, and a disruption or termination of the session can result. Some manufacturers wrap the entire session in HTTP to fix this situation because the sessions are almost always allowed to pass through a firewall using HTTP protocols. In general terms, subnet roaming across access points located behind different Layer 3 devices, such as routers, Layer 3 switches, VPN concentrators , firewalls, or EWGs with WLANs, present various connectivity problems. Many of the problems are solved with Mobile IP solutions.