[ntp:hackers] 'noserve' etc. and the protocol response matrix

Miroslav Lichvar mlichvar at redhat.com
Fri Jan 31 17:41:41 UTC 2014


On Thu, Jan 30, 2014 at 08:14:40AM -0500, Brian Utterback wrote:
> On 1/29/2014 10:14 AM, Miroslav Lichvar wrote:
> >Recommending "disable monitor" would be problematic as it effectively
> >disables the restrict limited option.
> 
> I am not sure what you mean. What are the downsides to setting
> "restrict default noquery" vs. "disable monitor"? I thought disable
> monitor would just stop monlist/mrulist, right?

It disables the monitoring facility, which is used for the "limited"
restrict option. If ntpd doesn't know how often is the client sending
requests, it can't decide whether to ignore the one it just received
or not.

That monlist/mrulist has nothing to report with disabled monitoring is
just a side effect I think.

> >I agree the best option would be to fix the protocol so it doesn't
> >allow any amplification, but it seems that's not possible without
> >breaking compatibility with older versions.
> 
> Possibly. What I would like to see is that all write commands
> require the nonce dance just to verify that they really come from
> where we think they come from.

I think the write commands are allowed only when the client is
authenticated, so using a nonce shouldn't be necessary with them. The
problem is mainly in the commands that don't require authentication
and can send multiple replies per request (or send larger reply than
request).

> Since we would fix ntpq with the
> protocol change at the same time, it just means that they would need
> a up to date version of ntpq. If I recall correctly, this isn't the
> first time we have said that you need a current version of ntpq to
> get some functionality.

Yeah, it's the inconvenience of keeping compatible ntpq and ntpd
versions across multiple machines.

> If there is a read request that doesn't need multiple packets then
> the protocol doesn't change at all, so there is no backwards
> compatibility problem at all in that case. The mrulist command
> already requires the nonce, we just have to reduce the number of
> packets exchanged per request which I believe is already handled by
> ntpq. I think the only other command that can send multiple response
> packets is the peers list commands. We could change that in some way
> so that we could detect an old request and new request and if we get
> an old request, we still respond but with only the first packet's
> worth of data. That should minimize the number of instances of
> backwards incompatibility problems.

Does the size of the reply packet matter too or just the number of
packets per request?

BTW, in the chrony control protocol was found a similar problem
(replies larger than request) and it was fixed by an incompatible
change in the protocol.

-- 
Miroslav Lichvar


More information about the hackers mailing list