Hi Tal,
The MAC is a necessary component in the current protocol when
extensions are present. The parsing of incoming packets uses frame size as
mechanism for determining the code path to take in addition to its obvious
utility value in autokey. The relevant section in 5905 is the first sentence
in the NTP Extension Field Format section 7.5.
In NTPv4, one or more extension fields can be inserted after the
header and before the MAC, which is always present when an extension
field is present.
From: Tal Mizrahi [mailto:[email protected]]
Sent: Tuesday, July 12, 2011 7:44 AM
To: Greg Dowd; [email protected]; [email protected]
Subject: RE: [TICTOC] [ntpwg] New draft:
draft-mizrahi-tictoc-checksum-trailer-00
Hi Greg,
Thanks for your feedback.
> In NTP, the addition of an extension field requires the presence of the MAC.
[TM] According to RFC5905 "The extension fields are used to add optional
capabilities, for example, the Autokey security protocol". So indeed, the only
extension field currently defined is for security purposes, but the current
draft proposes to use a newly defined extension field, independent of the MAC
usage.
> How would this model work if the NTP packet did have the MAC?
[TM] The current draft is more useful for cases where the MAC is not used,
since this draft is about simplifying the implementation of intermediate nodes.
When the MAC is used, it would mean that the intermediate node would have to
compute the MAC, and only then to perform the Checksum update.
> 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?
[TM] The idea is that the intermediate node (an ASIC/FPGA) assigns the packet's
timestamp field, significantly improving the accuracy. The benefit of this
improvement is negligible if the path between the NTP nodes consists of a large
number of hops, BUT when there is a small number of hops this improvement is
significant. An example use-case I have in mind is in the wireless backhaul,
where the RBS and RNC synchronize over a CES, either using PTP or NTP. When NTP
is used in this case, high precision is required, and can benefit from
timestamping at the intermediate node.
Regards,
Tal.
From: Greg Dowd [mailto:[email protected]]
Sent: Monday, July 11, 2011 6:29 PM
To: Tal Mizrahi; [email protected]; [email protected]
Subject: RE: [TICTOC] [ntpwg] New draft:
draft-mizrahi-tictoc-checksum-trailer-00
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]] On Behalf Of Tal
Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: [email protected]; [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.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
