MPLS-Sec-V1

8/8/2019 MPLS-Sec-V1

http://slidepdf.com/reader/full/mpls-sec-v1 1/25

L3 MPLS/VPN SECURITY CONSIDERATIONS

SUMMARY/PURPOSE OF DOCUMENT:

The intent of this document is to provide a detailed reference guide with respect to

security best practices for organizations who either implement Layer 3 MPLS VPN’s as aservice offering or for consumers of such services. As such, security considerations froma service provider perspective as well as from a customer perspective are examined. This

document will address current perspectives/practices to protect the network elements,services carried thereon and the data itself from compromises ensuing from unintentional

errors as well as deliberate attacks.

The document begins with a discussion of the various network scenarios currently being

encountered in the MPLS/VPN environments and the issues, which predominate in them.

Then, these areas are examined in further detail with respect to the technology currentlyavailable. It then addresses these issues by detailing a set of best current practicesincluding sample configurations.

Since considerable effort has already been expended with respect to best practices forInternet Service Providers and since the issues in an MPLS/VPN environment frequently

overlap those encountered by ISP’s and their customers, this document will referenceother publicly available information in support of the practices discussed hereinwhenever possible.

Detailed Definitions:

1.0 Scenarios

In general, MPLS/VPN implementations may be characterized into 5 sets whichpresent differing requirements with respect to the CE-PE arrangements, namely:

1.1 Managed VPNs

In the “Managed VPN” environment, the customer edge equipment (CE) ismanaged by the service provider (SP). That is, the SP’s control extends all the way

out to a point-of-presence within the customers’ IGP. As such, the SP has full controlof the CE configuration including:

- access to the router itself - interaction with the rest of the customers’ IGP

- interaction with the SP’s PE routing mechanism- openness to customer statistics gathering- management requirements specific to the SP operation




1.0 Scenarios (cont’d)

1.1 Managed VPNs (cont’d)

This model provides the SP with the greatest degree of control over the potential

impact of the customers’ operations on the SP’s network itself as well as greatercontrol over issues which may arise affecting other SP customer VPN’s.

In converse, this arrangement implies some degree of trust on the part of thecustomer in terms of:

- customer allows another company (the SP) to have access to their IGP

- customer trusts the SP to map it’s network communications solely toendpoints approved by the customer

- customer assumes that SP will provide majority of fault analysis andresolution activity (since their own access is somewhat limited)

Additionally, there may be environments where customer demands call for somedegree of sharing of responsibility between the SP and themselves. In thesesituations, the span of control with respect to the above parameters may shift in

one direction or the other.

1.2 Unmanaged VPNs

Unmanaged VPN’s are distinguished by the notion that the CE router is ownedcontrolled by the customer. In this scenario, the demarcation point between the SP

and the customer is usually the dataset at the customer premises (although it is quitepossible that the communication facility provider may not in fact be the layer 3MPLS/VPN provider). The customer has full control of the configuration of the CE

router and interacts with the SP’s network over some mutually agreed arrangementbetween the SP and the customer.

In this situation, the SP may have some exposure of his network operation to thecustomer’s configurations of the CE router. As such, the SP needs to take additional

steps to ensure that their network operations are not disturbed by changes in the

customers’ network environment or CE router setups.

However, this operative mode may be more palatable to some customers who desireto maintain the following:

- complete control of their IGP

- additional fault analysis/troubleshooting information access- minimized exposure of their network to the SP




1.0 Scenarios (cont’d)

1.2 Unmanaged VPNs (cont’d)

From the SP’s perspective, the unmanaged VPN environment changes the span of

control significantly. This approach impacts the SP in a number of ways, including:

- need to protect layer 3 interconnect between the CE and PE- possible need to protect the layer 2 interconnect (if shared)- requirement for clear definition of SLA-impacting responsibilities due to

changes in span of control and the need to closely interact with customer in theevent of problems

- additional level of security awareness at the PE router since the CE is no longerunder their explicit control

1.3 CSC Environments

“Carrier-Serving-Carrier” (CSC) networks can be viewed as a special case of ‘unmanaged VPNs’. In these environments, a hierarchy of service provider operators

are utilized to provision end to end connectivity for a customer where the SP who isdirectly interfacing with the end customer may not have facilities in place to meet all

of the customers needs completely. As an example, a smaller SP may have beenselected to provide MPLS/VPN services for a given customer. However, while

this SP may have direct facilities in place to meet the customer’s needs at the endpoints of the network, they may not be able to provide, say intercontinental ortransoceanic facilities. As such, the SP may contract with a carrier who has such

networking available thru a CSC type of arrangement. Consequently, the top tier SPwill view the second tier SP as an “unmanaged VPN client” while the second tier SPmay have either an unmanaged or managed arrangement with the end customer.

CSC is usually accomplished by the higher level SP mapping the secondary SP’s

traffic through some form of a VPN/LSP path. As such, one essentially has endcustomer traffic mapped into a VPN by the first SP, and then again into anotherlabeled hierarchy by the second SP.

There is also a variation on this approach, usually referred to as an “inter-as” network

where the interconnection between SP’s is purely a label-switching mechanism andthe end point peering is still accomplished between the CE routers.

Several topology discussions are set forth in chapter 14 of the CiscoPress book “MPLS and VPN Architectures” (see appendix for ISBN).



CSC network environments present an additional set of interconnection concerns inthat the following connectivity arrangements will be present:

- connections between customer and provider

- connections between provider and their carrier

- routing and label implementation arrangements between the two SP’s

