Return-Path: 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 9EBF2120096; Thu, 25 Jul 2019 01:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 0w6qQ7M8M_kU; Thu, 25 Jul 2019 01:21:24 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1264A120045; Thu, 25 Jul 2019 01:21:23 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id x6P8LLmK004469-x6P8LLmM004469 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Jul 2019 10:21:21 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id F036C815B04; Thu, 25 Jul 2019 10:21:18 +0200 (CEST) In-Reply-To: <2CF584EA-17C5-4623-AA0A-FAB215DEF288@meinberg.de> References: <626997121-17255@srv-kerioconnect.py.meinberg.de> <2CF584EA-17C5-4623-AA0A-FAB215DEF288@meinberg.de> To: "Heiko Gerstung" Cc: "Daniel Franke" , "Doug Arnold" , "NTP WG" , "ntp" MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Thu, 25 Jul 2019 10:22:05 +0200 Content-Type: multipart/alternative; boundary="=_alternative 002DE4DFC1258442_=" Archived-At: Subject: Re: [Ntp] Follow-up to yesterday's mic comment about PTP security X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 08:21:27 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002DE4DFC1258442_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable To be clear: I'm not trying to say that using NTP/NTS rather than PTP on=20 campus (locally) helps you out in any significant way. But using NTP/NTS rather than GNSS to *get UTC to your campus* (globally)=20 helps you out on one critical aspect: guaranteed traceability - the other=20 being precision/accuracy levels, (where NTP/NTS performs much worse than=20 GNSS). If you're able to use PTP (hopefully secured PTP soon) over a=20 long-distance landline to synchronize to a master that is NMI-levels close = to UTC, then that seems pretty close to ideal - but it does require the=20 appropriate landline, which is not trivial and rules this option out for=20 many users. Regarding generalizations of protocol properties: some things do depend on = the transmission protocol, specifically on whether it allows messages in=20 both directions or just one. We have proof that "NTP/NTS =3D (Time of NTP/NTS Server) +- (roughly half o= f=20 RTT)" is actually valid. This holds because you get a crypto-secured 2-way = exchange. And it works if your NTP server in this case is the NTP server of your=20 appropriate NMI, and they might be able to give you the additional=20 uncertainty for how close to their utc(NMI) the NTP server is - and that=20 gets you very close to actual, full on 100%-guaranteed (if you assume the=20 worst-cases conservatively enough) traceability, proven by the properties=20 of the transmission protocol. That is something that you *cannot* get with any purely 1-way based=20 transmission method, specifically with a GNSS receiver - no matter what=20 crypto people throw onto the GNSS signal, because delay attacks exist and=20 are not just unpreventable but unbounded in pure 1-way connections. I know that MiFID II in particular does not acknowledge this and=20 specifically accepts GNSS (I think even explicitly GPS) as satisfactory -=20 but I think that this should be changed in the next guideline, and also=20 carefully suspect that it actually might be. Best regards, Kristof =20 Von: "Heiko Gerstung" An: "kristof.teichel@ptb.de" , "Doug Arnold"=20 Kopie: "NTP WG" , "Daniel Franke" Datum: 25.07.2019 09:39 Betreff: Re: [Ntp] Follow-up to yesterday's mic comment about PTP=20 security Gesendet von: "ntp" I agree with Kristof that using GPS (or any other GNSS for that matter)=20 does not automagically turns your PTP GM into a UTC traceable time source. = The folks of NPL have shown that you can use PTP (without GNSS) to=20 transfer UTC traceable time with a high level of accuracy (<1us) over long = distances. So "PTP !=3D UTC" is obviously as generalizing as "NTP/NTS =3D=20 UTC". It doesn't depend on the network protocol.=20 =20 I get the point of Kristof that using GPS in the setup Doug described will = not guarantee UTC, but funny as it is, the European MiFID II regulation=20 specifically accepts using GNSS to obtain time and be compliant with the=20 UTC requirements of ESMA.=20 =20 My goal is to work on using NTS-KE for PTP as well, if anyone is=20 interested in joining us to work out something please let me know.=20 =20 Regards, Heiko =20 =20 --=20 Heiko Gerstung=20 Managing Director MEINBERG=AE Funkuhren GmbH & Co. KG Lange Wand 9 D-31812 Bad Pyrmont, Germany Phone: +49 (0)5281 9309-404 Fax: +49 (0)5281 9309-9404 Amtsgericht Hannover 17HRA 100322 Gesch=E4ftsf=FChrer/Management: G=FCnter Meinberg, Werner Meinberg, Andre=20 Hartmann, Heiko Gerstung Email: heiko.gerstung@meinberg.de=20 Web: Deutsch https://www.meinberg.de English https://www.meinbergglobal.com Do not miss our Time Synchronization Blog: https://blog.meinbergglobal.com=20 Connect via LinkedIn:=20 https://www.linkedin.com/in/heikogerstung =20 =20 =20 Von: ntp im Auftrag von Datum: Donnerstag, 25. Juli 2019 um 09:14 An: Doug Arnold Cc: NTP WG , Daniel Franke Betreff: Re: [Ntp] Follow-up to yesterday's mic comment about PTP security =20 Good morning all,=20 what you will really need from these folks, Doug, is a clear statement of=20 whether they need their level of synchronicity (50ms, 100us, whatever)=20 only locally between all their machines or also in reference to a global=20 time scale such as UTC.=20 And maybe if they need different precision/accuracy levels for both, such=20 as needing/wanting sub-ns level locally and a 100% guaranteed 100us within = UTC or something like that (I suspect something like this will turn out to = be true for most of them).=20 Using PTP to make sure that all of their devices agree on the time to a=20 better-than-100us level is fine, but if they need actual guarantees with=20 regard to UTC, it might be short-sighted to just go "well, our server is=20 GPS-disciplined, so basically as good as UTC".=20 Best regards,=20 Kristof=20 Von: "Doug Arnold" =20 An: "NTP WG" =20 Kopie: kristof.teichel@ptb.de, "Daniel Franke"=20 =20 Datum: 24.07..2019 21:17=20 Betreff: Re: [Ntp] Follow-up to yesterday's mic comment about PTP=20 security=20 Hello Everyone,=20 Some financial companies only need 50 ms, and for them I recommend NTP. It = is cheaper and easier to install than PTP, and the protocol is more mature = and implementations are usually robust. In general they prefer to have=20 their own NTP servers, inside their network, and behind the fire wall. I=20 will be recommending NTS when available from their vendor. That will be=20 an easy sell, since they generally want to turn on security options for=20 the protocols they use.=20 Some network operators tell me that achieving 100 us time synchronization=20 in their network is near the edge of what they currently get using NTP, so = they want to switch to PTP for this spec and the coming tighter specs.=20 Most of them have switches and routers which have PTP on path support or=20 the operators expect them to in the near future. This will be an issue=20 which needs discussion since that represents a security challenge. If=20 every switch is shaping the information, then there is either a "secret"=20 every node knows, or many secrets, each of which must be kept.=20 Doug From: =20 To: Daniel Franke =20 Cc: NTP WG =20 Sent: 7/24/2019 9:00 AM=20 Subject: Re: [Ntp] Follow-up to yesterday's mic comment about PTP security = Hey all,=20 first of all, I'm really glad if this whole thing (security of one-way=20 mechanisms and mechanism selection) is a discussion that we're going to=20 have in the WG.=20 To comment on your assertions, Daniel:=20 1.=20 It is established in general (and I have a proof lying around for a model=20 of NTS in particular) that a client performing a request-response exchange = with NTS and using all relevant checks gets a strong guarantee that the=20 error in its measured offset is no larger than half the added flight times = of the packets (plus some negligibly small delta accounting for frequency=20 instability of the clocks used on client and server side).=20 For anyone wondering why we bothered to prove this again: this guarantee=20 is 100%, and the new part is "no matter what a Man-in-the-Middle attacker=20 did in the process".=20 So I would be careful about naming a specific amount, because flight times = do depend on the specific client's connection - but 50ms seems like a good = rule of thumb, and I overall agree with your assertion.=20 2.-3.=20 If we're operating und the assumptions that=20 a) you can only use one time sync mechanism at a time and keep track of=20 one clock disciplined via data from that mechansim, and=20 b) end users always have exactly one requirement level for each of=20 security and precision/accuracy and need to use the least-effort path to=20 achieve them=20 .... then I agree with your assertions whole-heartedly.=20 But I really think both assumptions deserve their own hard looks and=20 considerations.=20 For example, it might be reasonable for someone, specifically a financial=20 institute, to run NTP with NTS in their local network to obtain a 100%=20 security guarantee for a 100us level (demanded by MiFID II for example)=20 and also still use PTP / White Rabbit (unsecured for the time being) to=20 have the precision/accuracy levels they actually want - with no strong=20 guarantee, but still valid in the (most likely) case that their=20 infrastructures are not currently under attack.=20 4.=20 Again, I agree with the assertion for the most part and in the given=20 status quo.=20 But the underlying assumption that every relevant adversarial 2-way=20 network also suffers from long, unpredictable and asymmetric travel times=20 is mostly valid because the only candidate for such a network is the=20 internet.=20 If someone built, say, a GNSS network where two-way communication (with=20 satellites or between two ground stations) was readily available to=20 everyone, the whole situation would be different:=20 That would still potentially qualify as an adversarial network, but with=20 the proper crypto, your 100% security guarantees could be extended to much = better precision/accuracy levels.=20 The same thing could be true for long-distance tree-topology fibre-based=20 networks exclusively for time synchronization - which are kind of in the=20 process of being built all over Europe.=20 Lengthy comments and caveats notwithstanding, I agree with and would=20 endorse your 1.-4. decision making sheet as an excellent starting point.=20 Best regards,=20 Kristof=20 "ntp" schrieb am 23.07.2019 18:19:33: > Von: "Daniel Franke" =20 > An: "NTP WG" =20 > Datum: 23.07.2019 18:20=20 > Betreff: [Ntp] Follow-up to yesterday's mic comment about PTP security=20 > Gesendet von: "ntp" =20 >=20 > My comments yesterday about PTP security shifted context a few times > so it may have been hard to follow what I was claiming. My assertions > were: >=20 > 1. If you need 50ms precision, pick some good public NTP servers and use = NTS. >=20 > 2. If you need 100=B5s precision, colocate a time source in the same > datacenter as the client systems. Use NTP and NTS; you don't need PTP > for this. >=20 > 3. If you need 1=B5s precision, use PTP and physically secure the link > between the time source and the clients so that cryptographic > authentication is unnecessary. >=20 > 4. If you need 1=B5s precision over an adversarial network, good luck! > This is simply not achievable and no amount of cryptographic pixie > dust is ever going to save you. >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=20 ntp mailing list=20 ntp@ietf.org=20 https://www.ietf.org/mailman/listinfo/ntp=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ntp mail= ing list=20 ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --=_alternative 002DE4DFC1258442_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable To be clear: I'm not trying to say that using NTP/NTS rather than PTP on campus (locally) helps you out in any significant way.
But using NTP/NTS rather than GNSS to *get UTC to your campus* (globally) helps you out on one critical aspect: guaranteed traceability - the other being precision/accuracy levels, (where NTP/NTS performs much worse than GNSS).
If you're able to use PTP (hopefully secured PTP soon) over a long-distance landline to synchronize to a master that is NMI-levels close to UTC, then that seems pretty close to ideal - but it does require the appropriate landline, which is not trivial and rules this option out for many users.

