[Ntp] Re: [IANA #1413181] NTP Extension Field additions, and IANA NTP table management process (ntp-parameters)

[[e-mail]]

1) Compatibility problem:
I don't believe this one was unclear in the slightest, especially since it 
is follwowing Miroslav's argument, who quoted with reference:

> Quoting from section 2 of
> https://datatracker.ietf.org/doc/html/draft-stenn-ntp-mac-last-ef-04:
>
>   In the example below the Field Length in the LAST-EF is 4, because
>   there is clearly no need in this case for the 28 octets required by
>   RFC 7822 [RFC7822].  But the LAST-EF could have any supported length,
>   as any payload is ignored.

Do you wish to debate that this poses an incompatibility with 
RFC7822-compliant implementations?
Because that discussion hardly seems productive, or in-good-faith.
(You could BTW just choose to make it RFC7822-compliant with a one-liner, 
or arguably by just not going out of your way to make clear that you don't 
think 7822 should be followed here)

2) Problem with potential harm to the NTP (or even NTP-external) 
ecosystem:
This one is harder to pin down, because it concerns I-DO (
https://datatracker.ietf.org/doc/html/draft-stenn-ntp-i-do-06) 
specifically the interaction between an "offer" and a "response" (or 
"I-DO-RESPONSE", or "I-Do Response") message, which is not documented all 
that well in that document version.
(Response is mentioned from page 3, an offer -or the fact that there is a 
dichotomy offer/response- seems is mentioned from page 5...)
But there is this (Section 2.3 "Behavior", bottom of page 5):

> Any system that receives an I-Do "offer", 0x0007, SHOULD reply with
> an I-Do "response", 0x8007.
>
> Any system that sends an I-Do "offer" or "response" may send as few
> or as many of its supported Field Types as it chooses.

...and this seems to me completely at odds with our policy of preventing 
amplification attacks by ensuring that one cannot provoke a longer reply 
by sending a shorter request.
It might be argued that with two-octet identifiers and a manageable number 
of potential EF types, this shouldn't be a big deal; but I think it has 
potential for problems (in theory, a response EF could be 2^16*2 bytes, 
which meets and exceeds any reasonable max packet length, in response to a 
minimal-length offer EF which would be like 4-8 bytes).
I think this is easily fixable (e.g. make it so a response MUST NOT 
include anything not already offered in the offer), but you would have to 
do that.



Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        [phone]
E-Mail:   [e-mail]
__________________________________________



Von:    "Harlan Stenn" <stenn=[e-mail]>
An:     [e-mail], "Salz, Rich" <[e-mail]>
Kopie:  "[e-mail]" 
<[e-mail]>, "NTP WG" <[e-mail]>
Datum:  15.08.2025 09:47
Betreff:        Re: [Ntp] Re: [IANA #1413181] NTP Extension Field 
additions, and IANA NTP table management process (ntp-parameters)



On 8/15/2025 2:41 AM, kristof.teichel=[e-mail] wrote:
> I will interject to remind that while I am arguing procedure (need for 
> clearer specification because IETF says so), I am also arguing some 
> substance:
> The documentation we do have suggests that parts of the intended 
> mechanism are incompatible with existing specification documents, and 
> also allows suspicion that parts of the intended mechanism might be 
> damaging to the whole ecosystem where it would be deployed (see my mail 
> from July 10th).

For each of the requested EF types for which I have requested 
allocation, please identify which EF type requests you think are OK, and 
which EF types have a specification that you believe has a problem.

Please specifically identify each place you think has a problem.

Thanks...

H

>  From what I understand, these are expressly the types of problems that 
> DEs should watch out for in this process.
> 
> 
> Besten Gruß / Kind regards,
> Kristof Teichel
> 
> __________________________________________
> 
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.:    [phone]
> E-Mail: [e-mail]
> __________________________________________
> 
> 
> 
> Von: "Salz, Rich" <rsalz=[e-mail]>
> An: "Harlan Stenn" <stenn=[e-mail]>, "iana-prot- 
> [e-mail]" <[e-mail]>
> Kopie: "NTP WG" <[e-mail]>
> Datum: 14.08.2025 15:40
> Betreff: [Ntp] Re: [IANA #1413181] NTP Extension Field additions, and 
> IANA NTP table management process (ntp-parameters)
> ------------------------------------------------------------------------
> 
> 
>   * The metaphor for what is happening now is that I am registering the
>   * owner of a plot of land.  The DEs are apparently asking for detailed
>   * building plans.
> 
> 
> It is not fair to ?blame? the DEs for this. RFC 9748, which updated the 
> NTP Registries requires a specification [1]. That document is an IETF 
> consensus document and they are just doing as directed.
> 
> [1] _https://www.rfc-editor.org/rfc/rfc9748.html#name-designated- 
> experts_ <https://www.rfc-editor.org/rfc/rfc9748.html#name-designated- 
> experts>_______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!