[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

path spec



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