UDP/123 policers & status

[stenn at nwtime.org (Harlan Stenn)]

On 3/28/2020 5:35 PM, Ragnar Sundblad wrote:
> 
> 
>> On 29 Mar 2020, at 01:18, Harlan Stenn <stenn at nwtime.org> wrote:
>>
>> Ragnar,
>>
>> On 3/28/2020 4:59 PM, Ragnar Sundblad wrote:
>>>
>>>
>>>> On 29 Mar 2020, at 00:35, Harlan Stenn <stenn at nwtime.org> wrote:
>>>>
>>>> Ragnar,
>>>>
>>>> On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
>>>>>
>>>>>> On 28 Mar 2020, at 23:58, Harlan Stenn <stenn at 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?

I made no such claim.

I was talking about:

>>>>> 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.

and that statement is not as clear as it could be.  Specifically:

 NTS was designed to avoid amplification attacks

is vague.

You have just now written:

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

Completely different?  How?

Where is the amplification in an unauthenticated mode 3 request and an
unauthenticated response?

How does cryptographically securing these packets make any difference here?

> 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?

I sure think I understand these points.

Who here has said that there was any problem with there being an
amplification issue with properly-authenticated NTS packets?

The current NTS spec is *only* written for mode 3/4 exchanges.  While it
might be applicable for mode 6/7, I haven't seen any specs for this
usage.  In the NTP Project's Reference implementation there are extra
implementation-specific protections built in to mode 6/7 exchanges.
While some of this might be addressed in the NTS spec, I don't recall
ever seeing this.

So why are you talking about mode 6/7 in this context?

>>> 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 think you're in the right ballpark, but the edges of your boundaries
are a bit off.

> I just canâ??t imagine that you didnâ??t fully understand that.

I think I have a pretty wide and deep understanding of these issues.

If I'm correct, then perhaps we are simply communicating imprecisely.

If I'm missing something, I'd like to know what it is.

>> 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.

I took my lead from the exchanges above.

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

My initial inclination is to disagree with you first clause.  Then I
noticed you used the word "generally" and perhaps we agree and have
different ways of expressing ourselves.

As for your second clause, yes, that might be a good solution.  But
there's still a staggering number of v3 systems out there.

Simply creating a new mechanism and believing it will fix the problem
seems naive to me.  But I also think incremental and appropriate use of
BCP 38, especially at the connection with the customer, is a good and
workable idea.  I say this arrogantly, as I'm not in the business of
providing network access to entities.

> 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.

I think we're talking past each other.

>>>> 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

I think we're talking past each other.

-- 
Harlan Stenn <stenn at nwtime.org>
http://networktimefoundation.org - be a member!