NTPv4 Autokey protocol: pcap does not meet the standard

NTP
retag add tags

In RFC 5906: Section 10 standard it is written:

In Autokey the 8-bit Field Type field is interpreted as the version number, currently 2.

REM: Look at Figure 7 above.

But in fact, the version is not specified in the "Field Type" (second byte), it is parsed by Wireshark on "Flags" field (last 6 bits of first byte). By default, the "Opcode" should be in the first byte, the "Version" should be in the second byte. In fact, the opposite is true.

Is this a bug of Wireshark or ntpd or should I believe the implementation?

Link to pcap: https://yadi.sk/d/hahMZm2xYJPhoQ

REM: Look at "Extensional" fields in client's requests .

oup_job

asked 2020-09-09 15:09:34 +0000, updated 2020-09-09 15:15:12 +0000

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

Your capture doesn't seem to comply with the RFC, that field type value (0x0201) isn't on the IANA list.

The NTP dissector doesn't currently perform any dissection of Extension fields other than that specified in RFC 5905, i.e. Type (as a uint16), Length and the Value.

Edit: My tests were performed with the development version that doesn't have support for Autokey post the merge of change 38037.

23.8k

grahamb

answered 2020-09-09 15:42:46 +0000, updated 2020-09-10 08:28:32 +0000

edit flag offensive 0 remove flag delete link

Comments

"The NTP dissector doesn't currently perform any dissection of Extension fields"

This isn't true, at least not prior to https://code.wireshark.org/review/git...

I don't know why Autokey was removed instead of fixed. So this looks like a Wireshark bug to me, and thus a bug report should be filed to not only add AutoKey dissection back but to also fix it.

See also: Bug 16640.

cmaynard (2020-09-09 16:23:36 +0000) edit

"The NTP dissector doesn't currently perform any dissection of Extension fields" This isn't true, at least not prior to https://code.wireshark.org/review/git...

Lol, I forgot to add "at the time of writing".

grahamb (2020-09-09 16:39:21 +0000) edit

It is currently supported as of this writing in the stable releases, albeit with bugs.

cmaynard (2020-09-09 16:45:33 +0000) edit

Another file in which the "Field type" matches IANA list: https://yadi.sk/d/jSN7nyK7O-2eqA.

The problem is the same. Why "Version" is in the first byte?

oup_job (2020-09-10 08:08:17 +0000) edit

As noted by @cmaynard, there is a bug in the dissector in the stable versions, and the Extension Field dissection was actually removed. The version I was testing your capture with (a locally built copy of the development version) doesn't have the buggy Autokey dissection.

See Issue 16640 for discussion of the removal and Issue 16222 for discussion on the Autokey replacement.

Although 16440 notes that Autokey will be replaced with NTS, there will still be Autokey implementations out in the wild and thus Wireshark should support that. Again as noted by @cmaynard, raise an Issue to request Autokey support (or better still submit a Merge Request).

grahamb (2020-09-10 08:25:38 +0000) edit

add a comment see more comments

NTPv4 Autokey protocol: pcap does not meet the standard

Comments

1 Answer

Comments

Your Answer

NTPv4 Autokey protocol: pcap does not meet the standard edit

Comments

1 Answer

Comments

Your Answer

NTPv4 Autokey protocol: pcap does not meet the standard