Re: [ntpwg] New Version Notification for draft-ietf-ntp-network-time-security-12.txt and draft-ietf-ntp-using-nts-for-ntp-03.txt

[Danny Mayer <[e-mail]>]

On 12/22/2015 8:33 PM, Harlan Stenn wrote:
> [e-mail] writes:
>> You can see it in the draft "draft-ietf-ntp-using-nts-for-ntp-03". There 
>> it is mentioned e.g. in sect. 6.1.3.2. The idea is that NTS for NTP 
>> defines one additional extension field (see section IANA registration) and 
>> that all NTS-messages are using this extension field. The different NTS 
>> message types are distinguished by their respective OID (see the next 
>> version of the draft "draft-ietf-ntp-cms-for-nts-message"). This also is 
>> true for the MAC. Kristof please correct me if I'm wrong. The field type 
>> of the NTS extension field is not registered yet. This has to be done as 
>> soon as possible. This was also discussed with the NTF.
>>
>> Dieter
> 
> I gather we want an extension field for NTS and we want an extension
> field for the message authenticator.
> 
> DLM says the original expectation and plan was for mulitple extension
> fields to be allowed, and that the MAC, if present, would always be the
> last thing in the packet.
> 
> If a new extension field was added to the packet that process should
> remove any previous MAC field and add a new one to the end of the packet.
> 

That would be necessary if there is only the MAC at the end of the
packet because you cannot have two or more of them. However if the MAC
is an extension field itself there can be as many as necessary.

> I'm curious if there is new information available that would show good
> reason why we should reconsider this.

Yes. The MAC field in the packet has reached the end of it's useful
life. It is inflexible, the algorithm to be used cannot be specified,
and we are currently guessing whether or not it is present and how long
it is.

Danny

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg