Re: [tor-talk] Tor and HTTPS graphic

[coderman <coderman@xxxxxxxxx>]

On Mon, Mar 12, 2012 at 11:57 AM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
> ...
> Your ideas intrigue me and I wish to subscribe to your newsletter.

my last comment for this sad, confused tangent of a thread;
  it has been accosted via conjecture with too much frequency *grin*


SCTP for congestion control of transparent proxy TCP/UDP traffic.
local classification of traffic allocates by protocol / use fairness
instead of aggregate tcp fairness. like bittorrent or aria2 parallel
traffic treated as distinct low priority unit of traffic, deferring to
higher priority low latency web traffic and messaging.

multi-homing / multi-path endpoints in SCTP would maintain concurrent
connection with distinct endpoints, avoiding predecessor, timing,
denial of service attacks present in reliable, ordered, single stream
transports.

edges would be screwed as you mention, unless they were full fledged
participants consistently. using a UDP based transport with LEDBAT or
other technique to keep broadband upstream unsaturated and unclogged
(no deep queues), allowing all broadband endpoints the ability to
contribute to a large shared network.

ORCHID IPv6 addressing with IPsec tunnels is intended to re-use
existing work, including well tested auth+privacy with datagram
padding in IPsec. SCTP+TLS would fit over top of IPv6 ORCHID endpoints
(using IPsec SAs) to transport signalling/keying and encapsulated
client traffic. part of this would also include lowest priority (lossy
reliable) SRMP type delivery of useful, less immediate information to
nodes. to some extent the ORCHID addresses could be thought of as
hidden service names and also circuit endpoints for a given IPsec
tunnel.

this set of:
a. critical signalling and keying traffic
b. high priority, interactive web traffic and messaging
c. lower priority bulk traffic, downloads, streaming media
d. best effort, latent bulk caching and exchange

are the classful shaping groups ordered inside of opaque SFQ outbound
queues at various improved/concurrent stratified dependent link
padding paths of IPsec telescopes carrying intermediate
hop(signalling) and bearer traffic.

combining better prioritization of traffic and consistent consumption
of traffic (deferring low priority packets and using opportunistic
caching strategies for network information respectively) obtains the
best performance out of the SFQ DLP paths with the lowest latency for
priority traffic.

still, so many details left as exercise for the reader ;)


> Do free reference implementations exist for all of these protocols?

sort of, for only parts; if you want a portable user space
implementation (or port) it's all custom. the joys of wild conjecture
include absurd timelines and technical effort for free...

rump is about as close as i've seen: http://www.netbsd.org/docs/rump/index.html

this is not the least of "how to deploy a thing like this" concerns.
there is also no backward compatibility or slow transition from an
existing Tor network to something using UDP encapsulated IPsec
telescopes (even if TCP can be transparently proxied over SCTP over
this).
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk