commit 8560a5be217893dd3742d65080a19370ac88a208 Author: Nick Mathewson nickm@torproject.org Date: Mon May 11 16:05:46 2020 -0400
Add proposal 319: RELAY_FRAGMENT cells --- proposals/000-index.txt | 2 + proposals/319-wide-everything.md | 123 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 125 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index ecfa49b..fb2fc56 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -239,6 +239,7 @@ Proposals by number: 316 FlashFlow: A Secure Speed Test for Tor (Parent Proposal) [DRAFT] 317 Improve security aspects of DNS name resolution [OPEN] 318 Limit protover values to 0-63 [OPEN] +319 RELAY_FRAGMENT cells [OPEN]
Proposals by status: @@ -283,6 +284,7 @@ Proposals by status: 315 Updating the list of fields required in directory documents 317 Improve security aspects of DNS name resolution 318 Limit protover values to 0-63 + 319 RELAY_FRAGMENT cells ACCEPTED: 188 Bridge Guards and other anti-enumeration defenses 249 Allow CREATE cells with >505 bytes of handshake data diff --git a/proposals/319-wide-everything.md b/proposals/319-wide-everything.md new file mode 100644 index 0000000..a7b9b8a --- /dev/null +++ b/proposals/319-wide-everything.md @@ -0,0 +1,123 @@ +``` +Filename: 319-wide-everything.md +Title: RELAY_FRAGMENT cells +Author: Nick Mathewson +Created: 11 May 2020 +Status: Open +``` + +(This proposal is part of the Walking Onions spec project.) + +# Introduction + +Proposal 249 described a system for `CREATE` cells to become wider, in order to +accommodate hybrid crypto. And in order to send those cell bodies across +circuits, it described a way to split `CREATE` cells into multiple `EXTEND` +cells. + +But there are other cell types that can need to be wider too. For +example, `INTRODUCE` and `RENDEZVOUS` cells also contain key material +used for a handshake: if handshakes need to grow larger, then so do +these cells. + +This proposal describes an encoding for arbitrary "wide" relay cells, +that can be used to send a wide variant of anything. + +To be clear, although this proposal describes a way that all relay +cells can become "wide", I do not propose that wide cells should +actually be _allowed_ for all relay cell types. + +# Proposal + +We add a new relay cell type: `RELAY_FRAGMENT`. This cell type contains part +of another relay cell. A `RELAY_FRAGEMENT` cell can either introduce a new +fragmented cell, or can continue one that is already in progress. + +The format of a RELAY_FRAGMENT body is one the following: + + struct fragment_begin { + // What relay_command is in use for the underlying cell? + u8 relay_command; + // What will the total length of the cell be once it is reassembled? + u16 total_len; + // Bytes for the cell body + u8 body[]; + } + + struct fragment_continued { + // More bytes for the cell body. + u8 body[]; + } + +To send a fragmented cell, first a party sends a RELAY_FRAGMENT cell +containing a "fragment_begin" payload. This payload describes the total +length of the cell, the relay command + +Fragmented cells other than the last one in sequence MUST be sent full of +as much data as possible. Parties SHOULD close a circuit if they receive a +non-full fragmented cell that is not the last fragment in a sequence. + +Fragmented cells MUST NOT be interleaved with other relay cells on a circuit, +other than cells used for flow control. (Currently, this is only SENDME +cells.) If any party receives any cell on a circuit, other than a flow +control cell or a RELAY_FRAGEMENT cell, before the fragmented cell is +complete, than it SHOULD close the circuit. + +Parties MUST NOT send extra data in fragmented cells beyond the amount given +in the first 'total_len' field. + +Not every relay command may be sent in a fragmented cell. In this proposal, +we allow the following cell types to be fragmented: EXTEND2, EXTENDED2, +INTRODUCE1, INTRODUCE2, RENDEZVOUS. Any party receiving a command that they +believe should not be fragmented should close the circuit. + +Not all lengths up to 65535 are valid lengths for a fragmented cell. Any +length under 499 bytes SHOULD cause the circuit to close, since that could +fit into a non-fragmented RELAY cell. Parties SHOULD enforce maximum lengths +for cell types that they understand. + +All `RELAY_FRAGMENT` cells for the fragmented cell must have the +same Stream ID. (For those cells allowed above, the Stream ID is +always zero.) Implementations SHOULD close a circuit if they +receive fragments with mismatched Stream ID. + +# Onion service concerns. + +We allocate a new extension for use in the ESTABLISH_INTRO by onion services, +to indicate that they can receive a wide INTRODUCE2 cell. This extension +contains: + + struct wide_intro2_ok { + u16 max_len; + } + +We allocate a new extension for use in the `ESTABLISH_RENDEZVOUS` +cell, to indicate acceptance of wide `RENDEZVOUS2` cells. This +extension contains: + + struct wide_rend2_ok { + u16 max_len; + } + +(Note that `ESTABLISH_RENDEZVOUS` cells do not currently have a an +extension mechanism. They should be extended to use the same +extension format as `ESTABLISH_INTRO` cells, with extensions placed +after the rendezvous cookie.) + +# Handling RELAY_EARLY + +The first fragment of each EXTEND cell should be tagged with `RELAY_EARLY`. +The remaining fragments should not. Relays should accept `EXTEND` cells if and +only if their _first_ fragment is tagged with `RELAY_EARLY`. + +> Rationale: We could allow any fragment to be tagged, but that would give +> hostile guards an opportunity to move RELAY_EARLY tags around and build a +> covert channel. But if we later move to a relay encryption method that +> lets us authenticate RELAY_EARLY, we could then require only that _any_ +> fragment has RELAY_EARLY set. + +# Compatibility + +This proposal will require the allocation of a new 'Relay' protocol version, +to indicate understanding of the RELAY_FRAGMENTED command. +