For " 3.3. False Time" it's not obvious how " consideration should also be made for hardware-based timestamping " will help.
On " Intermediate devices such as hardware capable of performing timestamping of packets SHOULD be able to add information to packets in flight without requiring modification or removal of authentication or confidentiality on the packet.": shouldn't it be preferable to integrity-protect these, too? Here it's not clear whther such hardware will replace a timestamp in a packet or will add some extension field to a packet. In the latter case one could also add a MAC built from the existing MAC and the new timestamp. So the receiver could check both MACs: If the additional MAC fails, it would ignore the hardware timestamp and continue checking the original MAC...
The way I thought I set the wording was that timestamps not from middleboxes must have authentication, and hardware NICs/middleboxes/etc that rewrite or append timestamps should. This should be clarified.
Ulrich writes:
The way I thought I set the wording was that timestamps not from middleboxes must have authentication, and hardware NICs/middleboxes/etc that rewrite or append timestamps should. This should be clarified.