[Olsr-dev] Bug Secure Plugin - Endianness ?

[Roar Bjørgum Rotvik]

Den 14.05.2011 1:19, wrote Henning Rogge:
> Am Freitag 13 Mai 2011, 19:36:51 schrieb Roar Bjørgum Rotvik:
>> What do you believe is "broken" in it's design? Remember that the design
>> criteria was simple, small and low overhead (hence no PKI).
> I don't think there is really an attacker model that would be protected
> against...
>
> if you have an insider attacker, he is already part of your network and a
> shared group key approach does not help.

Sure, but one of the design criteria was that we could trust other 
nodes. This trust was verified by another system that let us distribute 
the group key to a authenticated node. A new node has to authenticate it 
self to existing nodes and if one of the existing nodes can say that it 
"trust" the new node, all other existing nodes in the network trust this 
new node, so we get a chain of trust.

> if your fear outsiders, securing your link layer will be much better than an
> authentication scheme for the routing.

Secure in our context here means message integrity checking, not 
encryption of traffic. Encryption of routing traffic or data traffic was 
not needed or part of our design, it is outside the scope of the secure 
plug-in.

> But the mayor problem I saw when I looked at it is that it works on packet
> level. Packets are not forwarded through the whole network, they are only used
> hop by hop to transfer the messages. This means the signature scheme is only
> hop-by-hop and not end-to-end, which remove the possible advantage over a
> linklayer sollution.

There are some years since we designed this module, so I may not 
remember all the details any more.
But as far as I can remember the decision to use a separate message for 
signature of other olsr messages, was to be compatible with other nodes 
not using the secure plug-in and let non-secured nodes see and use the 
secured nodes olsr messages, allowing secured nodes to participate in a 
bigger olsr ad hoc network (to create a secured subnet within a 
community network as an example).

Wasn't it so that MPR nodes forwarded all other messages, even messages 
that it self could not parse? I remember it that way. So that would let 
MPR nodes without secure plug-in forward signature messages through the 
network so that the secured network would work over several hops.

I may recall this incorrectly, but remember that this was long before 
any optimization of the routing protocol (no ETX, no fisheye, only 
standard rfc routing with MPR nodes).

> I think a possible "secure" transport mechanism for the routing should work on
> the message level, it should encrypt everything of the message after the
> originator and should contain a signature within the encrypted part for the
> whole message except the TTL field.

I understand that you would like a secure plug-in that contains all 
features you seem to need, like encryption and so on.
Anyone is free to implement that, but sometimes a reasonable "guarantee" 
that the routing messages is not tampered with is enough for somebody, 
and in that case the secure plug-in goes a long way. And it was designed 
to use unmodified olsr messages to be able to "integrate" with existing 
ad hoc network.

If you start to encrypt every message, you will get a lot of overhead 
per olsr packet (one packet may contain several messages, each would 
need to be encrypted) plus generate a signature for the whole packet 
(you meant for the whole packet and not per message?) and you would need 
to create proprietary messages that is not understood by nodes not using 
your encryption design.

This may be ok for those requiring encryption, but may not fit small 
embedded boxes with weak CPU's. But feel free to create a new plugin 
that implement your goals, it is open source after all :)

--
Roar Bjørgum Rotvik