In this situation, there are SLA and security requirements amongst three entities,rather than the typical two.

1.4 VPN + Internet

In network environments where both private network and Internet access are providedby one infrastructure, the security considerations applicable to the VPN world take on

the added significance of the Internet component’s impact or potential impact on theSP backbone and the customer edge connections. Not only are two corporate entities

involved in the network services provisioning, but the Internet and its millions of connections and users are now closely coupled with the corporate data networks. Thisnecessitates stringent adherence to SP security best practices -

(see http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip )

- to ensure that corporate (once private network) data is not adversely impacted by thevagaries of the Internet data flows. Careful consideration must be given to various

design options. Considerable discussion on the various approaches to this type of network service are explored in chapter 12 of the CiscoPress book “MPLS and VPNArchitectures” (see appendix for ISBN).

In general, it is recommended that the VPN service network interconnects and the

Internet access be run over separate links and to separate routers (not the VPN-supporting routers) rather than attempting to homogenize them over a single facility.That is, the SP should provision separate PE’s for VPN versus Internet access even if

the backbone P routers are convergent. As well, the interconnections between theVPN and Internet PE’s should be unique and preferably be terminated on separate CE

routers. This allows for the greatest degree of configuration flexibility (thereby policycontrol) and will reduce the concern that Internet-launched DoS attacks will have animmediate impact on the VPN performance.

As well, firewalling should be viewed as a necessary component of any Internetaccess, whether accomplished by any of the following means:

- firewall at central site with centralized Internet access

- firewall at each CE site

- firewalling thru an SP service offering



However, it is understood that there may be considerable monetary incentives to both

the SP and the customer to provide a single access facility for both services. If necessary, strict consideration should be given to the following set of criteria

when establishing such a shared interconnect:

1. Use a high speed interconnect to minimize cross-service load impacts

- considering the traffic loads that an average number of DDoS bots cangenerate, a shared link should be in the gigabit bandwidth range(GiG-E)

2. Customer should implement double-firewall design- try to minimize the risk of intrusion from Internet hackers

3. EBGP or static routing should be used as a PE/CE protocol since this offers the

greatest degree of control over routing paths

4. Strict filtering should be imposed on both ends of the connection

5. CAR/Policing should be used to control Internet-driven traffic load

6. Vrf-lite may be used on the CE, in order to force incoming traffic flows to theappropriate DMZ (firewall) or trusted network space.

1.5 PE/CE Layer 2 Interconnect

The notion of a SP edge router interconnecting with a customer’s network at a Layer2 level is increasingly popular – in particular in metro environments. In this design,

the customer presents a layer 2 based interconnect, possibly one or more vlans to thePE layer 3 network. In effect the SP PE router is the routing kick off point for layer 3service for the customer. The customer has no layer 3 routing occurring within their

own network.

This approach is generally favored by customers who do not wish to operate a Layer3 network or who feel that they can simply use the SP’s expertise and support staff tooperate the Layer 3 environment on their behalf. This allows the customer to focus

primarily on the pure switching component of networking the ir campuses.

In order to secure this type of connectivity arrangement several differentconsiderations need to be addressed other than the typical Layer 3 interconnect.

In the case of a LAN-based, Layer 2 interconnect the PE router will need to maintainarp entries for all of the end system addresses that are reachable beyond that interface.

The number of entries may be considerable depending on the size of the connectedsite and can impact router cpu and memory considerably. It is generally viewed that



network components and the system as a whole to minimize the likelihood of any of the above scenarios. However, as with all resource-consuming features, a balance

must be struck between maximizing security and offering the performance andusability that the service is intended to provide. Clearly, a wholly disconnected host

or router has total security – however it’s ability to forward data or provide services is

substantially compromised.

The state of the network from an availability and security viewpoint may also differwith respect to the perspective of the interested party. That is, the concerns of the

service provider and the customer are an intersecting, but not completely overlappingset of needs. Indeed, the perspective of the current status of the network may not beidentical for the 2 parties.

2.1 Service Provider Perspective

The service provider’s concerns can be generalized to the following set of issues:

- protection of the backbone infrastructure in terms of availability, accessibility,

load, manageability etc.

- ensuring that committed SLA’s are maintained

- ensuring that billing support functions are uncompromised

- maintaining segregation between different customer domains

- verifying that customers are getting the services that they are entitled to – nomore and no less

2.2 Customer Perspective

The customer has a somewhat differing perspective on the network from theservice provider. The customers concerns include:

- can data/routes pass reliably and unhindered to all appropriate end-points

- ensuring that data/routes are not leaked to other service provider customers

- ensuring that the service provider is meeting committed SLA’s in terms of



availability and thruput

- can the SP quickly troubleshoot a network problem

- can the customer themselves quickly analyse a problem

- what protections can the customer implement to protect themselves from service

provider errors both initially and as their network grows and as the SP’scustomer base grows

- what mechanisms/policies can the customer use to protect themselves fromdeliberate assaults originating from the service provider

Design Considerations:

1.0 Topological and Network Design Considerations

Clearly, the type of physical network selected to interconnect the CE and PE offerdiffering levels of resilience to intrusion and redirection. A serial point-to-point facility

is very difficult to subvert and intrusions usually quite noticeable. When a serialconnection of this nature is interrupted, alarms are raised very quickly and the two end

points are difficult to masquerade.

PVC-based networks, such as Frame Relay and ATM, are somewhat less resistant in that

they are generally controlled by software-based virtual circuit switching and can bereadily mis-switched or duplicated. However, even these facilities typically utilize a

serial point-to-point connection between the CE and the telco central office makingintrusion difficult outside of the telco realm.

Ethernet-based facilities are most readily compromised in that it is relatively easy toinsert a promiscuous monitoring device somewhere in the path. Note that the physical

links from the CE to the central office remain directly cabled and consequently intrusionstill generally requires telco access.

Of course, it is possible to insert equipment into these physical plants, but the level of expertise required to identify the correct facility, access the physical structures and

unobtrusively insert illicit systems is very high and not readily performed by any but adetermined and well-funded attacker.

The more significant issues with shared physical-interface accesses (PVC-based orVLAN-based) would be managing the offered traffic loads so that one VPN cannot

impact the operational characteristics of other VPN’s being terminated on the same port.In order to guarantee the performance of the VPN’s per SLA agreements, it is necessary



Design Considerations:

1.0 Topological and Network Design Considerations (cont’d)

to either provision much greater bandwidth on the access port than the expected load or

to manage the bandwidth available using policing and shaping mechanisms. Typicallythis is done thru the offering of a limited set of performance options (say 4 or 5 classes)

to the customer when they request the service. Policing controls are then applied to theinterfaces based upon these pre-defined classes of service to meet the expectations of the

customer. In an unmanaged VPN where different entities control the CE and PE, andconsequently neither can be guaranteed to stay within the expected operationalcharacteristics, these controls would need to be applied to both routers to ensure that

offered loads do not impact the applicable networks.

Further detailed discussions with respect to QOS planning and application may be seen atthe following:

http://www.cisco.com/en/US/about/ac123/ac114/ac173/ac170/about_cisco_packet_technology09186a00801016da.html

http://www.cisco.com/en/US/tech/tk543/tk766/technologies_white_paper09186a00800a3

e2f.shtml

http://www.cisco.com/warp/public/732/Tech/qos/

Control Plane Hardening:

Routing Mechanisms:

In order to manage forwarding information between the PE and CE some sort of L3routing must be performed. There are, in essence, 2 options – static routing or dynamic

routing. The pros and cons of each are well understood in L3 routing environments andapply equally to an MPLS/VPN network. However, since an MPLS/VPN PE-CEconnection involves a relationship between separate corporate entities, due consideration

must be given to the security and stability implications of such interconnections. Forexample, the concerns of interconnecting two entities may include:

- PE or CE may be subject to floods of routes from its neighbor- instabilities in the routing protocol processes may adversely affect cpu

utilization- invalid routes injected into either network space may cause traffic flows

resulting in suboptimal or insecure pathing




Routing Mechanisms (cont’d):

These issues are no different than those faced by most ISP’s today although generally

ISP’s do not utilize IGP’s in their interconnection points, relying solely on BGP for thispurpose. MPLS/VPN customers may desire the use of mechanisms other than BGP and

as a result, consideration needs to be given to the requirements that this may impose.

Clearly, static routing provides the most stable and controlled scenario for the PE-CE

interconnect. With static route definitions there are no opportunities for errant routes tobe introduced other than by typing them directly into the configurations. As well, there is

less cpu impact with static routes since there is no dynamic routing process to run (otherthan the SP iBGP). In addition, since the CE and PE are both using explicitly configured

routes, the security of the interconnection is improved – monitoring the intervening pathwill not provide any information as to what routes are accessible beyond the router.

Alternatively, using a dynamic routing protocol reduces the amount of configurationeffort on both the PE and CE routers. As well, changes within the customer’s network addressing are readily accommodated and alternate pathing is more easily deployed. If a

dynamic protocol is to be used between the PE and CE routers, then eBGP is therecommended choice due to its inherent stability, scalability and control features. In any

case, the use of a dynamic protocol mandates the use of an authentication mechanismbetween the two routers for security purposes.

Dynamic Routing Authentication:

In order to provide a degree of security in a dynamically routed PE-CE environment, with

respect to the peer relationships across the PE-CE links, MD5 authentication (MessageDigest 5 Hashed Message Authentication Code or HMAC) should be enabled between

the peers. This mechanism utilizes a highly resistant hash algorithm in the handshakebetween the peers to provide some assurance that the peer is in fact the intendedneighbor. The use of a pre-shared secret on the PE and CE routers provides support for

the one-way encrypted hash message used to authenticate the peers. As such, co-ordination is required between the PE and CE management entities if they are separately

controlled.

MD5 should be used as opposed to the other, less resilient hashing mechanisms available.

This mechanism is available for all of the PE-CE routing protocols currently supported

including;




Dynamic Routing Authentication (cont’d):

EBGP PE-CE Routing;

With BGP, authentication is defined on a per neighbor basis. Also, BGP does notcurrently support the use of key chains.

router bgp 13address- family ipv4 vrf Peabody1

neighbor 1.1.1.1 remote-as 14neighbor 1.1.1.1 update-source loopback 0

neighbor 1.1.1.1 password 5 1Sherman2# establishes use of MD5 password “1Sherman2” for this neighbor

address- family ipv4 vrf Dudley1neighbor 2.2.2.2 remote-as 15

neighbor 2.2.2.2 update-source loopback 0neighbor 2.2.2.2 password 5 77doright2# establishes use of MD5 password “77doright2” for this neighbor

NOTE: With BGP, ensure that MD5 authentication is enabled at both ends of therouter pair – a router without MD5 auth definitions will still accept routes

from a peer who is sending MD5

EIGRP PE-CE Routing;

EIGRP authentication is defined in an interface-specific manner and can beinstantiated using either cleartext or MD5 passwords. As previously stated, MD5is the recommended usage. Authentication must be enabled for the autonomous

system (AS) in question.

router eigrp 13address-family ipv4 vrf Bullwinkle1autonomous-system 14

network 1.0.0.0# define the vpn known as “Bullwinkle1” as operating under the

eigrp autonomous system 14



address- family ipv4 vrf Rocky1autonomous–system 15

network 1.0.0.0# define the vpn known as “Rocky1” as operating under the

eigrp autonomous system 15

i n t e r f a c e E t h e r n e t 0 / 0

i p v r f f o r wa r d i n g B u l l wi n k l e 1

i p a d d r e s s 1 . 1 . 1 . 1 2 5 5 . 0 . 0 . 0

n o i p d i r e c t e d - b r o a d c a s t

i p a u t h e n t i c a t i o n mo d e e i g r p 1 4 md 5

# d e f i n e s a u t h e n t i c a t i o n mo d e f o r e i g r p AS 1 4

# t o b e MD5

i p a u t h e n t i c a t i o n k e y - c h a i n e i g r p 1 4 e i g r p 1 4

# s e t s t h e k e y c h a i n n a me f o r e i g r p AS 1 4 t o t h e

# s t r i n g “ e i g r p 1 4 ”


i p v r f f o r w a r d i n g R o c k y 1i p a d d r e s s 1 . 1 . 1 . 1 2 5 5 . 0 . 0 . 0


i p a u t h e n t i c a t i o n mo d e e i g r p 1 5 md 5

# d e f i n e s a u t h e n t i c a t i o n mo d e f o r e i g r p AS 1 5

# t o b e MD5

i p a u t h e n t i c a t i o n k e y - c h a i n e i g r p 1 5 e i g r p 1 5

# s e t s t h e k e y c h a i n n a me f o r e i g r p AS 1 5 t o t h e

# s t r i n g “ e i g r p 1 5 ”

k e y c h a i n e i g r p 1 4

k e y 1

k e y - s t r i n g 5 1 n a t a s h a f a t a l e 3# c r e a t e s a ‘ c h a i n ’ k n o wn a s “ e i g r p 1 4 ” o f 1 k e y , wi t h t h e

# MD5 p a s s wo r d s e t t o “ 1 n a t a s h a f a t a l e 3 ”

k e y c h a i n e i g r p 1 5

k e y 1

k e y - s t r i n g 5 3 Bo r i s b a d e n o v 1

# c r e a t e s a ‘ c h a i n ’ k n o wn a s “ e i g r p 1 5 ” o f 1 k e y , wi t h t h e

# MD5 p a s s wo r d s e t t o “ 3 B o r i s b a d e n o v 1 ”

The key chain software feature allows the user to define a set of keys bound into achain that can then be applied to an authentication operation. The ability to define

a set of keys, rather than just one, allows for easier key migration on the basis of some predetermined interval. Note the key number in this command construct is just an index rather than the ‘key’ variable used in an MD5 context. Additional

information with respect to key management and configuration is available in thefollowing documentation:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ ipcprt2/1cfindep.htm#1001635





OSPF PE-CE Routing;

OSPF also establishes authentication requirements on a per interface basis.Additionally, authentication must be enabled for the area within the AS where

authentication will be performed. As with BGP, OSPF does not currently use thekey chain methodology.

r o u t e r o s p f 5 2 v r f Do n a l d

a r e a 5 2 a u t h e n t i c a t i o n me s s a g e - d i g e s t

# e n a b l e s u s e o f a u t h e n t i c a t i o n wi t h i n t h i s o s p f a r e a f o r

# o s p f p r o c e s s 5 2


i p v r f f o r wa r d i n g Do n a l d

i p a d d r e s s 1 0 . 1 . 1 . 2 2 5 5 . 2 5 5 . 2 5 5 . 0


i p o s p f a u t h e n t i c a t i o n me s s a g e - d i g e s t

# e s t a b l i s h e s a u t h e n t i c a t i o n f o r t h e n e i g h b o r a c r o s s t h i s

i n t e r f a c e

i p o s p f me s s a g e - d i g e s t - k e y 1 3 md 5 5 1 Da i s y 3 # defines “1Daisy3” as the MD5 password to be used on this link

r o u t e r o s p f 4 2 v r f Mi c k e y

a r e a 4 2 a u t h e n t i c a t i o n me s s a g e - d i g e s t

# e n a b l e s u s e o f a u t h e n t i c a t i o n wi t h i n t h i s o s p f a r e a f o r

# o s p f p r o c e s s 4 2


i p v r f f o r wa r d i n g Mi c k e y

i p a d d r e s s 1 0 . 1 . 1 . 2 2 5 5 . 2 5 5 . 2 5 5 . 0


i p o s p f a u t h e n t i c a t i o n me s s a g e - d i g e s t

# e s t a b l i s h e s a u t h e n t i c a t i o n f o r t h e n e i g h b o r a c r o s s t h i s

i n t e r f a c e

i p o s p f me s s a g e - d i g e s t - k e y 1 3 md 5 5 2 mi n n 1 e 7

# defines “2 mi n n 1 e 7 ” as the MD5 password to be used on this link





RIPV2;


i p v r f f o r wa r d i n g Da f f y 1

i p a d d r e s s 1 . 1 . 1 . 1 2 5 5 . 0 . 0 . 0


i p r i p a u t h e n t i c a t i o n mo d e md 5

# e n a b l e s MD5 a u t h e n t i c a t i o n o v e r t h i s r i p i n t e r f a c e

