[Olsr-dev] olsrd web of trust plug-in

[(spam-protected)]

On Mon, Dec 22, 2008 at 7:38 PM, Henning Rogge <(spam-protected)> wrote:
> On Montag 22 Dezember 2008 18:04:07 you wrote:
>> > If you just do "link based" security (you authentificate that the
>> > packages you receive are send by the one-hop neighbor it pretends to be)
>> > an attacker can just use his legal key to "retransmit" a forged packet.
>> > The attacker will just pretend that he got a package from someone else
>> > and you have no chance to validate it's claim.
>>
>> Yes, that's right. But otherwise each node should store all the public
>> keys of the other nodes in the network (or download a key each time it
>> needs it), and, unless we use synchronized time (argh), to prevent
>> replay attacks, perform a timestamp exchange with every other node in
>> the network...
> Replay attacks can be prevented by sequence numbers I think, unless the
> attacker controls all communication between two stations.

Two ways of using sequence numbers come to my mind:
1) use a message sequence numbering associated to a single node. That
is sequence numbers incremented at each new outgoing OLSR message.
In this case, a node joining the network should know somehow the
current sequence numbers of other nodes, which probably brings us to a
protocol very similar to the timestamp-exchange protocol;
2) use a message sequence numbering associated to a couple of nodes.
That is, each node keeps a different sequence number associated to
each destination node, for example departing from zero. Each time that
node A sends an OLSR message to node B, it must increment the sequence
number associated to node B.
The drawbacks are that this does not work with multicast, and that if
a node reboots, then the sequence numbers' status is lost.


>> But if we put ourselves in a community network scenario, we can just
>> focus on outsider attacks and assume that the neighboring nodes that
>> we know and trust will not act maliciously against us.
>> (In fact the title of my thesis, "Trusted routing in OLSR MANETs" is
>> wrong. It should have been something like "Trusted routing in Wireless
>> Community Networks", but thanks to italian bureocracy the title
>> couldn't be changed... :/ )
> I think community based networks are very VULNERABLE against insider
> attackers. An attacker who plans to disrupt a larger mesh net will have to use
> lot's of resources (time, work, equipment) to do it... so it's very likely the
> attacker will just join the network.

This may be partially prevented through PGP's web of trust model:
trust is associated to other node's keys not automatically but
manually by each node owner. So, to join the network and have her/his
messages considered, an attacker should perform a "social attack",
partecipating to the social life of the community, gaining the other
members' trust, having her/his public key signed by these members and
then acting maliciously against them.

By the way, I forgot to point out another problem. Actually, the
implementation leaves to olsrd the burden of route calculation. Then,
at the end, the plug-in re-gains control and inserts these routes into
different routing tables. This is not correct, as in this way olsrd
does not take into account trust when computing routes. The correct
way of doing it should be replicating the local link information base
and the topology set for each different level of trust, and then
computing routes separately on these different information bases. But
I don't know if implementing this as a plug-in still makes sense...

Bye,
Clauz