Reply to post: "But isn't that how NAT works?"

"But isn't that how NAT works?"

No, it's not how NAT works. NAT doesn't ACK, because it has no control of the transmission, nor it does anything about the state but the address:port mapping - only the two ends know exactly what has been sent and what has been received.

Say A sends a packet P to B through router R. If R ACKs P, A thinks B has received it. But if the packet is lost between R and B, (there could be other routers, switches, access points, etc.) and B doesn't ACK it, R can't resend it because it has no memory of packets, and B would never resend it because it has seen the ACK.

While it is true that NAT breaks the end-to-end design, and externally it's seen as the "host", is also true that it can't (and must not) perform the full TCP processing because it has not the required data to do it (and it would also make it far slower). Some protocols may require additional processing to work, and require the router to mess with parts of the payload, but that's why NAT is "evil", still, it doesn't Control (the C in TCP) the transmission.

The only thing NAT has to look at the TCP/UDP layer are the ports - and if and only if PAT is used, you can do 1:1 NAT between IP addresses and ignore ports - because that's what is used for mappings.

Fragmentation is handled at the IP level, and it's transparent for TCP and UDP (and with IPv6, routers don't do fragmentation either).

If sending a given stream of packets triggers other issues is a different thing, it doesn't depend on the SACK implementation. I don't think this attack needs a huge number of packets, anyway,