UDP/123 policers & status

Thu Mar 19 02:43:32 UTC 2020

 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 <damian at google.com> wrote:

> On Wed, Mar 18, 2020 at 8:45 AM Steven Sommars <stevesommarsntp at 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)?
>
> Damian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200318/2181c9a7/attachment.html>