[ntp:hackers] Findinterface

David L. Mills mills at udel.edu
Sun Jun 12 20:43:25 PDT 2005


Todd,

We have had this discussion before. There is no way to guarantee 
timekeeping performance other than on a probabilistic basis for real 
world or in simulation with artificial signals. I do take exception to 
your statement that NTP has not been rigorously tested. See my papers 
and briefings, as well as three comprehensive surveys in past years. 
Greg Troxel and his dissertation at MIT come to mind. As for nobody else 
testing it, talk to Martin Marietta, who are testing it for the DDX 
destroyer. Talk to Bellcore, a former consulting client who did the 
same. It is true that testing was intended for a specific program and 
the testers did not have merit badges.

Now, if what you mean by performance audit is an examination of the 
algorithms for verifiable correctness principles, that would indeed be 
useful. I've suggested the exercise as training in computer science 
courses, especially using Estelle or Lotus. Maybe push harder on that 
agenda once the book is at the printers.

There is a glaring fault now that a rigorous test plan needs to be 
developed. I dropped a preliminary test plan on the task force and asked 
for help but got zero response. Only when the test plan is executed 
successfully would the code even be eligible for audit.

Having said that, I believe there is no way the current code base can be 
audited or even morphed to auditable shape. It would have to be 
reconstructed from scratch rigorously from the spec, should it 
eventually appear. I give you the X.25 wars thirty years ago. The only 
way that will happen is to drop boucoup bucks on a Beltway bandit and 
limit it only to one system, nonportable and all the necessary options 
(only) be made permanent.

Just to gain some perspective here, the BlueCross BlueShield Association 
has in fact formally audited NTP with respect to their internal 
applications and found it acceptable. I admit I am a consultant to BCBSA.

Dave

todd glassey wrote:

>Dave - you were an advisory member of CertifiedTime's Technologies Board -
>which by the way I am restarting if  anyone is interested... you should know
>what my response is already.
>
>As to NTP -  Its never been tested by anyone but you and this team Dave,
>there is no formal audit of the code base,  no performance or repeatability
>specifications, no loading factors no nothing... All that is available is
>people's "I think" testimony and that is of little value in a NASD OATS
>dispute for instance. My take is that its time to make NTP accountable and
>not just a physicists toy.
>
>
>Todd Glassey, CISM, CIFI
>
>----- Original Message ----- 
>From: "David L. Mills" <mills at udel.edu>
>Cc: "NTP Hackers" <hackers at ntp.org>
>Sent: Sunday, June 12, 2005 8:16 AM
>Subject: Re: [ntp:hackers] Findinterface
>
>
>  
>
>>Danny,
>>
>>Well said. In Autokey tests here I have no trouble keeping the time
>>every bit as good as without it. As for X509, Autokey really does use
>>it. As for expensive development, Autokey has been stable for the last
>>two years.
>>
>>Dave
>>
>>mayer wrote:
>>
>>    
>>
>>>----- Original Message Follows -----
>>>
>>>      
>>>
>>>>Maybe I should say this again... "NTP cannot be secured" - the process
>>>>of securing it makes in less accurate and installs an immediate
>>>>uncertainty to the time data. I will as an auditor argue this and win
>>>>in all instances. Plugging a UDP based protocol into a collision
>>>>domain as a LAN also has problems.
>>>>
>>>>
>>>>        
>>>>
>>>I'm not sure I understand what you mean by this. There is an exchange
>>>at the beginning of the association while the client verifies the
>>>server's keys. After that there it just processes the MAC section in the
>>>NTP packet every time it receives an NTP packet and there is no further
>>>exchanges (except for once every 24 hours). Are you saying the
>>>processing
>>>the MAC takes longer and therefore reduces the accuracy or is there
>>>something that I'm missing? Note that there's always some uncertainty
>>>in the time data since there is a variable amount of time that the
>>>system will take to process the packets depending on what else the
>>>system is doing, not to mention the fact that the network may or may
>>>not be congested. Processing the security data is the least of the
>>>variabilities.
>>>
>>>
>>>      
>>>
>>>>What NTP really needs is performance standardization rather than huge
>>>>efforts to secure the open Internet Transport of UDP data, which is a
>>>>hopeless case from an Audit Perspective. This statement is something
>>>>that the cryptographers in the group are going to rail up against,
>>>>but the fact that they want to spend their time trying new variant of
>>>>AutoKEY or in plugging x509 Certificates into NTP as some us have
>>>>already done, myself included. What this all boils down to is that
>>>>        
>>>>
>>>>from an Audit perspective NTP is an At-Risk Protocol.
>>>      
>>>
>>>Performance standardization analysis IS needed but what has that got
>>>to do with cyptography or authentication? NTP does NOT try to secure
>>>the transport of the UDP data nor does it encrypt it. It only tries
>>>to verify that it actually came from the server that it said it
>>>came from which is very different. Or did I misunderstand what you
>>>are saying?
>>>
>>>
>>>      
>>>
>>>>What NTP really does need rather than huge amounts of work in evolving
>>>>AutoKEY in NTP, is the commercial standardization as to "what specs
>>>>the Uniform NTP Port should perform to" and whether there is a set of
>>>>striated implementations that perform at different levels. This is
>>>>even more important for those who want to standardize or characterize
>>>>systems like Symmetricom's 2100 or other appliance style NTP Servers.
>>>>
>>>>
>>>>        
>>>>
>>>Standardization of the NTP v4 protocol is under way. Autokey will be
>>>a separate part of that effort and be a separate document from what
>>>I understand of the IETF WG charter. I'm not sure what you mean by
>>>commercial standardization, IETF RFCs or something else? Also what
>>>do you meant by "Uniform NTP Port" and I assume you mean "conform to"
>>>rather than "perform to"?
>>>
>>>Characterization of a refclock is very different from the
>>>characterization of NTP and I think that's more a matter of
>>>the manufacturers have a standard to follow than NTP to
>>>have a standard.
>>>
>>>
>>>      
>>>
>>>>This is the type of information that the Audit Community needs and
>>>>they ultimately will determine how successful the NTP consortia is in
>>>>its goals to standardize NTP.
>>>>
>>>>Todd Glassey, CISM, CIFI
>>>>
>>>>
>>>>        
>>>>
>>>Maybe you can clarify what you are saying as I'm really confused
>>>by it.
>>>
>>>Danny
>>>
>>>      
>>>
>>_______________________________________________
>>hackers mailing list
>>hackers at support.ntp.org
>>https://support.ntp.org/mailman/listinfo/hackers
>>    
>>




More information about the hackers mailing list