UDP/123 policers & status

Sun Mar 29 01:25:08 UTC 2020

Hi Harlan,

I am quite sure that we actually generally agree and are just talking
past each other, and so are you judging from your mail below.

Let’s move this discussion from the list.

Regards,

Ragnar

> On 29 Mar 2020, at 03:06, Harlan Stenn <stenn at nwtime.org> wrote:
> 
> 
> 
> 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!