-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/14/2012 03:31 AM, André Becker wrote: > Hi, > > Am 14.03.2012 00:11, schrieb Marc Petit-Huguenin: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 03/13/2012 02:02 PM, André Becker wrote: >>> Hi, >>> >>> there's an ambiguity in the current draft concerning the ConfigUpdate >>> mechanism. It remains unclear which node is responsible for checking >>> the configuration_sequence number (and, additionally, to generate the >>> appropriate error and the ConfigUpdateReq). Section 5.5.4 states: >>> >>> The ConfigUpdate method is used to push updated configuration data >>> across the overlay. Whenever a node detects that another node has old >>> configuration data, it MUST generate a ConfigUpdate request. >>> >>> A ConfigUpdate request must be generated if an old >>> configuration_sequence number is detected, but when does a node check >>> it? In section 5.3.2.1 it says: >>> >>> When a destination node receives a request, it MUST check that the >>> configuration_sequence field is equal to its own configuration sequence >>> number. If they do not match, it MUST generate an error, either >>> Error_Config_Too_Old or Error_Config_Too_New. In addition, if the >>> configuration file in the request is too old, it MUST generate a >>> ConfigUpdate message to update the requesting node. >>> >>> The critical term now is "destination node". If you search the >>> document, you'll find this term also in section 5.3.4. Here it is used >>> for the node that reassembles the fragments and checks the signature, >>> meaning the last node on the message's route. There are several >>> reasons why this node cannot or should not be meant by section 5.3.2.1. >>> I'm pretty sure that the configuration_sequence number must be checked >>> by EACH peer, including intermediate nodes. If only the last node >>> checked the configuration_sequence number, it would take significantly >>> longer time for new configuration data to spread in the overlay. >>> Additionally, security problems would arise, which is even more >>> important. So my suggestion would be to change the text of section >>> 5.3.2.1 cited above to something equivalent to the following: >>> >>> Whenever a destination node or intermediate node receives a message, it >>> MUST check that the configuration_sequence field is equal to its own >>> configuration sequence number. If they do not match, it MUST generate >>> an error, either Error_Config_Too_Old or Error_Config_Too_New. In >>> addition, if the configuration file in the request is too old, it MUST >>> generate a ConfigUpdate message to update the last node that forwarded >>> the message. >>> >> There was a similar discussion last year: >> >> https://www.ietf.org/mail-archive/web/p2psip/current/msg06040.html > Thanks for the pointer. However, the discussion back then did not include > the security aspects. I outlined a possible attack on RELOAD using the > current ConfigUpdate mechanism in my bachelor thesis which is, > unfortunately, written in german. But here a short summary of the attack: > > An adversary who is part of the overlay can store an old message of a node > he wants to attack (called the target node). He now changes the > configuration_sequence number (which is not included in the signature) to > an old value and sends this message to an arbitrary destination node in > the overlay. What does this node do? It first generates an > Error_Config_Too_Old which is sent to the adversary (by reversing the via > list). The ConfigUpdateReq, however, cannot be sent by reversing the via > list, it is a totally new request with new transaction_id. This request is > sent to the creator of the message, which is not the adversary, but the the > target node. > > This means the adversary can cause an arbitrary node to send a message of > big size, probably RELOADs biggest message to a target node he wants to > attack. This node MUST check the message's signature, which is the > potentially most expensive operation in RELOAD. Now the adversary can send > it's, let's say "forged messages" (old messages with altered > configuration_sequence) to a huge number of nodes over routes of different > lengths (arranged with appropriate destination lists). These nodes that > generate the ConfigUpdateReqs also have different distances to the target > node. This means: > > If correctly timed, the adversary can cause a huge number of messages of > big size to arrive at the target node at approximately the same time, which > definitely could result in a denial of service. The adversary needs only > one single node to form the attack AND he cannot be detected by the > attacked peer.
The configuration_sequence field should probably be part of the signature. - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPYJnRAAoJECnERZXWan7ERloP/0VCYNjSvs14w6JgxC/QkmS4 8cr9tdj6Ozi/tR1tQqRsd7/JCet+sMlBYj45+owPFj7ahZuI8X7K5jlM3ZQWWlo7 7rItWnR3qzEoTNETHXkKMY7ifLRkkFrg345S/pUY8aTaeYNwLkvCPZiLPynjB8Nr 84AsIUv/4iVd0+Qe6U9cJqtIoPrykg+J32MolLgEYFVAEaicnJG0DPcBDj7vMN3U CeBWOD776JqMswzqa7czrHQ8DR3qdbcyyAIG2Ntri3OWAqXL5rxb7V9RtKxNvFLy ti5KZPwEpm+AoPZH2gQbPkuGJU0u+w0TgBhQITGc/Grn9Yy+0TBEqq5vfJtpqBRM gCOJ36Y4MxeWsRqeTiYzaKposRc3g7rjPvRnZetat3CPxwMHr0Qn5aMwFZeqCwSe NpSSKmeCaeTE5+4CHkg6ywiY6xJYRUQhKtUoO2ESownUwei59axorL8Tjr20enqg zwJ5Z9O/MGu5C9M1YBjVbEdC2znLxyGGu6tGTLwl4VoFVqkwL66fQaORM4vU7XhI dJesg+tJoeqrWbdOXskD0wx3X4PL6fKYJNWzLCXX/xP49JN++GCZdXfQjlJ4SYqj K+AH9d0++2TIHRCsW3xDIYJJFb1GVsG07mGKU9lbQYfGLif+F9vXu7Os1dWfA3Tu HNbvxpTx2/O7OLByhp68 =pAkb -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
