Subject: Re: [TICTOC] WGLC for draft-ietf-ntp-mode-6-cmds

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 13 Jun 2018 09:46:19 +0000

Folks,

Please respond to this WGLC. The deadline is Friday!

Karen

> On May 31, 2018, at 5:26 AM, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
> 
> This begins a 2 week working group last call for the following document: 
> 
> Control Messages Protocol for Use with Network Time Protocol Version 4
> https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/
> 
> Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed. 
> 
> Please send all comments in by Friday 15 June 2018.  
> 
> Thank you!
> Karen and Dieter
> 
>

---

From: Alex Campbell <[email-masked]>
Date: Wed, 13 Jun 2018 23:06:33 +0000

Hi,
I've reviewed this document and I have the following issues:

* Clock source value 8 ("eyeball-and-wristwatch") - is this a serious value? If the time server is synchronized to a wristwatch which is not synchronized to any other source, I would think the correct value is "unspecified/unknown".
* Clock source values should not be defined in a fixed lookup table. There are a number of other possible clock sources (such as IEEE 1588v2, Building Integrated Timing Supply, an unsychronized local clock, or a video camera pointed at a sundial) and it is not possible to cover every conceivable clock source in 6 bits. I can understand that the 6-bit code might still be required for backward compatibility, but there should also be a variable which can specify more details (such as the exact name of the radio station being used)
* Likewise for the error code ("Clock Code") in the clock status word. For example I would expect a GPS-sourced clock with a poorly-placed antenna to be able to return a status message such as "Not enough satellites in view."
* Please clarify whether the System Event Counter resets to 0 when an event occurs which has a different event code from the preceding event.
* Likewise for the Peer Event Counter, and the event counter in the Clock Status Word. 
* Please clarify where whitespace can be added (and MUST be ignored by the recipient) in a command data field, and where it is significant (and MUST NOT be ignored).
* Please clarify whether whitespace is ignored in response data in a similar manner.
* Please clarify which characters are considered whitespace. (I take "ASCII nonprinting format effectors" to include backspace, horizontal tab, vertical tab, linefeed, carriage return and form feed)
* In a Read Status (1) response with zero as the association identifier, how are the entries delimited from each other, and how is the association identifier delimited from the status word within an entry?
* In a Read Variables (2) command, the command data field may be a list of identifiers, but the draft doesn't specify that this list has any effect. Is it meant to filter the returned variables?
* Set Trap Address/Port (6) - how long is a lengthy interval?
* Read MRU (10) - how is the nonce returned in the response?
* Read MRU (10) - which variables are returned in the response data?
* Read MRU (10) - please clarify that the response data format is the same as for Read Variables (if this is actually the case).
* Read MRU (10) - how does the command data affect the response?
* Read ordered list (11) - what is the format of the response data?
* Should NTP control requests from the public Internet be processed by a server, or should the use of them be generally restricted to authorized administrators?
* Appendix A - why must the data area for a request be exactly 40 octets in length? Surely this would be server-specific.
* Appendix A - can requests also be fragmented?
* Why are there two distinct protocols (one not standardized) for server monitoring and configuration? (Control and Remote Facility)

Alex

________________________________________
From: TICTOC <[email-masked]> on behalf of Karen O'Donoghue <[email-masked]>
Sent: Wednesday, 13 June 2018 9:46 p.m.
To: [email-masked]
Cc: [email-masked]
Subject: EXTERNAL: Re: [TICTOC] WGLC for draft-ietf-ntp-mode-6-cmds

Folks,

Karen

> Please send all comments in by Friday 15 June 2018.

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Karen O'Donoghue <[email-masked]>
Date: Fri, 15 Jun 2018 17:36:21 +0000

Folks,

I am extending this WGLC one week to solicit additional input. Please review and comment ASAP. The document isn’t that long. If you have no comments, that’s fine… just indicate that you have reviewed it and it is ready to progress. Remember the intention of this document is to document the existing practice. Further enhancements will be done in a separate effort. 

Regards,
Karen

> On May 30, 2018, at 11:26 PM, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
>

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 15 Jun 2018 11:18:07 -0700

Yes, clock source type 8 is real. It was more relevant 30 years ago, but it’s still a choice. Sysplex. 

If clock sources are not defined, there is no way to track or lookup the metadata. 

More from me on these and your other points later. 

