Steps for IPsec Interoperability Testing
draft-hoffman-ipsec-testing-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Paul E. Hoffman , Michael Richardson | ||
| Last updated | 2000-09-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Bringing up IPsec gateways, clients and end systems is a hard task. There are the numerous configurations issues that occur when doing this. Techniques for diagnosing regular nodes may not yeild understandable results when one or both nodes have network security features. There is a further difficulty presented by the number of configuration options presented by a typical IPsec gateway implementation, and the lack of consistent diagnostics from gateways. The network administrator, field engineers and product support staff are faced with multiple indistinguishable failure modes: is the client unable to connect because of a network outage, or because the two products have never actually tested in that scenario? Or is the naive user unaware that they are behind a network address translator?
Authors
Paul E. Hoffman
Michael Richardson
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)