We were trying to figure out some criteria for selecting intro points and rendezous points as well as circuits to connect to them and had some questions we couldn't determine from our poking around for answers. Does anyone know for current stable code (and, e.g., post 224 etc. if any of this is expected to change) the following?
Are guards ever selected for intro points? Are exits ever selected for intro points? Are guards ever selected for rendezous points? Are exits ever selected for rendezvous points?
Are client circuits to intro points selected from prebuilt circuits? If so, is the third hop an exit relay? Or is a prebuilt circuit cannibalized in some way to avoid using an exit?
Are client circuits to rendezvous points selected from prebuilt circuits? If so, is the third hop an exit relay? Or is a prebuilt circuit cannibalized in some way to avoid using an exit?
Fuller answers (e.g., 'Yes. guards can be selected as intro points, but only in accord with their chance of being selected as a middle relay.') and/or where to find these in documentation appreciated.
If someone knowledgeable feels this is better directed at tor-dev, please let me know (or simply reply there rather than here).
aloha, Paul
On 17 Jun (15:42:36), Paul Syverson wrote:
We were trying to figure out some criteria for selecting intro points and rendezous points as well as circuits to connect to them and had some questions we couldn't determine from our poking around for answers. Does anyone know for current stable code (and, e.g., post 224 etc. if any of this is expected to change) the following?
Some stuff below could change for 224. We haven't got there yet since these are the last building blocks (client/service). But I believe most of it will stay the same.
Are guards ever selected for intro points? Are exits ever selected for intro points?
Any node can be picked as an IP.
Are guards ever selected for rendezous points? Are exits ever selected for rendezvous points?
Any node can be picked as a RP and the choice is weighted.
The requirement for both the IP and RP nodes are (from the code):
CRN_NEED_UPTIME | CRN_NEED_DESC | CRN_NEED_CAPACITY
<b>CRN_NEED_UPTIME</b> is set in flags and any router has more than a minimum uptime, return one of those.
<b>CRN_NEED_DESC</b> is set in flags, we only consider nodes that have a routerinfo or microdescriptor -- that is, enough info to be used to build a circuit.
<b>CRN_NEED_CAPACITY</b> is set in flags, weight your choice by the advertised capacity of each router.
Are client circuits to intro points selected from prebuilt circuits? If so, is the third hop an exit relay? Or is a prebuilt circuit cannibalized in some way to avoid using an exit?
Multiple scenarios are possible. Client always try to have 3 preemptive internal circuits that is the last hop does NOT need to be an exit but could be. They then can be cannibalized and extended to the IP.
If the introduction fails at the first IP, the circuit is reused and extended to an other IP ultimately going up to 6 hops if I'm not mistaken because:
G -> M -> M -> IP1 -> IP2 -> IP3
Keep in mind that:
Guard and Exit are also Middle so they can be picked at any point in the chain.
Exit are _never_ Guard.
Are client circuits to rendezvous points selected from prebuilt circuits? If so, is the third hop an exit relay? Or is a prebuilt circuit cannibalized in some way to avoid using an exit?
Yes, it can be from the preemptive circuits that are internal so exit as a 3rd hop.
Fuller answers (e.g., 'Yes. guards can be selected as intro points, but only in accord with their chance of being selected as a middle relay.') and/or where to find these in documentation appreciated.
If someone knowledgeable feels this is better directed at tor-dev, please let me know (or simply reply there rather than here).
Yeah, I believe tor-dev@ would have been more appropriate but it's fine.
Cheers! David
aloha, Paul _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
tor-onions@lists.torproject.org