This will need breaking down further, it's rather complex. But it solves most of the known major problems with announcement IMHO.
OBJECTIVES: - A newbie node must be able to announce. It's okay to ask for CAPTCHAs at this stage. - An existing node that's been offline must be able to announce, WITHOUT USER INPUT. - A newbie node must get a new location that *it does not choose*. - A newbie node may not keep on creating new locations until it gets one it wants. - No node may announce for another IP than its own. - No node may spam announcements, including seednodes. - Poorly performing and unconnected seednodes should be detectable, and automatically removed. - No seednode should be able to spam announcements. - Becoming a seednode must be as easy as possible. Announcements 2.1: - Bootstrapping and announcement involve the client contacting an additional seednode, which will sign off on the broadcast, so that a malicious seednode can't broadcast an IP it wants to blacklist. Announcements 2.2: - The choice of IP-sign-off seednode must be verifiably random. A malicious seednode with a co-conspirator can still do a bogus broadcast, but only with probability 1/n where n is the number of seednodes. Announcements 3.0: - The list of seednodes should only be available to active seednodes and osprey, not to everyone who announces. - A script on osprey will assign a random set of seednodes on installation. This will have to be fetched by the installer, so it must support proxies etc. Announcements 4.0: - Ideally, the seednodes would network internally via something like a DHT, so even the seednodes wouldn't have the full list, and announcement and bootstrapping would not have to broadcast to every node, only a few. BOOTSTRAPPING ========== For now, the full seednodes list is distributes as it is today. Client node A connects to seed X X checks that A's IP address hasn't bootstrapped recently. A sends X the hash of a nonce, and its pubkey hash. X creates its own nonce and a CAPTCHA. X forwards to seed Y, which creates its own nonce, and returns the hash and a CAPTCHA. Y forwards to seed Z, which creates its own nonce, and returns the hash and a CAPTCHA. (Unless the answer is received quickly, the nonce will be deleted) The hash of all the nonces, and the CAPTCHAs, are returned to A. A solves the CAPTCHAs (it has 3 tries for each, each time a different puzzle). The data is returned up the path to Z, each hop verifying or sending a retry or failing. Z broadcasts the IP address, signed by all involved nodes, so it can't bootstrap again. The choice of nodes must be verifiably random, so that Z can't block IPs it doesn't like, even if it has more than one seednode. All 4 parties un-blind their nonces, and the result is used to derive a location for the new node. The new node's Bootstrapping Certificate is created by the signatures of X, Y and Z and A's pubkey hash. X proceeds with announcing. ANNOUNCING ======== Client node A connects to seed X. A sends its Bootstrapping Certificate and its noderef. X checks that the BC's location is the same as the location on the noderef. [ HYBRID NODES MUST NOT CHANGE LOCATION ] X checks that A has not announced too many times recently (by pubkey hash and IP). X takes a Master Announcement Token off its list. X creates an Announcement Certificate, using its own pubkey and the MAT, and a timestamp. X chooses two other random seednodes, and gets A to contact at least one of them. X forwards the announcement, including the AC, in the current fashion. Responsibilities of individual opennet nodes: - Only forward announcements with a valid AC signed by a seednode on the current seeds list. - Only forward announcements with a valid BC. - Only forward announcements where the noderef matches the BC. - Only forward announcements with a valid MAT. MATs are only valid for a limited period of time, and have a generation number. If generation 21 is seen, generation 20 MATs are only valid for a limited period. - Track the last N MAT's used by any seed. Report immediately if an MAT is reused. - If HTL = 10 on an announcement, insert the MAT to a PSK for that MAT. If it collides, with different data, we know the MAT has been reused. Report this immediately. REINITIALISING ========= When seeds run out of MATs, they reject announcements. The broadcasts allow all seednodes to track the status of all seednodes' MAT queues. When most seednodes' MAT queues are less than half full, ignoring any outliers (e.g. receiving new traffic), it's time to reinitialise. Reinitialisation involves creating new MATs for each seednode. These are created collaboratively via some cryptographic magic, so that: - Any node that knows the current seednodes list can verify that the MATs are valid. - The seednodes all agree on a timestamp for the MATs. This probably involves some sort of N-of-M signature scheme. NEW SEEDNODE ========== An opennet node is eligible to be a seednode if: - The port appears to be forwarded. - Uptime is above some threshold. If an opennet node appears to be eligible, and it hasn't asked before, it asks the user whether to be a seednode. If an opennet node wants to be a seednode, and it's not in the current seednodes list, and hasn't submitted itself for some time, it will submit itself to the seednodes. It does this by contacting 3 of them at random. The seednodes will check IP-based restrictions on seednodes e.g. one seednode per IP etc, limited number per /24. These 3 seednodes each pick a random other seednode, which attempts to contact the new seed. If the new seed is contactable, we do an Announcement Test. If that is successful, the new seednode is broadcasted, and all currently connected seeds attempt to connect to it. If this is successful, the new seednode is accepted into the seednode list. SEEDNODE MONITORING =============== All seednodes maintain connections to all seednodes. The seednodes are a fully connected set. Hence we know when each seednode goes down. Individual opennet nodes track: - The number of incoming announcements signed by each seednode. - The seednodes they have recently announced successfully and unsuccessfully through. This data can be probed randomly by any seednode. If a seednode is sending a lot of announcements, but very few nodes can be found that have announced through it, then the seednode may be spamming. An Announcement Test is a randomly routed request, signed by a seednode, rate limited and using an MAT, which causes a random opennet node to do an announcement. It will accept all the connections obtained by the announcement - if it doesn't need any more connections, it will accept them anyway, but as temporary connections, not routed down, shut down as soon as they are not needed. The results of the announcement are returned to the original seednode. For now, we will need a central authority to decide what the "official" seednodes list is. I haven't worked out all the details yet. But IMHO the most important stuff is covered above.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
