Re: UDP/123 policers & status

[Harlan Stenn]

On 4/17/2020 2:01 AM, Ragnar Sundblad wrote:
> 
> I thought we were talking about control traffic.

I expect there will be a TCP control traffic option.

I expect there will continue to be a UDP control traffic option.

These are "mechanisms", there will be a reasonable default policy (that
will change and evolve over time), and there will be a mechanism to
allow the local admins to implement their local policy choices.

> If you want to do some NTP time comparison mode with larger responses
> than requests, I agree that TCP is likely not a good option.

I still don't see why, in the general case, some here think we must
force a smaller request packet to be padded just so a possibly larger
response packet will provide no amplification.

Basic packets are of a known and identical size.  Before the 7822
braindamage (my opinion of 7822), EFs *required* MACs.  Post 7822 they
don't, but even so, if people implement EFs and don't include (disable?)
"protection" they've pretty much made their choice.  But we're speaking
in generalities here.

What new or proposed packet content would trigger a larger response that
would not require an authenticated request in the first place?

And I just realized this is the NANOG list and not the NTP list, so I'm
happy to stop.

H
--
> Ragnar
> 
>> On 17 Apr 2020, at 10:44, Harlan Stenn  wrote:
>>
>> NTP uses UDP for time.
>>
>> I'm not sure what you're talking about.
>>
>> H
>>
>> On 4/17/20 1:32 AM, Ragnar Sundblad wrote:
>>>
>>>
 On 17 Apr 2020, at 01:28, Harlan Stenn  wrote:

 I found this as an unsent draft - I hope I didn't send it before.

 On 3/30/2020 2:01 AM, Ragnar Sundblad wrote:
>
>
>> On 30 Mar 2020, at 08:18, Saku Ytti  wrote:
>>
>> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:
>>
>>> 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?
>>
>> Why? Why not pad requests to guarantee attenuation vector until
>> authenticity of packets can be verified?
>
> Right, and NTS does that.

 There is more to NTP than NTS.

 Are y'all seriously recommending that NTP always sends a max-sized
 packet as a client request so the client/server can send back an
 identical response?  That's just wasting huge amounts of bandwidth to
 save the possibility of a possibly larger response.
>>>
>>> If there is no sender verification, yes. It doesn’t have to be larger
>>> than the maximum response size.
>>>
>>> Another option is to use TCP - the handshake solves the problem.
>>>
 And just becase a responbse may be larger, that doesn't necessarily
 translate into an amplification vector.
>>>
>>> If there is no sender verification, it generally does.
>>> In what case does it not?
>>>
 The alternative seems to be that the client sends a smaller request and
 is ready when the response from the server is "Send your request again,
 but this time pad it to NNN bytes so I can respond with the same sized
 packet"?
>>>
>>> Sure, that is one way!
>>> Or - Here are the first N entries, send another request for the
>>> next batch, optionally: there are M entries in total.
>>> Or - TCP.
>>> There likely are many other options.
>>>
>>> Ragnar
>>>
>>>
>>
>> -- 
>> Harlan Stenn 
>> http://networktimefoundation.org - be a member!
> 
> 

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Ragnar Sundblad]

I thought we were talking about control traffic.

If you want to do some NTP time comparison mode with larger responses
than requests, I agree that TCP is likely not a good option.

Ragnar

> On 17 Apr 2020, at 10:44, Harlan Stenn  wrote:
> 
> NTP uses UDP for time.
> 
> I'm not sure what you're talking about.
> 
> H
> 
> On 4/17/20 1:32 AM, Ragnar Sundblad wrote:
>> 
>> 
>>> On 17 Apr 2020, at 01:28, Harlan Stenn  wrote:
>>> 
>>> I found this as an unsent draft - I hope I didn't send it before.
>>> 
>>> On 3/30/2020 2:01 AM, Ragnar Sundblad wrote:
 
 
> On 30 Mar 2020, at 08:18, Saku Ytti  wrote:
> 
> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:
> 
>> 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?
> 
> Why? Why not pad requests to guarantee attenuation vector until
> authenticity of packets can be verified?
 
 Right, and NTS does that.
>>> 
>>> There is more to NTP than NTS.
>>> 
>>> Are y'all seriously recommending that NTP always sends a max-sized
>>> packet as a client request so the client/server can send back an
>>> identical response?  That's just wasting huge amounts of bandwidth to
>>> save the possibility of a possibly larger response.
>> 
>> If there is no sender verification, yes. It doesn’t have to be larger
>> than the maximum response size.
>> 
>> Another option is to use TCP - the handshake solves the problem.
>> 
>>> And just becase a responbse may be larger, that doesn't necessarily
>>> translate into an amplification vector.
>> 
>> If there is no sender verification, it generally does.
>> In what case does it not?
>> 
>>> The alternative seems to be that the client sends a smaller request and
>>> is ready when the response from the server is "Send your request again,
>>> but this time pad it to NNN bytes so I can respond with the same sized
>>> packet"?
>> 
>> Sure, that is one way!
>> Or - Here are the first N entries, send another request for the
>> next batch, optionally: there are M entries in total.
>> Or - TCP.
>> There likely are many other options.
>> 
>> Ragnar
>> 
>> 
> 
> -- 
> Harlan Stenn 
> http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Harlan Stenn]

