[ntp:hackers] Autokey background processing for expensive crypto
David L. Mills
mills at udel.edu
Tue Sep 20 12:53:19 UTC 2011
Dave,
Your observations are most relevant to the busy server. In the revised
design described in the "NTP Security Model:, the only serious server
vulnerability is to decrypt the message digest key provided by the
client. I'm not sure what the costs and benefits are.
Dave
Dave Hart wrote:
>Dr. Mills,
>
>I notice in the thread "Autokey Protocol Analysis" you mentioned
>concern about keeping autokey crypto operations cheap enough to
>continue to allow for high-throughput NTP service by, for example,
>national labs, in the thousands of requests/sec range. Currently, all
>Autokey operations are handled by ntpd's main thread, which needs to
>minimize blocking operations to continue to service requests in a
>timely manner.
>
>This reminds me that ntpd now has the infrastructure to farm out
>blocking DNS queries to worker threads (or child processes, if threads
>are not detected or are disabled). It would be relatively
>straightforward to do something similar, moving expensive Autokey
>crypto operations to worker(s) (likely up to one per
>CPU/core/hyperthread). The main thread would farm off expensive
>crypto to a worker thread and, once the work is done, send the
>response, potentially having serviced many other requests while the
>crypto chugged along in the background. I suspect that would enable
>better scaling, particularly when there is a mix of plaintext and
>Autokey client traffic.
>
>Do you think that would be a useful capability for ntpd's Autokey
>implementation?
>
>Cheers,
>Dave Hart
>
>
More information about the hackers
mailing list