[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Fixed some FIXMEs and added some commen
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: Fixed some FIXMEs and added some comments to discuss |
|
Date: |
Tue, 15 Jun 2021 14:18:40 +0200 |
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 05c485f Fixed some FIXMEs and added some comments to discuss
05c485f is described below
commit 05c485fc93d79c5474a0fdae741b21f400d9dcd5
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Tue Jun 15 14:15:51 2021 +0200
Fixed some FIXMEs and added some comments to discuss
---
draft-summermatter-set-union.xml | 74 ++++++++++++++++++++++++----------------
1 file changed, 45 insertions(+), 29 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 0467499..c2e154a 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -1168,7 +1168,8 @@ hashSum | 0x0101 | 0x5151 | 0x5050 |
0x0000 |
The first case is when one of the peers announces having an
empty set. This is announced by setting
the SETSIZE field in the <em><xref target="messages_se"
format="title" /></em> to 0.
<!-- FIXME: why not also do this if sending the elements is
about as
- expensive as sending the SE? Should be a simple
calculation. (thesis summermatter: future work) -->
+ expensive as sending the SE? Should be a simple
calculation. (thesis summermatter: future work) @Christian:
+ As discussed 14.06 we let this comment in here as it is
described in the thesis-->
The second case is if the application requests full
synchronisation explicitly.
This is useful for testing and MUST NOT be used in production.
</t>
@@ -2489,7 +2490,7 @@ FUNCTION END
is to be applied after the SE calculation to
the computed set size differences, resulting
in a hard cap on the set size difference estimate
- that is then actually used. -->
+ that is then actually used. @Christian: ???-->
</t>
</section>
@@ -2851,7 +2852,8 @@ END FUNCTION
send at the beginning of the operation.
<!-- FIXME: I don't see how the next sentence makes
sense. If we got a FULL_DONE,
and we still have differing sets, something is
broken and re-doing it hardly
- makes sense, right? -->
+ makes sense, right? @Christian im not sure about
that it could be that for example
+ the set size changes (from application or other
sync) while synchronisation is in progress....-->
If the sets differ, a resynchronisation is required.
The number of possible
resynchronisation MUST be limited, to prevent resource
exhaustion attacks.
</t>
@@ -2872,10 +2874,22 @@ END FUNCTION
exceeded, or if the size is implausible for the
given operation.
</t>
</dd>
+ <dt><xref target="messages_ibf_last" format="title" /></dt>
+ <dd>
+ <t>
+ When all <em><xref target="messages_ibf"
format="title" /></em> messages have
+ been received an <em><xref
target="messages_ibf_last" format="title" /></em> message
+ should conclude the transmission of the IBF and a
change to the <strong>Active Decoding</strong>
+ phase should be ensured.
+ </t>
+ </dd>
<!-- FIXME: we can also receive an IBF_LAST in this state,
here additional sanity checks, like that we have
received
all of the other fragments/parts of the IBF first and
- that the parameters are thus consistent apply. -->
+ that the parameters are thus consistent apply.
@Christian So we would have
+ to transmit the number of IBF slices that will be
transmitted first
+ to do this check right?
+ -->
</dl>
</section>
@@ -2888,10 +2902,12 @@ END FUNCTION
To prevent an endless loop in decoding, loop detection
MUST be implemented.
The simplest solution is to prevent decoding of more than
a given number of elements.
<!-- FIXME: this description is awkward. Needs to be
discussed.
- I think you also do not mean 'hashes' but 'element
IDs'. -->
+ I think you also do not mean 'hashes' but 'element
IDs'. @Christian just omit the details
+ i guess anybody can freely decide how to handle loops
its just important that e protection is
+ in place. Right?-->
A more robust solution is to implement a algorithm that
detects a loop by
analyzing past partially decoded IBFs. This can be achieved
- by saving the hash of all prior partly decoded IBFs hashes
in a hashmap and check
+ by saving the element IDs of all prior partly decoded IBFs
hashes in a hashmap and check
for every inserted hash, if it is already in the hashmap.
</t>
<t>
@@ -2899,12 +2915,14 @@ END FUNCTION
operation MUST be terminated.Furthermore, if the IBF
decoding successfully terminates and fewer elements were
decoded than plausible, the operation MUST also be
terminated.
- The upper and lower thresholds
- for the number of decoded elements can be calculated with
the peers set sizes
- and the other peer's committed set sizes from the
<strong>Expecting IBF</strong>
- state.
+ The upper thresholds for decoded elements from the IBF is
the
+ remote set size the other peer has committed too (Case if
the complete remote set is
+ new). The lower threshold for decoding element is the
absolute value of the difference
+ between the local and remote set size (Case the set
difference is only in the set of
+ a single peer). The other peer's committed set sizes
+ is transmitted in the the <strong>Expecting IBF</strong>
state.
<!-- FIXME: be more precise about how to calculate those
- bounds from those inputs. -->
+ bounds from those inputs. @Christan better? -->
</t>
<t>Security considerations for received messages:</t>
@@ -2948,15 +2966,15 @@ END FUNCTION
<t>
The <em><xref target="messages_done"
format="title" /></em> message is only received if the IBF has finished
decoding and all offers have been sent. If the
<em><xref target="messages_done" format="title" /></em> message is received
before
- the decoding of the IBF is finished or all open
offers and demands
+ the decoding of the IBF is finished or all open
demands
have been answered, the operation MUST be
terminated.
<!-- FIXME: it is legitimate to not respond to an
offer, right? Otherwise
we would not need demands; hence, the above
should only be
- for 'open demands', right? -->
+ for 'open demands', right? @Christian your
right corrected this one-->
If
the sets differ, a resynchronisation is required.
The number of possible
resynchronisation MUST be limited to prevent
resource exhaustion attacks.
- <!-- FIXME: again, how can this happen? Why should
we really allow this? -->
+ <!-- FIXME: again, how can this happen? Why should
we really allow this? @Christian same point above if set changes while we
synchronize-->
</t>
<t>
When a <em><xref target="messages_done"
format="title" /></em> message is received the
@@ -3004,14 +3022,6 @@ END FUNCTION
The set difference calculated from the strata
estimator needs to be plausible,
which means within the byzantine boundaries
described in section <xref
target="security_generic_functions_check_byzantine_boundaries" format="title"
/>.
</t>
- <t>
- <!-- FIXME: I do not think this kind of consideration
- belongs into an RFC... Besides, you can have
memory
- corruption at most steps of the algorithm if
the code is sufficiently
- careless... -->
- In case of compressed strata estimators the
unpacking algorithm needs to
- be protected against unpacking memory corruption
(memory overflow).
- </t>
</dd>
</dl>
</section>
@@ -3036,10 +3046,10 @@ END FUNCTION
elements received matches the number that the
remote peer
originally committed to transmitting,
otherwise the operation MUST be terminated.
- <!-- FIXME: this is redundant, already covered by
the new state, right? -->
+ <!-- FIXME: this is redundant, already covered by
the new state, right? @Christian: ??? State-->
After receiving the
<em><xref target="messages_full_done"
format="title" /></em> message, future elements MUST NOT be accepted.
- <!-- FIXME: again, how can this happen? Why should
we really allow this? -->
+ <!-- FIXME: again, how can this happen? Why should
we really allow this? @Christian Again set changes while sync ;-) -->
If
the sets differ, a resynchronisation is required.
The number of possible
resynchronisation MUST be limited to prevent
resource exhaustion attacks.
@@ -3061,10 +3071,8 @@ END FUNCTION
then the swap will no longer just add 0.5
RTT! I think
we MUST instead permit that an IBF decodes to
an element
that was offered/demanded (only in the
previous iteration?) and then
- simply SKIP that element ID! -->
- In this moment the peer MUST
- wait for all open offers and demands to be
fulfilled, to prevent
- retransmission before switching into active
decoding operation mode.
+ simply SKIP that element ID! @Christian oh i
missed this one. Yes, your right we dont do this!
+ -->
A switch into active decoding mode MUST only be
permitted for
a predefined number of times as described in <xref
target="security_generic_functions_active_passive_switches" format="default"/>
</t>
@@ -3074,9 +3082,17 @@ END FUNCTION
<t>
A check needs to be in place that prevents receiving
an inquiry
for an element multiple times or more inquiries than
are plausible.
+ The upper thresholds for sent/received inquiries is the
+ remote set size the other peer has committed too (Case
if the complete remote set is
+ new). The lower threshold for for sent/received
inquiries is the absolute value of the
+ set difference between the local and remote set size
+ (Case the set difference is only in the set of a
single peer).
+ The other peer's committed set sizes is transmitted in
the the <strong>Expecting IBF</strong> state.
+ Beware that it is possible to get key collisions and
an inquiry for the same key
+ can be transmitted multiple times, so the threshold
should take this into account.
<!-- FIXME: how again does one determine how many
inquiries are plausible?
Be precise! I can see several options (overall
set sizes, but also
- SE, or even IBF size). -->
+ SE, or even IBF size). @Christian I Added check
parameter-->
The sending and receiving of <em><xref
target="messages_inquiry" format="title" /></em> messages should
always be protected with an <xref
target="security_generic_functions_mfc" format="title" />
to secure the protocol against missing, duplicated,
out-of-order or unexpected messages.
--
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: Fixed some FIXMEs and added some comments to discuss,
gnunet <=