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

Henning Rogge (spam-protected)
Thu Mar 1 08:01:17 CET 2012

On 02/28/2012 07:59 PM, Wojciech Zabolotny wrote:
>> 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.

I was just thinking about an address selection algorithm that can run 
without a central instance.

> 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.)
You also need an authentication system for the mesh-wide flooding of 
messages of the routing protocol. Thats something which cannot be done 
easily with symmetric crypto.

> 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 
 > (well, I don't know how it would scale up for a network consisting of 
 > 200 nodes covering a small town.)

OLSR don't do better or worse with randomized IPs. It doesn't care. ^^

> 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.

I can see that this should work for unicast in IPv6 networks. IPv4 has 
not enough combinations, generating a fitting public/private key for a 
certain IPv4 address should be doable for an attacker.

If the mesh would be using a /32 IPv6 address range, it would have 96 
bits of 'fingerprint' per node. That should be good enough for most mesh 


If every of this public/private keys is bound to a name, we could use 
this to give each user an ID that is more easy to remember (if the user 
choose to do so).

> 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.

Lets talk more about the flooding/multicast authentication we will need 
for the mesh protocol.

>> 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 

I will try to summarize your proposal...

A) every node generates a public/private key pair
B) every node selects its mesh IP based on the Hash of the public key
C) when a node wants to send unicast traffic to another node the first 
time, it requests the public key from the target node, then use standard 
security protocols like IPsec/OpenVPN to establish a secure end-2-end 

Henning Rogge

Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6156 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120301/02b7d7a2/attachment.bin>

More information about the Olsr-users mailing list