Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F17F949 for ; Mon, 13 Feb 2017 11:14:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8213BE0 for ; Mon, 13 Feb 2017 11:14:04 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 909F72D006FB; Mon, 13 Feb 2017 12:14:03 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro.local (unknown [213.55.211.10]) by server3 (Postfix) with ESMTPSA id B25C32D00145; Mon, 13 Feb 2017 12:14:02 +0100 (CET) To: Eric Voskuil , Bitcoin Protocol Discussion References: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> From: Jonas Schnelli Message-ID: Date: Mon, 13 Feb 2017 12:14:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ" Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 11:14:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ Content-Type: multipart/mixed; boundary="TDr5xUoebJE8C3VLxT8NxMSHNkHv61GcC"; protected-headers="v1" From: Jonas Schnelli To: Eric Voskuil , Bitcoin Protocol Discussion Message-ID: Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility References: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> In-Reply-To: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> --TDr5xUoebJE8C3VLxT8NxMSHNkHv61GcC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> Look at feefilter BIP 133 >> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backwa= rd-compatibility) >> or sendheaders BIP130 >> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backwa= rd-compatibility) >> Isn't it the same there? > No. This is what I was referring to. These messages are enabled by > protocol version. If they are received by a node below the version at > which they are activated, they are unknown messages, implying an invali= d > peer. The above messages cannot be sent until *after* the version is > negotiated. BIP151 violates this rule by allowing the new control > message to be sent *before* the version handshake. This indeed is not ideal for compatibility checks, but increases security= =2E I could not find a protocol specification that said communication must be terminated when messages are transmitted before the version handshake has been done. I mostly looked into Bitcoin-Cores implementation (which means also into BitcoinXT/UT, where this is allowed). Also. BIP151 clearly says that the requesting peer needs to initiate the encryption (encinit). In case of light clients not supporting BIP151 connecting to peers supporting BIP151, there should never be transmission of new message types specified in BIP151. > >> Once BIP151 is implemented, it would make sense to bump the protocol >> version, but this needs to be done once this has been >> implemented/deployed. > There are already nodes out there breaking connections based on the BIP= =2E It could very likely be possible that the initial responding peer tries to initiate a encryption session which would mean that BIP151 was not implemented correctly. Correct me if I'm wrong please. > >> Or do I make a mistake somewhere? > Yes, the ordering of the messages. New messages can only be added after= > the handshake negotiates the higher version. Otherwise the handshake is= > both irrelevant (as Pieter is implying) and broken (for all existing > protocol versions). I could not find evidence of the protocol specification that would forbid (=3Dterminate connection) such messages and I think allowing unknown-messages before the version handshake makes the protocol flexible= =2E Are there any reasons we should drop peers if they send us unknown, but correctly formatted p2p packages (magic, checksum, etc.) before the version handshake, ... but not drop them if we have received unknown messages after the version handshake? I can't see that a such spec. would reduce the DOS attack vector? > >>> As for DOS, waste of bandwidth is not something to be ignored. If a p= eer >>> is flooding a node with addr message the node can manage it because i= t >>> understands the semantics of addr messages. If a node is required to >>> allow any message that it cannot understand it has no recourse. It >>> cannot determine whether it is under attack or if the behavior is >>> correct and for proper continued operation must be ignored. >> How do you threat any other not known message types? > You may be more familiar with non-validating peers. If a message type i= s > not known it is an invalid message and the peer is immediately dropped.= > We started seeing early drops in handshakes with bcoin nodes because of= > this issue. If this had happened, it's very likely because the responding peer tried to initiate a encryption session which is against BIP151 specs. > >> Any peer can send you any type of message anytime. > Sure, a peer can do what it wants. It can send photos. But I'm not sure= > what makes you think it would be correct to maintain the connection whe= n > an *invalid* message is received. Check: https://github.com/bitcoin/bitcoin/blob/a06ede9a138d0fb86b0de17c42b936d9f= e6e2158/src/net_processing.cpp#L2595 I think it was a wise implementation decision to allow unknown (not invalid) messages. This had allowed us to deploy stuff like compact blocks, feefilter, etc. without breaking backward compatibility. IMO, without a such flexibility, the deployment complexity would be irresponsible high without really solving the DOS problem. > >> Why would your implementation how you threat unknown messages be > different for messages specified in BIP151? > > Because it properly validates the protocol. For feefilter or compact block or sendheaders? You can't link a (unimplemented) specification (improvement process) to a protocol version before deployment. Or can you? Once it has been widely deployed, we should set a protocol minversion for BIP151, right. --TDr5xUoebJE8C3VLxT8NxMSHNkHv61GcC-- --dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMu5cTD+hXMrbRqvlKdS8tkFvU+wFAlihlPoACgkQKdS8tkFv U+ykfA/9FIfkaoqjvjerNkUO3q9pjAU9iBpdpYkjdsYy0v/AJipVSUfHOrSEUFaM mLxPaojG2Ib7WCFIFSk71lI5nAejW4WyNqZ2HMD8XoK++Rpl815cKHKu5y/Ih3D+ J1rIxMdWMaaW+QBu58sVUYpRNcDYqzxCbH6ZLLdNeuPkedr2UppregpWCKeNsUhw 2NBYvohbNLe6CpysbRP4fJvb18SxCqBxwNnBQeL7ioGMnkLRZknvBzUmPQYdTwMo ZYx+iu3k/i6RB5l9k7ZrjWLRqI9ionPa2lvIZYgNGcA9q+ysaahVNrHlX04532j7 TiRxcPRzOH8X8qTpslNBvIMaruVovDbgym8kbp5qO4BZ71p4r5RlnalvDwtz+InI IJX2YFB6ghMWXOP4EjqMlihhbGuy9sAcuQvJALWN6G5DV5FKipuCgMQ0DLhs9QQR JHnON6fT4royw7ODFVOFyfmXWW2EFv47XaGOaSVVugFWEDUb7KH/NFUE7Um8SgyJ sDFlyZO70ML8EGXs0obGUn4FXTefieM3ZY+MvrEBRsTJdvH+2UOrZ6sw5qgv+HsW getzw9T5H0keFv4EALdrh2s8VtdfkchiwTmAt/rdP9t90zOSJ8NLOMYHfCYu175N Uh/iEeVyvl6ZiAogJnquUUULfNvbZZONmggz/AaNHYeD2QKDNUg= =15N5 -----END PGP SIGNATURE----- --dNnVSQvgskeC9aXb0wsEX5aG6L0aUnxwQ--