Re: What do you consider acceptable packet / session modification for a network operator?

[Ca By via NANOG <nanog () lists nanog org>]

On Fri, Dec 26, 2025 at 1:03 AM Andrew via NANOG <nanog () lists nanog org>
wrote:

> Glad everyone agrees ISPs should not be doing this!

😂

> Most of these things are currently being done by a US national wireless
> ISP to their ~100M customers. I’m sure you can guess who it is, there are
> only 3 choices.

Only at&t does this IPv6 address change, no ?


> I spent an afternoon hand-crafting packets on their network to a remote
> cloud VPS to try to understand wtf their network is doing. I did all of
> this over IPv6 to avoid CGNAT.


Many have already done this research

But at&t laid out a version of their plan here

https://www.theregister.com/2014/02/24/saving_private_spying_cryptobusting_proxy_proposal_surfaces_at_ietf/

https://datatracker.ietf.org/doc/html/draft-loreto-httpbis-trusted-proxy20-01




> The first clue to me is that a ‘what is my IP’ website does not report the
> same IPv6 as the device. Obviously we should never be using NAT in IPv6, so
> clearly this ISP is doing something suspicious, and the ‘what is my IP’
> IPv6 ends in ::8 which is also suspiciously manually generated. I
> eventually concluded that all traffic with a TCP or UDP destination port of
> 443 was being NATed via this ::8 address, while a random high numbered
> destination port was coming from the device’s IPv6 as expected.
>
> I drilled down into the behavior of this port 443 proxy and concluded:
> - The proxy responds to all TCP SYNs with a SYN ACK and establishes a
> connection
> - After the connection is established, it will then dial the remote side,
> so if I never send the ACK it will never dial the remote side
> - If the remote side rejects the connection, the proxy will ‘eat’ all of
> the bytes which have already been sent and then close the connection
> without any error on the client side
> - The proxy will still pass arbitrary bytes after the connection is
> established, even if they are not TLS traffic, it also does not appear to
> impact TLS traffic in any way that I could detect
> - The proxy re-negotiates all of the TCP options, so setting MSS manually
> on either side does not get passed through. Congestion control will also be
> impacted by this. The proxy seems to choose 1370 as its preferred MSS on
> both sides.
>
> I cannot understand a legitimate use case for an ISP to run such a proxy
> on port 443, and the resources required to proxy essentially all of the TLS
> traffic for 100M customers must be enormous.
>
> I then tried to scan all ports with TCP SYNs to see if any proxy responded
> with a SYN ACK, but hit some sort of rate limit on new connections and got
> unreliable responses (this could have been in my handset, which is acting
> as a hotspot). I limited my search to the first 1024 ports and found
> similar behavior on ports 21, 80, 443, and 554. All four proxies each have
> their own public IP, and it is different for each (so ‘what is my ip’ on
> port 80 is different than on 443).
>
> Digging in to the port 80 proxy, when connecting over HTTP to any
> destiatnation on port 80, the proxy adds a ‘Via:’ header to the HTTP
> request. This includes a seemingly random but never changing ID which is
> formatted as a DNS name, although the specific subdomain does not exist. I
> suspect this is a unique identifier which identifies me as a subscriber
> uniquely for advertising purposes. It's also found that sending a valid
> HTTP response with an invalid HTTP status code number will cause the proxy
> to return an HTML page which says 503 Service Unavailable. I was not able
> to detect any modification of data, but again I have no idea if it may be
> modifying only certain sites / …
>
> Again, this is not my network, I am trying to understand why a network
> operator would interfere with their users in this way.
>
> Andrew
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/4GGYOTKHLHEJEIRWN32GEWL7EKSN7OBH/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/MAAQJJMUSGZ2OC6VZZI7T2A5DQSGAMLS/