NTS not 'working', likely operator error

Tue May 21 00:37:24 UTC 2024

Comcast removed the IPv4 port 123 filter: IP length != 56-bytes in my
region (Suburban Chicago) on May 7.
It was removed in at least one other region, but I don't know about other
regions.  I believe that Comcast plans to remove the filter in all
regions.

Filters from other carriers are still in place

On Tue, Apr 9, 2024 at 9:19 AM Steven Sommars <stevesommarsntp at gmail.com>
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)
>
>
>
>
>
>
>
> 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/20240520/7cad28f3/attachment.htm>