Encrypted ESP Echo Protocol
draft-ietf-ipsecme-encrypted-esp-ping-00
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
Expired & archived
|
|
|---|---|---|---|
| Authors | Antony Antony , Steffen Klassert | ||
| Last updated | 2025-10-05 (Latest revision 2025-04-03) | ||
| Replaces | draft-antony-ipsecme-encrypted-esp-ping | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| 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
This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED.
Authors
Antony Antony
Steffen Klassert
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)