NTP uses UDP for time.

I'm not sure what you're talking about.

H

On 4/17/20 1:32 AM, Ragnar Sundblad wrote:
> 
> 
>> On 17 Apr 2020, at 01:28, Harlan Stenn  wrote:
>>
>> I found this as an unsent draft - I hope I didn't send it before.
>>
>> On 3/30/2020 2:01 AM, Ragnar Sundblad wrote:
>>>
>>>
 On 30 Mar 2020, at 08:18, Saku Ytti  wrote:

 On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:

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

 Why? Why not pad requests to guarantee attenuation vector until
 authenticity of packets can be verified?
>>>
>>> Right, and NTS does that.
>>
>> There is more to NTP than NTS.
>>
>> Are y'all seriously recommending that NTP always sends a max-sized
>> packet as a client request so the client/server can send back an
>> identical response?  That's just wasting huge amounts of bandwidth to
>> save the possibility of a possibly larger response.
> 
> If there is no sender verification, yes. It doesn’t have to be larger
> than the maximum response size.
> 
> Another option is to use TCP - the handshake solves the problem.
> 
>> And just becase a responbse may be larger, that doesn't necessarily
>> translate into an amplification vector.
> 
> If there is no sender verification, it generally does.
> In what case does it not?
> 
>> The alternative seems to be that the client sends a smaller request and
>> is ready when the response from the server is "Send your request again,
>> but this time pad it to NNN bytes so I can respond with the same sized
>> packet"?
> 
> Sure, that is one way!
> Or - Here are the first N entries, send another request for the
> next batch, optionally: there are M entries in total.
> Or - TCP.
> There likely are many other options.
> 
> Ragnar
> 
> 

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Ragnar Sundblad]

> On 17 Apr 2020, at 01:28, Harlan Stenn  wrote:
> 
> I found this as an unsent draft - I hope I didn't send it before.
> 
> On 3/30/2020 2:01 AM, Ragnar Sundblad wrote:
>> 
>> 
>>> On 30 Mar 2020, at 08:18, Saku Ytti  wrote:
>>> 
>>> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:
>>> 
 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?
>>> 
>>> Why? Why not pad requests to guarantee attenuation vector until
>>> authenticity of packets can be verified?
>> 
>> Right, and NTS does that.
> 
> There is more to NTP than NTS.
> 
> Are y'all seriously recommending that NTP always sends a max-sized
> packet as a client request so the client/server can send back an
> identical response?  That's just wasting huge amounts of bandwidth to
> save the possibility of a possibly larger response.

If there is no sender verification, yes. It doesn’t have to be larger
than the maximum response size.

Another option is to use TCP - the handshake solves the problem.

> And just becase a responbse may be larger, that doesn't necessarily
> translate into an amplification vector.

If there is no sender verification, it generally does.
In what case does it not?

> The alternative seems to be that the client sends a smaller request and
> is ready when the response from the server is "Send your request again,
> but this time pad it to NNN bytes so I can respond with the same sized
> packet"?

Sure, that is one way!
Or - Here are the first N entries, send another request for the
next batch, optionally: there are M entries in total.
Or - TCP.
There likely are many other options.

Ragnar

Re: UDP/123 policers & status

[Harlan Stenn]

I found this as an unsent draft - I hope I didn't send it before.

On 3/30/2020 2:01 AM, Ragnar Sundblad wrote:
> 
> 
>> On 30 Mar 2020, at 08:18, Saku Ytti  wrote:
>>
>> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:
>>
>>> 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?
>>
>> Why? Why not pad requests to guarantee attenuation vector until
>> authenticity of packets can be verified?
> 
> Right, and NTS does that.

There is more to NTP than NTS.

Are y'all seriously recommending that NTP always sends a max-sized
packet as a client request so the client/server can send back an
identical response?  That's just wasting huge amounts of bandwidth to
save the possibility of a possibly larger response.

And just becase a responbse may be larger, that doesn't necessarily
translate into an amplification vector.

The alternative seems to be that the client sends a smaller request and
is ready when the response from the server is "Send your request again,
but this time pad it to NNN bytes so I can respond with the same sized
packet"?

> Ragnar

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Ragnar Sundblad]

> On 30 Mar 2020, at 11:08, Harlan Stenn  wrote:
...
> Are y'all seriously recommending that NTP always sends a max-sized
> packet as a client request so the client/server can send back an
> identical response?

The request only has to be larger than or equal size of the response,
they don’t both have to be max size.

If the response can be max size, then the easiest way is that the
request is too.

Ragnar

Re: UDP/123 policers & status

[Saku Ytti]

On Mon, 30 Mar 2020 at 12:08, Harlan Stenn  wrote:

> Are y'all seriously recommending that NTP always sends a max-sized
> packet as a client request so the client/server can send back an
> identical response?

