Manual tunnel limitations
The present implementation of manual IPSec tunnels has some major limitations:
- Each host is assumed to have a fixed IP address.
- There is no provision for negotiating configuration
parameters and encryption keys between hosts.
- There is no provision for automating the renewal of
encryption keys when a tunnel's lifetime expires.
These limitations significantly restrict the usefulness of the VPN feature.
Specifically, it becomes difficult to effectively use IPSec tunnels in a
DHCP environment, and virtually impossible to do so in a dial-up environment.
Without a facility to automatically negotiate and exchange tunnel parameters
and keys, this information would have to be manually exchanged (by some
means or other) every time a tunnel is created or renewed. The situation
is exacerbated by the lack of graphical configuration tools - all configuration
files must be edited by hand.
IBM recommends that tunnels be renewed (that is, re-established with new
encryption and authentication keys) at least once for every eight hours
of use. In light of the above limitations, adhering to this recommendation
would be difficult if not impossible.
Dynamic tunnel limitations
Dynamic tunnels were designed to overcome the limitations of manual tunnels.
Unfortunately, they introduce a major limitation of their own: since dynamic
tunnels are a proprietary IBM technology, they may only be used in conjunction
with an IBM firewall server (i.e. AIX SecureWay Firewall).
General limitations
At present, the range of cryptographic algorithms available is severely
limited: specifically, only Keyed MD5 is available for authentication, and
only DES and CDMF are available for encryption. These algorithms are considered
relatively weak by today's security standards, although they are generally
sufficient for protecting against casual intrusion.
The firewall design seems intended to allow other algorithms to be installed,
like plugins, if drivers are made available. Unfortunately, IBM has not
seen fit to provide any additional drivers, and the driver interface does
not appear to be publically documented for use by third-party developers.
Other solutions
The industry-standard solution to the limitations of manual tunnels is the
Internet Key Exchange (IKE) protocol, also known as ISAKMP/Oakley.
When implemented, IKE runs on each host and negotiates the security associations
between them; it also allows hosts to be configured by constant identifiers
(such as host or user name) rather than by IP address. Unfortunately, MPTS
does not come with an IKE implementation.
If the built-in VPN feature (with the limitations described here) proves
insufficient, there are other, more complete VPN products available from
third parties (such as InJoy by F/X
Communications).
[Back]
[Next]