[lsd0003] branch master updated: Added active decoing to sc

[gnunet]

This is an automated email from the git hooks/post-receive script.

elias-summermatter pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new 45d6653  Added active decoing to sc
45d6653 is described below

commit 45d66538c0ff998f4ed580ce889a2580849a67bf
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Tue Feb 23 10:53:43 2021 +0100

    Added active decoing to sc
---
 draft-summermatter-set-union.xml | 88 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 81 insertions(+), 7 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index a18fbc6..f42e152 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -1849,6 +1849,15 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
             <!-- 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.
+            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.
@@ -1856,6 +1865,7 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
         </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>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.