Freenet JMS

Project: Freenet over JMS
Goal
The goal of this project is to provide Freenet's reader and publisher anonymnity to people behind firewalls, proxies, NATs, and any other network obstacle, using an extensible standards based mechanism to allow infrastructure developers to create tools to overcome challenges to the Internet's end to end assumption. This replaces the previous HTTP/FNP proposal

Overview
This project will modify / extend FRED to support the Java Message Service (JMS) as a transport layer, as well as select, configure, package, and distribute an implementation of JMS (probably Open JMS). Once FRED can communicate via JMS, the particular JMS implementation can be configured to handle whatever network topology is necessary - if a direct bidirectional connection is possible, it can use TCP sockets. If unidirectional connections are possible, it can use polling TCP sockets. If no direct TCP connections are not possible, it can use HTTP or HTTPS (with persistent 1.1 connections, bidirectional requests, or polling unidirectional requests). If neither HTTP connections nor TCP sockets are available, more exotic methods can be used, such as email (SMTP, POP3, IMAP), ftp (bidirectional or polling), UDP, or even UUCP. The transport mechanisms available are dependent on the JMS provider's implementation, but FRED does not need to know anything about it.

Once FRED can communicate via JMS, this project will focus its efforts on extending the JMS provider's implementation to support more anonymizing techniques, like using the above transport mechanisms, mixmaster style actions (padding messages, adding random delays, as well as sending out bogus messages / requests / emails / etc), and even extremely aggressive techniques like stenography. However, the big push will be simply to get FRED using JMS and have the JMS provider support jumping over firewalls, HTTP proxies, and NATs.

Why JMS
Basically, JMS is a standard J2EE API used in "enterprise" environments to allow for transport- and location-independent messaging - disconnecting the application logic from the details of how components communicate. It brings to Java the Message Oriented Middleware (MOM) technologies that have been used for years with products such as IBM's MQSeries, TIBCO, among others.

JMS has two modes of use - queues and publish/subscribe. A simple analogy for those is to think of queues as email and publish/subscribe as usenet - queues go to one place and publish/subscribe "channels" go to all subscribers. This document isn't an intro to JMS or MOMs - see java's JMS page, this MOM/MQSeries intro, or this IBM course (465K PDF) for more info.

The Freenet Network Protocol (FNP), as an asynchronous message based protocol, is a perfect match for JMS. For Freenet's purposes, there is one significant JMS related recommendation I will make - that Freenet use queues exclusively, as opposed to publish/subscribe "channels" - specifically, that queues be named according to the public key of each node. This would allow nodes to communicate effectively, not dramatically change the way the FNP works, and allow nodes to respond appropriately to flooding attacks (by authorizing the JMS router to refuse connections / messages to a queue from a flooder). If channels were used, there could be significant performance benefits (Request Data? and Announce messages could be transparently sent to multiple nodes simultaneously), but flood protection would be significantly more complicated (use of some sort of consensus among the channel subscribers to "vote off" the flooder).

I am very open to being convinced otherwise on this point - in TCP terms, you can consider publish/subscribe to be similar to multicast sockets and queues to be normal unicast sockets. How did freenet decide to use unicast exclusively, or was that merely a reflection of the fact that most of the freenet nodes aren't on multicast networks?

Effects on freenet
Splitting up the implications on Freenet into three sections - performance, scalability, and anonymnity - I can see seven major pros and two noticable cons

Performance

More storage capacity due to more nodes being able to participate in the network

Timeouts on JMS routed messages may need to be set significantly higher

Routing tables can be kept more consistent, as messages are routed based on the node's identity, not their (possibly temporary) IP address.

Scalability

JMS routers can network themselves as well, building more tightly meshed networks

JMS extends the networks that can use Freenet

Anonymnity

Obfustication of network communication beyond simple encryption

Traffic analysis can be defeated by mix-style communication

Simplicity of "wiretap" necessitates message encryption, at least on JMS

More users generates more traffic

Effects on FRED
This project will need to refactor / extend the following sections of FRED

To implement JMS, a new transport must be created

To support both JMS and TCP, transport configuration must be added, rather than always assuming TCP

