The following list of Frequently Asked Questions is answered from a variety
of sources, primarily discussions held on the Virtual Private Networks mailing
list. This is a work in progress -- I'll be adding more information as I compile
it. If you've got suggestions or answers for any of these issues, or questions
you think should be considered, please submit them to the mailing
list - all information will be attributed to the original author.

The VPN mailing list is a forum for the discussion of supporting
private network connections over public telecommunications infrastructure, such
as the Internet. The list is moderated by Tina Bird. Appropriate postings will
relate to all varieties of VPN technology: subscription services, in which an
organization outsources the maintenance of the VPN system; in-house systems,
including both hardware and software implementations; security policy issues
relating to the use of VPNs as a means of remote access; and legal/regulatory
concerns, domestic and international.

Although some vendors and service providers might disagree,
in common usage a virtual private network is a group of two or more computer
systems, typically connected to a private network (a network built and maintained
by an organization solely for its own use) with limited public-network access,
that communicates "securely" over a public network. VPNs may exist between an
individual machine and a private network (client-to-server) or a remote LAN
and a private network (server-to-server). Security features differ from product
to product, but most security experts agree that VPNs include encryption, strong
authentication of remote users or hosts, and mechanisms for hiding or masking
information about the private network topology from potential attackers on the
public network.

Q4: What types of VPNs are there, and what
are their relative advantages and disadvantages?

Despite the large (and rapidly expanding) number of VPN products,
all fall into three broad categories: hardware-based systems, firewall-based
VPNs and standalone VPN application packages.

Most hardware-based VPN systems are encrypting routers. They
are secure and easy to use, since they provide the nearest thing to "plug and
play" encryption equipment available. They provide the highest network throughput
of all VPN systems, since they don't waste processor overhead in running an
operating system or other applications. However, they may not be as flexible
as software based systems. The best hardware VPN packages offer software-only
clients for remote installation, and incorporate some of the access control
features more traditionally managed by firewalls or other perimeter security
devices.

Firewall-based VPNs take advantage of the firewall's security
mechanisms, including restricting access to the internal network. They also
perform address translation; satisfy requirements for strong authentication;
and serve up real-time alarms and extensive logging. Most commercial firewalls
also "harden" the host operating system kernel by stripping
out dangerous or unnecessary services, providing additional security for the
VPN server. OS protection is a major plus, since very few VPN application vendors
supply guidance on OS security. Performance may be a concern, especially if
the firewall is already loaded -- however, some firewall vendors offer hardware-based
encryption processors to minimize the impact of VPN management on the system.

Software-based VPNs are ideal in situations where both endpoints
of the VPN are not controlled by the same organization (typical for client support
requirements or business partnerships), or when different firewalls and routers
are implemented within the same organization. At the moment, standalone VPNs
offer the most flexibility in how network traffic is managed. Many software-based
products allow traffic to be tunneled based on address or protocol, unlike hardware-based
products, which generally tunnel all traffic they handle, regardless of protocol.
Tunneling specific traffic types is advantageous in situations where remote
sites may see a mix of traffic --some that needs transport over a VPN (such
as entries to a database at headquarters) and some that doesn't (such as Web
surfing). In situations where performance requirements are modest (such as users
connecting over dial-up links), software-based VPNs may be the best choice.

But software-based systems are generally harder to manage than
encrypting routers. They require familiarity with the host operating system,
the application itself, and appropriate security mechanisms. And some software
VPN packages require changes to routing tables and network addressing schemes.

Be aware that as the VPN market evolves, the distinctions between
VPN architectures are becoming less clearly defined. Some hardware vendors have
added software clients to their product offerings, and extended their server
capabilities to include some of the security features more "traditionally" offered
by software or firewall-based VPNs. A few stand-alone products have added support
for hardware-based encryptors to improve their performance. And for all types
of VPNs, further implementation of the proposed IPSec protocol is making it
easier (tho' not trivial) to mix and match VPN products. So bear in mind that
these VPN categories are becoming less meaningful as time goes on.

The PPTP specification was originally developed
by a consortium that included Ascend Communications, 3Com/Primary Access, ECI
Telematics, U.S. Robotics and Microsoft. The protocol was originally designed
as an encapsulation mechanism, to allow the transport of non-TCP/IP protocols
(such as IPX) over the Internet using Generic Routing Encapsulation (GRE). The
specification itself is fairly generic, and allows for a variety of authentication
mechanisms and encryption algorithms. Note that these security features were
added later, not built in from the beginning.

Several vendors have created PPTP systems. However, the vast
majority of PPTP users implement the Microsoft version. The following discussion
of PPTP security issues are specific to the Microsoft implementation, which
features:

PPTP can be used to control access to the private network via
NT domain security controls (user- and group-level access to domain resources),
and by segregating resources on the corporate network. With the release of the
Internet Authentication Services update for NT 4.0, RADIUS may be used to perform
PPTP authentication -- but it is unknown whether or not the authorization and
access control features of RADIUS are also supported.

Use of PPTP requires that IP forwarding be enabled on the NT
server.

Setting up a PPTP system requires configuring the Remote Access
Server capability on the NT server, adding routing functionality to the RAS
system, applying several newly-released security patches, and configuring the
PPTP-specific registry keys. And hardening the server itself.

The initial release of PPTP used the MSCHAP mechanism for end-user
authentication. After numerous criticisms that MSCHAP was easily compromised,
especially in situations when Windows 95 was the client operating system, Microsoft
released a patch to the original authentication protocol. To quote the Microsoft
WebSite: "This new protocol provides mutual authentication, stronger initial
data encryption keys, and different encryption keys for the transmit and receive
paths. To minimize the risk of password compromise during MSCHAP exchanges,
MSCHAP V2 drops support for the MSCHAP password change V1, and will not transmit
the LMHash encoding of the password. ...For VPN connection requests, a Windows
NT server will offer MSCHAP V2 before offering the legacy MSCHAP. Updated Windows
clients (all platforms) will accept MSCHAP V2 when it is offered." (August 18,
1998) Microsoft also added a new registry key, SecureVPN, that forces incoming
VPN connection requests to use the new authentication
mechanism. These changes should prevent a PPTP client from indicating using
the older, LMHash mechanism. However, the effectiveness of these patches has
not yet been verified by any independent reviewer.

