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.
I hope this revives the discussion.
Regards,
André
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