To address the anonymnity con (ease of wiretap), messages on JMS should be encrypted to the target node

To address the delays JMS can find acceptable but FRED may not desire, timeouts and routing should be adjusted to handle each target's performance history. This is a tuning issue, and may not be essential for operation, but will most likely become significantly usefull for the JMS transport

Once FRED supports JMS, it is likely that no other transports will be introduced down the line (other than possibly IPC), as JMS should fill all of those transport needs without need for modifying FRED (if a new transport was necessary, the development could be done outside of FRED on the JMS provider). Those with needs for specific performance characteristics should be able to tune or select another JMS provider.

Implementation Plan
Spec out/document how FRED will use JMS (what queues to use, what node specific configuration will be necessary, etc)

Select JMS provider, implement Freenet wrappers, and test sending / receiving messages

Strip out TCP transport and replace with JMS, and test announce/request/insert with two instances of FRED

Refactor transport configuration in FRED and test that multiple transports can coexist successfully (test announce/request/insert with three FRED instances - one with TCP only, one with JMS only, and another with both TCP and JMS)

Configure/extend a JMS provider to breach firewalls, proxies, and NATs

Questions
Originally the support for node stealth and mixes was planned for FRED 0.8 (google cache as its off the new site), is this still the case? If so, would this project meet those needs?

The ability to jump over firewalls, proxies, and NATs without compromising publisher or browser anonymnity is necessary and IMHO incredibly important for Freenet as a free speech enabling mechanism (otherwise, freenet would only enable free speech for those who are on open networks and us techno-weenies who know what firewalls, proxies, and NATs are [needless to say can configure them]). Does anyone have any suggestions for achieving this goal in a simpler way than JMS? While architecturally, I'd prefer to use JMS, as it allows for the reuse of existing transport technology and research as well as cleanly factoring out the transport layer specifics from FRED, if there are easier ways to achieve this goal, I'd love to hear them.

Are there particular sections of FRED that I should be very carefull around due to its volatility?

Most importantly, should this JMS support be implemented as part of FRED, or should instead this be pushed off onto another branch to be merged back in when FRED was ready, or should this be a complete fork (aka does this sound like where FRED will want to go?)

I know everyone's busy doing plenty of really important work, and I'm not trying to be a burden on y'all. My concern is that we're pretty significantly limiting the ability of mere mortals to take advantage of Freenet's anonymnity by requiring either end-to-end networks connections (a rapidly diminishing resource) or administrative control of the firewalls or NATs in use. Once this project is complete, someone with any sort of network access (ftp, web, email) will be able to retrieve and install FRED, specify the JMS configuration, and participate anonymously within Freenet.

My primary concern is not in finding ways to quickly share 0-day w4r3z or download some porn, but to let people like Subcomandante Marcos or Tao Haidong communicate freely. Simply tossing on a way to get through an HTTP proxy may help defeat some attacks, but when we have to deal with more sophisticated (and more dangerous) situations like the ones those two face, if we have to dig through FRED to add some transport level anonymization feature (like implementing mix style messages, having our network listeners look normal unless they're accessed in a certain way, or using stenography), we're going to be fighting a losing battle. By adopting JMS as a transport layer, all transport level issues are instantly factored out of FRED and can be dealt with seperately.

As you can see, this project really has two goals - one functional (allowing more people to use Freenet), and one technical (giving Freenet the infrastructure it needs to manage the defenses against more complex attack scenarios). Yes, it is possible to build the precautions necessary to defeat an advanced attacker into FRED, but is that sort of network stealth best placed inside FRED or in a seperate component that is designed for no other purpose than to secretly communicate messages? I'm not saying this just from the elegance stand point, but from a practical "how am I supposed to patch a 115KLOC application to defend against attack X?" standpoint.

As always, I welcome comments and input. I'm on IIP as jrandom and I can be reached via jrandom@cryptomail.org (don't use my iipmail account). I still haven't reworked those "pretty" FNP docs, partly because I found the new more complete (and much better) docs online and haven't had time to revise the UML, and partly because it isn't necessary to getting this project up and running (the JMS layer just needs to pass off the messages instead of actually understanding what the messages mean).