Cisco Press IPSEC Virtual Private Network Fundamentals Jul 2006 ISBN 1587052075

  

IPsec Virtual Private Network Fundamentals

By James Henry Carmouche, - CCIE No. 6085

...............................................

  Publisher: Cisco Press Pub Date: July 19, 2006 Print ISBN-10: 1-58705-207-5 Print ISBN-13: 978-1-58705-207-1 Pages: 480

   An introduction to designing and configuring Cisco IPsec VPNs Understand the basics of the IPsec protocol and learn implementation best practices

  Study up-to-date IPsec design, incorporating current Cisco innovations in the security and VPN marketplace Learn how to avoid common pitfalls related to IPsec deployment Reinforce theory with case studies, configuration examples showing how IPsec maps to real-world solutions

  IPsec Virtual Private Network Fundamentals provides a basic working knowledge of IPsec

on various Cisco routing and switching platforms. It provides the foundation necessary to

understand the different components of Cisco IPsec implementation and how it can be

successfully implemented in a variety of network topologies and markets (service provider,

enterprise, financial, government). This book views IPsec as an emerging requirement in

most major vertical markets, explaining the need for increased information authentication,

confidentiality, and non-repudiation for secure transmission of confidential data. The book

is written using a layered approach, starting with basic explanations of why IPsec was

developed and the types of organizations relying on IPsec to secure data transmissions. It

then outlines the basic IPsec/ISAKMP fundamentals that were developed to meet demand

for secure data transmission. The book covers 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 high availability solutions and public key infrastructure

(PKI). Sample topology diagrams and configuration examples are provided in each chapter

to reinforce the fundamentals expressed in text and to assist readers in translating

concepts into practical deployment scenarios. Additionally, comprehensive case studies are

IPsec Virtual Private Network Fundamentals

  By James Henry Carmouche, - CCIE No. 6085 ...............................................

  Publisher: Cisco Press Pub Date: July 19, 2006 Print ISBN-10: 1-58705-207-5 Print ISBN-13: 978-1-58705-207-1 Pages: 480

  

  

  

  

  

  

  

Copyright

  IPsec Virtual Private Network Fundamentals

  James Henry Carmouche, CCIE No. 6085 Copyright © 2007 Cisco Systems, Inc.

  Published by: Cisco Press 800 East 96th Street Indianapolis, 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 publisher, 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

Trademark Acknowledgments

  All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer

  This book is designed to provide information about IPsec virtual private networks. Every effort has been made to make this book as complete 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 nor responsibility to any person 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 necessarily those of Cisco Systems, Inc.

Corporate and Government Sales

  Cisco 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 1-800-382-3419

  For sales outside the U.S. please contact: International Sales

   Feedback Information

  At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, 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 quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at

   . Please make sure to include the book title and ISBN in your message.

  We greatly appreciate your assistance.

  Publisher Paul Boger Cisco Representative Anthony Wolfenden Cisco Press Program Manager

  Jeff Brady Executive Editor Brett Bartow Production Manager Patrick Kanouse Development 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

  Corporate Headquarters Cisco Systems, Inc.

  170 West Tasman Drive San Jose, CA 95134-1706 USA

  

  Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

  European Headquarters

  Cisco Systems International BV Haarlerbergpark Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands

  

  Tel: 31 0 20 357 1000 Fax: 31 0 20 357 1100

  Americas Headquarters Cisco Systems, Inc.

  San Jose, CA 95134-1706 USA

  

  Tel: 408 526-7660 Fax: 408 527-0883

  Asia Pacific Headquarters Cisco Systems, Inc.

  Capital Tower 168 Robinson Road #22-01 to #29-01 Singapore 068912

  

  Tel: +65 6317 7777 Fax: +65 6317 7799 Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco.com Web site at

  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

  Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco 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, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, StrataView 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 of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0303R) Printed in the USA

Dedication

  For 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.

About the Author

  James 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 GSU's 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 UNC's 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 Reviewers

  

Aamer 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 Layer 3 VPNs and related technologies in a cross-Cisco effort.

  Jason Guy is 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. Jason's 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.

Acknowledgments

  During 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.

  I'd like to thank Mike O'Shea for his support and friendship over the course of developing this book. Mike's 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.

Command Syntax Conventions

  The 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 show command).

  Italics indicate 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.

Introduction

  In 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.

Methodology

  This 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 today's enterprise networks are presented and discussed. Within each chapter, the design concepts are presented and then reinforced with configurations, 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.

How This Book Is Organized

  The organization of the book is formatted in a layered approach, starting with a basic explanation of the motivation behind IPsec's 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 meet demand 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.

  

  of this book, covering the

  most basic concepts required to develop an understanding of

  IPsec VPNs. The chapter content provided in

  aims to help

  the reader 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

   you should

  have the working knowledge of IPsec VPNs necessary to begin building a knowledge base surrounding the fundamentals of

  IPsec VPN High Availability using the design concepts provided in

   "Introduction to VPN Technologies" This

  chapter includes an introduction to various VPN technologies, discusses how VPNs are utilized in today's 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.

   "IPsec Fundamentals" This 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.

   "Basic IPsec VPN Topologies and Configurations" This 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. deployments can involve a number of potential pitfalls if not properly addressed.

  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.

   . The topics discussed

  here build on the introductory concepts from

   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

   "Designing for High Availability" This 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.

   "Solutions for Local Site-to-Site High Availability" This 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.

   "Solutions for Geographic Site-to-Site High Availability" This chapter uses concepts previously

  described to develop solutions for geographic HA. This chapter discusses RRI, IPsec with GRE tunnels, and Dynamic Multipoint VPN.

  

