[Nbd] [PATCH/RFC] Synchronize NBD_OPT_STARTTLS
If option replies remain outstanding when NBD_OPT_STARTTLS is issued
then those replies may arrive unencrypted when NBD_OPT_STARTTLS
is processed. Similarly options sent after NBD_OPT_STARTTLS is
issued (but not replied to) may be sent unencrypted but are
expected to be encrypted. This is difficult to track server side,
so put the obligation on the client to act sensibly.
Signed-off-by: Alex Bligh <alex@...872...>
---
doc/proto.md | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
This patch is **NOT** my preferred option, but is the minimal
fix.
diff --git a/doc/proto.md b/doc/proto.md
index 24ab813..ff85572 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -523,7 +523,12 @@ negotiation.
The client MUST NOT issue `NBD_OPT_STARTTLS` if TLS has already
been initiated.
-Subject to the above two limitations, the client MAY send
+The client MUST NOT issue `NBD_OPT_STARTTLS` if there are any
+options it has already issued the replies to which remain
+outstanding, and the client MUST NOT issue any further options
+until it has received a reply to `NBD_OPT_STARTTLS`.
+
+Subject to the above three limitations, the client MAY send
`NBD_OPT_STARTTLS` at any time to initiate a TLS session. If the
client receives `NBD_REP_ACK` in response, it MUST immediately
upgrade the session to TLS. If it receives `NBD_REP_ERR_UNSUP`,
--
1.9.1
Reply to: