Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt

[James Browning <[e-mail]>]

On Sat, Dec 2, 2023 at 12:40 PM Danny Mayer <[e-mail]> wrote:
>
>
> On 11/26/23 9:52 PM, Hal Murray wrote:
> > Could you please save/reserve extensiion Field Type 0x0000?
> Yes. This is actually a crypto-NAK as defined in RFC 5905 Section 9.2
> though it's not called an extension field there.
> >
> > I don't have a good writeup.  The idea is tangled up with 7822.  The problem
> > is how to distinguish an extension from a MAC.
> That was the problem I was grappling with in that RFC. As the author of
> that section you can blame me it it's a bit mangled!
> >
> > Shared key MACs have a 4 byte key number and 16 or 20 bytes of MAC.  The key
> > number space was shared by autokey and manual assignments.  The manual mode
> > was restricted to the lower 65K.  So sites that are not using autokey don't
> > need the at least 28 byte length restriction from RFC 7822 for the last
> > extension.  If the type field is 0, the rest is a MAC rather than an extension.
>
> I did come up with an idea about handling a variable length MAC since
> the RFC was published though there may be some corner cases that would
> not be handled correctly. The problem is not having a length field to
> state how long it is supposed to be. The existing MAC should be replaced
> by an extension field MAC in a NTP v5 implementation so we have a length
> field we can depend on.

I suppose it's too much trouble to implement extension 0 as a
special case that ignores length and takes the entire remainder
of the packet as a MAC. IIRC, the only extension that should
have an issue with it is 0x2005 Checksum Complement, whose use
case is incompatible with MACs. But only for NTPv4, I agree MACs
should be in an extension. IIRC, Stenn had a draft or two
posted with that general intent.