[olsr-dev] Implementing an attack into olsrd

Bernd Petrovitsch (spam-protected)
Mon Jun 19 11:06:01 CEST 2006

On Mon, 2006-06-19 at 10:42 +0200, Sven-Ola Tuecke wrote:
> using Pub/Priv keypairs is not really an option:

Any other proposal? I fail to see another possibility. And yes, security
is an expensive good ....

> - U need the openssl/matrixssl lib installed (>1Mb footprint)

Well, for exactly one algorithm (which seems reasonable within one mesh
network) it should be much less.

> - Much cpu overhead to calculate keys each time you receive
>   a message (no hardware enc in the WRT), this will kill any
>   embedded box > 2 neighbours.

Hmm, given an unlimited amount of implementation time one can do the
same as PGP/GPG and SSH/SSL does: agree on a symmetric session key and
save lots of computing power.

> - Need to fiddle with all neighbours to fetch their pubkeys ->
>   mesh network is not open any more / very hard to handle
>   the org. Need to setup an Key-Expire-Infrastructure too.

The obivous solutio^Wideas are:
- distribute the keys within OLSR (which needs careful thinking to avoid
  exploits/fakes by evil nodes again).
- define a central place to store the pub-keys "officially" (which is
  meant as: without any possibility of faking) on a HTTP accessible
  place. And since this file must be signed too you need a "official"
  key (IOW: a certificate) also (and you need a certificate in anyway to
  allow packet checking also on the first packets).
  Just downloading the pubkey from the node (as in a really distributed
  open network) opens the possibility of trivial fakes (if no other
  means are taken to avoid this).
And yes, basically this suffers also under the problem of a not-existing

> I think it is more effective, to spot the location of a new
> vandal and make a personal visit with a couple of mesh
> members. In most cases this will be more easy than on the

This will very probably help with (unintentional) configuration errors
but will become significantly difficult with intentionally evil
roaming/mobile nodes. And the legal means to LART them effectively are
quite restricted too (at least in continental Europe) ....

> internet - Wifi range isn't too large...

Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

More information about the Olsr-dev mailing list