A recent extension that aims to add support for transport options to the User Datagram Protocol (UDP) is already showing promise. Unfortunately, its deployment may be undermined by the way existing network devices process UDP length and checksum. In this post we at the Electronics Research Group, University of Aberdeen, show how using an ad-hoc option can help to overcome these limitations.
UDP Options
Transport options are defined for many IETF transport protocols, including Transmission Control Protocol (TCP), Stream Control Transmission Protocol (SCTP) and Datagram Congestion Control Protocol (DCCP), to allow flexibility in protocol design and facilitate its evolution.
UDP, on the other hand, is characterised by a minimal overhead and a fixed-length header: more articulate protocols have been either implemented on top of UDP, using it as substrate (like Real-time Transport Protocol (RTP) or more recently QUIC) or defined ex-novo using a different protocol number (like UDP-Lite or DCCP).
A recent UDP extension, called UDP Options (UDP-O), adds support for options to a UDP datagram creating a surplus area after the UDP payload. This mechanism leverages the redundancy between UDP length and IP payload length (obtained as IP total length minus IP header length for IPv4 or as IPv6 payload length minus the length of the extension headers for IPv6) as shown in Figure 1.
Figure 1: UDP Options area
UDP-O can provide a means to communicate remote parameters or support optional transport functions alleviating the burden of implementing each function in every application. For instance, they offer the probing method to discover the maximum size of a UDP datagram that can be sent across a path, enabling UDP Datagram Packetization Layer PMTU Discovery (DPLPMTUD). Furthermore, the fragmentation option benefits applications like DNSSEC by enabling transport of larger responses without incurring the pitfalls of IP layer fragmentation.
Can UDP Options be safely deployed?
Despite the simplicity of the UDP-O mechanism, our work revealed an unforeseen level of ossification affecting UDP and revolving around the role of the UDP and IP lengths.
We identified two main issues:
- UDP checksum validation based on IP payload length instead than on UDP length
- Consistency check between UDP length and IP payload length
These pathologies were detected in middleboxes operating at the transport layer both in client’s networks (such as home Network Address Translations (NATs) or Carrier-Grade NATs) and in the proximity of UDP servers on the Internet (such as firewalls or IDS/IPS). Additionally, the checksum pathology was discovered in the Network Interface Controller (NIC) of end-hosts (servers, workstations, smartphones).
UDP checksum validation is not harmful per se when performed by a middlebox (rather it’s an advantage when performed by the NIC). Even implementations using IP payload length instead of UDP length in the pseudo-header and/or as checksum coverage are perfectly transparent to UDP because the two values coincide.
On the contrary, in the presence of UDP-O, the lengths differ and a middlebox implementing the wrong algorithm will not validate UDP-O packets with the correct checksum. This can severely reduce the expected success for UDP-O deployment.
To address the checksum pathology, we introduced an ad-hoc option, the Checksum Compensation Option (CCO). CCO adds fields to the UDP-O area that compensate for the difference between the correct UDP checksum and the checksum based on IP length, making incorrect implementations transparent to UDP-O.
Measurements
To assess UDP-O’s traversal on a large scale, we measured paths to UDP servers with Tracemore using actual application packets (STUN Bind requests, DNS queries), to trigger a reply from the destination, but encapsulating them in UDP and UDP-O datagrams forged with the different checksums or carrying the CCO. The subset of responses received reveals which packets have correctly traversed the path.
To increase the number of paths and ASes tested we also targeted HTTP servers leveraging the fact that a portion of them reply with Internet Control Message Protocol (ICMP) or ICMPv6 Port Unreachable messages, thus still revealing which packets have reached them.
Considering the end-to-end approach of our measurements, the benign checksum validation (the one based on UDP length) was expected to be the most prevalent. Instead, our measurement revealed a very different picture, showing a limited traversal rate for UDP-O datagrams compliant with the original specification and better performances for packets with the checksum based on IP length or using CCO.
Figure 2 combines the outcome of all the tests to characterise the paths in terms of UDP-O pathologies.
Figure 2: Path characterisation
CCO increases UDP Options traversal
To highlight the impact of CCO, Figure 3 displays the paths that can be traversed by a regular UDP-O packet and the paths traversed only using CCO. Our option significantly increases UDP-O deployability; for IPv4 paths to UDP servers, the increment due to CCO is even greater than the number of paths originally traversed.
Figure 3: Path traversal with and without CCO
Unfortunately, about 16% of the paths are not traversed by any UDP-O datagram. This is most likely due to middleboxes checking the consistency between UDP and IP payload lengths and discarding the packets in case of mismatch. The ossification on these paths cannot be mitigated and they would need to be updated to enable UDP-O traversal.
Our work has also explored the use of UDP zero checksum as an alternative to CCO, concluding the CCO offers most benefit. Zero checksum can be a viable solution for options which, by design, should not be covered by a checksum (such as LITE).
How to test UDP Options in your network
To reproduce our measurements or to test UDP-O in your network you can use Tracemore - it embodies traceroute methodology so you can also pinpoint the interfering node (it requires root).
To quickly test UDP-O from your Android smartphone you can use Mobile Tracebox (it does not require root). Figure 4 shows the output of the app.
Figure 4: Mobile Tracebox UDP Options test output on the tested network, Three UK. In this case, UDP-O packets with the correct checksum cannot be received unless CCO is used.
CCO can overcome the major obstacles associated with UDP Options
When introducing a new protocol or a protocol extension it is important to understand how it interacts with the network equipment already deployed.
Despite the simplicity of the UDP-O mechanism, our study has revealed an unforeseen level of ossification affecting UDP and potentially preventing UDP-O deployment. Our findings have shown how the Checksum Compensation Option can overcome the major obstacles and significantly enhances the chances of adoption of the new extension.
The CCO technique has since been adopted as a part of the UDP-O specification, by incorporating a recommendation to use a redesigned Option Checksum (OCS).
This was the first study to explore UDP-O deployment issues and their implications on UDP-O design. You can read the full paper, view our slides or watch the recording of our presentation at TMA 2020 below.
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.