Re: udp transport PoC

[Camilo Viecco <cviecco@xxxxxxxxxxx>]

I will resume the conversation .

For Nick: there is actually a third approach between a pure userspace
TCP-like stack
and a IP forwarding approach (like freedom).
This approach, the one the PoC takes, is to extract the transport part
of the IP packets
and only forward this section. Doing so assumes that there will be no
fragmentation
at the IP level or that fragmented packets will not be forwarded.
So yes we are using kernel build TCP/IP packets but only forwarding some
of the TCP
section. (not all TCP header fields need forwarding in our case).

This, as we agreed, can lead to an exit node (even assuming a perfect
TCP field scrubbing)
to probably identify the algorithm and/or parameters used by the a
client to adjust its advertised window and/or
handle packet loss by applying selective packet drops. Thus, while a
userspace TCP like stack
is best for anonymity, I will focus for now on packet scrubbing (the
suboptimal solution).

Adam:
Thanks for the pointers (even tough I strongly disagree in with many
parts of briscoes' paper.
He swaps the problem of link bandwidth fairness to cost fairness in a
global scale, which I think
is even harder to solve).
It is my opinion that the best we can do is to use a TCP stack because
it allows us
to build upon the research of many researchers (and copy their results).
(Further it allows us to test many TCP implementations/options without
writing one line of code.)
The 'unfairness' issue cannot be resolved with Briscoe's approach as his
solution assumes
a way to identify users in order to make them pay for their congestion
which cannot be done
in anoynmity systems.


coderman wrote:
> On Tue, May 13, 2008 at 3:11 PM, Adam Langley <agl@xxxxxxxxxxxxxxxxxx> wrote:
>   
>> ...
>>  Now it would appear that you have two issues to content with. Firstly,
>>  you have a flow control issue between nodes and secondly a packet-loss
>>  issue for an individual circuit.
>>     
>
> flow control / congestion avoidance / tcp fairness will be near
> impossible with userspace UDP.  splitting these functions would allow
> you a bulk fraction of bandwidth for UDP payloads and a reliable
> control channel (via simple DTLS timeout / re-xmit or more robust
> airhook / SSCOP style control sessions for reliable datagram
> transport)
>   
I do not agree here. The key to efficient use of a packet based network is
congestion control/avoidance. In partcular when the network characteristics
are so varied as what Tor nodes provide. I rather reuse a 'good enough
solution'
TCP that try to build a better solution. Airhook looks interesting, but
I did not
saw any congestion avoidance mechanisms in it... and that is a bad thing
(I might have overlooked that in the code, so if it does enlighten me).

>>  Your flow control should probably be based on[2]. The description in
>>  the TCP RFC now bares no relation to reality.
>>     
>
> the problem with trying for true tcp fairness in a datagram transport
> used among many peers in userspace is going to be timer resolution
> (especially on win32, but still problematic in *nix).
>   
Dont thought of this before.  Do you know that from experience in userspace
network stacks or in some other projects?
> i'd much prefer to see a robust fractional bandwidth allocation
> specified for the datagram stack as a whole, than watch the poor
> behavior of another attempted TCP over UDP in userspace.
>
>   
I dont like fractional bandwidth allocation because that implies allocation
of network resources beforehand and that could lead to DoS. However I do
like the idea of client enforced bandwidth allocation, to make all users
behave similarly (throughput wise) and to make  p2p users make a choice:
anonymity vs performance.
> (i admit a general bias against TCP fairness in userspace, so a grain
> of salt with this $0.02..)
>   
>
>   
>>  Your packet loss and windowing is pretty straight forward, so long as
>>  it can signal packet loss events to the flow control. I don't have any
>>  specific references here, common sense is as good as the state of
>>  practice here.
>>     
>
> i keep referencing airhook in these discussions, particularly because
> some of the control communication changes tailored for a lossy
> wireless environment map nicely to the latency / multi-hop issues Tor
> DTLS will apply to reliable datagram communications between nodes.
>
> a number of modifications would be needed, however, including the
> larger windows and explicit IV management for the DTLS sessions.
> (doing key schedule properly for the first DTLS implementation into
> Tor would also solve the long standing thread contention issues with
> SSL/TLS stream encryption/decryption across multiple CPU's in an SMP
> system, for example)
>
>
> aside from fingerprinting attacks, what other critical concerns exist?
>   
I ask the same question....


Thanks all for you comments...


Camilo