NTS not 'working', likely operator error

[ntpsec at anastrophe.com]

On 4/9/2024 7:19 AM, Steven Sommars via users wrote:
> I've examined NTP filtering quite a bit. IPv4 is more filtered than 
> IPv6  See 
> https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/ for 
> an analysis from 2020.
> The NTP blocks can change over time.  From  recent scans I see Comcast 
> blocks port 123 for UDP size not equal to 56 (NTP payload is 48 bytes).
> I saw this from two residential locations, one near Chicago and one near 
> Denver.    For my local system this block was added on about 2023-02-14.
> Level 3 is a big offender.
>
> With some work you can use traceroute or similar tools such as mtr to 
> probe for blocks in the outgoing direction.
>
>     mtr -n -s 450 -u -P 123   IPv4_address
>
>     -s sets the payload size.  -P set the outgoing port number.
>
> CAUTION.   I've found argument parsing bugs in some traceroute and mtr 
> versions.    The above example works for mtr version 0.95 but doesn't 
> work for version 0.85
> I use tcpdump/wireshark to verify that outgoing probe packets have UDP 
> destination port set to 123 and that they have the expected size.
>
> -P 123      NTP (UDP port 123) size 450 is blocked in local ISP, can't 
> tell where
>                                   Packets Pings
>  Host                           Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. local_system                 0.0%     3    1.3   1.2 1.2   1.3   0.0
>  2. (waiting for reply)
>
> -P 122     UDP port 122 size 450 is not blocked
> Packets               Pings
>  Host                           Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. local_system                 0.0%    16    1.3   1.1 0.8   1.3   0.2
>  2. (waiting for reply)
>  3. (waiting for reply)
>  4. 12.242.117.29                0.0%    16   10.7   9.8 6.2  13.1   2.6
>  5. 192.205.37.42                0.0%    16    7.9   9.6 7.4  18.7   3.5
>  6. 171.75.8.101                 0.0%    16  151.9 154.2 151.4 164.3   3.5
>  7. 62.67.67.154                 0.0%    16  152.2 152.9 151.5 157.4   1.5
>  8. 188.1.144.134                0.0%    16  157.3 185.6 157.2 255.3  42.5
>  9. (waiting for reply)

Thanks for the reply and the info regarding use of mtr. I've done a bunch 
of tests today between my mailserver in AWS, my webserver in the Oracle 
cloud, and my timeserver here on comcast/xfinity - both directions, 
different packet sizes, watching tcpdump output on both sides, using mtr, 
netcat, etc.. When my timeserver sends more than 48 bytes to either cloud 
server over UDP port 123, they will reach the destination server, but the 
reply back will not reach my timeserver.

I set up both my mailserver and my webserver to both run NTS. No problem 
communicating between the two. So, comcast/xfinity blocks large UDP 
packets on port 123, as you described.

It appears that I can no longer provide NTS timeservice to the outside 
world. This sort of widespread blocking can only further hinder adoption 
of NTS.

-- 
Paul Theodoropoulos
www.anastrophe.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20240409/43bd7dc1/attachment.htm>