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

[Roar Bjørgum Rotvik]

On 02/28/2012 12:31 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

[ deleted text ]

> I don't know whether this idea is new, neither if it is possible to
> implement in reasonable way,
> but it seems interesting...

Hi,

Automatic IPv4 address allocation in OLSRD mesh is implemented and
tested before: http://olsr-paa.sourceforge.net/

"Olsr ProActive Autoconfig is a software solution to enable IPv4 address
autoconfig in a ad hoc/mesh network using the flooding mechanism in
olsr.org"

Design document (ASCII):
http://olsr-paa.svn.sourceforge.net/viewvc/olsr-paa/trunk/paa/PAA-DOC?view=markup

I'm one of the authors behind PAA, and have tested this on a network
with about 20 nodes, and up to 3 or 4 hops.

This was some years ago, I see that the design paper is dated back in
2004. It worked with olsrd version 0.4.3, but as this was part of a time
limited project at my work, it is not updated to work with newer
versions of OLSRD and only works for IPv4.

While the PAA design document describes the details, this is an overview
of how it worked:
- PAA client allocated unique link local IPv4-adress (169.254.x.y)
- Using this address it broadcasted a request for address
- If an existing PAA node answers with an address:
  - Flood this address with a address_test within the mesh (using OLSRD
flooding mechanism)
  - If no negative answers, use this address
  - If negative answer (address already in use in the mesh), restart
address request
- If no answer from existing PAA-node, take a address and start PAA
daemon (assume you are the first node)
- Now with a valid IPv4-address, start OLSRD.

We had an idea to use the flooding mechanism in OLSRD to perform DAD
(Duplicate Address Detection) instead of inventing another mechanism,
since these flooded messages should reach every node in the mesh.
During startup we uses link local addresses, it is easy to make those
unique within 1-hop neighbours until we obtain a IPv4 address.

The reason for using a standalone PAA daemon that worked together with
OLSRD was to separate the address allocation from OLSRD and wait to
start up OLSRD until the node had a valid IPv4 address.

As I said, this is not an active project any more and would require some
tuning in the paa-plugin to make it work with newer OLSRD (api-changes
for plugins).

It does not have a 100% solution for network merges where address
duplication may happen, I think at least one of the conflicting nodes
would change IP address, that may cause some problems with running
applications or existing data streams like TCP.. But this problem
remains no matter what DAD solution you use.

At least it may give you a hint of what others have done before.

We also made the secure-plugin at the same time, it was supposed that
new nodes during address detection phase would authenticate itself to
the existing nodes (group key, certificate or similar solution), and
then all nodes would sign their own olsr messages with a static group
key (via the secure-plugin), so only authenticated nodes would be able
to participate in this mesh. It was more like a proof of concept, but
not implemented in this PAA solution.

Regards,
Roar Bjørgum Rotvik