Subject: [ntpwg] Packing and padding extension fields

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 9 May 2016 13:43:58 +0200

I was wondering what would be the best way to allow short extension
fields in NTP packets without breaking compatibility with old NTP
implementations. I think there may be a relatively clean solution. I'd
like to propose two special extension fields, which could be specified
in RFC 7822 and which could be used with future extension fields.

The first special extension field is a packing extension field. It
would contain one or more other extension fields, one after another,
including their headers. Its length would be the sum of lengths of the
contained fields plus 4 and it would always be least 28 octets long.

This would allow specification of extension fields that are shorter
than 16 octets, down to 4 octets. They would just always have to be
included in the packing extension field. Extension fields between 16
and 28 octets wouldn't have to be paired with a longer extension field
in order to satisfy the requirement on minimum length when the packet
doesn't have a legacy MAC.

Old servers that don't understand this field and require fields to be
at least 16 or 28 octets long would see an unknown valid extension
field and still be able to reply. The clients would know the packets
are not getting lost.

It's cheap. Only 4 extra octets are needed in the NTP packet for the
header of the packing extension field.

If it was restricted to packets without legacy MAC and no other
top-level extension fields, the length of the packing extension field
would be equal to the length of the optional part of the packet. This
could be specified as a new recommended format for NTPv4 packets. It
would allow parsers to determine and check the length of the NTP
packet in constant time, no need to iterate over multiple extension
fields and/or check if there is a MAC. I'm not sure how useful that
would really be.

The second proposed extension field is a padding extension field. It
would not contain any useful data. It would just fill the empty space
in the packing extension field up to 28 octets if the included fields
were shorter, or it could be used to make the lengths of the request
and reply symmetric in order to make the NTP measurements more
accurate. Some time ago I proposed to allow padding in the NTS
time_request and time_reply fields, but now I think the padding
extension field would be a cleaner approach. It could be used with any
extension fields, not just NTS.

Does this make sense? Do you think it would be a useful addition to
RFC 7822?

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg