commit 088b81be96febdc094c985aba76458989fa68e23
parent 4e0e7fc02b98d29d88bcb12ef6c3c84b8f1177e6
Author: Julius Bünger <buenger@mytum.de>
Date: Wed, 28 Feb 2024 16:02:03 +0100
cong: start incorporating notes from last meeting
Diffstat:
1 file changed, 188 insertions(+), 3 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -67,7 +67,45 @@ places can be easily tracked by everyone just by recording the different
addresses that are tied to that peer id over time.
..
- TODO how much info can be gained by that? all an observing peer sees is
+ TODO why does this prevent tracking?
+ - tracking hellos of peer: visible
+ - reverse mapping (address to peer?) not possible - there's no functionality
+ for that
+
+.. _Attacker-Model:
+
+Attacker Model
+""""""""""""""
+An attacker observes the hellos (containing ip addresses) published under a
+peer id and is thus capable of tracking locations and thus obtaining a movement
+profile of this peer.
+
+With the proposed changes to the peer id an attacker can only see a peer id and
+its connected set of addresses. A movement profile can not be obtained in the
+previous way.
+
+Tracking of addresses/locations might still be possible in the scenario that a
+mobile client uses mobile broadband and wifi uplinks and uses them in an
+'overlapping' manner. (Switching on mobile broadband before leaving the range
+of a wifi hotspot.) The overlap can be used to link the 'before' and 'after'
+address and - in extreme scenarios - obtain the full movement profile again.
+Note that this does not work on all, not all the time and requires work for the
+correlation.
+
+A way to circumvent this tracking mechanism would be for an attacker to exploit
+the means for consistently connect to the same peer.
+For example gns. With the knowledge of the gns entry, its peer ids and thus its
+addresses can be fully tracked.
+..
+ TODO explain that this limits the attack, is all we can do on this level and
+ that onion routing/mix networking is supposed to circumvent this
+
+..
+ TODO how much info can be gained by that? all an observing peer sees is the
+ ip addresses. how much can this tell?
+ - mobile provider (implicit: mobile connection)
+ - internet provider - home, company, public, ...
+ - region (country, city, building, ...)
.. _Implications:
@@ -77,6 +115,7 @@ Implications
Here we spell out the implications for different parts of the framework. This
should help get a grasp of the implications of the change.
+.. TODO poor phrasing?
.. _DHT:
@@ -97,7 +136,14 @@ When peer ids stop to be unique over time, the framework is in lack of a
globally unique identifier. Higher layers may rely (have reliede) on the
uniqueness of the ids. This means gnunet has to use other means for this
purpose. The Reconnects_ section below is concerned with the specific impact on
-reconnects for different higher-layer services.
+reconnects for different higher-layer services. In general gns/identity offers
+this functionality.
+
+As peer ids cease to be unique over time, this might be a good point to review
+the scope of its and other elements' usage and terminology. (See
+Open_Design_Questions_)
+
+FIXME This section overlaps in scope with the next section.
.. _Reconnects:
@@ -131,6 +177,9 @@ TODO lookup rst lists!
TODO: question: is gns needed for a reconnect? couldn't the peer with the new
id simply 'call back' the other peer?
+See Open_Design_Questions_ for thoughts on good designs to handle address
+changes more smoothly.
+
..
- disconnects -> cadet
- revocation (directly connected neighbor, don't use routing, only
@@ -142,6 +191,15 @@ id simply 'call back' the other peer?
- conversation
+.. _Messenger:
+
+Messenger
+"""""""""
+
+The current implementation of messenger heavily relies on a globally unique
+peer id. The change requires messenger to account for peer id changes.
+
+
.. _Details-on-how:
Details on how
@@ -151,6 +209,7 @@ Details on how
- adress bundle (transport communicators implement decision?)
- how adresses are generated:
- sort, hash, derive peer id from hash
+ - signaling functionality (signal pid change to higher layers)
.. _Open-questions:
@@ -164,9 +223,27 @@ Open questions
Core's Ownership of Peer IDs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+When the peer id was static, all parts of gnunet had a simple way to interface
+with it. Once it becomes dynamic, it makes a lot of sense that a single part
+takes control/responsibility for it. Core is the most suitable layer for this.
+
+..
+ TODO why is it?
+
+
+.. _Implications:
+
Implications
^^^^^^^^^^^^
+Core needs to take ownership. It is responsible for generating, changing and
+publishing the peer id to the peersore (?). As other parts still rely on the
+usage of the peer id, it needs to provide an interface for those systems: It
+needs to inform about current id, inform about changes and sign data on
+request. To be gentle on the ipc, it should not sign big amounts of data - if
+applicable rather hashes of data or such.
+
+
.. _Transport:
Transport
@@ -175,6 +252,15 @@ Transport
..
- transport creates and signs hello (w peer id)
+
+.. _Details-on-how:
+
+Details on how
+^^^^^^^^^^^^^^
+
+..
+ signing functionality as api call (only sign hashes? - load on ipc)
+
..
Notes from the meeting:
- higher-layer roll-over
@@ -216,4 +302,103 @@ libp2p Underlay
TODO
..
- TODO Look at the project milestones to check coverage
+ - addresses from underlay in string representation go into core
+ - libp2p can't handle hellos/peerstore
+ - address signaling btw. transport and core
+ - hellos should be handled by core
+
+
+.. _Open_Design_Questions:
+
+Open Design Questions
+---------------------
+
+ - terminology of peer ids
+ - scope of peer ids and other such elements (gns/identity, ...)
+ - smooth handling of address/pid change possible?/signaling change of address
+ - should be possible at least when we gain one address
+ - construct that allows an additional peer id that is pre-computed (not
+ based on addresses) and announced ahead of address change?
+ - other terminology: provide tracking capability selectively
+ - use peer ids as long as there are open connections with them?
+ - resolve gns to pid on lower layer? (cadet or even core)
+ - convenience api: cadet connection to domain name
+ - not one id per set of addresses, but per single address?
+ - multiple peer ids per peer
+ - tracking even harder
+
+
+.. _Requirements:
+
+Requirements
+------------
+
+In the discussions we seem to have lost partial oversight over things.
+In this section we figure out the requirements for core (and possibly other
+components) it's mechanisms.
+
+TODO: what requirements exactly did we want to document here?
+
+
+.. _Use-Cases-and-Scenarios:
+
+Use Cases and Scenarios
+-----------------------
+
+This section is supposed to help with the understanding of the use of elements
+and structures by imagined examples.
+
+
+.. _Peer-ID:
+
+Peer ID
+^^^^^^^
+
+The peer id has been used throughout gnunet as a very convenient means for many
+purposes. Here we collect the intended purposes and use cases and also point
+out some uses for which it was not intended and point to other means to achieve
+it.
+
+..
+ TODO
+ - e2e connectivity?
+ - analogy: ip address
+ - address change: shutdown vs. standby vs. ...
+
+
+.. _GNS:
+
+GNS
+^^^
+
+TODO
+
+..
+ - identify on user level
+ - vpn record: globally unique id
+
+
+.. _CADET:
+
+CADET
+^^^^^
+
+TODO
+
+
+.. _Messenger:
+
+Messenger
+^^^^^^^^^
+
+TODO
+
+..
+ TODO 'tracking capability' via gns: shared secret
+ - this a good place?
+ - understand how that would work
+ - hide multiple devices behind one identity
+
+
+..
+ TODO Overall: Look at the project milestones to check coverage
