Re: understanding problem, hidden services

[grarpamp <grarpamp@xxxxxxxxx>]

Ok, I think it could be written as:
Each endpoint must always be in control three nodes, with whoever
chose the meetme using that as their third.

Assuming meetme's don't apply in other areas of Tor, I suppose it
could be further clarified as:

Each endpoint must always be in control of three nodes.
The Server uses the IP as its third.
The Client uses the RP as its third.

So for each step in the process it seems like this:

# S inits 3 IP's
S -> SR1 -> SR2 -> IP
# S publishes descriptor
S -> SR1 -> SR2 -> SR3 -> DB
# C requests descriptor
C -> CR1 -> CR2 -> CR3 -> DB
# C inits RP
C -> CR1 -> CR2 -> RP
# C informs S of RP
C -> CR1 -> CR2 -> CR3 -> :IP <- SR2 <- SR1 <- S
# S uses RP
S -> SR1 -> SR2 -> SR3 -> RP
# full path established = 6 relays, 7 hops
C -> CR1 -> CR2 -> RP: <- SR3 <- SR2 <- SR1 <- S

The colon delimits the end of each sides control in the full path.
The arrows are build extensions, not traffic.

For the full Client-Server paths, I did not name the relays uniquely
as 'OR1, OR2, OR3, ORa, ORb' as you guys have done, because there's
no guarantee that they are used only once in such a path. AFAIK,
it's possible to have: C -> R1 -> R2 -> RP: <- R1 <- R3 <- R2 <- S

Note the reuse of relays R1 and R2 in arbitrary positions. The only
constraint that holds is that the Client and Server each choose
their own unique relays independantly. I've corrected that above
by calling out who chose them and their uniqueness within that. I'd
definitely do that too in the new spec/page clarification.

Does the code check that since S could be thought to consider RP
as just a destination beyond its "controlled exit" of SR3, and RP
is also just another relay from which S can build circuits, that
RP is in fact excluded from being any of its three relays? In other
words, this might be bad: S -> SR1 -> SR2(really RP) -> SR3 -> :RP ...
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/