Regarding generalizations of protocol properties: some things do depend on the transmission protocol, specifically on whether it allows messages in both directions or just one.
We have proof that "NTP/NTS =3D= (Time of NTP/NTS Server) +- (roughly half of RTT)" is actually valid. This holds because you get a crypto-secured 2-way exchange.
And it works if your NTP server in t= his case is the NTP server of your appropriate NMI, and they might be able to give you the additional uncertainty for how close to their utc(NMI) the NTP server is - and that gets you very close to actual, full on 100%-gu= aranteed (if you assume the worst-cases conservatively enough) traceability, proven by the properties of the transmission protocol.
That is something that you *cannot* get with any purely 1-way based transmission method, specifically with a GNSS receiver - no matter what crypto people throw onto the GNSS signal, because delay attacks exist and are not just unpreventable but unbounded in pure 1-way connections.

I know that MiFID II in particular d= oes not acknowledge this and specifically accepts GNSS (I think even explicitly GPS) as satisfactory - but I think that this should be changed in the next guideline, and also carefully suspect that it actually might be.


Best regards,
Kristof





 


Von:     &= nbsp;  "Heiko Gerstung" <heiko.gerstung@meinberg.de>
An:     &n= bsp;  "kristof.teichel@ptb.d= e" <kristof.teichel@ptb.de>, "Doug Arnold" <doug.arnold@mei= nberg.de>
Kopie:    =    "NTP WG" <ntp@ietf.org>, "Daniel Franke" <dfoxfranke@gmail.com>= ;
Datum:    =    25.07.2019 09:39
Betreff:   &nbs= p;    Re: [Ntp] Follow-up to yesterday's mic comment about PTP security
Gesendet von:  =      "ntp" <ntp-bounces@ietf.org>



