View Issue Details

IDProjectCategoryView StatusLast Update
0004625GNUnetexit daemonpublic2019-03-22 00:06
ReporterlynXAssigned To 
PriorityhighSeverityfeatureReproducibilityN/A
Status confirmedResolutionopen 
Product Version0.11.0pre66 
Target VersionFixed in Version 
Summary0004625: reverse resolve exit IP numbers to PeerId or suitable .gnu name
DescriptionFor many kinds of applications we need to authenticate incoming connections as coming from a certain person or at least from a certain peer. The exit daemon is currently not providing a way to find out who is calling. Resolving the virtual IP number would be the most backward compatible method. Best if it resolves to the same "hostname" as the matching outgoing <nickname>.gnu, or even uses the same virtual IP as an outgoing VPN tunnel would use.
Additional InformationUpdate: This issue is blocking ongoing work to integrate gnunet-vpn/exit into operating systems!
TagsNo tags attached.

Activities

Christian Grothoff

2018-06-23 15:29

manager   ~0013054

To summarize extensive discussions at GNUnet Hacker Meeting, this will take:
1) deterministic allocation of IP addresses in exit range by PeerId AND CADET port.
2) change of exit daemon to exit service, with new APIs to (a) export mapping of allocated IP addresses to PeerID and CADET port (and eventually also dynamic adding/removing of exit maps)
3) new service that hijacks DNS reverse lookups in the exit range, mapping them to its own GNS zone where labels are mapped to VPN records with the information from (2), and the label.zone is returned for the reverse lookup.

lynX

2018-06-27 16:26

developer   ~0013088

Note to myself:

My idea of having the same virtual IP for in- and outgoing cadet/vpn circuits would only be possible if vpn and exit service are merged into the same process, thus allowing it to do multiple things on the same IPs. So for now we just plan for using the same virtual hostname (GNS), hoping that many existing internet applications will accept that as equivalent.

Examples of apps that would use this:

- ircd, *jabberd, psyced... interserver link-up should be possible, allowing to make federations and irc networks over gnunet or gatewayed into gnunet
- nntpd, allowing to make a "dark" usenet
- senf, a p2p internet implementation of bitnet's sendfile protocol
- sendmail/smtpd, although CG claims that can also be achieved with GNS MX

lynX

2018-06-27 22:55

developer   ~0013094

Non-federated use cases - doing access authorization simply by hostname.

- httpd: Want to make some resources available only to certain people?
         Simply allow directory access for <name>.gnu or whatever GNS.
- ftpd: Same.
- lpd: Allow certain gnunet peers to print on your printer.
- rshd: Allow certain gnunet peers to execute a shell login (without ssh overhead, and without having to understand & edit gnunet.conf).
- murmur: Invite-only mumble server.
- etc…

lynX

2019-03-21 15:08

developer   ~0014231

Last edited: 2019-03-21 22:51

View 4 revisions

I'm upgrading this from "low" to "high" as it is impeding most of the useful use of GNUnet for most people. Once this issue is solved and GNUnet operates correctly on the CADET layer we can expect an explosion in popularity of the entire project. Also, developers are repeatedly tempted to implement native gnunet-only versions of standard applications which is a lot less efficient: we end up implementing the same things dozens of times and still do not make use of all the plethora of established software that could be delivered by the OS in a works-over-gnunet-by-default manner…

Let's pick rsh/rcmd/rexec/rlogin as an example: the problem with running rsh over gnunet-vpn currently is that the receiving side doesn't see who's calling.. so rshd can either allow everybody in (madness) or nobody (sad). when rshd does the lookup of the incoming ip number it should see myboss.gnu and from the .rhosts file know that myboss.gnu is always trustworthy. This way rshd or any other traditional pre-encryption networking application doesn't need a line of changed code: it would work over GNUnet naturally. We fix GNUnet to act like a safe Internet. We don't need to change Internet applications to make them work with GNUnet.

lynX

2019-03-21 15:14

developer   ~0014232

The greatest problem of the current Internet is the lack of DISINTERMEDIATION. When people want to talk they need a chat service. When they want to share files they need a file transfer service. This feature would solve this fundamental problem: Once people have added a person to their GNS they can immediately exchange files, chat and other functions *directly* with only the GNUnet in the middle. We can produce an OS distribution where these things work OUT-OF-THE-BOX. All it needs is an easy procedure for making "friendship". That's why this apparently minor feature request is actually the killer app that is keeping GNUnet from being of any relevance to average people.

lynX

2019-03-21 23:51

developer   ~0014233

Last edited: 2019-03-22 00:06

View 4 revisions

Actually I'm afraid what CG says above will not be enough: Some apps really need to have the same IP address going in and out. They won't act the way we want them if the identity of the peer only exists in form of the hostname. Therefore what we need to do is different:

1) merge exit daemon into vpn service so that the same process is in charge of all virtual IP numbers, no matter if they are being used for incoming, outgoing traffic or both;
2) same deterministic (long-term reliable) allocation of IP addresses per PeerId so that if an application stores the IP address of a person's peer in its data, it will always be correct and valid;
3) mapping of CADET ports to predictable (outgoing) or random (incoming) port numbers;
4) integration into DNS such that virtual IP numbers of peers resolve back to gnsnickname.gnu, making DNS support symmetric (bidirectional).

Issue History

Date Modified Username Field Change
2016-08-23 21:22 lynX New Issue
2018-06-13 14:22 lynX Assigned To => Christian Grothoff
2018-06-13 14:22 lynX Priority high => immediate
2018-06-13 14:22 lynX Severity feature => block
2018-06-13 14:22 lynX Status new => confirmed
2018-06-13 14:22 lynX Additional Information Updated View Revisions
2018-06-13 14:22 lynX Reproducibility have not tried => always
2018-06-23 15:29 Christian Grothoff Note Added: 0013054
2018-06-27 16:26 lynX Note Added: 0013088
2018-06-27 21:51 Christian Grothoff Assigned To Christian Grothoff =>
2018-06-27 21:51 Christian Grothoff Priority immediate => low
2018-06-27 21:51 Christian Grothoff Severity block => feature
2018-06-27 21:51 Christian Grothoff Reproducibility always => N/A
2018-06-27 21:51 Christian Grothoff Product Version => 0.11.0pre66
2018-06-27 22:55 lynX Note Added: 0013094
2019-03-21 15:08 lynX Priority low => high
2019-03-21 15:08 lynX Note Added: 0014231
2019-03-21 15:14 lynX Note Added: 0014232
2019-03-21 15:26 lynX Note Edited: 0014231 View Revisions
2019-03-21 22:48 lynX Note Edited: 0014231 View Revisions
2019-03-21 22:51 lynX Note Edited: 0014231 View Revisions
2019-03-21 23:51 lynX Note Added: 0014233
2019-03-21 23:51 lynX Note Edited: 0014233 View Revisions
2019-03-22 00:01 lynX Note Edited: 0014233 View Revisions
2019-03-22 00:06 lynX Note Edited: 0014233 View Revisions