[freehaven-dev] goals for deployable mixnet

[Roger Dingledine <arma@mit.edu>]

Summary: we have some goals below. Our end goal is to turn these into
  a spec which Gerald can build. Can somebody take the first steps
  of dividing these into topics (perhaps new threads) that we need to
  discuss, and pointing us in the right direction for each of them?

As the first draft of goals, we went through the zks-desiderata and
decided which ones we want and which ones we don't want, and then added
a few topics that aren't covered in that document. Our overall goal is
to come up with an extensible flexible system which we can actually 
deploy. It doesn't need to be perfect at the beginning, and we don't
even need to have a clear path to making it perfect. That's because none
of the systems out there are perfect, and all the people who could make
them better are working on solving the really hard problems. People have
solved some of the intermediary problems, but nobody has implemented any
of them yet because they move on to the harder problems. So the things
that are actually deployed are many years old and suck.

Things we don't want to deal with: (and it's not clear how to add
  correctly, even down the road)

We don't want to handle all tcp/ip stuff. Just an application-level
  bouncer or something is good enough.
Mixing. We're just tunnelling, like the freedom system.
'exit relay' concept -- we don't have the concept of 'exit relay' or
  'entry relay', so we can't make them behave differently. (but see
  later about service-specific entry relays.) 
ipv6
multiple certifiers, cert chaining
no guaranteed QoS
no fundamental economic routing/market crap
no required padding as protocol
don't worry about abuse policies, etc.

Things we want:
  (not all at once, obviously. which ones are needed for first
   round implementation/deployment, and which can be just stubs?)

everyone a relay
no single point of failure
client picks parameters
  Flexible number of hops
  paths
  etc
but limits to flexibility -- provide good default parameters
NAT/firewall support
bandwidth throttling
dynamic routing, QoS support (but probably not do anything more than just
  what tcp provides)
introducers -- consider efficiency, routing growth
  topology management as the system grows
infrastructure should be extensible for research:
  micropayments
  reputation / abuse tracking
  payment bonds
forward secrecy
fair and equitable metadata distribution -- that is, we need a system
  for making sure metadata gets to the people who need it.
"good" timeouts. this is an implementation issue, but boy is it important.
can we get bounds on topology effects from lots of people joining/leaving?
clean migration/protocol negotiation paths
pluggable client algorithms
key management. hee hee. make this trivial to begin with.
meeting place / reply blocks / addresses
  we need "some way of getting to other people".
    both other mix nodes, and also people connecting into the mix.
  we can make this pluggable/abstract, such that we can do the easy
    "everybody knows every" approach at the beginning, and plug in a
    subdivided chords current-address ring solution later (to make
    reply blocks obsolete) if we get it to work.