Download pdf - IPSEC VPN Fundamentals

7/13/2019 IPSEC VPN Fundamentals

1/480

From the Library of Ahmed


2/480

800 East 96th Street

Indianapolis, Indiana 46240 USA

Cisco Press

IPsec Virtual Private NetworkFundamentals

James Henry Carmouche, CCIE No. 6085

From the Library of Ah


3/480

ii

IPsec Virtual Private Network FundamentalsJames Henry Carmouche, CCIE No. 6085

Copyright 2007 Cisco Systems, Inc.

Published by:Cisco Press800 East 96th StreetIndianapolis, IN 46240 USA

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical,including photocopying, recording, or by any information storage and retrieval system, without written permission from the pub-lisher, except for the inclusion of brief quotations in a review.

Printed in the United States of America 1 2 3 4 5 6 7 8 9 0

First Printing June 2006

Library of Congress Cataloging-in-Publication Number: 2004107143

ISBN: 1-58705-207-5

Trademark AcknowledgmentsAll terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Pressor Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affectingthe validity of any trademark or service mark.

Warning and DisclaimerThis book is designed to provide information about IPsec virtual private networks. Every effort has been made to make this book ascomplete and as accurate as possible, but no warranty or fitness is implied.

The information is provided on an as is basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither liability norresponsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or fromthe use of the discs or programs that may accompany it.

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

Corporate and Government SalesCisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales.

For more information please contact: U.S. Corporate and Government Sales [email protected]

For sales outside the U.S. please contact: International Sales [email protected]

Feedback InformationAt Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and pre-cision, undergoing rigorous development that involves the unique expertise of members from the professional technical community.

Readers feedback is a natural continuation of this process. If you have any comments regarding how we could improve the qualityof this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Pleasemake sure to include the book title and ISBN in your message.

We greatly appreciate your assistance.



4/480

iii

Publisher Paul Boger

Cisco Representative Anthony Wolfenden

Cisco Press Program Manager Jeff Brady

Executive Editor Brett Bartow

Production Manager Patrick KanouseDevelopment Editor Andrew Cupp

Project Editor Interactive Composition Corporation

Copy Editor Interactive Composition Corporation

Technical Editors Aamer Akhter, Jason Guy, Mark J. Newcomb

Editorial Assistant Katherine Linder

Book and Cover Designer Louisa Adair

Composition Interactive Composition Corporation

Indexer Tim Wright



5/480

iv

About the AuthorJames Henry Carmouche, CCIE No. 6085,is a technical marketing engineer on the Cisco

Enterprise Systems Engineering team, where he is currently responsible for architecting,

constructing, and validating enterprise-class network systems solutions. As part of his solution

development responsibilities, Henry researches and publishes solution reference designs for use

by customers, technical sales staff members, and marketing staff members. Prior to joining ESE,

Henry worked as a technical marketing engineer in the Cisco Government Systems Unit, where

he was responsible for bringing advanced security products to market, building technical

marketing collateral and presentations, and designing new product introduction training for the

GSUs newly introduced security platforms. In addition to his product and solution development

experience, Henry has more than six years of technical consulting experience, including three

years as a network consulting engineer in the Cisco Advanced Services Group. Henry earned an

M.B.A. degree from UNCs Kenan-Flagler Business School and a B.S. degree in mechanical

engineering from Lehigh University. Henry currently lives in Chapel Hill, NC, with his wife and

two sons.

About the Technical ReviewersAamer Akhter, CCIE No. 4543,joined Cisco Systems in 1998 after graduating from Georgia

Tech with a B.S. degree in electrical engineering to work in the Cisco Technical Assistance Center.

He then supported the larger enterprise customers from Cisco in the NSA unit, where he helped

design and deploy several large Layer 2 networks. Aamer later moved to Networked Solutions

Integration Test Engineering (NSITE), where after a brief stint with IPsec VPNs, he moved into a

new group for testing MPLS-VPNs. Five years later, MPLS-VPNS had matured much but testing

of MPLS-related technologies still continues. Aamer is currently leading a team for testing Layer3 VPNs and related technologies in a cross-Cisco effort.

Jason Guyis an engineer within the Cisco Systems NSITE Security team, an organization

responsible for network-based security solution testing. Jason is a member of a team responsible

for testing, validating, scaling, and assisting in deployment of the Cisco security solution. Jasons

primary focus is on firewalls, IPsec Remote Access, and SSL VPN testing. Prior to his work on the

security technologies, Jason worked on the AToM Layer 2 VPN and MPLS VPN teams. Jason

received his Masters of Computer Engineering degree from North Carolina State University in

Raleigh, NC.

Mark J. Newcomb, CCNP, CCDP,is a retired network security engineer. Mark has more than

20 years experience in the networking industry, focusing on the financial and medical industries.

Mark is a frequent contributor and reviewer for Cisco Press books.



6/480

v

DedicationFor my loving wife, Kristen, and my two wonderful sons, James and Charlie. This would not have

been possible without your unconditional love, support, and inspiration.



7/480

vi

AcknowledgmentsDuring the development of this book, I had the privilege to work in three different groups at Cisco.

Thank you to all of my teammates in Enterprise Systems Engineering, the Government Systems

Unit, and Advanced Services who have lent me your professional acumen and loyal friendship

over the years.

Id like to thank Mike OShea for his support and friendship over the course of developing this

book. Mikes sound professional and personal advice have helped me endure the ebbs and flows

of sanity while balancing a challenging workload and added development responsibilities

associated with writing this book.

Thank you to Pavan Reddy, one of the sharpest technical minds in Advanced Services, who was

instrumental in helping me outline and define this scope of work and whose technical advice and

words of encouragement throughout the course of developing this book have proven to be

invaluable.

And on that note, many thanks go out to Andrew Cupp and Brett Bartow for their patience,

understanding, and support during this process. An author could not have asked for a more

professional team to work with while developing and publishing his work.



8/480

vii

This Book Is Safari EnabledThe SafariEnabled icon on the cover of your favorite technology book

means the book is available through Safari Bookshelf. When you buy this

book, you get free access to the online edition for 45 days.

Safari Bookshelf is an electronic reference library that lets you easily search

thousands of technical books, find code samples, download chapters, and

access technical information whenever and wherever you need it.

To gain 45-day Safari Enabled access to this book:

Go to http://www.ciscopress.com/safarienabled

Complete the brief registration form

Enter the coupon code 6LL4-NBLJ-5EK4-HDJP-PKVQIf you have difficulty registering on Safari Bookshelf or accessing the online

edition, please e-mail [email protected].

http://www.ciscopress.com/safarienabledhttp://www.ciscopress.com/safarienabled


9/480

viii

Contents at a Glance

Introduction xvii

Part I Introductory Concepts and Configuration/Troubleshooting 3

Chapter 1 Introduction to VPN Technologies 5

Chapter 2 IPsec Fundamentals 35

Chapter 3 Basic IPsec VPN Topologies and Configurations 105

Chapter 4 Common IPsec VPN Issues 141

Part II Designing VPN Architectures 205

Chapter 5 Designing for High Availability 207

Chapter 6 Solutions for Local Site-to-Site High Availability 235

Chapter 7 Solutions for Geographic Site-to-Site High Availability 267

Chapter 8 Handling Vendor Interoperability with High Availability 297

Chapter 9 Solutions for Remote-Access VPN High Availability 313

Chapter 10 Further Architectural Options for IPsec 359

Part III Advanced Topics 389

Chapter 11 Public Key Infrastructure and IPsec VPNs 391

Chapter 12 Solutions for Handling Dynamically Addressed Peers 417

Appendix A Resources 449

Index 452



10/480

ix

Contents

Introduction xvii

Part I Introductory Concepts and Configuration/Troubleshooting 3

Chapter 1 Introduction to VPN Technologies 5VPN Overview of Common Terms 5

Characteristics of an Effective VPN 6

VPN Technologies 9

Virtual Private Dialup Networks 10

Layer 2 Forwarding Protocol 10

Point-to-Point Tunneling Protocol 12

Layer 2 Tunneling Protocol 16

Multiprotocol Label Switching VPNs 18

IPsec VPNs 20

Transport Layer VPNs 21Secure Socket Layer VPNs 21

Transport Layer Security and SSL VPNs 25

Common VPN Deployments 25

Site-to-Site VPNs 25

Remote Access VPNs 28

SSL in RAVPN Architectures 28

Business Drivers for VPNs 29

Remote Access VPN Business DriversA Practical Example 30

Site-to-Site VPN Business DriversA Practical Example 30

IPsec VPNs and the Cisco Security Framework 31

Summary 32

Chapter 2 IPsec Fundamentals 35

Overview of Cryptographic Components 35

Asymmetric Encryption 36

Symmetric Encryption 39

Message Authentication, Message Integrity, and Sender Nonrepudiation Mechanisms 42

Hashing and Message Digests 42

Digital Signatures 44

Public Key Encryption Methods 46

RSA Public-Key Technologies 48

RSA Encryption 48RSA Signatures 50

Diffie-Hellman Key Exchange 51

The IP Security Protocol (IPsec) 51

IPsec Modes 52

Transport Mode 52

Tunnel Mode 54



11/480

x

IPsec Transforms 55

ESP 55

AH 57

IP Payload Compression Protocol (IPPCP) and LZS 58

IPsec SA 59

IPsec Configuration Elements 63

Creating an IPsec Transform 63

Crypto Map Configuration 66

Manual Keying 68

The Need for Security Association and Key Management 77

IKE and ISAKMP 78

IKE and ISAKMP Terminology and Background 78

IKE SA Negotiation and Maintenance 79

IPsec Diffie-Hellman Shared Secret Key Generation Using IKE 79

IKE Authentication Services 83

Pre-Shared Keys 83RSA Encryption (Encrypted Nonces) 85

RSA Signatures and X.509 Certificates 86

IKE Phase I Negotiation 87

Main Mode 88

Aggressive Mode 89

IKE Phase II Negotiation 90

Quick Mode 90

PFS 91

Dead Peer Detection and IKE Keepalives 92

Configuring ISAKMP 94

IKE with RAVPN Extensions 96Mode Configuration 96

X-Auth 98

Summary 100

Chapter 3 Basic IPsec VPN Topologies and Configurations 105

Site-to-Site IPsec VPN Deployments 107

Site-to-Site VPN Architectural Overview for a Dedicated Circuit 107

Cisco IOS Site-to-Site IPsec VPN Configuration 108

Verifying Cisco IOS Site-to-Site IPsec VPN Operation 111

Site-to-Site Architectural Overview over a Routed Domain 117

Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) 121Site-to-Site IPsec+GRE Architectural Overview 121

Increased Packet Size and Path MTU Considerations 122

GRE and Weighted Fair Queuing 122

QoS and the IPsec Anti-Replay Window 122



12/480

xi

Site-to-Site IPsec+GRE Sample Configurations 123

Cisco IOS Site-to-Site IPsec+GRE Configuration 123

Verification of IPsec+GRE Tunnel Establishment 126

Hub-and-Spoke IPsec VPN Deployments 128

Hub-and-Spoke Architectural Overview 129Standard Hub-and-Spoke Design without High Availability 129

Clustered Spoke Design to Redundant Hubs 130

Redundant Clustered Spoke Design to Redundant Hubs 131

Remote Access VPN Deployments 132

RAVPN Architectural Overview 132

RAVPN Clients 132

Standalone VPN Concentrator Designs 133

VPN Concentrator on Outside Network with Single DMZ 133

VPN Concentrator and Firewall in Parallel 134

VPN Concentrator with Dual DMZs to Firewall 135

What to Avoid in DMZ/VPN Concentrator Topologies 136Clustered VPN Concentrator Designs 137

Summary 138

Chapter 4 Common IPsec VPN Issues 141

IPsec Diagnostic Tools within Cisco IOS 141

Common Configuration Issues with IPsec VPNs 142

IKE SA Proposal Mismatches 142

IKE Authentication Failures and Errors 146

IKE Authentication Errors and PSKs 146

IKE Authentication Errors with RSA Encryption 151

IKE Authentication Errors with RSA Signatures 158IPsec SA Proposal Mismatches 165

Crypto-Protected Address Space Issues (Crypto ACL Errors) 169

Architectural and Design Issues with IPsec VPNs 171

Troubleshooting IPsec VPNs in Firewalled Environments 171

Allowing the Required IPsec Protocols to Pass 171

Firewalls Handling of Fragmented IPsec Packets 173

Filtering of ICMP Unreachables 174

NAT Issues in IPsec VPN Designs 174

Intrinsic IPsec/NAT Incompatibilities 175

IPsec NAT Transparency (NAT-T) 178

SPI-Based NAT 179The Influence of IPsec on Traffic Flows Requiring QoS 180

IPsecs Influence on DiffServ and LLQ/CBWFQ 181

IPsecs Effect on IntServ and RSVP 183



13/480

xii

Solving Fragmentation Issues in IPsec VPNs 183

Path MTU Discovery 184

Fragmentation Behavior on Cisco IOS VPN Endpoints 189

Solutions for Preventing Fragmentation 193

The Effect of Recursive Routing on IPsec VPNs 197

Summary 200

Part II Designing VPN Architectures 205

Chapter 5 Designing for High Availability 207

Network and Path Redundancy 208

IPSec Tunnel Termination Redundancy 210

Multiple Physical Interface HA with Highly Available Tunnel Termination Interfaces 210

Tunnel Termination HA Using HSRP/VRRP Virtual Interfaces 211

HA with Multiple Peer Statements 212

RP-based IPSec HA 214

Managing Peer and Path Availability 215Peer Availability 216

Path Availability 218

Managing Path Symmetry 219

Load Balancing, Load Sharing, and High Availability 222

Load-Sharing with Peer Statements 222

Routing 224

Domain Name System (DNS) 225

Cisco VPN3000 Concentrator Clustering 227

IPSec Session Load-Balancing Using External Load Balancers 230

Summary 232

Chapter 6 Solutions for Local Site-to-Site High Availability 235

Using Multiple Crypto Interfaces for High Availability 235

Impact of Routing Protocol Reconvergence on IPsec Reconvergence 238

Impact of Stale SAs on IPsec Reconvergence 240

Impact of IPsec and ISAKMP SA Renegotiation on IPsec Reconvergence 241

Stateless IPsec VPN High-Availability Alternatives 242

Solution Overview for Stateless IPsec High Availability 242

Hot Standby Routing Protocol 244

RRI 245

Stateless High Availability Failover Process 246

Step 1: Initial IPsec VPN Tunnel Establishment 247

Step 2: Pre-HSRP RRI Execution 251

Step 3: Active Router Failure 254

Step 4: HSRP Reconvergence 254

Step 5: IPsec Reconvergence 255

Step 6: Post-HSRP RRI Execution 257



14/480

xiii

Stateful IPsec VPN High-Availability Alternatives 257

Solution Overview for Stateful IPsec High Availability 258

HSRP and RRI 259

Stateful Switchover (SSO) and IPsec High Availability 259

Stateful High Availability Failover Process 261Step 1: Initial IPsec VPN Tunnel Establishment 261

Step 2: SADB Synchronization with SSO 261

Step 3: Pre-HSRP Failover RRI Execution 262

Step 4: Active Router Failure 262

Step 5: HSRP Reconvergence 262

Step 6: IPsec Reconvergence 262

Step 7: Post-HSRP RRI Execution 263

Summary 263

Stateless IPsec VPN High Availability Design Summary 263

Stateful IPsec VPN High Availability Design Summary 265

Chapter 7 Solutions for Geographic Site-to-Site High Availability 267

Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 267

Solution Overview for RRI with Multiple IPsec Peers 267

Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing

Protocols 278

Solution Overview for IPsec+GRE with Encrypted Routing Protocols 279

Dynamic Multipoint Virtual Private Networks 287

DMVPN Solution Design Drivers 288

DMVPN Component-Level Overview and System Operation 289

Summary 295

Chapter 8 Handling Vendor Interoperability with High Availability 297Vendor Interoperability Impact on Peer Availability 297

The Inability to Specify Multiple Peers 297

Lack of Peer Availability Mechanisms 300

Vendor Interoperability Impact on Path Availability 301

IPSec HA Design Considerations for Platforms with Limited Routing

Protocol Support 302

IPSec HA Design Considerations for Lack of RRI Support 304

IPSec HA Design Considerations for Lack of Generic Routing Encapsulation (GRE)

Support 305

Vendor Interoperability Design Considerations and Options 306Phase 1 and 2 SA Lifetime Expiry 307

SADB Management with Quick Mode Delete Notify Messages 307

Invalid Security Parameter Index Recovery 308

Vendor Interoperability with Stateful IPSec HA 309

Summary 311



15/480

xiv

Chapter 9 Solutions for Remote-Access VPN High Availability 313

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel

Termination 314

IPsec RAVPN Concentrator High Availability Using VRRP 315

IPsec RAVPN Concentrator HA Using HSRP 327IPsec RAVPN Concentrator HA Using the VCA Protocol 333

IPsec RAVPN Geographic HA Design Options 342

VPN Concentrator Session Load Balancing Using DNS 343

VPN Concentrator Redundancy Using Multiple Peers 345

Summary 355

Chapter 10 Further Architectural Options for IPsec 359

IPsec VPN Termination On-a-Stick 359

IPsec with Router-on-a-Stick Design Overview 359

Single, Flatly Addressed L3 Domain 360

Lack of In-Path Design Options 361Single Interface to the Bridged LAN 361

Crypto-Enabled Loopback Interface 361

Case Study: Small Branch IPsec VPN Tunnel Termination with NAT On-a-Stick 362

In-Path Versus Out-of-Path Encryption with IPsec 368

Out-of-Path Encryption Design Overview 370

Case Study: Firewalled Site-to-Site IPsec VPN Tunnel Termination 370

Separate Termination of IPsec and GRE (GRE-Offload) 379

GRE-Offload Design Overview 379

Lack of Support for GRE Processing 380

Low GRE Performance 380

Case Study: Large-Scale IPsec VPN Tunnel Termination with GRE Offload 382Dynamic Crypto Maps and GRE-Offload 383

IKE Extended Authentication (X-Auth) 384

Firewalled Cleartext Traffic 385

High-Speed GRE Tunnel Termination for GRE-Offload 385

Summary 386

Part III Advanced Topics 389

Chapter 11 Public Key Infrastructure and IPsec VPNs 391

PKI Background 391

PKI Components 394

Public Key Certificates 394

Registration Authorities 395

Certificate Revocation Lists and CRL Issuers 396

Certificate Authorities 397

PKI Cryptographic Endpoints 397



16/480

xv

Life of a Public Key Certificate 397

RSA Signatures and X.509v3 Certificates 397

Generating Asymmetric Keypairs on Cryptographic Endpoints 402

Registration and Endpoint Authentication 402

Receipt and Authentication of the CAs Certificate 403Forwarding and Signing of Public Keys 403

Obtaining and Using Public Key Certificates 403

PKI and the IPSec Protocol SuiteWhere PKI Fits into the IPSec model 404

OCSP and CRL Scalability 404

OCSP 405

Case Studies and Sample Configurations 405

Case Study 1: PKI Integration of Cryptographic Endpoints 407

Case Study 2: PKI with CA and RA 410

Case Study 3: PKI with Redundant CAs (CA Hierarchy) 412

Summary 414

Chapter 12 Solutions for Handling Dynamically Addressed Peers 417

Dynamic Crypto Maps 417

Dynamic Crypto Map Impact on VPN Behavior 418

Dynamic Crypto Map Impact on ISAKMP/IKE 418

Routing Considerations with Dynamic Crypto Maps 419

Security Considerations for Dynamic Crypto Maps 421

Dynamic Crypto Map Configuration and Verification 425

Tunnel Endpoint Discovery 430

TED Configuration and Verification 432

Case StudyUsing Dynamic Addressing with Low-Maintenance Small Home Office

Deployments 432Summary 446

Appendix A Resources 449

Books 449

RFCs 449

Web and Other Resources 450

Index 452



17/480

xvi

Command Syntax ConventionsThe conventions used to present command syntax in this book are the same conventions used in

the IOS Command Reference. The Command Reference describes these conventions as follows:

Boldface indicates commands and keywords that are entered literally as shown. In actual

configuration examples and output (not general command syntax), boldface indicates

commands that are manually input by the user (such as a showcommand).

Italicsindicate arguments for which you supply actual values.

Vertical bars (|) separate alternative, mutually exclusive elements.

Square brackets [ ] indicate optional elements.

Braces { } indicate a required choice.

Braces within brackets [{ }] indicate a required choice within an optional element.



18/480

xvii

IntroductionIn recent years, network security solutions have grown to include IPsec as a critical component

of secure network architecture design. One primary objective of this publication is therefore

to provide the reader with a basic working knowledge of IPsec on various Cisco routing and

switching platforms and an understanding of the different components of the Cisco IPsec

implementation. This book covers successful implementation of IPsec in a variety of network

topologies. This book views IPsec as an emerging requirement in most major vertical markets

(service provider, enterprise financial, government), explaining the need for increased information

authentication, confidentiality, and non repudiation for secure transmission of confidential data

(government records, financial data, billing information).

The primary development objective of this book is to create a work that aids network architects,

administrators, and managers in their efforts to integrate IPsec VPN technology into their existing

IP infrastructures. The focus is on IPsec deployments in Cisco network environments, from simple

site-to-site virtual private network (VPN) configurations to comprehensive VPN strategies,including architectural redundancy and interoperability.

MethodologyThis book follows a tiered approach toward building a working knowledge of fundamental IPsec

VPN design, starting with an overview of basic IPsec business drivers and functional components.

These concepts and components are then used as a foundation upon which IPsec VPN High

Availability (HA) design considerations are presented. Lastly, several advanced IPsec VPN

technologies that are commonly available in todays enterprise networks are presented and

discussed. Within each chapter, the design concepts are presented and then reinforced withconfigurations, illustrations, and practical case studies where appropriate.

Who Should Read This Book?This book presents information for technically savvy individuals who want to further their

understanding of the fundamentals of this specific technology. Those parties interested in this

book most likely include network engineers, network design consultants, network administrators,

systems administrators, information security specialists, and all other individuals who have an

interest in securing their networks with Cisco routers and VPN products. Additionally, networking

professionals who have an understanding of IPsec and also want to view typical Cisco specific

IPsec configurations and practical IPsec deployment examples on Cisco products may also find

the design guidance provided in this book valuable. Because it provides information at a

fundamental level, this book may also serve as an effective design reference for decision makers

looking to make strategic decisions impacting the security of their organizations network.



19/480

xviii

How This Book Is OrganizedThe organization of the book is formatted in a layered approach, starting with a basic explanation

of the motivation behind IPsecs development and the types of organizations that rely on IPsec to

secure data transmissions. The book then proceeds to outline the basic IPsec/Internet Security

Association and Key Management Protocol (ISAKMP) fundamentals that were developed to meetdemand for secure data transmission. The book proceeds to cover the design and implementation

of IPsec VPN architectures using an array of Cisco products, starting with basic concepts and

proceeding to more advanced topics, including HA solutions and public key infrastructure (PKI).

Sample topology diagrams and configuration examples are provided to help reinforce the

fundamentals expressed in the text, and to assist the reader in translating explained IPsec concepts

into practical working deployment scenarios. Case studies are incorporated throughout the text in

order to map the topics and concepts discussed to real-world solutions.

Chapters 1 through 4 compose Part I of this book, covering the most basic concepts required to

develop an understanding of IPsec VPNs. The chapter content provided in Part I aims to help thereader achieve the following objectives:

Understand the background of IPsec VPN development

Differentiate IPSEC/SSL VPN from other VPN technologies

Understand the underlying cryptographic technologies that compose an IPsec VPN

Understand basic IPsec VPN configuration techniques

Understand common issues that can affect all IPsec designs

After you are familiar with the content of Part I, you should have the working knowledge of IPsec

VPNs necessary to begin building a knowledge base surrounding the fundamentals of IPsec VPNHigh Availability using the design concepts provided in Part II. The chapters in Part I include:

Chapter 1, Introduction to VPN TechnologiesThis chapter includes an introduction

to various VPN technologies, discusses how VPNs are utilized in todays networks, and

identifies the drivers for business migration to VPN technologies. The discussion in this

chapter provides the reader with a high-level overview of VPN, particularly with a

comparison between Multiprotocol Label Switching (MPLS), Virtual Private Dialup Network

(VPDN), Secure Sockets Layer (SSL), and IPsec VPNs. After a brief comparison of the VPN

technologies, the focus turns to the business drivers for VPN, which include both economics

and security.

Chapter 2, IPsec FundamentalsThis chapter focuses on the underlying components

and mechanics of IPsec, including cryptographic components, Internet Key Exchange (IKE),

and IPsec. This chapter includes basic configuration examples (not step-by-step) to

demonstrate the concepts.



20/480

xix

Chapter 3, Basic IPsec VPN Topologies and ConfigurationsThis chapter

demonstrates building of basic VPN topologies using the knowledge gained in the previous

chapters. Three basic topologies are discussed: hub-and-spoke without generic routing

encapsulation (GRE), hub-and-spoke VPN with GRE, and remote-access VPN.

Chapter 4, Common IPsec VPN IssuesIPsec deployments can involve a number ofpotential pitfalls if not properly addressed. Chapter 4 discusses the common IPsec VPN issues

that a network engineer should take into consideration during the design and deployment

process. It discusses common troubleshooting techniques to diagnose these problems should

they occur in your network. Design solutions to the common VPN issues presented in this

chapter are provided, along with the appropriate design verification techniques.

Part II consists of Chapters 5 through 10. The topics discussed here build on the introductory

concepts from Part I, extending them to encompass a common architectural goal: High

Availability. Additional architectural variations are provided so as to present a comprehensive

scope of design options available. The chapters in Part II include:

Chapter 5, Designing for High AvailabilityThis chapter discusses the basic principles

of an HA VPN design. Based on these principles, subsequent chapters develop solutions for

local and geographical HA and discuss issues and options for achieving HA in multi-vendor

VPN environments.

Chapter 6, Solutions for Local Site-to-Site High AvailabilityThis chapter uses

concepts previously described to develop solutions for local HA, including the use of highly

available interface for IPsec tunnel termination, stateless tunnel termination HA, and stateful

tunnel termination HA.

Chapter 7, Solutions for Geographic Site-to-Site High AvailabilityThis chapter usesconcepts previously described to develop solutions for geographic HA. This chapter discusses

RRI, IPsec with GRE tunnels, and Dynamic Multipoint VPN.

Chapter 8, Handling Vendor Interoperability with High AvailabilityUnfortunately,

current IPsec standards do not address HA. This leads to interoperability issues among

vendors. This chapter discusses common issues and details the options that exist to handle

these scenarios.

Chapter 9, Solutions for Remote Access VPN High AvailabilityThis chapter discusses

the HA concepts previously discussed in Chapters 6 and 7 in the context of RAVPN

deployments. Additionally, it covers other HA tools commonly found in RAVPNs, including

the use of VPN concentrator clustering with VCA and DNS-based load balancing.

Chapter 10, Further Architectural Options for IPsecThis chapter discusses other

architectural variations in designing VPN solutions. It describes each option with usage

considerations and finishes with case studies of each.



21/480

xx

IPsec VPN design concepts range from fundamental cryptographic operations to dynamic spoke-

to-spoke peering and MPLS VPN routing and forwarding (VRF)-Aware IPsec VPNS. Although

the scope of this book is firmly centered around the fundamental concepts of IPsec VPN design,

the chapters included in Part III provide design guidance around two advanced topics of IPsec that

are quite commonly deployed in todays enterprise-class IP networks:

Chapter 11, Public Key Infrastructure and IPsec VPNsThis chapter discusses the

usage of public key infrastructure (PKI) to authenticate IPsec peers via Rivest, Shamir, and

Adelman (RSA) signatures. This method uses a certificate authority as a trusted third party to

secure and scale IKE authentication. As organizations become more Public Key Infrastructure

(PKI)-aware, this will become the de facto authentication mechanism.

Chapter 12, Solutions for Handling Dynamically Addressed PeersDynamic peers

allow network administrators to ensure network connectivity when remote network peers are

either not known in advance or change to an unknown value over time. Dynamic peers also

require less administrative effort than do static peers. This chapter addresses IPsec dynamicpeering options, some of which are less commonly used, and others that are more prolific in

various architectures.



22/480

This page intentionally left blank



23/480



24/480

Part I: Introductory Concepts and

Configuration/Troubleshooting

Chapter 1 Introduction to VPN Technologies

Chapter 2 IPsec Fundamentals

Chapter 3 Basic IPsec VPN Topologies and Configurations

Chapter 4 Common IPsec VPN Issues



25/480



26/480

C H A P T E R 1

Introduction to VPN

Technologies

Modern business environments have been consistently changing since the advent of the Internet

in the 1990s. Now more than ever, organizational leaders are asking themselves how efficiencies

can be gained through making their workforce more mobile and thus increasing the scope of

sales and distribution channels while continuing to maximize the economies of scope in their

existing data infrastructure investments. Virtual private network (VPN) technologies provide

a means by which to realize these business efficiencies in tandem with greatly reduced IT

operational expenditures. In this chapter, we will discuss how todays VPN technologies enable

enterprise workforces to share data seamlessly and securely over common yet separately

maintained network infrastructures, such as through an Internet service provider (ISP) between

enterprise networks or with corporate extranet partners. We will introduce several IPsec VPN

topologies commonly found in todays enterprise networks, and we will conclude with the

overview of two IPsec VPN business models, complete with cost savings realized by the

enterprise.

VPN Overview of Common TermsA VPNis a means to securely and privately transmit data over an unsecured and shared network

infrastructure. VPNs secure the data that is transmitted across this common infrastructure by

encapsulating the data, encrypting the data, or both encapsulating the data and then encrypting

the data. In the context of VPN deployments, encapsulation is often referred to as tunneling, as

it is a method that effectively transmits data from one network to another transparently across a

shared network infrastructure.

A common encapsulationmethod found in VPNs today is Generic Routing Encapsulation

(GRE). IP-based GRE is defined in IETF RFC 2784 as a means to enclose the IP header and

payload with a GRE-encapsulation header. Network designers use this method of encapsulationto hide the IP header as part of the GRE-encapsulated payload. In doing so, they separate or

tunnel data from one network to another without making changes to the underlying common

network infrastructure. Although GRE tunnels have primitive forms of authentication, as well

explore in later chapters when discussing dynamic multipoint VPN (DMVPN) deployments,

they currently provide no means to provide confidentiality, integrity, and non-repudiation

natively. Nevertheless, GRE tunneling is a fundamental component of many different IP

Security Protocol (IPsec) designs, and will be discussed frequently in subsequent chapters.



27/480

6 Chapter 1: Introduction to VPN Technologies

Encryptionrefers to the act of coding a given message into a different format, while decryptionrefers to decoding an encrypted message into its original unencrypted format. For encryption to

be an effective mechanism for implementing a VPN, this encrypted, encoded format must only

be decipherable by those whom the encrypting party trusts. In order to deliver upon these

requirements, encryption technologies generally require the use of a mathematical operation,

usually referred to as an algorithm, or cipher, and a key. Although generally complex in nature,

mathematical functions are known. It is the symmetric key, or as youll see in the case of

asymmetric cryptography, the private key, that is to be kept unknown to would-be attackers. The

key is the primary way to keep the encrypted tunnel secure. This book discusses these two

common types of cryptographic operations: symmetric key encryption and asymmetric key

encryption. Other types of encryption discussed in the framework of this book include securehashes and digital signatures.

Characteristics of an Effective VPN

VPNs exist to effectively, securely, and privately protect data that is transmitted between two

networks from the common, shared, and separately maintained infrastructure between the

two networks. In order to effectively perform this task, there are four goals that a confidential VPN

implementation must meet:

Data confidentiality: Protects the message contents from being interpreted byunauthenticated or unauthorized sources.

Data integrity: Guarantees that the message contents have not been tampered with or altered

in transit from source to destination.

Sender non-repudiation: A means to prevent a sender from falsely denying that they had

sent a message to the receiver.

Message authentication: Ensures that a message was sent from an authentic source and that

messages are being sent to authentic destinations.

Incorporating the appropriate data confidentialitycapabilities into a VPN ensures that only the

intended sources and destinations are capable of interpreting the original message contents. IPsec

is very effective at encrypting data using the encapsulating security protocol (ESP), described

in RFC 1827. Utilizing ESP, IPsec transforms clear text in to encrypted data, or ciphertext.

Because ESP-transformed messages are only sent across in their ciphered representations, the

original contents of the message are kept confidential from would be interceptors of the

NOTE Although IPSec-processed data is encrypted, it is also encapsulated with either

Encapsulating Standard Protocol (ESP) or Authentication Headers (AH).



28/480

Characteristics of an Effective VPN 7

message. Figure 1-1 illustrates a high-level exchange of encrypted message between to endpoints,

James and Charlie.

Figure 1-1 Confidentiality and Authenticity in Encrypted Communications

Encrypting messages relies on the use of a key to encrypt clear text and to decrypt ciphered

messages. In the exchange of messages in Figure 1-1, both James and Charlie require the

appropriate keys to encrypt and decrypt communications from each other. Assuming that these

keys were exchanged or derived securely (for example, via a Diffie-Hellman exchange, which is

discussed in detail in Chapter 2, IPsec Fundamentals), when James receives a message from

Charlie that he is able to decrypt, he can be assured that the message has been delivered with full

confidentiality,and vice versa.

Hashes and digital signatures protect the integrity of a specific communication of data. Hashes and

digital signatures append unique messages to the original message before transmission that ensure

that the message has not been tampered with in transit. Figure 1-2 illustrates the operation of a

hash performed on a message to ensure data integrity.

By providing a unique fingerprint specific only to the sender of the message, a digital signature

also provides the receiver a method of message authentication and sender non-repudiation.

Notice in Figure 1-3 that digital signatures require the use of a public decryption key unique to the

sender's private encryption key. The use of this cryptographic keypair thus guarantees message

authenticity, ensuring that the message was sent from the authentic origin, and safeguards against

sender non-repudiation, preventing a situation in which the sender of a specific message

intentionally and falsely denies their transmittal of the message. While a secure hash can

provide data integrity, digital signatures provide added levels of security by offering message

authentication and sender non-repudiation, the operation of which is illustrated in Figure 1-3.

Hey Charlie, what did youlearn at school today?

4$h5*&FsW@4^%TY&^i*f

Plain Text

Cipher Text:

James

Charlies Encryption Key


4$h5*&FsW@4^%TY&^i*f

Plain Text

Cipher Text:

Charlies Decryption KeyCipher:

RSA

Charlie

Cipher:

RSA

Charlie shares his encryptionkey only with James



29/480


Figure 1-2 Data Integrity, Secure Hashes

Figure 1-3 Message Authenticity and Data Non-Repudiation with Digital Signatures


Charlie separates James messagedigest from original message

Charlie verifies the Jamesmessage digest with his own

Fsd$#^@43#@Ad5J$


Fsd$#^@43#@Ad5J$

Plain Text

Hash Value:

James


Fsd$#^@43#@Ad5J$

Plain Text

Hash Value:

Fsd$#^@43#@Ad5J$

Hash Value:

Jamesappendsmessagedigest

tooriginalmessage

Charlie

Hash:MD5

Hash:MD5


Charlie separates James messagedigest from original message

Charlie verifies the Jamesmessage digest with his own

Plain Text

JamesEncryption Key

JamesDecryption Key

Hash Value:

James Charlie

Hash Value:James encrypts themessage digest

Charliedecryptsthe digitalsignature

Fsd$#^@43#@Ad5J$Digital

Signature

DigitalSignature


James appends messagedigest to original message

DigitalSignature

Fsd$#^@43#@Ad5J$

Hash Value:

Fsd$#^@43#@Ad5J$

Hash:MD5

Cipher:RSA

Hash:MD5

Cipher:RSA




30/480

VPN Technologies 9

VPN Technologies

Although IPsec-based VPNs represent one of the most secure and widely deployed types of VPNs,

they are only one of many VPN technologies in existence today. As well discuss throughout the

course of this book, VPNs have been designed to protect data at almost every layer of the OSI

stack. For example, customers in different market verticals will deploy a range of encryption

technologies, from Layer 1 bulk encryptors to encryption technologies embedded within the

applications themselves (SSL-based VPNs).

The OSI model consists of 7 layers, Physical, Data-Link, Network, Transport, Session,

Presentation, and Application. Although our primary focus will be IPsec VPNs, which are a Layer 3

VPN technology, it is important to understand IPsec VPNs within the context of other VPN

technologies corresponding to different layers within the OSI stack. Figure 1-4 illustrates the OSI

stack and provides some examples of VPN technologies that operate at each corresponding

OSI layer

Figure 1-4 VPN Technologies and the OSI Model

Secure HTTP (HTTPS)S/MIME, PGP

N/A

N/A

SSL and TLSSOCKS, SSH

IPSec Deployments,MPLS VPNs

VPDN-PPTP, L2TP, L2FATM Cell Encryptors

Frame-Relay Frame Encryptors

Optical Bulk EncryptorsRadio Frequency (RF)

Encryptors

Layer 7, Application

Open-Standard Interconnect (OSI)Model Layer VPN Technology

Layer 6, Presentation

Layer 5, Session

Layer 4, Transport

Layer 3, Network

Layer 2, Data Link

Layer 1, Physical



31/480


Virtual Private Dialup Networks

Virtual private dialup networks (VPDN)are used to tunnel data across a shared media. Although

the primary goal of a VPDN is to tunnel data across shared network infrastructures, some VPDNs

may also incorporate data confidentiality. Most VPDNs rely on the use of PPP to encapsulate

data in transit across a common network infrastructure. Typical VPDN deployments consist ofone or many PPP clients establishing a PPP session that terminates on a device at the opposite

end of the tunnel, usually located at a central location within the enterprise or service provider

edge. In doing so, a secure point-to-point tunnel is established from the clients network to

the PPP concentrator. After the tunnel has been established, the client's network appears as

if it were the same network as the enterprise side, while the underlying common network

infrastructure across which data is tunneled remains unchanged. Common VPDN technologies

deployed in todays networks include Layer 2 Forwarding Protocol, Point-to-Point Tunneling

Protocol, and Layer 2 Tunneling Protocol.

Layer 2 Forwarding Protocol

TheLayer 2 Forwarding (L2F) Protocolwas originally developed by Cisco Systems as a way

to tunnel privately addressed IP, AppleTalk, and Novell Internet Protocol Exchange (IPX) over

PPP or Serial Line Internet Protocol (SLIP) dialup connections over shared networks. In

order to do this, this VPDN technology concentrates tunnels at a home gateway, allowing all

dial-up networks to appearas if their physical point of termination is the home gateway itself,

regardless of the location of their actualdialup termination point. L2F uses control messages

on UDP port 1701 to establish the session. Once a tunnel is established, L2F-encapsulated

packets are forwarded in parallel with L2F control datagrams. Both L2F control and payload

datagrams are forwarded on UDP 1701. The L2F encapsulated PPP packets have the formatdescribed in Figure 1-5.

Figure 1-5 L2F Data Packet Format

During the creation of an L2F tunnel, initially a user dials into the Network Access

Server (NAS), negotiates PPP, and is authenticated with either Password Authentication

Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP), as illustrated in

Figure 1-6.

NOTE In an L2F environment, a home gateway refers to a gateway located at the corporate

headquarters.

PPP Encapsulation PPP PayloadL2F EncapsulationUDP



32/480

VPN Technologies 11

Figure 1-6 L2F Topology and Tunnel Establishment

The following steps describe the creation of an L2F tunnel, as illustrated in the steps in

Figure 1-6:

1. NAS and the PPP client negotiate a PPP session. NAS authenticates the PPP client with

CHAP (or, optionally, PAP).

Once the PPP session has been authenticated, a series of exchanges are performed to offload

the termination of the dialup session to the home gateway. Figure 1-7 illustrates the CHAP

handshake between the PPP client and the NAS shown in Figure 1-6.

2. NAS initiates a tunnel connection to the home gateway.

3. The home gateway authenticates NAS against the authentication database (RADIUS or

TACACS+).

4. The home gateway confirms acceptance of the tunnel negotiation initiation request from NAS.

NOTE The NAS can optionally authenticate PPP connections against the AAA (or in this

case, Cisco Secure Access Control Server) server in the service provider cloud. Managing userconnections centrally would ease the administrative burden and provide additional accounting

and user database synchronization capabilities (that is, synchronization with NT databases and

automated backup of AAA data on peer CSACS databases).

PSTN/ISDNConnections

Cisco SecureACS, ISP

NAS

Step 4

Step 2

Step 3

Step 5

Step 6Step 1

HomeGateway

PPP Client,Mobile Worker

PPP Client,Branch Office

PPP Client,Telecommuter

PPP Client, SmallHome Office PPP Client,Mobile Worker

Cisco SecureACS, Corporate



33/480


Figure 1-7 PPP Authentication with CHAP

5. The home gateway and PPP client negotiate additional authentication, authorization,

accounting, IP addressing, and tunneling parameters.

6. An L2F tunnel is established and maintained between the PPP client and the home gateway.

Point-to-Point Tunneling Protocol

Point-to-point Tunneling Protocol (PPTP),a technology originally created by Microsoft, provides

a seamless integration of remote PPP capable devices into an enterprise network. PPTP leverages

authentication parameters inherent to native PPP and the tunneling capabilities of GRE to

establish a VPDN. After a client has established a PPTP tunnel to a concentrator on a centralized

enterprise network resource, that client appears as if it were part of the enterprise network

itself, regardless of the underlying common infrastructure that the data is tunneled across.

Consider the following exchange between a small remote office network (the PPP client) and

a corporate VPDN (PPTP) concentrator. Figure 1-8 illustrates the order of operations executed

when a client accesses the VPDN using PPTP.

The PPP client in this scenario needs to connect to their enterprise network. The corporations

security policy mandates that data be separated from the common service provider infrastructure

and that central network connectivity provided by the service provider must remain transparent

to the PPP clients, who are PSTN or ISDN attached. In order to accomplish this task, PPTP is

used to provide an end-to-end tunnel for PPP connections inbound to the service provider.

NOTE For more information on L2F, refer to RFC 2341 at http://www.ietf.org/rfc/rfc2406.txt.

Step 1: PPP CHAP Authentication Operation

1) Establish link (LCP);

initiate PPP negotiation

2) Select CHAP as PPP authentication scheme

3) Acknowledge PPP authentication scheme

4) Challenge

5) Create one-way hash and use as response

6) Create one-way hash; verify clients response; accept or reject connection

PPP Client, SmallHome Office

NAS

http://www.ietf.org/rfc/rfc2406.txthttp://www.ietf.org/rfc/rfc2406.txt


34/480

VPN Technologies 13

Figure 1-8 PPTP Topology and Tunnel Negotiation

Generally, there are two different types of PPTP VPDN tunnels: compulsory tunnels and voluntary

tunnels. Compulsorytunnels are formed when a PPP client accesses the NAS or PPTP Access

Concentrator (PAC). The NAS/PAC in turn establishes a tunnel with the PPTP Network Server

(PNS). Voluntarytunnels are formed when a PPP client directly negotiates a PPTP tunnel with

the PNS. The creation of a voluntary PPTP tunnel executes the following steps (illustrated in

Figure 1-8):

1. The first step in the negotiation occurs when the PPP client establishes a connection with the

NAS and is authenticated through a chosen form of PPP authenticationPAP, CHAP, or

Microsoft CHAP (MS-CHAP). PPTP tunnels can be encrypted through the use of MicrosoftPoint-to-Point Encryption (MPPE) to provide confidentiality in VPDNs. Cisco IOS supports

both 40- and 128-bit MPPE encryption. In order to encrypt a PPTP tunnel using MPPE, the

network administrator must use MS-CHAP to authenticate PPP connections to the NAS.

2. Now that the PPP client has accessed the service provider network, the client has IP

connectivity to the PNS at its corporate headquarters. The PPP client and the PNS must

maintain two connections to one anothera control connection and a tunnel protocol

connection. The PPTP control connection maintains the connection state and negotiates call

setup and teardown. As such, it must be established before the tunnel protocol connection can

be established. Once an NAS receives the call from the PPP client, the next step in creating

the VPDN connection is to either establish a compulsory tunnel from the NAS/PAC to the

TIP Authentication of PPP sessions can be passed to a centrally managed authentication

database, such as CSACS via RADIUS or TACACS+. Authenticating PPP sessions against a

CSACS database greatly eases administration of user authentication data for VPN access.

NAS/PAC PIX/PNSGatewayRouter

Step 1

Service ProviderNetwork

EnterpriseNetwork

Step 4

Step 3

Step 2





PPP Client,Small Home Office




35/480


PNS or to establish a voluntary tunnel from the PPP client itself to the PNS. In Figure 1-8, the

PPP client elects to establish a voluntary tunnel directly to the PNS. In this scenario, the PIX

is acting as the PNS for the PPTP exchange. The client initiates the tunnel by establishing a

TCP connection to the PNS on port 1723.

3. Once the PPP client and the PNS have TCP connectivity, they can start to exchange PPTP

tunnel negotiation information between them. The tunnel negotiation process consists of

exchanging connection request and reply messages as defined in RFC 2673 between the PNS

and the PPP client.

4. Once the PPTP control connection has negotiated call setup, call maintenance, and tunnel

parameters accordingly, a second session is establishedthe PPTP tunnel connection itself.

The PPTP tunnel connectionuses a modified version of GRE to tunnel PPP frames over the

IP cloud, which, in Figure 1-8, is the service provider network. The GRE-encapsulated formatof the PPTP tunneled packet is illustrated in Figure 1-9.

Figure 1-9 PPTP Tunnel Protocol Data Structure

The preceding scenario describes a voluntary PPTP tunnel negotiation between the PPP client,

which also acts as its own PAC, and the corporate PIX Firewall, acting as the PNS. In a compulsory

PPTP tunnel negotiation, the NAS would act as the PAC and would multiplex multiple sessions

CAUTION In many cases, including the example in Figure 1-8, TCP port 1723 must be

allowed through any corporate firewalls or other filtering security devices for PPTP to operate

correctly. In this scenario, the PIX would be configured with the appropriate static translation

and access list entry on its outside interface to allow TCP sessions from remote clients on port

1723.

TIP As with PPP authentication on the NAS/PAC, PPTP connections on PIX firewalls and

Cisco routers can be authenticated against a Cisco Secure ACS database using RADIUS or

TACACS+. Implementing user accounts on a central CSACS database greatly eases

administrative overhead.

NOTE The header used in the PPTP encapsulation process is similar to a GRE header, with

some slight modifications to the specification outlined in RFC 1701. The PPTP version of the

GRE header includes an acknowledgment field to determine the rate at which packets aretraversing the PPTP tunnel.

Data Link Header Data Link TrailerIP Header PPTP Header PPP Header PPP Payload



36/480

VPN Technologies 15

from the PPTP clients into a single tunnel to the PIX, or PNS. The exchanges in a compulsory

tunnel would follow the same steps chronologically, but would appear as displayed in

Figure 1-10.

Figure 1-10 A PPTP Compulsory Tunnel Setup between PAC and PNS

As depicted in Figure 1-10, only a single tunnel is negotiated between the PAC/PNS pair. In avoluntary exchange, it is possible that all 5 PPP clients dialing into the NAS terminate separate

tunnels with the PIX/PNS. As such, compulsory tunnel architectures can be used to keep tunnel

termination overhead low on the PNS. In the examples in this chapter, the voluntary tunnel negotiation

option could yield up to five times the tunnel maintenance of a compulsory tunnel negotiation

option (five PPP clients initiating tunnels to the PIX in a voluntary arrangement vs. one tunnel

initiated from the NAS in a compulsory setting).

Compulsory tunnels, however, do not offer end-to-end confidentiality with MPPE. In the

preceding compulsory arrangement, the PPP connections to the NAS would remain

unencryptedonly the connection from the PAC to the PNS would be encrypted with MPPE.As such, those network administrators requiring fully confidential exchange of data in their

PPTP environments should choose to allow their clients to voluntarily negotiate an end-to-end PPTP

tunnel with the PNS or, in this case, the corporate PIX Firewall. In doing so, the network

administrator can ensure that all legs of the VPDN from their remote dialup hosts using PPP to

their corporate PNS are encrypted for end-to-end data confidentiality.

NOTE Although both L2TP and PPTP support both voluntary and compulsory tunnels,Cisco IOS only supports voluntary and compulsory tunnels for L2TP. While voluntary

PPTP tunnels are supported in Cisco IOS, compulsory PPTP tunnels are currently not

supported.

NAS/PAC PIX/PNSGatewayRouter


Service ProviderNetwork

EnterpriseNetwork

PPP Client

PPP Client

PPP Client

PPP Client

PPP Client

Step 2

Step 3

Step 1

Step 4



37/480


Layer 2 Tunneling Protocol

Layer 2 Tunneling Protocol (L2TP)is a collaborative effort to develop a standards-based VPDN

protocol within IETF. Vendors collaborating on this initiative include, among others, Cisco and

Microsoft. As with PPTP, L2TP is a client-server operation consisting of two main components:

L2TP Access Concentrator (LAC)The LAC represents the client side of this network and

typically exists on the switch infrastructure between remote dialup nodes and the access

server that terminates the inbound PPP sessions across the switched ISDN or PSTN

infrastructure. As remote hosts initiate and terminate PPP connections on the NAS, the LAC

serves as a proxy originator of L2TP control and tunnel data to the LNS at the corporate

network. LACs are often collocated with the access server itself. A Cisco router or access

server is capable of providing LAC functionality within a VPDN.

L2TP Network Server (LNS)The LNS represents the server side of this VPDN

architecture. It resides within the enterprise network and terminates tunneled data from the

LAC. As users connect to the LAC, connections are multiplexed across the negotiated tunnel

to the LNS, where they are eventually terminated.

A typical L2TP session resembles a compulsory PPTP tunnel negotiation between a PAC and a

PNS. As with PPTP, two types of data are forwarded into an L2TP tunnelcontrol data and tunnel

data. Unlike PPTP, however, L2TP is not connection oriented. Instead, it is packet oriented. So,

whereas PPTP relied on a TCP-based connection to establish a control channel between the

PAC and PNS, L2TP uses UDP to maintain control data and tunnel data simultaneously. L2TP

leverages the use of control messages and data packets as follows:

L2TP control messages negotiate tunnel setup and maintenance. Control messages establishtunnel IDs for new connections within an existing tunnel. They also tear down and remove

previously established tunnel IDs within an existing L2TP tunnel. L2TP control messages

are originated on a given source port and forwarded to UDP destination port 1701.

L2TP payload packets tunnel data within a given network. When data is tunneled from LAC

to LNS across an IP cloud, it is encapsulated with an L2TP header. The format of the

L2TP payload is illustrated in Figure 1-11. As with L2TP control messages, L2TP payload

packets are forwarded to UDP 1701.

Figure 1-11 L2TP Tunnel Protocol Data Structure

NOTE L2F control and payload packets are also sent on UDP port 1701. Network devices

inspect the version field to differentiate between L2F and L2TP packet formats.

Data Link Header Data Link TrailerIP Header UDP Header PPP Header PPP PayloadL2TP Header



38/480

VPN Technologies 17

Figure 1-12 depicts a sample L2TP tunnel setup in which a company uses L2TP to establish

seamless, secure connectivity across an untrusted media. In this case, that shared network is the

ISP cloud. The ISP owns the access server that terminates the customers dialup connection

using PPP as the Layer 2 protocol. In this example, the access server also serves as the LAC.

The LNS is located on the customer premises and terminates the L2TP tunnel originatedfrom the LAC.

Figure 1-12 L2TP Tunnel Negotiation

The following steps outline the creation of the L2TP VPDN from the remote host to the corporate

network as described in Figure 1-12:

1. The user dials in to the NAS/LAC over PSTN or ISDN. The user establishes a PPP connection

with the NAS and is authenticated with CHAP.

2. The user initiates an L2TP tunnel and is prompted for a username and password. The ISP

inspects the remote users username and authenticates it against its central authentication

database via TACACS+ or RADIUS.

3. Once authenticated, the LAC initiates an L2TP tunnel to the LNS located at their corporate

facility.

4. The LNS receives the request for tunnel negotiation and optionally authenticates the request

against the corporate central authentication database via TACACS+ or RADIUS. The LNS

responds with either an acceptance or a rejection of the tunnel initiation to the LAC.

Cisco Secure ACS, ISP

ServiceProviderNetwork

NAS/LAC

Step 4

Step 3

Step 5

Step 6

Step 1

LNS

Step 2





PPP Client, SmallHome Office PPP Client,

Mobile Worker

Cisco SecureACS, Corporate



39/480


5. The LNS creates a virtual interface for the tunnel ID corresponding to the requesting remote

PPP client. The remote PPP client and the LNS are now able to exchange authentication,

authorization, accounting, and IP addressing data with one another over the tunneled PPP

session. L2TP headers are stripped on ingress at the LNS for inbound connections from thePPP client. Likewise, L2TP headers are stripped at the LAC for outbound connections from

the LNS to the PPP client.

6. A PPP connection now exists between the PPP client and the LNS. Additionally, an

L2TP tunnel has been negotiated between the LAC and the LNS. When a new PPP client

attempts to access the corporate network and is authenticated at the ISP, the LAC does not

create a new L2TP tunnel but instead adds a new tunnel ID to the existing tunnel for that

client.

Multiprotocol Label Switching VPNsMultiprotocol Label Switching (MPLS) VPNslogically separate VPN traffic over a shared

media through the use of VPN Routing and Forwarding Instances (VRFs). In an MPLS network,

different devices play different roles to achieve this logical separation:

Provider (P) Router: P routers typically comprise the MPLS core and therefore provide

transport between PE routers. Instead of using IP routing information base (RIB) or IP

forwarding information base (FIB) lookups to make forwarding decisions, P routers use a

label forwarding information base (LFIB) lookup to make their forwarding decisions.

Convergence of the LFIB between P routers in the provider network is facilitated through the

use of Label Distribution Protocol (LDP).

Provider Edge (PE) Routers: PE routers typically provide the interface between the service

provider and the customer, and it is most common for the provider to own the PE router.

PE routers communicate information about VPNv4 addresses, including the IPv4 prefix and

8-byte route descriptor, between one another using the Multiprotocol Border Gateway

Protocol (MP-BGP), enabling convergence at the PE.

Customer Edge (CE) Routers:CE routers provide the interface to the PE routers. CE routers

typically perform forwarding decisions based on standard RIB or FIB lookups, and

convergence between CE routers and the PE router can typically be achieved through the use

a standard IGP.

NOTE MP-BGP plays a critical role in the convergence of an MPLS VPN. For more

information on MP-BGP and its role in MPLS VPNs, please refer to the following IETF RFC:

http://www.ietf.org/rfc/rfc2547.txt

http://www.ietf.org/rfc/rfc2547.txthttp://www.ietf.org/rfc/rfc2547.txt


40/480

VPN Technologies 19

A VRF describes a separate routing and forwarding table, enabled by the use of Route Descriptors,which are 8-byte unique identifiers derived from VPN-specific information at the provider edge

(PE). MPLS VPNs enable customer edge (CE) routers to establish normal Layer 3 RP adjacencies

with MPLS-aware PE routers. Each PE router is MPLS VPN aware and is able to forward traffic

to its destination PE router on the opposite side of the provider core using VPNv4 addresses

learned from MP-BGP advertisements from other PE routers. The provider core routers remain

unaware of the customer networks routing table or IP addressing information. Instead, traffic is

switched within the MPLS cloud using labels and an entry in the P routers label forwarding

information base (LFIB). Figure 1-13 illustrates IP-routed and VRF-routed domains with MPLS.

Figure 1-13 Traffic is IP-Routed to the Provider Edge (PE)

When the traffic from the customer edge reaches the PE router, it is then label switched across the

MPLS Service Provider core to its destination PE router. In this manner, customer routing and

IP addressing information is kept virtual and private from the provider corethe P routers use

CAUTION An MPLS VPN does not provide confidentiality unless it is deployed in

conjunction with IPsec.

CustomerNetwork

B

PE Routers use MP-BGPto distribute VPNv4routes to one anotherover the network of Prouters.

Customer Networks A, B, C,and D use the a single,shared, virtualized coreenabling all networks toparticipate in the VPN #1while only allowingCustomer Networks C and Dparticipate in the VPN #2.

CustomerNetwork

C

C

C

CE

CE

IPSwitched

CustomerNetwork

D

C

CE

IPSwitched

IP Switched IP Switched

C CE

CustomerNetwork

A

P

P

PE

PE

PE

PE

LabelSwitched

= VPN #1 = VPN #2



41/480


MPLS labels and an associated LFIB entry to forward the traffic across the MPLS core rather than

IP addressing information.

When MPLS-switched traffic arrives at the destination PE router, traffic can be forwarded to

neighboring CE routers based on the previously installed VPNv4 address learned from MP-BGPadvertisements from neighboring MP-BGPenabled PE routers. The CE routers perform IP RIB

lookups to determine the appropriate destination and forwarding decisions within the customer

core IP network.

The operation of MPLS offers separation of multiple virtual data networks across a shared

network such as an ISP. The addition of MPLS labels at the service provider core allows customers

to separate networks from other customers virtually over a shared core network such as a service

provider network. The use of route descriptors on PE nodes provides separation at the control

plane, allowing customers to use overlapping address space and overlapping services that would

normally present conflict within a non-MPLS environment. As mentioned previously, data-planeseparation is achieved using VPN labels to make the forwarding decisions on PE routers.

IPsec VPNs

IPsec VPNsencrypt data at the Layer 3 IP packet layer, offering a comprehensively secure VPN

solution through providing data authentication, anti-replay protection, data confidentiality, and

data integrity protection. As such, IPsec is one of the most widespread VPN technologies in

todays enterprise, service provider, and government networks. Using ESP in tunnel mode, IPsec

supports the rewrite of Type of Service (ToS) bits into an outer IP header, thereby supporting

encrypted data payloads while preserving quality of service (QoS) within a given network. IPsec

is a standards-based protocol and therefore supports interoperability across products from

multiple vendors.

As we will discuss, IPsec is supported within Cisco IOS on a wide array of different routers,

firewalls, VPN Service Modules, VPN concentrators, and VPN clients. Likewise, Cisco offers avariety of different hardware-based VPN acceleration options for enhanced VPN performance

within a network. IPsec will serve as the primary VPN discussion point for the duration

of this book.

IPsec VPNs tunnel data across shared media using ESP, AH, or a combination of both. These two

standards-based protocols both use symmetric encryption technology.

NOTE Although IPsec is standards based, there are many optional components of IPsec (not

required for RFC compliance) and proprietary innovations that present compatibility

considerations in multi-vendor environments. We will discuss these design considerations in

greater detail in Chapter 8, Handling Vendor Interoperability with High Availability.



42/480

VPN Technologies 21

IPsec-supported symmetric encryption transforms include data encryption standard (DES,

56-bit transform), triple data encryption standard (3DES, 168-bit transform), and most recently,advanced encryption standard (AES, 256-bit transform). Security parameters, including keys used

for symmetric encryption, are communicated securely using the Internet Key Exchange (IKE)

protocol, which is also considered part of the IPsec protocol suite. The operation of protocols

incorporated within the IPsec protocol suite is discussed in greater detail in Chapter 2. Subsequent

chapters will explore design considerations of IPsec-based VPNs.

Transport Layer VPNs

Transport layer VPNsprovide an additional layer of security at the transport of the OSI stack.

Transport layer VPNs typically consist of a client application and a server. A transport layer VPN

will undergo a handshake to agree on common parameters to use for the SSL or TLS session,

including cryptographic keying material and transforms. The messages in this handshake are

confidentially exchanged between client and server, typically with a form of public key encryption

such as RSA encryption. During the handshake, the client and server also agree on a set of

symmetric session keys and a symmetric key transform, such as DES or 3DES, for bulk data

encryption over the SSL VPN.

Secure Socket Layer VPNs

In todays network architectures, Secure Socket Layer (SSL)VPNs represent one of the most

popular choices for transport layer security. SSL was originally developed by Netscape in 1994to secure client/server applications across the Internet. SSL is effective at providing data

authentication, data integrity, and data confidentiality between client and server applications,

but it does not offer data non-repudiation services. As discussed before, SSL is performed over

TCP in the transport layer of the OSI stack, as illustrated in Figure 1-14.

Figure 1-14 SSL and the OSI Stack

NOTE The precise operation of ESP and AH are outlined more comprehensively in Chapter 2.

Secure Socket Layer (SSL)Services

Layer 4, Transport, TCP

Layer 3, Network, IP

Layer 2, Data Link

Layer 1, Physical



43/480


SSL follows five broad steps when establishing a secure sessionclient exchange of cryptographic

parameters, server exchange of cryptographic parameters, cryptographic key derivation, session

authentication, and secure data exchange. Refer to the scenario illustrated in Figure 1-15 for the

following description of SSL tunnel negotiation. In the SSL tunnel negotiation, public key

encryption is typically used for initial client and server authentication. The client and server alsoexchange public keys to encrypt each message in the handshake. Once the handshake is

completed, symmetric key transforms are used for bulk data encryption between client and server.

Figure 1-15 SSL Tunnel Establishment

The following order of operations describes the SSL handshake illustrated in Figure 1-15:

Client Exchange of Cryptographic ParametersCLIENT-HELLO Message:

Cipher suite (supported symmetric transforms) Version (SSL v2, v3, or v3.1) ClientRandom (for master secret calculation) Optional session ID

Compression algorithmCLIENT-HELLO-DONE Message

Server Exchange of Cryptographic ParametersSERVER-HELLO Message:

Cipher suite (supported symmetric transforms) Version (SSL v2, v3, or v3.1) ServerRandom (for master secret calculation) Optional session ID Compression algorithm

SERVER-HELLO-DONE Message

Cryptographic Key DerivationCLIENT-KEY-EXCHANGE Message:

Client protocol version Pre-master secret: a 48-byte value

FINISHED Message

Hash of all exchanged messages executed in the handshake

Session AuthenticationFINISHED Message

Hash of all exchanged messages executed in the handshake including the Client FINISHED message

Session Authentication

FINISHED Message Hash of all exchanged messages executed in the

handshake including the Client FINISHED message

1

2

3

4

5 5

SSL Concentrator

SSL Concentrator

SSL Concentrator

SSL Concentrator

SSL Concentrator

SSL Client

SSL Client

SSL Client

SSL Client

SSL Client



44/480

VPN Technologies 23

1. Client Exchange of Cryptographic ParametersThe client and server must agree on the

parameters used for encryption, such as the encryption algorithm, key exchange method, and

hash method to use for data integrity. If the client and server have not already agreed on these

parameters, then the client will initiate the exchange of messages to negotiate mutually

acceptable parameters to use for future operations using by sending a CLIENT-HELLO

message to the concentrator.

2. Server Exchange of Cryptographic ParametersThe server responds to the CLIENT-

HELLO message with a SERVER-HELLO message and, optionally, several other messages:

SERVER-CERTIFICATEContains the serverss public key for

server authentication and pre-master secret encryption.

SERVER-KEY-EXCHANGEOptionally used to encrypt the

CLIENT-KEY-EXCHANGE message in Step 3 below.

CLIENT-CERTIFICATE-REQUEST The SSL concentrator or

server can optionally request a client certificate for authentication. If this

message is sent to the client, the clients server mustbe forwarded to the

SSL concentrator and successfully validated.

The SERVER-HELLO will specify the parameters to use for the SSL session, includingthe highest version ID and the strongest supported symmetric key cipher specified in the

CLIENT-HELLO message from Step 1. At this point, the client and server should have

the appropriate information necessary to agree on cryptographic parameters. A SERVER-

HELLO-DONE message is then forwarded to the SSL client to indicate that the SSL server

has received the required information for this sequence of the handshake and is awaiting

information from the client (as described in the next step).

3. Cryptographic Key DerivationThe client is now ready to generate and share its pre-master

secret key with the SSL server. The pre-master secret is comprised of a 48-byte value (in the

case where RSA is used). This value is then encrypted with the SSL servers public key and

forwarded to the SSL server using a CLIENT-KEY-EXCHANGE message. Optionally, theclient will also forward two additional messages at this point in the SSL handshake:

CLIENT-CERTIFICATEThe client must possess a certificate and

forward it to the server using this message if the client receives a

CLIENT-CERTIFICATE-REQUEST in Step 2 above.

NOTE RSA signatures are commonly used to facilitate the authentication and confidential

exchange of messages during the SSL handshake. RSA Signatures, including x.509-based

certificates and certificate authorities, are discussed in full detail in Chapter 2 and Chapter 12,

Public Key Infrastructures and IPsec.



45/480


CERTIFICATE-VERIFYThis message is a hash of all previous

handshake messages appended. It is sent to the SSL server to validate the

authenticity and data integrity of the CLIENT-CERTIFICATE message

(and all other previous handshake messages) if the client receives a

CLIENT-CERTIFICATE-REQUEST in Step 2 above.

The SSL Server decrypts the CLIENT-KEY-EXCHANGE message to obtain the pre-master

secret sent by the client. The client and server then derive the master secret by hashing

the pre-master secret with the ClientRandom and ServerRandom values shared in Step 1. The

master key is then used to derive 4 session keys that SSL will use to encrypt data:

Client Write MAC SecretClient uses this key to create a hash

appended to the original message; server uses this key to verify the hash.

Server Write MAC SecretServer uses this key to create a hash

appended to the original message; client uses this key to verify the hash.

Client Write KeyClient uses this key to encrypt messages; server

uses it to decrypt messages.

Server Write KeyServer uses this key to encrypt messages; client

uses it to decrypt message.

The client concludes this phase of the SSL handshake by sending a CLIENT-FINISHED

message to the server. The FINISHED message contains a hashed value of all previous messages

in the handshake to this point. The server verifies this message to determine that the previous

exchanges have indeed been authentic with preserved data integrity.

4. Session AuthenticationThe SSL concentrator or server must validate the hash (MAC)

sent in the client FINISHED message received in Step 3 above. Upon successful validation of

the MAC contained in the client FINISHED message, the server now safely assumes that the

SSL handshake has proceeded with authenticity and preserved data integrity. The server

subsequently forwards a server FINISHED message to the SSL client containing a MAC

resulting from a hash of all previous messages in the handshake to this point. Upon receipt

of this message, the SSL client performs a validation of the MAC received in the server

FINISHED message so that it too can assume that the handshake has completed with

authenticity and preserved data integrity.

5. Confidential Exchange of Data with Preserved IntegrityThe client and server now use

the session keys derived from the master secret in Step 1 to encrypt and decrypt data sent toand from one another. This is done through an agreed-upon cipher transform such as DES or,

in this case, 3DES. However, to ensure data integrity, a hashed message authentication

code (HMAC) is appended to the original message. The newly formed payload (original

message + HMAC) is encrypted with the selected transform.

NOTE The creation of hashed message authentication codes is covered in greater detail in

Chapter 2.



46/480

Common VPN Deployments 25

Transport Layer Security and SSL VPNs

SSL was originally developed by Netscape and has proven to be effective for HTTPS

communications. However, the IETF standards track protocol for security at the transport layer is

actually transport layer security (TLS). The operation of TLS is similar to SSL 3.0 but has

significant modifications, specifically with respect to support for different cryptographicalgorithms, that make the two incompatible with one another.

TLS has big implications in 802.1x identity-based networking systems, because extensible

authentication protocol with TLS (EAP-TLS) is part of the 802.1x standard. Additionally, TLS is

a critical component in wireless network security. Although not formally a component of the

newly ratified 802.11i IEEE standard for wireless network security, EAP-TLS is the de facto

means of authentication in 802.11i-compliant networks.

Common VPN Deployments

Network infrastructures in which a VPN technology may be commonly deployed include, but

are not limited to, trunks to Internet service provider networks, corporate extranet partner

networks, or even private leased line connections in a corporate intranet. Next, we will briefly

explore some of the common situations in which a VPN may be deployed.

Site-to-Site VPNs

As cryptographic technology becomes more embedded in various network elements, growth in

site-to-site VPN deployments has risen. A site-to-site VPN could be as simple as encrypting the

link between two different nodes on a point-to-point connection. Or it could be slightly more

complex, offloading the initiation and termination of the VPN tunnel to a firewall or VPNconcentrator on each organizations DMZ. Figure 1-16 illustrates a simple site-to-site IPsec VPN

deployment between two networks, A and B.

Figure 1-16 Simple Site-to-Site Design Scenario

Although the two IPsec tunnel implementations in Figure 1-16 use the same physical topology to

accomplish a similar task, there is a significant difference between these two simple site-to-site

VPN designs. For example, if a smaller router is used for the WAN connection, there could be a

IPSec tunnel over point-to-point link

IPSec tunnel over routed links

Network A Network B



47/480


substantial improvement in VPN performance by processing IPsec on the VPN concentrators. In

such a case, the routed IPsec tunnel between the two VPN concentrators would be an optimal

choice. However, if the PIX are performing network address translation (NAT), the VPN concentrators

may need support for special features, such as IPsec NAT Transversal (IPsec NAT-T), for IPsec to

work properly. If the concentrators do not have the appropriate features, the IPsec tunnel built overthe point-to-point line might be a better option.

In the scenario in Figure 1-16, it is critically important to note that the flexibility to choose between

the two tunnel deployments is enabled by the fact that IPsec VPNs operate at Layer 3, the

network layer, of the OSI model. As such, VPNs are no longer limited to bulk data-link encrypt