[Olsr-dev] Bug Secure Plugin - Endianness ?
Roar Bjørgum Rotvik
Sun May 15 23:00:25 CEST 2011
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
> 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
> 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
More information about the Olsr-dev