UDP/datagram/cell based networks [was: Why_can't_email_be_secure]
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...
On Thu, Aug 29, 2013 at 1:39 AM, grarpamp <grarpamp@gmail.com> wrote:
... 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.
i should clarify: the mode of operation for this presumed design and implementation is to have SOCKS, HTTP, HTTPS, transparent UDP, transparent TCP, transparent DNS (this is indeed different than just UDP :), and some subset of transparent ICMP proxy support on the client / node. you could configure proxy settings, direct traffic to the trans ports, or perform queries directly against the DNS port of the running real time datagram mixer instance. at the exits for public traffic or at the private ORCHID based "hidden/overlay" endpoints, you transit these same protocols, per advertised support in exit policy or overlay service capability respectively. on the wire, you would be sending UDP datagrams that encapsulate the NAT busting IPsec telescope containing path data, multi-path SCTP in userspace for reliable TCP stream transport over the datagram overlay. for all intents and purposes these packets would look like AH/ESP or CryptoBox wrapped opaque cipher texts in some standard UDP encapsulation. as for ATM, SONET, satellite data terminals, metro wireless, and all other unusual or exotic transports: these are likely not useful for the core network unless directly public UDP IPv4 reachable. censorship bypass, non-node capable devices like phones, or very poor network connectivity situations, would require other transports and protocols for this initial tunnel into the overall real-time datagram mix-like network. in this context, the varied physical layers and logical paths in a given metro region operating beneath IP routing can play a role in passing traffic from suppressed/blocked users out to the broader mesh or internet at large. devices and users communicating via obfuscated links into the dgm network do not have traffic analysis protections like full participants. despite this lack of stronger anonymity, the actors observing at the edge can only note that you are tunneling into the public network, and utilizing some stochastic gradient of bandwidth in aggregate for some period of time. this is still not much information, especially compared to the current state of affairs! there are many complications and constraints around how this would work - i make it sound so easy ;) however, you could provide such services, including wireless metro area mesh or p-to-mp distribution networks, constrained by propinquity and referral by reputation, in combination with broadband internet uplink of a more traditional sort where available. and in fact, using multiple paths / transports concurrently provides advantage for data continuity and throughput despite volatile and changing upstream link availability on an individual basis to particular gateway or router or access point devices. metro area mesh benefits nicely from some backhaul ad-hoc or fixed plant high capacity point-to-point links over distance with short IP routes; there is a good paper from early 2000's about using atheros 802.11a devices with a custom tertiary firmware and host driver to bond eight devices into a single point-to-point link with an aggregate throughput over three or four hundred megabit a second in transport rate... or so i recall. IPoATM on a OC12 or bigger to an internet provider would absolutely be useful as an upstream sink within such a mesh. i would love to see high degree mesh optimizer p-to-mp nodes applying the latest high bit rate software defines radios for backhaul and security. isolate each radio like a Pervices Noctar[0] or USRP B210 [1] into its own guest and isolate devices with VT-d enforced memory access boundaries. you may even put more than one device in a single SDR Backhaul Guest VM if doing large-QAM or other complex MIMO front-ends and signal processing. i could go on, but alas, i've got code to write... *grin* 0. "Noctar: 8Gbps, low latency, PCIe x4 bus, 250MHz bandwidth, full duplex, RF frontend 100kHz – 4GHz, Two, 12 bit, 125 MSPS ADCs, Dual channel, 16 bit, 250 MSPS DAC, 20MHz, 0.28ppm, reference TCXO, Altera Cyclone IV EP4CGX22C FPGA" http://www.pervices.com/support/ 1. "USRP B210 Kit: USB 3.0 (bus max 3.2Gb/s) for xfer ~60 MSym/sec, 56 MHz bandwidth 1x1 / 32 MHz 2x2 MIMO bandwidth, 70 MHz to 6 GHz frequency range, flexible rate 12bit ADC/DAC, 2 TX and 2 RX full or half duplex channels (4 total), Xilinx Spartan 6 XC6SLX150 FPGA" https://www.ettus.com/product/details/UB210-KIT
On Thu, Aug 29, 2013 at 4:07 AM, coderman <coderman@gmail.com> wrote:
... as for ATM, SONET, satellite data terminals, metro wireless, and all other unusual or exotic transports...
i should have mentioned: metro Ethernet or municipal run fiber networks with peering are the best option for mesh traffic relaying like this. ATM is too expensive; IDSN, despite a proud origin story of the first data mix networks, is also expensive, and super slow. get rooftop access for radios in a Fresnel friendly internet exchange where you can simply forward traffic down a few floors over Ethernet and you're in the best of positions. consumer fiber to the home would be great, if ToS restrictions didn't make such forwarding risky. and the business upgrade for FTTP is pretty outrageous in almost every case. you could route through a VPN provider or dedi server of your own in this case, but tunneling may not be sufficiently covert depending on the amount of bandwidth used.
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)
On Thu, Aug 29, 2013 at 10:25 AM, grarpamp <grarpamp@gmail.com> wrote:
... because of our silly desire to not fill our pipes with chaff, we've made it easier in some cases for GPA's [...] to watch and connect the inputs/outputs across a relatively silent backbone...
active attacks are often even more effective at rapid traffic confirmation and analysis[0]; GPA is pretty tame perhaps! in any case the challenge you mention: thwarting or preventing traffic analysis without a full mix of constant traffic. if the datagram based system above existed, combine with: - stochastic fair queuing and re-ordering of egress traffic. by "clamping" the outbound rate of randomized, re-ordered datagrams to a broad "size/chunk" of capacity, you deter traffic confirmation, anonymity set reduction, and other traffic analysis attacks of various types. - client-side classification of application traffic into prioritized classes[1] for ingress / dgm proxy level active shaping by classful HTB queues before transiting the first hop and losing all visibility into the content and priority of message payloads. - integrate a lowest effort / unreliable background reliable multicast like bulk transport channel for resource and key pre-caching, network participant and performance information distribution, secure remote archives, random performance measurement/tests across peer groups, other low priority communications suited for this "filler" class of traffic. (consuming more or less filler traffic helps smooth out the effective throughput and efficiency when changing the broad "stochastic traffic capacity range" appropriate for a given peer.) - provide LEDBAT or AQM management of edge traffic to upstream(s) to prevent unnecessary latency in upstream buffers. this ensures that even at full utilization the responsiveness of the broadband link is excellent. - and the multi-path SCTP, IPsec, UDP NAT traversal and encapsulation, and other user space network stacks communicating across this overlay network as discussed above for requisite application and control communication support. these techniques combined allow you to use still not insignificant "stochastic traffic capacity ranges" instead of a constant fixed amount of traffic to protect against these attacks. these stochastic ranges can be adjusted up or down as network performance and capacity dictate. this protocol provides congestion control and TCP friendliness while greatly reducing the amount of bandwidth consumed relative to a traditional mix. --- at best (in theory), an attacker with local active and global passive methods on hand could discern anonymity sets for broad categories / scales of possible communication usage. E.g. anon set A exhibits traffic utilization on the order of 1Mbps to 5Mbps, while anon set B exhibits traffic utilization on the order of 5Mbps to 50Mbps, and anon set C exhibits traffic utilization on the order of 50Mbps to 1Gbps, etc. given this drawback, code a kick ass client with participation enabled by default if sufficient connectivity and resources are available. you've now made these broad traffic volume sets nearly useless in a practical / actionable sense. congratulations! you've now got a traffic analysis resistant low latency anonymity protocol, implementation, and network that nearly anyone can participate in and contribute to. for my next magic hand wave, a directory / route selection method that scales to billions of peers while leveraging geographic propinquity and social peer groups to constrain Sybil attacks and impact of bad actors. next grow network capacity in a way that continually applies implicit feedback from the network overall and peers directly and your deterrence to these attacks begins to improve further over time, perhaps even one day hitting a tipping point of prevalence and persistence for de-facto victory in most threat models... we can dream! --- perhaps someone should toss up a Bitcoin donation address to support work on detailed technical specifications, experimental prototypes, maintaining clouds for continuous builds, regression checks, load tests, and traffic analysis for quality measurement and security improvement[2], could also use donations for bounties for identifying or exploiting security or privacy vulnerabilities in the design and implementation of this final generation anonymous network. whoever sets this up should probably use an onion to coordinate development and distribute sources, other resources... calling all "tup" s, ... ;P --- 0. "From a Trickle to a Flood: Active Attacks on Several Mix Types" http://freehaven.net/doc/batching-taxonomy/taxonomy.pdf 1. i have mentioned the following classes before, with each in priority order for the HTB prioritization / shaping before traffic enters the network and becomes opaque: a. control and signalling traffic - always takes precedence. b. real-time and interactive communications, but not video. c. real-time video communication, if applicable. d. low priority bulk communication. torrents, archives, opportunistic caching e. filler / last-tier best effort unreliable traffic as mentioned above for filling in the remaining capacity at the current stochastic rx/tx rate center point. 2. instead of trying to research and author formal proofs of entropy bounds for various idealized models, cut straight to the chase and build the most aggressive, best in class developmental learning / deep learning systems for classification and identification of nodes, flows, protocols, identities in a test bed setup that provides full traffic visibility and active client edge MitM capability (E.g. simulate attack via rogue AP or cell tower for tagging? selective DoS? others,). malicious attacks performed by the remote end or injected by remote's upstream are not in scope for this traffic analysis and privacy assessment. however, passive capture of all exit communications and ORCHID hidden endpoint communications is in scope for analysis. then, see how effective this best scenario and tools attack is against a running implementation. did it fail catastrophically in flames or break wide open with trivial effort? keep improving... respectably hardened against the most aggressive machine learning and malicious active attacks you could conceive of and build? great! have a beer and then find the people who see the oversights and blind spots you don't. keep improving... rinse, repeat, ...
participants (2)
-
coderman -
grarpamp