[olsr-dev] olsrd secure plugin

[Bruno Randolf]

hi!

i have made a patch to block arbitrary (configurable) routes from beeing added 
to the kernel routing table some month ago. i have attached it, but it might 
be a bit outdated since i think there have been some changes in the cvs 
recently in this area.

after a discussion with andreas, i had to agree that it is not a good idea to 
include things like this in the official olsr release, since this makes it 
easy to break the routing for the whole network. suppose you block a HNA or 
an other route locally, but other nodes rely on you to reach this 
destination. a counter-argument was, that this blocking of routes would just 
be a measure against routes which are broken anyway. but then if people can't 
even configure their HNA right, they could even create bigger problems if 
they were able to block arbitrary routes.

greetings,
bruno



On Wednesday 23 February 2005 11:44, Sven-Ola Tuecke wrote:
> Hi Andreas,
>
> thanks for your reply. Well, here in Berlin we are working on a small
> registry system to manage IPs and participants. For now, nearly all users
> are cooperative which means there is always a chance to make an email note
> to the one injecting wrong/disfunct HNA4s.
>
> To be prepared for the things to come its always good to have options. One
> of these options will be the secure plugin - we may distribute the key via
> email just to make sure the database entry of a participant is correct. If
> rejecting HNAs is not an option, there are plenty of methods left for
> adjusted responses to administrative/technical problems anyhow.
>
> Regards, Sven-Ola
>
> "Andreas "Tønnesen"" <(spam-protected)> schrieb im Newsbeitrag
> news:(spam-protected)
>
> > Hi Sven,
> >
> > The secure plugin only uses a SHA-1 hash function from openSSL as far as
> > I can remember. I just used the openSSL lib since it is the most
> > widespread lib for theese things. I think it's a good idea to use a much
> > smaller lib, (or perhaps include hashing code in the plugin?). All you
> > really need is a hashing function, so if MatrixSSL supports SHA-1/MD5
> > etc. (which I guess it does), it should work fine :)
> >
> > Regarding your HNA blocking question that is a rather tricky one. This
> > has been discussed before and I belive we came to the conclusion that it
> > would not be supported in officcial olsrd code. The problem is that this
> > kind of functionallity has to be distributed if we are to avoid routing
> > loops. I think the best way is to create a plugin that will broadcast a
> > set of IPs to ignore when parsing HNA messages. But then there is the
> > security issue...
> > I fully agree that this would be a useful feature but IMO it can only be
> > done if it is distributed.
> >
> > - Andreas
> >
> >> Hello oncemore,
> >>
> >> while I'am in questioning mode - the secure olsr plugin rely on the
> >> OpenSSL
> >> library which is really huge (in terms of flash/disk space usage). Is
> >> there
> >> a chance to link it against MatrixSSL?
> >>
> >> Regards,
> >> Sven-Ola
> >>
> >>
> >> _______________________________________________
> >> olsr-dev mailing list
> >> (spam-protected)
> >> https://www.olsr.org/mailman/listinfo/olsr-dev
> >
> > ---------
> > Andreas Tønnesen
> > http://www.olsr.org
> > _______________________________________________
> > olsr-dev mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-dev
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olsr-block_routes.diff
Type: text/x-diff
Size: 8324 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20050223/d3be2a60/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20050223/d3be2a60/attachment.sig>