The Juniper PE router must be configured to have each Virtual Routing and Forwarding (VRF) instance bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.

From Juniper Router RTR Security Technical Implementation Guide

Part of SRG-NET-000512-RTR-000005

Associated with: CCI-000366

JUNI-RT-000610_rule The Juniper PE router must be configured to have each Virtual Routing and Forwarding (VRF) instance bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.

Vulnerability discussion

The primary security model for an MPLS VPN infrastructure is traffic separation. Each CE-facing interface can only be associated to one VRF; that alone is the fundamental framework for traffic separation. Once a packet from the connecting CE reaches the PE router, a forwarding decision is made based on the forwarding table belonging to the VRF. The next hop will always point to another PE. As the packet traverses the label-switched path (LSP) between the two PE routers, it is encapsulated with a VPN header - the inner MPLS label mapping to the associated VPN.The provider must guarantee the customer that data plane and control plane traffic from one VPN does not leak into another VPN or into the core, and that core traffic must not leak into any VPN. There is, however, the possibility of providing customer interconnections as well as the construction of an extranet to provide customers the ability to share common resources. Nevertheless, assuming correct operation and configuration of the MPLS core, the principles of separation prevail: VPNs are fully separated from each other so that intrusion from other VPNs or the core cannot occur. However, it is obvious that the greatest threat to the security model is human engineering; that is, misconfiguration of PE routers. For example, a customer-facing interface could be associated with the wrong VRF, prohibiting that site access to its proper VPN while providing access to another and vice versa.

Check content

Review the design plan for deploying L3VPN and VRF-lite. Review all CE-facing interfaces and verify that the proper VRF is defined. The example below depicts the CE-facing interface ge-0/1/0 bound to VRF titled L3VPN_CUST1. Notice that the PE router is peering OSPF with the CE router. interfaces { … … … } ge-0/1/0 { description "link to Customer 1"; unit 0 { family inet { address 101.3.44.6/30; } } } … … … } routing-instances { L3VPN_CUST1 { description "Between PE1 & PE2"; instance-type vrf; interface ge-0/1/0.0; route-distinguisher 33:33; vrf-target target:33:33; vrf-table-label; protocols { ospf { area 0.0.0.1 { interface ge-0/1/0.0; } } } } } If any VRFs are not bound to the appropriate physical or logical interface, this is a finding.

Fix text

Configure the PE router to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs as shown in the example below. [edit] set routing-instances L3VPN_CUST1 instance-type vrf set routing-instances L3VPN_CUST1 description "Between PE1 & PE2" set routing-instances L3VPN_CUST1 interface ge-0/1/0.0 set routing-instances L3VPN_CUST1 protocols ospf interface area 1 ge-0/1/0.0 set routing-instances L3VPN_CUST1 route-distinguisher 33:33 set routing-instances L3VPN_CUST1 vrf-target target:33:33 set routing-instances L3VPN_CUST1 vrf-table-label

Pro Tips

Lavender hyperlinks in small type off to the right (of CSS class id, if you view the page source) point to globally unique URIs for each document and item. Copy the link location and paste anywhere you need to talk unambiguously about these things.

You can obtain data about documents and items in other formats. Simply provide an HTTP header Accept: text/turtle or Accept: application/rdf+xml.

Powered by sagemincer