3. Design Considerations

There are two distinct VPN classes. VPN for infrastructure and VPN for access. It is quite common for people (and even big vendors) to misuse infrastructure technologies for access and vice versa.

3.1 VPN for infrastructure

VPN for infrastructure is a replacement for leased lines and on-demand links between remote offices. In order to be fit for this purpose a VPN technology must offer:

• Reliable up-to-date information on link status (up/down)
• Possibility to fall back to a secondary link (if necessary via an alternative VPN gateway) and reroute traffic after a link failure. Secondary link may be a different technology altogether including dial-on-demand
• Authentication on per machine basis and unattended mode of operation where a user does not have to re-enter credentials for re-establishing a connection
• Performance should be comparable to a fixed line with similar bandwidth for the full range of packet sizes, packet rates and data rates under congested and non-congested conditions

It is also nice to have (especially for a big installation):

• Possibility to propagate changes in topology and routing by making a single change to a single device
• Possibility to initiate a tunnel from an anonymous IP address (for infrastructure it is "nice to have", but usually not mandatory).
• Possibility to re-initiate the tunnel from either side of the link after a failure
• Some installations may also require data privacy. While "good to have", this is not mandatory as many non-encrypted VPN technologies will offer adequate data privacy due to technical problems associated with eavesdropping. A good example of VPNs deemed to be secure enough not to require encryption are provider provisioned MPLS VPN services (layer 2 and Layer 3).

Another important consideration is that in order to achieve most of the requirements for stability, fallback and status reporting VPNs have to carry a considerable amount of predictable and./or repetitive traffic (routing protocols, keepalives, etc). This traffic can be used for "known plaintext" attacks and will effectively downrate any encryption scheme used for data privacy. There is very little information on the extent of downrating caused by routing protocol and other predictable traffic, because there has been virtually no work done by cryptographers on this aspect of VPN data privacy.

It is quite obvious that in nearly all cases in order to satisfy these requirements a technology must present the vpn link as an interface to the underlying OS. If it is presented as an interface all other requirements may be resolved by running routing protocols and/or using keepalives in the VPN protocol. This presentation is typical for most implementations (including FreeBSD ones) of IP-in-IP tunnels, GRE, PPP over various transports, PPTP, L2TP and most SSL VPN varieties.

It is important to note that tunnel mode IPSEC is not on the above list. In fact, it is not suitable for infrastructure. It has no fallback mechanisms in the standard. It does not have proper operational state checking either. It does not provide the OS an abstraction which will allow to use a dynamic routing protocol. There are various vendor specific extensions and hacks which work around some of these limitations. None of them are present in FreeBSD. Most of them will also limit an implementation to a single vendor. Some will also downrate the security of the solution.

3.2 VPN for RAS

VPN for access is a replacement for dialup into a central office. In order to be fit for this purpose a VPN technology must offer:

• Access from an arbitrary IP address with possibility to traverse at least some NAT and firewall technologies
• Per user authentication and interfacing into classic RAS authentication solutions or central office authentication solutions
• Guarantee a reasonable level of data privacy. RAS VPNs are usually assumed to traverse insecure networks.

It is also nice to have (especially for a big installation):

• Possibility to authenticate a machine as well as a user
• Possibility to provide clients with basic settings like name servers, wins (if used), time servers, routing, etc.

There is also a number of features which are not VPN features as such. These are mostly related to firewalling and integrity checking of the connecting client. These are not VPN features and the fact that they are bundled in commercial products does not mean that they cannot be performed by other third party software that has nothing to do with any VPN functionality.