Accepting packets from nodes with very old localtime

[Ben West]

I've been testing a TP-Link TL-MR3020 running OpenWRT Attitude Adjustment
v12.09, albeit custom compiled to include the recent release olsrd
v0.6.5.4. This particular device has no internal hardware clock (not
unusual for low-cost consumer-grade wifi routers), and it does consistently
boot up with local time at 1 Jan 1970, which I've found causes other nodes
to reject its OLSR packets.

Here is a snippet from the olsrd debug output on the gateway node for this
TP-Link node:

Recevied hash:
...
Calculated hash:
...
[ENC]Match for 5.201.40.204
[ENC]Timestamp slack: -2147483648
[ENC]Timestamp scew detected!!
[ENC]Timestamp missmatch in packet from 5.201.40.204!
[ENC]Rejecting packet from 5.201.40.204
[ENC]Adding signature for packet size 20
[ENC]timestamp: 1369027304
Signature message:
10 0 0 36
5 49 3 43
1 0 136 112
1 2 0 0
81 153 178 232
249 200 155 145
129 37 154 191
125 220 118 79
67 201 81 35
[ENC] Message signed
INTERNET GATEWAY VIA eth0 detected in routing table.
[ENC]Checking packet for challenge response message...
Input message:
10 0 0 36
5 201 40 204
1 0 132 58
1 2 0 0
0 0 3 146
210 5 117 73
30 93 35 39
117 64 115 152
167 254 218 235

Although the choice to reject all incoming OLSR packets with substantial
time offset is understandable for security concerns, this creates a
chicken-and-egg problem when using OLSRd to provide routes to nodes that
happen to always power-up with local time set to the beginning of the UNIX
epoch, and which thus depend on a valid route to set their local time via
ntp.

Indeed, this policy of rejecting old packets appears to not be observed
consistently, since I can still trick the gateway node's OLSRd instance
into accepting incoming packets from the TP-Link by manually setting the
TP-Link's local time to something still not current (tested with 30 April
2009). If OLSRd must throw away old packets for security reasons, is there
really a difference between a packet that is 4 years old vs 33 years old?

Besides that, is it possible to somehow disable timestamp checking for
incoming OLSR packets? Or is this a drawback of using the (now presumably
outdated) secure plugin?

For reference, the gateway node was a UBNT Nanostation Loco M2 running the
same OpenWRT/OLSRd combination as the TP-Link. Here is the
/etc/config/olsrd I used:

config olsrd
option IpVersion '4'
option LinkQualityLevel '2'
option LinkQualityAlgorithm 'etx_ffeth'
option SmartGateway 'yes'
option Pollrate '0.2'
option UseHysteresis 'no'
option TcRedundancy '2'
option MprCoverage '7'

config LoadPlugin
option library 'olsrd_arprefresh.so.0.1'

config LoadPlugin
option library 'olsrd_dyn_gw.so.0.5'

config LoadPlugin
option library 'olsrd_dyn_gw_plain.so.0.4'

config LoadPlugin
option library 'olsrd_secure.so.0.6'
option Keyfile '/etc/olsrd.d/olsrd_secure_key'

config LoadPlugin
option library 'olsrd_txtinfo.so.0.1'
option accept '0.0.0.0'

config Interface
list interface 'mesh'
option Mode 'mesh'
option Ip4Broadcast '255.255.255.255'

[Henning Rogge]

Post by Ben West
I've been testing a TP-Link TL-MR3020 running OpenWRT Attitude Adjustment
v12.09, albeit custom compiled to include the recent release olsrd v0.6.5.4.
This particular device has no internal hardware clock (not unusual for
low-cost consumer-grade wifi routers), and it does consistently boot up with
local time at 1 Jan 1970, which I've found causes other nodes to reject its
OLSR packets.

If I understand the code right the neighbors of the OLSR node should
forget the last stored timestamp after 30 seconds with no valid
packet.

Post by Ben West
Besides that, is it possible to somehow disable timestamp checking for
incoming OLSR packets? Or is this a drawback of using the (now presumably
outdated) secure plugin?

If you disable the timestamps you will be open to replay attacks,
which are a trivial way to disrupt your network.

The alternative would be to use some kind of linklayer-security, it
would offer you practically the same security for OLSR than the secure
plugin, most likely even more.

Henning Rogge

--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

[Ben West]

Hi Henning,

Thank you for the explanation. I do try to use link-layer security where
available (e.g. IBSS-RSN encryption), but would still prefer to retain
security mechanisms at other layers too.

Since OLSRd seems to still accept incoming packets whose timestamps are
only a couple years or so out of date, I am able to work-around this
problem by having such nodes run this delightful kludge in /etc/rc.local.
This kludge just takes advantage of the firmware typically having written
recently something to /etc/somewhere/current, and strips out the most
recent file timestamp.

# This is a hack to set localtime to something current enough so that
# remote a OLSRd instance will accept packets from this node.

# Get date/time components of most recent filemod under
/etc/somewhere/current
FILELISTING=`ls -l -u -e /etc/somewhere/current | tail -1`
[ -n "${FILELISTING}" ] && {
FILEMOD_YYYY=`echo $FILELISTING | awk '{printf "%d", $10}'`
FILEMOD_HHMMSS=`echo $FILELISTING | awk '{printf "%s", $9}'`
FILEMOD_DD=`echo $FILELISTING | awk '{printf "%s", $8}'`
FILEMOD_MONTH=`echo $FILELISTING | awk '{printf "%s", $7}'`

# Convert Month to numerical MM format
case "${FILEMOD_MONTH}" in
"Jan") FILEMOD_MM="01" ;;
"Feb") FILEMOD_MM="02" ;;
"Mar") FILEMOD_MM="03" ;;
"Apr") FILEMOD_MM="04" ;;
"May") FILEMOD_MM="05" ;;
"Jun") FILEMOD_MM="06" ;;
"Jul") FILEMOD_MM="07" ;;
"Aug") FILEMOD_MM="08" ;;
"Sep") FILEMOD_MM="09" ;;
"Oct") FILEMOD_MM="10" ;;
"Nov") FILEMOD_MM="11" ;;
"Dec") FILEMOD_MM="12" ;;
*) FILEMOD_MM="01" ;;
esac

# Set local date/time, assuming format "YYYY-MM-DD hh:mm:ss"
DATE="${FILEMOD_YYYY}-${FILEMOD_MM}-${FILEMOD_DD} $FILEMOD_HHMMSS"
date -s "${DATE}"
}

Again, I'm not sure why OLSRd or OSLRd + secure plugin chooses to reject
packets with timestamp (T - 40years), but still accept packets with
timestamp (T - 2years). The kludge above would render this security
provision moot, right?

Post by Ben West

Post by Ben West
I've been testing a TP-Link TL-MR3020 running OpenWRT Attitude Adjustment
v12.09, albeit custom compiled to include the recent release olsrd

v0.6.5.4.

Post by Ben West
This particular device has no internal hardware clock (not unusual for
low-cost consumer-grade wifi routers), and it does consistently boot up

with

Post by Ben West
local time at 1 Jan 1970, which I've found causes other nodes to reject

its

Post by Ben West
OLSR packets.

If I understand the code right the neighbors of the OLSR node should
forget the last stored timestamp after 30 seconds with no valid
packet.

Post by Ben West
Besides that, is it possible to somehow disable timestamp checking for
incoming OLSR packets? Or is this a drawback of using the (now

presumably

Post by Ben West
outdated) secure plugin?

If you disable the timestamps you will be open to replay attacks,
which are a trivial way to disrupt your network.
The alternative would be to use some kind of linklayer-security, it
would offer you practically the same security for OLSR than the secure
plugin, most likely even more.
Henning Rogge
--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

[Henning Rogge]

Post by Ben West
Hi Henning,
Thank you for the explanation. I do try to use link-layer security
where available (e.g. IBSS-RSN encryption), but would still prefer to
retain security mechanisms at other layers too.

Just to tell you, if you use IBSS-RSN the secure-plugin will give you no
additional security at all.

Post by Ben West
Since OLSRd seems to still accept incoming packets whose timestamps are
only a couple years or so out of date,

Hmm... I wonder if this could be an integer underflow/overflow problem.

But a 32 bit integer in seconds should not have this problem. It should
be okay until ~2038.

Post by Ben West
I am able to work-around this
problem by having such nodes run this delightful kludge in
/etc/rc.local. This kludge just takes advantage of the firmware
typically having written recently something to /etc/somewhere/current,
and strips out the most recent file timestamp.

Henning Rogge