I'm seriously recommending that, when the server cannot verify
authenticity of packet, force attenuation by protocol design. See
MinimaLT white paper, https://cr.yp.to/tcpip/minimalt-20131031.pdf

-
Given this, MinimaLT is designed to minimize amplification attacks, in
which a request is smaller than its reply (to a spoofed source
address).


-- 
  ++ytti

Re: UDP/123 policers & status

[Saku Ytti]

On Mon, 30 Mar 2020 at 11:56, Harlan Stenn  wrote:

> OK, and exactly how bad is a single byte attenuation, when compared
> against the cost of 100% of all of the 1-byte shorter NTP packets being
> made bigger to make the attenuation vector 0?

I can't parse that, sorry. I'm saying attenuation of 1B or more is
good, no attenuation or amplification is worse.

-- 
  ++ytti

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/30/2020 2:01 AM, Ragnar Sundblad wrote:
> 
> 
>> On 30 Mar 2020, at 08:18, Saku Ytti  wrote:
>>
>> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:
>>
>>> 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?
>>
>> Why? Why not pad requests to guarantee attenuation vector until
>> authenticity of packets can be verified?
> 
> Right, and NTS does that.

There is more to NTP than NTS.

Are y'all seriously recommending that NTP always sends a max-sized
packet as a client request so the client/server can send back an
identical response?

The alternative seems to be that the client sends a smaller request and
is ready when the response from the server is "Send your request again,
but this time pad it to NNN bytes so I can respond with the same sized
packet"?

> Ragnar

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Ragnar Sundblad]

> On 30 Mar 2020, at 08:18, Saku Ytti  wrote:
> 
> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:
> 
>> 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?
> 
> Why? Why not pad requests to guarantee attenuation vector until
> authenticity of packets can be verified?

Right, and NTS does that.

Ragnar

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/30/2020 1:27 AM, Saku Ytti wrote:
> On Mon, 30 Mar 2020 at 11:15, Harlan Stenn  wrote:
> 
>> Please help me understand this.
>>
>> Exactly how bad is it if the query and response packets are of a
>> different size?  Does it matter at 4 bytes?  32?
> 
> Presumably, if it's attenuation vector (1byte or more), presumably
> attacker will use any of the other many vectors which are
> amplification vectors or will directly attack from the zombie machines
> they pwn. Since NST would have negative ROI on attack if there is
> _any_ attenuation.

OK, and exactly how bad is a single byte attenuation, when compared
against the cost of 100% of all of the 1-byte shorter NTP packets being
made bigger to make the attenuation vector 0?

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Saku Ytti]

On Mon, 30 Mar 2020 at 11:15, Harlan Stenn  wrote:

> Please help me understand this.
>
> Exactly how bad is it if the query and response packets are of a
> different size?  Does it matter at 4 bytes?  32?

Presumably, if it's attenuation vector (1byte or more), presumably
attacker will use any of the other many vectors which are
amplification vectors or will directly attack from the zombie machines
they pwn. Since NST would have negative ROI on attack if there is
_any_ attenuation.

-- 
  ++ytti

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/29/2020 11:18 PM, Saku Ytti wrote:
> On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:
> 
>> 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?
> 
> Why? Why not pad requests to guarantee attenuation vector until
> authenticity of packets can be verified?
> 
> MinimaLT does this. I think all UDP based and initial TCP should do
> it, doing it for existing protocols may not be possible, but why not
> for new?
> 
> I proposed similar method for proxy-trace (bidir tracerouting) -
> https://github.com/ytti/proxy-trace/blob/master/draft-ytti-intarea-proxy-trace.xml#L169

Please help me understand this.

Exactly how bad is it if the query and response packets are of a
different size?  Does it matter at 4 bytes?  32?

what are the expected costs of different %s of response packets being
sent back?  I think this needs to be understood for a variety of
different sized query/response packets.

Then factor in the costs of padding the shorter packets.  Include the
cost of the actual bump in network bandwidth, which I suspect is
negligible, and at the same time we can do a reality check on the folks
who claim that NTP packets are a significant cause of the bufferbloat
problem.

Then we need to thoroughly study how the various size differences
between the client request and server response packets affect the
quality of time synchronization, in various network scenarios.  Some
have claimed this is clearly noticeable and significant.  I'd like to
see the experiments and the data.

NTF is very happy to do this work, incrementally if needed, if we can
get the necessary support and cooperation/collaboration.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Saku Ytti]

On Mon, 30 Mar 2020 at 01:58, Ragnar Sundblad  wrote:

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

Why? Why not pad requests to guarantee attenuation vector until
authenticity of packets can be verified?

MinimaLT does this. I think all UDP based and initial TCP should do
it, doing it for existing protocols may not be possible, but why not
for new?

I proposed similar method for proxy-trace (bidir tracerouting) -
https://github.com/ytti/proxy-trace/blob/master/draft-ytti-intarea-proxy-trace.xml#L169

-- 
  ++ytti

Re: UDP/123 policers & status

