Subject: [Ntp] Garbage NTP request packets

From: Hal Murray <[email-masked]>
Date: Tue, 22 Sep 2020 22:34:13 -0700

I noticed that an error counter that was going off more than I expected, so I 
hacked a server to print out a few garbage requests.

Ones like this happen often enough to attract my attention.
  e3000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000
  00000020 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

The first 3 lines look like a version 4 request.  The last line starts to look 
like a MAC using key 20 (hex) but the HMAC/CMAC part is 28 bytes.  I haven't 
setup key 20 and our code doesn't support bare MACs with a total length of 32 
bytes.

I've seen them from various IP Addresses.

Has anybody tracked down this sort of garbage?

-- 
These are my opinions.  I hate spam.

---

From: Paul Gear <[email-masked]>
Date: Wed, 23 Sep 2020 15:41:23 +1000

>   e3000000 00000000 00000000 00000000

Hi Hal,

I haven't ever bothered tracking down their sources, but my pool servers
regularly see traffic with trailing MAC garbage, including unknown keys,
and what appear to be padding bytes.  I suspect network middle boxes
which do packet disassemble/reassemble, but I have no data to back this up.

I'm happy to grab you some packet captures for all the longer-than
expected packets if it helps you track this down.

Paul

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 23 Sep 2020 10:44:23 +0200

> hacked a server to print out a few garbage requests.

I think that's normal. On my public servers I see all kinds of weird
requests.

>   e3000000 00000000 00000000 00000000

This example looks like a valid NTPv4 request to me. It's not a MAC,
but an extension field (type 0, length 32 octets).

I have a script for monitoring pool.ntp.org servers that sends
requests like that (and others) to check various features of the
server like whether it can respond to an unknown extension field, what
implementation it is running, etc. FWIW, a server that doesn't respond
to a request that has an unknown extension field makes it more
difficult for clients to detect whether the extension field is
supported.

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Wed, 23 Sep 2020 15:35:29 -0400

Was there a working group question in here?

---

From: Daniel Franke <[email-masked]>
Date: Wed, 23 Sep 2020 15:48:36 -0400

Danny, I agree that Hal's question is slightly off-topic for this list
but I can't think of any better forum for it. The people who should
see it are all here; I don't they're all anywhere else. Is it worth
spinning up a new list for this sort of thing? Something like an
implementation-neutral forum for NTP developers and public server
operators?

On Wed, Sep 23, 2020 at 3:35 PM Danny Mayer <[email-masked]> wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Wed, 23 Sep 2020 14:15:24 -0700

> Was there a working group question in here?

Not a simple explicit one.  Would you be happier if I had added a wraper?  How 
about:

Are garbage packets interesting to the working group?  Should they be 
mentioned in the next BCP?

How frequent are they?  Can we divide them into categories?  Where are they 
coming from?  Who is sending them?  Why?  (bugs, research project, malicious 
intent...)

Are there any interesting security considerations?  Are bad guys sending 
broken packets to probe for bugs/weaknesses?

------------

Many years ago, I worked with a group of smart people.  One in particular was 
very good at a class of software details.  I would occasionally ask him 
questions like "How do I do X?" or "Why doesn't Y work the way I expect?".  
Often the answer would began with "This is the question you should have 
asked...", and then he would answer that one.

There is an art to asking good questions.

There is also an art to providing good answers, including answers to questions 
that haven't actually been asked yet.

I am perhaps less skilled at asking good questions because I've been fortunate 
to work with people who were good at answering them.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 23 Sep 2020 22:17:41 -0400

Isn't there a rechartering where we get to define the scope due? I may
have promised to write a draft charter, but know nothing about such
matters: will ask around at work.

Such a charter could, AFAIK, include operational issues: I know there
is a dnsops WG.  Whether or not that's desirable or effective is
another question, and I'm not aware of other fora for NTP operational
questions to be discussed. It's certainly something that has to be
considered in future standardization.

-- 
Astra mortemque praestare gradatim

---

From: Erik Kline <[email-masked]>
Date: Wed, 23 Sep 2020 21:34:05 -0700

We do need to recharter the group if it's going to work on NTPv5 ("The goal
of this working group is to document NTPv4..." :-).  We could float the
idea of including operational "care and feeding" of all NTP versions in the
to-be-proposed scope of work.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 24 Sep 2020 13:28:33 -0400

On 9/24/20 12:34 AM, Erik Kline wrote:
> We do need to recharter the group if it's going to work on NTPv5 ("The
> goal of this working group is to document NTPv4..." :-).  We could
> float the idea of including operational "care and feeding" of all NTP
> versions in the to-be-proposed scope of work.
>
I'd welcome adding that to the todo list for the WG. At least as a
discussion.

Danny