I agree with Kristof that using GPS (or any other GNSS for that matter) does not automagically turns your PTP GM into a UTC traceable time source. The folks of NPL have shown that you can use PTP (without GNSS) to transfer UTC traceable time with a high level of accuracy (<1us) over long distances. So "PTP !=3D UTC" is obviously as generalizing as "NTP/NTS =3D UTC". It doesn't depend on the network protocol.
 
I get the point of Kristof that using G= PS in the setup Doug described will not guarantee UTC, but funny as it is, the European MiFID II regulation specifically accepts using GNSS to obtain time and be compliant with the UTC requirements of ESMA.
 
My goal is to work on using NTS-KE for PTP as well, if anyone is interested in joining us to work out something please let me know.
 
Regards,
   Heiko
 
 
--
Heiko Gerstung
Managing Director

MEINBERG=AE Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Gesch=E4ftsf=FChrer/Management: G=FCnter Meinberg, Werner Meinberg, Andre H= artmann, Heiko Gerstung

Email:
heiko.gerstung@meinberg.de
Web:
Deutsch   https://www.meinberg.de
English    https://www.meinbergglobal.c= om

Do not miss our Time Synchronization Blog:
https://blog.meinbergglobal.com

Connect via LinkedIn: <= u>
https://www.linkedin.com/in/heikog= erstung
 
 
 
