Summary

  • RFC 8520 lets a limited-purpose device point to a description of the communications it requires. The standard explicitly calls that description a set of suggestions, not directives; the receiving network retains the authority to narrow, reject, ignore or locally instantiate it.
  • A MUD URL, a valid CMS signature and a successfully compiled access list answer different questions. None alone proves the identity, integrity, patch state, admission or benign behaviour of the device instance presenting the URL.
  • A defensible MUD receipt joins URL provenance, signer accountability, device-to-session binding, the local approval and compiler decision, installed enforcement state, exceptions and observed traffic. “MUD verified” is too compressed to be an audit conclusion.

The device arrives with a sentence about its future. It may need DNS and time service. It may contact a named cloud controller. It may accept commands from a local controller and have no legitimate reason to browse the wider Internet. If those limits are accurate, a network can reduce the device's attack surface without first understanding every line of its firmware.

That sentence is valuable precisely because it is small. It is also easy to overread. A device that presents a Manufacturer Usage Description URL has not thereby proved its identity. A signed description has not proved the signer was authorized for that manufacturer. A rule generated from the description has not proved the rule reached the switch. Traffic that matches the description has not proved the device is uncompromised.

RFC 8520, published in 2019, gives this boundary unusually direct language. Eliot Lear is one of its three named authors, with Ralph Droms and Dan Romascanu. The document says that manufacturer statements are “not directives, but suggestions” and that local administrators decide what is appropriate. Lear's contribution is a route into a careful architecture, not a claim that he alone invented MUD or controls the devices, products and networks that implement it.

A URL points to a description; it does not identify the speaker

MUD begins with a URL. A device can emit it through DHCP or LLDP, carry it in an X.509 certificate extension, or acquire an association through another local mechanism. The manager uses the URL to retrieve a JSON description and its signature from a server. The description expresses the communications a device type is designed to have.

The phrase “device type” matters. RFC 8520 says a MUD URL is not intended to be unique to one Thing. Many units of one model can present the same URL. The authority component can classify devices as belonging to a manufacturer class, but it does not name the individual radio, camera, bulb or controller now attached to one access port.

The acquisition channel determines what may safely be inferred. A URL carried inside a validated device certificate can have a stronger relationship to an authenticated identity than the same string announced through unprotected DHCP or LLDP. RFC 8520 warns that a Thing may lie about what it is and gain additional access when the URL is emitted insecurely. It recommends against granting elevated permissions unless identity is strongly bound to L2 and L3 transmissions.

The first receipt must therefore record the URL bytes, acquisition method, interface, session, time and assurance level. A field called mud_url without that provenance discards the difference between a certificate-bound statement and a string any local endpoint could claim.

This is also a privacy boundary. A URL can reveal the manufacturer, model or firmware family and help an observer infer likely vulnerabilities. The same identifier can classify a type without identifying a unique unit, yet still contribute to tracking when combined with a port, MAC address, household or time window. Classification, authentication and identifiability are not the same property.

The file signature protects a recommendation

MUD files affect access lists, so RFC 8520 requires a CMS signature. A manager validates the signature over the file, checks certificate use, builds a chain to a trust anchor and, in some certificate-bound cases, compares the file signer with the mudsigner value carried by the device certificate. Failure stops processing until an administrator approves an exception.

What does success prove? It proves that the retrieved bytes have not changed since an accountable signer signed them, under the trust configuration the manager used. It does not automatically prove that the signer is the device manufacturer. The standard explicitly allows that an integrator or another accountable party may sign, and says accountability for the recommendation can matter more than a simple device-to-file relationship.

That distinction prevents a familiar security shortcut. File integrity answers “whose statement did I receive, according to this certificate chain?” Signer authorization asks “was that party entitled to speak for this model, version and policy namespace?” Device identity asks “which instance is on this authenticated session?” Those checks may share certificates, but they remain separate decisions.

RFC 9238 makes the gap visible through QR codes. A sticker can direct an installer to a MUD URL, but the later RFC warns that the visual presence of a code can create an unjustified impression that a device has been vetted. It also observes that RFC 8520 does not itself define infrastructure to authenticate or authorize MUD-file signers. A neat label is not assurance; neither is a syntactically valid signature without a signer policy.

