Protocol ossification: Difference between revisions

Revision as of 23:20, 1 December 2022

Latest revision as of 14:52, 22 June 2025

(15 intermediate revisions by 9 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 17 ⟶ 18:

[[QUIC]] is the first [[IETF]] transport protocol to deliberately minimise its wire image to avoid ossification.{{sfn|Trammell|Kuehlewind|2019|p=2}}

The [[Internet Architecture Board]] identified design considerations around the exposure of protocol information to network elements as a "developing field" in 2023.{{sfn|Arkko|Hardie|Pauly|Kühlewind|2023|loc=3. Further Work}}

== Causes ==

Line 22 ⟶ 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 ==

The [[Internet Architecture Board]] recommended in 2019 that implicit signals to observers should be replaced with signals deliberately intended for the consumption of those observers, and signals not intended for their consumption should be not be available to them (e.g., by encryption); and also that the protocol metadata should be [[message authentication|integrity protected]] so that it cannot be modified by middleboxes.{{sfn|Hardie|2019|p=7-8}} However, even fully encrypted metadata may not entirely prevent ossification in the network, as the wire image of a protocol can still show patterns that come to be relied upon.{{sfn|Fairhurst|Perkins|2021|loc=7. Conclusions}} Network operators use metadata for a variety of benign management purposes,{{sfn|Fairhurst|Perkins|2021|loc=2. Current Uses of Transport Headers within the Network}} and Internet research is also informed by data gathered from protocol metadata;{{sfn|Fairhurst|Perkins|2021|loc=3. Research, Development, and Deployment}} a protocol's designer must balance ossification resistance against observability for operational or research needs.{{sfn|Fairhurst|Perkins|2021|loc=7. Conclusions}} {{harvtxt|Arkko|Hardie|Pauly|Kühlewind|2023}} provides further guidance on these considerations: disclosure of information by a protocol to the network should be intentional,{{sfn|Arkko|Hardie|Pauly|Kühlewind|2023|loc=2.1. Intentional Distribution}} performed with the agreement of both recipient and sender,{{sfn|Arkko|Hardie|Pauly|Kühlewind|2023|loc=2.2. Control of the Distribution of Information}} authenticated to the degree possible and necessary,{{sfn|Arkko|Hardie|Pauly|Kühlewind|2023|loc=2.3. Protecting Information and Authentication}} only acted upon to the degree of its trustworthiness,{{sfn|Arkko|Hardie|Pauly|Kühlewind|2023|loc=2.5. Limiting Impact of Information}} and minimised and provided to a minimum number of entities.{{sfn|Arkko|Hardie|Pauly|Kühlewind|2023|loc=2.4. Minimize Information}}{{sfn|Arkko|Hardie|Pauly|Kühlewind|2023|loc=2.6. Minimum Set of Entities}}

Active use of extension points is required if they are not to ossify.{{sfn|Thomson|Pauly|2021|loc=3. Active Use}} Reducing the number of extension points, documenting invariants that protocol participants can rely on as opposed to incidental details that must not be relied upon, and prompt detection of issues in deployed systems can assist in ensuring active use.{{sfn|Thomson|Pauly|2021|loc=4. Complementary Techniques}} However, even active use may only exercise a narrow portion of the protocol and ossification can still occur in the parts that remain invariant in practice despite theoretical variability.{{sfn|Thomson|Pauly|2021|loc=3.1. Dependency Is Better}}{{sfn|Trammell|Kuehlewind|2019|p=7}} "Greasing" an extension point, where some implementations indicate support for non-existent extensions, can ensure that actually-existent-but-unrecognised extensions are tolerated (cf. [[chaos engineering]]).{{sfn|Thomson|Pauly|2021|loc=3.3. Falsifying Active Use}} [[HTTP headers]] are an example of an extension point that has successfully avoided significant ossification, as participants will generally ignore unrecognised headers.{{sfn|Thomson|Pauly|2021|loc=3.4. Examples of Active Use}}

A new protocol may be designed to mimic the wire image of an existing ossified protocol;{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=623}} alternatively, a new protocol may be to [[encapsulation (networking)|encapsulated]] within an existing, tolerated protocol. A disadvantage of encapsulation is that there is typically overhead and redundant work (e.g., outer checksums made redundant by inner integrity checks).{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=623-4}}

Besides middleboxes, other sources of ossification can also be resisted. [[User-space]] implementation of protocols can lead to more rapid evolution. If the new protocol is encapsulated in UDP, then user-space implementation is possible.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=630}}{{sfn|Corbet|2016}} Where support for protocols is uncertain, participants may simultaneously try alternative protocols, at the cost of increasing the amount of data sent.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=629}}

Line 55 ⟶ 58:

* [[Forward compatibility]]

* [[Interoperability]]

