UDP/123 policers & status

Harlan Stenn stenn at nwtime.org
Sun Mar 29 00:40:35 UTC 2020


I think I see the disconnect.

One of the design goals of NTS was to prevent NTS-protected time
requests from being used in amplification attacks.  Yes, that's true.

I've been interpreting this thread as people claiming that NTS will
solve a wider class of amplification vectors, and that's simply not true.

"Universal affirmatives can only be partially converted: all of Alma
Cogen is dead, but only some of the class of dead people are Alma Cogen."

It's also true, and generally not stated, that to the extent that
NTS-protected packets are exchanged, they will require increased network
capacity.  A cynic could argue that requiring additional internet
bandwidth is a profitable goal, and the drama about requiring that extra
protection is the distraction that normalizes that cost.

H

On 3/28/2020 5:18 PM, Harlan Stenn 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.
> 
>> 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.
> 
> But again, the use of mode 6/7 is completely independent of NTS.  You
> are trying to tie them together.
> 
> 
>>> 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.
> 
>> Ragnar
> 

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



More information about the NANOG mailing list