MUST, SHOULD, DON’T CARE: TCP Conformance in the Wild

Abstract

Standards govern the SHOULD and MUST requirements for protocol implementers for interoperability. In case of TCP that carries the bulk of the Internets' traffic, these requirements are defined in RFCs. While it is known that not all optional features are implemented and nonconformance exists, one would assume that TCP implementations at least conform to the minimum set of MUST requirements. In this paper, we use Internet-wide scans to show how Internet hosts and paths conform to these basic requirements. We uncover a non-negligible set of hosts and paths that do not adhere to even basic requirements. For example, we observe hosts that do not correctly handle checksums and cases of middlebox interference for TCP options. We identify hosts that drop packets when the urgent pointer is set or simply crash. Our publicly available results highlight that conformance to even fundamental protocol requirements should not be taken for granted but instead checked regularly.

Who's Breaking the Rules? Studying Conformance to the HTTP Specifications and its Security Impact

“…Other protocols. The fact that implementations not following the specification or applying differing interpretations lead to issues is well-known in TCP [47], URL parsing [67,4], or HTML [38]. To help developers, the W3C provides an HTML and CSS validator as well as a URL testing suite [76].…”

Less Is More: Choosing Fair Network Coding Parameters

“…TCP then ensures that the payload is small enough to fit this value, taking additional IP and TCP options into account [5]. As this approach is similar to MSS clamping, which is often done by routers [19], TCPyNC could be deployed specifically before network paths that are known to suffer from packet losses in order to reduce the overall load induced by network coding on all paths. For the sake of simplicity we consider end-to-end coding throughout this paper.…”