There are mechanism issues here that are separate from policy issues. As I understand it (and I am probably wrong on several of these points, but hey, it's a start):
- We do not have a mechanism to specify exactly which interfaces we listen to. - there are good policy reasons for this, and I can see that these policy reasons are not universal. If we could tell ntpd to "not listen" to certain interfaces, there is no way a Bad Guy could send packets to ntpd via those interfaces (regardless of whether or not ntpd would be vulnerable to those packets). If we could limit which interfaces an ntpd process listened to, it might be possible to run multiple ntpd's on a box, with one of them in primary control, and the others using something like a local refclock in 'prefer' mode. This might be a useful way to do some testing of ntpd. There are pros/cons to additional flexibility, and it is Useful to discuss and understand these tradeoffs. H _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
