[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