nanog mailing list archives

Re: UDP/123 policers & status


From: Ragnar Sundblad <ragge () kth se>
Date: Sun, 29 Mar 2020 01:35:13 +0100



On 29 Mar 2020, at 01:18, Harlan Stenn <stenn () nwtime org> wrote:

Ragnar,

On 3/28/2020 4:59 PM, Ragnar Sundblad wrote:


On 29 Mar 2020, at 00:35, Harlan Stenn <stenn () nwtime org> wrote:

Ragnar,

On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:

On 28 Mar 2020, at 23:58, Harlan Stenn <stenn () nwtime org> wrote:

Steven Sommars said:
The secure time transfer of NTS was designed to avoid
 amplification attacks.

Uh, no.

Yes, it was.

As Steven said, “The secure time transfer of NTS was designed to
avoid amplification attacks”. I would even say - to make it
impossible to use for amplification attacks.

Please tell me how.  I've been part of this specific topic since the
original NTS spec.  For what y'all are saying to be true, there are some
underlying assumptions that would need to be in place, and they are
clearly not in place now and won't be until people update their
software, and even better, tweak their configs.

The NTS protected NTP request is always of the same size, or in some
cases larger, than the NTS protected NTP response. It is carefully
designed to work that way.

So what?

The use of NTS is completely independent of whether or not a server will
respond to a packet.

And an unauthenticated NTP request that generates an unauthenticated
response is *always* smaller than an authenticated request, regardless
of whether or not the server responds.

Claiming that amplification is a significant issue in the case where
there's no amplification but the base packet size is bigger is ignoring
a key piece of information, and is disingenuous in my book.

You are now comparing unauthenticated mode 3 and mode 4 packets to
cryptographically secured ones, which is a completely different thing.

Disingenuous?

A protocol with varying packet size, as the NTS protected NTP is,
can easily have the bad property of having responses larger than the
requests if not taken care. Don’t you see that?

Hence, [what Steven said].

If you understand what's going on from the perspective of both the
client and the server and think about the various cases, I think you'll
see what I mean.

Hopefully, no-one exposes mode 6 or mode 7 on the internet anymore
at least not unauthenticated, and at least not the commands that are
not safe from amplification attacks. Those just can not be allowed
to be used anonymously.

But mode 6/7 is completely independent of NTS.

Exactly. No one needs to, or should, expose mode6/7 at all. They were
designed at a time when the internet was thought to be nice place were
people behaved, decades ago, today they are just huge pains in the
rear. Sadly allowing anonymous mode 6/7 was left in there far to long
(admittedly being wise in hindsight is so much easier than in advance).
And here we are, with UDP port 123 still being abused by the bad
guys, and still being filtered by the networks.

Your statement about "exposing" is imprecise and bordering on incorrect,
at least in some cases.

Exposing to the Internet, or anyone but the system owner.

I just can’t imagine that you didn’t fully understand that.

But again, the use of mode 6/7 is completely independent of NTS.  You
are trying to tie them together.

I am certainly not, and I think that should be perfectly clear from
the above.

Mode 6/7 packets should generally never be exposed outside localhost,
and should probably be replaced by something entirely different.

They are just a extremely troublesome relics from a time long ago,
and they should have been removed from anonymous exposure on the
Internet twenty years ago at least.

Don’t you understand that?
If you don't, you are part of the problem of killing UDP port 123,
not part of the solution for saving it.

It's disingenuous for people to imply otherwise.

I couldn’t say, I don’t even know of an example of someone who does.

You've done it in two cases here, from everything I have seen.

I have not. End of story.

Ragnar


Current thread: