|
Size: 1508
Comment:
|
Size: 1548
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 11: | Line 11: |
| {{{ | |
| Line 16: | Line 17: |
| The public key is part of they key pair the register_node uses to register and updates its hnames, therefore there should be only one key pair for each node, but nothing prevents the register node to have multiple key pairs, modify the netsukuku_d code and use them at the same. In this way the register node would have one counter_gnode for each pubk, therefore it can avoid the limit imposed by the counter_gnode. |
The public key is part of the key pair used by the register_node to register and update its hnames, therefore there should be only one key pair for each node. However, nothing prevents the register node to create multiple key pairs, modify the netsukuku_d code and use them at the same time. With this technique, the register node can have a new counter_gnode for each new generated key pair, avoiding in this way the registration limit. |
| Line 30: | Line 34: |
| }}} |
NTK_RFC 0007
Subject: ANDNA counter system based on public key
This text describes a change to the counter_gnode system in ANDNA. It will be included in the final documentation, so feel free to correct it. But if you want to change the system here described, please contact us first.
The counter_gnode is used to prevent massive registrations of hnames by a single node, however there is a bug in the actual protocol. Actually the IP of the counter_gnode is the hash of the public key of the register node. The public key is part of the key pair used by the register_node to register and update its hnames, therefore there should be only one key pair for each node. However, nothing prevents the register node to create multiple key pairs, modify the netsukuku_d code and use them at the same time. With this technique, the register node can have a new counter_gnode for each new generated key pair, avoiding in this way the registration limit. The solution is to calculate the IP of the hash_gnode using the hash of the IP of the register_node. This method was the previously proposed but it was discarded because every time the register_node changes IP it will have a new counter_gnode. The new counter_gnode cannot know how many hnames the register_node registered before so it will accept all the new requests, but in reality, this is not a problem, in fact, the new counter_gnode can accept only 256 hnames, thus the limit is maintained.
related: ["Netsukuku RFC"]