xxx-triangleboy-transport.txt (+comments on pluggable-transport)

[Nick Mathewson]

On Tue, Feb 1, 2011 at 12:08 AM, Mike Perry <mikeperry at fscked.org> wrote:
 [...]
>
> Appendix: List of key xxx-pluggable-transport.txt shortcomings
>
> 1. This pluggable transport does not need any intelligence or process
> launching on the Client side, aside from a way to tell Tor not to be
> so pedantic about ensuring identity key and IP address consistency.

What pedanticism exactly do you mean?  Matching the IP addr in the
netinfo cell, or something else?

> 2. The relay side needs to be able to detect if it has both the
> permissions and the network ability to send spoofed packets. It needs
> to communicate this fact with the Relay Plugin by responding with the
> appropriate extrainfo lines, or with "METHODS: NONE" to indicate
> error. This relay-side handshake should be specified in the
> pluggable-transport spec.

To be clear, you mean that the plugin checks whether it can spoof (and
tell Tor "I do nothing!" if it can't), or that Tor needs to find out
whether it can spoof and tell the plugin that whether it can spoof or
not.  The first sounds reasonable.  The second doesn't so much: most
Tors won't want to try to spoof, so building the checks into Tor
wouldn't make sense to me, unless I'm missing something.

> 3. The relay plugin side needs some way to communicate EXTRAINFO lines
> to be added to its extrainfo descriptor. In this proposal, we use the
> SMETHOD reply to do this.

Needs spec, not just an example.

> 4. Is extrainfo really the best place to keep this information?
> Shouldn't it just be in the relay/bridge descriptor? Putting it in
> extrainfo requires our TransportBridges to enable the wasteful
> DownloadExtraInfo=1 torrc setting, which will consume more scarce
> resources and RAM on what will probably be cheap routers with 32-64M
> of RAM.

Hm.  Relay/bridge descriptor should be okay, I guess.  I'm not sure
why the TransportBridges are getting those anyway, though:  I see why
the client needs it, but not what the transportbridge needs it.

Also, why are transportbridges even running tor?  They don't seem to
be doing anything particularly tor-like.

> 5. How would we go about chaining an actual obfuscation mechanism with
> this transport? Would we just create new and separate transport called
> TriangleBoyOverHTTP, for example, or is there a better way to chain
> different mechanisms?

On the client side, socks-over-socks-over-socks is not actually a
terrible way of doing things there.  We'll need to distinguish between
which transports are chainable and which aren't, though[*], and maybe
revise the design to make sure there's a way to tell to tell tor to do
said chaining.

On the server side, you need some way to distinguish which processing
method to do for incoming data. Separate ports seems ok there.  We
still need to figure out the server side.

[*] generally, obfuscation is chainable but transport isn't.

yrs,
-- 
Nick