]> 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, discouraging 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 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 entities 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 automatically 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 work, implementation effort, development time, costs, and code size. When memory is limited, a protocol engine may use cache-eviction policies to remove modules that are no longer needed and free up memory.

Adapting to Supported Modules and Updates Automatically 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 updated 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 reviewed and verified. The engine enforces common execution restrictions on modules.

Reducing the Need for Protocol Bridges By allowing endpoints to exchange communication behavior from each other, UMP aims to remove the need for separate protocol-translation bridges.

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. This also allows to tune protocols to their most optimum performance by allowing the recomposition of existing 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 and measure the level of security imposed on module behavior, and allow the protocol engine to decide whether to use a module based on its configuration.

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 at least includes a module identifier, module version, ABI version, protocol version, the Process and Deprocess WebAssembly or PDL code or both, 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 whenever a module digital signature is not present.

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 of this protocol engine follows this principle: the possessor of data determines the security applied to that data, and the possessor of processing resources determines the resource quota. PDL is intended to express security-related requirements, while the protocol engine enforces those security-related requirements and 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 the receiver fails to verify the module, it may continue processing or simply return an error to the sender and stop.

Security and Resource Possessor The sender, as the possessor 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. For fast composing modules, 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 micro operating system.

Protocol Description Language (PDL) PDL is intended to let the engine analyze modules and compile PDL into WebAssembly. A module without PDL must contain WebAssembly code that has been verified by a trusted third party and digitally signed. When PDL is present, the protocol engine may compile and analyze the module and, under its trust policy, sign the resulting package for later verification. A peer or repository client may then verify the signature without recompiling the module, provided that it trusts the signing engine and its signing policy. This can improve performance, for example, in local networks. 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. These are design goals; their effectiveness depends on the language specification, compiler correctness, engine implementation, and the trust placed in those components.

Protocol Description Intermediate Language (PDIL) The ideal PDL code syntax and structure should be as compact as possible while retaining all metadata required for analysis by any protocol engine. It should also compile quickly and have as small memory footprint as possible. Alongside caching and signing already compiled WebAssembly by a trusted protocol engine, or a receiver capability to use its own trusted modules, this goal of designing PDL can increase performance too. To keep it compact and make compilation as fast as possible, PDL is transpiled into PDIL. PDIL follows very strict rules. It is case-sensitive, contains no whitespace, follows a specific order, and is designed to be as deterministic as possible to support static analysis. It is not intended to be human-readable; instead, it acts as a compact intermediate language containing all metadata required for compilation to WebAssembly. PDIL is going to develop gradually and any new feature will be added rigorously to not only support above mentioned goals but also does not being able to be accomplished by another feature and make redundancy.

PDL compiler PDL is a high-level language based on PDIL. It is more flexible and human-readable, and it transpiles into PDIL. The protocol engine accepts both PDL and PDIL. For PDL input, the engine first transpiles it into PDIL. For PDIL input, it compiles the code directly into WebAssembly. The PDL compiler is part of the protocol engine and is responsible for compiling PDL or PDIL into WebAssembly and syntax and semantic checks.

Third party PDLs There can be lots of variants of PDLs with their own transpilers created by other parties, that can transpile to proposed PDIL in here. Protocol engine as a default accepts PDIL or PDL specifications proposed in this document. Because PDL is going to be converted to PDIL, any restriction and strict rule that PDL specification in this document has, is because PDIL enforces that the same way it is, and from transpile performance aspect PDL follows as much as possible the PDIL structure and is as much as similar and direct to PDIL while is as flexible and human readable as possible.

PDL Structure PDL semantic checks enforce the language's policy by requiring input data that will be exposed to untrusted environments to pass through the required encryption process. enforces the state machine of Process and Deprocess being in synchronization with each other and individually and also in co communication with each other do not fall in an infinite loop when data is not infinite. enforces that for any real payload data, if there is an encode then there is a corresponding decode mechanism at proper location for the other peer. enforces that timeout checks in both endpoints are according to each other. Encryption enforcement is made upon using encryption primitives or encryption functions made of encryption primitives. Encryption primitives are intended to be part of the language and may be extended through language versions. PDL does not have access to system I/O. It has access only to limited external information, such as system time, and can send and receive data between peers only through the protocol engine. PDL cannot allocate memory directly from upper layer OS; memory must be allocated to it by the protocol engine. The design favors compilation over interpretation for performance. PDL avoids garbage collection by using explicit memory ownership and ownership transfer to reduce memory-management errors. To describe Process and Deprocess together in a human-readable form, PDL contains the source code for both in a single combined description. PDL is based on running inside a state machine. PDL is case sensitive. Users cannot define arbitrary infinite loops; loop conditions are restricted by rules intended to prevent them. Everything is passed by reference. To pass data by copy, the user must call the appropriate reserved keywords. PDL memory is always little-endian similar to WebAssembly specification. The design goal is to make memory allocation strict and deterministic, allowing the compiler to estimate memory growth, to pass as a module meta data to allow protocol engine better know how to deliver memory to module. The design goal is to be deterministic as much as that compiler could be able to assess growth order of loops and iterations and states between two peers. Timeout management is coupled with state decision making. When a state changes from for example Process side to Deprocess side state, Protocol engine checks what states of Process side are addressed from Deprocess state side that jump is going to happen. Then starts a timer for all of those Process side states that new Deprocess state may change to them and check each state's specified time with it, if any of them expires then fails. Only functions with the encoder and decoder operation-limiter directives may modify user-level input data and return the result. Operations performed on the input data by these two functions should be reverses of each other. A PDL source may contain many of these functions. Only functions with the encrypt and decrypt operation-limiter directives must be used for encryption and decryption. Operations performed on the input data by these two functions should be reverses of each other. A PDL source may contain many of these functions. Encryptor functions are only allowed to call encryption primitives or other functions with encrypt directives, and as a fact decypt follows that too but in reverse. If an unencrypted branch of input data merges with encrypted data that will be returned by an encrypt function, compilation fails. The goal is to let the compiler check and verify functions with operation limiter directives being in reverse of each other.

PDL syntax This is a sample of PDL syntax <CODE BEGINS> // This is an inline comment /* This is a block comment */ /* user level input data is accessible as global::input variable user level settings is accessible as global::settings variable user level platform config is accessible as global::info variable */ includes section variables ... user functions declaration section [if it is not called before definition] user functions definition section /* This is an encoder function. keyword encoder indicates that there should be a decoder with the same name. When an encoder function gets called in a state, then the other peer should have call its corresponding decoder. */ function encoder A(buf) { variables ... code ... return // Should return a buffer type variable } /* This is a decoder function. keyword decoder indicates that there should be an encoder with the same name. When a decoder function gets called in a state, then the other peer should have call its corresponding encoder. */ function decoder A(buf) { variables ... code ... return // Should return a buffer type variable } function encrypt TestEncryptor(buf) // This is an encryptor function, for each encryptor there should be a decryptor with the same name { variables ... code ... // every single byte of input buffer before leaving this function should be passed through another encrypt function or encrypt primitive // this also checks merges and forks of input buffer // if input buffer is encrypted but further is merged with a non encrypt version of itself, then compile fails return // Should return an encrypted buffer } function decrypt TestEncryptor(buf) { variables ... code ... return // Should return a decrypted buffer } /* This specifies encryptor function that is going to be used when sending out the data to the other peer, and its complementary counterpart will be used when receiving data. */ encryptor = TestEncryptor /* This is always last function with exact same name. This controls the state machine for both peer at same code. This will be splitted to Process and Deprocess functions after transpile into PDIL. / control() { / P indicates this state is for Process side. label in front of P is state label to refer to. label should be unique in entire of this file. time indicates this state's timeout. */ P:01:time /* D indicates this state is for Deprocess side. label in front of D is state label to refer to. label should be unique in entire of this file. time indicates this state's timeout. */ D:02:time <CODE ENDS> The details of these mechanisms, as well as PDL's structure, syntax, and capabilities, are subject to change and remain areas for specification and implementation work.

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, but their signed modules or modules with PDL can be trusted, if verified by endpoints. Endpoints must apply their own 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 protocol and receiving endpoint's extra policy. 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 possession, 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