Summary

  • RFC 5920 treats a provider's MPLS or GMPLS core as its trusted zone and an inter-provider peer as potentially authorized but still untrusted.
  • Authentication can identify the peer, but it does not authorize every protocol, route, label, reservation or OAM action that the peer could send.
  • The durable operating model grants selected exchanges at the ASBR boundary and preserves filtering, rate limits, monitoring and disconnection authority on each side.

The peering agreement does not move the boundary

A commercial and technical agreement answers one question: may these two networks exchange a defined service? It does not answer a broader one: may either network rely on all behavior originating inside the other? RFC 5920 locates each provider's trusted-zone boundary at its own ASBRs. In its reference model, another provider can be a known and authorized neighbor while remaining outside that zone.

This separation matters because interconnection creates a path for both value and failure. Customers gain reach across domains. Providers gain the ability to assemble services that neither could deliver alone. The same path can carry malformed control traffic, excessive requests, spoofed updates, incorrect cross-connections or resource pressure. A defect or compromise in one peer can therefore become an exposure in the other without either party having intended to delegate internal authority.

The label itself does not close this gap. RFC 5920 notes that an MPLS label is locally meaningful and that the MPLS data plane does not carry a source identifier suitable for authenticating the sender. A packet arriving with a plausible label is not proof that its origin, purpose or requested treatment is legitimate. Identity must be established through the appropriate control or management mechanism, and permission must still be evaluated against the interconnect policy.

Identity, permission and trust are three different controls

Authentication narrows uncertainty about who sent a control message. That is valuable, but it is only the first decision. Authorization determines whether that identified peer may use a particular protocol, establish a particular class of LSP, originate a route, send OAM, reserve bandwidth or consume a defined amount of processing capacity. Trust is broader: it expresses how much unchecked behavior the receiving network is prepared to accept.

Collapsing these layers creates silent authority. If an authenticated session is treated as permission for every message it can technically carry, protocol capability becomes governance. If an authorized service is treated as evidence that the peer's entire core is trustworthy, the peering edge stops being an effective boundary. RFC 5920's model points in the opposite direction: permit the relationship while retaining controls over sources, protocols, rates and resources.

That control set is deliberately plural. The framework discusses session authentication, routing policy, inbound and outbound filtering, malformed-packet handling, per-interface or per-provider rate limiting, protocol enablement and monitoring. No single mechanism proves the whole relationship safe. Cryptography can protect identity and integrity, yet the RFC warns that it does not prevent every CPU- or bandwidth-exhaustion attack and may itself consume resources. Filtering constrains traffic but can also block legitimate recovery. Rate limits preserve capacity but can turn a surge into a service failure.

These are governed trade-offs, not a checkbox.

Benefits and costs land on different parties

Customers benefit when cross-provider paths are available and predictable. Each provider benefits from broader reach and shared service delivery. Yet the cost of preserving the boundary sits mainly with the operators of the two ASBRs: key management, configuration review, capacity reservation, telemetry, incident exercises and the risk of false positives. A restrictive filter may protect the core while interrupting a customer's circuit. A permissive profile may preserve continuity while letting an unexpected message consume control-plane attention.

The incentive mismatch is therefore structural. The sender benefits when its request is accepted quickly; the receiver bears the immediate risk of processing it. A bilateral agreement should make that asymmetry visible. It should state which protocol families are enabled, which objects and rates are acceptable, how changes are approved, what evidence is retained, and who may isolate the link. Authentication confirms the counterparty; it does not settle these operating choices.

The counterfactual clarifies the authority being granted

Without the interconnect, this particular boundary exposure disappears, but so does the cross-provider service. That is not a realistic answer when customers need the reach. The useful counterfactual is an interconnect that treats authorization as trust. It may work in quiet conditions, yet a peer error or compromise is more readily converted into internal state, resource exhaustion or a wider outage.

The authorized-but-untrusted model preserves the service while refusing that conversion. It asks the receiving provider to admit only the traffic and state needed for the agreed purpose, observe deviations and retain the ability to contain them. The peer is not an adversary by definition. It is a separate authority whose internal controls cannot be substituted for the receiver's own duty of care.

Evidence and limits

The protocol and security facts here come from RFC 5920, with RFC 5921 providing MPLS-TP architectural context and RFC 5718 marking the boundary with the preceding in-band management-channel briefing. RFC 5920 is Informational. Its descriptions of trust zones, authorized neighbors, threats and defensive capabilities are source facts; the responsibility map and change-control recommendations are Elias Ward's analysis.

No allegation is made about a provider, vendor or live network. The sources do not establish current adoption, a named operator's configuration, incident frequency, the effectiveness of any deployed control or a currently preferred cryptographic suite. Those remain unknown without contemporary operational evidence.

Sources