Network Time Protocol Version 4 (NTPv4) Extension Fields
RFC 7822

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) (was Discuss, Yes, Discuss) Yes

Comment (2016-02-04 for -06)
No email
send info
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?

(Brian Haberman) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-02-03 for -06)
No email
send info
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

(Joel Jaeggli) No Objection

Comment (2016-02-03 for -06)
No email
send info
tim chown provided the opsdir review

Barry Leiba No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection