]> none

ebrahimi.arash@yahoo.com

The Universal Modular Protocol (UMP) proposes a modular approach to application-layer communication. Instead of implementing every protocol feature in a monolithic protocol or application, UMP allows communication behavior to be composed from modules that can be obtained from a peer or a repository. A protocol engine manages module execution, communication, signatures, and resource restrictions. Modules execute in a WebAssembly sandbox, while the Protocol Description Language (PDL) is intended to support module composition and analysis. UMP is designed to reduce the effort required to introduce new protocol features, reuse protocol components, and connect applications that otherwise require protocol-specific integration. This document describes the motivation, module model, protocol operation, PDL, repositories, and current implementation status of UMP.

Introduction The Universal Modular Protocol (UMP) is based on a modular approach to communication. Modules can be transferred between the two endpoints of a communication channel. If an endpoint does not have a required module, the endpoints can exchange the module package or use a repository address to obtain it. UMP is intended to support communication with the minimum number of modules installed at both endpoints. In its minimal configuration, no modules are required. UMP is intended to operate at multiple layers of the OSI model, from Layer 2 through Layer 7; this document describes its use at Layer 7. The approach is intended to let protocol functionality grow horizontally through composable modules. The Layer 7 design is based on UDP and adds a UMP header to the UDP payload. The header is expected to contain fields such as a magic value and protocol version. With no modules configured, the design aims to keep the protocol engine's behavior minimal.

Problems with Current Protocols

Time and Effort Required to Adopt New Ideas Adopting a new idea and completing the required specification work can take a long time, reducing contributions from individuals and companies. A person or organization may have a useful idea but decide not to publish it because of the effort required to implement and deploy it. A new security or privacy feature, for example, often has to be implemented as a new protocol or added to an existing one. Updating an established protocol may require coordination with the people or organizations responsible for it, particularly when it is widely deployed. As a result, a substantial amount of time can pass between proposing an idea and using it in real systems. A related problem occurs when a new security or privacy feature is itself implemented as a protocol. Integrating that feature with an existing protocol, such as AMQP, may require changes to the existing protocol or its implementations. A developer who did not design or develop the existing protocol may not be able to integrate the new feature without depending on changes outside their control.

Duplication Across Protocols Different communication protocols sometimes share components or concepts. When these components are duplicated, multiple specifications and implementations must be reviewed and maintained. Duplication can also increase code size and resource consumption, which is especially significant on constrained systems such as embedded IoT devices.

The Cost of Updating Legacy Software When legacy software uses a particular communication protocol, adopting a newer version or a different protocol may require updating the software. Such updates consume time and money. Developers maintaining software must also track protocol-version changes, which requires expertise and additional work that organizations may prefer to avoid.

Differences Between Protocol Implementations There is no single organization that controls every implementation of a protocol in every real-world deployment. Different individuals and companies can implement the same protocol independently, and the resulting implementations may differ in behavior, security, or completeness.

Difficulty Connecting Independent Applications Two independently developed applications generally cannot communicate directly unless they support a compatible protocol. Otherwise, an intermediary bridge may be required to translate between protocols supported by the applications. Such a bridge adds complexity and may require manual configuration by a network administrator.

Limitations on Moving Processes Across Network Nodes Processes cannot generally move to another network node to use available or more powerful computing resources without additional supporting software. A solution may require an agent to be installed and supported on every participating platform, and the relevant machines must be accessible within the network's policies.

Limited Opportunities to Optimize Existing Protocols Improving the performance or security of an existing protocol usually requires working with its existing design and implementation complexity. Even when an optimization is intended only for a particular network or set of applications, implementing it may require specialist knowledge. Consequently, many deployments use generally available implementations tuned for broad use cases rather than for their own needs, and therefore are not working at their optimum performance.

Security of Protocol Designs and Implementations Protocol implementations are not always secure, and implementations may require independent review. In addition, a protocol design can itself contain security weaknesses, regardless of the quality of a particular implementation.

Goals of UMP

Reducing the Adoption Cycle UMP aims to reduce the need to implement every new protocol feature as a separate, monolithic protocol. The intended result is a shorter path from an idea to implementation and deployment, encouraging wider participation in protocol development.

Sharing Protocol Components UMP allows protocol functionality to be divided into reusable modules. Reuse is intended to reduce duplicated specification document, implementation effort, development time, cost, and code size. A protocol engine may use cache-eviction policies to remove modules that are no longer needed when memory is limited.

Adapting to Supported Modules UMP aims to let endpoints use supported modules without requiring every application to be updated whenever a protocol changes. The intended benefit is that applications can gain supported functionality through the protocol engine, subject to module availability, compatibility, and local policy.

A Small and Verifiable Protocol Engine UMP places common execution and security responsibilities in a protocol engine. The engine is intended to be small enough to be able to be reviewed and verified itself. Engine enforces common execution restrictions on modules.

Reducing the Need for Protocol Bridges By allowing endpoints to compose communication behavior from modules, UMP aims to remove the need for separate protocol-translation bridges. This may reduce complexity and latency where compatible modules are available at both endpoints.

Using Network Resources UMP's sandboxed execution model is intended to support controlled use of processing resources available on participating network nodes. Any such use remains subject to endpoint policy and resource restrictions.

Composing Protocols from Smaller Modules Smaller modules are intended to make protocol functionality easier to inspect, reuse, and combine. UMP aims to let developers compose new behavior from existing modules rather than reimplementing complete protocols.

Using PDL to Support Security Analysis PDL is intended to let the compiler check module syntax and semantics and verify its security and apply specified restrictions to module behavior. The design goal is to make security properties easier to analyze.

Modules A module package contains metadata and code for the Process and Deprocess stages. These names are used because the two stages may be inverses of one another, but they do not necessarily have to be. They may transform data or manage protocol state, so the terms encoder and decoder would not cover all intended uses. The Process and Deprocess binaries are WebAssembly modules executed in a sandbox . Module metadata includes a module identifier, module version, ABI version, protocol version, the Process and Deprocess code, a digital signature, permissions, and dependencies on other modules. A module may be composed from other modules and may share data or coordinate behavior with corresponding functionality at the other endpoint. Module execution and communication are mediated by the protocol engine. A module may also be described in PDL, which is intended to allow the engine to compile and analyze module behavior. PDL and its role in composition are described in Section 6.

Protocol Operation UMP is designed for the application layer and uses UDP as its underlying transport. The design therefore does not require changes to the underlying network structure. This section describes the intended operation when UMP is carried in UDP datagrams. The design follows two principles: the owner of data determines the security applied to that data, and the owner of resources determines the resource quota. PDL is intended to express or enforce security-related requirements, while the protocol engine applies resource limits when executing modules.

Sending and Receiving Data The sender passes data through a module's Process stage. The first packet identifies the required module in its UMP header. When possible, the sender may include some or all of the data in that packet to reduce the number of packets exchanged. The receiver checks the module identifier. If the module is not already available, the receiver checks its cache and, if configured, a repository. If the module is still unavailable, the receiver requests the module package from the sender. After obtaining the package, the receiver verifies its signature. If the package has no signature but contains PDL, the receiver may attempt to compile and sign it according to the engine's configured trust policy. The receiver then passes the data through the module's Deprocess stage and provides the resulting data to the upper-layer application. If receiver fails to verify module may continue process or simply return an error to sender and stop.

Security and Resource Ownership The sender, as the owner of the original data, chooses the module or modules used to apply the intended security protections. The sender may choose a module that does not provide security; UMP does not make the data secure merely by transporting it. The sender controls the resources used to execute Process on its own endpoint and may impose limits such as memory usage and execution time. The receiver similarly controls resources used to execute Deprocess on its endpoint and applies its own limits.

Bidirectional Communication Data sent in the reverse direction is processed according to the module behavior selected by the endpoint sending that data. The endpoints exchange roles for that transmission. Because a receiver may not trust the security choices made by the peer, it may use its own module for outgoing data. In that case, the module identifier-and, if necessary, the module package-must be provided to the other endpoint.

Module Results and Execution Cycles A module returns an array of buffers. The engine sends the buffers to the other endpoint. If the result's pending flag is set, the engine waits for a response, collects the response data, and calls the module again. This cycle continues until the pending flag is cleared or the execution-time limit is reached. The result also identifies whether the buffers are for negotiation or internal communication between peers, or represent the final payload. This distinction allows a module to exchange information with the peer before producing the final application data.

Module Composition A complete protocol, such as TCP, could be implemented as a single module. However, one goal of UMP is to reduce duplicated code by composing protocols from smaller modules that can be reused across different protocols. A module may therefore act as a composer that invokes other modules or primitives. Module metadata contains a dependency list, which the engine uses to locate required module packages in its cache, a repository, or from the peer. An optional Composer component may accept a graph of modules and create a composite module package expressed in PDL, preserving the relationships represented in the graph. It may also accept an ordered list of modules and create a composite module that executes them as a pipeline.

Resource Restrictions and Scheduling Modules have limited access to resources, such as execution time and persistent storage. They cannot perform I/O directly on peripherals. The engine is responsible for interacting with UDP and scheduling packet transmission to the other endpoint. In this respect, the engine is intended to provide some functions similar to those of a small operating system.

Protocol Description Language (PDL) PDL is intended to let the engine analyze and compile modules that provide a PDL description. A module without PDL must have been verified by a trusted third party and assigned a digital signature. When PDL is present, the engine may compile and analyze the module and, under its trust policy, sign the resulting package for later verification. A peer or a repository client may then verify the signature without recompiling the module, provided it trusts the signing engine and its signing policy. Encryption primitives are intended to be part of the language and may be extended through language versions or digitally signed libraries supplied by trusted parties. A trusted party may also verify protocol engines and sign them to indicate that they implement the required rules for module verification, signing, and resource enforcement. This approach is intended to avoid requiring a trusted third party to review every module individually. The PDL compiler is responsible for syntax and semantic checks and for compiling PDL to WebAssembly. The intended semantic checks include ensuring that outgoing data has passed through the encryption primitives required by the language's policy. The language may also enforce other behavior related to timing, buffering, and similar concerns. These are design goals; their effectiveness depends on the language specification, compiler correctness, engine implementation, and the trust placed in those components. PDL may also provide mechanisms for allocating smaller memory regions within memory made available to a module. The design favors compilation over interpretation for performance. It also aims to avoid garbage collection by using explicit memory ownership and ownership transfer to reduce memory-management errors.

Repositories Any party may operate a repository that stores modules locally or on the web. Repository-management software is expected to support the storage and exchange of module packages. Repositories are not responsible for enforcing module security, because a repository is not assumed to be trusted. Endpoints must apply their own verification and execution policies to modules obtained from repositories.

Security Considerations UMP introduces security considerations associated with downloading and executing code supplied by peers or repositories. A module package must be treated as untrusted until it has been validated according to the receiving endpoint's policy. A repository's availability of a package does not establish that the package is safe or trustworthy. The protocol engine is a critical security boundary. Its implementation must correctly validate module metadata and signatures, enforce permissions and dependencies, isolate module execution, limit resource consumption, and mediate network I/O. A defect in the engine, runtime, compiler, or sandbox could undermine these protections. Resource limits reduce some denial-of-service risks but do not eliminate all risks, including risks caused by excessive network traffic, repeated module transfers, or expensive validation. The design relies on a clear trust policy for signatures and for engines permitted to compile and sign PDL modules. An endpoint must not treat a signature as proof of safety unless it trusts the signing identity and the process used to produce the signed package. Key provisioning, revocation, signature algorithms, and the policy for trusting signed modules require further specification. The proposal intends PDL to support security analysis and to require specified encryption primitives for outgoing data. Such checks do not, by themselves, prove that a protocol is secure. Security depends on the precise language semantics, compiler implementation, cryptographic primitives, module composition, and endpoint configuration. Because modules may exchange data and coordinate with peer modules, implementations also need well-defined rules for data ownership, information sharing, module identity, dependency resolution, and the handling of malformed or unexpected results. The details of these mechanisms remain areas for specification and implementation work.

IANA Considerations This document has no IANA actions at this time. Any UMP identifiers, header fields, or registries that may require allocation will be specified in a future revision if needed.

Implementation Status UMP is under development. The design and implementation are not yet complete.

References Normative References Informative References World Wide Web Consortium

Acknowledgements This document is an early proposal and does not yet identify additional contributors.

Author's Address Arash Ebrahimi Email: ebrahimi.arash@yahoo.com