[ntp:hackers] i think it's time to review ntp's default acl's

Brian Utterback brian.utterback at sun.com
Tue Mar 28 19:57:25 UTC 2006

I am not sure of the ramifications of this, but maybe the monitoring and 
control functions should be done with TCP? This would avoid the whole 
amplification issue, since the three-way handshake would have to 
complete before more data would be sent than is received.

Or maybe have a cookie that must be used to get multi-packet responses?
That way you could be sure that you are talking to a real entity and
that the address is not spoofed.

David L. Mills wrote:
> Guys,
> You propose a sledgehammer to pulverize a peanut. Restricting to local 
> net would make it impossible to for me to watch campus time servers, as 
> they are on at least a dozen different nets and subnets. In almost all 
> cases now, monitoring of an NTP time servers is never on the same host 
> as this requires login password.
> Note that
> 1. Individual servers can restrict mode-6 and mode-7 access now. I'm not 
> sure what the proposal is; I assume it is to set the default as this 
> case. I won't concur with that until this issue is raised and debated in 
> the working group.
> 2. The KoD packets are already rate limited. That would be trivial to 
> add to mode 6/7 packets. Multiple packet responses could require 
> password as does other sensitive actions now.
> 3. As I mentioned previously, the whole idea of remote configuration and 
> authentication needs review.
> 4. The Autokey protocol can generate no more than one response per 
> request, but the responses involving certificates can be large. However, 
> this is a problem common to all certificate-response schemes. The 
> protocol is absolutely paranoid on resisting replays and spoofs, but 
> there are a couple of states in the machine before ending the dance 
> where an exploiter can cause the crypto unit to heat up. These are 
> explored in the documentation in grate detail and runarounds suggested.
> Dave
> Danny Mayer wrote:
>> Can people please include Dave's email address on these messages? He's
>> not on the hackers list and this is important.
>> Thanks,
>> Danny
>> Paul Vixie wrote:
>>> # DNS and NTP are just the tip of the iceberg, and I think it's a 
>>> huge one.
>>> yes.
>>> # Could somebody give me a lesson in the big picture? (URL would be 
>>> great.)
>>> <http://www.ietf.org/rfc/rfc2827.txt> or the PHB summary of same, 
>>> writ by me:
>>> <http://www.icann.org/committees/security/sac004.txt>.
>>> # Are we going to have to give up on UDP because it's easily abused 
>>> by bad
>>> # guys?
>>> that depends on who you mean by "we" and what you mean by "bad". 
>>> there will
>>> always be udp, and people using udp. their service will suffer, and 
>>> their
>>> suffering will create market pressure in unexpected 
>>> places/kinds/directions.
>>> the "bad" guys in this case are ISP's who choose not to deploy BCP38 
>>> based on
>>> the lack of economic incentive, thus creating unexpected and less 
>>> desireable
>>> outcomes like my plan to create a BGP blackhole list for open 
>>> recursive DNS
>>> servers.
>>> it's possible that T/TCP or SCTP should be used instead of UDP for 
>>> transaction
>>> based services like DNS. but the timing characteristics of either are 
>>> so much
>>> sloppier than UDP, that i don't imagine either being usable by NTP. 
>>> so, no.
>>> # Is it possible to get routers to drop packets with forged source 
>>> addresses?
>>> yes. every modern router has this functionality.
>>> # I assume there are both technical and social/political issues. I 
>>> don't know
>>> # if it's reasonable to solve either.
>>> it costs money to train staff for, write policies for, debug, and handle
>>> customer complaints about, BCP38. the ISP who does this will save no 
>>> money
>>> (since the pain caused by not doing it is felt by others, not by 
>>> them), and
>>> will make no money (since customers will not pay extra for a change 
>>> like this
>>> that adds no performance or features to their service.) so, it's 
>>> economics,
>>> not social/political issues, that leaves us where we now are (which 
>>> to say,
>>> "a deer in the headlights".)
>>> # For NTP, it seems possible to allow access only by previous 
>>> arrangements.
>>> # The administrative overhead would probably eliminate public servers 
>>> as they
>>> # are currently used. That would encourage/require ISPs to setup NTP 
>>> servers
>>> # for their customers.
>>> the way you say that doesn't make it sound bad. is it actually bad 
>>> and you're
>>> just really good at the kind of spin control that i find attractive, 
>>> or is it
>>> really as good as you imply?
>>> _______________________________________________
>>> hackers mailing list
>>> hackers at support.ntp.org
>>> https://support.ntp.org/mailman/listinfo/hackers
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers


Quidquid latine dictum sit, altum sonatur.
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

More information about the hackers mailing list