Subject: [Ntp] Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 28 Aug 2019 03:37:03 +0000

Folks,

The following four drafts are four different proposals for new extension fields. Please review each draft and indicate whether these should be adopted by the working group. I am sending them all as one set because they are all extension fields, but we need a response for each draft listed below. 

Thanks!
Karen and Dieter

1.  Network Time Protocol Extended Information Extension Field
https://datatracker.ietf.org/doc/draft-stenn-ntp-extended-information/

2.  Network Time Protocol I-Do Extension Field
https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/

3.  Network Time Protocol MAC/Last Extension Fields
https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/

4.  Network Time Protocol Suggested REFID Extension Field
https://datatracker.ietf.org/doc/draft-stenn-ntp-suggest-refid/

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 28 Aug 2019 08:54:20 +0200

Hi,

I do not support adopting all four drafts, I believe that we should either integrate them into a new revision of NTP ("NTPv5") or fix them problems/issues they address in that new "NTPv5" RFC. Most of the issues addressed by those drafts can be easily solved by changing/expanding the NTP packet format for "NTPv5". 

The "REFID" draft would be obsolete if an NTPv5 packet header for a server mode packet by definition includes  a "MY_ID" field. 

The "MAC/last extension field" draft would be obsolete if we define that NTPv5 does only support Extension Fields as allowed additional data and a MAC in v5 is always transported inside an extension field (the "MAC-EF" approach as described in the draft, for example). 

The "I-DO extension field" draft would be something I would integrate into a "NTPv5" RFC as a mandatory requirement for NTP servers. 

The "Extended Information Extension Field" draft would be obsolete if we introduce either additional packet header fields in v5 or just defined a new EF for information that we think should be available from the server. That EF could be sent or not, based on whether the client wants it or not (indicated by an EF sent by that client in its request, for example). 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® 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äftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 [email-masked] 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

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

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

On 28.08.19, 05:38 "ntp im Auftrag von Karen O'Donoghue" <[email-masked] im Auftrag von [email-masked]> wrote:

    Folks,

    Thanks!
    Karen and Dieter

    

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

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 28 Aug 2019 10:19:57 +0200

>>> Heiko Gerstung <[email-masked]> schrieb am 28.08.2019 um 08:54
in
Nachricht <[email-masked]>:
> Hi,
> 
> I do not support adopting all four drafts, I believe that we should either 
> integrate them into a new revision of NTP ("NTPv5") or fix them 
> problems/issues they address in that new "NTPv5" RFC. Most of the issues 
> addressed by those drafts can be easily solved by changing/expanding the NTP

> packet format for "NTPv5". 
> 
> The "REFID" draft would be obsolete if an NTPv5 packet header for a server 
> mode packet by definition includes  a "MY_ID" field. 

Hi!

Still I guess with a REFID as extension field could provide a solution
"sooner" as NTPv5, and it could be available in selected NTPv4 servers in the
near future.

> 
> The "MAC/last extension field" draft would be obsolete if we define that 
> NTPv5 does only support Extension Fields as allowed additional data and a
MAC 
> in v5 is always transported inside an extension field (the "MAC-EF" approach

> as described in the draft, for example). 

Just a random thought: Would it make sense for NTPv5 to create a completely
new packet format, or should NTPv5 be based on extension fields? Some old
clients could still try to interpret a new format with old rules (inoring the
version number). With extension fields the old clients could use NTPv5
"somewhat" (ignoring all true v5 additions), while with a new format those
clients will have a problem.

Regards,
Ulrich

> 
> The "I-DO extension field" draft would be something I would integrate into a

> "NTPv5" RFC as a mandatory requirement for NTP servers. 
> 
> The "Extended Information Extension Field" draft would be obsolete if we 
> introduce either additional packet header fields in v5 or just defined a new

> EF for information that we think should be available from the server. That
EF 
> could be sent or not, based on whether the client wants it or not (indicated

> by an EF sent by that client in its request, for example). 
> 
> Best Regards,
>    Heiko
> 
> 
> -- 
> Heiko Gerstung 
> Managing Director
> 
> On 28.08.19, 05:38 "ntp im Auftrag von Karen O'Donoghue" 
> <[email-masked] im Auftrag von [email-masked]> wrote:
> 
>     Folks,
>     
>     The following four drafts are four different proposals for new extension

> fields. Please review each draft and indicate whether these should be
adopted 
> by the working group. I am sending them all as one set because they are all

> extension fields, but we need a response for each draft listed below. 
>     
>     Thanks!
>     Karen and Dieter
>

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 28 Aug 2019 12:07:53 +0200

Hi Ulrich,

no objections if implementations want to realize the REFID solution earlier, I just would want to avoid running this through the WG to become an RFC when we all could start working on v5 and cover this in that new RFC. Might be more efficient. But that's just my opinion. 

Regarding backwards compatibility of NTPv5: I think it would be no problem to change the NTP packet format if there are requirements we want to meet that can be fulfilled more efficiently with a changed packet header. Any implementation that ignores the version field deserves whatever happens to it and, since a client mode packet contains the version number, an NTP server would most probably have to reply to a v4 client request with a v4 server response anyway. Only if an implementation sends a request with version=5 and then tries to decode the response based on a v4 packet format there will be a problem. And again, implementations doing this should go down in flames anyway IMHO. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

    in

    Hi!

    MAC 

    
    Regards,
    Ulrich

    
    EF 

    adopted

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 28 Aug 2019 12:37:52 +0200

> Regarding backwards compatibility of NTPv5: I think it would be no problem to change the NTP packet format if there are requirements we want to meet that can be fulfilled more efficiently with a ch…

I think a good reason to keep v5 mostly compatible with v4, similarly
to how previous versions were compatible with one another, would be
avoiding extra complexity in both server and client implementations.

My suggestion would be to keep the NTP header 48 octets long and
change only two fields: the refid and reference timestamp. They are
ignored by current servers and most clients. That gives us 12 octets
of contiguous space in the header to work with. That's plenty for the
timescale negotiation and other metadata. Longer fields should be in
extension fields. No MACs allowed.

FWIW, I'm willing to help with the NTPv5 specification if people are
considering to start working on that.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Aug 2019 03:42:15 -0700

> change only two fields: the refid and reference timestamp. They are

If you change the refid field how will you effect degree 1 loop detection?

> extension fields. No MACs allowed.

I assume you meant "No >legacy< MACs allowed."

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 28 Aug 2019 13:08:46 +0200

Hi Miroslav,

I do not think that it would add a lot of complexity if we would change the packet header format. 

Can you explain why you want to keep the 48 bytes length? Why is that so important? What would happen if the new v5 packet format would have, let's say, 56 bytes?

Any implementation that wants to be v4/v5 compatible can easily deal with two different packet header formats IMHO. Handling this in the right way will not remotely add as much complexity as all the other v5 changes will cause. Think about the added complexity when someone has to implement the RefID handling as described in that draft, compared to just having an additional field in the packet that indicates there is a leap second smear going on, or there is a specific ID that you want clients to use when they refer to your server in their RefID field. 

Please do not get me wrong, I do not want to change the NTP packet format at any cost (or for the sake of change or to make it as hard as possible for implementors), I just want to avoid that we all try to stick with the current format (that arguably has some shortcomings, as illustrated by the presented drafts) just because we want to avoid that someone implementing NTPv5 has to add a second packet header structure to their code and, upon receiving or sending a packet, has to select which of the two formats to work with. 

This *exactly* is why there is a version field in the header, and it is placed very close to the start of the packet to make it efficient and secure for implementations to support multiple NTP versions. 

Again, lets change the NTP packet format for v5 to make things easier and less complex for future implementations. And do not stick with the format just because you want to avoid changing your own code too much, protect bad/faulty implementations or save firewall admins from having to touch their configuration. 

That said, I would be happy to start working on v5, maybe by collecting a list of all the issues and problems that we all see in v4 and the features we would like to see added. But maybe we should open another email thread for this. 

Best Regards,
    Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 28.08.19, 12:39 "ntp im Auftrag von Miroslav Lichvar" <[email-masked] im Auftrag von [email-masked]> wrote:

    

    -- 
    Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 28 Aug 2019 13:14:58 +0200

> If you change the refid field how will you effect degree 1 loop detection?

Hopefully with something better than the current refid field based on
(hashes of) addresses. Something like your suggested-refid proposal,
except the extension field would contain both the ID of the server
(randomly generated) and the ID of the its reference.

This could fit into the space of the NTPv4 refid and reference
timestamp, but it would take 64 of those 96 bits and I'm not sure if
32 bits is enough for the other new stuff.

> I assume you meant "No >legacy< MACs allowed."

Right.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Aug 2019 04:19:29 -0700

> (randomly generated) and the ID of the its reference.

Extension fields are optional.

What benefit is there to requiring them if there's already an adequate
field for the information in the base packet?

I'm very curious how the ID if the remote server's reference will be
useful, and not just another attack vector.

> 32 bits is enough for the other new stuff.
Exactly what do you see as the use-cases for this information in the
base packet?  Exactly how would this information be used?

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 28 Aug 2019 13:23:35 +0200

Why not define a method in v5 that not only protects against degree 1 loops but maybe also against degree 2,3 or n? 

This is what I meant when trying to explain that we should not stick to the existing packet format with its shortcomings.

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 28.08.19, 13:20 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 28 Aug 2019 13:26:01 +0200

> Extension fields are optional.

Most clients don't need to know the refid, so to me it makes sense for
the refid information to be optional.

> useful, and not just another attack vector.

It's a random number and not an address. So it should be better than
the NTPv4 refid, right?

> base packet?  Exactly how would this information be used?

It seems you agree it should be optional.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 28 Aug 2019 13:30:43 +0200

> Why not define a method in v5 that not only protects against degree 1 loops but maybe also against degree 2,3 or n? 

Yes, that would be a nice feature. I think it was proposed on this list
as a new extension field some time ago. IIRC there were some security
concerns, i.e. conflict with the idea of hiding the refid. With random
refids it might make more sense.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Aug 2019 04:34:04 -0700

> the refid information to be optional.

Goes to traceability of time in environments where this information is
useful, if not critical.

> It's a random number and not an address. So it should be better than

How is this useful without knowing who the server is talking to?

> It seems you agree it should be optional.

No, I still believe the refid is a core critical component of the base
packet, at least in cases where one cares about understanding leaf
nodes.  Yes, we *could* fracture this out but I haven't seen a
significant benefit to doing this.  Making the refid optional just makes
it much harder to understand what's going on with a client.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Aug 2019 04:36:26 -0700

> This is what I meant when trying to explain that we should not stick to the existing packet format with its shortcomings.

Exactly how would this work?

Has there been any reported instances of this being useful or needed for
NTP?

What abuse vectors would this create?

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 28 Aug 2019 13:59:26 +0200

Harlan,

I asked why we would not want to improve the loop prevention mechanism, I do not have a solution at hand which I sketched out in full detail already. But here is a possibility that came to my mind just now, it certainly needs to be refined and checked and modified:

- create a random ID on each server at startup
- communicate that ID to each client which indicates (e.g. by an EF) that it is interested in this information, for example if it wants to be a server itself (stratum 2+)
- a tier-2 server uses that ID from its upstream server as its refID
- any server that is interested in degree n - loop detection will indicate this (using an EF, maybe something like the I-DO EF) to its upstream server(s)
- those servers respond with an EF containing a list of IDs representing the sync chain, maybe limited to n entries (if the requesting client asks for only n entries)
- now, if this server which received the chain of IDs from its upstream server(s) now is questioned by one of its downstream clients about the chain of sync, it will add the RefID of its upstream servers to the sync chain received by that upstream server and push this down to the client

This way, those clients interested in only degree 1 loop protection just use the RefID field. And those who are interested in degree n loop protection can request the chain of IDs from their upstream servers. 

The freedom to change the packet header format would allow us to increase the number of bytes for the RefID to improve security (more bytes, harder to guess). 

We have had cases where a server A was synchronized by server B which was synchronized by server C. Server C also used Server D which was synchronized by Server A, i.e. whenever your client believes it has more than one source of time and it turns out that all of them go back to one single source. Adding non-randomized IDs like "GPS" to the sync chain (by the stratum 1 server) would also allow the clients to identify if they are relying on one single source of time, which in turn would make it possible to choose another server with a different source (like Galileo) instead.

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 28.08.19, 13:38 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 28 Aug 2019 14:25:49 +0200

>>> Heiko Gerstung <[email-masked]> schrieb am 28.08.2019 um 13:59
in
Nachricht <[email-masked]>:
> Harlan,
> 
> I asked why we would not want to improve the loop prevention mechanism, I do

> not have a solution at hand which I sketched out in full detail already. But

> here is a possibility that came to my mind just now, it certainly needs to
be 
> refined and checked and modified:
> 

I'd add a "double-may" there: The ID MAY be random, and it MAY be re-created
on each server startup.
Maybe think of it like the driftfile that preserves some value across
restarts.

> - communicate that ID to each client which indicates (e.g. by an EF) that it

> is interested in this information, for example if it wants to be a server 
> itself (stratum 2+)

Why not always add it?

> - any server that is interested in degree n - loop detection will indicate 
> this (using an EF, maybe something like the I-DO EF) to its upstream 
> server(s)
> - those servers respond with an EF containing a list of IDs representing the

> sync chain, maybe limited to n entries (if the requesting client asks for 
> only n entries)
> - now, if this server which received the chain of IDs from its upstream 
> server(s) now is questioned by one of its downstream clients about the chain

> of sync, it will add the RefID of its upstream servers to the sync chain 
> received by that upstream server and push this down to the client
> 
> This way, those clients interested in only degree 1 loop protection just use

> the RefID field. And those who are interested in degree n loop protection
can 
> request the chain of IDs from their upstream servers. 
> 
> The freedom to change the packet header format would allow us to increase 
> the number of bytes for the RefID to improve security (more bytes, harder to

> guess). 
> 
> We have had cases where a server A was synchronized by server B which was 
> synchronized by server C. Server C also used Server D which was synchronized

> by Server A, i.e. whenever your client believes it has more than one source

> of time and it turns out that all of them go back to one single source. 
> Adding non-randomized IDs like "GPS" to the sync chain (by the stratum 1 
> server) would also allow the clients to identify if they are relying on one

> single source of time, which in turn would make it possible to choose
another 
> server with a different source (like Galileo) instead.

So this applies only to stratum-1 servers (which had spacial refIDs anyway).
What about having a "normal" REFID for stratum 1 servers, and adding a
mandatory "reference source class" (like "GPS", "Gallileo" (note the extra
length!), "NTP" (for stratum > 1), "DCF-77", etc? (Or even do it the GPT-way:
Allocate UUIDs (well, GUIDs will do as well) for all known reference clock
sources?)
And if you like splitting hairs, you could have different IDs for the "time
source" (like TAI), the "time carrier" (like GPS) and the "time access point"
(effectively the interface providing GPS time) like "Product X from Vendor Y
with further details Z"...
So if a specific product has a bug, you could filter it; if a specific carrier
has a problem, you could filter it, and if you distrust some source, you could
filter it... ;-)

Regards,
Ulrich

> On 28.08.19, 13:38 "ntp im Auftrag von Harlan Stenn" <[email-masked]

> im Auftrag von [email-masked]> wrote:
> 
>     
>     
>     > Why not define a method in v5 that not only protects against degree 1

> loops but maybe also against degree 2,3 or n? 
>     > 
>     > This is what I meant when trying to explain that we should not stick
to 
> the existing packet format with its shortcomings.
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 28 Aug 2019 14:52:11 +0200

> Any implementation that wants to be v4/v5 compatible can easily deal with two different packet header formats IMHO. Handling this in the right way will not remotely add as much complexity as all th…

Only servers care about refids.

Consider how much code will need to be written or changed to add an
NTPv5 support to existing implementations.

Most clients are extremely simple. They send a request with almost all
fields set to zero and ignore most fields in the response. Ideally, I
think upgrading such a client to NTPv5 would consist of just changing
the version in the request and accepting the version in the response
No other changes required. A single codepath works with NTPv2, NTPv3,
NTPv4, NTPv5.

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Wed, 28 Aug 2019 09:10:15 -0400

I oppose adoption of this draft; we should not be packing a bunch of
unrelated information into a single EF like this. I do agree on the
need for an EF that provides a UTC-TAI offset but
https://github.com/dfoxfranke/ntp-leap-seconds does this better.

I oppose adoption of this draft. It would be much better to define new
NTS-KE record types for exchanging this sort of static information.

I oppose adoption of this draft. Last-EF makes no sense except in
conjunction with Harlan's parsing proposal which is already a dead
document. The multiple MACs and random padding are silly as I already
explained more than three years ago.

I oppose adoption of this draft for the same reason as the I-Do draft,
but also because I oppose trying to pack yet more conflicting
semantics into the same 4-octet field.

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 28 Aug 2019 15:11:33 +0200

Miroslav,

if an implementation decides that NTPv5 support is too complicated, they can stick with v4 requests. As you know, lots of those simple implementations still send v3 requests as we speak, and as long as the servers still respond to that (they do for quite some years now), there is no need for a simple implementation to implement v5 support. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 28.08.19, 14:53 "ntp im Auftrag von Miroslav Lichvar" <[email-masked] im Auftrag von [email-masked]> wrote:

    

    -- 
    Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 28 Aug 2019 15:32:16 +0200

Apologies for the more or less broken quoting style. Outlook is crap in this regard ..

    in

    be 

OK, fine with me. 

    
    Why not always add it?
    
Because as Miroslav already pointed out, most client-only implementations do not need it. 

    
    
    can 

    
    
    another 

No, the whole sync chain thing would be applicable to all servers, not only stratum 1's. I just wanted to point out that you can avoid using the same root source of time with the stratum 1 servers creating the sync chain by just initializing it with a standardized RefID (like "GPS") referring to their non-NTP source. That way, a client could avoid using three servers all taking their time from GPS and then get hit by the same spoofing attack. 

Yes, why not. And yes, I took notice of the longer RefID value ;-) ...

Yep!

Regards,
    Heiko

    Regards,
    Ulrich

    
    to 

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn:

---

From: Watson Ladd <[email-masked]>
Date: Wed, 28 Aug 2019 08:58:47 -0700

I concurr completely with the points below.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Aug 2019 16:03:46 +0000

Whew, Christmas/Hannuka/Festivus came early. :)

I support adopting Anchal's roughtime draft; do we need a rechartering?

I support the Schiff chronos document, it should at least be a BCP if not proposed-standard updating 5905.

I support adopting the Gonts's (sic:) port randomization draft.

I share the concerns of several others about the four Stenn documents and would prefer that we re-chartered and worked on a new v5 protocol that assumes NTPsec and security as a base. Perhaps roughtime becomes part of it as well. I appreciate Harlan's efforts in trying to shoe-horn new capabilities into NTPv4, but the leather is too cracked to take more wear and we should think about what it would mean to move on. On a personal level, I regret saying this having known Harlan since UUCP days. :)

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 29 Aug 2019 08:21:36 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 28.08.2019 um 14:52 in
Nachricht <20190828125211.GN24761@localhost>:
>> Any implementation that wants to be v4/v5 compatible can easily deal with 
> two different packet header formats IMHO. Handling this in the right way
will 
> not remotely add as much complexity as all the other v5 changes will cause.

