On Sat, Apr 09, 2016 at 11:04:09AM +0100, Alex Bligh wrote:
[...]
> > [...]
> >> +The server MUST NOT send `NBD_REP_ERR_TLS_REQD` in reply to
> >> +any command if TLS has already been neogitated. The server
> >
> > negotiated
>
> I'd make sure you're looking at the latest version as Eagle Eyed Eric
> pointed out a whole pile of these.
Yeah, I noticed :-)
> > [...]
> >> +The client MAY send `NBD_OPT_STARTTLS` at any time to initiate
> >> +a TLS session, except that the client MUST NOT send
> >> +`NBD_OPT_STARTTLS` if TLS has alreay been initiated. If the
> >> +cllient receives `NBD_REP_ACK` in response, it
> >> +MUST immediately upgrade the connection to TLS. If it receives
> >> +`NBD_ERR_REP_UNSUP` in response or any other error, it indicates
> >> +that the server cannot or will not upgrade the connection to
> >> +TLS and therefore MUST either continue the connection without
> >> +TLS, or discconnect.
> >
> > That, or NBD_REP_ERR_POLICY.
>
> Yeah I can make that an alternative.
POLICY is the correct message; UNSUP is the alternative ;-)
(as in "for backwards compatibility, a client should also be prepared...")
[...]
> > (actually, "any error". If STARTTLS errors, the server effectively does
> > not support TLS)
>
> Well NBD_REP_ERR_INVALID means "The option sent by the client is known by
> this server, but was determined by the server to be syntactically invalid."
> which means the client has done something wrong. Given we've defined the
> legal responses to NBD_OPT_STARTTLS I'd rather keep that one.
Fair enough. Also, INVALID is the correct error message when the client sent
NBD_OPT_STARTTLS while inside a TLS connection, too, so that would've been a
contradiction ;-)
> > [...]
> >> - `NBD_OPT_STARTTLS` (5)
> >>
> >> - The client wishes to initiate TLS. If the server replies with
> >> - `NBD_REP_ACK`, then the client should immediately initiate a TLS
> >> - handshake and continue the negotiation in the encrypted channel. If
> >> - the server is unwilling to perform TLS, it should reply with
> >> - `NBD_REP_ERR_POLICY`. For backwards compatibility, a client should
> >> - also be prepared to handle `NBD_REP_ERR_UNSUP`. If the client sent
> >> - along any data with the request, the server should send back
> >> - `NBD_REP_ERR_INVALID`. The client MUST NOT send this option if
> >> - it has already negotiated TLS; if the server receives
> >> - `NBD_OPT_STARTTLS` when TLS has already been negotiated, the server
> >> - MUST send back `NBD_REP_ERR_INVALID`.
> >> -
> >> - This functionality has not yet been implemented by the reference
> >> - implementation, but was implemented by qemu so has been moved out of
> >> - the "experimental" section.
> >> + The client wishes to initiate TLS.
> >> +
> >> + The server MUST either reply with `NBD_REP_ACK` after which
> >> + point the connection is upgraded to TLS, or reply with
> >> + `NBD_REP_ERR_UNSUP`.
> >
> > (or POLICY)
>
> OK
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________
Nbd-general mailing list
Nbd-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nbd-general
