Hi,
this is a first go at a path spec. Please let me know if it's useful at
all or what should be changed.
$Id$
MIX3:path-spec
Type III (Mixminion) Path Specification
Status of this Document
This draft describes a proposed format of path specifications
for Type III (Mixminion) paths. It is not a final version.
It has not yet been submitted to any standards body.
Abstract
This document describes a way to specify paths that a packet should
take through the Type III network. It defines both the syntactical
format of path specifications as well as how implementations should
interpret them.
======================================================================
Table of Contents
Status of this Document
Abstract
Table of Contents
1. Introduction
2. Format
3. Interpretation
1. Introduction
A path specification defines a path that packets travel through the
Type III network.
2. Format
A path specification is string consisting of one or two leg
specifications, separated by a single colon. A leg specification is
a list of of one or more path components, separated by commas. Each
path component specifies either a node by nickname, a given number of
random hops, or a normal distributed number of random nodes.
Whitespace before and after separators is ignored.
The format of nicknames is defined in dir-spec. To specify a number
of random nodes "*n" is used, where n is the number of random hops.
To specify a normal distributed number of random nodes "~n" is used.
Here is a grammar:
PathSpec ::= LegSpec | LegSpec OptSpace ":" OptSpace LegSpec
LegSpec ::= PathComponent | LegSpec OptSpace "," OptSpace PathComponent
PathComponent ::= ByNickname | RandomHops | GaussianHops
ByNickname ::= <a nickname as defined in dir-spec>
RandomHops ::= "*" [0-9]+
GaussianHops ::= "~" [0-9]+
Space ::= " " | "\t"
OptSpace ::= | OptSpace Space
3. Interpretation
To build a path from a given path specification we build a list of
hops from the single path components. In case of a GaussianHops path
component, we pick a number from the random distribution with the
specified mean and standard deviation 1.5.
If there are random hops in the path, they should be filled in using
this algorithm: First, the last hop is chosen from the servers
recommended by the directory that support delivery of the payload
(SMTP, From headers, Fragmentation, etc.). Note that the same last
hop needs to be used for all packets of a fragmented message.
Then we go through the other hops, starting at the second to last
going to the first, choosing random servers from the recommended
servers' list. Care must be taken to ensure that pairs of adjacent
hops can talk to each other. A hop A can talk to another hop B if A
has an Outgoing/MMTP section, B has an Incoming/MMTP section and they
support a common MMTP protocol version. Implementations should avoid
selecting the same server twice in a row.
[XXX: what about Allow/Deny ACLs? - PP]
[XXX: I think that Allow Deny lines should also allow
giving host names since we now have FWD_HOST routing types.
Clients should not have to lookup the ip addresses of nodes,
in fact I think they SHOULD NOT do a lookup if they don't
deliver directly to it. - PP]
Because users may be behind fascist firewalls or be limited by other
constraints, clients may limit their choice of first hop to hops they
can talk to. Such limit must not influence the choice of any other
hops.
[XXX: I don't think that checking if a client can talk to a hop
leaks any info. An adversary can always learn that we want
to send a message once we actually send it. However an
active adversary can easily limit our choice of first hops,
so this should receive some consideration. - PP ]
If we need two legs in case of a simple forward anonymous messages
and no crossover point is specified, it is placed in the middle of
the path, rounding up the first leg and rounding down the second.
Peter
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred. | : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `- http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature