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

[Mike Perry]

Thus spake Nick Mathewson (nickm at freehaven.net):

> 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?

I actually don't know the full list there. I think the last time we
tried to enumerate this, we decided that "try it and see what actually
breaks" was a more efficient approach.

> > 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.

Yes, the first is what we want here.

> > 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?
 
> > 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.

> 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?

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110225/c2e2f4e0/attachment.pgp>