On Wed, Feb 14, 2007 at 09:59:16AM +0000, Michael Rogers wrote: > Let's use TCP and TLS.
As a transport plugin, sure. As the default transport plugin and something to implement in the near future, no. > > 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). UPnP has serious problems. It works about 50% of the time, and if you happen to be behind an ISP NAT or especially on an untrusted LAN it's a major vulnerability. UDP will often work even behind relatively hostile firewalls e.g. it is possible to get it past many nasty corporate PATs with the relevant flags, and it will in most cases when combined with STUN work almost out of the box. > > * 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). It is rare that message re-ordering is a problem. However it does use some resources to track recent unmatched messages, and the level of resources required will increase with the bandwidth used. Also in-order delivery increases latency. Per hop latency dominates request times. > > 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 have to maintain buggy platform dependant UP&P code instead? > > * We can use standard, peer-reviewed cryptographic protocols instead of > rolling our own (again, hard to debug). Which don't necessarily meet our needs. > > * Freenet traffic becomes much harder to identify (lots of other > software uses TLS over TCP, including HTTPS, POP, IMAP, SMTP...) This is a fair point. > > 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) This has been suggested on Frost. With UDP it is impossible because of NAT-related issues (port rewriting etc). With TCP it is standard practice, but it doesn't buy us any real protection from traffic flow analysis attacks, which look at the number of connections from an IP address, their typical uptime, the type of the destination IPs etc. > > * 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). Very high latency, otherwise a good idea if we were using TLS, but not enough to swing me in favour of TLS. > > 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. Don't modern BitTorrent's use UDP to avoid firewall issues? BitTorrent was originally adopted by geeks. The more hoops you have to get users to jump through (e.g. port forwarding), the fewer users will use your product. We can't assume that everyone who uses freenet will be familiar with port forwarding already. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20070214/8abc77b0/attachment.pgp>
