Protocol ossification: Difference between revisions

Revision as of 18:15, 12 August 2024

Latest revision as of 14:52, 22 June 2025

(3 intermediate revisions by 3 users not shown)

Line 1:

{{Short description|Reduction in the flexibility of network protocol design due to middleboxes}}

'''Protocol ossification''' is the loss of flexibility, [[extensibility]] and evolvability of [[network protocols]]. This is largely due to [[middlebox]]es that are sensitive to the [[wire image (networking)|wire image]] of the protocol, and which can interrupt or interfere with messages that are valid but which the middlebox does not correctly recognise. This is a violation of the [[end-to-end principle]]. Secondary causes include inflexibility in endpoint implementations of protocols.

Ossification is a major issue in [[Internet]] protocol design and deployment, as it can prevent new protocols or extensions from being deployed on the Internet, or place strictures on the design of new protocols; new protocols may have to be [[encapsulation (networking)|encapsulated]] in an already-deployed protocol or mimic the wire image of another protocol. Because of ossification, the [[Transmission Control Protocol]] (TCP) and [[User Datagram Protocol]] (UDP) are the only practical choices for [[transport protocol]]s on the Internet, and TCP itself has significantly ossified, making extension or modification of the protocol difficult.

Recommended methods of preventing ossification include [[encryption|encrypting]] protocol metadata, and ensuring that extension points are exercised and wire image variability is exhibited as fully as possible; remedying existing ossification requires coordination across protocol participants. [[QUIC]] is the first [[IETF]] transport protocol to have been designed with deliberate anti-ossification properties.

== History ==

Line 24 ⟶ 25:

The primary cause of protocol ossification is [[middlebox]] interference,{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=619}} invalidating the [[end-to-end principle]].{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=620}} Middleboxes may entirely block unknown protocols or unrecognised extensions to known protocols, interfere with extension or feature negotiation, or perform more invasive modification of protocol metadata.{{sfn|Edeline|Donnet|2019|p=171}} Not all middlebox modifications are necessarily ossifying; of those which are potentially harmful, they are disproportionately towards the [[network edge]].{{sfn|Edeline|Donnet|2019|p=173-175}} Middleboxes are deployed by network operators unilaterally to solve specific problems,{{sfn|Edeline|Donnet|2019|p=169}} including performance optimisation, security requirements (e.g., firewalls), [[network address translation]] or enhancing control of networks.{{sfn|Honda|Nishida|Raiciu|Greenhalgh|2011|p=1}} These middlebox deployments provide localised short-term utility but degrade the global long-term evolvability of the Internet in a manifestation of the [[tragedy of the commons]].{{sfn|Edeline|Donnet|2019|p=169}}

Changes to a protocol must be tolerated by all on-path intermediaries; if wide Internet deployment of the change is desired, then this extends to a large portion of intermediaries on the Internet. A middlebox must tolerate widely- used protocols as they were being used at the time of its deployment, but is liable not to tolerate new protocols or changes to extant ones, effectively creating a [[vicious cycle]] as novel [[wire image (networking)|wire images]] cannot gain wide enough deployment to make middleboxes tolerate the new wire image across the entire Internet.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=620}} Even all participants tolerating the protocol is no guarantee of use: in the absence of a negotiation or discovery mechanism, the endpoints may default to a protocol that is considered more reliable.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=621}}

Beyond middleboxes, ossification can also be caused by insufficient flexibility within the endpoint's implementation. [[Operating system kernels]] are slow to change and deploy,{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=621}} and protocols implemented in hardware can also inappropriately fix protocol details.{{sfn|Corbet|2015}} A widely- used [[application programming interface|API]] (API) that makes assumptions about the operation of underlying protocols can hinder the deployment of protocols that do not share those assumptions.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=620}}

== Prevention and remediation ==