The signature receipt should preserve file hash, signature hash, signer certificate, trust anchor, validation time, result and the local decision that maps the signer to an allowed manufacturer or integrator scope. If the signer changes, that transition is a policy event, not a routine refresh to hide inside a cache update.

A recommendation becomes policy only through local agency

After validation, the MUD manager interprets abstractions such as manufacturer, same-manufacturer, local networks, controllers and named services. It maps them to the topology and addresses known by the deployment, then generates configuration for switches, access points, firewalls or other enforcement systems.

The manufacturer cannot know every local network. It cannot decide which host is the approved controller in one hospital, which DNS resolver is mandatory in one factory, or which lateral communication an operator will tolerate. RFC 8520 therefore allows the manager to ignore individual components or the entire description. It recommends caution where the file contains concrete IP addresses and limits action vocabulary because publishers lack the local context for richer effects.

This is not a weakness to repair by giving the remote file more authority. It is the control boundary that keeps a recommendation interoperable without making it a command. The manufacturer describes a minimum communication envelope. The administrator bears the local risk and decides how to instantiate, narrow or reject that envelope.

Heng Lu's Minimum Initial Specification offers a useful reading. Shared coordination should standardize the smallest vocabulary needed for voluntary cooperation while leaving future decisions to the parties that face the consequences. MUD supplies a URL, a data model and processing rules. It does not appoint one global policy compiler or force every network to accept one manufacturer's view.

The policy receipt must name the local owner, approval or rejection, accepted file version, exceptions, expiry, compiler and compiler version. It should preserve the generated rule set or a deterministic hash, the topology mappings used for abstractions, and the target enforcement points. Otherwise a later operator cannot tell whether two sites made different legitimate choices or one site silently failed to translate the same recommendation.

A compiled rule is not an installed rule

RFC 8520 augments the generic YANG ACL model defined by RFC 8519. That supplies a common shape for matches and forwarding actions. It does not make every switch understand the same abstraction, accept the same transaction, order rules identically or expose the same counters.

The passage from a MUD file to running configuration has several independent failure points. Name resolution can return a changed address set. A controller class can be empty. The compiler can reject an extension. A target can lack capacity. A transaction can partially commit. Another local policy can take precedence. A later manual change can shadow the generated rule.

A manager that reports “compiled” has proved only that it produced an output. To claim enforcement, the system needs target identity, submitted configuration or hash, transaction identifier, acceptance result, effective rule order and a readback from the enforcement plane. If several switches protect one device path, the receipt needs each one; one successful edge cannot lend its result to another.

Lifecycle also matters. The description carries update and cache information, but expiry of a cache timer does not automatically require the manager to discard the file or disconnect the device. A manufacturer can update its recommendation, a domain can change ownership, a device can update firmware while retaining a fixed certificate URL, or the device can disappear while stale rules remain.

The safe record treats URL epoch, file epoch, local policy epoch and installed rule epoch as separate clocks. A new file should not silently erase the old decision or its observed effects. A disconnected device should release identity-bound state. A changed URL authority deserves validation rather than automatic privilege continuity.

Running traffic is a different witness

Once rules are installed, packets supply evidence about enforcement and behaviour. Permit and drop counters can show whether a rule is exercised. Denied flows can reveal missing manufacturer requirements, stale cloud dependencies, malware, a software update or a local mapping error. Allowed flows can reveal that the policy is wider than expected.

Observed conformance is still not attestation. Malware can use destinations and TLS profiles already permitted to legitimate software. A dormant capability may not appear during the observation window. A compromised controller can remain inside the approved class. A device can be unpatched and still follow its published communication pattern exactly.

RFC 9761 extends MUD so descriptions can include TLS and DTLS profile characteristics. The later work also preserves the boundary: protecting the MUD URL is useful, but a compromised device can expose legitimate software details to malware. Richer description makes some deviations easier to see; it does not turn middlebox observation into proof of internal integrity.

Likewise, deviation does not establish malicious intent. A vendor may have added a service without updating the file. DNS may have moved. The local compiler may have translated a class incorrectly. A temporary recovery endpoint may be legitimate but undocumented. The operational response should therefore classify and investigate deviations rather than silently permit everything or automatically condemn the device.

