<div dir="ltr"><div dir="ltr">Comcast removed the IPv4 port 123 filter: IP length != 56-bytes in my region (Suburban Chicago) on May 7.</div><div>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. </div><div><br></div><div>Filters from other carriers are still in place</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 9, 2024 at 9:19 AM Steven Sommars <<a href="mailto:stevesommarsntp@gmail.com">stevesommarsntp@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I've examined NTP filtering quite a bit. IPv4 is more filtered than IPv6 See <a href="https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/" target="_blank">https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/</a> for an analysis from 2020.<div>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). </div><div>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.</div><div>Level 3 is a big offender.</div><div><br></div><div>With some work you can use traceroute or similar tools such as mtr to probe for blocks in the outgoing direction. </div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>mtr -n -s 450 -u -P 123 IPv4_address </div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>-s sets the payload size. -P set the outgoing port number.</div></blockquote><div>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</div><div>I use tcpdump/wireshark to verify that outgoing probe packets have UDP destination port set to 123 and that they have the expected size.</div><div><br></div><div><font face="monospace">-P 123 NTP (UDP port 123) size 450 is blocked in local ISP, can't tell where<br> Packets Pings<br> Host Loss% Snt Last Avg Best Wrst StDev<br> 1. local_system 0.0% 3 1.3 1.2 1.2 1.3 0.0<br> 2. (waiting for reply)<br><br>-P 122 UDP port 122 size 450 is not blocked</font></div><div><font face="monospace"> Packets Pings<br> Host Loss% Snt Last Avg Best Wrst StDev<br> 1. local_system 0.0% 16 1.3 1.1 0.8 1.3 0.2<br> 2. (waiting for reply)<br> 3. (waiting for reply)<br> 4. 12.242.117.29 0.0% 16 10.7 9.8 6.2 13.1 2.6<br> 5. 192.205.37.42 0.0% 16 7.9 9.6 7.4 18.7 3.5<br> 6. 171.75.8.101 0.0% 16 151.9 154.2 151.4 164.3 3.5<br> 7. 62.67.67.154 0.0% 16 152.2 152.9 151.5 157.4 1.5<br> 8. 188.1.144.134 0.0% 16 157.3 185.6 157.2 255.3 42.5<br> 9. (waiting for reply)</font></div><div><br></div><div><br><div><div><br></div></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 9, 2024 at 1:37 AM ntpsec--- via users <<a href="mailto:users@ntpsec.org" target="_blank">users@ntpsec.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
On 4/8/2024 22:50 PM, Hal Murray via users wrote:
<blockquote type="cite"><span style="white-space:pre-wrap">
</span>
<pre>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.]
</pre>
</blockquote>
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.<br>
<br>
I did glean this from a long tcpdump -<br>
<br>
22:46:44.212917 IP 172-089-174-168.res.spectrum.com.ntp >
a-ntpsec.ntp: NTPv4, Client, length 48<br>
22:46:44.213246 IP a-ntpsec.ntp >
172-089-174-168.res.spectrum.com.ntp: NTPv4, Server, length 48<br>
22:46:44.728639 IP a-ntpsec.ntp > oregon.time.system76.com.ntp:
NTPv4, Client, length 956<br>
22:46:45.728637 IP a-ntpsec.ntp > time.txryan.com.ntp: NTPv4,
Client, length 924<br>
22:46:47.728639 IP a-ntpsec.ntp > time.cifelli.xyz.ntp: NTPv4,
Client, length 924<br>
22:47:00.728358 IP a-ntpsec.ntp > ntp1.net.berkeley.edu.ntp:
NTPv4, Client, length 48<br>
22:47:00.748122 IP ntp1.net.berkeley.edu.ntp > a-ntpsec.ntp:
NTPv4, Server, length 48<br>
<br>
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. <br>
<br>
For now, I'm going to sleep on it. Appreciate your indulgence thus
far.<br>
<pre cols="74">--
Paul Theodoropoulos
<a href="http://www.anastrophe.com" target="_blank">www.anastrophe.com</a></pre>
</div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@ntpsec.org" target="_blank">users@ntpsec.org</a><br>
<a href="https://lists.ntpsec.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.ntpsec.org/mailman/listinfo/users</a><br>
</blockquote></div>
</blockquote></div></div>