<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    I'll be darned, it's working!<br>
    <br>
    Any idea what prompted the change?<br>
    <br>
    Regardless, glad to have NTS back available again. Thanks for the
    heads-up!<br>
    <br>
    <div class="moz-cite-prefix">On 5/20/2024 17:37 PM, Steven Sommars
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAD4huA7Edm3=LwYtQwZEX4+p-dD0nk05+CD_0JcU97HU+WUX6A@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
              moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
                class="moz-txt-link-freetext">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"
                  moz-do-not-send="true" class="moz-txt-link-freetext">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">
                <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"
                  moz-do-not-send="true">www.anastrophe.com</a></pre>
                </div>
                _______________________________________________<br>
                users mailing list<br>
                <a href="mailto:users@ntpsec.org" target="_blank"
                  moz-do-not-send="true" class="moz-txt-link-freetext">users@ntpsec.org</a><br>
                <a
                  href="https://lists.ntpsec.org/mailman/listinfo/users"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.ntpsec.org/mailman/listinfo/users</a><br>
              </blockquote>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="74">-- 
Paul Theodoropoulos
<a class="moz-txt-link-abbreviated" href="http://www.anastrophe.com"
    moz-do-not-send="true">www.anastrophe.com</a></pre>
  </body>
</html>