.. _CONG-Subsystem-Dev:

.. index::
   double: CONG; subsystem

CONG
====

CONG (COre Next Generation) is the name of the project redesigns the CORE
service. Here we document the design decisions and parts that are about to
change.


Design goals
------------

TODO

Key exchange
------------

While we are at it we may as well improve the key exchange.
Currently, we are using our own ECDHE key exchange that derives
2x2 keys.
2 keys for each direction (sending/receiving).
Each direction uses two 256-bit symmetric encryption keys derived through the ECDH exchange.
Each payload is encrypted using AES(kA, Twofish(kB, payload)) both in CFB mode (!).

For CONG, we should double-check the security of your ECDHE construction and then
potentially move away from AES/Twofish, possible towards ChaCha20 or XSalsa20 (Needs discussion).

Proposal:

  * Use X25519 for the KX with our Ed25519 keys: https://doc.libsodium.org/advanced/ed25519-curve25519
  * Use XSalsa20 and kTx,kRx := KDF(X25519(),senderPK,receiverPK) for symmetric encryption

.. _Peer-IDs:

Peer IDs
--------

Peer ids stop to be unique for the lifetime of a peer, but change each time a
peer's addresses change. This includes gaining or losing an address.

It is important to note that this design choice only increases the cost of
network location tracking and does not fully prevent it. For this feature onion
routing on top of CADET is envisioned.

At this point it seems like one has to weigh privacy versus performance when it
comes to this design decision.

.. _Reasoning:

Reasoning
^^^^^^^^^

..
  	 - why this decision (and not others?)
  		 - (scenarios to understand whether it makes sense)

This change was introduced in order to stop tracking of more mobile peers.
For example a more mobile peer (laptop) that logs into the network at different
places can be easily tracked by everyone just by recording the different
addresses that are tied to that peer id over time.

..
  TODO
   - why does this prevent tracking? (partially answered in the attacker
     model section below
   - tracking hellos of peer: visible
   - reverse mapping (address to peer?) not possible - there's no functionality
     for that
   - gaining/losing as criterium to change peer id makes sense?


.. _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:

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:

DHT
"""

The DHT uses the peer id such that it determines which buckets a peer is
responsible for. So each time the peer id changes, the peer becomes responsible
for different data.


.. _Scope-of-Peer-ID-for-higher-Layers:

Scope of Peer ID for higher Layers
""""""""""""""""""""""""""""""""""

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. 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:

Reconnects
""""""""""

When addresses (and with those the peer id) of a peer change, all core
connections need to be torn down and with them all higher-layer connections.
This affects the layers above CADET as follows:

TODO lookup rst lists!

 - Revocation: Is not really affected as it is only connected to direct CADET
   neighbors and makes no use of CADET's routing, only of its flow and
   congestion control.
 - File sharing: Only the non-anonymous filesharing uses CADET connections.
   This is not significantly affected by a reconnect as it only looks up peer
   and port in the DHT, so in the meanwhile it's looking for other peers. TODO
   this is very unclear to me!
 - Messenger: All CADET connections would break and the peer might assume that
   all previously connected peers went offline. So it would require a
   mechanism to reconnect to peers with a known peer identity which offer
   routing capability (open port via CADET to connect to). In case the peer
   itself is providing such capability, it would help to know about peer ID
   changes ahead of time to communicate a switch between IDs to other peers.
   For other reconnections via GNS lookups are required.
 - Conversation: The call would be interrupted until the new peer id of the
   other has been found via GNS.

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
       congestion/flow control)
     - file sharing (non-anonymous): lookup peer and cadet port in dht
       (continue looking for other peers meanwhile)
     - messenging/messenger: not too bad, continue the lookup of the peer
       (gns)
     - 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
^^^^^^^^^^^^^^

..
   - 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:

Open questions
^^^^^^^^^^^^^^


.. _Core's-Ownership-of-Peer-IDs:

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
"""""""""

..
   - transport creates and signs hello (w peer id)
   - all other parts of gnunet that simply read the peer id from a file and
     assume its continuity


.. _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
  	 - problem in practice 'phone call not interrupted by change of
  	   location'
  	 - solved by gns entries? and re-connect?
  	 - cadet search for peer id - search in dht and via gns
  	 - caching-problem for gns
  	 - no signaling for roll-over
  	 - estimated reconnect within 15 minutes
  	 - change of address/peerid results in unclear state (down? lost
  	   connection, ....?)
  	 - cadet needs to regularily check gns entries
   - how signal the change of addresses?
  	 - do we signal trear-down?
  	 - scenario address change in internet cafe?
  	 - choice between privacy and connectivity
  	 - sense of changing ids for cadet?
  		 - -> rendez-vous peer (more stable)
  	 - tracking via gns?
  		 - only for people who are connected/known (tracking might be
  		   ok for this)
  			 - requires pir for gns
  		 - tracking impossible/hard for others


.. _Protocol_002dVersioning:

Protocol-Versioning
-------------------

TODO

.. _libp2p-Underlay:

libp2p Underlay
---------------

TODO

..
  - 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
---------------------

In this section we list design question that are not decided on, yet.

..
 - scope of peer ids and other such elements (gns/identity, ...)
 - terminology of peer ids
 - 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


.. _Peer-ID-changes-and-connectivity:

Peer ID changes and connectivity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

..
 - 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?

In case a peer's addresses change, it gets a new peer id and therefor needs to
reconnect. The challenge is to reconnect as fast as possible. The main problem
is that a peer cannot know its next peer id in all cases. Connections that have
dedicated peers at its endpoints will probably look up the new peer id of the
other peer in a higher-layer service, most probably gns.

In the case in which a peer just gains an additional address, that peer can
pre-calculate its next peer id, signal it via still open connections on the old
peer id and finally switch to using the new peer id.

Other more evolved ideas include using multiple peer ids per peer: Either an
additional address-independent peer id that will 'survive' address changes and
serve as means to link to the address-based peer id after a change. It would
just be sent to connected peers and reset once all connections have been
re-established. Alternatively (maybe in addition) peers could use multiple
address-based peer ids - one per address. Thus some peer ids might stay
unchanged while others go offline.

Another idea to address this challenge is to keep peer ids in use on
connections which are still in use, but don't publish those ids anymore.

Terminology-wise we might add another perspective and say that we selectively
and deliberately provide tracking capability to peers which we want to stay in
touch with.


.. _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