i p r i p a u t h e n t i c a t i o n k e y - c h a i n Da f f y 1

# s e t s “ Da f f y 1 ” a s t h e k e y c h a i n t o b e u s e d f o r t h i s

l i n k

k e y c h a i n Da f f y 1

k e y 1k e y - s t r i n g 5 1 3 S y l v e s t e r 1

# c r e a t e s a ‘ c h a i n ’ k n o wn a s “ Da f f y 1 ” o f 1 k e y , wi t h t h e

# MD5 p a s s w o r d s e t t o “ 1 3 S y l v e s t e r 1 ”


Routing Control:

Within an MPLS/VPN environment, it is conceivable that through deliberate action oraccidental mis-configuration an excessive number of routes may be propagated from one

routing peer to another. This behavior could readily impact the recipient router cpu and if great enough could lead to memory consumption sufficient to cause the router to disableCEF (and thereby all MPLS forwarding) or reload. This exposure exists for both the CE

router and the PE router and as such should be controlled on both to the extent possible.

At this time, only BGP supports the concept of a maximum number of permitted prefixes.Within BGP, the “maximum-prefix” construct allows a user to define a maximumnumber of routes to be accepted from this peer. Once this maximum has been reached

the router can be configured to either issue a warning message or to restart the offendingpeer, with the interval to restart being configurable. In addition, a threshold may be

defined where warning messages are issued prior to reaching the maximum.




Routing Control (cont’d):

The configuration of BGP prefix limits is illustrated below:

r o u t e r b g p 1 3

n o s y n c h r o n i z a t i o n

b g p l o g - n e i g h b o r - c h a n g e s

n o a u t o - s u mma r y

a d d r e s s - f a mi l y i p v 4 v r f V P N_ 2 0 4 9 9

n e i g h b o r 1 4 0 . 0 . 2 5 0 . 2 r e mo t e - a s 5 0 0

n e i g h b o r 1 4 0 . 0 . 2 5 0 . 2 a c t i v a t e

n e i g h b o r 1 4 0 . 0 . 2 5 0 . 2 ma x i mu m- p r e f i x 4 5 8 0 r e s t a r t 2

# d e f i n e s a 4 5 p r e f i x ma x i mu m f o r r o u t e s d e l i v e r e d f r o m t h i s

n e i g h b o r , wi t h a wa r n i n g me s s a g e i s s u e d a t 8 0 % o f 4 5 , a n dt h e BGP s e s s i o n r e s t a r t e d o n e x c e e d i n g 4 5 , wi t h a 2 mi n u t e

i n t e r v a l f o r r e t r y


n o s y n c h r o n i z a t i o n

e x i t - a d d r e s s - f a mi l y

The following reflects the console logging that occurs as the number of routes from aBGP peer reaches the threshold set for warning messages, and further the peer restartonce the actual maximum has been reached.

6 d 2 2 h : %B GP - 4 - MAXP F X: No . o f p r e f i x r e c e i v e d f r o m 1 4 0 . 0 . 2 5 0 . 2 ( a f i 2 )

r e a c h e s 3 7 , ma x 4 5

6 d 2 2 h : %B GP - 3 - MAXP F XE XC E E D: No . o f p r e f i x r e c e i v e d f r o m 1 4 0 . 0 . 2 5 0 . 2

( a f i 2 ) : 4 6 e x c e e d l i mi t 4 5

6 d 2 2 h : %B GP - 5 - ADJ C HANGE : n e i g h b o r 1 4 0 . 0 . 2 5 0 . 2 v p n v r f VP N_ 2 0 4 9 9 Do wn

B GP No t i f i c a t i o n s e n t

6 d 2 2 h : %B GP - 3 - NOT I F I C AT I ON: s e n t t o n e i g h b o r 1 4 0 . 0 . 2 5 0 . 2 3 / 1 ( u p d a t e

ma l f o r me d )

0 b y t e s F F F F F F F F F F

Once the maximum number of routes on the connection have been exceeded, the status of

the BGP peer will indicate that it has been idled due to prefix count limit having beenoverrun:

E S R 3 # s h i p b g p v a s | i 1 4 0 . 0 . 2 5 0 . 2

1 4 0 . 0 . 2 5 0 . 2 4 5 0 0 1 4 9 1 3 0 0 0 0 0 0 : 0 1 : 0 1 I d l e ( P f x Ct )




Routing Peers:

In the PE-CE dynamic routing space, the interconnections may be across multi-accessmedia or may be mis-connected in such a way that erroneous peers may be introduced. In

order to prevent routes being accepted from non-loved neighbors it is recommended thatMD5 authentication be used between PE’s and CE’s, which utilize dynamic protocols. If however, this is not acceptable in a given environment there is still a need to control the

peering associations. Within BGP, this is inherently accomplished through the “neighbor”construct. When EIGRP or RIP are in use, this functionality is not yet available for PE-

CE interfaces. Without MD5, the only protection against unwanted routes would be theautonomous system numbers – a very weak mechanism from a protection perspective. Inthis environment, the “distance” command may be used to control acceptable route

sources.

For example:r o u t e r e i g r p 6 6 6

a d d r e s s - f a mi l y i p v 4 v r f VP N_ 2 0 3 9 9

r e d i s t r i b u t e b g p 6 5 0 0 0 me t r i c 1 0 0 0 1 0 0 1 0 0 1 1 5 0 0

n e t w o r k 1 4 0 . 0 . 0 . 0

d i s t a n c e 9 0 1 4 0 . 0 . 2 0 0 . 2 0 . 0 . 0 . 0

