[tor-dev] How to introduce new RELAY_COMMAND_* types and new cell fields?

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


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150909/b2303139/attachment.sig>