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

Hi!

Reading RFC 7822 one could get the impression that a "crypto NAK" is a MAC:
"   If a MAC is used, it resides at the end of the packet.  This field
   can be either 24 octets long, 20 octets long, or a 4-octet
   crypto-NAK."

Also:
" However, a MAC
   is not mandatory after an extension field; an NTPv4 packet can
   include one or more extension fields without including a MAC."

And
"      In NTPv4, one or more extension fields can be inserted after the
      header and before the MAC, which is always present when an
      extension field is present."

Now what? MAC optional or not?

"      In NTPv4, one or more extension fields can be inserted after the
      header and before the MAC, if a MAC is present."

So no extension fields without a MAC?

Later on:
"      In NTPv4, one or more extension fields can be inserted after the
      header and before the MAC, if a MAC is present."

But if there may be an extension field only when a MAC is present, what's the sense of all this?

Even more confusing:
"      A MAC MUST NOT be longer than 24 octets if there is no extension
      field present, unless a longer MAC is agreed upon by both client
      and server."

And I wish the rules in 7.5.1.4. were explained.

An abstract parsing algorithm would help to understand.

Kind regards,
Ulrich

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of Salz, Rich
Sent: Wednesday, December 6, 2023 4:00 PM
To: Hal Murray <halmurray@sonic.net>
Cc: ntp@ietf.org
Subject: [EXT] Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt

> NTPv4 packets may contain a MAC (Message Authentication Code) that appears 
> where you would expect an extension but it does NOT have the type/length 
> header of an extension. RFC 7822 has the details of how MACs can coexist with 
> extensions.

There is already some wording there in section 2.2:

> [RFC7822] clarified the processing rules for Extension Field Types, particularly around
> the interaction with the Message Authentication Code (MAC) field.

Which I updated to merge in your text:

> {{RFC7822}} clarified the processing rules for Extension Field Types,
> particularly around the interaction with the Message Authentication Code
> (MAC) field.  NTPv4 packets may contain a MAC, but it appears where one would
> expect an extension even though it does not have the type/length header of an
> extension.

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp