Ocat with Phantom/Tor/I2P, IPv6, protocols
grarpamp
cc'd to the following, before I received the google bounce:
ocat...@cypherpunk.at, magnus....@fortego.se]
Hi :) In case it has not been made before, this note introduces
Phantom to Ocat and various related issues. Certainly Tor and I2P
have been introduced earlier. I'm a user, not a project party.
I'm interested in Phantom's:
- Ability to transport all protocols over the IP layer it provides:
TCP/UDP/GRE/ICMP/etc ?
Primarily for implementation of possible DNS solutions for the
anonymous networks as is being discussed by various parties. And
in general for use by any given application.
- IPv6/AP addressing scheme.
For interoperation with the Ocat shim, other/future anonymous
networks, etc. Note particularly that Ocat selected for its use,
one private IPv6/48 for Tor and one for I2P. This leaves the host
OS and applications free to use normal split horizon routing and
DNS to route between anonymous networks and other public/private
networks including the normal internet.
FD60:DB4D:DDB5::/48 - I2P
FD87:D87E:EB43::/48 - Tor
<rfc4193>/48 within FC00::/7 - Phantom ?
http://iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
http://www.iana.org/go/rfc4193
Are there other anonymous networks, deployed or in development,
that provide an IP layer as do Phantom or the Ocat shim?
If so, various parties should make sure they are all communicating
regarding at least IP addressing concerns!
As IPv6 is obviously the only way to go for internal addressing,
I left mention of IPv4 out of this note entirely.
Leslie P. Polzer
grarpamp wrote:
> I'm interested in Phantom's:
>
> - Ability to transport all protocols over the IP layer it provides:
> TCP/UDP/GRE/ICMP/etc ?
Phantom is not tied to a specific transport layer protocol.
The goal here is a tunnel device driver that works at the IP layer
and transparently moves traffic through Phantom paths.
Leslie
Magnus Bråding
any driver level code for this, but rather just application level
(userland) hooks).
Regards,
Magnus
> --
>
> You received this message because you are subscribed to the Google Groups "Phantom Protocol" group.
> To post to this group, send email to phantom-...@googlegroups.com.
> To unsubscribe from this group, send email to phantom-protoc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/phantom-protocol?hl=en.
>
grarpamp
> > - Ability to transport all protocols over the IP layer it provides:
> > TCP/UDP/GRE/ICMP/etc ?
> Phantom is not tied to a specific transport layer protocol.
Maybe you mean 'phantom is not limited to transporting only a specific
protocol over IP'.
ie: Tor only transports TCP natively. I2P doesn't really transport
any, TCP sortof.
Ocat provides an IPv6 address and route via a tunnel device by
interfacing with Tor/I2P. Thus any app/protocol can now run over those
networks.
> The goal here is a tunnel device driver that works at the IP layer
> and transparently moves traffic through Phantom paths.
A new driver? Why not use the existing tunnel drivers provided by the os?
http://www.cypherpunk.at/onioncat/
http://www.cypherpunk.at/onioncat/wiki/Installation
Magnus Bråding
>> and transparently moves traffic through Phantom paths.
>
> A new driver? Why not use the existing tunnel drivers provided by
> the os?
As mentioned in my other reply, not really a driver, but rather the most
possibly simple and clean way of application level hooking, e.g. (in
the Windows case) hooking all Winsock calls on the application level.
Regards,
Magnus
Leslie P. Polzer
grarpamp wrote:
>> Phantom is not tied to a specific transport layer protocol.
>
> Maybe you mean 'phantom is not limited to transporting only a specific
> protocol over IP'.
> ie: Tor only transports TCP natively. I2P doesn't really transport
> any, TCP sortof.
I'm not sure what you mean here. Phantom does its work at the Internet
Layer using IP and doesn't force you to use a specific Transport Layer
protocol like TCP.
> A new driver? Why not use the existing tunnel drivers provided by the os?
Again I'm not sure what you mean here. The OS has to provide hooks for
setting up a virtual network device, and such a device will have to be
written for Phantom.
Leslie
grarpamp
Maybe another way :) Phantom will look like this right?
All on one very long bidirectional line...
user app - os stack/route - tun(4) dev w/ipv6 addr - phantom
- internet -
phantom - tun(4) dev w/ipv6 addr - os stack/route - user app
grarpamp
previous diagram, we can do cool stuff like...
ps:
user 208 0.0 1.6 17328 17184 ?? Ss xxxxxAM 10:05.32 (tor)
user 1685 0.0 0.1 2532 684 ?? Ss xx:xxPM 00:07.39 ocat -B -R -t
192.168.0.1:9050 -a -u user
sockstat:
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
user tor 208 16 tcp4 192.168.0.1:9050 192.168.0.1:27353
user ocat 1685 13 tcp4 192.168.0.1:27353 192.168.0.1:9050
ifconfig:
tun0: flags=51<UP,POINTOPOINT,RUNNING> metric 0 mtu 1500
inet6 fd87:d87e:eb43:b375:28ae:d257:fe6a:7f36 prefixlen 48
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
Opened by PID 1685
netstat -r:
Destination Gateway Flags Netif
fd87:d87e:eb43::/48 link#4 U tun0
fd87:d87e:eb43:b375:28ae:d257:fe6a:7f36 link#4 UHS lo0
$ ping6 -q fd87:d87e:eb43:2243:5f84:5b12:7bb5:bbc2
--- fd87:d87e:eb43:2243:5f84:5b12:7bb5:bbc2 ping6 statistics ---
202 packets transmitted, 176 packets received, 12.9% packet loss
round-trip min/avg/max/std-dev = 4647.167/7877.539/11767.761/1286.511 ms
!!! :-)
grarpamp
> possibly simple and clean way of application level hooking, e.g. (in
> the Windows case) hooking all Winsock calls on the application level.
Thus, with the example, why hook [intercept] Winsock or UNIX
system calls at all? Let the apps and syscalls run normally
and let the stack do its thing as well.
Example of soon to be obsolete hook software:
http://code.google.com/p/torsocks/
Leslie P. Polzer
Looks like we're on the same page!
Leslie
grarpamp
Ok, if you saw my last two notes, then cool :)
That would leave just the things regarding/after
'- IPv6/AP addressing scheme.' in my first note as FYI's.
Particularly address range reservations.
Also, I didn't think IPv4 would be of any use to assign to the
tunnel device because it would limit the phantom userbase
to at most around 16M users [10.0.0.0/8 etc, minus any current
local usage of same]. And certainly the huge majority of apps
will be v6 capable by the time phantom is coded and released.
Nice to see phantom willing to use certain cpu and especially disk
resources to store and process its view of the world. I think storing
some views/tables of the net on disk is a great tradeoff considering
that many users will use much more than that for their personal data.
1M users with 128bit v6 + 8kb rsa key = 122GB, not so much eh :)
And users or the daemon can encrypt the store as need be.
I need to read the whitepaper again too.
Wishing goodspeed development and security analysis to phantom project.
grarpamp
Oops, major error. That should be:
10M users with 128bit v6 + 8kb rsa key = 9.7GB, not so much eh :)
Magnus Bråding
IP range or 10.0.0.0/8 addresses, since it functions as a darknet with
its own copy of the entire IP space (i.e. 4*10^9 users with IPv4).
The only real reason for having Phantom addresses in the same format as
normal IP addresses is to keep transparent compatability with
(unknowingly hooked/intercepted) applications.
Or did I misunderstand your point?
Anyway, your input is appreciated and you seem to be knowledgeable in
the anonymization field, so if you just read the whitepaper again, as
suggested by yourself, we could then have even more interesting
discussions, on even more the same page after that. :-)
Regards,
Magnus
grarpamp
Regarding section 6.4.2 of the paper [1]:
Say Joe somehow attaches his httpd to the phantom network and uses
it to anonymously operate his website for other phantom users.
Say Jane, a phantom user, wishes to anonymously browse Joe's website.
What, exactly (by example), will Jane put in her URL bar as the
canonical string necessary to reach Joe's website?
[1] http://www.fortego.se/phantom-paper.pdf
> Or did I misunderstand your point?
Our potential misunderstandings are converging :)
Magnus Bråding
Since this skips all kinds of DNS resolution completely.
If the website is of the kind that proof of specific activity on the
site is more sensitive than the fact that you visited it at all, it is
also possible to use standard DNS resolution for your Phantom AP
addresses if you want, and instruct the Phantom subsystem to allow DNS
out on the "normal Internet". This is of course quite dangerous in the
way of opening up for DNS backchannel attacks from the websites your are
visiting, but anyway.
The final option would be to start a DNS service inside the Phantom
network itself, which could make transparent AP address resolution (at
least a little more) secure too.
The best thing anonymity wise is probably to always use pure AP
addresses though.
Regards,
Magnus
grarpamp
elegant, scalable and system agnostic. Food for much thought.
Two things are working in conjunction to weaken or defeat the phantom
proposed scheme of user[land] interface to phantom. They are:
1) Phantom is an overlay network on top of the internet. The internet
has 2^32 IPv4 addresses and 2^128 IPv6 addresses. Applicable
quantities of FQDN's are available. Today, in the absense of phantom,
if Jane enters 1.2.3.4 or example.com into her application, she
expects to, and will get to those sites. Not to a possibly confusing
oversubscription of those strings. Further, how do you deal with
bookmarks, shell scripts, application/daemon configuration, etc in
that environment. With much difficulty and ambiguity perhaps.
2) The software scheme having been described previously, in various
places/ways, and in part by, and hereafter referred to jointly as
[Ref1]:
- "application level hooking, e.g. (in the Windows case) hooking
all Winsock calls on the application level."
- "it functions as a darknet with its own copy of the entire IP
space"
- "7.2.2. RT setup procedure (Out [pp. 16] / In [pp. 13]) ... the
application layer on each side of the connection is notified of
this"
There appears to be no need to notify or work in the application
layer at all. And in fact, doing so may be limiting or hazardous.
Please review the following links:
http://www.cypherpunk.at/onioncat/
http://www.cypherpunk.at/onioncat/wiki/Installation
http://iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
http://www.iana.org/go/rfc4193
http://code.google.com/p/torsocks/
Then note in particular:
1) The selection of an IPv6/48, an ample 2^80 addresses, for use
by the anon networks from official RFC space dedicated for such
purposes. The far reduced risk that a bug in the [Ref1] scheme will
result in user packets going places unintended due to the oversubscribed
use of the same string for both the internet and phantom.
1a) IPv6 is already widespread in OS and applications. By the time
phantom comes about, no sensible application will not have it.
Internet deployment will likely lag application deployment. But it
does not matter since this is a private overlay. Thus IPv4 is only
needed on the internet backside of phantom, and only until the IPv6
internet deployment is complete.
1b) As is the case with Tor and I2P today, nobody enters in the
anonymous URL's by hand. It is all done with hyperlinks and bookmarks.
So IPv6 addresses will fit right in.
2) The use of tun(4) devices configured with the 'AP address' of
the node.
2a) Any and all IP protocols can now be used. TCP/UDP/ICMP/GRE/etc.
The paper alludes to this generically, but only speaks directly,
by acronym, of TCP, mostly in reference to internal operations.
2b) A multiuser machine should not be used to run an anon system.
So ifconfig(8) other network tools are not an identity leak. And
packet filters easily prevent inbound connections. If phantom is
prepared to put time into writing [Ref1], they could switch to
writing simple networking docs. Or simply bank it and let the user
cover it.
3) The use of the host routing table to provide a path to and from
each anon network and its nodes. Internet, phantom, Tor, I2P,
whatever.
4) The now lack of any need to write and use methods such as [Ref1]
or torsocks. The lack of need to keep up with OS vendor's networking
syscalls, libraries and the like. The user doesn't have to deal
with phantom'ifying different applications [11.1.7]... they point
their app at a destination and the routing tables handle it. The
ease of dealing only with fundamental IP addressing/routing and
existing tun(4) devices.
4a) In conjunction with 1 above, not monopolizing the [Ref1] scheme
for phantom's use. Now no anon network needs to do this hooking at
all. Each anon network will have separate IPv6 space and thus are
all usable simultaneously via their tun(4) interfaces. And the user
enjoys all of it, easily, due to IP fundamentals. Websites on one
network can hyperlink without namespace collision to those on
another. Admins can use their usual host firewalls to block anon
troublemakers from their service, etc.
5) It is not suggested to use onioncat for this. Just make phantom
do what onioncat does to present an IPv6 address and a route to the
phantom network.
Perhaps the only thing that will not directly work with this are
future outproxies from the phantom net that phantom operators choose
to deploy. That can be handled a few ways.
1) User sets up an OpenVPN tunnel over the IPv6 tun(4) phantom
tunnel to the remote phantom outproxy node's OpenVPN and routes
whatever they want over that. As with Tor, people will develop
systems that allow for simple rotattion, randomization or picking
of outproxies. This also makes it possible for a phantom outproxy
operator to offer access to more/all sites. Or they could use their
firewall to limit what their outproxy can reach, as done differently
from [11.1.5.1].
2) Phantom provides the [Ref1] scheme as a second optional solution,
in conjunction with, and only developed for, outproxies.
3) Given that Tor exists and was designed for this purpose, phantom
outproxies may be seen as moot. However:
3a) That potentially means weakness due to spreading users between
both anon networks. [Available number of nodes, bandwidth.]
3b) Generic anon IP lookalike overlay systems, with outproxy features,
such as maybe phantom/I2P+Ocat... may eventually obsolete anon
outproxy nets with internal hidden services and IP overlay shims,
like Tor+Ocat. It is a question of core purpose and utility.
[11.1.7] DNS leaks... are not the responsibility of phantom because
it only provides AP/IP addressing. The user can run their apps in
a sandbox with an all protocol funnel to phantom. They can also run
a local split horizon DNS with .phan TLD forwarding to servers
inside the phantom network.
[7.3] Secure End-to-End Authentication... appears to still need
ironed out. Just like on the regular internet, IP address spoofing
can be a problem. The IPv6 node addresses will need to be backed
by some PKI private key known only to the node. It's outbound packets
will need to be signed. And it's inbound packets will need to be
checked against the network database of public keys.
Or something like that. Onioncat group is currently working on that
as it applies to their situation.
Phantom group has likely given at least some consideration to
preventing spoofing with authentication by their current proposal
to use IP address lookalikes [AP's].
[7.3] Secure End-to-End Encryption... Yes, absolutely, all the user
traffic that passes between Jane and Joe's phantom daemons over the
private phantom network tunnel between the daemons needs to be
encrypted. By the daemon, at the boundary between the daemon and
the tun(4) device. It is believed Tor and I2P already do this, for
similar reasons. Disk and CPU is cheap, buy some :)
Users are still free and encouraged to use SSL services on top of
that. In the case they don't trust phantom or the regular internet
or their commercial vpn provider, etc. Such as https, ssh, smtps,
etc.
Users can and will build their own anon web of trust communities
on top these generic overlay networks. Anonymous keysigning parties,
digicash, etc.
Phantom's goal is not to be a true anon packet routing overlay
network like the internet with BGP. But it can handle all the casual
user's applications so that it feels like an extension of the IP
internet... without getting exclusively in the way of it :)
Bcc: ocat-talk
End of text.
grarpamp
Ok, good, we are converged without misunderstanding :)
grarpamp
Was thinking maybe it might be a fit. If phantom could provide a
simple way for ocat to talk to it, it could save phantom from
maintaining the tun/addr/route bits too. Ocat already deals with
the different ways each OS handles those. It could be bundled with
phantom. You'd have to chat with the ocat folks.