Re: [Ntp] WG Call for Adoption: draft-stenn-ntp-extension-fields

[Miroslav Lichvar <[e-mail]>]

On Thu, Sep 27, 2018 at 01:36:17AM -0700, Hal Murray wrote:
> > An NTPv4.1 packet would have the following format:
> > - 48-octet NTPv4 header
> > - 2-octet magic number (the packing EF type)
> > - 2-octet length of all data following the NTP header (the packing EF
> >   length)
> > - >24 octets of one or more EFs with no restrictions on minimal length
> 
> A possible alternative would be an EF that said no bare MAC.
>   2 byte magic number
>   2 byte length

The length of the EF would be 4 octets? That would prevent the
ambiguity in parsing (assuming the minimum length of the packet is
still 76 octets), but it wouldn't be compatible with RFC 7822, which
says the minimum length of an EF is 16 octets. Implementations that
follow it would drop such a packet for having an invalid format.

> Is this whole problem a wild goose chase?  If two systems are using MACs, they 
> have exchanged keys.  Could they also exchange a no-bare-MAC flag using the 
> same mechanism?
> 
> Why can't a system simply declare that it doesn't support bare MACs?  If so, 
> why would anybody ever send it one?

A server and client can certainly do that, but all other devices or
programs that may be processing packets between would have to follow
that and keep some state.

A switch looking for the Correction EF will not be keeping any state
for NTP and it must be sure it's really the EF and not just a random
MAC before it modifies the packet.

It would be nice if tcpdump/wireshark could reliably parse NTP packets
and display individual EFs.

-- 
Miroslav Lichvar