>> Incidentally, we should only run one introducer at a time. Clients >> will attempt to connect to all of the FURL's "connection hints" >> simultaneously, and the first correct response will win. > > Oh, interesting, I was sure this process was sequential. That's even > better because it makes the attack of creating a rogue introducer by > someone having access to one of the DNS zone present in the furl much > more difficult. This rogue introducer needs to have lower latency than > the regular introducer to be able to attract a majority of the nodes.
The "tubid" portion of the FURL (the first long crypto string, before the @ sign) prevents completely "rogue" introducers: clients will only accept a connection with a server that proves ownership of the corresponding private key. Foolscap is designed to provide full end-to-end security, regardless of attacks at the DNS or IP level. The worst that a network-side attacker can do is to prevent you from connecting to the right server; they can't trick you into connecting to the wrong one. The connections are done in parallel both to speed things up and to get a slight form of path optimization: since the first correct response wins, it favors shorter paths. If you have multiple location hints, and one of them goes through a proxy or something (or the server lives on the same network as you do and one hint is for a local address and the other is for a global one that goes through a NAT port forwarding or something slow), then the faster hint ought to win, resulting in a slightly faster connection for the real data that follows. > I'd prefer if you call it 'volunteergrid.lothar.com' so we won't > confuse the VolunteerGrid with the TestGrid which runs only on > allmydata.com servers. Sure thing.. I wasn't sure which grid this was for. It might be appropriate to *not* set up DNS pointers for the other connection hints. If the primary introducer location (let's call it server[0]) is on francois' machine, and the hint[0] name gets resolved by a DNS service on the same machine (as would be the case for my volunteergrid.lothar.com server), then they share fate: if hint[0] can't be resolved, then server[0] won't be reachable anyways, so you don't win anything by making hint[1] point to server[0]. If/when server[0] goes down, the hint[1]-or-hint[2] name and server[1]-or-server[2] machine can be brought up. This would also reduce the delay incurred by a cached hint[1]->server[0] mapping sticking around for a while, so we could use a kinder 24hour DNS TTL. It'd also be ok to always map the hint[1]/hint[2] to real IP addresses and real ports (for server[1]/server[2]), which just don't happen to be running yet (and wouldn't be started until server[0] goes down). The Foolscap connection mechanism will handle that fine: it'll get Connection Refused from those hints and ignore them. If we wanted to crazy, we could create a meta-introducer: run all three servers at once, let clients connect to one at random, use the meta-introducer to introducer the regular introducers to each other, and flood announcements through all of the introducers. But we might as well do it right and implemented the distributed introducer properly. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
