[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] goals for deployable mixnet
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.)
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
but limits to flexibility -- provide good default parameters
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:
reputation / abuse tracking
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.