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

Danny Mayer mayer at ntp.isc.org
Fri Mar 31 22:13:26 UTC 2006


Moving mode 6 and mode 7 (query) packets to TCP might be a good idea and
since NTP owns the 123/TCP port as well it should keep things simple and
those are not used for anything critical (ie where a delay in processing
would effect the results) to the operation of the NTP server. ntpq and
friends would then have to be converted as well to try the TCP port and
fall back to UDP if not available (-u option to only use UDP for the
query). The public NTP servers could then require you to use TCP for
ntpq type of queries (we could add this as a configuration option).

This is the most workable suggestion I've seen so far.

Danny

Brian Utterback wrote:
> 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?


More information about the hackers mailing list