Re: [Qemu-devel] [Nbd] [PATCHv8] Improve documentation for TLS

[Eric Blake]

On 04/11/2016 01:27 AM, Alex Bligh wrote:

>>> +There is no requirement for the client or server to complete a negotiation
>>> +if it does not wish to do so. If the client does not find an export it
>>> +is looking for (for instance) it may simply close the TCP connection.
>>> +Under certain circumstances either the client or the server may be required
>>> +by this document to close the TCP connection. In each case, this is
>>> +referred to as 'terminate the session'.
>>> +
>>> ### Transmission
>>
>> NAK. If we have disconnect messages (NBD_OPT_ABORT and NBD_CMD_DISC), it
>> makes sense to say that clients should use them. Protocol violations by
>> peers are a different matter; but in the general case you should drop a
>> connection properly, i.e., by using the relevant "close the connection"
>> command.
>>
>> (I realize I didn't comment on this earlier, but I changed my mind
>> during the discussion about DISC).
> 
> This section only relates to the negotiation phase, so really this is
> about use (or not) or NBD_OPT_ABORT, not NBD_OPT_DISC.
> 
> Your statement is a bit surprising though as far as NBD_OPT_ABORT
> is concerned. 
> 
> Firstly, there is no way to the *server* to send NBD_OPT_ABORT.
> That's what this paragraph was primarily aimed at.
> 
> Secondly proto.md has:
> 
>> The phase continues until either side closes the connection.
> 
> That implies that either the client or the server can initiate the
> close.
> 
> I thought on this basis its use was entirely optional.
> 
> NBD_OPT_ABORT says:
> 
>> - `NBD_OPT_ABORT` (2)
>>
>>     The client desires to abort the negotiation and close the
>>     connection.
>>
> 
> I *presume* it has a reply (all the others do). Should a client
> wait for the undocumented reply before closing its end of
> the connection or not? I must admit the semantics are sufficiently
> opaque though I support it server side (with a reply) I would
> never sent it client side.

Current qemu NBD server implementation does NOT send a reply to
NBD_OPT_ABORT, but immediately closes the connection. I don't know if
that is a bug in qemu (especially given the discussion on NBD_CMD_DISC),
but it is an independent issue from TLS documentation, so may be better
discussed on that thread.

Likewise, current qemu NBD client implementation does NOT send
NBD_OPT_ABORT at all, so it's hard to say whether waiting around for a
reply is worthwhile.

> 
> Obviously NBD_OPT_ABORT and aborting the connection needs
> more clearing up, but I'm loathe to do it in the TLS patch.
> 
> In order not to make things worse, how about:
> 
>> There is no requirement for the client or server to complete a
>> negotiation if it does not wish to do so. Either end may simply
>> close the TCP connection (though see below re prior use

Not sure if the use of "re" is ideal (are you abbreviating for "regarding")?

>> of NBD_OPT_ABORT). Under certain circumstances either
>> the client or the server may be required by this document to close
>> the TCP connection. In each case, this is referred to as 'terminate
>> the session'.
>>
>> If the client wishes to terminate the session in the negotiation
>> phase, and is not doing so because it is required to do so
>> by this document, it SHOULD send NBD_OPT_ABORT first if the protocol
>> permits. There are instances where this is impossible, such as after
>> an NBD_OPT_EXPORTNAME has been issued, or on an unsuccessful
>> negotiation of TLS.  For instance, if the client does not find an
>> export it is looking for, it may simply send an NBD_OPT_ABORT
>> and close the TCP connection.

Otherwise, this seems reasonable, other than the fact that qemu needs
patches to actually start sending NBD_OPT_ABORT where possible.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature