Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1

[Harlan Stenn <[e-mail]>]

On 9/21/17 11:02 PM, Ulrich Windl wrote:
>>>> Harlan Stenn <[e-mail]> schrieb am 21.09.2017 um 00:42 in Nachricht
> <[e-mail]>:
> 
>>
>> On 9/20/17 12:10 PM, Brian Haberman wrote:
>>>
>>>
>>> On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>>>>> Brian Haberman <[e-mail]> schrieb am 18.09.2017 um 19:10 in
>>>> Nachricht <[e-mail]>:
>>>>> Ulrich noted that this document does not specify a version number for
>>>>> the mode 6 commands. I had suggested specifying it as "version 4 (or
>>>>> earlier)" given that the introduction of mode 6 commands has occurred at
>>>>> various versions of the protocol starting at RFC 1305. Ulrich pointed
>>>>> out that the version number drives the interpretation of the status words.
>>>>>
>>>>> For people who have implemented or use mode 6 commands, what makes sense
>>>>> here? Do we need to specify a version number per mode 6 command?
>>>>
>>>> Hi!
>>>>
>>>> I think there are several issues:
>>>>
>>>> 1) Assuming there are different versions (there are!), how can one find out 
>> which version the server implements? See 2)
>>>>
>>>> 2) if a client requests a version different from the server, what should the 
>> server do? The server could respond with a different version number, 
>> indicating that it is not willing to respond / privide the information in the 
>> format requested. Or the server could respond with a "bad request" status. 
>> Finally the server could respond in the format requested... I have slight 
>> favor for the first variant unless there is a command to find out what 
>> message format versions the server can provide.
>>>>
>>>> 3) As it seems to be now, the server ignores the version (versions 2, 3, and 
>> 4 all seem to work)
>>>>
>>>
>>> The above seems to argue for two things:
>>>
>>> 1) A preliminary handshake between an NTP server and the mode6-speaking
>>> client to determine what version is in use.
>>>
>>> 2) A change to the operating basis of the mode 6 commands in that the
>>> above mentioned handshake occurs before actually sending the mode 6 command.
>>>
>>> Is that a good representation of what is being asked for?
>>
>> If it is, I'm thinking we'd want a mode 6 "Identify" command, that would
>> have this information in a response.  This response would likely contain
>> different data before/after authentication.
> 
> Why that? You should elaborate on the role of authentication.

Here's a short list.

- Nobody but trusted folks should see the origin timestamp of a pending
  symmetric mode exchange.

- Nobody but trusted folks should be able to get the list of our
  potential servers.

- Nobody but VERY trusted folks should be able to issue :config
  directives

>> I'd also much rather we had changes to do this that are tested and known
>> to do what we want instead of codifying what folks hope will be a good
>> solution.
>>
>> I'm happy to work with collaborative folks, experienced or not, who want
>> to dig in to this.

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