The NTPv4 protocol, and the implementation, currently don't have the ability to distinguish an extension from a MAC uniquely. I would rather see a "NOOP" MAC (with keyid 0 or -1) function defined which would let nodes process and drop the frame with auth failure and not a malformed packet.
Looking beyond the protocol state machine, how could we include some indicator in the frame that it had been modified? Perhaps we could make some extension mandatory? One issue with the way TCs work in PTP is that they are all doing a read-modify-write against the correction field. It is not possible to distinguish either the number or the timing characteristics of the elements modifying the time. In a closed point-to-point protocol like telecom style PTP this is not an issue as the links, and the capabilities of the TC elements, are well-defined and managed. In NTP, it would be useful to develop a "profile" which would define this NTP application over a controlled or managed network. It could specifically call out the usage of hardware timestamps where available, the format and/or requirement to generate an extension, the restrictions on use of authenticators or autokey, the impact on the utility value of the dispersion/root distance fields, etc. Greg Dowd gdowd at symmetricom dot com (antispam format) Symmetricom, Inc. www.symmetricom.com<http://www.symmetricom.com> "Everything should be made as simple as possible, but no simpler" Albert Einstein From: David L. Mills [mailto:[email protected]] Sent: Wednesday, July 13, 2011 10:54 AM To: Greg Dowd Cc: Tal Mizrahi; [email protected]; [email protected] Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Greg, The MAC is intended to protect against a message modification attack, which surely is not the object here. In principle, the MAC can be omitted and an extension field can be used in much the same way as a transparent bridge in PTP. Dave Greg Dowd wrote: Is the use model you envision for NTP to support hardware timestamping at the edge? In NTP, the addition of an extension field requires the presence of the MAC. This requires the dissemination and maintenance of keys as well as the defined MAC checking. How would this model work if the NTP packet did have the MAC? This extension field would be covered by the MAC and the authenticator would fail. Or do you expect this block would have the key info and update the MAC as well? And, how would it work if the MAC isn't there. Would the update not be used? In PTP, there is a TC protocol function which necessitates the modification of the packet. In NTP, as it is defined as a UDP protocol, there is not as clear a path to how lower stack layers modify the PDUs. If you define this simply at the edge, I'm not sure how much value this additional UDP checksum update adds? Is there a model you have in mind? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Tal Mizrahi Sent: Monday, July 04, 2011 5:01 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Hi, I have posted a new draft that discusses Checksum updates in time synchronization protocols. http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 Comments will be welcome. Thanks. Tal. ________________________________ _______________________________________________ ntpwg mailing list [email protected]<mailto:[email protected]> http://lists.ntp.org/listinfo/ntpwg
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
