[ntpwg] Section 7.5. NTP Extension Field Format

[David L. Mills]

Danny,

Please note there is no Extension Type field. What there is is a Class 
field intended to multiplex among possibly many applications that might 
use the extension field. The Class field must be public for the same 
reason the TCP/UDP destination port must be public and it is used in 
much the same way. I don't like the particular field position in the 
word, but to change that kills Autokey in its present form.

Dave

Danny Mayer wrote:

> I strongly object to this change. The extension-private data belongs 
> inside the extension and placing them in the extension type field 
> makes it more difficult to deploy additional extensions.
>
> Danny
>
> David L. Mills wrote:
>
>> Guys,
>>
>> Following is a suggested replacement for Section 7.5. This preserves 
>> compatibility with symmetric key cryptography and Autokey, but allows 
>> up to 15 additional allications to use extenstion fields. As now, 
>> when a MAC is present it can be verified without knowledge of the 
>> extension field application and unknown applications are ignored.
>>
>> 7.5.  NTP Extension Field Format
>>
>> In NTPv4 one or more extension fields can be inserted after the 
>> header and before the MAC.  Other than defining the field format, 
>> this document makes no use of the field contents.  An extension field 
>> has the format shown in Figure 14.
>>
>>        0                   1                   2                   3
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |      xxx      | Class |  xxx  |            Length             |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       .                                                               .
>>       .                            Value                              .
>>       .                                                               .
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |                       Padding (as needed)                     |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                      Figure 14: Extension Field Format
>>
>> All extension fields are zero-padded to a word (4 octets) boundary. 
>> The 4-bit Class field defines the application using the extension 
>> field; the fields marked xxx are available to and defined by the 
>> application. Currently, only the Autokey class is defined with value 
>> zero.
>>
>> The Length field is a 16-bit unsigned integer which indicates the 
>> length of the entire extension field in octets, including the Padding 
>> field. In order to correctly parse packets with and without extension 
>> fields and with and without MACs, the minimum extension field length 
>> when a MAC is present is 2 words. If a MAC is not present, the 
>> minimum field length is 7 words. A maximum field length remains to be 
>> established.
>>
>> When a MAC is present, it is validated before the extension fields 
>> are processed. If a MAC is not present, or if a MAC is present and 
>> valid, the extension fields are processed in order; however, if a 
>> particular class code is not understood, the extension field is 
>> discarded.
>>
>> Dave
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>
>