Mike, In essence, your proposal is functionally equivalent to IP Differentiated Services (DiffServ), RFC 2474. As with DiffServ, your proposal has several shortcomings regarding what you describe as "cheating." It is always in the best interests of an individual client to cheat if it can, and your method for preventing cheating (i.e., checking the port number) will yield both false positives and false negatives. The argument that "this is a good practical measure for now" is tenuous, since there are inevitable side effects that cannot be overlooked. By encouraging cheating, the QoS bit will encouarge the use of random or misleading port numbers in order to fool the port-number-based sanity check. Like other protocols that use port number as a meaningful way of differentiating services, this proposal if implmented will encourage the overloading of specific port numbers for different kinds of purposes, rendering them generally useless. There is a reason why more and more services on the Internet listen on port 80... Next, consider this port-number issue in a greater context: one can think of port numbers as a form of "transport-layer routing," which is to say that when a host receives an IP packet, it determines (demultiplexes) to what process to send that packet based upon its port number. Remember that Tor is ultimately about decoupling identity from routing information; making a gratuitous exception for what is ultimately just routing at the transport layer seems inappropriate and even dangerous. Geoff On Tue, Feb 15, 2005 at 03:46:25AM -0600, Mike Perry wrote: > Thus spake Mike Perry (mikepery@xxxxxxxxxx): > > > > Sure, we accept patches, and do so often. One issue is that we get > > > way more design ideas than we get patches, so we don't always assume > > > that people are going to work on their designs. If you want to get a > > > significant design feature into the main tor distribution, it's > > > usually a good idea to submit a patch to tor-spec.txt first, so we can > > > talk about the actual details of the design before you spend too much > > > time on the implementation. > > > > Ok. I'll see about doing this next. > > Attached. Let me know what you think. The one thing I'm not sure about > is how an OR might determine the version of an OP that connects to it > to satisfy the last paragraph. I'm assuming all OR to OR connections > can check the directory platform string for version info.. But what of > OP to OR? > > -- > Mike Perry > Mad Computer Scientist > fscked.org evil labs > --- tor-spec.txt 2005-02-15 01:38:23.878301675 -0800 > +++ tor-spec.txt.MP 2005-02-15 01:40:28.452287305 -0800 > @@ -112,13 +112,35 @@ > fields: > > CircID [2 bytes] > - Command [1 byte] > + Priority [2 bits] (high bits) > + Command [6 bits] (low bits) > Payload (padded with 0 bytes) [509 bytes] > [Total size: 512 bytes] > > The CircID field determines which circuit, if any, the cell is > associated with. > > + [v0.1.0-Proposed] The Priority field is used to provide a form of QoS > + on the network. Packets are marked with this field according to their > + desired latency: > + 0 -- Unbuffered interactive traffic (ssh, telnet, rdesktop, tcp dns) > + 1 -- Application buffered interactive traffic (web, irc, aim) > + 2 -- Data transfer (ftp) > + 3 -- Bulk Traffic (bit torrent and the rest) > + > + For the time being, this priority field is used only with RELAY cells, and > + all the other commands will have an implicit 0 priority. When RELAY cells > + arrive, low value cells SHOULD be forwarded to the next OR before > + higher value ones. > + > + To avoid 'cheating', exit servers SHOULD verify that the priority fields do > + in fact match the destination port. > + > + These bits MUST be masked off when forwarded to ORs whose platform string > + in the directory is below v0.1.0. To discourage the use of old clients > + to boost bulk traffic priority, this field MUST be set to 3 upon receiving > + cells from an OR or OP whose version is below 0.1.0. > + > The 'Command' field holds one of the following values: > 0 -- PADDING (Padding) (See Sec 6.2) > 1 -- CREATE (Create a circuit) (See Sec 4)
Attachment:
signature.asc
Description: Digital signature