A county jail facilities team assumes a managed MPLS path inherently encrypts inmate-records traffic between sites. What is the accurate describe-level statement?

A county jail facilities team that assumes a managed MPLS path inherently encrypts inmate-records traffic is mistaken at describe level. MPLS provides label-based forwarding and can separate tenants with VRFs and VPN labels, but label switching does not by itself encrypt payloads. Confidentiality for sensitive jail data requires a separate mechanism such as IPsec (or other crypto overlay/service), applied in addition to—not implied by—MPLS transport.

MPLS always encrypting payloads with AES because labels include a crypto SPI is false. Labels do not embed AES SPIs; SPI belongs to IPsec, not MPLS shim headers.

LDP distributing IPsec keys along with label bindings invents a function LDP does not perform. LDP distributes label bindings; IKEv2/IPsec handle key exchange separately if encryption is required.

PHP providing confidentiality by popping labels before eavesdroppers can read them confuses a forwarding optimization with security. Popping a transport label early does not encrypt or hide IP payload contents from observers on a link.

Exam caveat: provider MPLS may offer isolation and obscurity of internal paths, but obscurity is not encryption. ENARSI and real designs treat IPsec, MACsec, or encrypted WAN services as explicit choices when confidentiality is required for civic records.

Operational check: if policy requires encryption, verify IPsec (or equivalent) SAs and interesting traffic ACLs independently of show mpls ldp neighbor success. Packet captures on a core link should show ciphertext only when crypto is actually configured—not merely because MPLS labels are present.