How to introduce new RELAY_COMMAND_* types and new cell fields?
I'm writing a handful of proposals that need to introduce either new cell sub-payloads or new command types. Specifically, I want to add: 1. Sub-fields to CELL_PADDING to allow clients to tell relays about the amount of link padding they want for Proposal 251. Mobile clients will probably want less or no padding, and need some way to say so. Adding this information to CELL_PADDING itself seemed to be an easy choice. 2. Sub-fields to RELAY_COMMAND_TRUNCATED and CELL_DESTROY to include HMAC data for Proposal 253. 3. Additional RELAY_COMMAND_* types for clients to request out-of-band HMAC request cells for Proposal 253. 4. Additional RELAY_COMMAND_* opcodes for clients to request padding from relays (for an upcoming padding negotiation proposal). I *think* that fields for items #1 and #2 can be simply added to the existing cell definitions, since we specify that cells should already be 0-filled, and I can rely on 0 fields to mean that the additional fields are absent. It should be OK if relays simply ignore/omit these fields until those proposals are implemented. Is this OK? However, for items #3 and #4, if I introduce a new RELAY_COMMAND type and send it to a relay that doesn't support it, then that relay will emit a warning log message from connection_edge_process_relay_cell() in relay.c. How should I detect support? Based on advertised relay version in the consensus? What about non-standard relay implementations that don't use Tor's versioning? -- Mike Perry
Op 10/09/15 om 04:10 schreef Mike Perry:
I'm writing a handful of proposals that need to introduce either new cell sub-payloads or new command types. Specifically, I want to add:
1. Sub-fields to CELL_PADDING to allow clients to tell relays about the amount of link padding they want for Proposal 251. Mobile clients will probably want less or no padding, and need some way to say so. Adding this information to CELL_PADDING itself seemed to be an easy choice.
2. Sub-fields to RELAY_COMMAND_TRUNCATED and CELL_DESTROY to include HMAC data for Proposal 253.
3. Additional RELAY_COMMAND_* types for clients to request out-of-band HMAC request cells for Proposal 253.
4. Additional RELAY_COMMAND_* opcodes for clients to request padding from relays (for an upcoming padding negotiation proposal).
I *think* that fields for items #1 and #2 can be simply added to the existing cell definitions, since we specify that cells should already be 0-filled, and I can rely on 0 fields to mean that the additional fields are absent. It should be OK if relays simply ignore/omit these fields until those proposals are implemented. Is this OK?
However, for items #3 and #4, if I introduce a new RELAY_COMMAND type and send it to a relay that doesn't support it, then that relay will emit a warning log message from connection_edge_process_relay_cell() in relay.c. How should I detect support? Based on advertised relay version in the consensus? What about non-standard relay implementations that don't use Tor's versioning?
I don't think you can use the consensus for this: for HS connections you wont have any relay info. How about introducing very basic version info into created2/extended/rendezvous cells? You'd have to be really careful to not leak too much version info, of course. Tom
participants (2)
-
Mike Perry -
Tom van der Woerdt