* [[Hyrum's law]]

* [[Network effect]]

* [[Robustness principle]]

* [[Vendor lock-in]]

Line 70 ⟶ 75:

* {{ cite ietf | rfc = 9170 | title = Long-Term Viability of Protocol Extension Mechanisms | date = December 2021 | last1 = Thomson | first1 = Martin | last2 = Pauly | first2 = Tommy }}

* {{ cite ietf | rfc = 9308 | title = Applicability of the QUIC Transport Protocol | date = September 2022 | last1 = Kühlewind | first1 = Mirja | last2 = Trammell | first2 = Brian }}

* {{ cite ietf | rfc = 9419 | title = Considerations on Application - Network Collaboration Using Path Signals | date = July 2023 | last1 = Arkko | first1 = Jari | last2 = Hardie | first2 = Ted | last3 = Pauly | first3 = Tommy | last4 = Kühlewind | first4 = Mirja }}

* {{ cite conference | doi = 10.1145/2068816.2068834 | title = Is It Still Possible to Extend TCP? | date = 2011 | conference = 2011 ACM SIGCOMM Conference on Internet Measurement | last1 = Honda | first1 = Michio | last2 = Nishida | first2 = Yoshifumi | last3 = Raiciu | first3 = Costin | last4 = Greenhalgh | first4 = Adam | last5 = Handley | first5 = Mark | authorlink5 = Mark Handley (computer scientist) | last6 = Tokuda | first6 = Hideyuki }}

* {{ cite conference | url = https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu | title = How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP | date = 2012 | conference = 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12) | last1 = Raiciu | first1 = Costin | last2 = Paasch | first2 = Christoph | last3 = Barre | first3 = Sebastien | last4 = Ford | first4 = Alan | last5 = Honda | first5 = Michio | last6 = Duchene | first6 = Fabien | last7 = Bonaventure | first7 = Olivier | last8 = Handley | first8 = Mark | authorlink8 = Mark Handley (computer scientist) }}

* {{ cite conference | doi = 10.1145/2535828.2535830 | title = Are TCP extensions middlebox-proof? | date = 2013 | conference = HotMiddlebox '13 | last1 = Hesmans | first1 = Benjamin | last2 = Duchene | first2 = Fabien | last3 = Paasch | first3 = Christoph | last4 = Detal | first4 = Gregory | last5 = Bonaventure | first5 = Olivier | citeseerx = 10.1.1.679.6364 }}

* {{ cite web | url = https://lwn.net/Articles/667059/ | title = Checksum offloads and protocol ossification | date = 8 December 2015 | last = Corbet | first = Jonathan | work = [[LWN.net]] }}

* {{ cite web | url = https://lwn.net/Articles/691887/ | title = Transport-level protocols in user space | date = 20 June 2016 | last = Corbet | first = Jonathan | work = [[LWN.net]] }}

* {{ cite conference | doi = 10.1145/2959424.2959443 | title = Implementing Real-Time Transport Services over an Ossified Network | date = July 2016 | conference = 2016 Applied Networking Research Workshop | last1 = McQuistin | first1 = Stephen | last2 = Perkins | first2 = Colin | last3 = Fayed | first3 = Marwan | hdl = 1893/26111 | hdl-access = free }}

* {{ cite journal | doi = 10.1109/COMST.2016.2626780 | title = De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives | date = 2017 | journal = [[IEEE Communications Surveys & Tutorials]] | last1 = Papastergiou | first1 = Giorgos | last2 = Fairhurst | first2 = Gorry | last3 = Ros | first3 = David | last4 = Brunstrom | first4 = Anna | last5 = Grinnemo | first5 = Karl-Johan | last6 = Hurtig | first6 = Per | last7 = Khademi | first7 = Naeem | last8 = Tüxen | first8 = Michael | last9 = Welzl | first9 = Michael | last10 = Damjanovic | first10 = Dragana | last11 = Mangiante | first11 = Simone | volume = 19 | pages = 619–639 | hdl = 2164/8317 | s2cid = 1846371 | hdl-access = free }}

* {{Cite web|url=https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/|title=Why TLS 1.3 isn't in browsers yet|date=2017-12-26|website=The Cloudflare Blog|language=en|access-date=2020-03-14|last = Sullivan | first = Nick }}

* {{ cite journal | doi = 10.1145/3211852.3211861 | title = Ex Uno Pluria: The Service-Infrastructure Cycle, Ossification, and the Fragmentation of the Internet | date = January 2018 | last = Ammar | first = Mostafa | journal = [[ACM SIGCOMM Comput. Commun. Rev.]] | s2cid = 12169344 }}

* {{ cite web | url = https://lwn.net/Articles/745590/ | title = QUIC as a solution to protocol ossification | date = 29 January 2018 | last = Corbet | first = Jonathan | work = [[LWN.net]] }}

* {{ cite conference | doi = 10.23919/TMA.2019.8784690 | title = A Bottom-Up Investigation of the Transport-Layer Ossification | date = 2019 | conference = 2019 Network Traffic Measurement and Analysis Conference (TMA) | last1 = Edeline | first1 = Korian | last2 = Donnet | first2 = Benoit }}