Brad Knowles wrote:
> Server access control is something that ntpd has never attempted in
> the entire history of the project. We have server authentication, which
> used cryptographic methods to prove to the clients that the time claimed
> actually came from the server claimed, but there is no access control,
> nor has there ever been. The closest we get is the "restrict" lines,
> and that's not the same thing.
Well, actually, its pretty close, at least conceptually. I think the
black list people want is pretty much 'drop packets from these IPs', or
maybe KOD them.
>
> You're talking about a totally different animal here, one that is
> unlike anything that has ever been done before with NTP, and has serious
> design and even protocol issues that cannot be just waved away with a
> motion of your hand.
Design issues, yeah, I can see that. Especially given ntp's real
time-ish constraints. (Though, you could just load the list into RAM, at
least on a PC).
OTOH, I'm not sure what protocol issues there are, at least over doing
the same thing with e.g., iptables. Please explain.
> That is absolutely nothing whatsoever like making the operation of
> the server totally and completely dependant on being able to access the
> disk on a query-by-query basis, in order to perform access control.
> Most disks have access times measured well into the milliseconds, and
> when you add filesystem and database overhead on top of that, you're
> probably into the hundreds of milliseconds.
In the worst case, maybe. In the normal case, it'll be handled by the
buffer cache.
Actually, ntpd need not wait on the disk at all. Someone could,
hypothetically, implement a way for ntpd to:
1) Tell a separate process "I just handled a packet
from a client I don't have access info cached for."
ntpd would reply to packets normally unless it had
cached auth info for the packet
2) Have a way for the separate process to tell ntpd:
"Drop all packets from <host>" or "Accept all packets
from <host>."
I think (2) may actually already exist in the form of ntpdc; (1) may as
well. Something similar
Then all your disk access, DNS access, carrier pigeons, whatever are in
a separate process, and if that process blocks, oh well, doesn't affect
ntpd.
>
> You're talking about building an OLTP database the likes of which
> the world has never seen before, and putting that into each and every
> NTP server in the world. Yes, big honking Oracle RAS servers may be
> able to get more than a few hundred queries per second, but not with
> jitter and latency measured to such extremely low levels. To make this
> useful for a time server, you'd have to be down into the single
> millisecond range, or even into the nanoseconds, for both latency and
> jitter.
No one in their right mind would attempt to design a system like that.
That is a straw man, at best.
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
