Subject: ntpstamp attribute values

From: Spencer Allain <[email-masked]>
Date: Mon, 27 Aug 2001 15:08:09 -0400

In attempting to deal with subsecond resolution of NTP timestamps and the
conversion between decimal and hexadecimal fractional values, I discovered
that there are no valid examples in the IDMEF Data Model & DTD.

For CreateTime, DetectTime and AnalyzerTimek, the "ntpstamp" attribute
is required.

On page 46 it states:

  "If the date and time represented by the element content and the NTP
   timestamp differ (should "never" happen), the value in the NTP
   timestamp must be used."

Only one set of examples actually has something filled in differently
than the "0x12345678.0x98765432" (which clearly doesn't correspond with
the content form), and unfortunately, it too doesn't match the time
printed in "human" form.

For the CreateTime's starting on page 64, I believe the correct values
should be (when using 8 hexadecimal fractional positions):

Page  Hex Value                   Date/Time String
----  ---------------------       -----------------------------------
[64]  0xbc723b45.0xef449129       2000-03-09T10:01:25.93464-05:00
[65]  0xbc71f4f5.0xef449129       2000-03-09T10:01:25.93464Z
[66]  0xbc72541d.0x00000000       2000-03-09T18:47:25+02:00
[67]  0xbc72b2b4.0x00000000       2000-03-09T15:31:00-08:00
[68]  0xbc7221c0.0x4ccccccc       2000-03-09T08:12:32.3-05:00
[69]  0xbc7221c0.0x4ccccccc       2000-03-09T08:12:32.3-05:00
[70]  0xbc71e980.0x00000000       2000-03-09T08:12:32-01:00
[71]  0xbc72e7ef.0x00000000       2000-03-09T22:18:07-05:00
[72]  0xbc72423b.0x00000000       2000-03-09T15:31:07Z
[74]  0xbc722ebe.0x00000000       2000-03-09T14:07:58Z
[75]  0xbc723b45.0xef449129       2000-03-09T10:01:25.93464-05:00
[89]  0xbdf11a91.0x26666666       2000-12-25T01:00:01.15+00:00

I've checked the code used to do the conversions above with the limited
sample NTP timestamps corresponding to actual written dates and times I
could find on the internet, so the above values should be correct.
Verification of the correctness of the values above should still probably
be done by a second party.

-Spencer

Spencer Allain
Senior Software Engineer
Teknowledge Corporation
3900 Jermantown Road, Suite 100
Fairfax, VA  22030
(703) 352-9300 x207

---

From: Stuart Staniford <[email-masked]>
Date: Mon, 27 Aug 2001 14:20:23 -0700

Thanks Spencer

Dave Curry is about to emit a new version, so hopefully this comment can be
incorporated.  (So this is a particularly good time for any other comments
on the document).

Stuart.

-- 
Stuart Staniford     ---     President     ---     Silicon Defense
         ** Silicon Defense: Technical Support for Snort **
mailto:[email-masked]  http://www.silicondefense.com/
(707) 445-4355 x 16                           (707) 445-4222 (FAX)

---

From: Paul Sangree <[email-masked]>
Date: Mon, 27 Aug 2001 16:35:50 -0500

>[89]  0xbdf11a91.0x26666666       2000-12-25T01:00:01.15+00:00
My conversion from the NTP value to a date & time yields 
2000-12-24T01:00:01.15+00:00 so we differ by 1 day exactly.  Make sure you 
took into account that 2000 is a leap year so you must subtract 1 day since 
the date is after Feb 28.

---

From: Paul Sangree <[email-masked]>
Date: Tue, 28 Aug 2001 09:07:15 -0500

My mistake.  I had a round-off error in my code.
Paul

---

From: Spencer Allain <[email-masked]>
Date: Tue, 28 Aug 2001 10:21:41 -0400

> My mistake.  I had a round-off error in my code.

Thanks so very much for checking my results, as it very well could have
been my code with the problem.  :-)  Bugs creep up everywhere, especially
dealing with date/time conversions.

> > > 2000-12-24T01:00:01.15+00:00 so we differ by 1 day exactly.  Make sure
> > > you took into account that 2000 is a leap year so you must subtract 1
> > > day since the date is after Feb 28.

-Spencer

Spencer Allain
Senior Software Engineer
Teknowledge Corporation