Cisco Systems OL-4344-01 manual North Bound Interface NBI, Ensuring VPN Isolation

Page 28

Chapter 1 About Cisco IP Solution Center

Security Requirements for MPLS VPNs

The forwarding table for a PE contains only address entries for members of the same VPN. The PE rejects requests for addresses not listed in its forwarding table. By implementing a logically separate forwarding table for each VPN, each VPN itself becomes a private, connectionless network built on a shared infrastructure.

IP limits the size of an address to 32 bits in the packet header. The VPN IP address adds 64 bits in front of the header, creating an extended address in routing tables that classical IP cannot forward. MPLS solves this problem by forwarding traffic based on labels, so one can use MPLS to bind VPN IP routes to label-switched paths. PEs are concerned with reading labels, not packet headers. MPLS manages forwarding through the provider’s MPLS core. Since labels only exist for valid destinations, this is how MPLS delivers both security and scalability.

When a virtual circuit is provided using the overlay model, the egress interface for any particular data packet is a function solely of the packet’s ingress interface; the IP destination address of the packet does not determine its path in the backbone network. Thus, unauthorized communication into or out of a VPN is prevented.

In MPLS VPNs, a packet received by the backbone is first associated with a particular VPN by stipulating that all packets received on a certain interface (or subinterface) belong to a certain VPN. Then its IP address is looked up in the forwarding table associated with that VPN. The routes in that forwarding table are specific to the VPN of the received packet.

In this way, the ingress interface determines a set of possible egress interfaces, and the packet’s IP destination address is used to choose from among that set. This prevents unauthorized communication into and out of a VPN.

Ensuring VPN Isolation

To maintain proper isolation of one VPN from another, it is important that the provider routers not accept a labeled packet from any adjacent PE unless the following conditions are met:

The label at the top of the label stack was actually distributed by the provider router to the PE device.

The provider router can determine that use of that label will cause the packet to exit the backbone before any labels lower in the stack and the IP header will be inspected.

These restrictions are necessary to prevent packets from entering a VPN where they do not belong.

The VRF tables in a PE are used only for packets arriving from a CE that is directly attached to the PE device. They are not used for routing packets arriving from other routers that belong to the service provider backbone. As a result, there may be multiple different routes to the same system, where the route followed by a given packet is determined by the site from which the packet enters the backbone. So one may have one route to a given IP network for packets from the extranet (where the route leads to a firewall), and a different route to the same network for packets from the intranet.

North Bound Interface (NBI)

The user’s Web browsers communicate with IP Solution Center Web server through HTTP, and the client applications communicate with ISC’s CORBA server (backward compatible API) or through the Web server via XML/SOAP.

API Functionality Supported

API support is provided for the following services:

QoS Service

Cisco IP Solution Center, 3.0: MPLS VPN Management User Guide, 3.0

1-28

OL-4344-01

 

 

Image 28
Contents About Cisco IP Solution Center Overview of ISC ISC Network Management SubnetISC Features Service Provider Network for Vlan ID Management Access Domain Assigned Resource PoolsFeatures and Functions Provided in Provisioning with ISC VPN Service Profile-Based ProvisioningRole-Based Access Control Rbac CPE Customer’s and Provider’s View of the Network Customer’s View of the NetworkAbout Provider Edge Routers PEs About Multi-VRF CEsA Multi-VRF CE Providing Layer 3 Aggregation Using Templates to Customize Configuration Files Mapping IPsec Tunnels to Mpls VPNsAuditing Service Requests Uses for the Template FunctionAbout Mpls VPNs VPNs Sharing SitesCharacteristics of Mpls VPNs Intranets and ExtranetsVPN Routing and Forwarding Tables VRFs VRF Implementation Considerations Ip vrf site2 rdCreating a VRF Instance Route Distinguishers and Route TargetsRoute Target Communities CE Routing CommunitiesHub and Spoke Considerations Security Requirements for Mpls VPNs Address Space and Routing SeparationAddress Space Separation Routing SeparationHiding the Mpls Core Structure Resistance to Attacks Securing the Routing ProtocolLabel Spoofing Routing Authentication Securing the Mpls CoreTrusted Devices PE-CE InterfaceSeparation of CE-PE Links LDP AuthenticationConnectivity Between VPNs MP-BGP Security Features Security Through IP Address ResolutionEnsuring VPN Isolation North Bound Interface NBIAPI Functionality Supported NBI Benefits Distributed Load BalancingAPI Approach 11 Simple Flat-Based Server Load Balancing Configuration Four-Tier System Architecture Client tierControl tier