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

From: André Becker <[email-masked]>
Date: Tue, 13 Mar 2012 22:02:44 +0100

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.

I'd be glad to read your comments,
   André

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 13 Mar 2012 16:11:30 -0700

On 03/13/2012 02:02 PM, André Becker wrote:
> 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:
> 
> 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 
> 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
> 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

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: André Becker <[email-masked]>
Date: Wed, 14 Mar 2012 11:31:24 +0100

Hi,

Am 14.03.2012 00:11, schrieb Marc Petit-Huguenin:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
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é

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 14 Mar 2012 06:15:01 -0700

On 03/14/2012 03:31 AM, André Becker wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>>> mechanism. It remains unclear which node is responsible for checking 
>>> the configuration_sequence number (and, additionally, to generate the 
>>> across the overlay.  Whenever a node detects that another node has old
>>> 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:
>>> 
>>> 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.
>>> 
> 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, 
> 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:
> 
> 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

---

From: André Becker <[email-masked]>
Date: Wed, 14 Mar 2012 15:08:21 +0100

Hi,

> 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é

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 14 Mar 2012 08:22:40 -0700

>>>> On 03/13/2012 02:02 PM, André Becker wrote:

[...]

>>> using the current ConfigUpdate mechanism in my bachelor thesis which
>>> is, unfortunately, written in german. But here a short summary of the
>>> attack:
>>> 
>>> via list). The ConfigUpdateReq, however, cannot be sent by reversing
>>> the via list, it is a totally new request with new transaction_id. This
>>> 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.
> 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.

Well, this is not explicitly said in the I-D, but a reasonable way to
implement RELOAD is to be sure that any new version of the configuration
document always also contains the old root certificate when a new one is
distributed.

> 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.
> 
> 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 

- -- 
Marc Petit-Huguenin