The Importance of Protocol Tests in Network Interoperability
Introduction:
Network protocol testing ensures the reliability, security, and interoperability of computer networks. Network protocols are embedded in applications and devices operating on the Internet. Secure and reliable networks are highly dependent on the quality of the implementation of the network applications and devices.
This paper will review the impact on network interoperability with protocol errors, the lack of sufficient testing prior to deployment, the role of the U.S. Government with protocol testing, a review of network protocol testing for interoperability versus conformance, and steps you can take to protect your environment.
What is a network protocol?
A network protocol is a set of rules and procedures that govern the communication between devices on a network. The protocol defines how data is transmitted, received, and processed over the network. Examples of network protocols include ARP, DNS, HTTP, HTTPS, ICMP, IPv4, IPv6, MQTT, SNMP, SMTP, QUIC, TCP, UDP...
Network protocol testing allows the network product developer to evaluate the performance, functionality, and security of their protocol implementation; identify any potential issues; and ensure the issues are corrected, prior to deployment.
What happens to network interoperability if a product contains protocol errors?
In the early days of the Internet, a guiding principle of the Internet Engineering Task Force, in referring to Internet traffic / packets, was “be conservative in what you send; be liberal in what you accept”. Initially this philosophy was widely accepted; many products from diverse manufacturers could interoperate. Without the “liberal acceptance” philosophy, however, many products would have failed to interoperate with other products.
As the popularity of the Internet increased, malevolent actors took advantage of improperly (or incompletely) implemented protocols. The “liberal acceptance” philosophy had to change.
A good example of this is the Heartbleed bug. An extension to the transport layer security protocols, the “Heartbeat Extension” is defined in RFC 6520 TLS/DTLS. Unfortunately, this extension was improperly implemented in the OpenSSL code. This allowed attackers to gain access to private data without leaving a trace. The bug was eventually corrected. However, about a half million websites used OpenSSL and were subject to the attack. (For more information on the impact of this vulnerability, see:
https://www.darkreading.com/attacks-breaches/heartbleed-examining-the-impact )
Interoperability testing goes beyond conformance testing. Interoperability is not merely two heterogenous network devices passing packets back and forth. In addition, the devices must transmit packets securely, privately, without permitting data breaches. Uncorrected protocol implementation errors have a negative impact on network interoperability.
A good example is the manner in which a packet is decoded by the receiving network node. Best practice is for the packet to be decoded or disassembled in its entirety prior to processing the packet. Why? To ensure that the complete packet is properly constructed and valid. Some developers begin decoding and processing when just a few octets are received in order to improve performance. However if the packet is malformed or invalid, the receiving device is likely to hang or worse case, be compromised.
Are all applications and devices on the Internet subjected to protocol testing prior to deployment?
There are no restrictions prohibiting the deployment of untested, unproven products on the Internet. The general public’s expectation is that the network protocols “just work”. Of course, the large number of reported data breaches ought to inform the general public that something is amiss.
The only requirement for protocol testing is for one protocol, IPv6, and for one customer, the US Government. How did this come about?
In November 2020, the U.S. Office of Management and Budget issued memorandum M-21-07 “Completing the Transition to Internet Protocol Version 6 (IPv6)”. See: https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf
This document outlines the U.S. government's strategic intent "to deliver its information services, operate its networks, and access the services of others using only IPv6".
In general, such efforts must be applauded as they represent a step in the right direction. However, this program is managed by NIST which is only engaged in “classical” protocol conformance testing:
Protocol Conformance testing is the process of systematically selecting each requirement in a standards document and then testing to see if the device under test operates according to that requirement. This is done by creating a series of single function tests for each requirement, resulting in thousands or hundreds of thousands of tests.
NIST depends on a “Core Conformance” document that is 357 pages long with multiple tests listed on most pages. This document specifies a test for virtually every facet of the IPv6 protocol. Many of the tests are unnecessary and time consuming and do not address interoperability testing. A better approach would be to limit the scope of the tests to the more difficult and complex implementation areas of the protocol, as opposed to testing every single detail.
Nevertheless, requiring that products sold to the U.S. Government pass these tests signals a step in the right direction. The U.S. Government can assert these requirements, and suppliers must comply, because of the extremely large volume of purchases by the U.S. Government.
Network protocol testing for interoperability versus conformance.
Testing for interoperability addresses the larger environment of product usage. Conformance testing addresses the single function correctness of a portion of the product. It might be helpful to consider some examples.
It is possible for each part of an airplane to pass every single conformance test, but be unable to fly because of interoperability issues with those parts.
In California, an automobile is required to conform to the California Code of Regulations – Title 13 – Motor Vehicles. This document has several pages on requirements for air brakes, hydraulic brakes, and other aspects of braking. Those are the conformance requirements. However, interoperability for car brakes would include a crash test to understand harm to the vehicle occupants under various braking conditions.
What are the benefits of protocol tests for network interoperability?
Network protocol testing helps ensure that each application or device on the network demonstrates reliable operation by identifying performance issues, interoperability issues, and vulnerabilities.
Network protocol testing may enhance security through penetration testing (sending pathological packets) to a device or application under test. This process finds security weaknesses and vulnerabilities that the app or device supplier must remediate.
Network protocol testing helps reduce downtime by identifying potential issues before they cause major problems. Many major outages are a result of both a protocol error and a misconfiguration error. For example, in 2012, an error in the Domain Name System (DNS) protocol caused a widespread outage for users of several popular websites, including Amazon, Netflix, and Pinterest. The error occurred when one of the authoritative DNS servers for the affected websites began responding with incorrect information, causing some users to be redirected to incorrect IP addresses and resulting in service disruptions.
Network protocol testing helps identify performance issues both individually and among network devices. Some issues such as latency or fragmentation can impact the network's performance. It is difficult to find the cause of such problems on the network, as a slow and poorly performing device may be the result of a misconfigured router in a remote part of the network with the problem manifesting as latency on an end device.
Conclusion:
There is a compelling need for network protocol testing to keep our networks interoperable, safe and secure. However, with the exception of IPv6 implementations for the U.S. Government, application and device manufacturers are not required to do any testing at all. This must change. Too much of our Internet infrastructure depends on critical components with a haphazard genesis as illustrated by this well-known XKCD cartoon:
While most organizations do not have the purchasing power of the U.S. Government, these organizations can still ask potential suppliers to provide them information on how the product under consideration was tested.