November contest answer

The entries are in and the contest is over! With well over a thousand downloads of the packet capture, I received 86 entries in total, 44 of which contained the correct answer: 6 August 2008. The answer first appears in packet #31, the first OSPF hello from 10.0.12.1:

From the capture, we can observe that OSPF MD5 authentication is in use. Astute analysts will have noticed that the crypto sequence number in each hello packet increases by one hex digit for every second that passes. For example, compare the sequence number in #31 (0x48994f42) with the hello sent ten seconds later, in #63 (0x48994f4c). The difference between these two values is 0xa, or decimal 10.

Realizing that the OSPF sequence number increases at a rate of 1 per second, the next step is to determine the counter's reference point. As a number of entries correctly pointed out, appendix D of RFC 2328 sheds some light on the issue, specifically section D.3:

This specification does not provide a rollover procedure for the cryptographic sequence number. ... However, it is expected that many implementations will use "seconds since reboot" (or "seconds since 1960", etc.) as the cryptographic sequence number. Such a choice will essentially prevent rollover, since the cryptographic sequence number field is 32 bits in length.

Note that the RFC doesn't enforce a specific implementation of the crypto sequence counter; it only provides an example. However, from experimenting with the date of an IOS router running OSPF, it can be concluded that Cisco chose the UNIX epoch of midnight on 1 Jan 1970 as the reference point for the counter in IOS. In other words, the sequence number is a hexadecimal count of the number of seconds since the UNIX epoch from the router's perspective (according to its system clock). Knowing this, we can use simple addition to arrive at the contest answer:

• 0x48994f42 hex = 1218006850 decimal
• 00:00:00 1 Jan 1970 UTC + 1218006850 seconds = 07:14:10 6 Aug 2008 UTC

Of course, a shortcut is to use a handy converter like epochconverter.com. A number of submissions even included a couple lines of code in Python or PHP to demonstrate the conversion.

(Why 6 August? It's Jon Postel's birthday.)

Winners

Three correct entries were randomly chosen to receive the contest prizes. Congratulations to the following contest winners!

• Pekka Pietikainen
• Wade hansen
• Shane Miller

Each of the above wins a copy of Routing TCP/IP vol 1, 2nd ed. A big thank you to Cisco Press for donating these awesome prizes! I'm sorry I can't give out a book for every correct entry, but I offer my congratulations to everyone else who arrived at the correct answer.

Other answers

Many of the submissions asserted 15 or 16 Nov 2008 as the answer, having been taken from the meta headers in the capture file. Remember, this is merely the time the capture was taken, according to the local clock of the system performing the capture.

A number of people assumed that the clock on the router was simply never set, and concluded that it would default to 1 Mar 2002. Why wouldn't I have set the clock?

Other entries had correctly identified the OSPF crypto sequence number as the key bit of information, but apparently miscalculated the date relative to the epoch offset. A few of the entries had the correct day and month, but listed the year 1998, probably due to assuming the RFC's suggestion of 1 Jan 1960 as the clock reference.

Even if you didn't arrive at the correct answer, I hope you enjoyed the contest, and hopefully you gained a bit of experience in packet sleuthing that you can put to good use in the next contest!