commit 45d66538c0ff998f4ed580ce889a2580849a67bf
parent 15b3b8f4b371f6c5488528276da2b66127d14358
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Tue, 23 Feb 2021 10:53:43 +0100
Added active decoing to sc
Diffstat:
1 file changed, 81 insertions(+), 7 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -1850,12 +1850,22 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
</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.
+ The count of switches needs to be defined as such that its very undroppable that more
+ switches are required.
+ <!-- IMPLEMENT: This counter -->
+ </t>
+
+ <t>
Its important to close and purge connections after a given timeout
to prevent draining attacks.
<!-- IMPLEMENT: How ist this handeld right now? -->
</t>
+
<section anchor="security_states" numbered="true" toc="default">
<name>States</name>
@@ -1896,22 +1906,86 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
<section anchor="security_states_full_sending" numbered="true" toc="default">
<name>Full Sending</name>
- <t>
- Bla Bla
- </t>
+ <t>Security considerations for received messages:</t>
+ <dl>
+ <dt><xref target="messages_full_element" format="title" /></dt>
+ <dd>
+ When receiving full elements there needs to be checked that not
+ more elements are received from the other peer that plausibly can
+ be in the set.
+ <!-- IMPLEMENT: Is this check already implemented?-->
+ </dd>
+ <dt><xref target="messages_full_done" format="title" /></dt>
+ <dd>
+ Beside the formal message validity check no future check is required.
+ </dd>
+ </dl>
</section>
<section anchor="security_states_expecting_ibf_last" numbered="true" toc="default">
<name>Expecting IBF Last</name>
- <t>
- Bla Bla
- </t>
+ <t>Security considerations for received messages:</t>
+ <dl>
+ <dt><xref target="messages_ibf" format="title" /></dt>
+ <dd>
+ When receiving multiple IBFs its important to check that the other
+ peer can only send as many IBFs as expected, otherwise its possible
+ for an attacker to keep a connection open for ever.
+ </dd>
+ </dl>
</section>
<section anchor="security_states_active_decoding" numbered="true" toc="default">
<name>Active Decoding</name>
<t>
- Bla Bla
+ In the Active Decoding state its important to prevent an attacker from
+ generating and passing unlimited amount of IBF that do not decode or
+ even worse generate an IBF that decoding sends the peers in an endless loop.
+ To prevent an endless loop in decoding a loop detection should be implemented
+ the simplest solution would be to prevent decoding of more than a given amount of elements,
+ a little more robust solution is be to implement a algorithm to detect a loop by
+ analyzing past partially decoded IBFs.
+ <!-- IMPLEMENT: Implement an algo that detects loops in IBF decoding -->
</t>
+
+ <t>Security considerations for received messages:</t>
+ <dl>
+ <dt><xref target="messages_offer" format="title" /></dt>
+ <dd>
+ If an offer for an element that never has been requested by
+ an inquiry or the demand has already been send the offer MUST be discarded.
+ This requirement can be fulfilled by a simple table that keeps track of all send inquiries
+ and if they already have been answered.
+ <!-- IMPLEMENT: Check to keep track of all send Inquiries -->
+ </dd>
+ <dt><xref target="messages_elements" format="title" /></dt>
+ <dd>
+ If an element that never has been requested by
+ a demand or is already part of the set it MUST be discarded.
+ This requirement can be fulfilled by a simple table that keeps track
+ of all send demands and checking for every received elements that
+ its not already part of the set.
+ <!-- IMPLEMENT: Check to keep track of all send demands -->
+ If an invalid element is received the operation has failed and the
+ MUST be terminated.
+ <!-- IMPLEMENT: Termination if invalid element si revived -->
+ </dd>
+ <dt><xref target="messages_demand" format="title" /></dt>
+ <dd>
+ For every received demand a offer has to be send in advance. If an demand
+ for an element is received that never has been offered or already has
+ been answered the demand MUST be discarded. Its required to implement
+ a list which keeps track of all send and answered offers.
+
+ <!-- IMPLEMENT: Check to keep track of all send demands -->
+ </dd>
+ <dt><xref target="messages_done" format="title" /></dt>
+ <dd>
+ The done message SHOULD only be received if the IBF has been finished
+ decoding and all offers have been sent. If a done message is resived
+ before the operation MUST be terminated.
+ <!-- IMPLEMENT: Check that in active decoding no done message is received before ibf has been decoded-->
+ </dd>
+ </dl>
</section>
<section anchor="security_states_finish_closing" numbered="true" toc="default">
<name>Finish Closing</name>
