detha <de...@foad.co.za> wrote: >> Maybe. For the moment I think it is sufficient if we provide a mechanism >> by which offenders gets reported to *some* system. We *could* also provide >> a method by which white/black-list can be dynamically set from an external >> source, so enough hooks exists, but I do not think that NTPD should be >> burned with the rest of that system. > > Agreed, not core functionality for ntpd; but it would be nice to have a > hook where one can 'vet' an incoming IP address, much like the RBL hooks > are implemented in mail agents.
The problem is that source addresses can be spoofed. There is the BCP38 document that recommends providers to implement countermeasures against that, but it is not widely followed, mostly because there is no financial gain for those that do it. This reminds me of the situation with open SMTP relays. Those once were common practice (and even had a function), and when it became apparent that they had to be closed because of the abuse, there also was a large number of providers that did not want to cooperate. There were forced to do so by an RBL system that started to refuse mail from systems that were not appropriately configured. Probably the only way to get BCP38 implemented is to develop a similar system that just rejects traffic orginating at providers who don't do source address filtering. Without that, NTP server operators are really helpless against attacks, both of their servers and backscatter attacks against innocent victims. But of course it is outside the scope of NTP to do this, it just happens that NTP is a recent victim of this wide misconfiguration problem. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions