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

Terje Mathisen terje.mathisen at hda.hydro.com
Wed Mar 29 13:33:24 UTC 2006


Brian Utterback wrote:
> Terje Mathisen wrote:
>> Brian Utterback wrote:
> 
>>>
>>> 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.
>>
>> This would still require some form of multi-packet setup, wouldn't it?
> 
> That's the point. The problem is that a single UDP packet from the
> client (ntpdc) can send a command (monlist) that results in many
> UDP packets sent to the source address, which may be spoofed. The
> TCP solution works because the three-way handshake guarantees that
> the address is not spoofed, because the data is not sent until we
> know that the client has received the SYN-ACK and replied with its
> own ACK. By using a cookie generated by the server that must
> accompany further requests, we know that the packet got back to
> the originator, and that the source address must be valid.
> 
> You need only require the cookie on on requests that need more than
> one packet to contain their response. In fact, you could use it as
> an opaque handle to hold the necessary state for subsequent packets.
> Like LDAP views, you would have a packet exchange for each sequential
> subset of the data returned. No cookie means send the first N lines
> of data and cookie1 (to fill one packet). The same request with cookie1
> means send the next N lines along with cookie2. And so one.

I like it!

This would in one fell swoop get rid of the amplification problem, as 
well as the packet loss due to a single big burst.

To work properly, the first reply packet could be quite short, i.e. it 
should not provide significant more traffic than the incoming request.

This would make it harder to stay compatible with current 
implementations though, since an old version ntpq/ntpdc client would not 
receive any useful info.

Since this is a security fix, I would still be quite happy to make a 
somewhat incompatible protocol upgrade, where only new requestors would 
be capable of getting info out of new servers, while both old and new 
code could query old servers.

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

-------------- next part --------------


***********************************************************************
NOTICE: This e-mail transmission, and any documents, files or previous
e-mail messages attached to it, may contain confidential or privileged
information. If you are not the intended recipient, or a person
responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of
any of the information contained in or attached to this message is
STRICTLY PROHIBITED. If you have received this transmission in error,
please immediately notify the sender and delete the e-mail and attached
documents. Thank you.
***********************************************************************



More information about the hackers mailing list