Subject: Re: [P2PSIP] draft-ietf-p2psip-base-20: Responsibility for ConfigUpdate mechanism

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jun 2012 15:35:47 -0700

This does seem kind of unattractive, though I would observe that

(a) it's not blind
(b) you actually have to have valid RELOAD credentials to mount it.

I'm not sure it's enough to check the sequence on each peer, since the
attacker could just connect to  a bunch of peers. Maybe if you checked
the sequence, the rule could be that you sent an update to where you got
it from since he is obviously wrong.

Thoughts?

-Ekr

On Wed, Mar 14, 2012 at 7:08 AM, André Becker
<[email-masked]> wrote:
> 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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip