commit e3781d00ce1a0c6608ed9eaa9af7845288834930
parent 79c94b3f3ce9ce7b052a1d99086371e49ab52e4c
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Sun, 28 Feb 2021 21:48:41 +0100
Added some more sc
Diffstat:
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -1838,47 +1838,40 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
<name>Security Considerations</name>
<t>
- In this protocol the definition of security is different then in other
- protocols. This peer to peer protocol should primarily prevent an attacker from
- wasting cpu and network resources.
+ The security considerations in this document focus mainly on the security
+ goal of availability, the primary goal of the protocol is prevent an attacker from
+ wasting cpu and network resources of the attacked peer.
</t>
<t>
- To prevent Denial of Service attacks its vital to check that any other peer can only try to
- reconcile a set once in a pre defined time span. If necessary to enhance reliability and to allow
+ To prevent denial of service attacks its vital to check that peers can only
+ reconcile a set once in a pre defined time span. This is a predefined values and need
+ to be adapted on per use basis. To enhance reliability and to allow
failures in the protocol its possible to introduce a threshold for max failed reconciliation
- ties in given time. The optimal values for these thresholds depend on the use case.
+ ties.
<!-- IMPLEMENT: How to implement? IP? Other construct? -->
</t>
<t>
The formal format of all messages needs to be properly validated, this is important to prevent many
attacks on the code. The application data should be validated by the application using
the protocol not by the implementation of the protocol.
- In case the format validation fails the set operation should be terminated.
+ In case the format validation fails the set operation MUST be terminated.
<!-- IMPLEMENT: Are all messages checked for formal valid format -->
</t>
<t>
- To prevent the protocol to loop for ever between active and passive decoding a
- limitation for active/passive switches in needed. This can be implemented by
- a simple counter which terminates the connection after a predefined count of switches.
+ To prevent an attacker from sending a peer into a endless loop between active and passive decoding a
+ limitation for active/passive roll switches in required. This can be implemented by
+ a simple counter which terminates the operation after a predefined count of switches.
The count of switches needs to be defined as such that its very undroppable that more
- switches are required.
+ switches are required an the malicious intend of the other peer can be assumed.
<!-- IMPLEMENT: This counter -->
</t>
<t>
+ <!--- SHOULD BE HANDLED BY UNDERLYING PROTOCOL BUT HOW IS IT HANDLED? -->
Its important to close and purge connections after a given timeout
to prevent draining attacks.
- <!-- IMPLEMENT: How ist this handeld right now? -->
- </t>
-
- <t>
- In the last protocol message (<xref target="messages_done" format="title" /> or
- <xref target="messages_full_done" format="title" /> ) a 512-bit hash of
- the complete synchronized set has to be transmitted to the other peer.
- Sending the hash ensures that both sets are truly identical, if
- they differ a resynchronisation is required. The count of possible
- resynchronisation MUST be limited to prevent resource exhaustion attacks.
+ <!-- IMPLEMENT: How ist this handheld right now? -->
</t>
@@ -1955,6 +1948,10 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
When receiving the full done message its important to check that
not less elements are received as the other peer has committed to
send.
+ The 512-bit hash of the complete reconciled set contained in
+ the full done message is required to ensures that both sets are truly identical. If
+ the sets differ a resynchronisation is required. The count of possible
+ resynchronisation MUST be limited to prevent resource exhaustion attacks.
<!-- IMPLEMENT: Is this check already implemented?-->
</dd>
</dl>
@@ -2035,6 +2032,10 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
the decoding of the IBF is finished or all open offers and demands
have been answered the operation MUST be terminated.
<!-- IMPLEMENT: Check that in active decoding no done message is received before ibf has been decoded-->
+ The 512-bit hash of the complete reconciled set contained in
+ the done message is required to ensures that both sets are truly identical. If
+ the sets differ a resynchronisation is required. The count of possible
+ resynchronisation MUST be limited to prevent resource exhaustion attacks.
</dd>
</dl>
</section>
@@ -2100,6 +2101,10 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
otherwise the operation MUST be terminated. After receiving the
full done message no future elements should be accepted.
<!-- FIXME: Check that after full done in full receiving no elements can be received anymore! Additional state? -->
+ The 512-bit hash of the complete reconciled set contained in
+ the full done message is required to ensures that both sets are truly identical. If
+ the sets differ a resynchronisation is required. The count of possible
+ resynchronisation MUST be limited to prevent resource exhaustion attacks.
</dd>
</dl>
</section>
