Fwd: NTP changes in 12.4T?

     [ I have no idea if this message made it to the list the first time
I sent it - my apologies if this ends up being a double post... ]

-------- Original Message --------
Subject: NTP changes in 12.4T?
Date: Fri, 26 Feb 2010 20:36:58 +0200
From: Bogdan Sass <bogdan.sass_at_catc.ro>
To: CCIE Groupstudy <ccielab_at_groupstudy.com>

      I have been struggling for a few days now in getting a (very, VERY
simple) NTP configuration to work. IOS - 12.4(22)T2.
      I initially tried this with my students, using a router as server
and an ASA as client. After seeing that this doesn't work, I tried using
routers (2811) for both the client and the server. Still no go...

      The configs are as follows:
      -server:
R1#sh run | i ntp
ntp authentication-key 1 md5 1511021F0725 7
ntp authenticate
ntp master 4

      -client:
R2#sh run | i ntp
ntp authentication-key 1 md5 00071A150754 7
ntp authenticate
ntp trusted-key 1
ntp server 10.0.0.1 key 1

      First problem - is it just me, or is the "debug ntp validity"
missing from this IOS version? (I find that odd, given that it was one
of the best tools for troubleshooting NTP...)

      Second problem - notice the debug output on the client:

R2#

*Feb 26 18:08:02.175: NTP Core(DEBUG): ntp_receive: message received
*Feb 26 18:08:02.175: NTP Core(DEBUG): ntp_receive: peer is 0x4707FD10,
next action is 1.
*Feb 26 18:08:02.175: NTP Core(NOTICE): ntp_receive: dropping message:
crypto-NAK.

      Luckily, after a couple of days of messing around with the configs,
I came across this article:
http://ccietobe.blogspot.com/2009/02/ntp-how-long-is-too-long.html

      I must admit - it never even crossed my mind to enable "ntp trusted
key" on the server (given that in NTP, it is the server that needs to
authenticate itself to the clients). Well, I add the command on the
server, and amazingly enough...

Feb 26 18:17:10.568: NTP message received from 10.0.0.1 on interface
'FastEthernet0/0' (10.0.0.2).
Feb 26 18:17:10.568: NTP Core(DEBUG): ntp_receive: message received
Feb 26 18:17:10.568: NTP Core(DEBUG): ntp_receive: peer is 0x4707FD10,
next action is 1.
Feb 26 18:17:10.568: NTP Core(DEBUG): receive: packet given to
process_packet

      Looks good.... and after a few minutes...
R2#sh ntp status
Clock is synchronized, stratum 5, reference is 10.0.0.1

      Even more - after this minor addition, even the ASA (second ntp
client) gets the time correctly:
ASA1# sh ntp status
Clock is synchronized, stratum 5, reference is 10.0.0.1

      It looks like the server no longer uses a key that is not marked as
"trusted" in order to authenticate itself to the clients. But there was
absolutely nothing in the server debugs that would indicate this problem
(all I could see on the server was "packet received"... "doing fast
answer to client").

      As far as I can remember, before switching to this IOS I could use
the configuration described here (
http://www.internetworkexpert.com/resources/01700369.htm ) without any
problems. So my second question is - is this a new change in the IOS?
And more important - is this documented anywhere? (all I could find on
the DocCD is the NTP client configuration)

      And maybe a third question - if you need "trusted-key" on both
client and server, what is the point of having this command anyway? I
thought the whole idea behind having two commands (ntp
authentication-key vs ntp trusted-key) was that you could have a set of
keys used for authenticating received ntp packets (trusted keys), and a
different set of keys used to authenticate packets sent to clients
(untrusted keys).

      Thank you,

-- 
Bogdan Sass
CCAI,CCSP,JNCIA-ER,CCIE #22221 (RS)
Information Systems Security Professional
"Curiosity was framed - ignorance killed the cat"
Blogs and organic groups at http://www.ccie.net