On Sunday 16 March 2014 21:43:43 Ask Bjørn Hansen wrote: <snip> > > In addition to the usual brouhaha about BCP38 getting the misconfigured NTP > servers fixed will also help make this problem go away. Though very good > progress is being made on that, if it'll be a success within a reasonable > timeframe or end up like BCP38 remains to be seen. > <snip>
While this is indeed correct, the unfortunate state of affairs is that providers are placing the entire onus upon service operators to prevent abuses and once the "fix" is in place, the status quo returns where BCP38 is deemed "not needed after all" because responsive security (updating software, blocking ports) has been put in place. Many providers are uninterested in spending money and resources in implementing proactive security. I agree, service operators must do their part to patch and keep secure installations as good netizens, but unfortunately the matter remains where this has become an absolutist element where seemingly it's either "service operators must implement secure measures" OR "BCP38 must be implemented". The current climate doesn't encourage both measures as once each protocol that gets targetted for abuse (DNS, NTP) is "fixed", the issue "goes away" on providers' radar. This issue is further amplified by providers who do not feel pressure to get their customers to fix broken software and to fix their networks to prevent abuses (where abuse departments may not exist at all — There's some providers that I've sent abuse notices to where their abuse@ and addresses in whois do nothing useful). There's still entire networks of broken NTP and DNS instances still receptive to RDDoS and given the current climate that's unlikely to change until this issue is kept in any way possible on providers' radar as a larger problem of accountability. K -- Kradorex Xeron <[email protected]> Founder, Executive Director Digibase Operations, Research and Development _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
