Re: [tor-dev] Pre-draft of Proposal XXX: Extended ORPort and TransportControlPort

[George Kadianakis <desnacked@xxxxxxxxxx>]

Nick Mathewson <nickm@xxxxxxxxxxxx> writes:

> On Thu, Jan 26, 2012 at 8:38 PM, George Kadianakis <desnacked@xxxxxxxxxx> 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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev