On 8/29/13, grarpamp <grarpamp@gmail.com> wrote:
On 8/26/13, coderman <coderman@gmail.com> wrote:
On Sun, Aug 25, 2013 at 10:52 PM, Bill Stewart <bill.stewart@pobox.com>
Datagrams don't give you any useful anonymity, ... usability for example to support UDP traffic and applications which
Are we necessarily even speaking strictly of UDP 'datagrams' or applications? For example, I presume there might be something to be said for software switched packet/cell network stacks. Even if they are encapsulated in meshes of TCP overlay circuits for the TCP properties. Streams of buckets passing inside, be they full of ham or discarded chaff. The cost is the bandwidth you wish to dedicate to it, the cpu/ram to pass, route and control it. Can old ATM transports be anonymized or assist in that...
i should have mentioned:
Yes, applying some of the areas you mentioned to building new physical networks, grafting in pieces of the existing net where needed... good stuff. Almost everyone can find some cheap 3+ ethernet port routing capable device these days. Add protocols on top. I should have been more clear on the topic of my note... right now we have really good content encryption for I2P/Tor/etc type networks. And pretty good intelligently random multi hop routing mechanisms. But because of our silly desire to not fill our pipes with chaff, we've made it easier in some cases for GPA's [1] to watch and connect the inputs/outputs across a relatively silent backbone... whether by timing, or transfer amount over time. Now if you dedicate N kbps to the net and fill it, and everyone else picks their commit rate and fills it, that passive weakness goes away. A bit like ATM, you won't move any more than your rate over it, but you idly fill it with chaff that gets discarded somewhere else at no extra cost. Keeping lines full is inverted thinking, so I'm not sure if anyone's tried to napkin mechanisms for that. [1] Not ActiveAdversaries. Here's a fun notice from Tor that could be viewed as a potential targeted isolation attack: Aug xx hh:mm:ss [notice] We stalled too much while trying to write N bytes to address [scrubbed]. If this happens a lot, either something is wrong with your network connection, or something is wrong with theirs. (fd num, type OR, state n, marked at main.c:line)