[Olsr-users] Network address associated with fingerprint of the node's public key?

[Wojciech Zabolotny]

On Tue, Feb 28, 2012 at 12:45 PM, Henning Rogge
<(spam-protected)> wrote:
> On 02/28/2012 12:24 PM, Wojciech Zabolotny wrote:
>>
>> Hi,
>>
>> I've experimented a little with spontaneously created mesh networks
>> based on olsr protocol.
>> The idea was, that the net is totally open, without any management
>> nodes (so the network should survive as long as sufficient amount
>> of users is on-line, creating the mesh).
>> Therefore it was also not possible to provide any DHCP server.
>> Everyone could connect selecting any free IP belonging to the pool of
>> the addresses belonging to the network.
>
> Maybe a distributed address distribution could help. Or just switch to IPv6
> and choose your IP based on the MAC address of your WLAN card (or just with
> a random suffix).
>
Unfortunately this can be spoofed as well.
>
>> Unfortunately, such simplistic scheme is not immune against IP
>> conflicts (either occuring due to random selection of IP, or caused
>
>> by malicious intruders trying to destroy the network).
> The random collision could be solved by moving to IPv6. Choosing randomly
> out of a pool of 2^64 addresses should be enough (assuming the network just
> use a /64 prefix).
>
Yes. But the concern is about malicious spoofing targeted on
destroying the network.
>
>> The network could be protected, if the IP address could be associated
>> with the public key of the node (e.g. it could be based on fingerprint
>> of this key).
>
> Hmm...
>
>
>> In this case the intruder could not spoof the particular node, unless
>>
>> he has the secret key associated with public key matching that IP.
>>
>> When maintaining the network, nodes should check, that  the node
>> claiming to have particular IP really has the key pair matching
>> it (by sending challenge encrypted with the public key, and
>> requesting the response).
>
>
> This doesn't solve the spoofing problem, unless you
> a) send a challenge for every packet your receive (and base the challenge on
> the packet)
> or
> b) the sender puts a signature into each packet.
>

OK. So probably it should include generation of symmetric keys for exchange of
packets between each pair of nodes. The challenge-response mechanism should
be used only when establishing the communication between those nodes.
(As you describe it below.)

> For point-2-point traffic this is a little bit easier, source and
> destination can just use their public/private keys to agree on a common
> session key and use it to encrypt and authenticate their data stream (see
> IPsec).
>
> Public/Private key operations are quite expensive in terms of cpu power and
> storage space (in network packets).
>
> The other problem associated with public/private key pairs is that you have
> to know which one is valid.

The key is valid if it matches the IP, which node claims to have (as
described below).

>> Of course it could be difficult to add such mechanism to the IP4 based
>> network (as with less than 2^32 possible IP numbers it could could be
>> possible to generate key matching any selected IP - even though
>> it should be time consuming), but in IPv6 it should be doable.
>> I don't know if this idea is new, neither if it is possible to
>> implement in reasonable way, but it seems interesting...
>
>
> I would suggest NOT following this idea, stay with established cryptographic
> algorithms and protocols. Its very easy to build "crypto protocols" that
> look interesting but are insecure. Do not invent the wheel again, try to use
> the proven wheels others have already looked at and see if they can solve
> your problem.
>
> For your idea to be feasible each node has to have the algorithm to generate
> the private key for each IP, because otherwise it cannot join the network!

In the simplest version, the IP could be just the appropriate number
of bytes from
the fingerprint of the key. So the asymmetric key is generated first, then the
fingerprint is calculted and IP is obtained from it. Of course in this
case the IP
is somehow randow, however in my experiments (up to ca. 20 node) the olsr
protocol could handle fully random IP addresses (well, I don't know how it would
scale up for a network consisting of e.g. 200 nodes covering a small town.)

> And if a valid node can do it, how do you want to prevent the attacker from
> doing it?

The probability, that the attacker would be able to generate the asymmetric key
matching the same IP is almost equal to zero.
I don't want to not allow the intruder to connect. The network is
supposed to be fully open.
What I want to avoid is the spoofing, which allows the attacker to
hijack traffic
and destroy established routes in the mesh.

> Even if you go the way of "choose secret, IP is hashvalue of secret", you
> face the problem of "trust/not trust" an incoming packet. If you don't sign
> every packet (which is A LOT of overhead), you still don't know if the
> packet is from a valid node until you send the challenge and got the
> response.

I think that the above described scheme (IP allocation, encryption of
node to node
communication with negotiated symmetric key) should solve those problems.
Of course it will generate some overhead - is unavoidable price of the
increased security.
>
> If you are still interested in designing a 'secure' mesh, I will be happy to
> continue to discuss it with you.
>

Thanks, generally I'm not involved in development of mesh networking protocols
(I mainly deal with DSP and FPGA based systems)
I simply had an idea, which seemed worth to share.

The main goals of my idea was to provide means to create fully open and
fully decentralized mesh network, which should be immune to attempts
to bring it down either by enforced switching off of the servers
(that's why it should
be fully decentralized) and by destroying of routing by spoofed nodes
(of course,
as the net is fully open, it can be flooded by malicious nodes, but it will only
decrease the performance).

If my idea is simply crazy and useless, sorry for taking your time.
Thanks for all responses,
-- 
Wojtek