Task 12.30 NTP Authentication

Hey all,

Just wanted to bring everyone's attention to an issue I've encountered and seen mentioned elsewhere.

According to the classic NTP authentication rules, ONLY THE DEVICE THAT WILL USE THE PACKET TO UPDATE ITS CLOCK NEEDS TO TRUST THE KEY NUMBER CONTAINED IN THE PACKET.

That does not seem to work however, as stated.

Suppose, a router, R5 in this particular task, is using another, R4 as a SERVER and using authentication.

Now, according to the above rule, you would need to TRUST the key ONLY on R5 whereas on R4, the key would just be configured so the router knows about it.

I noticed that with said configuration, R5 was not accepting or willing to synch up with R4.

R5

ntp authentication-key 4 md5 CISCO4


ntp authenticate

ntp trusted-key 4

ntp source Loopback0

ntp server 150.1.4.4 key 4


R4

ntp master 5

ntp authenticate

ntp authentication-key 4 md5 CISCO4

------------------------------------------------------------------------------------------------------------------------

Now on R5, if a DEBUG NTP ALL is issued, the following message is encountered

 


.May 19 18:23:29.266: NTP Core(DEBUG): ntp_receive: message received

.May 19 18:23:29.266: NTP Core(DEBUG): ntp_receive: peer is 0x64CEF2F0, next action is 1.

.May 19 18:23:29.266: NTP Core(NOTICE): ntp_receive: dropping message: crypto-NAK.

--------------------------------------------------------------------------------------------------------------------

This goes on for a while and needless to say, R5 does not synch up with R4.

At this time, if on R4, the key number is TRUSTED 

 

Rack1R4(config)#ntp trusted-key 4

 

And debugs are checked on R5,

 


.May 19 18:27:31.272: NTP Core(DEBUG): ntp_receive: message received

.May 19 18:27:31.272: NTP Core(DEBUG): ntp_receive: peer is 0x64CEF2F0, next action is 1.

.May 19 18:27:31.272: NTP Core(DEBUG): receive: packet given to process_packet

.May 19 18:27:31.272: NTP Core(DEBUG): Peer becomes reachable, poll set to 6.

.May 19 18:27:31.272: NTP Core(INFO): peer 150.1.4.4 event 'event_reach' (0x84) status 'unreach, conf, auth, 2 events, event_reach'

 

This essentially begins the sync up process and within a few moments, R5 is synced with R4.

This person here also had the SAME problem - http://ccietobe.blogspot.com/2009/02/ntp-how-long-is-too-long.html

 

What I really want to know is is this JUST AN IOS BUG or a fundamental change in how authentication should be configured?

Most importantly, if I finish the task this way in the lab, points granted or lost?

I appreciate all who took the time to look at this post.

Nic

 

Comments


  • One more thing that I encountered right afterwards.

    Suppose a client, R5, is trying to BROADCAST the NTP packets out of one of its interfaces, WITH a certain key. Now once again, THE ROUTER SHOULD NOT HAVE TO BE CONFIGURED TO TRUST THE KEY.

    Or so it would seem. In my case, as long as I DO NOT configure the key as TRUSTED, the router DOES NOT EVEN BROADCAST THE PACKETS.

    Relvent debugs.

    Right now, the router is configured to TRUST key 58 for BROADCAST out of interface F0/0

     

     

    .May 19 18:53:03.241: NTP message sent to 255.255.255.255, from interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:53:20.241: NTP message sent to 150.1.4.4, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:53:20.281: NTP message received from 150.1.4.4 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:53:21.449: NTP message received from 155.1.58.8 on interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:53:21.449: NTP message sent to 155.1.58.8, from interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:53:25.241: NTP message sent to 150.1.6.6, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:53:25.297: NTP message received from 150.1.6.6 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:54:09.241: NTP message sent to 255.255.255.255, from interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:54:24.241: NTP message sent to 150.1.4.4, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:54:24.281: NTP message received from 150.1.4.4 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:54:25.457: NTP message received from 155.1.58.8 on interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:54:25.457: NTP message sent to 155.1.58.8, from interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:54:28.241: NTP message sent to 150.1.6.6, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:54:28.297: NTP message received from 150.1.6.6 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:55:12.242: NTP message sent to 255.255.255.255, from interface 'FastEthernet0/0' (155.1.58.5).


    Rack1R5(config)#no ntp trusted-key 58


    .May 19 18:55:27.242: NTP message sent to 150.1.4.4, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:55:27.282: NTP message received from 150.1.4.4 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:55:31.242: NTP message sent to 150.1.6.6, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:56:32.242: NTP message sent to 150.1.4.4, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:56:32.282: NTP message received from 150.1.4.4 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:56:36.242: NTP message sent to 150.1.6.6, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:57:36.242: NTP message sent to 150.1.4.4, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:57:36.282: NTP message received from 150.1.4.4 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:57:40.242: NTP message sent to 150.1.6.6, from interface 'Loopback0' (150.1.5.5).


    Rack1R5(config)#ntp trusted-key 58   


    .May 19 18:58:26.243: NTP message sent to 255.255.255.255, from interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:58:42.243: NTP message sent to 150.1.4.4, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:58:42.283: NTP message received from 150.1.4.4 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:58:46.243: NTP message sent to 150.1.6.6, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:58:46.299: NTP message received from 150.1.6.6 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:59:32.243: NTP message sent to 255.255.255.255, from interface 'FastEthernet0/0' (155.1.58.5).

    .May 19 18:59:48.243: NTP message sent to 150.1.4.4, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:59:48.283: NTP message received from 150.1.4.4 on interface 'Loopback0' (150.1.5.5).

    .May 19 18:59:51.243: NTP message sent to 150.1.6.6, from interface 'Loopback0' (150.1.5.5).

    .May 19 18:59:51.299: NTP message received from 150.1.6.6 on interface 'Loopback0' (150.1.5.5).

    .May 19 19:00:38.243: NTP message sent to 255.255.255.255, from interface 'FastEthernet0/0' (155.1.58.5).

     

    So for what is worth, my observation is that anytime NTP needs authentication, both CLIENT and SERVER need to TRUST the key.

    Any and all input is appreciated.

     

    Good luck with your studies.

     

    Nic

     

     


  • I agree with you, it looks like Cisco made some changes in the way NTP operates. I could not get ntp security to work without specifying the trusted key on both servers and client. As for broadcast, that wasn't required for me to specify a key as trusted on the server, but that might have to do with the versions of IOS that I'm using there.

     

    If you still have that could you post the  IOS version?

     

    I was using:

    Version 12.4(24)T2 on NTP Server -> client  Version 12.4(15)T5 ->broadcasting to -> 3560 Version 12.2(25)SEE4

     

    Thanks for the post, I was almost about to give up on this lab. Huge thanks!!!!!

     

    Tom

  • Cisco IOS Cookbook Recipe no. 14.12 might help. Check out the following link which says that the key should be trusted on both Server and Client.

    http://fengnet.com/book/cisco.ios.cookbook.2nd/I_0596527225_CHP_14_SECT_13.html

Sign In or Register to comment.