[tor-commits] [torspec/master] Update spec with SHOULD/MUST behavior for padding bytes

[nickm@xxxxxxxxxxxxxx]

commit 7b1a76c734e186e50858de52675c50468bd8306a
Author: Dave Rolek <dmr-x@xxxxxxxxxx>
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



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits