Cisco press MPLS VPN security a practical guide to hardening MPLS networks jun 2005 ISBN 1587051834

Publisher: Cisco Press Pub Date: June 08, 2005 ISBN: 1-58705-183-4 Pages: 312 Table of Contents | Index A practical guide to hardening MPLS networks Define "zones of trust" for your MPL

By Michael H Behringer, Monique J Morrow

Publisher: Cisco Press Pub Date: June 08, 2005 ISBN: 1-58705-183-4 Pages: 312

Table of Contents | Index

A practical guide to hardening MPLS networks Define "zones of trust" for your MPLS VPN environment Understand fundamental security principles and how MPLS VPNs work Build an MPLS VPN threat model that defines attack points, such as VPN separation, VPN spoofing, DoS against the network's backbone, misconfigurations, sniffing, and inside attack forms Identify VPN security requirements, including robustness against attacks, hiding of the core

infrastructure, protection against spoofing, and ATM/Frame Relay security comparisons

Interpret complex architectures such as extranet access with recommendations of Inter-AS, carrier-supporting carriers, Layer 2 security considerations, and multiple provider trust model issues Operate and maintain a secure MPLS core with industry best practices Integrate IPsec into your MPLS VPN for extra security in encryption and data origin verification Build VPNs by interconnecting Layer 2 networks with new available architectures such as virtual private wire service (VPWS) and virtual private LAN service (VPLS) Protect your core network from attack

by considering Operations, Administration, and Management (OAM) and MPLS backbone security incidentsMultiprotocol Label Switching (MPLS) is becoming a widely deployed

technology, specifically for providing virtual private network (VPN) services Security is a major concern for companies migrating to MPLS VPNs from existing VPN technologies such as ATM Organizations deploying MPLS VPNs need security best practices for protecting their networks, specifically for the more complex deployment models such as inter-provider

networks and Internet provisioning on the network.MPLS VPN Security is the first book to address the security features of MPLS VPN networks and to show you how to harden and securely operate an MPLS network Divided into four parts, the book begins with an overview

of security and VPN technology A chapter on threats and attack points provides a foundation for the discussion in later chapters Part II addresses overall security from various

perspectives, including architectural, design, and operation components Part III provides practical guidelines for implementing MPLS VPN security Part IV presents real-world case studies that encompass details from all the previous chapters to provide examples of overall secure solutions.Drawing upon the authors' considerable experience in attack mitigation and infrastructure security, MPLS VPN Security is your practical guide to understanding how to effectively secure communications in an MPLS environment "The authors of this book, Michael Behringer and Monique Morrow, have a deep and rich understanding of security issues, such

as denial-of-service attack prevention and infrastructure protection from network

vulnerabilities They offer a very practical perspective on the deployment scenarios, thereby demystifying a complex topic I hope you enjoy their insights into the design of self-defending networks." Jayshree V Ullal, Senior VP/GM Security Technology Group, Cisco Systems®

By Michael H Behringer, Monique J Morrow

Publisher: Cisco Press Pub Date: June 08, 2005 ISBN: 1-58705-183-4 Pages: 312

or entity with respect to any loss or damages arising from the information

contained in this book or from the use of the discs or programs that may

accompany it

The opinions expressed in this book belong to the author and are not necessarilythose of Cisco Systems, Inc

All terms mentioned in this book that are known to be trademarks or servicemarks have been appropriately capitalized Cisco Press or Cisco Systems, Inc.cannot attest to the accuracy of this information Use of a term in this book

should not be regarded as affecting the validity of any trademark or service

mark

Corporate and Government Sales

Cisco Press offers excellent discounts on this book when ordered in quantity forbulk purchases or special sales

Readers' feedback is a natural continuation of this process If you have any

comments regarding how we could improve the quality of this book or otherwisealter it to better suit your needs, you can contact us by e-mail at

feedback@ciscopress.com Please make sure to include the book title and ISBN

in your message

We greatly appreciate your assistance

Credits

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia • Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico • The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa

• Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

Copyright © 2003 Cisco Systems, Inc All rights reserved CCIP, CCSP, the

Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems

Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net ReadinessScorecard, Networking Academy, and ScriptShare are trademarks of Cisco

Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The FastestWay to Increase Your Internet Quotient, and iQuick Study are service marks ofCisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE,CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS,the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, theCisco Systems logo, Empowering the Internet Generation, Enterprise/Solver,EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV,

Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX,

Registrar, SlideCast, SMARTnet, Strata View Plus, Stratm, SwitchProbe,

TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems,Inc and/or its affiliates in the U.S and certain other countries

All other trademarks mentioned in this document or Web site are the property oftheir respective owners The use of the word partner does not imply a partnershiprelationship between Cisco and any other company (0303R)

Michael H Behringer obtained his diploma in computer science at the

Technical University of Munich For five years, he worked at the European

Internet service provider DANTE, based in Cambridge, UK, where he last heldthe position of senior network engineer, responsible for the design and

implementation of DANTE's pan-European networks In 1998, Michael joinedCisco Systems and is now based in Nice As a senior distinguished engineer, hefocuses on service provider security issues such as MPLS security and denial-of-service attack prevention

Michael is an active member of the IETF, where he started publishing work onMPLS VPN security in 2001 He is the author of "Analysis of the Security ofBGP/MPLS IP VPNs" (draft-behringer-mpls-security) and coauthor of "SecurityFramework for Provider Provisioned Virtual Private Networks" (draft-ietf-l3vpn-security-framework) Michael is a frequent speaker at security and networkingconferences and has published a number of articles

Monique J Morrow is currently a CTO consulting engineer at Cisco Systems,

Inc She has more than 20 years' experience in IP internetworking, includingdesign, implementation of complex customer projects, and service developmentfor service providers Monique has been involved in developing managed

network services such as remote access and LAN switching in a service providerenvironment She has worked for both enterprise and service provider companies

in the United States and in Europe Monique led the Engineering Project teamfor one of the first European MPLS VPN deployments in 1999 for a Europeanservice provider

Paris, 2000; MPLSCon 2000, London; MPLS Japan, 2002; APRICOT, Taipei,Taiwan, 2003; MPLScon 2003; Supercomm 2003; MPLS Japan 2003, MPLSJapan 2004; IEEE IPOM in Beijing, 2004; MPLS Conference 2003; The 16thCommunication Systems Workshop (CSWS) on Information, Communication,and Signal Processing ("Verification of Broadband Services and Its Future,"Nov 1213, 2003) by Communications System Engineers in IEICE, Japan;

Monique has been a speaker at the following conferences: MPLS Congress-APRICOT 2004 in Kuala Lumpur; and has spoken at several Cisco Networker

Monique is currently engaged in MPLS OAM standards development and hasbeen engaged in carrier discussions internationally on the topic Monique is co-

IEEE Communications Magazine on the topic "GMPLS: The Promise of the

Next Generation Optical Control Plane," with publication scheduled for July2005

Saul Adler is a systems architect at Cisco Systems, focusing on network

infrastructure security He is currently focused on service provider network

security with a focus on MPLS security requirements As a former vice presidentand network architecture manager for both Bankers Trust and Deutsche Bank,Saul has more than 15 years' experience in designing, deploying, and supportingglobal enterprise networks This includes solutions for supporting the data

center, trading floor, branch office, Internet DMZ, and telecommuters Saulobtained an MSEE from Polytechnic University in Brooklyn, New York

Marc Binderberger is an IP architect at COLT Telecom Plc His focus is

backbone technologies such as routing protocols and MPLS, design and

implementation of Internet and VPN networks, and related security aspects.Marc holds a Ph.D in physics and has eight years' experience in

telecommunication and networking technologies

Y Reina Wang has more than 10 years' experience in the packet switching

network industry as a networking engineer for Bell Labs and AT&T Labs Herarea of expertise aligns on new network feature implementation and realization

in the service provider network scope Her profound and up-to-date knowledge

in IP Multicast, MPLS VPN, MPLS Inter-AS VPN, and Multicast VPN, coupledwith hands-on and practical experience, prepared her as a lead engineer in

enabling these network features in large and complex network environments.Currently working in the IP Network Certification Organization at AT&T Labs,leading for AT&T global IP network feature enablement testing Reina graduatedfrom the Georgia Institute of Technology and earned master's degrees in physicsand electrical engineering

Raymond Zhang is a senior network architect for INFONET in the areas of

global IP backbone infrastructure, routing and service architecture planning, andtheir evolutions Current main areas of interest are large-scale backbone routing,traffic engineering, performance and statistical analysis, MPLS-related

technologies (including PPVPN, interdomain traffic engineering, multiproviderQoS and security, and so on), and multicast

We wish to acknowledge a number of people who have made this book possible,namely our employer, Cisco Systems, and our managers, Christine Hemrick,Steven Steinhilber, Chip Sharp, and Axel Clauberg Without their support, thisbook would not have been written We are grateful to our technical reviewerswho have assured that the content is of quality and relevant to the industry: Y.Reina Wang, AT&T; Marc Binderberger, COLT Telecom; Raymond Zhang,INFONET; and Saul Adler, Cisco Systems We would like to thank these

reviewers for their time and effort Additionally, we would like to acknowledgethe following individuals at Cisco Systems who have contributed to this effort(unknowingly): Azhar Sayeed, Sangita Pandiya, Jim Guichard, Mark Townsley,Gery Czirjak, Thomas Nadeau, George Swallow, Alexander Renner, Laure

Andrieux, Eric Vyncke, Jeff Apcar, and Barry Greene It has truly been a teameffort! We also thank Jayshree Ullal, senior vice president of Security at CiscoSystems, for taking the time out of her very busy schedule to write the foreword

to our book Finally, we are most grateful to our editors and the Cisco PressteamRaina Han, Brett Bartow, Jim Schachterle, Sheri Cain, and Tammi

Barnettfor working diligently with us on this book and keeping it on schedule forpublication

In 1996, Cisco pioneered a concept called tag switching to establish efficient

tags and protocols across a connection-oriented ATM network A decade later,tag switching has permeated into the core of large-scale internetworks usingMPLS (Multiprotocol Label Switching) to become the mainstream standard Inparallel, network security has also evolved from simple access lists and

perimeter firewalls to the creation of remote secure access and tunnels acrossthousands of users and subscribers using VPNs (virtual private networks) Thispowerful combination of security and scale has generated one of the most

versatile solutions for the Internet of the 21st century

At Cisco, the innovations of MPLS VPNs with built-in Cisco IOS services

deliver versatile voice, video, and data access at multigigabit line rates to

achieve successful enterprise and service provider networks The software codebase has grown from several thousand lines to an excess of a million lines, andthe engineering staff has grown from a handful of engineers to more than 1000engineers

There are many components that comprise the Cisco Self-Defending Networksincluding foundational IP protection, threat defense, trust and identity, effectivetransport connectivity, and secure management Large service provider and

enterprise customers are wrestling with the threat models and network scalability

as the adoption of MPLS permeates widely This book offers a unique guide totechnology aspects of MPLS VPN security, providing deployment guidelines forbuilding Internet-class security with real-world case studies It addresses the keypriority for customers: securing and managing services with high network

availability

Over the past decade, internetworks have evolved from adjunct security to

integrated and holistic capabilities, tightly interwoven into the fabric of Ciscoswitches, routers, and appliances The authors of this book, Michael Behringerand Monique Morrow, have a deep and rich understanding of security issuessuch as denial-of-service attack prevention and infrastructure protection fromnetwork vulnerabilities They offer a very practical perspective on the

Jayshree V Ullal

Senior VP/GM Security Tech Group

Cisco Systems, Inc

Icons Used in This Book

The conventions used in this book to present command syntax are the sameconventions used in the IOS Command Reference The Command Referencedescribes these conventions as follows:

Much has been written about MPLS as a technology and service enablerandcertainly, for the past several years, both service providers and enterprises havebeen deploying MPLS in their networks This book focuses on the securityaspects of MPLS VPNs for implementation, and it goes further to discuss notonly MPLS architectural security, but security overall and its impact on

deployment Security, when implemented correctly, enables networks to runbusiness-critical applications, even on a shared infrastructure or on the Internet.Therefore, we have written this book in order to provide best practice guidelinesand to discuss security principles as companies deploy MPLS in their networks.Bear in mind that any network, whether it is a voice, Frame Relay, or ATMnetwork, can be attacked and has been Having an awareness of security and thesecurity requirements for networks and services is the first step toward

mitigating against such attacks

This book is intended for network managers, engineers, and network operationsand security staff of organizations that deploy MPLS or are subscribers of aservice based on MPLS We have provided configuration examples for theoperations team to balance theory with practical examples of the security

principles

Part I, "MPLS VPN and Security Fundamentals," gives the foundations forMPLS VPN security work:

Chapter 1, "MPLS VPN Security: An Overview," gives a short introduction

to the fundamental principles of security and how MPLS VPNs work, andprovides comparison to other VPN technologies It also defines "zones oftrust" for an MPLS VPN environment

Every security project should first define the threats against each trustedzone Chapter 2, "A Threat Model for MPLS VPNs," builds a threat modelwith specific attack points

Chapter 4, "Secure MPLS VPN Designs," explains how to design secure

MPLS VPN networks It gives recommendations on how to implementvarious network topologies securely

Chapter 5, "Security Recommendations," suggests how to operate the

network securely Best practices in securing routers are explained here, andmany examples are given

Part III, "Practical Guidelines to MPLS VPN Security," discusses special cases:

Chapter 6, "How IPsec Complements MPLS," discusses applications ofIPsec in MPLS VPN environments

Chapter 8, "Secure Operation and Maintenance of an MPLS Core," explainshow to manage an MPLS VPN network securely

The book is rounded up by some practical case studies, a configuration example,and resources in Part IV, "Case Studies and Appendixes":

Part I: MPLS VPN and Security Fundamentals

Chapter 1 MPLS VPN Security: An Overview

Chapter 2 A Threat Model for MPLS VPNs

technologies, such as MPLS VPN Further, it develops a security referencemodel for MPLS VPNs that serves as a foundation for terminology and keyconcepts in later chapters.

To be able to analyze and evaluate the security of MPLS networks, it is

important to understand some fundamental security concepts This section

specifically targets network engineers who normally do not work much withsecurity For security engineers, this section serves as a review of the

to be planned into the network from the beginning because various functionalnetworking solutions may have completely different security properties This isalso the reason why security cannot be easily retrofitted into an existing network:Some network design decisions might later complicate network security Forexample, if the address plan of a network is disjoined with contiguous subnetsdistributed over different parts of the company, it is harder to define a consistent

However, companies often have relatively strict separation between the

networking group and the security group Sometimes this separation is

formalized in an organizational structure, but even when both types of engineersare part of the same group, the security engineers and the rest of the group

frequently have communication issues When both groups must jointly managesome parts of a network, frictions can regularly be observed between the groups

The security group is often seen by the networking people as too restrictive, andnetworking people often have the reputation of being too permissive The typicaldiscussion centers on a new security measure, which requires network

management changes The network engineers do not acknowledge the addedvalue of the new measure ("we have never had an issue with this"), while thesecurity group deems it necessary Often there is no objective way to prove theeffectiveness of a security measure

One of the main reasons that it is important for both network and security

engineers to be involved in the network design is that security as a technologyarea is substantially different from other technology areas: To succeed in otherareas, such as wide-area networking, one needs to find a single way among

several options to implement a solution For example, there are many ways tointerconnect two sites, with a number of technologies such as MPLS, ATM, and

so on, and with various routing protocols Many of these options will lead tosuccess, maybe with subtle differences So an engineer can select one of severaloptions and implement it Proving that this solution works is relatively simpleand can be done by simulating user behavior and tools Even if some aspects of atechnology do not work as expected, the solution can often be used anyway.Maybe one routing protocol converges faster than another in the case of an

outage of connections; but in most cases, both protocols will be sufficient for thesolution So in most technologies, there are many possible solutions, and onlyone is required for an implementation

In security, this logic is reversed: a security engineer is successful if no securitybreaches occur This cannot be fully tested, so there is never a full guarantee thatall security mechanisms are configured correctly An intrusion into a VPN, forexample, can occur in many different ways: through a vulnerability in a

In other words, the difference between security and other technologies lies in

how one defines success: A network engineer is successful when he finds one

single way to implement a network A security engineer is unsuccessful if there is one single way to break into the system It is very hard to prove that a security

engineer is successful: only failures are clearly visible

What Is "Secure"?

When talking about security concepts, the first question one needs to answer is,

"What is meant by the term 'secure'"? In fact, there is no global definition for thisconcept In a normal family household, for example, a good door lock is

considered adequate security In a jeweler's shop, a door has to be considerablymore robust to be secure; and in a bank, there might be guards in addition toseveral strong doors So in every scenario, the first step is to define "secure."

Early discussions on MPLS VPN security had exactly this problem: To someusers, "secure" was equivalent to "encryption." Of course, with this definition,MPLS VPNs as such would be insecure Many enterprises, however, do notnecessarily require encryption, and for them "secure" meant essentially

separation from other networks These two viewpoints clashed because theywere based on different definitions for "secure." Based on their respective

angles: from the VPN customer and from the service provider Both possessdifferent threat models: For a customer, it is important to safeguard against

network intrusions from outside of the customer's VPN Therefore, one of themain threats for a VPN customer is intrusions into his or her domain For a

service provider, one of the key issues is availability of the core network Thusone of the main threats is prevention of denial of service (DoS) attacks Bothaspects are important in MPLS VPN scenarios, but each part of the network has

"zones of trust." Each of these zones of trust has its own security policy and itsown threat model

So the formally correct way to define "secure" in a certain context is to start bydefining the zones of trust in a given environment and then to develop a threatmodel for each zone and for the overall environment "Secure" can then be

defined using the requirements coming from the threat model

This book follows this procedure as well: In this chapter, we define the zones oftrust for an MPLS VPN environment, we define a threat model, and in Chapter 3

we define the security requirements Thus, the first three chapters define the term

"secure" for the context of MPLS VPNs and serve as a basis for the rest of thebook

There is no absolute, 100 percent system security despite the fact that singlecomponents of a given system may be 100 percent secure Entire systems cannever be 100 percent secureoften because of the human factor involved

For example, the one-time pad (OTP) in cryptography is a 100 percent secureencryption algorithm Every bit in the clear text is encrypted using a bit from akey string If the key string is as long as the plain text and is never reused, and ifthe bits in the key string are entirely random, the encryption as such is 100

percent secure However, of course, this key string has to be carried from theencrypting to the decrypting side It may be intercepted, or the device used forwriting the message may have a backdoor that allows sniffing the plain text Sothe overall system will never be 100 percent secure

When engineers are asked to work on new projects, they are often given sloppyguidelines such as "it must be secure," without any further explanation One ofthe problems here is, as explained above, that the term "secure" needs to be

defined Second, even if there is a clear understanding of what is meant by theterm "secure" in a certain context, security is not an absolute value and can never

be achieved 100 percent A more reasonable approach is to define a system assufficiently secure against a list of perceived threats This is one of the reasonswhy a security policy must contain a threat model Security must always bemeasured against perceived threats

Three Components of System Security

Many discussions about MPLS VPN security commenced with analysis of thearchitectural aspects of the solution For example, the assertion was made thatnobody can intrude from the outside of a customer network into a customerVPN The technical reason for this was that the service provider core would notaccept labeled packets from outside the service provider network

Then the customer discovered that if an operator misconfigured a provider edge(PE) router, VPN separation would no longer be guaranteed The customer

concluded that MPLS is insecure, but this is an incorrect conclusion because theproblem of the misconfiguration is an operational problem that can happen in

This confusion became apparent when traditional VPN technologies, such asATM, were looked at People had to admit that those technologies had

essentially the same problems, yet they were assumed to be secure So whatwent wrong in these discussions?

The previous OTP example provides an explanation: even if an algorithm isproven to be 100 percent secure, the overall system might still have weaknesses

in other areas

Therefore, when classifying the overall security of a system such as an MPLSVPN network, one has to analyze separately the three fundamental parts thatcompose the system (see Figure 1-1):

The architecture (or algorithm) used This is the formal specification In

cryptography, the algorithm itself, in the case of MPLS VPNs, is the formalspecification (as defined in RFC 2547bis, "BGP/MPLS IP VPNs." See

www.ietf.org/internet-drafts/draft-ietf-13-vpn-rfc2547bis-03.text, which is awork in progress.)

Implementation of that architecture or algorithm This refers to how the

architecture or algorithm is actually implemented in reality Programmingmistakes, such as buffer overflows, play a role here

Operation of the architecture of algorithm This includes operator issues,

such as choosing weak passwords on routers or workstations, or accidentaldisclosure of a shared key, such as if configurations are sent to untrustedthird parties

Figure 1-1 Three Key Components of Security

to understand this separation when defining security policies because the bestalgorithm is useless when operated in a weak way In practice, one can findsystems where a lot of effort was put into securing the architecture, but itsoperation was completely neglected Password management in enterprises is anexample of this: often, very good security systems are rendered useless becauseusers choose weak passwords The designers of such systems should keep inmind that the overall security depends on all three security components

This book keeps these three parts of a system separate: Chapters 3 and 4 focussolely on the architecture as defined in the standard RFC 2547bis In thesechapters, there are no references to implementation or operation at all; the

essential question answered in Chapters 3 and 4 is whether the standard is

secure, or in other words, whether an MPLS VPN network as defined by thestandard can be operated securely Chapters 5 through 8 then describe the

measurement, but quite often, the weakest link is the human factor There aremany well-known cases of this, such as users giving out their passwords freely

to someone calling them on the phone, or configuration errors in otherwise verysecure systems

automated tools have their own problems, but they provide consistency andprevent mistyping and transient mistakes, such as wrong parameters The

specific topic of operations in an MPLS network will be discussed in detail in

Chapter 8, "Secure Operation and Maintenance of an MPLS Core."

Even though the human factor is, in practice, often the weakest link, other parts

of the security system might also be flawed and need to be monitored carefully.The security policy should cover all parts of the system with their potential

weaknesses, and it should be checked regularly The only way to find and

eliminate the weakest link in a network is with consistent monitoring and tightoperational control

Principle of the Least Privilege

Because human mistakes are an important security risk, the most secure way todesign systems is to provide every operator only the authorization strictly

idea is that every privilege an operator or user has might lead to potential

security breaches, and that therefore every privilege must be monitored andcontrolled The less an operator is authorized to do, the less control and

monitoring needs must be done and the smaller the overall risk of security

problems

In this area, MPLS networks do not behave any differently than other networks,and the normal controls for network operations apply equally More information

on how to secure a core network can be found in the book Cisco ISP Essentials

(1-58705-041-2; published by Cisco Press)

The principle of the least privilege was originally devised in the context of

human operators However, the principle of the least privilege can equally beapplied to general network security in that, on a network, everything should berestricted as much as possible For example, it is not necessary for a user outsidethe core network (on the Internet or in a VPN) to send packets to core routers.Only very few protocols must reach the core routers from outside the core

networkrouting protocols are the obvious case (for example, BGP to and fromthe external peers) Therefore, the "privilege" to send traffic into the networkshould be limited from the outside to what is really required, such as routing

This type of traffic filtering is also referred to as infrastructure access control

lists (iACLs) Further discussion on this topic can be found in the book Cisco ISP Essentials, mentioned previously.

Of course, security is a broad field, and it is impossible to capture all the details

in a short introduction However, some additional security concepts are worthmentioning briefly:

Confidentiality, integrity, availability These are the three basic properties

of security (some text books add authenticity as a fourth) When definingsecurity, one can be more precise by defining which of the security

properties is required to which extent For example in a military

environment, the most important security property is probably

confidentiality In a bank, confidentiality is important, too, but even moreimportant is the integrity of the data: it is imperative that no customer datasuch as account balances be accidentally or maliciously changed For anonline shopping site, however, availability of the web page is an importantfactor: every minute the web site is not available leads to direct loss ofrevenue Overall, security can usually be defined using these three

properties

In the MPLS context, every VPN customer will have slightly differentrequirements for these parameters, but generally, customers will expecttheir data to be private (confidential), such that they are not accessibleoutside their VPN They will expect the data not to change in transit, andthey will expect the MPLS VPN service overall to be available to theminother words, that it suffer very few or no outages

Defense in depth Because one weak link is sufficient to endanger the

security of an overall system, it is common practice to construct several

"layers" of security around a solution, such that if one single componentbreaks, others still defend the assets The best example of this in enterprisenetworks is the demilitarized zone (DMZ) In a DMZ, a company's serversare usually highly protected; however, even if this protection fails and ahacker gains access to a server, there is still a firewall to overcome to getinto the network

It is good practice to add several layers of defense around everything that

Secure failure The primary mode of operation of any technology is usually

well thought through and well secured However, when the primary methodfails, the backup method also needs to be secured appropriately It is

common practice today to use secure shell (SSH) for router configuration;however, a backup method of getting to a router is necessary in case theSSH server fails, for example This is usually done through out-of-bandaccess, mostly over the telephone network It is important that this backupmode be as secure as the principal access mode

There is ample literature available for more detail on security in general and inthe networking context Please refer to Appendix B for recommendations

It is difficult to define precisely what constitutes a virtual private network (VPN)because the term means different things to different people To some people,separation of their traffic on a network is sufficient to call it "private"; othersexpect encryption when they hear the word "private." The opposite seems

clearer: a private network is strictly speaking completely separate from othernetworks Of course, with this definition almost any network invented after thetelegraph system in 1837 by Samuel Morse would be a virtual network Today's

"private" leased lines, for example, use a shared SONET or Synchronous DigitalHierarchy (SDH) infrastructure, and the physical lines or fibers carry manydifferent "private" networks

For any practical discussion in the context of MPLS, ATM, Frame Relay, andother VPN technologies, operators currently understand that services deliveredover SONET or SDH are regarded as private because separation over these

carrier technologies is so efficient that users cannot detect the sharing of corefibers

VPNs thus exist in many different forms and have been classified in a variety ofways All of these classifications exist because of different user requirements.VPN technologies can also be used in a nested way, that is, over an existingVPN such as a company intranet where it is possible to further define moredetailed VPNs

The criteria that distinguish VPN technologies from each other include the

following:

Connection-oriented/connectionless technologies Many VPN

technologies are connection oriented That means that a VPN user whoconnects to the VPN service appears to have a connection to another VPNuser Examples for connection-oriented VPNs are IPsec, GRE, and IP-in-IP.Also point-to-multipoint technologies, such as multipoint GRE (mGRE),introduced in IOS Version 12.2T, are essentially connection oriented, even

if the other endpoints might not be configured but discovered dynamically

equipment) does not have a direct relationship with any other VPN user;rather, it is connected to the MPLS service as a "cloud," which ensures thatpackets are forwarded correctly to the other VPN user site Specifically, aVPN user does not have explicit knowledge of other VPN users This is one

of the key advantages of MPLS IP VPNs: they scale very well because lessVPN information needs to be kept at the edge Figure 1-2 shows the

or secure sockets layer (SSL) are on the increase MPLS is by default

nonencrypting Encryption can be added (using PE-PE IPsec, for example)

Internet based/not Internet based Some VPN types can be used over the

public Internet and thus allow easy interconnection of sites worldwide,assuming availability of Internet services in these locations IPsec, GRE,IP-in-IP, TLS, and SSH are examples of VPN technologies that can be usedover the Internet The advantage of Internet-based VPN types is their

acceptable to use a simple tunneling technique, such as GRE or IP-in-IP, to beable to interconnect sites over the public Internet For larger companies, this type

of VPN would be harder to manage for scalability reasons; they might preferMPLS-based VPNs to keep their network simpler and easier to manage Fororganizations dealing with secret information, confidentiality would be essential,and they would use some encrypting VPN technology such as IPsec

Several VPN technologies can be used together in one common solution This isbeing done where different technologies address different needs For example,IPsec VPNs can be used on top of an MPLS VPN This type of architecture isnot necessarily redundant: IPsec might be chosen because there is a need forconfidentiality on the data path Many European countries, for example, by lawrequire encryption of personal data over any public data network, and this isoften addressed by using IPsec However, the organization still requires

connectivity between its sites for its IPsec traffic to pass between the offices.This could be addressed over the public Internet, but also over ATM, FrameRelay VPN services, or MPLS Each of these options has its advantages anddisadvantages, but MPLS VPN services have been used often in the past due toconsistent service guarantees not available on the public Internet, as well as tooften better prices than on other VPN technologies

To understand MPLS VPN technology, it is important to know its basic

concepts This section explains the nomenclature used in MPLS VPN networksand how MPLS works in simple terms One important differentiator of MPLSnetworks is that they employ a connectionless VPN technology The concepts ofMPLS and VPN technology are explained here

Nomenclature of MPLS VPNs

RFC 2547bis, "BGP/MPLS IP VPNs," describes the nomenclature and

definitions used in the MPLS VPN framework More precisely, it defines IPVPNs, meaning that the VPN service accepts IP datagrams from customer sitesand delivers them also as IP datagrams to other customer sites The connection

For the remainder of this book, the term "MPLS VPN" will be used for the type

of VPN defined in RFC 2547bis unless explicitly stated otherwise

This book uses the same nomenclature as the RFCs; they are listed here for yourreference:

Service provider The organization providing an MPLS VPN service to a

customer

Customer An organization receiving an MPLS VPN service from the

enterprise or set of enterprises, an application service provider, or otherorganizational entities

Figure 1-3 shows an MPLS VPN network with connected VPNs The core

consists of PE and P routers Customer routers (CEs) connect to the PEs One PEcan hold several CEs of different VPNs or the same VPN

Figure 1-3 MPLS VPN Structure

[View full size image]