Heng Lu's running-code lens places the final question in the network itself. A standard, signature and generated policy are coordination artefacts. Whether the intended restriction survives implementation is shown by installed state and traffic under real failures, updates and exceptions. Running evidence does not replace the earlier receipts; it tests what they produced.

NIST's reference build shows the missing joins

NIST SP 1800-15 documents a reference architecture for using MUD to mitigate network-based attacks against small-business and home IoT devices. The guide is valuable because its implementation contains more than a file: discovery, a MUD manager, threat-signalling components, policy enforcement and test scenarios all participate.

That operational example should not be converted into a deployment census. It shows that the standard can be assembled into a working control system under documented conditions. It does not prove universal vendor support, consistent signer governance, identical policy compilation or a security outcome for a product not tested in the build.

The economic effect depends on the joins. A reliable description can lower the cost of writing per-model policy. Reusable abstractions can let one operator govern many device types. But a false sense of attestation can raise risk: procurement may admit a device because it has a URL, operations may trust a green signature badge, and incident teams may ignore traffic that remains inside an overly broad recommendation.

The right measure is not “percentage of devices with MUD”. It is the share of active device sessions with provenance strong enough for the access granted, an authorized and current file, a reviewable local decision, confirmed enforcement coverage and recent behavioural evidence. Each missing join changes the meaning of the percentage.

Lear's record establishes contribution, not jurisdiction

The IETF Datatracker profile reviewed on 31 August 2026 says Eliot Lear has participated in the IETF since 1989 and currently focuses on IoT security and onboarding. It lists him as chair of the Independent Submission Editor group, a member of the RFC Series Approval Board, and a reviewer for the ART Area Review Team and Internet of Things Directorate. It lists 20 RFCs and four active Internet-Drafts.

Those are dated public facts. They may change, and they do not make Lear the operator of any MUD manager. RFC 8520 is collective work by Lear, Droms and Romascanu and an IETF consensus document. RFC 8519, RFC 9238 and RFC 9761 have their own author groups. NIST's practice guide belongs to its documented collaborators. Attribution should follow the evidence rather than collapse later work into one person's biography.

This limit is institutionally useful. A standards author can define a shared interface and explain its security conditions. The manufacturer decides what to recommend. A signer accepts accountability for a file. The device presents an identifier. A network administrator decides what to allow. Enforcement systems apply local state. Observability systems report outcomes. None of those actors can borrow the authority of all the others.

Heng Lu's agency critique helps name the failure: governance goes wrong when one actor's bounded role becomes an excuse to speak for another. A manufacturer recommendation must not become administrator consent. A signature must not become device identity. A standard must not become proof of implementation.

Build one joined receipt, not one green badge

The first part of the receipt concerns the device session. Record instance and authenticated session identifiers, access interface, L2/L3 binding, URL bytes, acquisition mechanism, assurance level and teardown trigger. State whether the URL is model-level or instance-specific. Never infer uniqueness from the URL itself.

The second concerns the recommendation. Preserve retrieval time and result, file bytes or hash, description scope and version, CMS signature, signer certificate, trust anchor, cryptographic validation and the separate decision that the signer is authorized for the claimed namespace. Record a signer or domain-ownership change as an exception requiring review.

The third concerns local authority. Name the policy owner, approval, narrowing or rejection, accepted abstractions, mappings, exceptions, expiry, compiler version and exact generated rules. Preserve why additional access was granted and who may revoke it.

The fourth concerns enforcement. Record target elements, transaction IDs, acceptance and partial-failure results, effective order, configuration readback and counters. For a multi-hop path, show where protection begins and where ungoverned lateral traffic remains possible.

The fifth concerns running evidence. Record permitted and denied flows at a privacy-safe level, anomalies, requested exceptions, last observation time, support and patch status from independent sources, and any separate attestation result. Conformance, patching and attestation need their own fields because MUD does not supply them.

Joined by device session, file epoch, policy epoch, enforcement transaction and time, those records support a precise conclusion: an accountable party recommended a bounded communication pattern; a local authority accepted a particular interpretation; named controls applied it; observed traffic did or did not conform during a stated interval. That is already powerful. Calling it device attestation would make it less accurate and less safe.

Sources