Comcast traffic shaping^H^H^H^H^H^H^H^H^H^H^HNATs

| Networking
A group in Colorado recently reported that Comcast had introduced a new traffic shaping mechanism which was blocking even non-P2P TCP connections:
Recently, it has been observed that Comcast is disrupting TCP connections using forged TCP reset (RST) packets [1]. These reset packets were originally targeted at TCP connections associated with the BitTorrent file-sharing protocol. However, Comcast has stated that they are transitioning to a more "protocol neutral" traffic shaping approach [2]. We have recently observed this shift in policy, and have collected network traffic traces to demonstrate the behavior of their traffic shaping. In particular, we are able (during peak usage times) to synthetically generate a relatively large number of TCP reset packets aimed at any new TCP connection regardless of the application-level protocol. Surprisingly, this traffic shaping even disrupts normal web browsing and e-mail applications. Specifically, we observe two different types of packet forgery and packets being discarded.


We synthetically generated TCP SYN packets at a rate of 100 SYN packets per second using the hping utility [3]. The packets were destined for the reserved IP address, on which no host is present. We simultaneously collect network traces using tcpdump [4]. This data collection process was repeated at various times throughout multiple days. In addition, we could monitor a destination host to determine if outgoing packets reached their destination, and to determine if responses are generated by the destination host or by a third-party. Finally, this data collection was conducted from multiple Comcast accounts, all within close geographical proximity.

My initial reaction was that 100 SYN packets per second is a pretty pathological load, especially when these packets are being sent to a bogus net block (2/8 is unallocated by IANA) and that this sounded a lot more like some sort of anti-DoS measure, not really traffic shaping. The answer seems out to be even simpler:

A note regarding our findings: Further experiments have led us to believe that our initial conclusions that indicated Comcast's responsibility for dropping TCP SYN packets and forging TCP SYN, ACK and RST (reset) packets was incorrect. Our experiments were conducted from behind a network address translator (NAT). The anomalous packets were generated when the outbound TCP SYN packets exceeded the NAT's resources available in it's state table. In this case, TCP SYN, ACK and RST packets were sent. We would like to thank Don Bowman, Robb Topolski, Neal Krawetz, and Comcast engineers for bringing this to our attention. We sincerely apologize for any inconvenience that this posting may have caused.

This sounds pretty plausible to me; NATs often have fairly small state tables and 100 cps could definitely overload a residential NAT pretty quickly, and it's certainly easy enough to forget that the NAT box you're sitting behind is anything other than transparent. One thing that surprises me a bit is that the researchers claim to be seeing two kinds of anomalies: RSTs and spoofed SYN/ACKs. One would generally expect to see only one kind of response to overload. Maybe they have more than one NAT, though. It would certainly be interesting to hear what exact network gear they are using.