[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[minion-cvs] Finish integrating bursty MMTP and DNS into the spec.

To: mixminion-cvs@freehaven.net
Subject: [minion-cvs] Finish integrating bursty MMTP and DNS into the spec.
From: nickm@seul.org (Nick Mathewson)
Date: Thu, 4 Sep 2003 12:14:04 -0400 (EDT)
Delivered-to: archiver@seul.org
Delivered-to: mixminion-cvs-outgoing@seul.org
Delivered-to: mixminion-cvs@seul.org
Delivery-date: Thu, 04 Sep 2003 12:14:14 -0400
Reply-to: mixminion-dev@freehaven.net
Sender: owner-mixminion-cvs@freehaven.net
Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/tmp/cvs-serv16386

Modified Files:
	dir-spec.txt minion-spec.txt spec-issues.txt 
Log Message:
Finish integrating bursty MMTP and DNS into the spec.

Index: dir-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/dir-spec.txt,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- dir-spec.txt	3 Sep 2003 16:01:43 -0000	1.13
+++ dir-spec.txt	4 Sep 2003 16:14:02 -0000	1.14
@@ -319,7 +319,15 @@
    
         'Version': The string '1.0'
 
-        'IP': An IPv4 address, in dotted-quad format.
+        'IP': An IPv4 address, in dotted-quad format.  [Deprecated but
+        necessary as of Mixminion 0.0.6; will be removed in favor of
+        'Hostname' in Mixminion 0.0.7.]
+
+        'Hostname': A fully qualified hostname, or an IPv4 address in
+        dotted-quad format.  [New in Mixminion 0.0.6.  As a temporary
+        hack, clients SHOULD assume that servers with hostnames can send
+        *FWD/HOST messages, and that servers with IPs can send
+        *FWD/IPv4 messages.]
 
         'Port': A port at which IP accepts incoming MMTP connections.
 

Index: minion-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/minion-spec.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- minion-spec.txt	22 Aug 2003 01:17:59 -0000	1.11
+++ minion-spec.txt	4 Sep 2003 16:14:02 -0000	1.12
@@ -481,8 +481,8 @@
    0x0000 DROP    (0 octets of routing information)
    0x0001 FWD/IP4 (IP: 4 octets, PORT: 2 octets, KEYID: 20 octets): 26 octets
    0x0002 SWAP-FWD/IPV4 (same info as FWD/IP4)
-   0x0003 FWD/IP6 (IP: 16 octets, PORT: 2 octets, KEYID: 20 octets): 38 octets
-   0x0004 SWAP-FWD/IPV6 (same info as FWD/IP6)
+   0x0003 FWD/HOST (PORT: 2 octets, KEYID: 20 octets, NAME: variable width)
+   0x0004 SWAP-FWD/HOST (same info as FWD/HOST)
 
    0x0100-0x0FFF: PREDEFINED DELIVERY TYPES.
 
@@ -506,12 +506,19 @@
    field contains the SHA1 hash of the ASN.1 representation of the
    next node's identity public key.
 
-   A SWAP routing type tells the node to exchange headers as described below.
-
-   The FWD/IP6 and SWAP-FWD/IP6 routing types are analogous to FWD/IP4
-   and SWAP-FWD/IP4, except that they use IPv6 addresses rather than
-   IP4 addressed.  Path generation in this case is an open issue.
+   A SWAP routing type tells the node to exchange headers as described
+   below.
 
+   The FWD/HOST and SWAP-FWD/HOST routing type are analogous to
+   FWD/IPV4 and SWAP-FWD/IPV4, except that they expect fully qualified
+   hostnames rather than IPv4 addresses.  Servers SHOULD not block
+   while resolving the hostnames.  [The *FWD/HOST family first appears
+   in Mixminion 0.0.6, and is meant to replace *FWD/IPV4.  Mixminion
+   0.0.7 and later will not generate or accept *FWD/IPV4 messages.  If
+   a server is addressed via a static IPs, it should use a dotted quad
+   as their hostname.  As of Mixminion 0.0.7, the types formerly
+   associated with *FWD/IPv4 will become unallocated.]
+   
    See 'E2E-spec.txt' for more information about SMTP and MBOX delivery.
 
 3.2.2. Header Structure
@@ -983,12 +990,12 @@
      * B sends "RECEIVED", CRLF, HASH(M|"RECEIVED") (10 + 20 octets)
 
        [Note that A SHOULD NOT wait for B's reply before sending
-        further packets; rather, A SHOULD sending its next packet
-        immediately.  Node B SHOULD NOT send a reply until it has
-        committed the packet to local storage, and Node A SHOULD NOT
-        remove the packet from local storage before it has it has
+        further packets; rather, A SHOULD start sending its next
+        packet immediately.  Node B SHOULD NOT send a reply until it
+        has committed the packet to local storage, and Node A SHOULD
+        NOT remove the packet from local storage before it has it has
         received B's reply.  Node A MAY pause if it is waiting for 16
-        hashes at a time.]
+        or more hashes at a time.]
 
   * Padding case:
 

