[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Added active decoing to sc
From: |
gnunet |
Subject: |
[lsd0003] branch master updated: Added active decoing to sc |
Date: |
Tue, 23 Feb 2021 10:55:01 +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 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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0003] branch master updated: Added active decoing to sc,
gnunet <=