VPN Consortium
Version 1.0
March 27, 2002
New VPN administrators are faced with a very difficult task. They have to learn two new technologies (IKE and IPsec), lots of new vocabulary, and a new administrative interface, usually all at the same time. If they are expected to do that and, at the same time, get two VPN systems from different vendors to interoperate, they may give up in frustration and blame their problems on the lack of interoperability in VPNs.
In order to help these administrators, VPN manufacturers should make it easier for someone reading the documentation for an IPsec system to figure out how to set up the system for typical scenarios. If the documentation for two different systems have the same example scenario with walkthroughs on how to set up the scenario, the administrator can more easily figure out how to get the two systems to interoperate..
The purpose of these documentation profiles is to help system administrators determine where the two vendors use different vocabulary. Even more important, people seeing the examples can see the different ways that the two systems do the same thing. This, in turn, will help the VPN industry.
Please send any comments to Paul Hoffman at VPNC.
Every VPN vendor should include at least one of the scenarios in their documentation. The example used in the vendor's documentation should use both the artwork (either ASCII or printer-ready) and the verbal description of the scenarios.
No vendor is required to include the example scenarios here in any of their documentation. This document has recommendations but not specifications. However, any vendor that does use the example scenarios described here must include the scenario names and numbers so that users will recognize them as common to multiple vendors. It is expected that these scenarios might appear in printed or on-screen documentation, or at least as downloadable notes from the vendor's support site.
Although the scenarios are developed by the VPN Consortium, anyone may use the scenarios in their documentation as long as attribution of the specification to VPNC is given. Attribution must include the words (in the language of the document) "These scenarios were developed by the VPN Consortium."
When including a given scenario in the documentation, first include the scenario exactly as it is, using the scenario's vocabulary. When describing how to set up the scenario, use the vocabulary that is already used in the product's documentation and user interface. This helps the user see how other systems use different vocabulary for the same idea or feature.
If a vendor uses multiple scenarios that are similar, it is acceptable to list the changes between the scenarios. That is, it is not required to duplicate the entire example description or the entire walkthrough, just the parts that are different. This is particularly useful if one is documenting both Scenario 1 (identity using preshared secrets) and Scenario 2 (identity using PKIX certificates) because the other features of the two scenarios are the same.
The scenarios use particular settings for the options in Phase 1 and Phase 2. Most IPsec systems allow many settings other than the ones shown. You may want to list all of the settings that can by chosen in your product, but you should not do so in the scenarios themselves. Instead, possibly add an additional section listing all the settings for the options, using the vocabulary you used in the scenarios.
In general, the order of the documentation for the implementation of a scenario should be as follows.
For gateways, tell the reader how to turn on both the internal and external interfaces. For clients, tell the user how to turn on the network interface that will be used. If possible, give information on how to tell whether or not each interface is up and accessible; this should be done whether or not the reader has to set up the interface. In the example, be explicit about which interface name in the system matches each name in the scenario.
Naming the interfaces is very important. Some systems use names like "LAN", "corporate", "internal", and "inside" for the interface over which unencrypted data goes. Some systems use names like "WAN", "Internet", "external", and "outside" for the interface over which unencrypted data goes.
If the system also contains a firewall, tell the reader how to set up the firewall to allow the traffic specified in the scenario. This is particularly important for systems where the firewall is inherently disallowing all traffic unless told to allow particular traffic. Note that the scenarios specify which IP protocols, ports, and addresses are to be allowed.
Many systems have separate user interface pieces for setting the Phase 1 and Phase 2 parameters. If so, the documentation of the scenario should clearly separate the two sets of parameters. In systems where the parameters of Phase 1 and Phase 2 are mixed in the user interface, it is acceptable to mix them in the description; however, it is not acceptable to change the layout of the scenario description.
If the system being described has any testing or diagnostics available to the reader, the steps to use them should be described here. In particular, steps to ping between the network interfaces of the two systems are very useful to readers. Items that might be included in this section include:
The following is a typical gateway-to-gateway VPN that uses a preshared secret for authentication.
10.5.6.0/24 172.23.9.0/24
| |
--| |--
| +-----------+ /-^-^-^-^--\ +-----------+ |
|-----| Gateway A |=====| Internet |=====| Gateway B |-----|
| AL+-----------+AW \--v-v-v-v-/ BW+-----------+BL |
--| 10.5.6.1 14.15.16.17 22.23.24.25 172.23.9.1 |--
| |
Gateway A connects the internal LAN 10.5.6.0/24 to the Internet. Gateway A's LAN interface has the address 10.5.6.1, and its WAN (Internet) interface has the address 14.15.16.17.
Gateway B connects the internal LAN 172.23.9.0/24 to the Internet. Gateway B's WAN (Internet) interface has the address 22.23.24.25. Gateway B's LAN interface address, 172.23.9.1, can be used for testing IPsec but is not needed for configuring Gateway A.
The IKE Phase 1 parameters used in Scenario 1 are:
The IKE Phase 2 parameters used in Scenario 1 are:
To set up Gateway A for this scenario, use the following steps:
. . . Your instructions go here . . .
One of the most common mistakes in setting up this scenario is the use of the wrong kind of addresses for the Phase 2 selectors; be sure to describe how to use IPv4 subnets.
Note that the selectors are for all IP protocols on all ports. Be sure to clearly describe how to specify these settings both in the firewall (if any) and in Phase 2.
The following is a typical gateway-to-gateway VPN that uses PKIX certificates for authentication.
10.5.6.0/24 172.23.9.0/24
| |
--| |--
| +-----------+ /-^-^-^-^--\ +-----------+ |
|-----| Gateway A |=====| Internet |=====| Gateway B |-----|
| AL+-----------+AW \--v-v-v-v-/ BW+-----------+BL |
--| 10.5.6.1 14.15.16.17 22.23.24.25 172.23.9.1 |--
| |
Gateway A connects the internal LAN 10.5.6.0/24 to the Internet. Gateway A's LAN interface has the address 10.5.6.1, and its WAN (Internet) interface has the address 14.15.16.17.
Gateway B connects the internal LAN 172.23.9.0/24 to the Internet. Gateway B's WAN (Internet) interface has the address 22.23.24.25. Gateway B's LAN interface address, 172.23.9.1, can be used for testing IPsec but is not needed for configuring Gateway A.
The IKE Phase 1 parameters used in Scenario 1 are:
The IKE Phase 2 parameters used in Scenario 1 are:
To set up Gateway A for this scenario, use the following steps:
. . . Your instructions go here . . .
Note that the network setup and most of the IKE parameters are the same as for Scenario 1. If your documentation uses both Scenario 1 and Scenario 2, you may instead use the following description.
The following is a typical gateway-to-gateway VPN that uses PKIX certificates for authentication. The network setup is identical to the one given in the previous scenario. The IKE Phase 1 and Phase 2 parameters are identical to the ones given in the previous scenario, with the exception that the identification is done with signatures authenticated by PKIX certificates.
The steps for describing the PKIX certificates should include (in order):