commit 02049040cd6816ed4893a508a57b61164f9c70ea Author: Nick Mathewson nickm@torproject.org Date: Thu Sep 22 21:41:18 2011 -0400

Incorporate Roger's comments into proposal 184 --- proposals/184-v3-link-protocol.txt | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/proposals/184-v3-link-protocol.txt b/proposals/184-v3-link-protocol.txt index 910f223..8af15f9 100644 --- a/proposals/184-v3-link-protocol.txt +++ b/proposals/184-v3-link-protocol.txt @@ -51,12 +51,28 @@ Design: Indicating variable-length cells. Design: Variable-length padding.

We add a new variable-length cell type, "VPADDING", to be used for - padding. All Tor instances may send a DROP cell at any point that + padding. All Tor instances may send a VPADDING cell at any point that a VERSIONS cell is not required; a VPADDING cell's body may be any length; the body of a VPADDING cell MAY have any content. Upon receiving a VPADDING cell, the recipient should drop it, as with a PADDING cell.

+ (This does not give a way to send fewer than 5 bytes of padding. + We could add this in the future, in a new link protocol.) + + Implementations SHOULD fill the content of all padding cells + randomly. + +A note on padding: + + We do not specify any situation in which a node ought to generate + a VPADDING cell; that's left for future work. Implementors should + be aware that many schemes have been proposed for link padding + that do not in fact work as well as one would expect. We + recommend that no mainstream implementation should produce padding + in an attempt to resist traffic analysis, without real research + showing that it helps. + Interaction with proposal 176:

Proposal 176 says that during the v3 handshake, no cells other