Keep peers state on edge nodes

[emanuele-f]

Maybe we can avoid sending duplicate information such us the original edge sender (https://github.com/ntop/n2n/blob/dev/n2n_wire.h#L152 which is 19 bytes long) by implementing a mechanism to ask information about another edge node (see https://github.com/meyerd/n2n/commit/ad2d41651006beb180ea35d4e9bd2b98ca7386cf for example) and caching it on the edge nodes. We already have some structures to hold the peers information (https://github.com/ntop/n2n/blob/dev/n2n.h#L219) but an hash table would be more suitable (see https://github.com/meyerd/n2n/commit/a114909d849af3fcdc6bfabcbd6a926da59b95cb for example). Such structure could be passed to the encyption and decryption functions where a specific transop could add specific fields. This would be a transop-independent way of storing and accessing peers state without relying on struct sa of transop_aes for example.

[Logan007]

A few thoughts:

• Where do we get the information about the other nodes from? Do we trust the supernode but for forwarding? The information deposited at the supernode would need to be encrypted and maybe even signed and replay protected (so nobody else could have deposited by just replaying it) which would make it maybe necessary to make the supernode part of the encryption infrastructure. Do we want that? Would we need public key crypto for that? Other than that, the supernode could only hold publicly available data of quite "static" character.
• Maybe the required data could be hold by the edges and delivered encryptedly (if necessary: via the supernode) to the requesting edge triggered by a request that gets distributed via the supernode. That way, the supernode stays off sensitive data.
• Overall packet header could be kept shorter if we did not stick to MAC but some other counting method, maybe a 16 bit number or "hash" that internally gets mapped to the nodes. This of course would limit network size. As far as I can see it, the MACs in the outer packet are for routing purposes only.
• I think we definitely need host-keyed structures (no matter if hashtables, indexed or directly MAC-keyed) for storing connection state & keys (when later generated by DH), feature set (replay attack protection, supported encryption schemes, ...), last time stamp information, ...

[emanuele-f]

For that, I would implement a generic n2n_peer_data request which allows the edges to exchange data (a field specifies the data type). The supernode only acts as a relay. The edge nodes can then encrypt and/or sign payload data as they wish.