[Ragnar Sundblad]

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

Re: UDP/123 policers & status

[Ragnar Sundblad]

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

Re: UDP/123 policers & status

[Ragnar Sundblad]

> On 29 Mar 2020, at 00:35, Harlan Stenn  wrote:
> 
> Ragnar,
> 
> On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
>> 
>>> On 28 Mar 2020, at 23:58, Harlan Stenn  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.

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.

> It's disingenuous for people to imply otherwise.

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

Ragnar

Re: UDP/123 policers & status

[Ragnar Sundblad]

> On 28 Mar 2020, at 23:58, Harlan Stenn  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.

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

> NTS is a task-specific hammer.

Yes.

Ragnar

Re: UDP/123 policers & status

[Ragnar Sundblad]

> On 28 Mar 2020, at 23:29, Bottiger  wrote:
...
> Broken protocols need to be removed and blacklisted at every edge.

A protocol isn’t broken just because it can be abused when spoofed,
it is abused. Even TCP can be abused in that way.
Should we blacklist and remove TCP?

> Pushing the responsibility to BCP38 is unrealistic.

It would help quite a bit against a lot if abuse, and it would be
reasonable to include it on a lowest level of technical level to
actually get to be called an ISP.

So what do the ISP:s want - earn money while doing nothing until the
Internet is unusable? I don’t get it.
There are enough threats against the open Internet as it is, we
don’t need that too.

Ragnar

Re: UDP/123 policers & status

[Ragnar Sundblad]

> On 27 Mar 2020, at 18:54, Saku Ytti  wrote:
> 
> On Fri, 27 Mar 2020 at 19:48, Ragnar Sundblad  wrote:
> 
>> Is this really what the ISP community wants - to kill off port 123,
>> and force NTP to move to random ports?
> 
> Make NST attenuation vector, so that reply is guaranteed to be
> significantly smaller than request, and by standard drop small
> requests.

The NTP replies on port 123 are of the same size as the request, or
smaller on error.

If filtering on request/reply (or “mode” in NTP lingo), you could filter
out the control packets which have the amplification problems in very old
configurations.
You could allow request and reply, mode 3 and 4, but disallow control
packets, mode 6.
This kind of filtering may not be possible in all equipment though.

Another option is to rate limit the traffic, even though that is not
entirely without problems either - public servers are supposed to get
a lot more traffic than a typical client generates.

I know that ISP:s have been hunting down machine with other services
that could be used for e.g. amplification or spam, like SMTP relays,
DNS resolvers, HTTP proxies, and similar.
This would be fully possible also with these bad NTP configurations
that have not been updated in many many years.
I think only the ISP:s are in a position to both find out who they
are, and to force them to be fixed.

Ragnar

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/28/2020 5:35 PM, Ragnar Sundblad wrote:
> 
> 
>> On 29 Mar 2020, at 01:18, Harlan Stenn  wrote:
>>
>> Ragnar,
>>
>> On 3/28/2020 4:59 PM, Ragnar Sundblad wrote:
>>>
>>>
 On 29 Mar 2020, at 00:35, Harlan Stenn  wrote:

 Ragnar,

 On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
>
>> On 28 Mar 2020, at 23:58, Harlan Stenn  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 

Re: UDP/123 policers & status

[Harlan Stenn]

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  wrote:
>>>
>>> Ragnar,
>>>
>>> On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:

> On 28 Mar 2020, at 23:58, Harlan Stenn  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 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Harlan Stenn]

Ragnar,

On 3/28/2020 4:59 PM, Ragnar Sundblad wrote:
> 
> 
>> On 29 Mar 2020, at 00:35, Harlan Stenn  wrote:
>>
>> Ragnar,
>>
>> On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
>>>
 On 28 Mar 2020, at 23:58, Harlan Stenn  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 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Harlan Stenn]

Ragnar,

On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
> 
>> On 28 Mar 2020, at 23:58, Harlan Stenn  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.

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

It's disingenuous for people to imply otherwise.

>> NTS is a task-specific hammer.
> 
> Yes.
> 
> Ragnar

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/28/2020 3:29 PM, Bottiger wrote:
> but why isn't BCP 38 widely deployed?  
> 
> 
> Because it costs time and money. People have been asking for it to be
> implemented for decades. It is never going to be deployed on every network.

So you are claiming BCP 38 has to be all or nothing?  That there is *no*
benefit to incremental deployment?

> What fraction of the
> world does implement BCP 38?  
> 
> 
>  Not enough. Everyone has to use it for it to work. Otherwise the
> hackers will still find a network that doesn't have it.

I disagree.  Enough people have to use it for it to work.  And as more
folks use it, there is increasing motivation for more folks to use it.
As the number of deployments increases, one can assume (perhaps
correctly) that it will become less expensive to deploy, and that
additional measures will be found to help accomplish the same thing.

> I'd also be interested in general background info on DDoS.  Who is
> DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor? 
> Bad guys making a test run to see if the server can be used for a
> real run?  
> 
> 
> Most motivations for attacks can't be traced. But this is not just a
> gaming problem. It is used to extort businesses for money, destroy
> competitors, shutdown government critics, fame. 
> 
>  Is DDoS software widely available on the dark web?
> 
> 
> You don't need the dark web. It is widely available on Github like most
> other attack types.
> 
> https://github.com/search?q=ntp+ddos  
> 
> Broken protocols need to be removed and blacklisted at every edge.
> Pushing the responsibility to BCP38 is unrealistic.

The monlist attack was mitigated many years' ago.  The problem is that
too many folks don't upgrade their software.

> On Mon, Mar 23, 2020 at 7:43 AM Hal Murray
>  > wrote:
> 
> Steven Sommars said:
> > The secure time transfer of NTS was designed to avoid
> amplification attacks.

Uh, no.

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.

NTS is a task-specific hammer.

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Bottiger]

>
> but why isn't BCP 38 widely deployed?
>

Because it costs time and money. People have been asking for it to be
implemented for decades. It is never going to be deployed on every network.

What fraction of the
> world does implement BCP 38?
>

 Not enough. Everyone has to use it for it to work. Otherwise the hackers
will still find a network that doesn't have it.

I'd also be interested in general background info on DDoS.  Who is DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor?
> Bad guys making a test run to see if the server can be used for a real
> run?


Most motivations for attacks can't be traced. But this is not just a gaming
problem. It is used to extort businesses for money, destroy competitors,
shutdown government critics, fame.

 Is DDoS software widely available on the dark web?


You don't need the dark web. It is widely available on Github like most
other attack types.

https://github.com/search?q=ntp+ddos

Broken protocols need to be removed and blacklisted at every edge. Pushing
the responsibility to BCP38 is unrealistic.


On Mon, Mar 23, 2020 at 7:43 AM Hal Murray <
hgm+na...@ip-64-139-1-69.sjc.megapath.net> wrote:

> Steven Sommars said:
> > The secure time transfer of NTS was designed to avoid amplification
> attacks.
>
> I work on NTP software (ntpsec).  I have a couple of low cost cloud
> servers in
> the pool where I can test things and collect data.
>
> I see bursts of 10K to several million packets "from" the same IP Address
> at
> 1K to 10K packets per second.  Ballpark of 100 events per day, depending
> on
> the size cutoff.  I saw one that lasted for most of a day at 1K
> packeets/sec.
>
> All the packets I've seen have been vanilla NTP requests - no attempt at
> amplification.  I'm only checking a very small fraction of the garbage.
>
> I haven't seen any pattern in the target IP Address.  Reverse DNS names
> that
> look like servers are rare.  I see legitimate NTP requests from some of
> the
> targets.
>
> Would data be useful?  If so, who, what, ... (poke me off list)
>
> I don't see any good solution that a NTP server can implement.  If I block
> them all, the victim can't get time.  If I let some fraction through, that
> just reduces the size of the DDoS.  I don't see a fraction that lets
> enough
> through so the victim is likely to get a response to a legitimate request
> without also getting a big chunk of garbage.  I'm currently using a
> fraction
> of 0.  If the victim is using several servers, one server getting knocked
> out
> shouldn't be a big deal.  (The pool mode of ntpd should drop that system
> and
> use DNS to get another.)
>
> If NTS is used, it would be possible to include the clients IP Address in
> the
> cookie and only respond to requests with cookies that were issued to the
> client.  That has privacy/tracking complications.
>
> --
>
> I don't want to start a flame war, but why isn't BCP 38 widely deployed?
> Can
> somebody give me a pointer to a talk at NANOG or such?  What fraction of
> the
> world does implement BCP 38?
>
> I'd also be interested in general background info on DDoS.  Who is
> DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor?
> Bad guys making a test run to see if the server can be used for a real
> run?
> Is DDoS software widely available on the dark web?  ...
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>

Re: UDP/123 policers & status

[Roland Dobbins]

On 21 Mar 2020, at 4:58, Hal Murray wrote:

I don't want to start a flame war, but why isn't BCP 38 widely 
deployed?  Can
somebody give me a pointer to a talk at NANOG or such?  What fraction 
of the

world does implement BCP 38?

I'd also be interested in general background info on DDoS.  Who is 
DDoS-ing
whom and/or why?  Is this gamers trying to get an advantage on a 
competitor?
Bad guys making a test run to see if the server can be used for a real 
run?

Is DDoS software widely available on the dark web?  ...


Answers to all of these questions are readily available via search 
engines, searching the archive of this and related listservs, searching 
the presentation archives of 
NANOG/RIPE/APRICOT/APNIC/AusNOG/NZNOG/LACNIC, et. al.  My archive of 
public presentations is available here:




These topics are well-understood and -documented, and a bit of research 
can help bring one up to speed on them pretty quickly.



Roland Dobbins 

Re: UDP/123 policers & status

[Saku Ytti]

On Fri, 27 Mar 2020 at 19:48, Ragnar Sundblad  wrote:

