[Olsr-users] secure plugin bug
Victor
(spam-protected)
Wed Jan 23 01:02:13 CET 2008
Hi,
I think theres a bug in the secure plugin code though I'm not 100% sure
since it seems to be so blatantly obvious I would have thought it would have
been detected by now. I'm running the secure plugin on 3 freifunk routers
called 104.3.69.1, 104.3.67.1 & 104.3.210.1. For short I'll call them 69, 67
and 210.
>From observing the control messages that the routers are putting out the
current network configuration is as such.:
67 <------> 69 <-----> 210
The output from the debug output (olsrd -d 9) does not seem to correlate at
all with what the routers are doing.
The following is the output from all 3 routers:
----------------------------------------------------------------------------
----------------------------------------------------------------
104.3.67.1
----------------------------------------------------------------------------
----------------------------------------------------------------
[ENC]Checking packet for challenge response message...
[ENC]Match for 104.3.69.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.69.1!
[ENC]Rejecting packet from 104.3.69.1
[ENC]Checking packet for challenge response message...
[ENC]Match for 104.3.210.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.210.1!
[ENC]Rejecting packet from 104.3.210.1
----------------------------------------------------------------------------
----------------------------------------------------------------
104.3.69.1
----------------------------------------------------------------------------
----------------------------------------------------------------
[ENC]Checking packet for challenge response message...
[ENC]Challenge message received
[ENC]To: 104.3.69.1
[ENC]No match for 104.3.67.1
[ENC]Challenge: 0xadffdb2b
[ENC]Signature verified
[ENC]Building CRESPONSE message
[ENC]Challenge-response: 0xed5ec767
[ENC]Timestamp 1200976984
[ENC]Sending challenge response to 104.3.67.1 challenge 0xed5ec767
[ENC]Adding signature for packet size 60
[ENC]timestamp: 1200976984
[ENC] Message signed
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
[ENC]Checking packet for challenge response message...
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
[ENC]Checking packet for challenge response message...
[ENC]Response-response message received
[ENC]To: 104.3.69.1
[ENC]Signature verified
[ENC]Match for 104.3.67.1
[ENC]Entry-challenge 0xed5ec767
[ENC]Error in response signature from 104.3.67.1!
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
[ENC]Checking packet for challenge response message...
[ENC]Challenge message received
[ENC]To: 104.3.69.1
[ENC]No match for 104.3.67.1
[ENC]Challenge: 0xadffdb2b
[ENC]Signature verified
[ENC]Building CRESPONSE message
[ENC]Challenge-response: 0xed5ec767
[ENC]Timestamp 1200976984
[ENC]Sending challenge response to 104.3.67.1 challenge 0xed5ec767
[ENC]Adding signature for packet size 60
[ENC]timestamp: 1200976984
[ENC] Message signed
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
[ENC]Checking packet for challenge response message...
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
[ENC]Checking packet for challenge response message...
[ENC]Response-response message received
[ENC]To: 104.3.69.1
[ENC]Signature verified
[ENC]Match for 104.3.67.1
[ENC]Entry-challenge 0xed5ec767
[ENC]Error in response signature from 104.3.67.1!
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
INTERNET GATEWAY VIA vlan1 detected in routing table.
[ENC]Adding signature for packet size 20
[ENC]timestamp: 1200976985
[ENC] Message signed
[ENC]Checking packet for challenge response message...
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
----------------------------------------------------------------------------
----------------------------------------------------------------
104.3.210.1
----------------------------------------------------------------------------
----------------------------------------------------------------
[ENC]Checking packet for challenge response message...
[ENC]Match for 104.3.67.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.67.1!
[ENC]Rejecting packet from 104.3.67.1
[ENC]Checking packet for challenge response message...
[ENC]Match for 104.3.69.1
[ENC]Message from non-validated host!
[ENC]Timestamp missmatch in packet from 104.3.69.1!
[ENC]Rejecting packet from 104.3.69.1
----------------------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------------
As you can see the out all 3 routers seem to be ignoring each other though
their control messages tell a different story ie.
67 <------> 69 <-----> 210
It seems to me that the routers are sending the challenge and challenge
responses back and forth correctly but the response response always fails:
[ENC]Error in response signature from 104.3.67.1!
Furthermore despite the failure will still forward those routers in their TC
messages etc.
In fact, now that I think about it I have so far only once seen a pair of
routers with debug outputs indicating that they are accepting each other as
valid routers whilst their control messages said the opposite story.
The bottom line is that debug output does not match what the routers is
actually doing.
Another issue I have run into is if you restart a router it appears that the
other routers will not drop that router from their timestamp database for a
long long time. So when the restarted router comes back online the other
routers think it's a replay attack and discard all packets from it. This is
why 67 and 210 are not connected despite the fact that are sitting ontop of
each other on a stack.
>From what I've observed it takes hours for them to drop the restarted router
from the database. I'm wondering if this is a bug or a design aspect. I'm
thinking more bug as I would imagine that you would instead want to just
drop the original timestamp from the restarted router and send a new
challenge message. I acknowledge though that this could make the network
more vulnerable to a denial of service attack.
I know that the secure plugins have not been properly tested and are still
fairly buggy (see
http://lists.olsr.org/pipermail/olsr-users/2006-March/001499.html) . However
if someone could just confirm what I'm seeing then I'd be happy to accept
that and fix the problems myself. I need the secure plugin to work in a
fairly stable manner for my thesis project and I'd be glad to share the code
once its done.
Thanks
Victor Kuo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20080123/b1ee518a/attachment.html>
More information about the Olsr-users
mailing list