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

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

Alvaro Retana No Objection

(Brian Haberman; former steering group member) Yes

Yes ( for -05)
No email
send info

(Jari Arkko; former steering group member) (was Discuss, Yes, Discuss) Yes

Yes (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?

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

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

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (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

(Terry Manderson; former steering group member) No Objection

No Objection ( for -06)
No email
send info