Let's use TCP and TLS. Disadvantages:
* Most users will have to forward a port. However, the popularity of BitTorrent shows that most users can manage this (especially with UPnP and NAT-PMP support, which we can copy from Azureus or Limewire). * TCP delivers messages in order, which we probably don't need. However, it would be nice not to have to worry about malicious reordering in the higher layers of the protocol (two words: model checking). Advantages: * We don't have to maintain our own UDP transport layer. * We don't have to maintain as much crypto code (which is notoriously hard to debug). * We can use standard, peer-reviewed cryptographic protocols instead of rolling our own (again, hard to debug). * Freenet traffic becomes much harder to identify (lots of other software uses TLS over TCP, including HTTPS, POP, IMAP, SMTP...) Some more thoughts about disguising Freenet traffic: * Use an ephemeral port for each outgoing TCP connection (this would defeat the filter mentioned in the SecurityFocus article... by the way, check out who the author used to work for) * Add a simple stego wrapper to the TLS socket: the wrapper keeps outgoing data in a queue and passes random-sized chunks of data to the socket at random intervals (the intervals get shorter when the queue gets longer). By the time the data's been packed into records by TLS and coalesced into sensible-sized packets by TCP, the original size and timing of the messages should be pretty well disguised. It would be easy to extend this to CBR padding at a later date (keep the mean interval the same regardless of queue length, send padding when the queue is empty). I know this suggestion is unlikely to be accepted, but I'm not trolling - we could save ourselves a lot of work by using what's already out there, and BitTorrent shows that it wouldn't hurt performance or adoption. Cheers, Michael
