Ballot for draft-ietf-ntp-extension-field
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Thank you for writing this much clarifying document! I want to recommend its approval with a 'Yes' position, but before that I had two issues / question which I believe would benefit from some discussion: Issue 1: Suresh Krishnan's Gen-ART review raised a number of comments, and I thought fixing this was important: > I could not find the text in RFC5905 Section 7.5 that this draft says it is > replacing. Specifically the following "OLD:" text does not exist in RFC5905 Can the authors comment on this and make any changes that might be needed? Issue 2: Section 7.5.1.2 says: If an NTP packet is received with two or more extension fields that require a MAC with different algorithms, the packet MUST be discarded. However, Section 7.5 already said earlier: If a host receives an extension field with an unknown Field Type, the host SHOULD ignore the extension field and MAY drop the packet altogether if policy requires it. This leaves me wondering how the MUST-drop-packet-with-fields-with-different-algs can be implemented. Did you perhaps mean: If an NTP packet is received with two or more extension fields that this receiver recognises and those fields require a MAC with different algorithms, the packet MUST be discarded. Or maybe something else? Can you clarify?
tim chown provided the opsdir review
If you do revisit the MACing setup, (as indicated in the response to the secdir review [1]), I hope you maybe consider taking some input on this from security folk - having a scheme where essentially random parts of the packet are/are-not protected by a MAC isn't necessarily a good way to go. I do totally agree that getting away from depending on the length to figure out the algorithm is a thing that definitely should be done, and moving to use modern ciphers as well of course;-) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06329.html