Revision as of 09:15, 7 July 2023 edit Polyphemus Goode (talk \| contribs) Extended confirmed users 1,099 edits RFC 9419 ← Previous edit		Revision as of 09:20, 7 July 2023 edit undo Polyphemus Goode (talk \| contribs) Extended confirmed users 1,099 edits fix name Next edit →
Line 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\|~~Paulie~~Pauly\|Kühlewind\|2023\|loc=3. Further Work}} == Causes == Line 30: == 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 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\|~~Paulie~~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\|~~Paulie~~Pauly\|Kühlewind\|2023\|loc=2.1. Intentional Distribution}} performed with the agreement of both recipient and sender,{{sfn\|Arkko\|Hardie\|~~Paulie~~Pauly\|Kühlewind\|2023\|loc=2.2. Control of the Distribution of Information}} authenticated to the degree possible and necessary,{{sfn\|Arkko\|Hardie\|~~Paulie~~Pauly\|Kühlewind\|2023\|loc=2.3. Protecting Information and Authentication}} only acted upon to the degree of its trustworthiness,{{sfn\|Arkko\|Hardie\|~~Paulie~~Pauly\|Kühlewind\|2023\|loc=2.5. Limiting Impact of Information}} and minimised and provided to a minimum number of entities.{{sfn\|Arkko\|Hardie\|~~Paulie~~Pauly\|Kühlewind\|2023\|loc=2.4. Minimize Information}}{{sfn\|Arkko\|Hardie\|~~Paulie~~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}} Line 73: * {{ 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 = ~~Paulie~~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) }}

Protocol ossification: Difference between revisions