2018-08-21 15:36 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004625GNUnetexit daemonpublic2018-06-27 22:55
ReporterlynX 
Assigned To 
PrioritylowSeverityfeatureReproducibilityN/A
StatusconfirmedResolutionopen 
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.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]
+Relationships

-Notes

~0013054

Christian Grothoff (manager)

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.

~0013088

lynX (developer)

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

~0013094

lynX (developer)

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…
+Notes

-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
+Issue History