Well, IPSEC - real IPSEC as it exists today - is still morphing, but not so much that one shouldn't require it as a basis for a VPN. So we might have:
► IPSEC compliant (including ISAKMP/Oakley)
► Interoperability with other IPSEC compliant vendors
► Strong encryption, long key length
► If the VPN solution is not part of the firewall, which is fine, will it work with the firewall?
► Does the VPN product work both with and without trust? (Remember, it requires working closely with the firewall.)
► For an "add on" VPN, does it work in conjunction with the firewall, or does it simply circumvent the firewall? (I'm not suggesting one way is good and the other bad, but it may be something the security manager cares about, and the answer should be known.)
► Does the VPN support automatic creation of user-level VPNs (for mobile users)? In a very large organization, the system manager probably would rather not have to manually create VPN accounts for every user.
► Has the VPN been certified by a recognized organization? (The ICSA has a certification and testing process for VPNs. Others probably exist as well.)
If we are imaging an IPSEC world, where eventually the majority of gateways we might connect to supports IPSEC, things become both easy and interesting. If we have a mechanism that can invite encryption use, respond to such invitations, but also talk without encryption if required, we need to think about things such as:
► What risk are we under from eavesdroppers?
► Do we always want to talk encrypted if we can?
► What are the list of sites or networks with whom we must talk encrypted?
► If we cannot talk encrypted to those "must encrypt" sites, what do you want the fall back to be?
► What if we're invited to talk encrypted, but using weak crypto (answer this question both for the general case as well as for the "must encrypt" set of networks)?
► How often do we change session keys?
► Do we need the ability to recover data or keys for encrypted sessions? (I'm arguing that this is almost a 100% "yes" if we were talking about file encryption, but almost 100% "no" for network communications.)
► Are we going to have the encryption be certificate-based? Who do we trust to be a Certification Authority?
► Will we allow encryption through the firewall or only up to the firewall?
► How do we protect the keys? Who has access to the keys?
With firewalls, we went from a very small number of security-wise companies using real firewalls to firewalls becoming a "must have" on a checklist. But somehow, having a firewall became synonymous with "all my Internet security problems are solved!" VPNs and IPSEC have started off that way too. There has been a lot of "When we have IPSEC on the desk top we won't need firewalls." This is nonsense. VPNs cannot enforce security policies, they cannot detect misuse or mistakes, and they cannot regulate access. VPNs can do what they were meant to do: keep communications private.
Privacy from end to end. The cryptography used, generally speaking, is very good. Whatever you do, that is encrypted, is very well hidden from sniffers on the net. Whatever is not encrypted, you may as well shout from the rooftops or post on your web page.
VPNs are typically handled as just another job by the network or system administrator staff. Whoever is managing the firewall today can easily add VPN management to the plate because once a VPN is set up there is little else to do on most implementations.
Well, the perimeter security issues mentioned above, plus a firewall should give the option of VPN with or without trust. For example, I would prefer all sessions between my firewall and my clients and business partners to be encrypted - to be VPNs. But, I want all of them to run up against my firewall if they try to do anything besides what I permit. On the other hand, if I dial in from the speaker's lounge at a conference, I would like a private connection (that is to say, encrypted) that also looks and feels like a virtual "inside" connection, just as if I was sitting in the office.
While VPNs were available before firewalls via encrypting modems and routers, they came into common use running on or with firewalls. Today, most people would expect a firewall vendor to offer a VPN option. (Even though most people today don't use VPNs.) Also, they want it managed via the same firewall management interface. But then, users today seem to want nearly everything on the firewall: mail server, name server, proxy servers for HTTP, FTP server, directory server, and so on. That's terrible and a subject in itself.
Only the things you want everyone to be able to eavesdrop on. In general, the answer is "no," but if a VPN is in use from a system behind a firewall to a system outside the firewall, the firewall cannot enforce an organization's security policy beyond connection rules.
VPNs should be used for all information exchange. I don't want to have to "go encrypted" when something secret is about to be sent. I want everything to be encrypted. It should be as commonplace as people sending postal mail in sealed envelopes. It will also ensure that the VPN mechanism is working.
Businesses who understand the use of crypto for privacy in electronic documents also understand the need for the emergency recovery of that data. Whether this is done by saving an individual's private key information, encrypting it with a trusted third party's key, or saving all keys used to encrypt all documents, it is well understood that some mechanism is needed for the recovery of encrypted files owned by an individual, by the individual, or a company, by the company for business or law enforcement reasons. Key recovery of session keys used to encrypt a network connection is a requirement of law enforcement. VPNs must use the strongest crypto available and feasible given the hardware on which it is being run. Weak cryptography (for example, 40 bit key length) should be completely avoided.