Summary

  • RFC 9735 says a Map-Request for the 80-bit DN EID ietf.lisp can validly receive the registered 40-bit DN EID ietf. The result establishes a longest match, not an exact-name registration.
  • AFI 17 encoding, NULL termination, Mask-Len, Instance-ID and use-case syntax determine what was asked and interpreted. Authentication can protect a registration without turning a free-form label into X.509 identity or proving a locator works.
  • A defensible system preserves the received bytes, parsed name, requested and returned lengths, match class, registrar authority, locator set, cache readback, packet observation and application outcome as separate receipts.

The request contained ietf.lisp. Its EID Mask-Len was 80 bits: nine visible characters plus the terminating NULL octet. The Map-Server answered ietf, whose registered length was 40 bits.

Nothing had malfunctioned.

That is the example RFC 9735 uses to explain DN-EID lookup. When a name of the same length is registered, a proxy Map-Server can return an exact match. When only a less-specific name is registered, it returns that registered name and its shorter Mask-Len. The response can therefore be correct even though the question and answer are not the same string.

The mechanism is ordinary longest-match reasoning applied to a variable-length name. The governance hazard appears later, when an application reduces the exchange to a green badge marked “identity found”. The badge has discarded the fact on which accountability depends: what was requested and what authority actually answered are different records.

“Distinguished” does not mean certified

RFC 9735 defines how Address Family Identifier 17, “Distinguished Name”, is carried in LISP Endpoint Identifier and Routing Locator records. LISP already separates EIDs from RLOCs: one names the endpoint side of the relationship; the other describes where packets can be routed. The DN format adds a variable-length, readable representation to either position.

The RFC is unusually direct about a likely category error. Its Distinguished Name has no relationship to the similarly named field in PKIX and X.509. It is not a certificate subject merely because the words sound familiar. A DN can be a resource name, a role label, a street location, a public-key hash representation, a router name or any self-documenting string permitted by the deployment.

That flexibility is useful. It also means semantic authority comes from the surrounding contract: the Instance-ID, use-case grammar, registration admission policy and authenticated principal. The string alone cannot tell an auditor whether it denotes one chassis, a changing pool of gateways, a service class or an operator convenience label.

The wire record comes before the name

AFI 17 is variable length, so the AFI value cannot imply the number of following octets as IPv4 or IPv6 can. RFC 9735 terminates the string with 0x00. For a DN used as an EID, Mask-Len is the string length in bits including that NULL octet. When the DN is nested in an LCAF structure, an explicit octet length may be used, and it too includes the NULL.

This creates several facts that should never be compressed into one text field:

Receipt Narrow claim
received octets the exact field delivered on the wire
declared length or Mask-Len the boundary the message asserted
first-NULL parse the string the implementation interpreted
trailing-octet disposition whether bytes existed after an early NULL and were ignored
Instance-ID and grammar the namespace in which the parsed string has meaning

The RFC requires one NULL at the end, but it also says an implementation may accept an earlier NULL inside an explicitly sized field; if it does, later octets must not form part of the string. It must also accept a NULL immediately after the AFI, which represents the empty string.

These rules do not prove an exploit or an interoperability failure. They prove that “the raw bytes were equal” and “the parsed names were equal” are different questions. A parser-normalized log that retains only the displayed text can no longer show which bytes were ignored, which length was announced or whether two implementations accepted the same boundary.

The returned length is the verdict

The decisive evidence in the RFC’s lookup example is not the attractive label. It is the pair of names and lengths.

The request asks for ietf.lisp at 80 bits. A registered ietf occupies 40 bits because the four visible characters and NULL form five octets. The response returns ietf with 40 bits. The smaller returned Mask-Len says that the mapping system answered from a less-specific registration.

An operator interface should name this result less_specific_match, not exact_identity_found. A decision record should retain at least:

  • requested DN and requested Mask-Len;
  • returned DN and returned Mask-Len;
  • Instance-ID and name-syntax version;
  • exact or less-specific match classification;
  • registration identity, age and admission policy;
  • Map-Server and policy epoch that produced the answer.

This does not make the less-specific answer inferior. A broader registration can be the intended control object, much as a route prefix can intentionally cover more-specific destinations. The error is not using the abstraction. The error is claiming the abstraction established a fact it was designed to leave open.

One name can denote a changing role pool

RFC 9735’s deployment-experience section makes the point operational. Proxy-ETRs can register a common DN that describes their role, each contributing its own locator. The Mapping System aggregates those locators into a shared set. An ingress device can request or subscribe to that DN to discover the current Proxy-ETR pool.

The DN is doing useful coordination work. It is also intentionally not a one-device identity. The same string may refer to several locators today, fewer after a withdrawal and different devices after replacement. A successful lookup proves that the mapping system returned its current registered set for the role. It does not prove that every member still performs the role, that the locators are mutually independent, or that the selected gateway can reach an external destination.

This is where the earlier BTW analysis of external-exit selection begins; it is not where this article ends. The present boundary is one stage earlier: the common role label and the member devices are different objects. An audit must retain the label-to-registration relationship before it can reason about any chosen exit.

Authentication answers who registered, not what happened next

The RFC imports the security considerations of the LISP control plane in RFC 9301 and of LCAF in RFC 8060. Registration authentication matters. It can bind a control message to credentials and allow the Map-Server to enforce who may register in a namespace.

It cannot make a free-form name globally unique. It cannot decide that a registrar was authorized for a different Instance-ID. It cannot prove that a shared role still describes each locator at query time. It cannot show that an ITR installed the reply, selected a working RLOC or delivered a packet.

The useful chain is longer:

Stage What its receipt can establish What remains open
parse accepted bytes became one DN namespace and authority
admission a principal could register this syntax in this Instance-ID current operational truth
lookup a policy returned an exact or less-specific registration cache installation
distribution a reply or notification reached a subscriber forwarding use
readback expected cache state became visible packet path
observation traffic reached a locator application completion
outcome a named service completed a transaction validity for other requests

This is Lu Heng’s Reality Layers applied to a protocol exchange. Symbol, authorized record, running state and observed outcome should join through evidence. They should not be made visually identical because one status field is easier to automate.

Instance-ID is part of the sentence

RFC 9735 recommends a unique Instance-ID for each DN use case. If different uses share an Instance-ID, they must define their own Instance-ID and syntax structure. That recommendation prevents a readable token from acquiring unbounded meaning merely because two teams chose the same characters.

Consider edge. In one namespace it might denote a Proxy-ETR role. In another it might be an onboarding signal. Elsewhere it might label an RLOC for human inspection. A search index that removes Instance-ID and use-case version will merge three separate claims into one apparent identity.

The minimum stable key is therefore not the string. It is something closer to (Instance-ID, use-case, syntax-version, encoded-name, length). The registration principal and policy epoch then say who was allowed to make that claim at that time.

Lu Heng’s Minimum Initial Specification offers the sound design posture: standardize the smallest interoperable object and let later decisions remain local and visible. RFC 9735 standardizes the encoding and lookup behavior. Deployments should resist turning that narrow common layer into one universal naming constitution.

Empty and early-terminated names need observability

The empty DN is syntactically required to be accepted. That does not mean it should silently acquire a production role. Admission policy can reject an empty name for a particular use case, quarantine it, or treat it as an explicitly documented sentinel. What matters is that the implementation distinguish protocol parsing from local authorization.

The same applies to early termination. If a field contains edge\0shadow, and an implementation accepts it under the RFC’s condition, the interpreted name is edge; the trailing bytes are not part of the string. The correct evidence is not merely name=edge. It is parse=accepted_early_null, with raw bytes and declared length preserved under appropriate access controls.

Otherwise two risks arise. First, monitoring may treat differently encoded inputs as identical without knowing it. Second, later incident analysis cannot determine whether a sender, parser, cache and policy engine operated on the same object.

No public claim should be made that a named product mishandles this case without tests. But every implementation can test the boundary: final NULL, early NULL, empty string, length mismatch, non-ASCII input, same displayed name under different Instance-IDs and exact versus less-specific replies.

A notification is still a control-plane receipt

RFC 9437 allows LISP mappings to be distributed through publish/subscribe behavior. That can keep a role pool current without waiting for ordinary lookup cycles. A notification and its acknowledgement are valuable convergence evidence.

They remain control-plane evidence. The subscriber can acknowledge a message before a forwarding table has been updated. A cache can contain the intended locator set while hardware uses older state. A locator can receive encapsulated traffic yet fail beyond decapsulation. The application can fail after the network delivered every packet correctly.

The evidence ladder should therefore be monotonic: later receipts add claims; they do not rewrite earlier receipts into broader ones. A data-plane canary adds reachability to an admitted mapping. It does not retroactively turn a less-specific lookup into an exact match.

Sources

Sources