While I can't take you up on your offer to test your code, since I'm
about to change jobs in a couple weeks. As an NTP weenie, two
thoughts came to my mind:
- Is the implementation style such that the delay through the
forwarder is constant without regard to the direction of flow? If
not, this will introduce a bias in the measured clock offsets due to
an asymmetric delay.
- Why not just run an NTP peer on the firewall system, and live
without direct NTP connectivity? I guess there are plenty of reasons,
but I just have this (possibly unfounded) worry about yet another
source of "noise" on the NTP clock offset/delay samples being
introduced by the relay daemon.
Entering "paranoid mode"..
Also, having a "secured" NTP daemon on the firewall lets you configure
authenticated NTP peers, and you won't have to replicate all of that
on your "internal" machines. This could be important, as you may not
want to be open to someone spoofing an (unauthenticated) external NTP
clock peer and screwing with your system's time. This can be an issue
for protocols (e.g., Kerberos) which use timestamps in protocol
exchanges to protect against replay attacks.
Louis Mamakos
University of Maryland
Follow-Ups:
References:
|
|