> Is this really what the ISP community wants - to kill off port 123,
> and force NTP to move to random ports?

Make NST attenuation vector, so that reply is guaranteed to be
significantly smaller than request, and by standard drop small
requests.

-- 
  ++ytti

Re: UDP/123 policers & status

[Ragnar Sundblad]

Hello,

I am one of the authors of the NTS for NTP specification,
.

Steven described this well, and as he wrote, the first step in the NTS
procedure is to contact a Key Establishment (KE) server, the KE server
will point to the NTP server and port to use, also taking into
consideration what the client requested, if it did.

The NTP packets will be larger than what they are today, since they
contain one or sometimes more than one “cookies” or “cookie placeholders”
(a measure to make amplification impossible).

Today, some points in the internet still filter port 123 on size.

If this continues, NTS enabled NTP server owners will likely not run
the corresponding NTP server on port 123, since there is no need to,
they can run it on an arbitrary port.

There seems to be no willingness from the ISP community to try to
clean up the old NTP traffic amplifiers that are still out there.

Is this really what the ISP community wants - to kill off port 123,
and force NTP to move to random ports?

Ragnar

Re: UDP/123 policers & status

[Hal Murray]

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

I work on NTP software (ntpsec).  I have a couple of low cost cloud servers in 
the pool where I can test things and collect data.

I see bursts of 10K to several million packets "from" the same IP Address at 
1K to 10K packets per second.  Ballpark of 100 events per day, depending on 
the size cutoff.  I saw one that lasted for most of a day at 1K packeets/sec.

All the packets I've seen have been vanilla NTP requests - no attempt at 
amplification.  I'm only checking a very small fraction of the garbage.

I haven't seen any pattern in the target IP Address.  Reverse DNS names that 
look like servers are rare.  I see legitimate NTP requests from some of the 
targets.

Would data be useful?  If so, who, what, ... (poke me off list)

I don't see any good solution that a NTP server can implement.  If I block 
them all, the victim can't get time.  If I let some fraction through, that 
just reduces the size of the DDoS.  I don't see a fraction that lets enough 
through so the victim is likely to get a response to a legitimate request 
without also getting a big chunk of garbage.  I'm currently using a fraction 
of 0.  If the victim is using several servers, one server getting knocked out 
shouldn't be a big deal.  (The pool mode of ntpd should drop that system and 
use DNS to get another.)

If NTS is used, it would be possible to include the clients IP Address in the 
cookie and only respond to requests with cookies that were issued to the 
client.  That has privacy/tracking complications.

--

I don't want to start a flame war, but why isn't BCP 38 widely deployed?  Can 
somebody give me a pointer to a talk at NANOG or such?  What fraction of the 
world does implement BCP 38?

I'd also be interested in general background info on DDoS.  Who is DDoS-ing 
whom and/or why?  Is this gamers trying to get an advantage on a competitor?  
Bad guys making a test run to see if the server can be used for a real run?  
Is DDoS software widely available on the dark web?  ...





-- 
These are my opinions.  I hate spam.

Re: UDP/123 policers & status

[Steven Sommars]

 NTS is initialized using a relatively expensive, but short lived, TCP TLS
session.  NTP loss due to rate limiting will require more frequent TCP
initializations.

The NTP size-blocks I've observed have been hard, not rate limits.  Martin
Langer provided a table showing sizes between 228 and 1468 bytes depending
on the encryption algorithm and number of cookies.  I've asked the NTS
authors about potential workarounds, but suspect it would be difficult.
The authors have also confirmed that size blocks have been detected during
NTS tests.

The secure time transfer of NTS was designed to avoid amplification
attacks.  Impairment of UDP port 123 could require use of alternate UDP
port(s), which might be unpopular.

On Wed, Mar 18, 2020 at 6:46 PM Damian Menscher  wrote:

> On Wed, Mar 18, 2020 at 8:45 AM Steven Sommars 
> wrote:
>
>> The various NTP filters (rate limits, packet size limits) are negatively
>> affecting the NTP Pool, the new secure NTP protocol (Network Time Security)
>> and other clients.  NTP filters were deployed several years ago to solve
>> serious DDoS issues, I'm not second guessing those decisions.  Changing the
>> filters to instead block NTP mode 7, which cover monlist and other
>> diagnostics, would improve NTP usability.
>>
>> http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf
>>
>>
>
> I've advocated a throttle (not a hard block) on udp/123 packets with 468
> Bytes/packet (the size of a full monlist response).  In your paper you
> mention NTS extensions can be 200+ bytes.  How large do those packets
> typically get, in practice?  And how significant is packet loss for them
> (if there's high packet loss during the occasional attack, does that pose a
> problem)?
>
> Damian
>

Re: UDP/123 policers & status

[Damian Menscher via NANOG]

On Wed, Mar 18, 2020 at 7:05 PM Harlan Stenn  wrote:

> On 3/18/2020 4:46 PM, Damian Menscher via NANOG wrote:
> > On Wed, Mar 18, 2020 at 8:45 AM Steven Sommars
> > mailto:stevesommars...@gmail.com>> wrote:
> >
> > The various NTP filters (rate limits, packet size limits) are
> > negatively affecting the NTP Pool, the new secure NTP protocol
> > (Network Time Security) and other clients.  NTP filters were
> > deployed several years ago to solve serious DDoS issues, I'm not
> > second guessing those decisions.  Changing the filters to instead
> > block NTP mode 7, which cover monlist and other diagnostics, would
> > improve NTP usability.
> >
> >
> http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf
>
> >
> >
> > I've advocated a throttle (not a hard block) on udp/123 packets with 468
> > Bytes/packet (the size of a full monlist response).  In your paper you
> > mention NTS extensions can be 200+ bytes.  How large do those packets
> > typically get, in practice?  And how significant is packet loss for them
> > (if there's high packet loss during the occasional attack, does that
> > pose a problem)?
>
> I expect to see NTP UDP packets that would approach the MTU limit, in
> some cases.
>
> If a packet is "too big" for some pathway, then are we talking about a
> fractional packet loss or are we talking about 100% packet loss (dropped
> mid-way due to size)?
>

I implement it as a throttle... but that effectively means "0% packet loss
most of the time, and significant packet loss when there's a large
attack".  Doing it as a complete block (which Sommars showed some networks
do) is unnecessary.

So my question is whether occasional bursts of hard-block are a problem.
If you only need large packets during the initialization phase, but the
ongoing communication is done with smaller packets, then my approach may be
acceptable, and we just need to convince other network operators to
throttle rather than hard-block the large packets.  But if you need large
packets all the time, and occasional breakage of large packets causes
problems, then I'll need to re-think my approach.

Damian

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/18/2020 4:46 PM, Damian Menscher via NANOG wrote:
> On Wed, Mar 18, 2020 at 8:45 AM Steven Sommars
> mailto:stevesommars...@gmail.com>> wrote:
> 
> The various NTP filters (rate limits, packet size limits) are
> negatively affecting the NTP Pool, the new secure NTP protocol
> (Network Time Security) and other clients.  NTP filters were
> deployed several years ago to solve serious DDoS issues, I'm not
> second guessing those decisions.  Changing the filters to instead
> block NTP mode 7, which cover monlist and other diagnostics, would
> improve NTP usability.
> 
> 
> http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf  
> 
> 
> I've advocated a throttle (not a hard block) on udp/123 packets with 468
> Bytes/packet (the size of a full monlist response).  In your paper you
> mention NTS extensions can be 200+ bytes.  How large do those packets
> typically get, in practice?  And how significant is packet loss for them
> (if there's high packet loss during the occasional attack, does that
> pose a problem)?

I expect to see NTP UDP packets that would approach the MTU limit, in
some cases.

If a packet is "too big" for some pathway, then are we talking about a
fractional packet loss or are we talking about 100% packet loss (dropped
mid-way due to size)?

> Damian

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Damian Menscher via NANOG]

On Wed, Mar 18, 2020 at 8:45 AM Steven Sommars 
wrote:

> The various NTP filters (rate limits, packet size limits) are negatively
> affecting the NTP Pool, the new secure NTP protocol (Network Time Security)
> and other clients.  NTP filters were deployed several years ago to solve
> serious DDoS issues, I'm not second guessing those decisions.  Changing the
> filters to instead block NTP mode 7, which cover monlist and other
> diagnostics, would improve NTP usability.
>
> http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf
>
>

I've advocated a throttle (not a hard block) on udp/123 packets with 468
Bytes/packet (the size of a full monlist response).  In your paper you
mention NTS extensions can be 200+ bytes.  How large do those packets
typically get, in practice?  And how significant is packet loss for them
(if there's high packet loss during the occasional attack, does that pose a
problem)?

Damian

Re: UDP/123 policers & status

[Saku Ytti]

On Wed, 18 Mar 2020 at 18:05, Ca By  wrote:

> Yeh, not changing ipv4 filters, Sorry pool. Burned once, twice shy.

On many edge routers from Juniper, Nokia and Cisco you can create
offset based bit-matches. I'm NTP illiterate, but isn't NTP mode in
fixed offset after UDP header? So it should be possible to do this in
hardware at linerate just the same as matching UDP port on typical
edge router.

-- 
  ++ytti

Re: UDP/123 policers & status

[Ca By]

On Wed, Mar 18, 2020 at 8:46 AM Steven Sommars 
wrote:

> The various NTP filters (rate limits, packet size limits) are negatively
> affecting the NTP Pool, the new secure NTP protocol (Network Time Security)
> and other clients.  NTP filters were deployed several years ago to solve
> serious DDoS issues, I'm not second guessing those decisions.  Changing the
> filters to instead block NTP mode 7, which cover monlist and other
> diagnostics, would improve NTP usability.
>
> http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf
>
>

Yeh, not changing ipv4 filters, Sorry pool. Burned once, twice shy.

There is no simple way to do router filters based on ntp app modes.

I suggest people be aware of time.google.com

And  time.cloudflare.com

CB


