My Cart
Hello Brian and Brian,
This email is long overdue, but I just wanted to let you both know that I passed my CCIE R&S exam a couple of months back. I used the IE workbook and found it extremely useful throughout the preparations.
Thank You very much for the help, guidance and above all, the great workbook. CCIE number 16803 is mine to keep............now I need to go get paid for it........;)
Thanks Again
Imran Moin
CCIE #16803
CCIE Lab Preparation Resources
Understanding Network Time Protocol (NTP) Authentication
by: Brian McGahan, CCIE #8593
Introduction:
Network Time Protocol (NTP) is a UDP based protocol used to synchronize time clocks amongst network devices. NTP is especially useful to ensure that timestamps on log messages are consistent throughout the entire network. NTP is a standards based protocol, and is defined in RFC 1305, Network Time Protocol Version 3.
NTP uses a stratum, or hop count, in order to determine how close a device is to a master time source. A lower stratum is better, and devices with a stratum of 1 are assumed to be the authoritative time source. Devices which receive their time directly from a stratum 1 device have a stratum of 2, and so on and so forth.
Time advertisements in NTP are always sent in UTC, also known as Greenwich Mean Time (GMT). Time zone information is always locally significant to a device running NTP.
Since NTP is used to ensure accurate log file timestamp information, NTP poses a security risk. If malicious users were able to falsify NTP information passed over the network, timestamp information could be falsified to the advantage of said attacker. In order to deal with this vulnerability, NTP optionally implements an authentication mechanism.
To implement an attack on NTP, a hacker could make a rogue host appear to be a valid NTP server, and inject false time into the network. Therefore, the NTP authentication model is opposite of the typical client-server authentication model.
NTP authentication is used to authenticate the time source, not the recipient.
Objective:
To demonstrate how NTP authentication works in Cisco IOS™ software
Overview:
R1 and R2 are Cisco® 2610 series routers running Cisco® IOS™ version 12.2(15)T5. R1 will be configured as an NTP master clock with a stratum of 1. R2 will be an NTP client of R1. The following combinations of NTP authentication will be used to demonstrate the proper configuration:
Note: The NTP specification dictates that a client can only update its clock a certain amount of time per clock period.
<RFC 1305>
The local-clock process operates upon the offset data produced by the update procedure and adjusts the phase and frequency of the local clock using the mechanisms described in Section 5. This may result in either a step-change or a gradual phase adjustment of the local clock to reduce the offset to zero.
</RFC 1305>
The key phrase to note is that the adjustment "may result in either a step-change or a gradual phase adjustment of the local clock to reduce the offset to zero." This means that depending on how far off the local clock is, the local device will either completely replace the local clock with the value that the peer is advertising (step change) or move the local clock closer and closer to what is being advertised (gradual phase adjustment).
A common problem when configuring NTP is that synchronization takes a long time. Also, you may have noticed in your studies that NTP will synchronize after reloading your routers. The reason that synchronization happens immediately after the reload is because the 2x00 series routers don't have a hardware clock. This means that when they reload, the clock is reset to the default (00:00:00 UTC Mon Mar 1 1993). Since the NTP devices in question now have clocks that are relatively close to each other, the gradual phase adjustment and synchronization process will happen very quickly.
On the other hand, if the local clock is very different than the clock source, it may take a long time for this gradual adjustment to happen, hence a long time until synchronization.
To solve this problem, make sure that you configure the correct time (in UTC) on all devices before starting NTP configuration. This will ensure that the change in offset during synchronization is minimal, hence a short time to synchronization.
Case I: No authentication
Configuration:
R1:
R1#clock set 00:00:00 1 Jan 2000 R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ntp master 1
R2:
R2#clock set 00:00:00 1 Jan 2000 R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#ntp server 12.0.0.1
Verification:
R1#show ntp status
Clock is synchronized, stratum 1, reference is .LOCL.
nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz,
precision is 2**18
reference time is BC17C2B4.EDC6DA36 (00:03:00.928 UTC Sat Jan 1 2000)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.02 msec, peer dispersion is 0.02 msec
R2#show ntp status
Clock is synchronized, stratum 2, reference is 12.0.0.1
nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz,
precision is 2**18
reference time is BC17C2BC.B07E8007 (00:03:08.689 UTC Sat Jan 1 2000)
clock offset is 1.1910 msec, root delay is 3.42 msec
root dispersion is 2.20 msec, peer dispersion is 0.98 msec
As we can see from the above output, R1 is the master server with a stratum of 1, whose reference clock is the local device. R2 is synchronized with the clock 12.0.0.1, and has a stratum of 2.
Case II: Authentication on Master (R1) Only
Configuration:
R1:
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ntp master 1 R1(config)#ntp authenticate R1(config)#ntp authentication-key 1 md5 CISCO
R2:
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#ntp server 12.0.0.1
Verification:
R1#sh ntp status Clock is synchronized, stratum 1, reference is .LOCL. nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz, precision is 2**16 reference time is BC17C241.A9F22584 (00:01:05.663 UTC Sat Jan 1 2000) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.02 msec, peer dispersion is 0.02 msec R2#sh ntp status Clock is synchronized, stratum 2, reference is 12.0.0.1 nominal freq is 249.5901 Hz, actual freq is 249.5900 Hz, precision is 2**16 reference time is BC17C238.6FBA7873 (00:00:56.436 UTC Sat Jan 1 2000) clock offset is 0.2074 msec, root delay is 3.33 msec root dispersion is 0.26 msec, peer dispersion is 0.03 msec R2#sh ntp association detail 12.0.0.1 configured, our_master, sane, valid, stratum 1 ref ID .LOCL., time BC17C201.AAC02E8E (00:00:01.666 UTC Sat Jan 1 2000) our mode client, peer mode server, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.03, reach 377, sync dist 1.724 delay 3.33 msec, offset 0.2074 msec, dispersion 0.03 precision 2**16, version 3 org time BC17C238.6F5ABAA7 (00:00:56.434 UTC Sat Jan 1 2000) rcv time BC17C238.6FBA7873 (00:00:56.436 UTC Sat Jan 1 2000) xmt time BC17C238.6EDB7F53 (00:00:56.433 UTC Sat Jan 1 2000) filtdelay = 3.33 3.33 3.34 3.36 3.33 3.36 3.33 3.33 filtoffset = 0.21 0.19 0.18 0.16 0.16 0.13 0.13 0.11 filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12
As we can see from the above output, R1 is the master server with a stratum of 1, whose reference clock is the local device. R2 is synchronized with the clock 12.0.0.1, and has a stratum of 2. Although authentication is enabled on the master, this session has not been authenticated.
Case III: Authentication on Client (R2) Only
Configuration:
R1:
R1#clock set 00:00:00 1 Jan 2000 R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ntp master 1
R2:
R2#clock set 00:00:00 1 Jan 2000 R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#ntp authenticate R2(config)#ntp authentication-key 1 md5 CISCO R2(config)#ntp trusted-key 1 R2(config)#ntp server 12.0.0.1 key 1
Verification:
R1#sh ntp status Clock is synchronized, stratum 1, reference is .LOCL. nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz, precision is 2**16 reference time is BC17C21E.E2025C2A (00:00:30.882 UTC Sat Jan 1 2000) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.02 msec, peer dispersion is 0.02 msec R2#sh ntp status Clock is unsynchronized, stratum 16, no reference clock nominal freq is 249.5901 Hz, actual freq is 249.5899 Hz, precision is 2**16 reference time is BC17C478.70F636C7 (00:10:32.441 UTC Sat Jan 1 2000) clock offset is 4.9077 msec, root delay is 3.42 msec root dispersion is 5.40 msec, peer dispersion is 0.47 msec R2#sh ntp association detail 12.0.0.1 configured, insane, invalid, unsynced, stratum 16 ref ID 0.0.0.0, time 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900) our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000 delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00 precision 2**5, version 3 org time BC17C21D.A98986BD (00:00:29.662 UTC Sat Jan 1 2000) rcv time BC17C215.F9D7D2C3 (00:00:21.975 UTC Sat Jan 1 2000) xmt time BC17C215.F8F5A889 (00:00:21.972 UTC Sat Jan 1 2000) filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
As we can see from the above output, R1 is the master server with a stratum of 1, whose reference clock is the local device. R2 is not synchronized, reports that the clock 12.0.0.1 is insane, and has a stratum of 16. Since the server is not responding to the client’s authentication request, synchronization is not achieved.
Case IV: Authentication on Master (R1) and Client (R2)
Configuration:
R1:
R1#clock set 00:00:00 1 Jan 2000 R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ntp master 1 R1(config)#ntp authentication-key 1 md5 CISCO
R2:
R2#clock set 00:00:00 1 Jan 2000 R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#ntp authenticate R2(config)#ntp authentication-key 1 md5 CISCO R2(config)#ntp trusted-key 1 R2(config)#ntp server 12.0.0.1 key 1
Verification:
R1#sh ntp status Clock is synchronized, stratum 1, reference is .LOCL. nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz, precision is 2**16 reference time is BC17C250.CBF1C712 (00:01:20.796 UTC Sat Jan 1 2000) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.02 msec, peer dispersion is 0.02 msec R2#sh ntp status Clock is synchronized, stratum 2, reference is 12.0.0.1 nominal freq is 249.5901 Hz, actual freq is 249.5899 Hz, precision is 2**16 reference time is BC17C223.9538661E (00:00:35.582 UTC Sat Jan 1 2000) clock offset is 0.1998 msec, root delay is 3.43 msec root dispersion is 0.27 msec, peer dispersion is 0.05 msec R2#sh ntp association detail 12.0.0.1 configured, authenticated, our_master, sane, valid, stratum 1 ref ID .LOCL., time BC17C210.CBB5CB7E (00:00:16.795 UTC Sat Jan 1 2000) our mode client, peer mode server, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.03, reach 377, sync dist 1.785 delay 3.43 msec, offset 0.1998 msec, dispersion 0.05 precision 2**16, version 3 org time BC17C223.94D4F0AA (00:00:35.581 UTC Sat Jan 1 2000) rcv time BC17C223.9538661E (00:00:35.582 UTC Sat Jan 1 2000) xmt time BC17C223.944184E3 (00:00:35.579 UTC Sat Jan 1 2000) filtdelay = 3.43 3.51 3.42 3.46 3.43 3.51 3.43 3.42 filtoffset = 0.20 0.15 0.18 0.17 0.17 0.09 0.10 0.10 filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12
As we can see from the above output, R1 is the master server with a stratum of 1, whose reference clock is the local device. R2 has authenticated the clock 12.0.0.1, has synchronized with it, and has a stratum of 2. This is the correct configuration for NTP authentication.
Review:
This exercise has demonstrated that NTP authentication is initiated by the client. An NTP association may be formed without authentication, without the client initiating authentication, and with the client initiating authentication and the server responding. NTP synchronization cannot occur if the client requests authentication and the server refuses.
© 2003 Internetwork Expert, Inc.
R&S Mock Lab Workshop
R&S Advanced Technologies Class-on-Demand
R&S Lab Workbook Volume I
R&S Lab Workbook Volume II
R&S Lab Workbook Volume III
R&S Mock Lab Exams
R&S Advanced Technologies Audio Class
R&S Rack Rentals
Toll Free (US & Canada):
(877) 224.8987 x1
International:
+1.775.826.4344 x1
Fax:
+1.775.826.4344
Email:
Sales
Support
Customer Service
Shipping
Main Sales Office (US):
10627 Professional Circle
Reno, NV 89521