Network Time Protocol Version 4 (NTPv4) Extension Fields
draft-ietf-ntp-extension-field-07
Yes
(Brian Haberman)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 05 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -05)
Unknown
Jari Arkko Former IESG member
(was Discuss, Yes, Discuss)
Yes
Yes
(2016-02-04 for -06)
Unknown
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?
Alissa Cooper Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -06)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -06)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -06)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -06)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-02-03 for -06)
Unknown
tim chown provided the opsdir review
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -06)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -06)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-02-03 for -06)
Unknown
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
Terry Manderson Former IESG member
No Objection
No Objection
(for -06)
Unknown