Re: [Nbd] [PATCHv8] Improve documentation for TLS
- To: Alex Bligh <alex@...872...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, "Daniel P. Berrange" <berrange@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>
- Subject: Re: [Nbd] [PATCHv8] Improve documentation for TLS
- From: Wouter Verhelst <w@...112...>
- Date: Tue, 12 Apr 2016 14:40:55 +0200
- Message-id: <20160412124055.GA15484@...3...>
- In-reply-to: <ACE271FF-7D80-48CD-A044-780AC6AC4EF9@...872...>
- References: <1460292452-1348-1-git-send-email-alex@...872...> <20160411061013.GE28660@...3...> <4942E119-AFFA-42B4-A6DF-2BD6F729D84D@...872...> <570C059E.6090000@...696...> <ECBAC2D7-160B-4E86-A469-00594CB45910@...872...> <20160412060155.GF4281@...3...> <0D0FC6E7-F6DA-4B70-A2DD-66ADCD038CA2@...872...> <20160412092058.GA30686@...3...> <ACE271FF-7D80-48CD-A044-780AC6AC4EF9@...872...>
On Tue, Apr 12, 2016 at 10:53:57AM +0100, Alex Bligh wrote:
> Wouter,
>
> On 12 Apr 2016, at 10:20, Wouter Verhelst <w@...112...> wrote:
>
> > To summarize, there are three ways for the connection to end:
> >
> > - The client wishes to end the session, and sends the appropriate
> > termination message (OPT_ABORT or CMD_DISC). This is a normal
> > disconnect.
> > - Either peer violates a MUST in the spec, and the other side doesn't
> > know how to handle the resulting inconsistency. The only proper
> > solution at that point is to drop the connection, but that's only
> > because there's really nothing else we *can* do. This is an abnormal
> > disconnect.
> > - The server wishes to terminate the session. There isn't actually a
> > message for this, so it also results in an abnormal disconnect.
>
> The last case includes (e.g.) 'NBD_OPT_EXPORT_NAME' issued to
> a non-existing mount)
>
> > Perhaps we could state that the server can send a message (offset 0,
> > length 0, handle 0, error EINTR) when it wants to terminate the session
> > for whatever reason (e.g., because it's being restarted).
>
> I think that will make clients' life harder. Most clients don't
> expect messages from the server which aren't replies, so I can see
> them treating it as a reply to the next message they issue, or
> getting into some horrible blocking situation.
>
> (Also please don't use EINTR - that implies you can retry. ETERM?)
>
> > Originally, there were a number of termination points where we could
> > drop the connection without further explanation. It was a mess, because
> > it resulted in confusing messages (e.g., the server would produce error
> > messages in system logs for every disconnect because it couldn't
> > distinguish between clean disconnects and unclean disconnects).
> >
> > I don't want to go there again.
>
> I think what we should probably say is this (wording needs
> tweaking I know):
>
> * One side MAY drop the connection if the other end violates a
> MUST condition.
> * The server MUST drop the connection in the 'no way out' situations
> during the negotiation phase (error on NBD_OPT_EXPORT_NAME, error
> in negotiating text).
> * As protocol authors we should minimise the number of 'no way out'
> situations.
> * The server SHOULD NOT otherwise drop the connection. It can wait
> and error the next command. Clearly there are situations where
> this is going to happen (e.g. server shutdown).
> * If the server does need to drop the connection, it SHOULD wait
> until there are no commands in-flight in transmission mode,
> it possible.
> * If he client is going to drop the the connection, then other
> than in the event of a protocol violation or a 'no way out'
> situation (e.g. TLS negotiation fails), it MUST use NBD_CMD_DISC
> or NBD_OPT_ABORT
> * We should tidy up the semantics and descriptions of NBD_CMD_DISC
> and NBD_OPT_ABORT, viz replies or not to the latter, shutting
> down TLS properly etc.
Right, that sounds good.
--
< 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
Reply to: