Nick Mathewson <[email protected]> writes: > On Thu, Jan 26, 2012 at 8:38 PM, George Kadianakis <[email protected]> > wrote: >> After discussion in tickets #4773 and #3587 this is a pre-draft of a >> proposal that revamps the Extended ORport, introduced in proposal 180, >> <snip> >> communication between the tor process and the pluggable transport >> proxy. To achieve this, this proposal refactors the extended ORPort >> protocol specified in Proposal 180, and introduces a new port, >> TransportControlPort, whose sole role is the exchange of control >> information between transport proxies and tor. > > So before we get too far into this, let's do a protocol overview! I'd > suggest inserting something like this into the text, assuming that it > is actually what you meant: > > "Server-side Transports need to talk to the Tor server about > individual connections, and continue to do so as the connection is > ongoing. To do so, > the transports deliver each connection to an "Extended ORPort", where > they provide metadata and agree on an identifier for each tunneled > connection. Once this handshake occurs, the OR protocol proceeds > unchanged. > > Additionally, each transport maintains a single connection to Tor's > "TransportControlPort", where it receives instructions from Tor about > rate-limiting on individual connections. >
A similar string to this, can be found in the beginning of section 3. . I think we should remove the first paragraph of section 3, and put your version of the string in the end of section 2. >> 3. The new extended ORPort protocol >> >> Server transport proxies may need to connect to the bridge and pass >> additional information about client connections that the bridge >> would ordinarily receive from the kernel's TCP stack. To do this, >> they connect to the "extended server port" as given in >> EXTENDED_SERVER_PORT, send a short amount of information, wait for a >> response, and then send the user traffic on that port. >> >> The extended server port protocol is as follows: >> >> COMMAND [2 bytes, big-endian] >> BODYLEN [2 bytes, big-endian] >> BODY [BODYLEN bytes] >> >> Commands sent from the transport proxy to the bridge are: >> >> [0x0000] DONE: There is no more information to give. (body ignored) > > Let's add, "the next bytes sent by the transport will be those > tunneled over it." > I agree. >> [0x0001] USERADDR: an address:port string that represents the user's >> address. >> >> [0x0002] WANT_CONTROL: A body-less message which indicates that >> the transport proxy wants to use the TransportControlPort of >> the bridge. It SHOULD be followed by a CONTROL command from >> the bridge, otherwise the transport may close the connection. >> >> # will this work? > > Hm. I think it'd be better to have this command mean "We support the > transportcontrolport protocol," not "you must use the > transportcontrolport protocol!" After all, if Tor _doesn't_ tell the > transport about rate-limiting, it's not like anything breaks > disastrously. > Hm, when I thought of 'WANT_CONTROL', I was considering that there might be transports that absolutely _require_ the use of TransportControlPort. Since we don't have such transports at the moment, and the short-term future transports don't seem to require TransportControlPort, I guess it could be OK to diss WANT_CONTROL for now. Still, I'm not sure if tor should do business with a transport proxy that does _not_ support the TransportControlPort protocol. It wouldn't surprise me if there are bridge operators out there who consider rate-limiting essential. >> Replies sent from tor to the proxy are: >> >> [0x1000] OKAY: Send the user's traffic. (body ignored) >> >> [0x1001] DENY: Tor would prefer not to get more traffic from >> this address for a while. (body ignored) >> >> [0x1002] CONTROL: a NUL-terminated "identifier" string, followed >> by a second NUL-terminated string of the <address>:<port> of >> the TransportControlPort. The pluggable transport proxy must >> use the "identifier" to access the TransportControlPort. >> >> # pass TransportControlPort <address>:<port> through env. vars? > > Seems wise, sure. > OK, then, CONTROL should simply contain the TransportControlPort identifier and we should update 180 to specify how we pass the TransportControlPort creds through environment variables. >> # what should parties do when they receive a command they don't >> # understand? should we enforce forward-compatibility with protocol >> # versioning or with "ignore commands you don't understand", or what? > > Let's say "ignore." If you want, we can reserve the top bit of each > command to indicate "you must understand this; if you don't, close the > connection." > 'ignore' sounds fine. If you think that reserving the top bit will be helpful in the long-run, I guess we should do it. >> [We could also use an out-of-band signalling method to tell Tor >> about client addresses, but that's a historically error-prone way >> to go about annotating connections.] > > Yes; let's not do that. > That was actually your own text copied from 180. Since you seem to agree with your one-year-younger self, I guess we can erase it from the proposals :) >> The new TransportControlPort protocol >> >> The TransportControlPort protocol is as follows: >> >> COMMAND [2 bytes, big-endian] >> BODYLEN [2 bytes, big-endian] >> BODY [BODYLEN bytes] >> >> Association commands sent from the transport proxy to the bridge >> are: >> >> [0x0000] ASSOCIATE: a NUL-terminated "identifier" string. See >> 'Association' section below. > > Hm. I think that each command should have an associated identifier, > and that identifiers should be (say) 16-byte binary values. All this > hex encoding/decoding seems pointless, since this isn't a > text-oriented protocol. So how about > ConnectionID [16 bytes] > Command [2 bytes] > Bodylen [2 bytes] > Body [bodylen bytes] > Looks good! >> Association commands sent from the bridge to the transport proxy >> are: >> >> [0x1000] ASSOCIATED: Sent upon receiving a legit ASSOCIATE >> command from a transport proxy. (body ignored) >> >> [0x1001] NOT_ASSOCIATED: Sent after the bridge receives a >> non-legit ASSOCIATE command from a transport proxy. Also sent >> when the bridge receives a non-ASSOCIATE command from a >> non-associated transport proxy. Upon sending this command, the >> bridge SHOULD close the connection. (body ignored) >> >> Configuration commands sent from the transport proxy to the >> bridge: >> >> [0x0001] RATE_LIMITED: Message confirming that the rate limiting >> request of the bridge was carried out successfully (body >> ignored). See the 'Rate Limiting' section below. >> >> [0x0001] NOT_RATE_LIMITED: Message notifying that the transport >> proxy failed to carry out the rate limiting request of the >> bridge (body ignored). See the 'Rate Limiting' section below. >> >> Configuration commands sent from the bridge to the transport >> proxy are: >> >> [0x1002] RATE_LIMIT: Carries information on how the pluggable >> transport proxy should rate-limit its traffic. See the 'Rate >> Limiting' section below. >> >> # what should parties do when they receive a command they don't understand? > > Send an "unrecognized command error", perhaps. Or ignore it. If the > latter, let's add a way to declare what version of this protocol you > will understand. > Since we like 'ignore' in the 'ExtendedOR Protocol', we can use 'ignore' here too. Maybe. >> 3.1. Association and identifier creation >> >> For Tor and a transport proxy to communicate using the >> TransportControlPort, an identifier must have already been negotiated >> using the 'CONTROL' command of Extended ORPort. >> >> The TransportControlPort identifier should not be predictable by a >> user who hasn't received a 'CONTROL' command from the Extended >> ORPort. For this reason, the TransportControlPort identifier should >> not be cryptographically-weak or deterministically created. >> >> Tor should create its identifiers by generating 16 bytes of random >> data and hashing them with the SHA256 cryptographic hash function. >> The identifier string transmitted with the 'CONTROL' command should be >> the hex representation of the SHA256 output. > > The hashing step seems pointless; why not just generate 16 random > bytes and use those? > I'm stupid. >> 4. Configuration commands >> >> 4.1. Rate Limiting >> >> A tor relay should be able to inform a transport proxy in real-time >> about its rate-limiting needs. >> >> This can be achieved by using the TransportControlPort and sending a >> 'RATE_LIMIT' command to the transport proxy. >> >> The body of the 'RATE_LIMIT' command should carry two integers, in >> NUL-terminated ASCII string format, representing the bandwidth rate >> and bandwidth burst in 'bytes per second', that the transport proxy >> must set. >> >> # better transmit format? After reading langsec.org, I prefer to avoid >> # length fields. Not that this format is bug-proof... > > 4 bytes, big-endian, I'd say. > I like. That was what I wanted to do originally, but I then discarded it as non-future-proof enough. Let's pump it up to "The body of the 'RATE_LIMIT' command should carry two integers describing 'bytes per second'. Each of them is 8 bytes, big-endian...". That comes to 18.45 exabytes per second, which should be quite future-proof. >> When the transport proxy sets the appropriate rate limiting, it should >> send back a 'RATE_LIMITED' command. If it fails while setting up rate >> limiting, it should send back a 'NOT_RATE_LIMITED' command. >> >> After sending a 'RATE_LIMIT' command. the tor bridge might want to >> stop pushing data to the transport proxy, till it receives a >> 'RATE_LIMITED' command. If, instead, it receives a 'NOT_RATE_LIMITED' >> command it might want to shutdown its connections to the transport >> proxy. >> >> # is this realistic? > > Hm. There probably also wants to be an overall rate limit that > applies to all connections. Also, there should be a way for the > transport to report to Tor how many bytes it's actually using, I > think, if the bytes on the wire are more vebose than the traffic they > encode. > Actually, when I was thinking of 'RATE_LIMIT', I was thinking that the rate limit value describes "the overall rate limit that applies to all connections". I _wasn't_ thinking of it as per-connection. I know it feels stupid and/or unintuitive to specify the global rate limit in a per-connection stream, but it seemed like the simplest way to do it. What do you think? I also agree that there should be a way for the transport to report to Tor how many bytes it's actually using. Specifically, my proposal does *not* specify how transport proxies pass usage statistics to tor. This is quite needed at the moment. >> 5. Security Considerations >> >> Extended ORPort or TransportControlPort do _not_ provide link >> confidentiality, authentication or integrity. Sensitive data, like >> cryptographic material, should not be transferred through them. >> >> Note that an attacker with superuser access, is able to sniff network >> traffic, and capture TransportControlPort identifiers and any data >> passed through those ports. >> >> # Is it worth adding an SSL layer (passing pub. key fpr via >> # env. vars?)? :/ > > I say no; though it probably _is_ worthwhile to say "This should only > use localhost, and should shout very loudly if you try to bind or > connect somewhere else with it." > Sounds good. >> # Talk about Incentives of tor or transport proxies to comply to the >> # wishes of each other. Ways to detect nonconformism. (threat >> # model. Should tor speak with 3v1l transport proxies in the first >> # place?) > > I disagree with that; the transport proxies are run by the bridge > operators and need to do more or less what they're supposed to do. > Trying to get proxies to be sandboxable or something seems like a much > bigger and sorta unrelated task. > > yrs, If you haven't done it already, I'll try to update the proposal today or tomorrow, and also specify how statistics should be passed around. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
