Protocol ossification

Recommended methods of preventing ossification include 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.

[5] QUIC is the first IETF transport protocol to deliberately minimise its wire image to avoid ossification.

[6] The Internet Architecture Board identified design considerations around the exposure of protocol information to network elements as a "developing field" in 2023.

[13] 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.

[16] 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.

[17] Network operators use metadata for a variety of benign management purposes,[18] and Internet research is also informed by data gathered from protocol metadata;[19] a protocol's designer must balance ossification resistance against observability for operational or research needs.

[17] Arkko et al. (2023) provides further guidance on these considerations: disclosure of information by a protocol to the network should be intentional,[20] performed with the agreement of both recipient and sender,[21] authenticated to the degree possible and necessary,[22] only acted upon to the degree of its trustworthiness,[23] and minimised and provided to a minimum number of entities.

[27] 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.

A flag day, where protocol participants make changes in concert, can break the vicious cycle and establish active use.

TLS 1.3, as originally designed, proved undeployable on the Internet: middleboxes had ossified the protocol's version parameter.

[44] QUIC has been specifically designed to be deployable, evolvable and to have anti-ossification properties;[45] it is the first IETF transport protocol to deliberately minimise its wire image for these ends.