> Think about the added complexity when someone has to implement the RefID 
> handling as described in that draft, compared to just having an additional 
> field in the packet that indicates there is a leap second smear going on, or

> there is a specific ID that you want clients to use when they refer to your

> server in their RefID field. 
> 

But from the view of their time suppliers those are clients.

> ‑‑

---

From: Dieter Sibold <[email-masked]>
Date: Thu, 29 Aug 2019 10:02:47 +0000

With the WG chair hat off: I agree with Heiko. If we specify NTPv5 we should not restrict ourselves to the limitations of the existing packet format.

Regards
Dieter

Am 28.08.19, 13:24 schrieb "ntp im Auftrag von Heiko Gerstung" <[email-masked] im Auftrag von [email-masked]>:

    
    Regards,
       Heiko
    
    -- 
    Heiko Gerstung 
    Managing Director

    
    Email:

    Connect via LinkedIn:

---

From: [email-masked]
Date: Fri, 30 Aug 2019 14:34:43 +0200

Hello all,

I also oppose adoption of the four draft as documents intended for use 
with NTPv4.

I broadly agree with Heiko's assessment insofar as I think most of the 
individual content in the four drafts is relevant, but should be treated 
in a different context: 
not as an attempt to repair the holes that are opening up in NTPv4, but as 
a set of principles going into the next revision of NTP ("NTPv5", likely).

Best regards,
Kristof

P.S.:

This is especially drastic for the I-DO proposal, where I do not see how 
it makes sense to try to catch implementation that are too old to 
understand certain newer EFs by forcing them to understand another new EF 
with which they can talk about which EFs they do understand.
It does seem important to do something akin to this, but I really think it 
only makes sense if you can assume ALL implementations to a) understand 
the I-DO-inspired EF and b) be able to use crypto methods to provide 
authentication for whatever is in the I-DO-inspired EF.

Semi-related, I really believe NTPv5 should enable behavior that splits 
messages (especially server responses) into two parts, the first as small 
as possible, basically only an identifier saying that it is an NTP packet 
and providing an ID for the association/exchange it belongs to, the second 
carrying all the timestamps and meta information.
This would enable an almost completely free choice of information that a 
client could request, each piece of it in its own extension field, without 
it endangering speed or accuracy.
But it is another feature you can only have if you can expect all 
participants to understand it.

Von:    "Heiko Gerstung" <[email-masked]>
An:     "Karen O'Donoghue" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Datum:  28.08.2019 08:55
Betreff:        Re: [Ntp] Calls for Adoption -- NTP Extension Field drafts 
-- Four separate drafts
Gesendet von:   "ntp" <[email-masked]>

Hi,

I do not support adopting all four drafts, I believe that we should either 
integrate them into a new revision of NTP ("NTPv5") or fix them 
problems/issues they address in that new "NTPv5" RFC. Most of the issues 
addressed by those drafts can be easily solved by changing/expanding the 
NTP packet format for "NTPv5". 

The "MAC/last extension field" draft would be obsolete if we define that 
NTPv5 does only support Extension Fields as allowed additional data and a 
MAC in v5 is always transported inside an extension field (the "MAC-EF" 
approach as described in the draft, for example). 

The "I-DO extension field" draft would be something I would integrate into 
a "NTPv5" RFC as a mandatory requirement for NTP servers. 

The "Extended Information Extension Field" draft would be obsolete if we 
introduce either additional packet header fields in v5 or just defined a 
new EF for information that we think should be available from the server. 
That EF could be sent or not, based on whether the client wants it or not 
(indicated by an EF sent by that client in its request, for example). 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
Hartmann, Heiko Gerstung

Email:

Connect via LinkedIn: 

    Folks,
 
    The following four drafts are four different proposals for new 
extension fields. Please review each draft and indicate whether these 
should be adopted by the working group. I am sending them all as one set 
because they are all extension fields, but we need a response for each 
draft listed below. 
 
    Thanks!
    Karen and Dieter