link padding document

[Rachel Greenstadt]

Hi Andrei and Onion-dev folks,
 
   In the course of my work at Harvard this summer and while reading
the discussion here, it has also occurred to me that a rigorous
analysis/taxonomy of traffic padding methods would be useful.
Though, I'd personally like it to be more general in focus....

Some things I've been thinking about (that aren't currently in 
Andrei's document)

- end to end link padding (when is it necessary/possible)
- other reasons that full link padding is impractical (DoS)
- an analysis of traffic shaping as it's been described (what
does it buy you, how do you need to set up the intervals so
that you don't leak too much information)
- If padding changes are there any covert channels/tagging attacks
that can be used to communicate information between corrupt nodes?
- I've been thinking about what you can get with nodes that have
a constant number of neighbors which are fully padded links. 
You ought to gain an exponential level of uncertainty with 
each step in the path and if the path is sufficiently long your 
level of security should be similar to full link padding...I'm told
George has been thinking about similar things (hi george, are you 
here?)  
- it might be a good idea to make the list of things we need to protect
against with link padding more concrete (basically 
anything a passive adversary can do) however, there
are schemes which will hide the amount of bandwidth on each link but
not much else and this might be useful in certain circumstances 
(high efficiency requirements, or if you use some other mechanism
to acheive desirable properties)
- how is the link padding situation different in a cascade situation
like WebMixes?


Anyway, I realize this is a lot of questions and such, but I've been
thinking about the answers and I think they would be good
things to talk about in a document such as the one Andrei mentioned.
I intend to flesh out each of these points as I get time, though 
other people are welcome to do that first.

-Rachel