TCP Checksum: The Fault in the Stars

TCP Checksum could be deemed as one of the weakest non-cryptographic checksums, and yet it continues to be there, undisputed. Sometimes edge-systems even have it turned off for performance reasons, counting on the application checksums for integrity; while other systems like gateways and servers have them offloaded to the network interface card (NIC), mostly because the functionality exists. The question is, does it really serve any purpose in today’s date? It does, very little.

RFC 793:

The checksum field is the 16 bit one’s complement of the one’s complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.

Continue reading “TCP Checksum: The Fault in the Stars”

IPv6: Floating IPs and Duplicate Address Detection

The very nature of the floating IPs can lead to some classical quirks in a distributed system network. This discussion mainly focuses on IPv6, and how its duplicate IP detection mechanism can clash with the floating IP technique.

Floating IPs are a common scenario in Highly Available or Scaled-out Distributed Systems. The basic idea behind it is to have a transient IP address that can move from one node to another, keeping the change of serving-node transparent on the access-side of the network. For instance, if there are two server machines, each represented by an unique IP, and one of them goes down, then its IP address “floats” to the other server which will henceforth process the client requests. This technique is widely used to provide seamless transition from one serving-node to another in case of failures. One such implementation is present in OpenStack Nova.

On the other hand, Duplicate Address Detection (DAD) is a mechanism to identify if same IP is assigned to multiple nodes in a local network. It is implemented using the Neighbor Discovery Protocol (NDP) under IPv6. It uses the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. The operation is applicable to all the IPs that are link-local. More specifically:

  • all the IPs that fall under the link-local address-family
  • all the IPs that fall under global address-family but are present on the same LAN (one hop away on the link)

Continue reading “IPv6: Floating IPs and Duplicate Address Detection”

TCP_MD5SIG: An Undocumented Socket Option in Linux

Although the Linux kernel implements RFC 2385 as TCP_MD5SIG socket option, there are no man page entries describing the functionality and the usage, for kernel as well as user-space. The setsockopt() is a straightforward API, however, the prerequisites or constraints put by the RFC makes it a bit tricky to use. It was meant to put a check on authenticity, although it could also be transparently used for data integrity, where the TCP checksum is not good enough!

RFC 2385 talks about “Protection of BGP Sessions via the TCP MD5 Signature Option”. It was proposed way back in 1998 to avoid the BGP from spoof-attacks wherein the attacker can forge the TCP segments. By adding MD5 signature as a TCP Option (Type #19), this spec provides a mechanism to vouch on the authenticity of the sender and data. The MD5 signature is computed using a pre-shared key between the client and the server.

The socket option TCP_MD5SIG saves a mapping of the pre-shared MD5 key against the corresponding peer endpoint. It is mandatory to bind the client to a particular IP and port known to the server. The setsockopt() must be called on the listen socket of the server and the connection socket of the client, before the connect() gets called from client.

Continue reading “TCP_MD5SIG: An Undocumented Socket Option in Linux”