Index: spec-issues.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/spec-issues.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- spec-issues.txt	22 Aug 2003 01:18:00 -0000	1.5
+++ spec-issues.txt	4 Sep 2003 16:14:02 -0000	1.6
@@ -24,10 +24,10 @@
             Status of this Document                                    X
    0.       Meta-issues
    1.       Issues in MIX3:1: 'minion-spec.txt'
-   1.1.     Disposition of 'DROP' messages -- RESOLVED
+   1.1.     Disposition of 'DROP' messages -- CLOSED
    1.2.     Generation of dummy messages and link padding
    1.3.     Recommended pooling rule -- RESOLVED
-   1.4.     Hostnames versus IPs -- RESOLVED, NEED SPEC
+   1.4.     Hostnames versus IPs -- CLOSED
    1.5.     IPv6 -- RESOLVED, NEED SPEC
    1.6.     Denial-of-service prevention -- DEFERRED
    1.7.     Bursty MMTP
@@ -40,6 +40,7 @@
    2.6.     News -- RESOLVED, NEED SPEC
    2.7.     PKI bootstrapping 
    2.8.     Multiple recipients
+   2.9.     Plaintext payload versioning
    3.       Issues in MIX3:3: 'dir-spec.txt'
    3.1.     Directory agreement
    3.2.     Integrated pinging
@@ -61,19 +62,7 @@
 
 1. Issues in Mix3:1: 'minion-spec.txt'
 
-1.1. Disposition of 'DROP' messages -- RESOLVED
-
-   We need to specify: are 'DROP' messages dropped before they go
-   into the mix pool, or after they're pulled from the pool?
-
-   [Before. -NM]
- 
-   [My feeling is After, but I should think about it... -GD]
- 
-   [Roger seemed pretty sure that it should be 'before', but I don't
-      remember why.  Roger? -NM]
-
-   [RESOLVED 3Aug: "Before".  Roger will tell us why.]
+1.1. Disposition of 'DROP' messages -- CLOSED
 
 1.2. Generation of dummy messages and link padding
 
@@ -105,51 +94,7 @@
    [RESOLVED 3AUG: Stick with binomial timed dynamic pool until we
      get something better.]
 
-1.4. Hostnames versus IPs -- RESOLVED, NEED SPEC
-
-   In the current specification, we address servers only by IP.  While
-   this approach prevents DNS-related attacks against the mixnet, it
-   wreaks havoc with any attempt to run a server with a dynamic IP.
-
-   Although it is possible to incorporate dynamic-IP servers in the
-   current scheme (for example, nodes could re-address messages to a
-   server's new IP upon learning of the new IP via a fresh directory
-   publication), such approaches basically amount to reinventing a
-   broken, high-latency DNS clone.
-
-   Thus, I think that instead of using an IP address in FWD and
-   SWAP-FWD subheaders, we should use a hostname instead.  Nodes should
-   cache the result of the lookup until a connection fails, in order to
-   prevent spoofing attacks.
-
-   [Peter says we should use TTLs instead so you can move a server
-   without shutting down the old one.  Sounds good.]
-
-   Pro:
-      - Servers with dynamically assigned IP become viable.
-      - Changing a server's IP no longer delays traffic until the
-        change propagates to the directory.
-
-   Con:
-      - The server codebase must become more complicated in order to 
-        efficiently perform and cache DNS lookups while resisting
-        DNS-related lockups.  (But note that any other solution to
-        the dynamic-IP problems would also require a significant amount
-        of server code.)
-      - An attacker who can compromise a node's DNS could block some of
-        the traffic intended for that node until the DNS was restored.
-
-   Nonissues:
-      - We don't need to worry about attackers stealing or destroying
-        traffic by compromising DNS, since MMTP is authenticated.
-  
-                                      -- Nick
-
-   [3Aug: We decided to allow administrators to provide either
-     hostname or IP at their discretion.  I need to come up with a
-     migration plan and modify minion-spec.txt to say the right
-     thing. -NM]
-    
+1.4. Hostnames versus IPs -- CLOSED
 
 1.5. IPv6 -- RESOLVED, NEED SPEC
 
@@ -302,6 +247,17 @@
 
    [3Aug: <=8 addresses.  If client gets more than 8, divides into N/8
      messages.  Eliminate dups at client; dups at server are error.]
+
+2.9. Plaintext payload versioning
+
+   We should burn a byte or two for a version number on plaintext
+   payloads.  This way, we have some hope of changing to a better 
+   fragmentation algorithm in the future, or what have you.
+   
+   Doing this doesn't break the key property that forward payloads
+   can be recognized as okay, but that corrupt payloads, reply
+   payloads, and encrypted payloads are indistinguishable except to
+   their recipients.
 
 3. Issues in MIX3:3: 'dir-spec.txt'
Prev by Author: [minion-cvs] Sketch out work for 0.0.6
Next by Author: [minion-cvs] Hopefully-not-too-bogus answers to more questions
Previous by thread: [minion-cvs] Sketch out work for 0.0.6
Next by thread: [minion-cvs] Hopefully-not-too-bogus answers to more questions
Index(es):
- Author
- Thread