Subject: [Ntp] Public NTP servers already responds to NTPv5

From: g16 <[email-masked]>
Date: Mon, 30 Nov 2020 00:49:09 +0900

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

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

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."

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.

I welcome any comments.

Thank you for reading the entire email.

Best regards

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 29 Nov 2020 20:43:32 +0100

> So I surveyed how the currently public NTP servers respond to NTPv5 packets.

The draft document probably doesn't make things better. It says to
just drop the packet in case the version is higher than 5, nor
does it have any text on what a client could do to talk to a
server that supports older versions. So in case a version 6 is ever
introduced, first the stratum 1 servers have to upgrade, then the
stratum 2 servers, and so on.

Either the the v5 packet should be in such a format that a v4
server can interprete the packet and reply in v4, or a v4 server
should tell the client which version it does support.

Reading the draft document, it at least looks like we try to be
compatible to the v4 format.

Kurt

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 30 Nov 2020 08:23:15 +0100

>>> g16 <[email-masked]> schrieb am 29.11.2020 um 16:49 in Nachricht
> - 10% response: NTPv4 or NTPv3

In my view 65% of those servers are broken.

> - 10% response: NTPv4 format packet that version field is  5

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.

> 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.

> 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

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 30 Nov 2020 12:42:27 +0100

> So I surveyed how the currently public NTP servers respond to NTPv5 packets.

Thanks for doing that.

> - 65% response: NTPv4 format packet that version field is 5

This seems to be mostly the ntp.org ntpd.

> - 10% response: NTPv4 or NTPv3

This is mostly the NIST NTP implementation.

> - 10% response: NTPv4 format packet that version field is  5

This seems to be mostly the Google and Cloudflare NTP implementations.

> I'm not sure. It may confuse implementations that support nptv5.

I don't think it's a problem. An NTPv5 client following the draft
is supposed to check the client cookie field (replacing the origin
timestamp), which will be incorrect if it is a NTPv4 response using
version 5. For the client it will look like an off-path attacker.
All NTP clients need to be able to deal with unexpected responses.

Please note that the broken servers respond also to versions 6 and 7.
There is no point in trying to make v5 compatible with v4 and
postponing incompatible changes to v6.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 30 Nov 2020 12:51:40 +0100

> just drop the packet in case the version is higher than 5, nor

My intention was to let the future NTPv6 specification describe how
older versions should be handled in the same way this draft allows an
NTPv5 server handle requests with versions 4 and older.

> server that supports older versions.

The client could try NTPv5 and see if it gets a valid response. This
would be similar to the proposed detection of the alternative port.

> So in case a version 6 is ever

I hope that won't be necessary.

-- 
Miroslav Lichvar

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 30 Nov 2020 12:52:28 +0100

> postponing incompatible changes to v6.

Then I suggest that the client and server packet should not be the
same format, and that there is no reason for the client to send
all those fields with 0 filled in.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 30 Nov 2020 12:56:28 +0100

> all those fields with 0 filled in.

You mean to make the client request shorter containing only the
relevant fields? That would cause a traffic amplification and
also an asymmetric network delay with an impact on accuracy of
synchronization.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Nov 2020 04:14:10 -0800

> This seems to be mostly the ntp.org ntpd.

Dave has long insisted this is a feature.  I'll discuss this with him
more. I believe he has always intended that any changes to the packet
format would *extend* the packet, so if v5 needed more fields they would
be after the v4 payload, so if a request came in to a v4 server with a
v5 (or greater) version, the client would respond with the same version
from the other side, and that side would know how to deal with it
because of the packet length.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 30 Nov 2020 13:30:17 +0100

> because of the packet length.

FWIW, ntpd doesn't respond to any longer packet. At most it responds
with a crypto NAK if it looks like a MAC with specific length.

>From the code it looks like a bug. NTPv5 packets are classified as
"previous version", with no case handling future versions.

        } else if (   !(restrict_mask & RES_VERSION)
                   && hisversion >= NTP_OLDVERSION) {
                sys_oldversion++;               /* previous version */                                                                  

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Nov 2020 04:45:22 -0800

> with a crypto NAK if it looks like a MAC with specific length.

Yes.

>                 sys_oldversion++;               /* previous version */                                                                  

It's a bug that we don't properly count newer versions.

---

From: g16 <[email-masked]>
Date: Mon, 30 Nov 2020 23:11:29 +0900

Everyone and Miroslav

Thank you for your interest and reply.

Miroslav's reply makes a lot of sense. In NTPv5 draft-00, I understand that
the client can reject bad responses.
> version 5.

Considering future deployment, I think the following description in spec
(6.2) is sufficient.
> 2.  Checks the version in the request.  If it is larger than 5, it
>    MUST drop the request.

I will continue to do some research. If I find something, I will report it.

thank you

---

From: Danny Mayer <[email-masked]>
Date: Mon, 30 Nov 2020 09:42:01 -0500

> It's a bug that we don't properly count newer versions.

My understanding was that you only should respond with the current 
version that the server is running and MAY respond to the previous 
version. All other version numbers should be ignored and the packets 
dropped. I don't think we have been doing this and I don't think it's 
documented in any RFC but I think that SHOULD be the behavior. This will 
force bad implementations to fix their code.

Different packet sizes for different versions is a separate issue and 
with extension fields possibly present in the packet that can cause an 
previous version to have a larger packet size than the current version. 
That may well be the case for a NTPv5 and don't forget that NTPv4 will 
be around for many years after NTPv5 finally arrives.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 30 Nov 2020 11:09:30 -0500

On 11/30/20 9:42 AM, Danny Mayer wrote:
> documented in any RFC but I think that SHOULD be the behavior. This 
> will force bad implementations to fix their code.
>
> previous version to have a larger packet size than the current 
> version. That may well be the case for a NTPv5 and don't forget that 
> NTPv4 will be around for many years after NTPv5 finally arrives.
>
I forgot to add that we should include in the document whether or not a 
NTPv5 server should reply to an NTPv4 request with a NTPv4 response and 
not an NTPv5 response. Whether you can respond with NTPv5 packets to an 
NTPv4 request depends whether or not the NTPv5 packet is a proper 
superset of an NTPv4 packet.

Separately you need to decide how to deal with a NTPv5 request coming to 
an NTPv4 server and how it should respond.

Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 08:36:16 +0100

>>> Danny Mayer <[email-masked]> schrieb am 30.11.2020 um 17:09 in Nachricht

> superset of an NTPv4 packet.

Hi!

You mean a NTPv5 packet with a version 4 in the header? What sense does that make?
Thge best the client can do is ignore the packet realizing it cannot handle it. How can an old v4 client know how a future v5 packet will look like? Accepting a v5 packet needs to know exactly that.

> an NTPv4 server and how it should respond.

It has two choices: Not responding or responding with a proper v4 packet. However then the client has the same problem: Sending v5, but receiving v4: Ignore or accept?

IMHO a v4 server should _never_ answer a packet version it does not know about. I know you cannot change the past, however.

Regards,
Ulrich

> 
> Danny
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp