Hi all,
(added rjones from nbdkit fame -- hi there)
So I think the following would make sense to allow TLS in NBD.
This would extend the newstyle negotiation by adding two options (i.e.,
client requests), one server reply, and one server error as well as
extend one existing reply, in the following manner:
- The two new commands are NBD_OPT_PEEK_EXPORT and NBD_OPT_STARTTLS. The
former would be used to verify if the server will do TLS for a given
export:
C: NBD_OPT_PEEK_EXPORT
S: NBD_REP_SERVER, with an extra field after the export name
containing flags that describe the export (R/O vs R/W state,
whether TLS is allowed and/or required).
If the server indicates that TLS is allowed, the client may now issue
NBD_OPT_STARTTLS:
C: NBD_OPT_STARTTLS
S: NBD_REP_STARTTLS # or NBD_REP_ERR_POLICY, if unwilling
C: <initiate TLS handshake>
Once the TLS handshake has completed, negotiation should continue over
the secure channel. The client should initiate that by sending an
NBD_OPT_* message.
- The server may reply to any and all negotiation request with
NBD_REP_ERR_TLS_REQD if it does not want to do anything without TLS.
However, if at least one export is supported without encryption, the
server must not in any case use this reply.
There is no command to "exit" TLS again. I don't think that makes sense,
but I could be persuaded otherwise with sound technical arguments.
Thoughts?
(full spec (with numbers etc) exists as an (uncommitted) diff to
doc/proto.txt on my laptop, ...)
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list