On this page
01 Why the NTP server matters to evidence
An NTP server is the source a device consults to set its clock. Every piece of network evidence carries a time written by such a clock: a switch syslog line, a firewall session record, a flow sample, a packet capture, an audit trail, the validity dates on every certificate. None is better than the clock behind it, and a device four minutes fast cannot be aligned with one two minutes slow.
Provenance for a timestamp therefore means two things: the clock was synchronised to a source with a known relationship to UTC, and a record shows it was synchronised when the event occurred. This page in the lane index for wire-level provenance covers how NTP achieves the first, how to prove the second, and where NTP falls short.
02 How NTP works
RFC 5905 defines NTP version 4. Servers form a hierarchy described by stratum. A stratum 1 server is attached to a reference clock, commonly a GPS receiver. A stratum 2 server synchronises to stratum 1 servers, and so on down. Stratum 16 marks an unsynchronised clock and must not be used as a source.
Each exchange records four timestamps, t1 to t4 in RFC 5905: client send, server receive, server send, client receive. Delay is (t4 minus t1) minus (t3 minus t2); offset is half the sum of (t2 minus t1) and (t3 minus t4). The arithmetic assumes a symmetric path; asymmetry becomes error, so a distant server is less accurate than a local one.
A client polls each server every 64 to 1024 seconds, keeps several samples, discards the worst and selects the servers that agree before adjusting its clock. One source is therefore a design fault; the client has nothing to compare it against. RFC 5905 also defines Kiss-o'-Death packets that tell an abusive client to back off.
03 Designing the NTP server hierarchy
Every device that writes a timestamp should get time from a small set of servers you control, and those servers should prove where they got it. Two or more stratum 1 sources are the floor: a GPS-disciplined appliance in each of two sites, or GPS plus a national service upstream. The NIST Internet Time Service page describes its public servers, which make a good second source alongside GPS.
Below them sit two to four internal stratum 2 servers running chrony or ntpd, each using all the stratum 1 sources. Everything else points at that set: every switch, router, balancer, firewall, collector and certificate authority. If the sFlow collector's clock is wrong every sample is mis-timed at ingest, and the sFlow sampling and collector reference assumes agent and collector agree on time.
Monitoring closes the loop. Poll each device's offset and stratum, and alert when offset exceeds a threshold suited to the device (10 ms for a switch, 1 ms for a collector) or stratum hits 16. The SNMP MIB tables for network devices show which objects expose this.
04 Authenticated NTP with RFC 8915 NTS
Plain NTP has no authentication; anyone on the path can spoof replies, shift a client's clock, revive expired certificates and make every log line lie. RFC 8915, Network Time Security, fixes this in two phases. The client first performs NTS key establishment over TLS on TCP port 4460, receiving cookies and keys and verifying the server's certificate, then sends NTP over UDP with extension fields that authenticate each packet.
The result is a time source with a verified origin: the client knows which server answered because its certificate chained to a trusted CA. Deploy NTS from the stratum 2 servers to their upstreams and to any device that supports it; older switch firmware often offers only RFC 5905 symmetric keys, still better than nothing.
Where sub-microsecond agreement matters, trading floors, telecom backhaul and some industrial control, IEEE 1588 Precision Time Protocol replaces NTP, timestamping packets in hardware at the switch port and requiring PTP-aware switches on the path. Most network evidence does not need it.
05 Trusted timestamping with RFC 3161
NTP proves what time a device thought it was. It cannot prove to a third party that a file existed at that time. RFC 3161, the Time-Stamp Protocol, fills that gap: a client sends a document's hash to a Time Stamping Authority (TSA), which returns a signed token binding the hash to the TSA's time. Anyone holding the token, the document and the TSA's certificate can later verify the document existed no later than that time.
It is the right tool for any archive that may become evidence. Sealing log files is covered in the tamper-evident edge log procedure; the RFC 3161 token anchors that seal to an external clock.
| Source | Proves | Does not prove |
|---|---|---|
| Unsynchronised clock | Nothing | Event order across devices |
| Public pool NTP | Tracked some Internet server within tens of ms | Which server; that replies were not spoofed |
| Internal NTP, symmetric key | Replies came from a holder of the shared key | Server identity to a third party |
| NTS (RFC 8915) | Replies came from a server certified by a trusted CA | That a file existed at a given time |
| RFC 3161 token | A hash existed no later than the TSA's signed time | Anything about the device's own clock |
06 Worked example: aligning three devices
A review needs to establish when 198.51.100.23 first spoke to 203.0.113.9. Three records exist: a switch port-security event, a firewall session record and a mirror-port capture, disagreeing by minutes.
Monitoring history holds the offsets: the switch ran +142 s after a reboot that briefly picked a wrong source, the firewall -0.003 s, and the capture host, a VM with NTP disabled, -38 s. The switch line reads 10:14:52, the firewall session start 10:12:31.410, the capture's first SYN 10:11:53.218.
Correcting each by its recorded offset gives 10:12:30 for the switch (one-second syslog resolution), 10:12:31.413 for the firewall and 10:12:31.218 for the capture. They agree within the second, and only because offsets were recorded at the time; an estimate made afterwards does not survive cross-examination.
$ chronyc sources -v MS Name/IP address Stratum Poll Reach LastRx Last sample ^* ntp1.example.net 2 6 377 12 +18us[ +21us] +/- 412us ^+ ntp2.example.net 2 6 377 14 -31us[ -28us] +/- 455us ! IronWare switch side, illustrative FastIron(config)# clock timezone gmt gmt+00 FastIron(config)# sntp server 192.0.2.10 FastIron(config)# sntp server 192.0.2.11 FastIron# show sntp associations
^* marks the selected source and 377 shows eight polls answered. Older Foundry switches speak SNTP, a simplified client acceptable at the leaf; the syntax is in the IronWare command reference by task.
07 Steps to make network timestamps defensible
Establish two stratum 1 sources
Install a GPS-disciplined NTP appliance in each of two sites and add a national time service upstream as a check.
Build the internal stratum 2 layer
Run two to four servers with chrony or ntpd, each using every stratum 1 source, NTS toward upstreams, and an internal CA certificate for NTS clients.
Point every device inward
Configure every switch, router, balancer, firewall, collector and hypervisor to use only the stratum 2 servers; block outbound UDP 123 from all else.
Log in UTC everywhere
Store timestamps in UTC with an explicit zone marker on every device; convert only for display.
Record offset and seal archives
Poll offset and stratum into monitoring with the same retention as the logs. When archive files close, hash them and store an RFC 3161 token beside them.
08 Pitfalls: local time, VMs, single sources
- Local time in logs. Local time produces one ambiguous hour each autumn and one missing hour each spring, and sites in different zones cannot be aligned without each device's zone setting.
- Trusting the hypervisor. A VM's clock follows the host through pauses, migrations and snapshots. Run an NTP client in the guest against the internal servers.
- A single upstream. One stratum 1 source that drifts, loses GPS lock or is spoofed takes the estate with it; the RFC 5905 selection algorithm needs three sources to reject a bad one.
- Logging before first sync. A switch writes timestamps from its power-on default until its first NTP exchange; log the first successful sync.
Every other record in this lane inherits its timestamps from this page. Syslog lines carried over TLS to a central collector and pcap files with nanosecond timestamps and a custody record are both worthless as a timeline if the devices that wrote them disagreed about the time.
09 Questions
What is an NTP server?
A host that answers NTP requests with its current time and a stratum indicating how it obtained that time. A stratum 1 server has a reference clock attached; a stratum 2 server synchronises to stratum 1 servers. Clients query several and follow the agreed time.
How accurate is NTP?
On a LAN with an internal stratum 2 server, offsets well under a millisecond are normal. Over the Internet, tens of milliseconds is typical and asymmetry adds more. For microsecond agreement, IEEE 1588 PTP with hardware timestamping is used instead.
Is the public NTP pool good enough for evidence?
It is far better than an unsynchronised clock and fine for ordering events to the second, but it cannot prove which server answered or that replies were unaltered. For records you may need to defend, run internal servers with NTS to authenticated upstreams.
What does RFC 8915 NTS add?
Authentication. NTS performs a TLS key exchange on TCP port 4460, then authenticates each NTP packet with extension fields, so a client can verify the server's identity through its certificate and detect altered replies, the on-path spoofing plain NTP cannot see.
When do I need RFC 3161 instead of NTP?
When you must prove to a third party that a file existed at a specific time. NTP only makes your own clocks agree. An RFC 3161 token from a TSA binds the file's hash to a signed external time that anyone can verify later without trusting your clocks.
A record is only as good as the clock that stamped it, and the clock only as good as its source. Two reference sources, an internal NTP server layer with NTS, UTC everywhere, a record of offset and an RFC 3161 token on the archive turn a timestamp into evidence.