> On Tue, Mar 17, 2020 at 11:17 AM Mark Tinka  wrote:
>
>>
>>
>> On 17/Mar/20 18:05, Ca By wrote:
>>
>>
>>
>>
>> +1 , still see, still have policers
>>
>> Fyi, ipv6 ntp / udp tends to have a much higher success rate getting
>> through cgn / policers / ...
>>
>>
>> For those that have come in as attacks toward customers, we've "scrubbed"
>> them where there has been interest.
>>
>> Mark.
>>
>

Re: UDP/123 policers & status

[Steven Sommars]

The various NTP filters (rate limits, packet size limits) are negatively
affecting the NTP Pool, the new secure NTP protocol (Network Time Security)
and other clients.  NTP filters were deployed several years ago to solve
serious DDoS issues, I'm not second guessing those decisions.  Changing the
filters to instead block NTP mode 7, which cover monlist and other
diagnostics, would improve NTP usability.

http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf

On Tue, Mar 17, 2020 at 11:17 AM Mark Tinka  wrote:

>
>
> On 17/Mar/20 18:05, Ca By wrote:
>
>
>
>
> +1 , still see, still have policers
>
> Fyi, ipv6 ntp / udp tends to have a much higher success rate getting
> through cgn / policers / ...
>
>
> For those that have come in as attacks toward customers, we've "scrubbed"
> them where there has been interest.
>
> Mark.
>

Re: UDP/123 policers & status

[Mark Tinka]

On 17/Mar/20 18:05, Ca By wrote:

>
>
>
> +1 , still see, still have policers
>
> Fyi, ipv6 ntp / udp tends to have a much higher success rate getting
> through cgn / policers / ...

For those that have come in as attacks toward customers, we've
"scrubbed" them where there has been interest.

Mark.

Re: UDP/123 policers & status

[Ca By]

On Tue, Mar 17, 2020 at 9:03 AM Compton, Rich A 
wrote:

> Yes, we still see lots of UDP amplification attacks using NTP monlist.  We
> use a filter to block UDP src 123 packets of 468 bytes in length (monlist
> reply with the max 6 IPs).
>
> -Rich


+1 , still see, still have policers

Fyi, ipv6 ntp / udp tends to have a much higher success rate getting
through cgn / policers / ...



>
> On 3/17/20, 8:55 AM, "NANOG on behalf of Jared Mauch" <
> nanog-boun...@nanog.org on behalf of ja...@puck.nether.net> wrote:
>
> I’m curious what people are seeing these days on the UDP/123 policers
> in their networks.
>
> I know while I was at NTT we rolled some out, and there are a number
> of variants that have occurred over the past 6-7 years.  I’ve heard from
> people at the NTP Pool as well as having observed some issues with NTP at
> Akamai and time sync from time to time.
>
> Are you still seeing a lot of NTP attacks in your flows these days?
>
> Should we be looking to remove these, similar to how we did for
> SQL/Slammer after a time?
>
> - Jared
>
> E-MAIL CONFIDENTIALITY NOTICE:
> The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) and may contain confidential and/or legally
> privileged information. If you are not the intended recipient of this
> message or if this message has been addressed to you in error, please
> immediately alert the sender by reply e-mail and then delete this message
> and any attachments. If you are not the intended recipient, you are
> notified that any use, dissemination, distribution, copying, or storage of
> this message or any attachment is strictly prohibited.
>

Re: UDP/123 policers & status

[Compton, Rich A]

Yes, we still see lots of UDP amplification attacks using NTP monlist.  We use 
a filter to block UDP src 123 packets of 468 bytes in length (monlist reply 
with the max 6 IPs).

-Rich

On 3/17/20, 8:55 AM, "NANOG on behalf of Jared Mauch"  wrote:

I’m curious what people are seeing these days on the UDP/123 policers in 
their networks.

I know while I was at NTT we rolled some out, and there are a number of 
variants that have occurred over the past 6-7 years.  I’ve heard from people at 
the NTP Pool as well as having observed some issues with NTP at Akamai and time 
sync from time to time.

Are you still seeing a lot of NTP attacks in your flows these days?

Should we be looking to remove these, similar to how we did for SQL/Slammer 
after a time?

- Jared

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: UDP/123 policers & status

[Mark Tinka]

On 17/Mar/20 16:53, Jared Mauch wrote:

> Should we be looking to remove these, similar to how we did for SQL/Slammer 
> after a time?

FWIW, we've never policed udp/123 on our end. We haven't seen anything
untoward.

Mark.

UDP/123 policers & status

[Jared Mauch]

I’m curious what people are seeing these days on the UDP/123 policers in their 
networks.

I know while I was at NTT we rolled some out, and there are a number of 
variants that have occurred over the past 6-7 years.  I’ve heard from people at 
the NTP Pool as well as having observed some issues with NTP at Akamai and time 
sync from time to time.

Are you still seeing a lot of NTP attacks in your flows these days?

Should we be looking to remove these, similar to how we did for SQL/Slammer 
after a time?

- Jared