[Ntp] Public NTP servers already responds to NTPv5

g16 <g16g16g16@gmail.com> Sun, 29 November 2020 15:49 UTC

Return-Path: <g16g16g16@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F414D3A0656 for <ntp@ietfa.amsl.com>; Sun, 29 Nov 2020 07:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEmeffUeRpti for <ntp@ietfa.amsl.com>; Sun, 29 Nov 2020 07:49:36 -0800 (PST)
Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374D03A0653 for <ntp@ietf.org>; Sun, 29 Nov 2020 07:49:36 -0800 (PST)
Received: by mail-oo1-xc31.google.com with SMTP id i7so2147583oot.8 for <ntp@ietf.org>; Sun, 29 Nov 2020 07:49:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=n9TmyhPCOYChJPS85JsduuwEjhzv/hhtuJCwD78krvk=; b=vDr62gXb4VYtu8Q+oR85Lz5Vw4HNxTBHWc0rAhJqAwRxCIf3HWjFoVAy0GRvMk7KHl 9Zp58I7aKXl+jzfcJcR/n4gYkO3nT/wT12q7cH2FlmlsL2ETDOT8w9ZB8wpOfduk54tA bNEcvFY9T0nCZeUSRgGrTOE0hTEnWrZ6bLvWgpgHCH3szWWn49EicX3vFR2UXF2uqiNo ixKUfNczx7jtPwLYoAcQUFdrBTEWdWzks6EiOvz/7lV+VcWjZb+j8rA3o9j6X04mZK+A eiEAYXSY6LiDkRc84hK+TQQ7oLrY0YezpDq9V6WPlUyTdQntl213cwc5Sv7xQbG4BZjH xDrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n9TmyhPCOYChJPS85JsduuwEjhzv/hhtuJCwD78krvk=; b=pcxJXXG1cBJmeplcmUkG8ZBHETj8nWoLz+OdEAukl+oLfrZnM26AeESPBqrXqMFWBy csbLizWew9h1YuckYlcaQXp8emK7QMxHDBUUDqdbhd9+ZKEbbfc6+1e+bywpMC3hAZvb tDxlgu9V8wkXfXzeKlhrfDtzmArqAbO+AamLPmkYxuIt0c+2qI4MD21cn64oBAMC4QEr 8SW1lbscZPE+H64BAt8lyE6vRVenXqDt/8GcUtGtHP6w7XyiX+tXvbYEUo0o9aLP3MMG RwJXQ9h4V5dHy0ScyoFj8KG288EmWWDjGmb/wzEzpaPtkJ/Dmid4mezIKpPM2Xq+T5lK 2bag==
X-Gm-Message-State: AOAM533iLWFIB92ArXVpDWd9cQ3KMCUdvP2pYE3YXH0YIrWwS3+GN777 Qw18DSuibziOnl8vRj/W/skS4ArZav6B8C2csCWNNdjadgI=
X-Google-Smtp-Source: ABdhPJyf9X086Qcak/Ir4F/TV8HLdfS40/9h/6KNoUTqjaFRxjEUbI+cOKQ8LoBt2LzcIKbNHcjqruUe6/SVgIj1KuA=
X-Received: by 2002:a4a:9711:: with SMTP id u17mr12352505ooi.57.1606664975153; Sun, 29 Nov 2020 07:49:35 -0800 (PST)
MIME-Version: 1.0
From: g16 <g16g16g16@gmail.com>
Date: Mon, 30 Nov 2020 00:49:09 +0900
Message-ID: <CAFZ=0SzC1cKbMf=9tNDdxYfde9UnD4CcLYZ2EGwvcKMEtp1i1w@mail.gmail.com>
To: ntp@ietf.org, mlichvar@redhat.com
Content-Type: multipart/alternative; boundary="0000000000001dfec805b540d78b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/YJlTu_nw3RTDJWD0ToUF72o2ggs>
Subject: [Ntp] Public NTP servers already responds to NTPv5
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Nov 2020 15:49:38 -0000

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