# d e f i n e s a n a d mi n i s t r a t i v e d i s t a n c e o f 9 0 ( d e f a u l t )

f o r e i g r p r o u t e s r e c e i v e d f r o m a d d r e s s 1 4 0 . 0 . 2 0 0 . 2

d i s t a n c e 2 5 5 0 . 0 . 0 . 0 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5

# s e t s a l l o t h e r s o u r c e s o f r o u t i n g t o a v a l u e o f

u n k n o wn / u n t r u s t e d

a u t o n o mo u s - s y s t e m 1


# NOT E : E I GR P r e q u i r e s t h a t a c c e p t a b l e s o u r c e s mu s t

p r e c e d e t h e “ 2 5 5 ” s o u r c e a s s h o wn a b o v e

r o u t e r r i p

v e r s i o n 2

a d d r e s s - f a mi l y i p v 4 v r f VP N_ 2 0 3 9 9

v e r s i o n 2

r e d i s t r i b u t e b g p 6 5 0 0 0

n e t w o r k 1 4 0 . 0 . 0 . 0

d i s t a n c e 2 5 5

# s e t s a l l s o u r c e s o f r o u t i n g i n f o t o a v a l u e o f 2 5 5 –

u n k n o wn / u n t r u s t e dd i s t a n c e 1 2 0 1 4 0 . 0 . 2 0 0 . 2 0 . 0 . 0 . 0

# s e t s a n a d mi n i s t r a t i v e d i s t a n c e o f 1 2 0 ( d e f a u l t ) f o r

r i p r o u t e s r e c e i v e d f r o m 1 4 0 . 0 . 2 0 0 . 2



More information is available at the following url:

http://www.cisco.com/warp/customer/105/admin_distance.html




PE-CE Link Addressing:

The physical facility between the PE and CE remains an exposure with respect to accessto the networks, data flows and attack points. This link should be secured to the extent

feasible while supporting application requirements and maintenance efforts.

The use of un-numbered links is frequently seen as a means to enhance the security of thePE, and to some extent the CE since there is no exposed L3 address to attack. If such anapproach is desired, consideration must be given to the implications on the routing

protocol being used between the PE and CE. For example, if eBGP is the protocol in use,peering will need to be linked to loopback addresses (or other) and ‘multi-hop’ must be

enabled for the eBGP session. This control allows eBGP sessions to maintained over anumber of hops by setting the TTL appropriately. Unfortunately, the use of this modifier

allows for remote eBGP connection attempts from any number of hops – not necessarily just as defined in the sourcing configuration.

One of the most used troubleshooting tools in the IP network space is the ICMP Echo(ping) test. The use of un-numbered links removes the ability of the network operator toping the directly connected interface as a fault analysis methodology. This may be seen

as sufficient cause to support numbered interfaces in itself.

Further protection may also be had by encrypting the traffic flowing over the link usingeither payload encryption mechanisms or full link encryptors. If the data being passedover the network is considered at extreme risk then such protection may be appropriate.

Router Accessibility:

Access requirements to a given PE may include:

- pingability by SP personnel- pingability by customer personnel- telnet access by SP personnel

- SNMP read/write access by SP personnel- SNMP read access by customer personnel

- privileged mode operation by SP personnel

Similarly, the customer may wish to provide some degree of access to the CE router in

order to enhance the SP’s ability to troubleshoot a network problem. In the case of amanaged-CPE, the same set of questions would be applicable. Generally speaking, one

should not permit access to a given router beyond the minimally required set for goodnetwork operations and maintenance. Access to the router should be secured using




Router Accessibility (cont’d):

access-lists controlling the connections to the router vty’s and access to the physical

console and auxiliary ports need to be protected. Ideally, all remote access to the routersshould be under the auspices of an AAA server. See below for example AAA access

control using CiscoSecure:

http://www.cisco.com/en/US/products/sw/secursw/ps4911/products_tech_note09186a0080107cfd.shtml

SNMP access to the router should be limited to read-only for any personnel/systems otherthan those under direct control of the owner of the router. All SNMP access and

messaging should be explicitly controlled through configuration. Telnet access to a routershould only be permitted via specific access control lists and mechanisms such as SSH

are preferable (requires DES-supporting image load). Since the PE is generally a devicesupporting multiple customers’ connections, and since there is no ‘per-vrf’ segmentationof resource views, access to router statistics should be limited to SP personnel only. In

general, with respect to PE-CE link operation, the benefits gained by allowing ICMPecho mechanisms outweigh the risks associated therein.

For details regarding current best practices recommended to ISP’s in the area of routersecurity (as well as general ISP usage) please refer to the following:

http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip

Note that within an MPLS/VPN environment, the configuration constructs for telnetaccess have been altered in order to apply them to vrf instances. For example, if applying

an access class to a set of vty’s the parameter “vrf-also” is required. Failure to includethis modifier will cause all telnet attempts from a CE to be refused. As such, applicationof a simple access list to the vty ports will prevent access to the router, as recommended

above, and with the “log” keyword included in the explicit deny, inappropriate attemptswill be logged.

Example 1 - Denying CE Telnet access:

L i n e v t y 0 4

l o g i n

p a s s wo r d mo o s ea c c e s s - c l a s s d o g i n

#applies access-list dog to inbound telnet requests

i p a c c e s s - l i s t s t a n d a r d d o g

p e r mi t 1 . 1 3 . 1 3 . 2

d e n y a n y l o g

# c r e a t e s a n a me d AC L “ d o g ” wh i c h p e r mi t s a c c e s s f r o m

h o s t 1 . 1 3 . 1 3 . 2 a n d d e n y s a n d l o g s a l l o t h e r a t t e mp t s





Example 2 - Pemitting CE Telnet access:L i n e v t y 0 4

l o g i n

p a s s wo r d mo o s e

a c c e s s - c l a s s 1 3 i n v r f - a l s o

#applies access-list 13 to inbound telnet requests including those

entering from vrf’d interfaces

Note that the operations of other access service functions such as rsh, rcp, and tftp are notchanged when used within an MPLS/VPN environment. That is, access control remainsas it has been prior to MPLS/VPN’s – and such controls should be applied using the

appropriate ACL’s and authentication mechanisms. Note that these services would not

normally be enabled on a PE or CE router – the security implications are unacceptableand the management requirements for these functions are minimal.

An abbreviated sample configuration illustrating the above points follows:

h o s t n a me t o p

a c c e s s - l i s t 1 3 p e r mi t 1 . 1 3 . 1 3 . 2

a c c e s s - l i s t 1 3 d e n y a n y l o g

# e s t a b l i s h e s a c c e s s - l i s t 1 3 , p e r mi t t i n g p a c k e t s f r o m i p a d d r e s s

1 . 1 3 . 1 3 . 2 a n d d e n y i n g / l o g g i n g a l l o t h e r s

i p r c md r s h - e n a b l e

# e n a b l e s r s h s e r v i c e s

i p r c md r e mo t e - h o s t t o p 1 3 b o t #permits rsh commands to this router “top” from a host permitted by access-list13 with a name of “bot”

t f t p - s e r v e r f l a s h : s a f e _ b o t . c f g 1 3 #enables tftp-server services for flash file “safe_bot.cfg” restricted by

access list 13

i p a c c e s s - l i s t 1 4 p e r mi t 1 . 1 . 1 . 1

i p a c c e s s - l i s t 1 4 p e r mi t 1 . 1 . 1 . 1 3

i p a c c e s s - l i s t 1 4 d e n y a n y l o g

# c r e a t e s a n a c c e s s l i s t “ 1 4 ” p e r mi t t i n g a c c e s s f r o m h o s t s

1 . 1 . 1 . 1 a n d 1 . 1 . 1 . 1 3 a n d d e n y i n g a n d l o g g i n g o t h e r a t t e mp t s

s n mp - s e r v e r e n g i n e I D l o c a l 0 0 0 0 0 0 0 9 0 2 0 0 0 0 5 0 7 3 2 6 6 7 0 1

s n mp - s e r v e r c o mmu n i t y c o w R O

# e s t a b l i s h e s t h e S NMP r e a d - o n l y c o mmu n i t y s t r i n g a s “ c o w”

s n mp - s e r v e r c o mmu n i t y b u l l R W 1 4

# e s t a b l i s h e s “ b u l l ” a s t h e r e a d - w r i t e s n mp c o mmu n i t y s t r i n g

a n d l i mi t s a c c e s s t o t h o s e h o s t s a s d e f i n e d b y a c c e s s l i s t 1 4





n o s n mp - s e r v e r i f i n d e x p e r s i s t

s n mp - s e r v e r t r a p - a u t h e n t i c a t i o n

s n mp - s e r v e r t f t p - s e r v e r - l i s t 1 4# l i mi t s t f t p r e l a t e d s n mp o p e r a t i o n s p e r a c c e s s l i s t 1 4

l i n e c o n 0

e x e c - t i me o u t 5 0

# a p p l i e s 5 mi n u t e t i me o u t t o i n a c t i v e s e s s i o n s

l i n e a u x 0

l i n e v t y 0 4

a c c e s s - c l a s s 1 3 i n

# l i mi t s t e l n e t a c c e s s t o v t y p o r t s p e r a c c e s s l i s t 1 3

p a s s w o r d c i s c o

l o g i n

In addition, the C12000 supports a receive access-list mechanism that allows the line

cards to filter traffic destined for the router itself based upon a configured access-list.Since this control is executed in the hardware of the line cards, it can prevent undesired

high traffic loads from disrupting main cpu operations.

More details on this command are available at:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guid

e09186a00800a8531.html



DATA PLANE HARDENING:

Unicast RPF:

Unicast Reverse Path Forwarding (uRPF) lookup feature should be enabled on each

interface of the PE routers’ CE-facing interfaces and on the CE routers’ PE-facinginterfaces. RPF attempts to verify that the source of an incoming packet is accessible via

the interface from which it was received (by checking the CEF tables) prior to switchingthe packet through.

uRPF is currently available in two general operating modes:

Loose;In this mode, if the incoming packet’s source address is reachable thru any

interface in the router, the packet is forwarded.

Strict; In strict mode, the packet must enter via the exact interface that the sourceaddress would be reached prior to forwarding.

Generally speaking the two modes are intended for operation at different points of thenetwork. Loose mode is primarily applicable in network cores while strict mode is

intended for use at the edges of a given network.

Since PE and CE routers implement the network edge in an MPLS/VPN context, strictmode would be the appropriate choice.

For more details see:

New syntax:

i p v e r i f y u n i c a s t r e v e r s e - p a t h R e v e r s e p a t h v a l i d a t i o n o f s o u r c e

a d d r e s s ( o l d c o mma n d f o r ma t )

i p v e r i f y u n i c a s t s o u r c e Va l i d a t i o n o f s o u r c e a d d r e s s

Old syntax:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122tcr/122tsr/fothercr/sftrpf.pdf




Unicast RPF (cont’d):

The following illustrates the configuration of uRPF on a PE router:


i p v r f f o r wa r d i n g Da f f y 1

i p a d d r e s s 1 . 1 . 1 . 1 2 5 5 . 0 . 0 . 0


i p v e r i f y u n i c a s t s o u r c e r e a c h a b l e - v i a r x

# enables strict RPF checking on incoming packets

CAR/QOS:

Various QOS mechanisms can be utilized to protect the PE and CE router interfaces from

undue traffic volumes. A higher than expected traffic flow may be due to a deliberateDOS assault or may simply be the result of a mis-configured device somewhere withinthe network. However, as these mechanisms are inserted directly into the forwarding path

they do have an impact on packet forwarding rates especially on software-basedplatforms. As such, these features should be applied with care and due consideration

given to the environment where they are to be applied.

For example, the following configuration sample illustrates an approach to controlling theicmp traffic, which is permitted to enter the interface in question:

c l a s s - ma p ma t c h - a n y d o g g i tma t c h p r o t o c o l i c mp

# d e f i n e s a c l a s s ma p r e f e r e n c e o f “ d o g g i t ” wh i c h ma t c h e s

i c mp p a c k e t s

p o l i c y - ma p d o g g i t

c l a s s d o g g i t

p o l i c e c i r 8 0 0 0 0

e x c e e d - a c t i o n d r o p

# c r e a t e s a p o l i c y wh i c h p o l i c e s t r a f f i c s e l e c t e d b y t h e

c l a s s “ d o g g i t ” t o a l e v e l o f 8 0 Kb p s ; t r a f f i c b e y o n d t h i s

l e v e l i s d r o p p e d


i p v r f f o r wa r d i n g c o w

i p a d d r e s s 1 . 1 3 . 1 3 . 2 2 5 5 . 0 . 0 . 0

i p v e r i f y u n i c a s t s o u r c e r e a c h a b l e - v i a r x

s e r v i c e - p o l i c y i n p u t d o g g i t #applies the policy “doggit” to the input packet stream on interfaceEthernet 1/0




CAR/QOS (cont’d):

For more details on configuring routers to control traffic loads see the following url:

http://www.cisco.com/en/US/tech/tk543/tech_topology_and_network_serv_and_protocol

_suite_home.html

IDS and FIREWALLING:

Considerable documentation is available on Intrusion Detection and Firewallingmechanisms for IP networks. Over the past years, the need for such mechanisms in any

given IP network have become increasingly apparent. This requirement is not obvia ted bythe use of an MPLS/VPN as a transport network and should be implemented in such away as to protect corporate assets.

The architecture and implementation of IDS systems and Firewalls is quite involved andwill not be detailed herein. The following locations provide information on these topics:

http://www.cisco.com/go/safe

http://www.cisco.com/en/US/netsol/ns110/ns170/ns171/ns292/networking_solutions_pac

kage.html

http://www.cisco.com/en/US/netsol/ns110/ns170/ns171/ns118/networking_solutio ns_package.html

http://www.robertgraham.com/pubs/network-intrusion-detection.html




IPSec:

MPLS/VPN’s forward user information over the network in the same format as it isreceived from the CE – as with any other data-transparent transport network (ATM,

FrameRelay, HDLC). As such, it is possible, though perhaps requiring considerable effortand access, to monitor traffic as it passes through the network. This may not be

acceptable for highly sensitive information such as financial data or confidentialmaterials. If inherent protection of the data from monitoring is desired, it is necessary touse some sort of encryption technique.

Various data encryption mechanisms have been available for some time including

software-based encryptors, hardware-based encryption and the most typically used withinthe IP world – IPSec. Full link encryptors may be used as long as they are inserted in the

lines between the routers such that the original data stream, in particular the headerinformation, is available for the routers to perform their forwarding decisions. As such,information is ‘in the clear’ on the cables between the encryptor/decryptor and the

attached router. However, a more typical approach in an IP environment is to use theIPSec mechanisms, which encrypt the data and still produce an output IP packet that canbe switched by the routers. In addition, IPSec also can provide support for verification of

the end-points of the data flow thus providing a high degree of certainty that theinformation is actually being received by the intended party.

Considerable information is publicly available on IPSec and its related standards. Furtherdetails may be readily found including:

http://www.cisco.com/en/US/tech/tk583/tk372/tech_protocol_family_home.html

http://www.ietf.org/html.charters/ipsec-charter.html

http://ietf.org/ids.by.wg/ipsec.html

RFC-2401 Security Architecture for the Internet ProtocolRFC-2406 IP Encapsulating Security Payload (ESP)RFC-2407 The Internet IP Security Domain of Interpretation for ISAKMP

RFC-2408 Internet Security Association and Key Management ProtocolRFC-2409 The Internet Key Exchange

Cisco Secure Virtual Private Networks ISBN1-58705-033-1



REFERENCES:

RFC2082 – RIP-2 MD5 Authentication

RFC2154 – OSPF with Digital SignaturesRFC2385 – Protection of BGP Sessions via the TCP MD5 Signature Option

RFC3013 – Recommended Internet Service Provider Security Services and ProceduresRFC2196 – Site Security Handbook

Cisco ISP Essentials – ISBN 1-58705-041-2

http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip

General Information on Securing Cisco Routers

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080120f48.shtml

Cisco Secure Virtual Private Networks - ISBN 1-58705-033-1

MPLS-Sec-V1

Documents

Transcript of MPLS-Sec-V1