[tor-dev] xxx-triangleboy-transport.txt (+comments on pluggable-transport)

[Nick Mathewson]

On Fri, Feb 25, 2011 at 9:34 PM, Mike Perry <mikeperry at fscked.org> wrote:
> Thus spake Nick Mathewson (nickm at freehaven.net):
>
>> On Tue, Feb 1, 2011 at 12:08 AM, Mike Perry <mikeperry at fscked.org> wrote:

>> > 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.
>
> Ok. Well, does the example I gave look like an instance of what we
> want to specify as the behavior?

Sounds plausible.

>> > 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.
>
> The transport bridge should avoid being an open proxy. I suppose it
> can only properly carry full TCP streams to an endpoint, but without
> restricting who those endpoints are, it becomes a reflector open to
> abuse such as portscans.

Hm. For bridges, at least, the transportbridge will need to get a
supported list from some other mechanism, since it can't get an
exhaustive list from any particular source.  For relays, though, this
makes sense.

I think your original point is a good argument that sometimes this
information doesn't belong in the extrainfo document.  (I think it
does in the case that only a bridge authority needs to care about it,
but not otherwise.)

>> Also, why are transportbridges even running tor?  They don't seem to
>> be doing anything particularly tor-like.
>
> Mostly for the consensus, for reasons above. Not strictly required, if
> we don't mind being an arbitrary SYN proxy.
>
>> > 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.
>
> This is not a bad generalization. Do we want to make this distinction
> (between obfuscation vs transport) elsewhere in the spec, I wonder?

I'm not sure.  I can imagine chaining most of these mechanisms under
sufficiently weird circumstances.  For example, you might want to
obfuscate the protocol (make it not resemble SSL) before you do
another transform to make it impersonate HTTP, before you send it over
a triangleboy-like transport.

-- 
Nick