gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0003] branch master updated: Added some more sc


From: gnunet
Subject: [lsd0003] branch master updated: Added some more sc
Date: Sun, 28 Feb 2021 21:30:55 +0100

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 79c94b3  Added some more sc
79c94b3 is described below

commit 79c94b3f3ce9ce7b052a1d99086371e49ab52e4c
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Sun Feb 28 21:29:33 2021 +0100

    Added some more sc
---
 draft-summermatter-set-union.xml | 54 ++++++++++++++++++++++++----------------
 1 file changed, 33 insertions(+), 21 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 846a24b..9758292 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2041,8 +2041,8 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
             <section anchor="security_states_finish_closing" numbered="true" 
toc="default">
                 <name>Finish Closing</name>
                 <t>
-                    In case not all sent demands or inquiries have ben 
answered in time the operation
-                    has failed and MUST be terminated.
+                    In case not all sent demands or inquiries have ben 
answered in time a pre defined
+                    timeout the operation has failed and MUST be terminated.
                 </t>
                 <!-- FIXME: In state diagram in finish closing only Elements 
can be received. What happens if i receive an offer? -->
                 <t>Security considerations for received messages:</t>
@@ -2065,16 +2065,20 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                 <dl>
                     <dt><xref target="messages_se" format="title" /></dt>
                     <dd>
-                        In case the Strata Estimator does not decoded the
+                        In case the Strata Estimator does not decode the
                         operation MUST be terminated to prevent to get to a 
unresolvable state.
                         <!-- IMPLEMENT: If in expect SE state the strata 
estimator does not decode terminate the operation -->
-                        Also a check should be in place that prevents the set 
difference to be
-                        unpassable large, in case its to large the operation 
MUST be terminated.
+                        The set difference calculated from the strata 
estimator needs to be plausible,
+                        to ensure this multiple factors need to be considered: 
The absolute plausible maximum of
+                        elements in a set which has to be predefined according
+                        to the use case and the maximal plausible element 
increase since the last
+                        successful set reconciliation which should be either 
predefined or can be calculated
+                        with the gaussian distribution function over all 
passed set reconciliations.
                         <!-- IMPLEMENT: Terminate if in check expect se state 
for a max size difference is exceeded -->
                     </dd>
                     <dd>
                         In case of compressed strata estimators the 
decompression algorithm has to
-                        be protected against
+                        be protected against decompression memory corruption 
(memory overflow).
                     </dd>
                 </dl>
             </section>
@@ -2084,16 +2088,17 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                 <dl>
                     <dt><xref target="messages_full_element" format="title" 
/></dt>
                     <dd>
-                        Besides formally validate the received element its 
good to do a
-                        plausibility check and count the received valid 
elements and compare
-                        it to the calculated set difference. In case the 
difference in the count of the received
-                        elements is unportable high the operation MUST be 
terminated, because the other peer
-                        could try to waste our bandwidth.
+                        The peer in <strong>Full Receiving</strong> state 
needs to check
+                        that exactly the number of elements is received from 
the remote peer as
+                        he initially committed too. If the remote peer 
transmits less or
+                        more elements the operation MUST be terminated.
                     </dd>
                     <dt><xref target="messages_full_done" format="title" 
/></dt>
                     <dd>
-                        After the full done message is received no <xref 
target="messages_full_element" format="title" />
-                        message should be received.
+                        When the full done message is received from the remote 
peer all
+                        elements that the remote peer has committed to needs 
to be received
+                        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? -->
                     </dd>
                 </dl>
@@ -2104,18 +2109,25 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                 <dl>
                     <dt><xref target="messages_ibf" format="title" /></dt>
                     <dd>
-                        In case an IBF message is received by the peer a 
active/passive role change
-                        is initiated if the max role change threshold is not 
reached. In this case all
-                        open demands and offers are waited to be fulfilled to 
prevent retransmission before switching
-                        to other state.
+                        In case an IBF message is received by the peer a 
active/passive role switch
+                        is initiated by the active decoding remote peer. In 
this instance the peer should
+                        wait for all open offers and demands to be fulfilled 
to prevent
+                        retransmission before switching into active decoding 
operation mode.
+                        A switch into active decoding mode should only be 
permitted for
+                        a predefined number of times as described in the top 
section
+                        of the security section.
                         <!-- IMPLEMENT: What does happen here in the code? -->
                     </dd>
                     <dt><xref target="messages_inquiry" format="title" /></dt>
                     <dd>
-                        In case an inquiry message is received it should be 
ensured
-                        that an inquiry for an element is just answered once, 
for this
-                        there needs to be a list with all requested inquiries 
to prevent
-                        an attacker from a replay attack.
+                        A check needs to be in place that prevents receiving a 
inquiry
+                        for an element multiple times or more inquiries than 
are plausible.
+                        The amount of inquiries that is plausible can be 
estimated by considering
+                        known values as the remote set size, the local set 
size, the
+                        predefined absolute maximum of elements in the set 
which is defined
+                        by real world limitations.
+                        To implement this restrictions a list with all 
received inquiries
+                        should be stored and new inquiries should be checked 
against.
                     </dd>
                     <dt><xref target="messages_demand" format="title" /></dt>
                     <dd>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]