I’m doing a bit of research on how consumer-focused ISPs are modifying their 
user’s traffic, and I think you guys would have useful insight into legitimate 
reasons to touch user packets.

Almost all of these examples have been seen in the wild by at least one US ISP, 
so none of these are purely hypothetical.

So, how do you feel about where to draw the line for what is acceptable from an 
ISP?

Examples:

- Using different source IP ranges in CGNat for ‘web’ traffic vs ’non-web’ 
(i.e. port 80/443 vs all other ports) - this can break local IP discovery for 
peer-to-peer stuff if it relies on a ‘web’ port for an API endpoint

- Using any form of NAT / packet translation with IPv6 (not including nat64 / 
other v4 transition related)

- Dropping non-TCP/UDP/ICMP protocols (outside of CGNat) - such as ‘raw’ IPSec 
ESP / AH without UDP encapsulation, or SCTP

- TCP MSS - MSS Clamping all connections

- TCP MSS - MSS Clamping, but you instead (accidentally?) set MSS to your 
desired value even if it was lower before

- Other TCP options - Dropping syn packets with invalid/unknown options

- TCP connection interception - Network operator terminates TCP session from 
user and then establishes a new one with the original destination. All TCP 
options, sequence numbers, .. are lost in this translation

- Related to above - Network accepts TCP connection which it will intercept 
(sends SYN/ACK to user) before it confirms that the destination is reachable

- Dropping/resetting port 80 sessions that don't ‘look like’ HTTP

- Dropping/resetting port 443 sessions that don't ‘look like’ TLS

- Redirecting port 53 DNS queries to ISP’s own servers, regardless of 
destination IP

- HTTP header injection into port 80 HTTP traffic (i.e. for user tracking)

- HTTP content injection into port 80 HTTP traffic (i.e. replacing ads, adding 
dialogs, …) (and not blanket redirection for non-payment)

Thanks,

Andrew ‘apalrd’ Palardy
www.apalrd.net
https://www.youtube.com/c/apalrdsadventures
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/JCNJISMBZQ3RBO5YJQKF6EU52T73A6B7/

Reply via email to