View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004625 | GNUnet | exit daemon | public | 2016-08-23 21:22 | 2019-03-22 00:06 |
| Reporter | lynX | Assigned To | |||
| Priority | high | Severity | feature | Reproducibility | N/A |
| Status | confirmed | Resolution | open | ||
| Product Version | 0.11.0pre66 | ||||
| Summary | 0004625: reverse resolve exit IP numbers to PeerId or suitable .gnu name | ||||
| Description | For 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 Information | Update: This issue is blocking ongoing work to integrate gnunet-vpn/exit into operating systems! | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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 |
|
|
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… |
|
|
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. |
|
|
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. |
|
|
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). |
| 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 | |
| 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 | |
| 2019-03-21 22:48 | lynX | Note Edited: 0014231 | |
| 2019-03-21 22:51 | lynX | Note Edited: 0014231 | |
| 2019-03-21 23:51 | lynX | Note Added: 0014233 | |
| 2019-03-21 23:51 | lynX | Note Edited: 0014233 | |
| 2019-03-22 00:01 | lynX | Note Edited: 0014233 | |
| 2019-03-22 00:06 | lynX | Note Edited: 0014233 |
