Network Time Protocol

The Network Time Protocol (NTP) often seems like a black box: You set the router or other host to get its time updated and never have to worry about it again. But that begs the question: Why should you care that much about the time on any host?

Why Time Matters

Time matters in the network in a number of ways. For starters, the time that information arrives or a particular action occurs might be important. Examples of these situations are common in the financial industry (time-stamping transactional data), in medical situations (time-stamping medical data), and in many matters involving litigation (what did she know and when did she know it?).

But every network has other tasks that are time sensitive. Most have time-scheduled jobs set to run at certain times (usually known as cron jobs , after the Unix daemon, crond , which manages them). Suppose that your cron job timing is set to use off-peak hours on the network and the jobs are staggered so they never overwhelm your bandwidth. If one or two devices have an incorrect time setting, their cron jobs will execute at a different time than planned. This could cause serious network problems or conceivably cause one or more of the cron jobs to fail.

System logs are referenced by time. That simple statement has profound implications that ripple through the SAFE Blueprint repeatedly. Almost all troubleshooting starts with a problem report, and efforts are made to trace back through time to learn the origin (as well as having someone work to mitigate the current problem, if necessary). If the logs are thick with entries, the easy way to find relevant data is to search for a time stamp close to the problem time and work from there.

If the device's time is wrong, the logs that it creates will have incorrect time stamps on every entry. Finding the right entry will be far, far more difficult.

Now consider that the problem you're troubleshooting is more than simple network connectivity; instead, the problem is that an intruder has somehow gained entry into the customer database server. To disguise his steps, he changes the system time before he alters certain settings or creates an account, to have an available back door at his convenience (perhaps he set the year to be two years earlier). When he's finished, he resets the time to what it should be. Now when you review the logs to figure out what went wrong (probably much later, unless something else happens to make you look hard at that server), you search the log by time stamp and do not notice the account creation.

As a third problem involving time, think a minute about operations that are time based or that have time as a component in changing things. An example might be terminating the lifetime of an IPSec Security Association (SA). A separate timer does not "tick away" the lifetime set for every time-limited process; instead, an expiration date/time is set, based on the designated lifetime duration and start date/time. Suppose that the goal was to disrupt VPN tunnels: If the date and/or time on one tunnel endpoint is advanced (moved forward in time), that device will believe that the tunnel's lifetime is expiring before the other endpoint. One end of the tunnel will renegotiate the SA when it believes that the lifetime has reached 30 seconds remaining, and traffic passage will be interrupted while this occurs. A simple script to reset a device's clock every few minutes (perhaps backward as well as forward) could disrupt a VPN tunnel: Traffic flows and then it doesn't, then it flows again and then it doesn't again. The tunnel would seem to flap as though there were a bad circuit between the two endpoints.

While employed by a major equipment vendor, I used a laptop that began losing time (several minutes per day). The time stamps on my copy of files that were exchanged as part of a collaborative project became less reliable. After much maintenance (including a new battery, which failed to resolve the problem) and lost productivity, the laptop was simply replaced .

Finally, of course, access lists based on time of day can be written and applied to interfaces when it is important to allow access at certain times and deny iteven to the same source-destination-protocol setsat others. System time matters, and it must be system time that you can trust.

Multiple time sources actually are available to a networking device, including its internal battery- powered clock, VINES, and manual configuration. If NTP is available, it is always considered more authoritative , and its value overrides that provided by any other source.

Using NTP

If used, NTP can prevent many of these time problems. It is based on a hierarchical system of time sources, identified by their stratum . This number designates both the level in the time server hierarchy and the accuracy and precision of the time it provides. Stratum 1 sources are the most precise and reliable sources available; they are the root-level time servers. Stratum 1 servers have direct access to an atomic clock or radio source (such as the Global Positioning System, GPS). Cisco devices do not usually have such access and usually do not offer stratum 1 service (although the capability is being added on certain high-end devices). Lower stratum levels are designated by the number of hops away from a stratum 1 source. In addition, some telecom vendors have stratum 3 or even stratum 2 clocking built into their core switches; with periodic checks to a stratum 1 server, these provide time service to connected networks.

Devices running NTP automatically choose to connect with the lowest -stratum server available to them (known to them by configuration); this provides them with the most accurate basis for their clock values. Because time must elapse between the time server sending the update and a time client receiving it, NTP uses UDP over IP (because UDP has less latency than TCP) on port 123. All NTP times are given as UTC, Coordinated Universal Time. Don't forget to configure your time zone and whether to update for daylight saving time (or summer).

NTP peerings are statically configured. Messages are normally unicast between peers, but you can configure devices to send or receive NTP messages via broadcast (although Cisco warns that this reduces the accuracy of the time values used because of the one-way nature of the traffic).

Configuring NTP

NTP support can be configured on both routers and some switches. Some of the newer switches use the IOS commands, while others use the Catalyst commands. Both types of commands are given in the examples that follow.

Router

In configuring NTP on a router, you must specify whether the relationship will be one of peers (time synchronized with each other) or whether the router will treat the other as a server (the router will synchronize to the other's settings). The syntax is

 ntp peer  ip-address  [version  number  ] [key  keyid  ] [source  interface  ] [prefer] 

or

 ntp server  ip-address  [version  number  ] [key  keyid  ] [source  interface  ] [prefer] 

The importance of the optional version numbers , keys, and preference settings is described shortly. You need to configure only one end of the association, whether peer or server. If the other device is NTP-capable, it automatically responds appropriately and forms the association when this device sends an NTP packet.

If you think about that last statement, you begin to realize why NTP must be controlled on the network in some way: Any device that can contact your router could form an NTP association with it and affect your time settings ( especially because NTP is more authoritative than any other source on your router or switch). That's why the SAFE Blueprint spends time (if you'll pardon the expression) worrying about NTP.

Switch

Switches, such as those in the Catalyst series, are NTP clients only. They can receive NTP updates as broadcast clients , or they can actively solicit NTP updates from a server. To receive broadcasts, the commands are as follows :

 set ntp broadcastclient enable set ntp broadcast delay  microseconds  

The latter command is a manual adjustment to compensate for the delay you believe to be present.

If you want your switch to request NTP updates, use these commands:

 set ntp server  ip_addr  set ntp client enable 

Securing NTP

Because time can so easily be manipulated, it is important to control which devices affect the time settings on your network. Cisco recommends two methods : access lists (ACLs) on a router and authentication on both routers and switches.

Access List

To secure NTP with an access list, define the acceptable peers or servers with a standard access list, and then apply the access list to NTP via the access- group command:

 access-list 77 permit host  ip_addr1  access-list 77 permit host  ip_addr2  access-list 77 deny any log 

This is applied via the command:

 ntp access-group peer 77 

Authentication

IP addresses in headers can be spoofed, so it is better to use authentication. Cisco uses MD5 for the NTP authentication method. For both routers and switches, the authentication process must be turned on, at least one key must be established and paired with another NTP device (which, of course, must have the same key), and, in the case of a switch, the NTP client process must have authentication turned on.

For a router, the process looks like this:

 ntp authenticate ntp authentication-key  number  md5  value  ntp trusted-key  number  

The key numbers should match, of course, and the md5 value is the actual key that is used when that key number is invoked.

For a switch, the process looks like this:

 set ntp authentication enable set ntp key  public_key  trusted md5  secret_key  set ntp server  ip_addr  key  secret_key  set ntp client enable 

Again, the key numbers should match (the public_key value), and the secret_key is the actual key used.

NTP Versions

NTP has been available since the late 1980s. Version 2 was the first version that included a limited capability to authenticate NTP peers (per RFC 1119); however, a full authentication capability was not available until NTPv3 (and the SAFE SMR Blueprint cites version 3 as the first to support a cryptographic authentication mechanism). Version 3 also offers improved technical performance of the timekeeping functionality; the features involved are potentially important to more modern, higher-speed links such as Gigabit Ethernet and faster.