Thus spake Nick Mathewson (nickm@freehaven.net):
On Tue, Feb 1, 2011 at 12:08 AM, Mike Perry mikeperry@fscked.org wrote: [...]
Appendix: List of key xxx-pluggable-transport.txt shortcomings
- 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.
- 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.
- 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?
- 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.
- 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?
On Fri, Feb 25, 2011 at 9:34 PM, Mike Perry mikeperry@fscked.org wrote:
Thus spake Nick Mathewson (nickm@freehaven.net):
On Tue, Feb 1, 2011 at 12:08 AM, Mike Perry mikeperry@fscked.org wrote:
- 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.
- 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.
- 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.
-
Mike Perry -
Nick Mathewson