[Ntp] Antw: [EXT] Public NTP servers already responds to NTPv5

[Ulrich Windl <[e-mail]>]

>>> g16 <[e-mail]> schrieb am 29.11.2020 um 16:49 in Nachricht
<CAFZ=0SzC1cKbMf=[e-mail]>:
> Hi, NTP WG and Miroslav !
> 
> I'm yuki.
> 
> I am interested in NTPv5 and ossification.
> 
> So I surveyed how the currently public NTP servers respond to NTPv5 packets.
> 
> As a result, as you may know, some NTP servers respond to NTPv5 packets.
> Surprisingly, the version field of some responses were 5.
> 
> ## Survey method
> I sent two packets to about 70 public NTP servers
> 
> - NTPv4 format packet that version field is 5
> - NTPv5 format packet (defined in draft-mlichvar-ntp-ntpv5-00)
> 
> the tool is here: https://github.com/flano-yuki/mock-ntpv5-client 
> 
> ## Result
>> NTPv4 format packet that version field is 5
> - 25% response: timeout
> - 65% response: NTPv4 format packet that version field is 5
> - 10% response: NTPv4 or NTPv3

In my view 65% of those servers are broken.

> 
>> NTPv5 format packet (draft-mlichvar-ntp-ntpv5-00)
> - 10% response: NTPv4 format packet that version field is  5
> - 90% response: timeout

Another 10% are broken IMHO.

At least this means that clients cannot trust a packet being tagged as v5 actually being a v5 packet.
Probably there should be a mechanism to de-associate such servers, specifically when they had been selected automatically before.
A notice-type (maybe even warning or error) of syslog message seem justified as well IMHO.

> 
> The result depends on the date of Transmit Timestamp and the existence of
> Extension Field.
> 
> full result list:
> https://gist.github.com/flano-yuki/5a587ab0197b23fe647d148a087b82ef 
> 
> ## Is this a problem?
> I'm not sure. It may confuse implementations that support nptv5.
> 
> I know some WG suffered from anomalous behavior in tcp-fast-open and TLS
> 1.3 deployments.
> - https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c/ 
> - https://archive.nanog.org/sites/default/files/Paasch_Network_Support.pdf 
> 
> but, it may be not matter with following reason in NTP WG
> - This response is not a problem for the client, because it can be filtered
> - It will be fixed as NTPv5 develops/deploys
> 
> ##  Who should solve the problem?
> Yes, this is an implementation issue.  RFC5905 (9.2) saids
> "Format checks require correct field length and alignment, acceptable
> version number (1-4), and correct extension field syntax, if present."

Should a NTPv5 server really respond to v1 and v2 queries? It was OK for v3, and probably the phrase was copied for v4 with a minor modification.

> 
> Even if it is fixed, I think it will take some time for all public ntp
> servers to be replaced. Meanwhile, we may be able to mitigate this problem
> with the v5 design that does not cause incorrect response.

A client can never prevent a server from sending an invalid response IMHO.

Regards,
Ulrich

> 
> I welcome any comments.
> 
> Thank you for reading the entire email.
> 
> Best regards