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

David L. Mills mills at udel.edu
Tue Mar 28 19:43:53 UTC 2006


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.


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

More information about the hackers mailing list