commit 7b1a76c734e186e50858de52675c50468bd8306a Author: Dave Rolek dmr-x@riseup.net Date: Wed Jul 18 21:00:38 2018 +0000

Update spec with SHOULD/MUST behavior for padding bytes

In doing so, specify a general behavior for padding bytes in Section 3 and cross-reference other locations to this, to aid in future consistency.

Also clarify a few vague parts of the prior wording.

Fixes #26860. --- tor-spec.txt | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tor-spec.txt b/tor-spec.txt index ea195ad..705b159 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -477,7 +477,9 @@ 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 payload is padded with 0 bytes. + 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.

PADDING cells are currently used to implement connection keepalive. If there is no other traffic, ORs and OPs send one another a PADDING @@ -1479,7 +1481,9 @@ see tor-design.pdf.

The 'Length' field of a relay cell contains the number of bytes in the relay payload which contain real payload data. The remainder of - the payload is padded with NUL bytes. + the unencrypted payload is padded with padding bytes. Implementations + handle padding bytes of unencrypted relay cells as they do padding + bytes for other cell types; see Section 3.

If the RELAY cell is recognized but the relay command is not understood, the cell must be dropped and ignored. Its contents