NTS not 'working', likely operator error

Tue May 21 01:51:21 UTC 2024

I'll be darned, it's working!

Any idea what prompted the change?

Regardless, glad to have NTS back available again. Thanks for the heads-up!

On 5/20/2024 17:37 PM, Steven Sommars wrote:
> 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 Theodoropoulos
>         www.anastrophe.com  <http://www.anastrophe.com>
>
>         _______________________________________________
>         users mailing list
>         users at ntpsec.org
>         https://lists.ntpsec.org/mailman/listinfo/users
>

-- 
Paul Theodoropoulos
www.anastrophe.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20240520/537e6bd3/attachment-0001.htm>