[Note that the dependence of PPTP authentication on MSCHAP makes
it vulnerable to attacks using l0phtcrack
-- so it's the only VPN tool with its own l0pht hyperlink!]

Also note that although Microsoft describes PPTP as using either
40-bit or 128-bit encryption, their use of the user's password to create a session
key, rather than a randomly generated key, greatly reduces the strength of the
encryption process. None of the recent security releases addresses this issue.

Microsoft claims to have improved the mechanism that generates
session keys (which is based on a hash of the user's password). If this is true,
it helps protect against hijacking attacks, as well as making brute force crypto
attacks harder. NB: even this enhancement does not improve the cryptographic
weakness, which is based on the flawed decision to use passwords to generate
keys. Remember, no matter how strong an encryption algorithm is, it can be compromised
via a brute-force attack. The only protection against brute force is a long
key length, with purely random keys - not what Microsoft has implemented. And
again, this enhancement has not been verified (as of November 1998) by any third-party
evaluator.

And of course, there are potential issues with getting GRE
through a lot of commercial firewalls, and lots of problems with technical support
on a system that could rapidly become mission-critical.

So no, the VPN list moderator doesn't think that PPTP is a reasonable
VPN solution, at least from the security point of view. Your mileage may vary.

IPSec is an evolving standard for secure private communications
over the Internet. Normal IPv4 packets consist of headers and payload, both
of which contain information of value to an attacker. The header contains source
and destination IP addresses, which are required for routing but may be spoofed
or altered in what are known as "man-in-the-middle" attacks; the payload consists
of information which may be confidential to a particular organization. IPSec
provides mechanisms to protect both header and payload data. The IPSec Authentication
Header (AH) digitally signs the outbound packet, both data payload and headers,
with a hash value appended to the packet, verifying the identity of the source
and destination machines and the integrity of the payload. The IPSec Encapsulating
Security Payload (ESP) guarantees the integrity and confidentiality of the data
in the original message by combining a secure hash and encryption of either
the original payload by itself, or the headers and payload of the original packet.

NAT is incompatible with Authentication Header protocol, whether
used in transport or tunnel mode. An IPsec VPN using AH protocol digitally signs
the outbound packet, both data payload and headers, with a hash value appended
to the packet. When using AH protocol, packet contents (the data payload) are
not encrypted.

Why this bothers NAT is the last part: a NAT device in between
the IPsec endpoints will rewrite either the source or destination address with
one of its own choosing. The VPN device at the receiving end will verify the
integrity of the incoming packet by computing its own hash value, and will complain
that the hash value appended to the received packet doesn't match. The VPN device
at the receiving end doesn't know about the NAT in the middle, so it assumes
that the data has been altered for nefarious purposes.

IPsec using Encapsulating Security Payload in tunnel
mode encapsulates the entire original packet (including headers) in a new IP
packet. The new IP packet's source address is the outbound address of the sending
VPN gateway, and its destination address is the inbound address of the VPN device
at the receiving end. When using ESP protocol with authentication, the packet
contents (in this case, the entire original packet) are encrypted. The encrypted
contents, but not the new headers, are signed with a hash value appended to
the packet.

This mode (tunnel mode ESP with authentication) is compatible
with NAT, because integrity checks are performed over the combination of the
"original header plus original payload," which is unchanged by a NAT device.
Transport mode ESP with authentication is also compatible with NAT, but is not
often used by itself. Since the hash is computed only over the original payload,
original headers may be rewriten.

In addition, NAT may interfere with IPSec (both ESP and AH)
if it prevents the two VPN gateways from successfully negotiating SAs using
ISAKMP/IKE with certificates. X.509 certificates are signed by a trusted third
party (called a Certificate Authority) in order to bind a user's or device's
public key to some other identifying public characteristic. Once common identifying
characteristic used for VPN gateway devices is external IP address.

If the two VPN gateways exchange signed certificates that bind
each gateway's identity to its IP address, NAT address rewriting will cause
IKE negotiation to fail.

Altiga (Cisco) has a revised version of their IPsec client that
allows connections through NAT. They term it "IPsec over UDP". This may be somewhat
less secure than true IPsec. Native IPsec requires that there be no change to
the headers and NAT obviously breaks that rule. But Altiga's IPsec over UDP
address a very practical concern - that many users of broadband Internet access
are starting to be required by their ISPs to use NAT.

PPTP seems to depend on whose NAT you are passing through. Seems
to work fine going through say a SonicWall firewall wall. But PPTP going out
through a Cisco NAT'ed router or firewall does not appear to work (if you are
NAT'ing to a single routable IP address - hence overloading/PAT'ing.)

Q9: How do I decide whether a VPN is a good
remote access solution for my organization?

To determine whether or not a VPN is a good answer to your company's
needs for remote connectivity, consider your specific technical requirements,
along with the pros and cons of VPN use.

Some advantages to using VPNs include:

the ability to securely connect high speed remote users over
broadband technology, including Cable Modems and DSL lines, which before VPNs
had not been possible. VPNs will work with any last mile technology as long
as IP is run over the connection.

no administrative headache for managing direct access telephone
lines, T1 or PRI lines used for data, or for the RAS equipment (modems or other
network access servers) terminating the phone calls

potential cost savings, especially if many of your remote users
are located outside your local calling area.

Some disadvantages include:

potentially lower bandwidth available to remote users over
a VPN connection as compared to a direct dial-in line.

inconsistent remote access performance due to changes in Internet
connectivity. (To counteract this, you can have your users choose Service Providers
that have higher levels of service, perhaps the same ISP from which you purchase
your corporate Internet connection to keep traffic inside the same backbone.)

No entrance in to the network if the Internet connection is
broken (Some administrators choose to leave a limited amount of dial-in access
for emergency access)

By definition, a VPN generally requires configuration of some
sort of access device, either software or hardware-based, to setup a secure
channel using private encryption and security parameters. A casual user can't
just "use" my VPN, since some knowledge is required to allow the remote user
or site access to my network (or even to begin a VPN handshake!).

Allowing VPN access only in conjunction with strong authentication
also prevents an intruder from successfully authenticating to your network,
even if they somehow configured/captured a VPN session.

Q11: How do I control which sorts of network
traffic are transmitted over my VPN?

Depending on the VPN solution being implemented, there are a
few ways to control the type of traffic sent over a VPN session. Many VPN devices
allow you to define a user or group based filter which can control IP address
and protocol/port services allowed through a tunnel. In addition, IPSec-based
VPNs allow you to define a list of networks to which traffic can be passed (Security
Associations). The first mechanism allows the administrator to limit access
to specific networks/machines and applications on her network. The second usually
provides fully connectivity to the private network.

Q12: Should my VPN be terminated on my firewall,
or directly on my private network?

There is no correct answer to this question, since it depends
on your security requirements and network architecture. Two of the most common
configurations for a VPN device providing Corporate Remote Access are to run
a VPN device in parallel to an existing firewall, or behind an
existing firewall. Terminating VPN sessions in front of a firewall or on a firewall
itself is not as popular.

There are pros and cons for all implementations.

Placing a VPN device in parallel to an existing firewall requires
no changes to an existing firewall infrastructure, but also means that you will
have two entry points into your private network. On most VPN devices, verify
that they block all non-VPN traffic to minimize the additional security risk.
Depending on how your network is set up, this will probably also require the
VPN device to do some sort of Address Translation, or to have the ability to
redirect this traffic to an existing firewall.

By placing a VPN device behind an existing firewall, you will
be required to make changes to your firewall. You will also need a firewall
smart enough to be able to configure a filter to pass the VPN traffic. Depending
on how your network is set up, this may also allow you to make use of only one
of the two or more Ethernet ports on your VPN device. This configuration is
sometimes known as One-Arm-Routing.

By placing a VPN device in front of your firewall, you will
be terminating secure traffic in a public zone. You will need to assign addresses
to users from a certain block of IP addresses and open a large hole in the firewall
for access from these IP addresses. A potential advantage to doing this would
be that you could then use your existing firewall to control the destination
of traffic, but most VPN boxes will also allow you to do this. This type of
application may make more sense for trading partner connectivity vs. remote
access users.

By doing VPN on an existing firewall, you add some intense processing
to a device whose original purpose was simply speaking, to control network access.
Some people like the simplicity of adding a service to an existing device on
the network perimeter.

Q13: How does the use of encryption affect
the performance of a network connection?

The use of encryption adds some additional overhead to a session.
Most VPN devices, whether hardware or software based, will be able to process
encryption for connections up to 10baseT speeds. On a lower speed connection
like a modem, VPN processing is much faster than delays introduced by the limited
bandwidth availability.

Often performance is potentially affected more by packet loss
and latency on bad Internet connections than by the encryption overhead.

In general, user authentication is based on the following principle:
an entity has authenticating knowledge (what you know), possession of an authenticating
device (what you have), or exhibits an required characteristic (what you are).
Strong authentication requires that at least two of the three principles be
demonstrated.

Encryption systems depend on two mechanisms to guarantee data
confidentiality. The encryption algorithm provides the mathematical "rules"
that convert the plain text message to a random ciphertext message. The algorithm
provides steps for convolving the plain text message with an "encryption key,"
a block of (typically) alphanumeric data that introduces the random element
into the ciphertext message. The longer the secret key is, the more time it
takes for an attacker to test all possible values of the key - and determine
the plain text content of the message. In other words, data that will be valuable
to an attacker for a long time should be encrypted with longer keys than ephemeral
data. This sort of attack is called a brute force attack.