Von: ntp <ntp-bounces@ietf.or= g> im Auftrag von <kristof.teichel@ptb.de>
Datum: Donnerstag, 25. Juli 2019 um 09:14
An: Doug Arnold <doug.arnold@meinberg.de>
Cc: NTP WG <ntp@ietf.org>, Daniel Franke <dfoxfranke@gmail.com= >
Betreff: Re: [Ntp] Follow-up to yesterday's mic comment about PTP secur= ity
 
Good morning all,

what you will really need from these folks, Doug, is a clear statement of whether they need their level of synchronicity (50ms, 100us, whatever) only locally between all their machines or also in reference to a global time scale such as UTC.
And maybe if they need different precision/accuracy levels for both, such as needing/wanting sub-ns level locally and a 100% guaranteed 100us within UTC or something like that (I suspect something like this will turn out to be true for most of them).

Using PTP to make sure that all of their devices agree on the time to a better-than-100us level is fine, but if they need actual guarantees with regard to UTC, it might be short-sighted to just go "well, our server is GPS-disciplined, so basically as good as UTC".


Best regards,
Kristof




Von:        "= Doug Arnold" <doug.arnold@meinberg.de>
An:        "N= TP WG" <ntp@ietf.org>
Kopie:        kris= tof.teichel@ptb.de, "Daniel Franke" <dfoxfranke@gmail.com>
Datum:        24.0= 7..2019 21:17
Betreff:        Re: [Ntp] Follow-up to yesterday's mic comment about PTP security




Hello Everyone,

Some financial companies only need 50 ms, and for them I recommend NTP.  It is cheaper and easier to install than PTP, and the protocol is more mature and implementations are usually robust.  In general they prefer to have their own NTP servers, inside their network, and behind the fire wall.  I will be recommending NTS when available from their vendor.  That will be an easy sell, since they generally want to turn on security options for the protocols they use.

