Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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,

Re: UDP/123 policers & status

> 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

Re: UDP/123 policers & status

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,

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

> 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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

> 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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

> 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

Re: UDP/123 policers & status

> 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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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?

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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 >

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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.

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

Re: UDP/123 policers & status

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

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