Sent from my iPhone. Please excuse brevity and typos.

> On Jun 13, 2018, at 4:06 PM, Alex Campbell <[email-masked]> wrote:
> 
> Hi,
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Steven Sommars <[email-masked]>
Date: Sat, 16 Jun 2018 20:21:29 -0500

What is the utility of this draft RFC?
1) The interface is not well defined.  Free form ASCII is a poor choice for
interoperability.
    Example: I filed a bug report with the reference ntpd, Bug 3484, for a
specific ntpq  - ntpd interop problem and learned that
     the draft RFC didn't specify how to encode a null.
2) Some widespread NTP implementations, e.g., chrony, do not support mode 6.
3) Many public NTP servers block mode 6 commands.  A few years ago a large
number of public servers under 20% responded to mode 6.  See also section 6
of this draft
4) Cleaning up the draft may take substantial effort.  Is a new
implementation based on this document likely?
5) Appendix B of RFC1305 seems adequate as a historical note.

Steven Sommars

On Wed, Jun 13, 2018 at 4:46 AM, Karen O'Donoghue <[email-masked]>
wrote:

> > Please review the referenced document and send any comments to the
> mailing list including your assessment of whether this document is mature
> enough to proceed to the IESG. Please note that these messages of support
> for progression to the mailing list will be used to determine WG consensus
> to proceed.
> >

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 18 Jun 2018 11:50:57 +0200

> Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these me…

I don't know much about the protocol, e.g. how accurately it describes
what current versions of ntpd/ntpq/ntpdc use, but I think the document
should make it more clear that it is not recommended for new
applications. Should it be labelled as "historic"?

The issue with amplification is a major problem. It is possibly the
most severe security issue NTP ever had in terms of damage. It's the
reason why some ISPs now block the UDP port 123 by default. If it
cannot be fixed, it should be deprecated.

-- 
Miroslav Lichvar

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 18 Jun 2018 12:23:56 +0200

Steven Sommars wrote:
> 3) Many public NTP servers block mode 6 commands.  A few years ago a
> large number of public servers under 20% responded to mode 6.  See also
> section 6 of this draft 

Even though many public servers block mode 6 commands for *public*
access, they still can (and many do) support monitoring from within
specific networks or hosts.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Alex Campbell <[email-masked]>
Date: Wed, 20 Jun 2018 03:29:13 +0000

I agree that this needs to be made more clear.
________________________________________
From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Sent: Monday, 18 June 2018 9:50 p.m.
To: Karen O'Donoghue
Cc: [email-masked]; [email-masked]
Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mode-6-cmds

--
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 25 Jun 2018 10:57:45 +0200

>>> Steven Sommars <[email-masked]> schrieb am 17.06.2018 um 03:21 in
Nachricht
> What is the utility of this draft RFC?

If it has no other purpose than helping to understand how ntpq works, it is reason enough IMHO. Another valid purpose is when you do your own monitoring avoiding to call ntpq, just to parse ist output.

> 1) The interface is not well defined.  Free form ASCII is a poor choice for

These are two different issues.

> 2) Some widespread NTP implementations, e.g., chrony, do not support mode 6.

How do you remotely monitor chrony?

> number of public servers under 20% responded to mode 6.  See also section 6

Many servers today also block FTP, but still it's interesting to know how it works.

> implementation based on this document likely?

I think the intentions are to document what is there now (and if bugs are found, maybe correct them). A better implementation is really desireable, but not the intention of the RFC.

> 5) Appendix B of RFC1305 seems adequate as a historical note.

It does not implement the NTPv4 mode 6 protocol, and it does not document the complete history of the protocol.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 25 Jun 2018 11:02:16 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 18.06.2018 um 11:50 in
Nachricht <20180618095057.GA32057@localhost>:
>> https://datatracker.ietf.org/doc/draft‑ietf‑ntp‑mode‑6‑cmds/ 
>> 
>> Please review the referenced document and send any comments to the mailing

> list including your assessment of whether this document is mature enough to

> proceed to the IESG. Please note that these messages of support for 
> progression to the mailing list will be used to determine WG consensus to 
> proceed. 
> 

Hi!

I think the reason for documenting mode 6 is exactly to teach those who block
port 123 unconditionally (they did it here as well, breaking all the pool
servers) how to block mode 6 (and 7?) packets only.

Regards,
Ulrich

> ‑‑