November contest answer
By stretch | Friday, November 21, 2008 at 1:49 a.m. UTC
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.)
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.
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!
Posted in Announcements
November 21, 2008 at 3:52 a.m. UTC
A very simple way to convert the Unix epoch time is with a system that has Gnu's coreutils, which includes the 'date' command (not sure if this would apply to non-Gnu):
$ <b>date -d @1218006850</b> Wed Aug 6 03:14:10 EDT 2008
November 21, 2008 at 5:10 a.m. UTC
I didn't find the answer but enjoyed the journey.
Props for the awesome contest stretch I certainly had fun.
November 21, 2008 at 10:00 a.m. UTC
Nice, i tried to find something in the telnet session packets and in the cdp and even in the ospf, but could find anything. This one was for the "Gurus" but damn nice for all the others. We want more ;) ( even without prizes )
November 21, 2008 at 12:17 p.m. UTC
nice comp, but just a thought??? all the routers must have approx same time on them or the OSPF MD5 authentication time stamp would throw up issues at the recieving router? can any cisco/encryption gurus throw any light?
November 21, 2008 at 12:35 p.m. UTC
@PatrickB: Nope, the sequence numbers are independent of one another, as they're primarily used simply to prevent replay attacks.
November 21, 2008 at 12:47 p.m. UTC
Very intriguing challenge stretch. This got most of my CCNP class interested, attempting to figure out the correct answer.
Thanks for the brain teaser!
November 21, 2008 at 2:14 p.m. UTC
I missed the start of this contest - looking forward to the next one though.
Will you be doing them on a regular basis?
November 21, 2008 at 7:21 p.m. UTC
Nice contest, Stretch. Took a while to work out it was the MD5 sequence number. Looking forward to the next one.
November 21, 2008 at 10:00 p.m. UTC
Gah! don't know how I buggered the math but I got it down to that... somehow I came up with July 4 '08, which seemed a likely enough answer... but I did it all via "60 seconds/minute/hour/day/year" which was surely the most error-prone method so I guess that's what I get :P
awesome contest though... this is the stuff that teaches you how to FIND a solution, rather than only regurgitating what you've been taught. love it!
November 21, 2008 at 10:52 p.m. UTC
I was on the right path, but I wasn't looking at the right fields. I tried everything I could think of in those OSPF packets except the authentication parts.
Good challenge, Stretch. I look forward to more later.
November 22, 2008 at 12:33 a.m. UTC
@ccielab: Semi-regularly. I'm hoping to squeeze another in sometime early January before I head off to Networkers, but I haven't come up with an idea for it yet.
Glad to hear everyone enjoys the contests! Your comments really make it worth the effort!
November 22, 2008 at 5:25 a.m. UTC
Well color me inattentive when I did that. I forgot to convert to UTC and it gave me EDT for some reason.
$ <b>date --utc -d @1218006850</b> Wed Aug 6 07:14:10 UTC 2008