NTS not 'working', likely operator error

[Steven Sommars]

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)







On Tue, Apr 9, 2024 at 1:37 AM ntpsec--- via users <users at ntpsec.org> wrote:

> On 4/8/2024 22:50 PM, Hal Murray via users wrote:
>
> The Ethernet MTU (max packet size) is 1500.  Round down for a couple of
> headers and you get 1472.  The Internet spec is 512.  (Or something like
> that.)  But (almost) everybody supports 1500.
>
> NTP with NTS packets are a couple hundred bytes -- much biffer than 48, but
> well below 1500, even with 7 extra cookies.
>
> There is a strange case that I don't think anybody has tracked down.  Some
> router (maybe many) drop NTP+NTS packets with 1, 2, or 3 extra cookies but
> work with 4.
>
> I don't have a good story for why netcat work but ntp+nts doesn't.  Did you
> try both directions?  Or from port 123 to port 123?  [My head hurts trying to
> dance around NAT.]
>
> Yes, agreed on the head hurting. As my later message acknowledged, I was
> seeing MTU at work. I was thinking the authenticated packets were larger
> than MTU, and "fun" ensuing from that, but as  you say they're less than
> 1500 even w/cookies.
>
> I did glean this from a long tcpdump -
>
> 22:46:44.212917 IP 172-089-174-168.res.spectrum.com.ntp > a-ntpsec.ntp:
> NTPv4, Client, length 48
> 22:46:44.213246 IP a-ntpsec.ntp > 172-089-174-168.res.spectrum.com.ntp:
> NTPv4, Server, length 48
> 22:46:44.728639 IP a-ntpsec.ntp > oregon.time.system76.com.ntp: NTPv4,
> Client, length 956
> 22:46:45.728637 IP a-ntpsec.ntp > time.txryan.com.ntp: NTPv4, Client,
> length 924
> 22:46:47.728639 IP a-ntpsec.ntp > time.cifelli.xyz.ntp: NTPv4, Client,
> length 924
> 22:47:00.728358 IP a-ntpsec.ntp > ntp1.net.berkeley.edu.ntp: NTPv4,
> Client, length 48
> 22:47:00.748122 IP ntp1.net.berkeley.edu.ntp > a-ntpsec.ntp: NTPv4,
> Server, length 48
>
> so, a normal exchange of NTP data for an NTP client, then my server sends
> "large" but less-than-MTU authenticated packets to the three NTS
> servers...but gets no reply.
>
> For now, I'm going to sleep on it. Appreciate your indulgence thus far.
>
> --
> Paul Theodoropouloswww.anastrophe.com
>
> _______________________________________________
> users mailing list
> users at ntpsec.org
> https://lists.ntpsec.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20240409/f20c7fee/attachment.htm>