Hi,
Am 14.03.2012 14:15, schrieb Marc Petit-Huguenin:
-----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.
I thought about that too, but I think that does not solve the problem.
This would mean that, before a ConfigUpdateReq is generated, the
receiving node had to validate the signature of the request. But: Can or
should a node be able to validate a signature computed with an old
configuration document? I don't think so, as the root certificates are
part of the document. Also, a possible extension to RELOAD could be to
include allowed (or required) algorithms for signature computation in
the configuration document. This would stress this problem even more.
This is why I would prefer to keep the configuartion_sequence out of the
signature. If the attack I presented is a serious issue (which I think
it is), the questions is which change would cut deeper: Checking of
configuration_sequence by each peer on the route, or taking
configuration_sequence into the signature. In my implementation, the
latter would cause more work, but I can't speak for other implementations.
Regards,
André
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
