[Olsr-dev] Bug Secure Plugin - Endianness ?

[Henning Rogge]

On Sun May 15 2011 23:00:25 Roar Bjørgum Rotvik wrote:
> 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.

The problem I see with this is that most people don' get the abilities and 
limitations of this security concept.

Hop-by-Hop trust/security should be done one the link layer if possible in my 
opinion.

> 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).
Yes, this limitation of the olsr v1 packet format can really be a pain for 
many things.
 
> 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.
Yes it is that way... but your signature messages have TTL 1, so they are not 
forwarded.

If I understand the plugin code right, the "authentication message" is just a  
good idea to work around the limitations of the packet format.

> 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.
No, I was talking about "per message" signatures (or encryption)...  so that 
you can distribute the message with its signature over the whole mesh.

Some kind of end-to-end authentication (and maybe encryption) for the meshs 
routing messages.
 
Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20110516/39f01f6e/attachment.sig>