"Handling Vendor Interoperability with

High Availability" Unfortunately, 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.

  

"Solutions for Remote Access VPN High

Availability" This chapter discusses the HA concepts

  previously discussed in

   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.

   "Further Architectural Options for IPsec" This chapter discusses other architectural variations in

  designing VPN solutions. It describes each option with usage considerations and finishes with case studies of each.

  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

   provide design guidance around two

  advanced topics of IPsec that are quite commonly deployed in today's enterprise-class IP networks:

  

"Public Key Infrastructure and IPsec

VPNs" This chapter discusses the usage of public key

  infrastructure (PKI) to authenticate IPsec peers via Rivest, Shamir, and Adelman (RSA) signatures. This method uses a scale IKE authentication. As organizations become more Public Key Infrastructure (PKI)-aware, this will become the de facto authentication mechanism.

  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 dynamic peering options, some of which are less commonly used, and others that are more prolific in various architectures.

  

Part I: Introductory Concepts and

Configuration/Troubleshooting Common IPsec VPN Issues

Chapter 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 today's 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 today's 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 Terms

  A VPN is 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 encapsulation method 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 encapsulation to 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 we'll 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.

Note

  Although IPSec-processed data is encrypted, it is also encapsulated with either Encapsulating Standard Protocol (ESP) or Authentication Headers (AH).

  Encryption refers to the act of coding a given message into a

  different format, while decryption refers 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 you'll 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 secure hashes 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 by unauthenticated 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 confidentiality capabilities 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 cipher text. Because ESP-transformed messages are only sent across in their ciphered representations, the original interceptors of the message. illustrates a high-level exchange of encrypted message between to endpoints, James and Charlie.

  

Figure 1-1. Confidentiality and Authenticity in

Encrypted Communications

[View full size image]

  Encrypting messages relies on the use of a key to encrypt clear text and to decrypt ciphered messages. In the exchange of messages in , 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

  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 unique messages to the original message before transmission that ensure that the message has not been tampered with in transit. illustrates the operation of a hash performed on a message to ensure data integrity.

  

Figure 1-2. Data Integrity, Secure Hashes

[View full size image]

  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 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 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. Message Authenticity and Data Non-

Repudiation with Digital Signatures

[View full size image]

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 we'll 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

  

  technologies that operate at each corresponding OSI layer

  

Figure 1-4. VPN Technologies and the OSI Model

[View full size image]

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 of one 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 client's 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 infrastructure across which data is tunneled remains unchanged. Common VPDN technologies deployed in today's networks include Layer 2 Forwarding Protocol, Point-to-Point Tunneling Protocol, and Layer 2 Tunneling Protocol.

Layer 2 Forwarding Protocol

  The Layer 2 Forwarding (L2F) Protocol was 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 appear as if their physical point of termination is the home gateway itself, regardless of the location of their

  actual dialup 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 format described in

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. L2F Topology and Tunnel

Establishment

[View full size image]

Note

  In an L2F environment, a "home" gateway refers to a gateway located at the corporate headquarters.

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

  Note the AAA (or in this case, Cisco Secure Access Control Server) server in the service provider cloud. Managing user connections 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).

  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. illustrates the CHAP handshake between the PPP client and the NAS shown in .

  Figure 1-7. PPP Authentication with CHAP [View full size image] 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.

  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.

Note

  For more information on L2F, refer to RFC 2341 at

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 operations executed when a client accesses the VPDN using PPTP.

  

Figure 1-8. PPTP Topology and Tunnel

Negotiation

[View full size image]

  The PPP client in this scenario needs to connect to their enterprise network. The corporation's 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.

  Generally, there are two different types of PPTP VPDN tunnels: compulsory tunnels and voluntary tunnels. Compulsory tunnels 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). Voluntary tunnels are formed when a PPP client directly negotiates a PPTP tunnel with following steps (illustrated in ):

  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 Microsoft Point-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.

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.

  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 PNS or to establish a voluntary tunnel from the PPP client itself to the PNS. In , the PPP client elects to 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.

Caution

  In many cases, including the example in 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.

  

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.

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.

  

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 connection uses a modified version of

  

  

  

Figure 1-9. PPTP Tunnel Protocol Data Structure 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 are traversing the PPTP tunnel.

  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 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. A PPTP Compulsory Tunnel Setup

  [View full size image]

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.

  As depicted in only a single tunnel is negotiated between the PAC/PNS pair. In a voluntary 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). 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.

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

  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 establish tunnel 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 As with L2TP control messages, L2TP payload packets are forwarded to UDP 1701.

  Figure 1-11. L2TP Tunnel Protocol Data Structure [View full size image]