commit 46bc41bb1b0c00ec4b898d03f936d5c9d9c3fdef Author: teor teor@torproject.org Date: Fri Jul 20 11:44:29 2018 +1000
tor-spec: Prop#289: RELAY cell padding should be randomised
Updates tor-spec for 26871 --- tor-spec.txt | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/tor-spec.txt b/tor-spec.txt index 666bc93..114d13c 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -482,9 +482,24 @@ see tor-design.pdf. drop the cell. Since more cell types may be added in the future, ORs should generally not warn when encountering unrecognized commands.
- The cell is padded up to the cell length with padding bytes. Senders - SHOULD set padding bytes to NUL and receivers MUST ignore their - value. + The cell is padded up to the cell length with padding bytes. + + Senders set padding bytes depending on the cell's command: + VERSIONS: Payload MUST NOT contain padding bytes. + AUTHORIZE: Payload is unspecified and reserved for future use. + Other variable-length cells: + Payload MAY contain padding bytes at the end of the cell. + Padding bytes SHOULD be set to NUL. + RELAY: Payload MUST be padded to PAYLOAD_LEN with padding bytes. + Padding bytes SHOULD be set to random values. + Other fixed-length cells: + Payload MUST be padded to PAYLOAD_LEN with padding bytes. + Padding bytes SHOULD be set to NUL. + We recommend random padding in RELAY cells, so that cell content is + unpredictable. See proposal 289 for details. For non-RELAY cells, TLS + authenticates cell content, so randomised padding bytes are redundant. + + Receivers MUST ignore padding bytes.
PADDING cells are currently used to implement connection keepalive. If there is no other traffic, ORs and OPs send one another a PADDING