[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r6996: Add a comment about v0 fallback approach. Why did we dislike (in tor/trunk: . doc)
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] r6996: Add a comment about v0 fallback approach. Why did we dislike (in tor/trunk: . doc)
- From: nickm@xxxxxxxx
- Date: Wed, 9 Aug 2006 02:41:30 -0400 (EDT)
- Delivered-to: archiver@seul.org
- Delivered-to: or-cvs-outgoing@seul.org
- Delivered-to: or-cvs@seul.org
- Delivery-date: Wed, 09 Aug 2006 02:41:38 -0400
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Author: nickm
Date: 2006-08-09 02:41:29 -0400 (Wed, 09 Aug 2006)
New Revision: 6996
Modified:
tor/trunk/
tor/trunk/doc/tor-spec.txt
Log:
r7056@Kushana: nickm | 2006-08-08 23:40:53 -0700
Add a comment about v0 fallback approach. Why did we dislike discriminating on X.509 certs again?
Property changes on: tor/trunk
___________________________________________________________________
Name: svk:merge
- 1f724f9b-111a-0410-b636-93f1a77c1813:/local/or/tor/trunk:8207
c95137ef-5f19-0410-b913-86e773d04f59:/tor/branches/eventdns:7014
c95137ef-5f19-0410-b913-86e773d04f59:/tor/branches/mmap:7030
c95137ef-5f19-0410-b913-86e773d04f59:/tor/branches/oo-connections:6950
+ 1f724f9b-111a-0410-b636-93f1a77c1813:/local/or/tor/trunk:8207
c95137ef-5f19-0410-b913-86e773d04f59:/tor/branches/eventdns:7014
c95137ef-5f19-0410-b913-86e773d04f59:/tor/branches/mmap:7030
c95137ef-5f19-0410-b913-86e773d04f59:/tor/branches/oo-connections:6950
c95137ef-5f19-0410-b913-86e773d04f59:/tor/branches/versions:7056
Modified: tor/trunk/doc/tor-spec.txt
===================================================================
--- tor/trunk/doc/tor-spec.txt 2006-08-09 00:58:27 UTC (rev 6995)
+++ tor/trunk/doc/tor-spec.txt 2006-08-09 06:41:29 UTC (rev 6996)
@@ -138,8 +138,8 @@
additional fields to existing structures; implementations are constrained
to ignore fields they do not expect.
- Parties negotiate OR connection versions as described below in section
-
+ Parties negotiate OR connection versions as described below in sections
+ 4.1 and 4.2.
2. Connections
@@ -305,14 +305,23 @@
0 when the other side is recognized as a router running version
0.1.2.??-alpha or earlier.
- If a server finds that it wants to send a cell (for example because a
+ [If a server finds that it wants to send a cell (for example because a
circuit wants to extend to that client, and the TLS connection
is already established) yet no cell has arrived yet, we can't
distinguish between a version 0 client and a slow network. We can't
assume that the other side approves of version 0, so we can't just
start using version 0. Perhaps the right answer is to then launch a
- new TLS connection because you don't have a usable one after all?
+ new TLS connection because you don't have a usable one after all? -RD]
+ [That would seem to be thrashy. Let's see if we can do better. Remember,
+ normal v0 clients always send something after connecting, so if we have
+ had a connection for a while and gotten nothing over it, we could get away
+ with assuming it's bad. Alternatively, we could identify V0 clients by
+ the OU=Tor field in the certificates: we don't check for it, and we never
+ documented it. We might break other people's clients by sending them
+ hello cells, but only if those clients are nonconformant. Am I right?
+ In any case, this seems way more reliable. -NM]
+
5. Circuit management
5.1. CREATE and CREATED cells