Some network operators tell me that achieving 100 us time synchronization in their network is near the edge of what they currently get using NTP, so they want to switch to PTP for this spec and the coming tighter specs.  Most of them have switches and routers which have PTP on path support or the operators expect them to in the near future.  This will be an issue which needs discussion since that represents a security challenge.  If every switch is shaping the information, then there is either a "secret" every node knows, or many secrets, each of which must be kept.

Doug


From: <kristof.teichel@ptb.de>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: NTP WG <ntp@ietf.org>
Sent: 7/24/2019 9:00 AM
Subject: Re: [Ntp] Follow-up to yesterday's mic comment about PTP secur= ity

Hey all,

first of all, I'm really glad if this whole thing (security of one-way mechanisms and mechanism selection) is a discussion that we're going to have in the WG.

To comment on your assertions, Daniel:

1.
It is established in general (and I have a proof lying around for a model of NTS in particular) that a client performing a request-response exchange with NTS and using all relevant checks gets a strong guarantee that the error in its measured offset is no larger than half the added flight times of the packets (plus some negligibly small delta accounting for frequency instability of the clocks used on client and server side).
For anyone wondering why we bothered to prove this again: this guarantee is 100%, and the new part is "no matter what a Man-in-the-Middle attac= ker did in the process".
So I would be careful about naming a specific amount, because flight times do depend on the specific client's connection - but 50ms seems like a good rule of thumb, and I overall agree with your assertion.

2.-3.
If we're operating und the assumptions that
a) you can only use one time sync mechanism at a time and keep track of one clock disciplined via data from that mechansim, and
b) end users always have exactly one requirement level for each of security and precision/accuracy and need to use the least-effort path to achieve them
.... then I agree with your assertions whole-heartedly.

But I really think both assumptions deserve their own hard looks and consid= erations.
For example, it might be reasonable for someone, specifically a financial institute, to run NTP with NTS in their local network to obtain a 100% security guarantee for a 100us level (demanded by MiFID II for example) and also still use PTP / White Rabbit (unsecured for the time being) to have the precision/accuracy levels they actually want - with no strong guarantee, but still valid in the (most likely) case that their infrastruct= ures are not currently under attack.

4.
Again, I agree with the assertion for the most part and in the given status quo.
But the underlying assumption that every relevant adversarial 2-way network also suffers from long, unpredictable and asymmetric travel times is mostly valid because the only candidate for such a network is the internet.=
If someone built, say, a GNSS network where two-way communication (with satellites or between two ground stations) was readily available to everyon= e, the whole situation would be different:
That would still potentially qualify as an adversarial network, but with the proper crypto, your 100% security guarantees could be extended to much better precision/accuracy levels.
The same thing could be true for long-distance tree-topology fibre-based networks exclusively for time synchronization - which are kind of in the process of being built all over Europe.


Lengthy comments and caveats notwithstanding, I agree with and would endorse your 1.-4. decision making sheet as an excellent starting point.


Best regards,
Kristof


"ntp" <ntp-bounces@ietf.org> schrieb am 23.07.2019 18:19:33= :

> Von: "Daniel Franke" <dfoxfranke@gmail.com>
> An: "NTP WG" <ntp@ietf.org>
> Datum: 23.07.2019 18:20 =
> Betreff: [Ntp] Follow-up to yesterday's mic comment about PTP security=
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> My comments yesterday about PTP security shifted context a few times > so it may have been hard to follow what I was claiming. My assertions<= br> > were:
>
> 1. If you need 50ms precision, pick some good public NTP servers and use NTS.
>
> 2. If you need 100=B5s precision, colocate a time source in the same > datacenter as the client systems. Use NTP and NTS; you don't need PTP
> for this.
>
> 3. If you need 1=B5s precision, use PTP and physically secure the link=
> between the time source and the clients so that cryptographic
> authentication is unnecessary.
>
> 4. If you need 1=B5s precision over an adversarial network, good luck!=
> This is simply not achievable and no amount of cryptographic pixie
> dust is ever going to save you.
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> ntp mailing list
> ntp@ietf.org
> https://www.ie= tf.org/mailman/listinfo/ntp<= br>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo= /ntp

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ntp mail= ing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--=_alternative 002DE4DFC1258442_=--