Other problems also existed but they are still being diagnosed.
| [A word about Marks & Symbols used within the Matrix] |
|
| OO: | Both Initiater & Responder Tests [Step 1] completed successfully. |
| O: | Test completion for the marked portion only. |
| X: | Test did not complete successfully. |
| *1: | Re-keying started from Phase I for [Step 2] instead of Phase II. |
| Lt Blue Bkgd: |
There was either not enough time to perform Step 2 or test was not perform for other reasons . |
| Responder
Initiator |
Watch Guard |
Shiva VPN Gateway Plus | PERMIT | Ravlin | Raptor Firewall NT | Side Winder Security Server | Contivity Extranet Switch | OneGate (Free Gate) 1000 | cIPro | VPNet | Mucho -EV | Yamaha RT140e | Cisco 1700 | A2DIS | Path Builder | SafeNet | Fort Knox | STAR- Gateware |
| WatchGuard | Watch Guard | T | OO | OO | T | T | T | - | - | OO | OO | T | T | T | OO | T | O | T |
| Shiva | T | Shiva | ? | ? | T | T | T | ? | T | ? | ? | T | T | T | T | T | - | T |
| PERMIT | OO | O | PERMIT | OO | OO | OO | T | - | OO | OO | OO | O | OO | T | OO | - | - | OO |
| Ravlin | OO | O | OO | Ravlin | OO | OO | T | - | T | OO | OO | T | OO | T | OO | T | T | OO |
| Raptor | T | T | OO | OO | Raptor | T | T | T | - | OO | OO | T | T | T | T | OO | T | OO |
| Side Winder | T | T | OO | OO | T | Side Winder | T | T | T | OO | OO | T | T | T | T | T | T | T |
| Contivity | T | T | T | T | T | T | Contivity | T | T | T | T | T | T | T | T | T | T | T |
| OneGate | O | - | - | O | T | T | OneGate | O | T | T | - | T | T | T | T | T | ||
| cIPro | O | T | OO | T | - | T | T | cIPro | OO | OO | OO | T | T | T | T | OO | ||
| VPNet | OO | O | OO | OO | OO | OO | T | - | OO | VPNet | OO | O | OO | T | T | OO | - | OO |
| Mucho-EV | OO | O | OO | OO | OO | OO | T | T | OO | OO | Mucho | ? | OO | T | OO | O | ? | OO |
| YAMAHA | T | T | ? | T | T | T | T | T | ? | ? | Yamaha | ? | T | ? | T | T | ||
| Cisco 1700 | T | T | OO | OO | T | T | T | - | OO | OO | OO | ? | Cisco | T | T | - | - | OO |
| A2DIS | T | T | T | T | T | T | T | T | T | T | T | T | T | A2DIS | T | T | T | T |
| PathBuilder | OO | T | OO | OO | T | T | T | T | T | T | OO | ? | T | T | Path Builder | T | T | T |
| SafeNet | T | T | O | T | OO | T | T | T | T | OO | ? | T | - | T | T | SafeNet | T | OO |
| FortKnox | ? | - | O | O | T | T | T | T | T | O | ? | O | T | O | T | Fort Knox | T | |
| STAR- Gateware |
T | T | OO | OO | OO | T | T | T | OO | OO | OO | T | OO | T | T | OO | T | STAR- Gateware |
| Amendment 1 | Shiva VPN Gateway | The [SA Lifetime] and [ISAKMP LifeTime] settings are one in the same, thus [Step 2] (Phase II only) could not be completed without restarting at [Step 1] Phase 1 again.
Operationally, proper communications can be re-established from Phase 1 each time although it will require the Phase I additional traffic each time it is re-negotiated. Also, if the other side initiates a Phase II first, an error will occur on the remote side and a new negotiation process will re-start from Phase II again. |
| Amendment 2 | FortKnox | The SA LifeTime only lasts for half of the time which is specified. Also, occasionally during re-keying, several Pinged packets tend to timeout during the Phase II re-negotiation process which should occur instantly which may interrupt communications for several seconds.
Manufacturer has said that this problem will be fixed in a future release. |
| Amendment 3 | OneGate | This is actually a beta version and was included in the testing, but the results will not be published.
A final release version is expected in the near future though. |
| Amendment 4 | YAMAHA RT-140 | This is actually a beta version and was included in the testing, but the results will not be published.
A final release version is expected in the near future though. |
| Amendment 5 | A2DIS VPNGateway | This product was able to establish secure communications with several vendors, but as it's unique [Identification] method caused negotiation [Fail] errors on various other vendors equipment, it was not included in this report.
This is actually a beta version and was included in the testing, but the results will not be published. A final release version is expected in the near future though. |
| Amendment 6 | SafeNet | This client supports an internal Virtual IP address support which is supported in the latest specifications, but which also didn't work with vendors whom didn't support the latest specs.
If both the Peer and Target IP are one in the same, some vendors won't communicate with it. These vendors' products haven't yet provided the [Virtual IP Address] support in their products yet. One interesting item noticed was that 3Com's box send the same packet twice in both Secure and Clear Traffic when both Peer and Target IP addresses were the same. This problem is supposedly fixed in their latest release. |
For those devices which did not pass [Step 1] and/or [Step 2], the main cause and supposition are included below:
To discover the main cause of not being able to pass the tests, the IKEVIEW Analyzer and Debug Logs included in other vendors products were used to summarize the findings.
Even if certain devices were unable to pass all of the specified tests, by using various other settings not specified for this test, secure communications were able to be established.
| Note 1 | Misuse of the [ID_Type] and [Identification_Data] within the [Identification_Payload] was the major cause of FAIL errors between devices.
(ID_TYPEFID_IPV4_ADDRAID_IPV4_ADDR_SUBNET, etc.) Many of the times, the [Notification] message specified that the HASH(2) portion didn't respond and thus negotiations were terminated. Several of the devices required specific fine-tuning to the parameters (usually scripts, or text editable parameters) before successful communications were made. Ex) Cisco & Sidewinder |
| Note 2 | Some of the Phase I failures were caused by the IPSEC Notify Messages "INITIAL_CONTACT" could not be made.
Upon modification of certain parameters without rebooting some machine caused many of the "INITIAL_CONTACT" errors. This is probably due to the fact that an SA was previously established using one set of parameters and to clear those already learned settings, some systems had to be reset. |
| Note 3 | If the Responder could not identify the "Vender_ID" of the originator, it was reported as a failure. This could also be related to Note 1: above.
If Phase1 cannot properly identify the payload, it cannot complete Phase 1 and therefore is fails to establish a secure session. Problems related to this were in the form of [PAYLOAD_MALFORM], [PAYLOAD_SYNTAX_ERROR], etc. Depending on the version of both VPN devices, the information provided in the "Vender_ID" depends on each manufacturer's implementation. Ex) Shiva VPN Gateway & RaptorFirewall |
| Note 4 | If the "IKE LifeTime" with in the proposal_payload is blank, it will cause Phase 1 to fail. Per specifications, this cannot be blank. The IPSec spec defaults to 28800 seconds if not specified otherwise by user. |
| Note 5 | If the device does not support "Multi-proposals" in the "Proposal_Payload", it will FAIL Phase1.
This could occur if either: - One (1) Proposal includes multiple Transforms. - Multiple Proposals are sent consecutively. This problem can be overcome by closely examining the devices and by fine tuning where required. Ex) StarGateware & Sidewinder |
| Note 6 | Invalid Proposals were the main cause of the Responder not being able to process the request properly and thus it would FAIL the test between both devices.
Ex) Ravlin & Contivity |
| Note 7 | If the [IKE LifeTime] & [IPSEC SA LifeTime] settings are one in the same, upon re-keying a new SA, the negotiation re-starts at Phase 1 instead of Phase 2.
Note: If the Phase 1 netogiation is restarted properly, then communications can continue and there is no real problem other than it FAILS to renegotiate from Phase 2 only and thus FAILS the specified Step 2 test. See the comments at the end of STEP 2 for more details. Ex) ShivaVPNGateway & Permit |
| Note 8 | A word about [Re-Key] negotiation FAILures:
Depending on how the [IPSEC SA LifeTime] was set, when the Responder initiates the [Re-Key] request, the Initiator must reply to the [Re-Key] negotiation, but the following problems were experienced by the Responder: Pattern 1: Renegotiation is not performed. Pattern 2: All ESP packets are ignored and then the Initiator starts the [Re-Key] request and it completes successfully. Pattern 3: The current SA is Deleted and re-negotiation starts at Phase 1. During actual testing, various parameters had to be fine tuned on several vendors' products for this to be performed properly. Ex) FortKnox CE & VPNet |