From 02049040cd6816ed4893a508a57b61164f9c70ea Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 22 Sep 2011 21:41:18 -0400 Subject: Incorporate Roger's comments into proposal 184 --- proposals/184-v3-link-protocol.txt | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'proposals/184-v3-link-protocol.txt') 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 -- cgit v1.2.3-54-g00ecf