===================================================================
RCS file: /cvsrepo/anoncvs/cvs/src/usr.bin/ssh/PROTOCOL,v
retrieving revision 1.48.4.1
retrieving revision 1.49
diff -u -r1.48.4.1 -r1.49
--- src/usr.bin/ssh/PROTOCOL	2023/12/18 14:57:43	1.48.4.1
+++ src/usr.bin/ssh/PROTOCOL	2023/08/28 03:28:43	1.49
@@ -104,32 +104,39 @@
 
 This is identical to curve25519-sha256 as later published in RFC8731.
 
-1.9 transport: strict key exchange extension
+1.9 transport: ping facility
 
-OpenSSH supports a number of transport-layer hardening measures under
-a "strict KEX" feature. This feature is signalled similarly to the
-RFC8308 ext-info feature: by including a additional algorithm in the
-initiial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
-"kex-strict-c-v00@openssh.com" to its kex_algorithms and the server
-may append "kex-strict-s-v00@openssh.com". These pseudo-algorithms
-are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored
-if they are present in subsequent SSH2_MSG_KEXINIT packets.
+OpenSSH implements a transport level ping message SSH2_MSG_PING
+and a corresponding SSH2_MSG_PONG reply.
 
-When an endpoint that supports this extension observes this algorithm
-name in a peer's KEXINIT packet, it MUST make the following changes to
-the the protocol:
+#define SSH2_MSG_PING	192
+#define SSH2_MSG_PONG	193
 
-a) During initial KEX, terminate the connection if any unexpected or
-   out-of-sequence packet is received. This includes terminating the
-   connection if the first packet received is not SSH2_MSG_KEXINIT.
-   Unexpected packets for the purpose of strict KEX include messages
-   that are otherwise valid at any time during the connection such as
-   SSH2_MSG_DEBUG and SSH2_MSG_IGNORE.
-b) After sending or receiving a SSH2_MSG_NEWKEYS message, reset the
-   packet sequence number to zero. This behaviour persists for the
-   duration of the connection (i.e. not just the first
-   SSH2_MSG_NEWKEYS).
+The ping message is simply:
 
+	byte		SSH_MSG_PING
+	string		data
+
+The reply copies the data (which may be the empty string) from the
+ping:
+
+	byte		SSH_MSG_PONG
+	string		data
+
+Replies are sent in order. They are sent immediately except when rekeying
+is in progress, in which case they are queued until rekeying completes.
+
+The server advertises support for these messages using the
+SSH2_MSG_EXT_INFO mechanism (RFC8308), with the following message:
+
+	string		"ping@openssh.com"
+	string		"0" (version)
+
+The ping/reply message is implemented at the transport layer rather
+than as a named global or channel request to allow pings with very
+short packet lengths, which would not be possible with other
+approaches.
+
 2. Connection protocol changes
 
 2.1. connection: Channel write close extension "eow@openssh.com"
@@ -738,4 +745,4 @@
 OpenSSH extends the usual agent protocol. These changes are documented
 in the PROTOCOL.agent file.
 
-$OpenBSD: PROTOCOL,v 1.48.4.1 2023/12/18 14:57:43 bluhm Exp $
+$OpenBSD: PROTOCOL,v 1.49 2023/08/28 03:28:43 djm Exp $