Hi, Here’s the latest version, -05, of draft-antony-ipsecme-encrypted-esp-ping. This update, since IETF 120, includes readability improvements and fixes to the IP-TFS subtype, as well as the addition of an IKEv2 notification.
There’s been interest in this work, as reflected in feedback from recent IETF meetings in Vancouver and Dublin, hallway discussions, and emails indicating potential implementation if adopted by the IPsecME working group. One detail remains to be addressed before Working Group Last Call—specifically, handling cases where the return path differs from the sending SA pair. I believe we can refine this through implementation experience following WG adoption. The packet format and protocol specification are stable. However, feedback from implementers may only come after WG adoption. I would like to invite show of hands if you are one of aspiring implementers or know of anyone else who is waiting for WG adoption. What would be a path toward working group adoption for this draft? regards, -antony On Wed, Nov 06, 2024 at 07:51:41 -0800, internet-dra...@ietf.org wrote: > A new version of Internet-Draft draft-antony-ipsecme-encrypted-esp-ping-05.txt > has been successfully submitted by Antony Antony and posted to the > IETF repository. > > Name: draft-antony-ipsecme-encrypted-esp-ping > Revision: 05 > Title: Encrypted ESP Echo Protocol > Date: 2024-11-06 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-antony-ipsecme-encrypted-esp-ping-05.txt > Status: > https://datatracker.ietf.org/doc/draft-antony-ipsecme-encrypted-esp-ping/ > HTML: > https://www.ietf.org/archive/id/draft-antony-ipsecme-encrypted-esp-ping-05.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-antony-ipsecme-encrypted-esp-ping > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-antony-ipsecme-encrypted-esp-ping-05 > > 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. > > > > The IETF Secretariat > > _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
