From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apiE9-0006VC-SP for qemu-devel@nongnu.org; Mon, 11 Apr 2016 16:14:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apiE5-0005nH-Qf for qemu-devel@nongnu.org; Mon, 11 Apr 2016 16:14:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apiE5-0005nB-J5 for qemu-devel@nongnu.org; Mon, 11 Apr 2016 16:14:25 -0400 References: <1460292452-1348-1-git-send-email-alex@alex.org.uk> <20160411061013.GE28660@grep.be> <4942E119-AFFA-42B4-A6DF-2BD6F729D84D@alex.org.uk> From: Eric Blake Message-ID: <570C059E.6090000@redhat.com> Date: Mon, 11 Apr 2016 14:14:22 -0600 MIME-Version: 1.0 In-Reply-To: <4942E119-AFFA-42B4-A6DF-2BD6F729D84D@alex.org.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2qsnNg1vdMsj45DQXAakF1rO0FSOFMrav" Subject: Re: [Qemu-devel] [Nbd] [PATCHv8] Improve documentation for TLS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh , Wouter Verhelst Cc: "nbd-general@lists.sourceforge.net" , "Daniel P. Berrange" , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2qsnNg1vdMsj45DQXAakF1rO0FSOFMrav Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/11/2016 01:27 AM, Alex Bligh wrote: >>> +There is no requirement for the client or server to complete a negot= iation >>> +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= =2E >>> +Under certain circumstances either the client or the server may be r= equired >>> +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 b= y >> 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). >=20 > This section only relates to the negotiation phase, so really this is > about use (or not) or NBD_OPT_ABORT, not NBD_OPT_DISC. >=20 > Your statement is a bit surprising though as far as NBD_OPT_ABORT > is concerned.=20 >=20 > Firstly, there is no way to the *server* to send NBD_OPT_ABORT. > That's what this paragraph was primarily aimed at. >=20 > Secondly proto.md has: >=20 >> The phase continues until either side closes the connection. >=20 > That implies that either the client or the server can initiate the > close. >=20 > I thought on this basis its use was entirely optional. >=20 > NBD_OPT_ABORT says: >=20 >> - `NBD_OPT_ABORT` (2) >> >> The client desires to abort the negotiation and close the >> connection. >> >=20 > 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. >=20 > Obviously NBD_OPT_ABORT and aborting the connection needs > more clearing up, but I'm loathe to do it in the TLS patch. >=20 > In order not to make things worse, how about: >=20 >> 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --2qsnNg1vdMsj45DQXAakF1rO0FSOFMrav Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXDAWeAAoJEKeha0olJ0NqLh4H/j/F5Sh0wjmTaYkDVoZxBrMa 2CN/NxXw4Bn6KaCenlfKKf5GHxFODimytla/6O6XEvigHhCkbE9DzVGHzQ/XOy3a cDS50zxQooP9ayZdgGemyhSZkQED7g3WMek9QHt2aR5hFRON6/U8OQBFLApyTdq/ hmmt1xjmdC3d1ct4zFCZlyZgcJKUR3jhmsKzxplvl2Thv5mv4PI+P1NyMrAX4XA7 zlOkxW0xOfqKvDlqlMyF5EBHLh43wa9EztrzRMdyf6o9MdC+GFpJ+9/ko3ChAJja IlRimtYCSV5Rc+C3J8PjjoR9xFOseK55z4JaiaImoE/7ymOJtc2SNSpLic2WXq4= =GsLF -----END PGP SIGNATURE----- --2qsnNg1vdMsj45DQXAakF1rO0FSOFMrav--