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

Tom van der Woerdt info at tvdw.eu
Thu Sep 10 08:45:03 UTC 2015


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3749 bytes
Desc: S/MIME-cryptografische ondertekening
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150910/8bbc65a9/attachment.bin>


More information about the tor-dev mailing list