If you've ever bought a "MPLS VPN" circuit from a carrier — the kind that connects your Chicago office to your Frankfurt data center as if they were on the same LAN — you've relied on the security model this RFC formalizes. RFC 4381 is not a protocol specification. It is a threat analysis: an argument, aimed at skeptical enterprise security teams in the mid-2000s, that BGP/MPLS IP VPNs (defined in RFC 4364) offer security "comparable to" traditional layer-2 services like Frame Relay and ATM. That was a controversial claim at the time, and the RFC exists because carriers kept losing sales to security officers who said "we don't trust IP."

The problem it addresses. In a BGP/MPLS VPN, hundreds of customers share the same provider backbone. Their packets travel over a common IP/MPLS core, distinguished only by MPLS labels and VPN Route Distinguishers in the provider's BGP tables. From a paranoid customer's viewpoint this looks terrifying: my traffic is one label-swap away from my competitor's. The RFC's job is to walk through, methodically, why that intuition is wrong — provided the provider is not itself hostile or grossly misconfigured.

Key claims and design analysis. Behringer breaks the security question into four properties and evaluates each:

• Address space and routing separation. Each VPN lives in its own VRF (Virtual Routing and Forwarding table) on the PE router. Overlapping RFC 1918 space across customers is fine — the Route Distinguisher makes routes globally unique in BGP, and the VRF keeps forwarding tables disjoint.
• Hiding of the core. Customer packets never see the provider's P routers. MPLS labels are pushed at ingress PE and popped at egress PE; the core's IP addresses are not reachable from the customer VRF. This is why traceroute across an MPLS VPN often shows a suspicious gap — the core is genuinely invisible.
• Resistance to attacks from other VPNs. A customer cannot inject a labeled packet into the core, because PE routers drop labeled packets received on customer-facing interfaces. This is the load-bearing assumption of the entire architecture. Break it and the model collapses.
• Resistance to label spoofing. Same mechanism. Labels are only trusted between P and PE devices inside the trusted core.

What the RFC honestly concedes. This is the interesting part. Behringer explicitly says BGP/MPLS VPNs provide no confidentiality, integrity, or authentication of the data itself. If you need those, you run IPsec on top. The security model is isolation-equivalent to a private circuit, nothing more. He also notes that a compromised or misconfigured PE is catastrophic — one fat-fingered route-target import statement can leak an entire customer's routes into another VPN. The trust boundary is the provider's operational discipline.

Why it still matters. Two decades later, the global carrier VPN market still runs on this model. Every SD-WAN vendor's "underlay" pitch, every hyperscaler's Direct Connect / ExpressRoute / Interconnect offering, and every enterprise MPLS tail circuit rests on the assumptions catalogued here. When cloud providers explain why their VPC isolation is safe, they are echoing this RFC's structure: separation of control plane, separation of forwarding plane, hidden infrastructure, and hardened trust boundaries. It's also a rare example of an RFC written primarily as a persuasive document for procurement committees — which is why it reads more like a whitepaper than a protocol spec.

Historical note. Behringer was a Cisco distinguished engineer, and this document was heavily driven by carrier customers demanding a citeable, standards-track answer to give their auditors. It succeeded: for years, "RFC 4381" was literally the answer on RFP responses to "prove your VPN is secure."