Flexible Anonymous Network

Florentin Rochet; Olivier Bonaventure; Olivier Pereira

arxiv: 1906.11520 · v1 · pith:WT7GCYDUnew · submitted 2019-06-27 · 💻 cs.CR

Flexible Anonymous Network

Florentin Rochet , Olivier Bonaventure , Olivier Pereira This is my paper

Pith reviewed 2026-05-25 14:50 UTC · model grok-4.3

classification 💻 cs.CR

keywords robustness principlePostel's lawprotocol securitysoftware architecturenetwork flexibilityauthentic evolutionanonymous networks

0 comments

The pith

A software architecture can deliver the robustness principle's flexibility while restricting it to authentic protocol evolution only.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper reexamines Postel's law, which tells protocol implementations to be tolerant of what they receive, and asks how that tolerance can be kept without creating security holes. It proposes defining a software architecture that keeps network services running across differing software versions yet confines the tolerance strictly to genuine updates of the protocol specification. A reader would care because the same tolerance that makes the internet work also lets attackers send malformed messages that current designs must accept. The architecture is meant to unify flexibility across specifications, designs, and code while adding an enforcement layer that blocks exploitative use.

Core claim

The authors argue that a software architecture can be defined to retain the benefits of the robustness principle—efficient network operation despite varied software versions—while guaranteeing that this tolerance is used solely to support authentic evolution of the protocol specification rather than being exploited.

What carries the argument

A software architecture that enforces distinction between authentic protocol evolution and exploitative uses of robustness tolerance.

If this is right

Network services continue to function when multiple software versions coexist.
Protocol evolution remains possible without opening avenues for attack through excessive tolerance.
Flexibility across specifications, designs, and implementations is preserved under a single controlled mechanism.
Security requirements are met by design rather than added after the fact.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same mechanism could be applied to anonymous communication systems to allow updates without leaking identifying information through version-specific behavior.
If the distinction works, it suggests a general pattern for making other tolerance-based systems, such as parsers or configuration loaders, resistant to misuse.
Real-world testing would require concrete rules for what counts as an authentic evolution, which the paper leaves open.

Load-bearing premise

A software architecture can be built that reliably identifies and permits only authentic protocol specification changes while blocking all other uses of implementation tolerance.

What would settle it

Build and deploy a prototype of the architecture for an existing protocol such as TCP or Tor and observe whether it accepts only documented specification updates while rejecting malformed inputs that exploit tolerance.

Figures

Figures reproduced from arXiv: 1906.11520 by Florentin Rochet, Olivier Bonaventure, Olivier Pereira.

**Figure 1.** Figure 1: Protocol plugin lifecycle Protocol Plugins are, in our design, embedded in Tor’s critical path when handling data cells and would be called for any protocol operation that would not follow the native implementation. We distinguish between the operations handled by the native code which each relay runs, depending on their Tor version, and the operations handled by protocol plug-ins as default operations a… view at source ↗

read the original abstract

Internet technologies have been designed from guidelines like the robustness principle also known as Postel's law. Jon Postel's law is described as: "Be conservative in what you do, be liberal in what you accept from others." Fundamentally, it advises protocol designs to be tolerant with what they accept from the other peers. We propose to take a step back and wonder how the robustness principle could be revisited to support security requirements as well as unifying flexibility from specifications, protocol design and software implementations. Our goal would be to define a software architecture that offers the benefits of the robustness principle (i.e., efficient network services despite the presence of various software versions), while also guaranteeing that this robustness cannot be exploited by making sure that it is only used to support authentic evolution of the protocol specification.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

This is a short position paper that flags a tension between robustness and security in anonymous networks but offers no architecture, mechanisms, or argument to resolve it.

read the letter

The main takeaway is that the authors want to adapt Postel's robustness principle so flexibility in anonymous networks only supports genuine protocol evolution and cannot be turned into an attack vector. They frame this as unifying flexibility across specifications, design, and implementations, with the goal of a software architecture that preserves interoperability while blocking exploitation. That framing is the only real novelty here, and it is modest; the underlying tension has been discussed in protocol work for years, though applying it specifically to anonymity systems is a reasonable angle. The paper states the problem cleanly and correctly notes that tolerance for variant implementations can create security issues in privacy-focused networks. Beyond that, there is little substance. The central claim—that an architecture can reliably enforce the distinction between authentic evolution and exploitative use—is simply asserted in the abstract with no design sketch, no negotiation protocol, no cryptographic approach, no informal invariant, and no discussion of how an implementation would make the call in practice. No examples, edge cases, or feasibility argument appear. This leaves the proposal at the level of a goal statement rather than a contribution that can be evaluated or built upon. The work is aimed at researchers already working on long-term maintenance of systems like Tor who might want a prompt for their own thinking. It does not contain results, data, or a concrete proposal that would support citation or further development. I would not bring it to reading group unless the group is explicitly collecting position pieces on protocol evolution. I would not cite it. It does not seem ready for peer review in a standard venue because there is no design or evidence for referees to assess; a short workshop position note might be a better fit if the venue accepts that format.

Referee Report

1 major / 1 minor

Summary. The manuscript proposes revisiting Postel's robustness principle to support security requirements in Internet protocols. It aims to define a software architecture that retains the benefits of tolerance to variant implementations (efficient services despite different software versions) while ensuring this flexibility supports only authentic evolution of the protocol specification and cannot be exploited.

Significance. A concrete architecture achieving the stated separation between authentic evolution and exploitative use of robustness would be significant for protocol design and security. The manuscript, however, contains no design, mechanisms, invariants, or analysis to indicate that the required distinction is achievable.

major comments (1)

[Abstract] Abstract (and full text): the central claim is that a software architecture can be defined to guarantee robustness is used only for authentic evolution. No mechanism, cryptographic primitive, negotiation protocol, or even informal invariant is provided that would allow an implementation to decide authentic vs. exploitative input while preserving interoperability. This absence is load-bearing for the stated goal.

minor comments (1)

The title 'Flexible Anonymous Network' does not match the manuscript content, which addresses the robustness principle rather than anonymity or anonymous networks.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the detailed review. The manuscript is a position paper that articulates a goal for revisiting Postel's robustness principle to incorporate security constraints on protocol evolution. It does not claim to deliver a concrete architecture or mechanisms. We address the major comment below.

read point-by-point responses

Referee: [Abstract] Abstract (and full text): the central claim is that a software architecture can be defined to guarantee robustness is used only for authentic evolution. No mechanism, cryptographic primitive, negotiation protocol, or even informal invariant is provided that would allow an implementation to decide authentic vs. exploitative input while preserving interoperability. This absence is load-bearing for the stated goal.

Authors: The manuscript states a goal ('Our goal would be to define a software architecture...') rather than asserting that such an architecture has been defined or that the authentic-vs-exploitative distinction is currently achievable. No mechanisms, primitives, or invariants are supplied because the contribution is conceptual: to motivate the need for an architecture that preserves interoperability benefits while preventing exploitation of robustness. We acknowledge that the paper contains no design or analysis that would allow an implementation to make the required distinction. If the editor concurs, we will revise the abstract and introduction to explicitly frame the work as a position paper whose detailed realization is left to future research. revision: yes

Circularity Check

0 steps flagged

No derivation chain present; conceptual proposal only

full rationale

The manuscript states a high-level goal of defining a software architecture that preserves robustness benefits while restricting it to authentic protocol evolution. No equations, fitted parameters, predictions, self-citations, or uniqueness theorems appear in the abstract or described content. The claim is aspirational and supplies no mechanism or derivation that could reduce to its own inputs. Therefore no load-bearing step exists to analyze for circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The paper is a conceptual proposal and does not introduce or rely on specific free parameters, axioms, or invented entities in the abstract.

pith-pipeline@v0.9.0 · 5649 in / 1092 out tokens · 29374 ms · 2026-05-25T14:50:41.074559+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

10 extracted references · 10 canonical work pages

[1]

Be conservative in what you do, be liberal in what you accept from others

REVISITING PROTOCOL FLEXIBILITY Internet technologies have been designed from guidelines like the robustness principle also known as Postel’s law [1] . Jon Postel’s law is described as: “Be conservative in what you do, be liberal in what you accept from others.” Fun- damentally, it advises protocol designs to be tolerant with what they accept from the oth...

work page
[2]

Protocol Plugins

FLEXIBLE ANONYMOUS NETWOK We call F AN, for Flexible Anonymous Network, an anony- mous network architecture able to transparently change its behavior for one or many users without having to restart relays or perturbing other user connections while proceed- ing to add, remove or modify protocol features. A F AN is achieved using what we call “Protocol Plug...

work page
[3]

We design Protocol Plugins from high-level languages such as C or Rust and we target a bytecode representation of a conceptual machine using the LL VM compiler Clang

PROTOCOL PLUGINS We suggest redesigning anonymous communication imple- mentations such as Tor to make them ﬂexible through Pro- tocol Plugins, which are pieces of code that are executed inside a userland VM (yet with comparable performance to native execution) in response to a particular event. We design Protocol Plugins from high-level languages such as ...

work page
[4]

A NEW PARADIGM? Anonymous communications is one of many ﬁeds that could beneﬁt from protocol plugins. Protocol plugins may serve other goals, such as advancing the arm race in censor- ship resistance (e.g., exploring how an authorized protoco l or application could hide another protocol from the cen- sor through plugins), advancing deployment’s speed of n...

work page
[5]

https://tools.ietf.org/html/rfc793, September 1981

Transmission control protocol. https://tools.ietf.org/html/rfc793, September 1981

work page 1981
[6]

https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack ,

Relay early conﬁrmation attack. https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack ,

work page
[7]

Accessed: 2018-05-02

work page 2018
[8]

De Coninck, F

Q. De Coninck, F. Michel, M. Piraux, F. Rochet, T. Given-Wilson, A. Legay, O. Pereira, and O. Bonaventure. Pluginizing QUIC. In K. Winstein and X. Jin, editors, Proceedings of the 2019 Conference of the ACM Special Interest Group on Data Communication, SIGCOMM 2019, Beijing, China, August 19-24, 2019 . ACM, 2019

work page 2019
[9]

Rochet and O

F. Rochet and O. Pereira. Dropping on the edge: Flexibili ty and traﬃc conﬁrmation in onion routing protocols. Proceedings on Privacy Enhancing Technologies , 2018(2):27–46, 2018

work page 2018
[10]

Samuel, N

J. Samuel, N. Mathewson, J. Cappos, and R. Dingledine. Survivable key compromise in software update systems. In Proceedings of the 17th ACM conference on Computer and communications security, pages 61–72. ACM, 2010

work page 2010

[1] [1]

Be conservative in what you do, be liberal in what you accept from others

REVISITING PROTOCOL FLEXIBILITY Internet technologies have been designed from guidelines like the robustness principle also known as Postel’s law [1] . Jon Postel’s law is described as: “Be conservative in what you do, be liberal in what you accept from others.” Fun- damentally, it advises protocol designs to be tolerant with what they accept from the oth...

work page

[2] [2]

Protocol Plugins

FLEXIBLE ANONYMOUS NETWOK We call F AN, for Flexible Anonymous Network, an anony- mous network architecture able to transparently change its behavior for one or many users without having to restart relays or perturbing other user connections while proceed- ing to add, remove or modify protocol features. A F AN is achieved using what we call “Protocol Plug...

work page

[3] [3]

We design Protocol Plugins from high-level languages such as C or Rust and we target a bytecode representation of a conceptual machine using the LL VM compiler Clang

PROTOCOL PLUGINS We suggest redesigning anonymous communication imple- mentations such as Tor to make them ﬂexible through Pro- tocol Plugins, which are pieces of code that are executed inside a userland VM (yet with comparable performance to native execution) in response to a particular event. We design Protocol Plugins from high-level languages such as ...

work page

[4] [4]

A NEW PARADIGM? Anonymous communications is one of many ﬁeds that could beneﬁt from protocol plugins. Protocol plugins may serve other goals, such as advancing the arm race in censor- ship resistance (e.g., exploring how an authorized protoco l or application could hide another protocol from the cen- sor through plugins), advancing deployment’s speed of n...

work page

[5] [5]

https://tools.ietf.org/html/rfc793, September 1981

Transmission control protocol. https://tools.ietf.org/html/rfc793, September 1981

work page 1981

[6] [6]

https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack ,

Relay early conﬁrmation attack. https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack ,

work page

[7] [7]

Accessed: 2018-05-02

work page 2018

[8] [8]

De Coninck, F

Q. De Coninck, F. Michel, M. Piraux, F. Rochet, T. Given-Wilson, A. Legay, O. Pereira, and O. Bonaventure. Pluginizing QUIC. In K. Winstein and X. Jin, editors, Proceedings of the 2019 Conference of the ACM Special Interest Group on Data Communication, SIGCOMM 2019, Beijing, China, August 19-24, 2019 . ACM, 2019

work page 2019

[9] [9]

Rochet and O

F. Rochet and O. Pereira. Dropping on the edge: Flexibili ty and traﬃc conﬁrmation in onion routing protocols. Proceedings on Privacy Enhancing Technologies , 2018(2):27–46, 2018

work page 2018

[10] [10]

Samuel, N

J. Samuel, N. Mathewson, J. Cappos, and R. Dingledine. Survivable key compromise in software update systems. In Proceedings of the 17th ACM conference on Computer and communications security, pages 61–72. ACM, 2010

work page 2010